Subject: [xml2rfc-dev] RFC 7991 issue #34: <artwork> src and content confusion

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Oct 2018 23:29:08 +0000

(From Miek Gieben)

Section 2.5

Alternatively, the "src" attribute allows referencing an external
graphics file, such as a vector drawing in SVG or a bitmap graphic
file, using a URI. In this case, the textual content acts as a
fallback for output representations that do not support graphics;
thus, it ought to contain either (1) a "line art" variant of the
graphics or (2) prose that describes the included image in sufficient
detail.

And later:

It is an error to have both a "src" attribute and content in the
<artwork> element.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 3 Oct 2018 23:33:10 +0000

> It is an error to have both a "src" attribute and content in the

Yeeps. That later sentence seems wrong, particularly when you look at the "alt" attribute:

2.5.2.  "alt" Attribute

   Alternative text description of the artwork (which is more than just
   a summary or caption).  When the art comes from the "src" attribute
   and the format of that artwork supports alternate text, the
   alternative text comes from the text of the artwork itself, not from
   this attribute.  The contents of this attribute are important to
   readers who are visually impaired, as well as those reading on
   devices that cannot show the artwork well, or at all.

--Paul Hoffman

---

From: Robert Sparks <[email-masked]>
Date: Thu, 4 Oct 2018 12:31:12 -0500

>     devices that cannot show the artwork well, or at all.
I don't see that as wrong. Content in the artwork element means 
<artwork>Content</artwork>, no?
What the text is trying to avoid is the ambiguity introduced by
<artwork src="a place with content that looks like T">content that looks 
almost, but not entirely, unlike T</artwork>

(Apologies if I'm being a bit sloppy, but I think that gets the point 
across? I see the alt attribute as orthoganal.

RjS
>
> --Paul Hoffman
>
>
>
> _______________________________________________
> xml2rfc-dev mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/xml2rfc-dev

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 4 Oct 2018 18:36:52 +0000

On Oct 4, 2018, at 10:31 AM, Robert Sparks <[email-masked]> wrote:
> I don't see that as wrong. Content in the artwork element means <artwork>Content</artwork>, no?
> <artwork src="a place with content that looks like T">content that looks almost, but not entirely, unlike T</artwork>

Fully agree, but the "it is an error" is a technical prohibition on something that the text at the beginning and middle of the same section allows. I think that prohibition needs to be removed.

--Paul Hoffman

---

From: Jim Schaad <[email-masked]>
Date: Thu, 4 Oct 2018 14:33:48 -0700

> -----Original Message-----
> From: xml2rfc-dev <[email-masked]> On Behalf Of Paul
> Hoffman
> Sent: Thursday, October 4, 2018 11:37 AM
> To: Robert Sparks <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [xml2rfc-dev] [Ext] RFC 7991 issue #34: <artwork> src and
content
> confusion
> >>> graphics or (2) prose that describes the included image in
> >>> sufficient detail.
> >>>
> >>> And later:
> >>>
> >> Yeeps. That later sentence seems wrong, particularly when you look at
the
> "alt" attribute:
> > <artwork src="a place with content that looks like T">content that
> > looks almost, but not entirely, unlike T</artwork>
> 
> Fully agree, but the "it is an error" is a technical prohibition on
something that
> the text at the beginning and middle of the same section allows. I think
that
> prohibition needs to be removed.

I have never been really happy with this.  I would have preferred to keep
both the "good" artwork and the "alt" artwork as first class citizens of the
artwork element.  I don't want to have a 55 line ascii art version of the
picture.  I realize that this is legal but ugly.  There should perhaps be an
"alt-src" attribute which could be used to pick up the alt version from a
file and then only could end up with a really long alt attribute only after
running the prep-tool.

Jim