Re: [1.2T-LC] title and desc example 'title-desc-tooltip.svg' (ISSUE-2060)

Doug Schepers:
....
>
> > - looking at the points list of #beeCell
> >   I came to the conclusion, that it is not a regular
> >   hexagon
>
> If you would be so kind as to make a true regular hexagon of similar
> dimensions, I'd be happy to change the example to use that instead.  Of
> course, if SVG had some sort of <polar> element, that would make it much
> easier to construct any regular polygon.

Without a possibility to note something in polar coordinates, it is not
even possible to specify a regular hexagon exactly at all with SVG 1.1 or
tiny1.2.
However, the following is a better approximation with about the same
file size:

points="-14 -24.2487 14 -24.2487 28 0 14 24.2487 -14 24.2487 -28 0"

    <use xlink:href="#beeCell" x="30" y="60" />
    <use xlink:href="#beeCell" x="75" y="34.0192" />
    <use xlink:href="#beeCell" x="120" y="60" />
    <use xlink:href="#beeCell" x="120" y="111.9615" />
    <use xlink:href="#beeCell" x="30" y="111.9615" />
    <use xlink:href="#beeCell" x="75" y="137.9423" />

    <use xlink:href="#beeCell" x="75" y="85.9808" />
>
> > (what is of course no problem, one cannot assume, that
> > a bee cell is really a regular hexagon),
>
> On the contrary, it's a little-known fact that bees always make perfect
> hexagons for their honeycombs, but they have a far more profound and
> advanced geometry than humans.  This also accounts for the seemingly
> irregular shape of each cell in a beehive, which adheres to a higher
> mathematics than we have yet discovered.

Maybe(e) they are much more familar with mathematics and polar coordinates 
(they are able to see the polar(isation) of light too ;o) than we think; there
is an alternative explanation, that those cell structures align themselves
like soap bubbles for a perfect symmetry due to some surface forces. 

>
> >   but then I do not understand the
> >   content of the meta element.
> >   Ok, the hexagon still has some symmetries, but
> >   four parameter are not sufficient to describe the
> >   hexagon (for a regular hexagon, four would be
> >   enough: center x,y, here 0,0, radius for corners,
> >   angle for one corner). Therefore without further
> >   explanation or reference to a specific namespace
> >   for hexagons it is not obvious, what the content
> >   of metadata could mean. Because there are
> >   not may samples for the use of metadata, it is
> >   useful to have it, but the relation to the parent
> >   element should be simpler to identify to have
> >   some profit from this part of the example.
>
> Oops.  That <metadata> element was an leftover artifact from when I was
> making the hexagon, and wasn't meant to be part of the example.  I've
> removed it.  Sorry about that.
>
Well, is useful to have some additional information about the structure
for such specific objects - such a reduced metadata in polar coordinates
can be pretty helpful to understand the construction or may simplify the
work to reconstruct such a shape, but of course, then it should be more
or less self explaining ;o)


> > - could be helpful to have somewhere an
> >   informative section including some more
> >   samples with short explanations for the content
> >   of role.
> >   I think, currently for a reader without
> >   a predisposition something like role="aria:tooltip"
> >   is not obvious, how this is constructed.
> >   For example in the referenced wai-aria document
> >   this is indicated as  'Role: tooltip'
>
> I agree that some more examples would help, including simpler ones with
> annotations, raster screencaps, and explanations, and I'm happy to work
> on that.

Yes, if we want to get this and those other new 'informative' attributes
get used by many authors and if we want more than to have them 
exist somehow in the DOM in such a way, that implementations may
provide those information on demand, it should be understandable,
how to use them, else they may remain as artefacts in the specification,
without ever appearing in 'real world documents'.

> > Additional side note:
> > Many examples in the draft have no title element,
> > but the chapter about title and desc notes:
> > "Authors should always provide at least a 'title', and preferably a
> > 'desc', as an immediate child element to the 'svg' element within an SVG
> > document."
> >
> > Well, if the examples in the draft have any educational functionality,
> > indeed, draft authors too should at least provide a title for the svg
> > element, if it is a complete sample and not just a document fragment
> > or should add some '...' to indicate, that it is only a fragment ;o)
> >
> > Or does this mean: "Authors should always provide at least a 'title' OR
> > primarily a 'desc' ...", because many samples have a 'desc' but no
> > 'title'?
>
> Most examples already in the spec were using the older, less-defined
> descriptions of <title> and <desc>, but the SVG WG will consider
> changing them as we have time.  I did remove those examples that seemed
> to contradict the new text-only content model of <title> and <desc>, and
> if you see any others, I'm happy to change those as well.

I'm still not convinced, that it is a good idea, to remove the other namespace
content from desc as well, because user agents are not required to interprete
other namespace content anyway. If they do not know the format or do not 
want to interprete it, they can simply only use the content of foreign
elements. For title indeed there is no need for other namespace content.

But one the other hand to use some semantic XHTML elements to structure
the content of desc for an alternative text display would be very nice,
especially for the desc of the (root) svg element. And it is for authors much
simpler to provide such a structured alternative within the svg desc as to
align and to structure the complete document in such a way, that the 
distrubuted title+desc elements provide a useful structure for an
alternative text representation, because this structure may have conflicts
with the graphical structure (which has to take into account the painters 
model as well), to cover both will typically a big challenge for any author of
a more complex document.
To move this into the metadata element is of course technically
possible, but obviously semantically metadata is not the same as a
description.

>
> However, the other examples in the spec are typically minimalistic, to
> illustrate a different point, so it's not clear that they need to be as
> rigorous as the ones that exemplify <title> and <desc>.  For the next
> version of the spec, we will take care to be more consistent in our
> examples.
>
> The SVG WG will discuss whether we can update the examples in the time
> we have allotted.  If this is satisfactory to you, please do let us know
> promptly.
>

Yes, sure, that is ok.



Olaf

Received on Tuesday, 23 September 2008 14:06:13 UTC