Re: Animating SVG with CSS

Tab Atkins Jr. wrote:
> On Thu, Sep 18, 2014 at 1:01 PM, Juergen Roethig
> <roethig@dhbw-karlsruhe.de> wrote:
>> Tab Atkins Jr. wrote:
>>> On Thu, Sep 18, 2014 at 12:31 PM, Juergen Roethig
>>> <roethig@dhbw-karlsruhe.de> wrote:
>>>> And that is the great "feature" what might easily break existing content:
>>>> If
>>>> an attribute (let's take "x" as an example, and let's even add a second
>>>> one,
>>>> "y") happens to become a presentation attribute (in order to make it work
>>>> with CSS animations or whatever), which it is was definitely not in SVG
>>>> 1.1,
>>>> a simple CSS rule of
>>>> * { x: 47; y: 11; }
>>>> which did not do any harm, so far (since unknown CSS properties _must_
>>>> _be_
>>>> _ignored_ by browsers, according to _any_ _CSS_ _spec_ in my knowledge),
>>>> makes all my SVG objects using individual x and y attributes appear at
>>>> the
>>>> very same place (47,11). One might address this issue by changing the
>>>> precedence of CSS rules over presentation attributes vice versa, but such
>>>> a
>>>> change might break other existing content :-(
>>>>
>>>> That's why I am sure that with this version-less web-language handling,
>>>> many
>>>> more problems will arise (or exist already) than what will be "solved".
>>>
>>> This issue is present with literally every property we ever introduce
>>> to CSS; it's theoretically possible that someone might have created an
>>> invalid property with that name, which suddenly becomes valid and
>>> starts doing unexpected things.  We generally consider this a
>>> non-issue.
>>
>> Then let's take the CSS rule
>> * { width: 10px; }
>> which was and is valid in the context of HTML and which now even makes all
>> my nice SVG rectangles have the same size under the assumption that "width"
>> becomes a presentation attribute. But probably, some clever guy has already
>> built a usage counter in Chrome for SVG's <rect> object which gave the
>> result that <rect> is used by less than 10% of all SVG documents and
>> therefore negligible ...
> 
> Luckily, that's an extremely ridiculous sort of rule to write in a
> page, and thus not something to worry about.

Poooh, we are so lucky to have the high jury's decision that this rule 
is so extremely ridiculous ;-)

>>> This is part of the reason why CSS does *not* expose unknown
>>> properties to the author; this discourages unknown properties from
>>> being used/abused in this manner.
>>
>> If you could explain to a dumb non-native English speaker what you mean by
>> "CSS does *not* expose unknown properties to the author", please ???
> 
> Hey now, no need to disparage yourself.
> 
> I meant that CSS throws away unknown properties, with no way for the
> page to know that they were there; there's no interface or API to tell
> you that an unknown property was ever specified.

Is this something special, and isn't this already implied by the term 
"ignore"? And on the other hand, "this also does *not* discourage 
unknown properties from being used/abused", since it does *not* throw an 
error/exception/whatever for using unknown properties ...

Juergen Roethig

Received on Thursday, 18 September 2014 20:48:48 UTC