Subject: [rfc-i] RFC 7996 fill and stroke "none"

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Oct 2021 20:37:44 +1100

RFC 7996 defines a fixed (and small) set of valid color values.  This is fine, but it also ends up prohibiting a very useful value for some attributes: "none".  stroke and fill attributes in particular permit this value: https://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint

svgcheck seems to be OK with this, but xml2rfc is choking on it.

It's possible to avoid needing to use a value of "none", but it invalidates certain ways of constructing SVG that might be more efficient or convenient or readable than alternatives.  For instance, if content is predominantly stroked content, using <g stroke="black"> is a tidy way to avoid repeating the attribute.

Adding a workaround is possible, but it seems better to allow this option.
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian Carpenter <[email-masked]>
Date: Wed, 20 Oct 2021 22:51:18 +1300

I don't have access to my code right now, but I thought that svgcheck did
object to stroke="none". At any rate, my fixup code simply deletes it, and
usually that seems to work fine. I haven't encountered fill="none".

Regards,
    Brian Carpenter
    (via tiny screen & keyboard)

On Wed, 20 Oct 2021, 22:38 Martin Thomson, <[email-masked]> wrote:

> RFC 7996 defines a fixed (and small) set of valid color values.  This is
> fine, but it also ends up prohibiting a very useful value for some
> attributes: "none".  stroke and fill attributes in particular permit this
> value: https://www.w3.org/TR/SVGTiny12/painting.html#SpecifyingPaint
>
> It's possible to avoid needing to use a value of "none", but it
> invalidates certain ways of constructing SVG that might be more efficient
> or convenient or readable than alternatives.  For instance, if content is
> predominantly stroked content, using <g stroke="black"> is a tidy way to
> avoid repeating the attribute.
>

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Oct 2021 21:17:45 +1100

On Wed, Oct 20, 2021, at 20:51, Brian Carpenter wrote:
> I don't have access to my code right now, but I thought that svgcheck 
> did object to stroke="none". At any rate, my fixup code simply deletes 
> it, and usually that seems to work fine. I haven't encountered 
> fill="none".

The tool that I'm modifying used it quite a bit.  It needed to because it was overriding directives higher up in the tree.  I'm removing it, but I think that it should be permitted; it's a perfectly valid and useful thing to use.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 20 Oct 2021 22:30:57 +1100

On Wed, Oct 20, 2021, at 21:17, Martin Thomson wrote:
> The tool that I'm modifying used it quite a bit.  It needed to because 
> it was overriding directives higher up in the tree.  I'm removing it, 
> but I think that it should be permitted; it's a perfectly valid and 
> useful thing to use.

So I found that curved paths in the tool I'm using definitely need fill="none".  The default fill is black[1], so it turns out that I need this change to avoid things looking pretty weird.

[1] https://www.w3.org/TR/SVGTiny12/painting.html#FillProperty

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2021 09:09:39 +1300

> So I found that curved paths in the tool I'm using definitely need fill="none".  The default fill is black[1], so it turns out that I need this change to avoid things looking pretty weird.

That makes sense. I never happened to encounter fill="none" when playing with various tools. stroke="none" on the other hand seems to
be essentially a no-op.

Anyway: RFC7996 is high on my list of things somebody needs to fix ASAP.

   Brian

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Oct 2021 23:00:37 +0200

On 2021-10-20, at 11:37, Martin Thomson <[email-masked]> wrote:
> xml2rfc is choking on it

I haven’t investigated this in any depth, but 

18 matches for " fill " in buffer: SVG-1.2-RFC.rnc
     16:     & (attribute fill { "none" | rfc-color }?,

Yes, I also ran into the curved paths, but I seem to remember I worked around some of this (can’t find any specific code in kramdown-rfc right now).

Grüße, Carsten

---

From: "John Levine" <[email-masked]>
Date: 20 Oct 2021 21:44:57 -0400

>Anyway: RFC7996 is high on my list of things somebody needs to fix ASAP.

Your offer of help is gratefully accepted.

I think we have figured out that trying to define our SVG profile by enumerating the elements didn't work, so I'd rather
try to describe the result we want, something like this:

* static drawings with no animation

* only black and white colors

* renders legibly at sizes readers are likely to use, say from a 11cm phone screen to A4 paper

* text items at least as legible as the surrounding text

* can be created and edited by available tools

* text can be selected and copied (desirable but due to tool limits, not required)

R's,
John

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 20 Oct 2021 19:21:40 -0700

On 20 Oct 2021, at 18:44, John Levine wrote:

>> That makes sense. I never happened to encounter fill="none" when 
>> playing with various tools. stroke="none" on the other hand seems to
>> be essentially a no-op.
>>
> I think we have figured out that trying to define our SVG profile by 
> enumerating the elements didn't work, so I'd rather

Not sure how to word this, but text in the artwork must be searchable. 
Also, require alt-text?

--Paul Hoffman

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Oct 2021 07:23:44 +0200

> * text can be selected and copied (desirable but due to tool limits, not required)

The question is when we'll be able to get that done.

In the meantime, would it make sense to raise errata ("held for
update"), so we can collect and agree upon the most pressing changes?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2021 07:27:45 +0200

> Not sure how to word this, but text in the artwork must be searchable. 

Why?

This is clearly a desirable (which needs to be weighed against other desirables), not a MUST.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2021 08:29:30 +0200

On 21. Oct 2021, at 08:15, Larry Masinter <[email-masked]> wrote:
> 
> Artwork which contains text needs accessible and searchable alt-text 

The searchability is usually provided by the plain-text version.

Accessibility — yes, we should spend more effort there.
I can’t find anything in RFC 7996 that would lead me there.

The XML source usually has an <artset element (which was invented after RFC 7991), which combines the SVG with a plaintext replacement.
If that is ASCII art, it is probably not that accessible, but at least searchable.
I’m not sure the plaintext subtree of the <artset makes it into the HTML.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2021 08:54:11 +0200

On 2021-10-21, at 08:47, Larry Masinter <[email-masked]> wrote:
> Carston wrote:
> RFC 7995 calls for PDF/UA which encourages it.

The authors don’t get to produce that PDF.
The RPC does, but they probably don’t want to produce text out of thin air.
This should be an automated process, starting from the XML.
Where do we put that information in the XML?

>> The XML source usually has an <artset element (which was invented after
>> RFC 7991), which combines the SVG with a plaintext replacement.
> Guideline 1.1 of WCAG https://www.w3.org/WAI/WCAG21/quickref/
> Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.

Right.  The HTML is generated from the XML.
So where do we put that information in the XML?

Grüße, Carsten

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 21 Oct 2021 18:07:21 +1100

(I'm not getting Larry's email; is there a list configuration/DMARC issue?)

> The searchability is usually provided by the plain-text version.

I think that Larry is making point about what accessibility means: it means being able to find the text that was read/displayed.  This applies to all versions.

Paul was careful to make two recommendations though and I don't want them to be mistaken for the other.

1. If I see text in a diagram, I might like to be able to search for that text and have that text found.  This means no rendering of text as paths and using a sensible DOM for the SVG

2. Accessibility depends on having textual descriptions of the content of diagrams.  Clearly, that text should be searchable by those that are using it.

> I’m not sure the plaintext subtree of the <artset makes it into the 

I have to ask, is there any sense in providing an alt-text variant as well?  That might provide HTML <img alt="" (or aria-something attribute) content.  Providing alt-text on images is pretty easy to do and of great utility for those who depend on it; it seems like it might be worth doing.

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2021 09:24:19 +0200

On 2021-10-21, at 09:07, Martin Thomson <[email-masked]> wrote:
> 
> 1. If I see text in a diagram, I might like to be able to search for that text and have that text found.  

Yes.

> This means no rendering of text as paths and using a sensible DOM for the SVG

This is the weird part I don’t understand.

It is way more important to be able to have figures like
https://www.rfc-editor.org/rfc/rfc9100#section-2-3.1.1

Why not have the search result pop up through the plaintext?

(The alt-text would probably actually have the LaTeX source to the formula.)

Maybe you should explain what you mean by searching.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Thu, 21 Oct 2021 09:25:37 +0200

> I have to ask, is there any sense in providing an alt-text variant as well?  That might provide HTML <img alt="" (or aria-something attribute) content.  Providing alt-text on images is pretty easy…

That would go *into* the SVG as @title and/or @desc; see
<https://css-tricks.com/accessible-svgs/>.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 21 Oct 2021 09:36:18 +0200

> <https://css-tricks.com/accessible-svgs/>.

Ah, there we are.

So the next step will be to find out how to best author these.

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 21 Oct 2021 12:44:30 -0400

> I can’t find anything in RFC 7996 that would lead me there.

Me neither.  We clearly need to require the alt text, but not sure how to 
best make it available.  We might twiddle the existing HTML with a popup 
of some sort, or maybe add an accessible HTML version that has the alt 
text instead of the SVG and doesn't have so much stuff helpfully appearing 
and disappearing.  I think that's better than the unformatted text since 
it has the document structure so you can easily skip from one section to 
the next or from the TOC to a section.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
rfc-interest mailing list
[email-masked]
https://www.rfc-editor.org/mailman/listinfo/rfc-interest

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Oct 2021 11:00:21 +1300

a) John, I really didn't volunteer. I just don't have the expertise in
things like rng that seem to be necessary.

b) Julian, wouldn't an issue tracker be more effective than RFC errata
for tracking the issues? I think they go a lot beyond specific errors
in 7996. I assume that one of the first outcomes will be dumping
Tiny SVG.

   Brian

On 21-Oct-21 18:23, Julian Reschke wrote:
> .

---

From: Julian Reschke <[email-masked]>
Date: Sun, 24 Oct 2021 14:23:59 +0200

> things like rng that seem to be necessary.

If RNC/RNG knowledge is the culprit, I'm happy to help.

> in 7996. I assume that one of the first outcomes will be dumping

I was looking for a way where we can actually make progress in the short
term without having a replacement for the spec in place.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 24 Oct 2021 15:30:08 +0200

> term without having a replacement for the spec in place.

Yes please.

Please remember that, since RFC 7991 was published, we were able to fix many issues, including completely reinventing the way SVG is integrated into RFCXMLv3 — without republishing RFC 7991 (<artset is the first place where RFCXMLv3 explicitly acknowledged that we have multiple rendering formats, some of which differ in the information they need from the published XML).  If we were able to do that, we should be able to fix the biggest stumbling blocks put into place by RFC 7996, in an unceremonious way.

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Sun, 24 Oct 2021 16:56:51 +0200

> Please remember that, since RFC 7991 was published, we were able to fix many issues, including completely reinventing the way SVG is integrated into RFCXMLv3 — without republishing RFC 7991 (<artse…

I agree in general.

<artset> IMHO was not needed, but that's what under the bridge.

Best regards, Julian

---

From: "John Levine" <[email-masked]>
Date: 24 Oct 2021 18:00:33 -0400

><artset> IMHO was not needed, but that's what under the bridge.

What would you do instead?  Rendering SVG into ASCII art doesn't work very well.

I'm thinking there are cases where a three-way artset would make sense when the
artwork is equations, the SVG for HTML snd PDF, an ASCII art version for the TXT,
and latex or similar source for an acessible version.

R's,
John

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 25 Oct 2021 00:30:41 +0200

> and latex or similar source for an acessible version.

Ah.  For kramdown-rfc features such as “protocol-goat”, “plantuml-utxt”, or “railroad-utf8", where a brief source input file generates both ASCII (really: UTF-8) art and SVG, I’d love to be able to ship the source input as well.  For that, we’d need to put “sourcecode” into an artset…

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 24 Oct 2021 21:34:31 -0400

> Ah.  For kramdown-rfc features such as “protocol-goat”, “plantuml-utxt”, or “railroad-utf8", where a brief source input file generates both ASCII (really: UTF-8) art and SVG, I’d love to be able to…

Well, for accessibility it does have to be a source language that the 
person reading the document is likely to be familiar with.  Latex
probably, protocol-goat not so much.

Regards,

---

From: Julian Reschke <[email-masked]>
Date: Mon, 25 Oct 2021 08:35:35 +0200

> What would you do instead?  Rendering SVG into ASCII art doesn't work very well.

V2 already had an ASCII fallback, we could have used that.

<artset> has introduced a lot of complexity for formatters, and some of
the issues caused by that are still open (see
<https://github.com/rfc-format/draft-iab-xml2rfc-v3-bis/issues/136>).

> and latex or similar source for an acessible version.

Interesting; I always had doubts about <artset> that is used for more
than an ASCII fallback.

It would be indeed interesting to find out about accessibility
recommendations for math. Requiring authors to maintain 3 different
versions consistenly sounds like asking for trouble, though.

Best regards, Julian

PS: let's fix SVG inclusion first.

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 25 Oct 2021 08:51:30 +0200

> versions consistenly sounds like asking for trouble, though.

That’s why it’s best to generate 2 forms out of the third…

> On 2021-10-25, at 03:34, John R Levine <[email-masked]> wrote:
> 
> Well, for accessibility it does have to be a source language that the person reading the document is likely to be familiar with.  Latex

The source notation that the “protocol” tool uses is rather “accessible” (pun intended):

~~~ protocol-goat
Source:16
Reserved:40
TTL:8
~~~

becomes

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Source            |                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+
|                    Reserved                   |      TTL      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and that becomes

on the SVG side (HTML, PDF) via goat.

Grüße, Carsten

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Oct 2021 11:10:00 -0400

> I'm thinking there are cases where a three-way artset would make sense
    > when the artwork is equations, the SVG for HTML snd PDF, an ASCII art
    > version for the TXT, and latex or similar source for an acessible
    > version.

draft-ietf-cellar-ffv1 (now RFC9043) had lots of math and a complex mmark
workflow to produce SVG for the math.
That document was the Informational pre-standardization description.
It has a fork which is: draft-ietf-cellar-ffv1-v4  which is still in the
work.

I mention this in case someone wants to study what was done, suggest new
things to do, and/or suggest experiments on either doing this better, or
spreading the good work.

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: "John R Levine" <[email-masked]>
Date: 25 Oct 2021 13:25:47 -0400

> The source notation that the “protocol” tool uses is rather “accessible” (pun intended):

A long time ago I made recorded versions of engineering textbooks for 
blind students, on reel-to-reel tapes.  When we got to a figure, I had to 
describe its appearance.  So this figure would be something like this:

The figure is a grid 32 cells wide, numbered from 0 to 31 at the top, and 
two rows high.  The first 16 cells in the first row are grouped into a box 
called Source.  The rest of the first row and the first 24 cells of the 
second row up to cell 23, a total of 40 cells, are grouped into a box 
called Reserved.  The last 8 cells, 24 to 31, are grouped into a box 
called TTL.

I suppose one could generate that mechanically, or more likely we'd point 
to a place that has a general description of goat diagrams, and then just 
lists the three fields.

Accessibility is complicated and I do not know haw much we can reasonably 
do ourselves and how much we might leave for people who do this 
professionally.

R's,
John

PS: One of ISOC's current board members is blind so the issue of 
accessibility is getting more attention all over ISOC.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Oct 2021 14:49:02 -0400

John R Levine <[email-masked]> wrote:
    > blind students, on reel-to-reel tapes.

Wow!

    > When we got to a figure, I had
    > to describe its appearance.  So this figure would be something like
    > this:

    > The figure is a grid 32 cells wide, numbered from 0 to 31 at the top,
    > and two rows high.  The first 16 cells in the first row are grouped
    > into a box called Source.  The rest of the first row and the first 24
    > cells of the second row up to cell 23, a total of 40 cells, are grouped
    > into a box called Reserved.  The last 8 cells, 24 to 31, are grouped
    > into a box called TTL.

So, that sure describes the diagram, but does it really describe the packet?

    > accessibility is getting more attention all over ISOC.

I'd be curious if they wouldn't prefer to know that the first first sixteen bits
are source, there are 20 bits reserved, and then 8 bits of TTL.

---

From: "John R Levine" <[email-masked]>
Date: 25 Oct 2021 15:49:21 -0400

> So, that sure describes the diagram, but does it really describe the packet?

No, but at least for Recording for the Blind, that was the style, describe 
the diagram, don't try to interpret it.  We got into some head scratchers 
when I was reading computer texts that had obvious errors.

> are source, there are 20 bits reserved, and then 8 bits of TTL.

They probably would, but wouldn't that also be in the text?  I am not 
wedded to that particular form of description, but it needs to be more 
than the three lines of goat-ish that generated it.

Regards,

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2021 11:03:31 +1300

> accessibility is getting more attention all over ISOC.

We had our own in-house consultant when Sam Hartman was
Security AD. (I think he was the origin of the "no Javascript"
rule for the web sites: a twin security and accessibility
argument.)

     Brian

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 25 Oct 2021 16:28:01 -0700

> rule for the web sites: a twin security and accessibility

To the best of my knowledge, forbidding JS does not meaningfully improve
accessibility
because the a11y tools scrape the DOM and well written JS-based single page
apps
manipulate the DOM. It's of course true that it's possible to make JS-based
apps
that are inaccessible, but it's also possible to do that without JS (e.g.,
render the page
as one giant PNG). Moreover, if you build the system the way I suggested,
using
server-based Web APIs and JS-based clients, it's much easier for someone to
write
their own client, which promotes a11y.

As far as security goes, I don't think this is a particularly strong
argument. It's of
course true that browser JS engines are a major source of compromise of
browsers
(something like half of exploitable vulnerabilities start in the JS
system), so you
might argue that you could improve the security of your browser by
disabling the
JS engine. However, as a practical matter, it's very difficult to use the
Web without
JS at all and common tools (e.g., NoScript) allow you to selectively enable
JS for
certain sites, which limits your exposure to those sites. While it's of
course possible
that the IETF site would be compromised and would attack you, this seems
like
a fairly modest additional risk.

-Ekr

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2021 14:19:19 +1300

Eric,

Not arguing about today's situation. Back around 15 years ago, I recall
that Sam encountered big problems with pages that invoked js.

Regards
    Brian

On 26-Oct-21 12:28, Eric Rescorla wrote:
> 
> 
> On Mon, Oct 25, 2021 at 3:03 PM Brian E Carpenter <[email-masked] <mailto:[email-masked]>> wrote:
> 
> To the best of my knowledge, forbidding JS does not meaningfully improve accessibility
> because the a11y tools scrape the DOM and well written JS-based single page apps
> manipulate the DOM. It's of course true that it's possible to make JS-based apps
> that are inaccessible, but it's also possible to do that without JS (e.g., render the page
> as one giant PNG). Moreover, if you build the system the way I suggested, using
> server-based Web APIs and JS-based clients, it's much easier for someone to write
> As far as security goes, I don't think this is a particularly strong argument. It's of
> course true that browser JS engines are a major source of compromise of browsers
> (something like half of exploitable vulnerabilities start in the JS system), so you
> might argue that you could improve the security of your browser by disabling the
> JS engine. However, as a practical matter, it's very difficult to use the Web without
> JS at all and common tools (e.g., NoScript) allow you to selectively enable JS for
> certain sites, which limits your exposure to those sites. While it's of course possible
> that the IETF site would be compromised and would attack you, this seems like

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 26 Oct 2021 10:29:06 +0900

> their own client, which promotes a11y.

Forbidding JS may not improve accessibility in a particular case, but it 
eliminates inaccessible JS-based apps. Just because it's possible to 
create a web page as one giant PNG, that's not really what web page 
creators do. Adding some JS that leads to inaccessibility is much more 
frequent. Making sure JS does not affect accessibility is really hard.

Anyway, for RFC purposes, it's not an issue at all, because it would be 
either uniform vetted JS or (better) no JS　anyway. I can't imagine 
allowing JS to vary per RFC.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 26 Oct 2021 10:36:04 +0900

> https://www.rfc-editor.org/rfc/rfc9100#section-2-3.1.1

I have no idea why the "52" or "version" or "present" should not be 
searchable, and could not be made searchable. Text in SVGs should be 
text, and that should be possible also for Math. The fact that this 
particular example uses paths instead of an italic font doesn't mean 
there isn't a way to do it better.

> Why not have the search result pop up through the plaintext?

When people search, they want to find all occurrences. If they are 
looking for a formula, they want to find the formula, not something else.

> (The alt-text would probably actually have the LaTeX source to the formula.)

It may have the formula in LaTeX source (for those who read LaTeX) and 
in a textual description (for others).

> Maybe you should explain what you mean by searching.

Finding (all!) the stuff we see (or hear or feel) when reading the document.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 26 Oct 2021 10:58:48 +0900

On 2021-10-26 04:49, John R Levine wrote:
>>    > The figure is a grid 32 cells wide, numbered from 0 to 31 at the 
>> top,
>>    > and two rows high.  The first 16 cells in the first row are grouped
>>    > into a box called Source.  The rest of the first row and the 
>> first 24
>>    > cells of the second row up to cell 23, a total of 40 cells, are 
>> grouped
>>    > into a box called Reserved.  The last 8 cells, 24 to 31, are grouped
>>    > into a box called TTL.
>>
> No, but at least for Recording for the Blind, that was the style, 
> describe the diagram, don't try to interpret it.  We got into some head 
> scratchers when I was reading computer texts that had obvious errors.

I think the idea is to provide blind people with an experience as close 
to those of seeing people as possible. Discussions might be in terms of 
the diagram. Blind people may need to know how such diagrams look 
because they may want to create or check them themselves when they write 
their own drafts/RFCs, and so on.

Regards,   Martin.

---

From: "John Levine" <[email-masked]>
Date: 26 Oct 2021 23:14:33 -0400

It appears that Martin J. Dürst <[email-masked]> said:
>searchable, and could not be made searchable. 

Because the programs that people use to edit SVG don't represent
text in a searchable way.  You want it stored as strings to search it,
but they place each character individually.

Don't complain to me, complain to the people who write the SVG editors.

R's,
John

---

From: Martin J. Dürst <[email-masked]>
Date: Wed, 27 Oct 2021 15:00:13 +0900

Hello John, others,

> but they place each character individually.

My question was from a user viewpoint. And I think the user viewpoint is 
what we should consider first and foremost. I know there are crappy tools.

> Don't complain to me, complain to the people who write the SVG editors.

I didn't complain to you, I complained to Carsten if anybody. 
Complaining to people who write crappy SVG tools seems to be a lost 
cause, it has happened for a long time, but in some cases apparently 
without much effect.

I think the choice we should take is to just avoid such tools, in order 
to provide the best possible experience to the user.

Regards,   Martin.

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 27 Oct 2021 08:30:28 +0200

> My question was from a user viewpoint. And I think the user viewpoint is what we should consider first and foremost. I know there are crappy tools.

You are forgetting the most important user community: those that actually make these RFCs.
An RFC that is not made (or made worse by the lack of good illustrations) serves nobody.

> I didn't complain to you, I complained to Carsten if anybody.

Yes, I have put some features into kramdown-rfc that can make it easier to generate SVG illustrations.
To me, it was more important that these come to life in the first place and serve well as illustrations.
Whether the SVG generated looks crappy on the XML side is pretty much irrelevant to this objective.

> Complaining to people who write crappy SVG tools seems to be a lost cause, it has happened for a long time, but in some cases apparently without much effect.

Unless we write the universal diagram editor, we’ll have to live with what we have.
Searchability of the output is a nice-to-have (the information already is in the plaintext or you are holding it wrong); blowing this up to a hard requirement is a complete non-starter.

> I think the choice we should take is to just avoid such tools, in order to provide the best possible experience to the user.

The best possible experience to the author, so they can produce the best possible result (and illustration that actually illustrates) within the limited time budget they have, is *way* more important than the abstract concept of crappiness peddled here.

Grüße, Carsten

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Oct 2021 09:11:47 +1300

> You are forgetting the most important user community: those that actually make these RFCs.

Right, but one thing that has not yet been done adequately is a clear list of drawing tools that are fit for (this) purpose, and which features of 
those tools to avoid.

     Brian

> The best possible experience to the author, so they can produce the best possible result (and illustration that actually illustrates) within the 
limited time budget they have, is *way* more important than the abstract concept of crappiness peddled here.

---

From: "John R Levine" <[email-masked]>
Date: 27 Oct 2021 16:58:32 -0400

On Thu, 28 Oct 2021, Brian E Carpenter wrote:
> Right, but one thing that has not yet been done adequately is a clear list of 
> drawing tools that are fit for (this) purpose, and which features of those 
> tools to avoid.

People who have more experience with SVG than I do tell me that the tools 
that produce good SVG aren't the ones that produce nice text strings.

It seems to me that any string you're looking for should be in the alt 
text, so what we need to do is make sure the alt text is in the rendered 
versions in a way that searches will find the picture.

Regards,

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 28 Oct 2021 02:35:30 +0200

On 27. Oct 2021, at 22:58, John R Levine <[email-masked]> wrote:
> 
> It seems to me that any string you're looking for should be in the alt text, so what we need to do is make sure the alt text is in the rendered versions in a way that searches will find the picture.

I assume that when you say “alt text” you mean the title= and desc= attributes of SVG?

We need to develop a convention what to put in there and how that will be presented (rendered).
This should be driven by realistic examples coming from actual draft authors…

We should that collecting these examples now.
https://www.rfc-editor.org/rfc/rfc9100.html#section-2-3.1.1 certainly could have had a description that is more accessible than the ASCII art in https://datatracker.ietf.org/doc/html/rfc9100#section-2 — e.g., the Latex-style math input 

	version = \sum_{fc=0}^{52} present(fc)  ⋅  2^{fc}

(I think I can now admit that I put that formula into the RFC because I could, not because it is particularly elucidating.  Just imagine that it were :-)

Grüße, Carsten

---

From: "John R Levine" <[email-masked]>
Date: 27 Oct 2021 20:47:26 -0400

> I assume that when you say “alt text” you mean the title= and desc= attributes of SVG?

I was thinking of the ASCII art part of the <artset> but I'm open to 
suggestions.

> This should be driven by realistic examples coming from actual draft authors…

Definitely.

Regards,