Re: [SVGMobile12] Comments: Document Structure (partial comments)

Chris Lilley wrote:
> Due to this and other comments on this section, it now reads
>
>   Content produced by illustration programs originally targeted at print
>   often has a fixed width and height, which will prevent it scaling for
>   different display resolutions. The first example below has a fixed
>   width and height in pixels, and no viewBox.
> 
>   Normally, SVG content is designed to be scalable. Such content must
>   include a viewBox attribute on the 'svg' element.

It's not clear to me whether "such content" here refers to "content produced by 
illustration programs" or something else.  The only other antecendent I can see 
here is "SVG content", and I doubt the intent is to have a MUST requirement that 
"SVG content" have a viewBox.

Should this say "To be scalable, SVG content must include ...", perhaps?  Or 
something along those lines?

> BZ> The phrase "world coordinate space" is not defined anywhere that I
> BZ> can see.
> 
> It has its normal computer graphics meaning

With which I was unfamiliar, unfortunately.  The parenthetical helps, thank you.

> BZ> It's not clear whether the <g> element itself is painted, and if so
> BZ> how.
> 
> It is not clear how a 'g' element *could* be painted.

Well, that is a good question.  If the 'g' element has a background, it's not 
painted in any way (not even under the shape determined by all the descendants 
of the 'g'), right?  That was, quite simply, not clear to me.

> BZ> What is the difference between <desc> and <title>? Why are both
> BZ> present here?
> 
> Because desc is more like HTML longdesc, while title is more like HTML
> title. Except that both are elements, as recommended by the I18n folks.

My point was that there is nearly no description of what <desc> is.  And the 
only thing really said about <title> is that it may be rendered as a tooltip... 
but then the prose says:

   If user agents need to choose among multiple 'desc' or 'title' elements for
   processing (e.g., to decide which string to use for a tooltip)

which re-blurs the distinction between the two.  Note that even the minimal 
"desc is more like HTML longdesc, while title is more like HTML title" 
description is absent in the spec as it stands now.

I would suggest adding a description of what these elements actually mean 
semantically (e.g. "The <desc> element contains a detailed description for the 
container or graphics element containing it.  This description should be usable 
as replacement content for cases when the user cannot see the rendering of the 
SVG element for some reason.  The <title> element contains a short title for the 
container or graphics element containing it.  This short title provides 
information supplementary to the rendering of the element, but is not sufficient 
to replace it.").  Or something.  I'm just guessing at the intent based on the 
comparison to longdesc and title.

> Both shall and must are RFC2119 keywords.

Fair enough.

> Yes. We have fixed this to refer to the computed values on the
> referencing elements. We retained 'specified' on the referenced
> elements, since it is the process of inheritance that is being
> described; to refer to the computed value, which might be inherited,
> would be circular and would leave it unclear where it was inherited from.

Makes sense.

The rest of the responses in this mail look OK at first glance.

-Boris

Received on Saturday, 12 November 2005 04:17:31 UTC