W3C home > Mailing lists > Public > www-svg@w3.org > November 2005

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

From: Doug Schepers <doug@schepers.cc>
Date: Sat, 12 Nov 2005 00:09:02 -0500
To: "'Chris Lilley'" <chris@w3.org>, "'Boris Zbarsky'" <bzbarsky@mit.edu>
Cc: <www-svg@w3.org>
Message-Id: <20051112050907.DE5161962B0@plunder.dreamhost.com>


Chris Lilley wrote:
| >> BZ> It's not clear whether the <g> element itself is 
| painted, and if 
| >> BZ> so 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?)

Boris, I think you may be conflating SVG's 'g' behavior with that of a 'div'
or 'span' (etc.) in HTML. SVG doesn't use the CSS box model, so there is no
explicit background that equates to the bounding box of the group's child
elements. Thus, there is nothing that is rendered (or that can take a paint
server) as there is in HTML. You *can* assign a fill, stroke, pattern,
filter, gradient, etc. to a group, but that is only for the purpose of
cascading it down to the child elements, which may or may not inherit it
depending on their own attributes and properties. 

As a side note, filters on a group do render differently than the same
filter applied to each individual child element, since for the purposes of
the filter applied to the group, the child elements are composited previous
to the application of the filter (I think that's the only difference in
rendering that you can see from a styling attribute applied to a group,
unless gradient acts the same way).

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

Boris, just to clarify (or confuse, if I'm wrong about what you're
thinking), I don't think this is talking about multiple sibling 'title'
elements; consider the case where you are hovering over this fragment:

   <title>My Group</g>
   <desc>This decribes my group</desc>

   <circle ... >
      <title>My Circle</g>
      <desc>This decribes my circle</desc>

   <polygon ... >
      <title>My Polygon</g>
      <desc>This decribes my polygon</desc>

Which title/desc do you display, the one of the element you're hovering
over, or that of the group of which that element is a child? There needs to
be some way of resolving that, and I think that's what the tooltip hint is

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

Chris, I prefer Boris' wording to "desc tends to be a longer description
while title is typically shorter". It explains the intent of the elements,
and is an implicit best-practice statement (though it should be
non-normative, of course). Is it possible to use that wording or something
like it in the Spec?


www.vectoreal.com ...for scalable solutions.
Received on Saturday, 12 November 2005 05:09:19 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:05 UTC