Re: Animating SVG attributes from Web Animations

On Sat, Jun 20, 2015 at 11:07 AM, Bob Hopgood <frahopgood@gmail.com> wrote:
> Apologies for responding to the wrong mail list but that is where the
> question arose.
>
> You say:
>
>> "(But there's nothing wrong with putting strings like that in CSS; I'm
>> unsure why you think there's a meaningful difference between <path
>> d="giant string"> and <path style="d: 'giant string'">.)"
>
> I didn't say there was a meaningful difference. I just asked whether CSS
> implementations were capable of handling 1 Megabyte or even 50 kbyte
> strings. Current SVG implementations have a problem handling very large
> numbers  of animated path descriptions while handling long path descriptions
> pretty well. (In consequence I have to distort the structure of an animation
> by compounding paths together to get reasonable performance.)
> The question was whether CSS implementations would be better or worse than
> the SVG implementation ?

If there are any problems, and they happen in practice, then they'll
be fixed.  Nothing more really needs to be said; there's nothing
theoretically making this difficult.

>> "A <path> carries no intrinsic meaning, just like an <img>; it is completely
>> opaque to a search engine, screen-reader, or other machines.  It is entirely
>> unlike text content."
>
> The example above in HTML would be:
>
> (1)
> h2.abc {text:giantstring}  in a stylesheet xyz.css and
>
> <h2 class="abc" text=""/> in the file sometext.htm
>
> in the HTML document compared with:
>
> (2)
> <h2 text="giant text string" /> in the file meaningfultext.htm
>
> There is a difference in how the XML elements are written in SVG and HTML.
> HTML writes the content of the element as  the content of the h2 whereas SVG
> writes the content of the path element as a d attribute. HTML quite rightly
> does not allow  the text content of the h2 to be changed by styling
> otherwise  the search engines would produce rubbish.  Similarly, SVG 1.1
> does not allow the graphical content of the path element to be restyled by a
> stylesheet. Otherwise a person reading the path description on a high
> quality search engine or screen reader could not understand the meaning at a
> superficial level.

There is no such "high-quality search engine or screen reader".
Purely theoretical OCR user agents don't really factor into this.  If
they did, they'd be required to be smart enough to actually apply CSS
and JS, too.

> Even the simplest of search engines should be able to see that:
> <path d="M0,0h30v-30h-60v30h30v30h30v30h-60v-30h30"/> defines a flow diagram
> with two boxes just as a search engine should be able to recognise
> <h2>Schemat przeplywu</h2>

No search engine in existence sees this.  (Nor do I, a human - if I
put that into a document it's a black square. If I make it stroke
rather than fill it's a squared-off S shape.)  Nor do I expect any
search engines to do so; you're assuming a rather remarkable degree of
AI competency that does not exist today.

> Students at Oxford Brookes University since 2000 have regularly had exam
> papers with path descriptions much more complicated than the one above that
> they must understand and most get good grades with no real difficulty. Only
> three have  had any idea what the HTML meant.They were European Union
> Erasmus exchange students from Poland.
>
> Personally I have no problem with theSVG and have no ability to say what the
> HTML means.  I tried Google for the HTML and the first 50 responses were in
> a language that I did not understand. I tried M0,0h30 and at least there was
> one entry in the top 10 that was concerned with SVG.

I have no idea what you're trying to say here.  Regardless, it seems
utterly unconnected to the topic at hand.

> Zaineb BEN FREDJ's  thesis "Enquiring and Reasoning Over Diagrams Using the
> Semantic Web" describes a system GraSSML built on SVG that can be used by
> blind users to reason over a range of formal diagrams. There is also
> interest in geometric search engines, see
> http://visionair.ge.imati.cnr.it/gse/.
>
> The main point is that the text in HTML is content as is the d attribute of
> SVG and neither should be changed by a stylesheet and a decent search engine
> should be able to extract meaning from both, which is the reason that a
> stylesheet should not be allowed to change rthe content in either.

Again, no search engine in existence does so.  If such a search engine
*did* exist, it *absolutely could not* operate simply by reading path
data from elements in the page, because *geometry itself* is
worthless.  It's the visual appearance that matters; such a search
engine would be OCRing the SVG as an image, and would thus need to
actually render the image, including things like colors and such which
are already covered by stylesheets.  Thus putting path data into the
style system would work just as well.

To the extent that any meaning can be extracted from the markup
itself, it's only in things like text, or the SVG connectors spec,
which communicates semantic relationships between nodes in a graph
(*and* them draws those nodes and connectors, for those of us looking
at the page rather than reading the source).

~TJ

Received on Monday, 22 June 2015 18:38:48 UTC