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

On Saturday, November 12, 2005, 5:17:26 AM, Boris wrote:

BZ> 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.

BZ> It's not clear to me whether "such content" here refers to "content produced by
BZ> illustration programs" or something else.

Something else; or rather, content (whether produced by illustration
programs or by other means) that does not exhibit this common flaw of
specifying a fixed width and height for no good reason.

BZ>   The only other antecendent I can see
BZ> here is "SVG content", and I doubt the intent is to have a MUST requirement that
BZ> "SVG content" have a viewBox.

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

That seems reasonable.

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

BZ> With which I was unfamiliar, unfortunately. The parenthetical helps,
BZ> 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.

BZ> Well, that is a good question. If the 'g' element has a background,

(how would it have a background?)

BZ> it's not painted in any way (not even under the shape determined by
BZ> all the descendants of the 'g'), right? That was, quite simply, not
BZ> clear to me.

Right. The individual descendents can paint, if they are graphical
elements. Is it clearer now?

>> 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.

BZ> My point was that there is nearly no description of what <desc> is.

Agreed

BZ>  And the
BZ> only thing really said about <title> is that it may be rendered as a tooltip...
BZ> but then the prose says:

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

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

The text now says that desc tends to be a longer description while title
is typically shorter.

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

That sounds like pretty good wording, actually.

>> Both shall and must are RFC2119 keywords.

BZ> 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.

BZ> Makes sense.

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

Thanks for your review!


-- 
 Chris Lilley                    mailto:chris@w3.org
 Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

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