Re: Animating SVG with CSS

Tab Atkins Jr. wrote:
> On Thu, Sep 18, 2014 at 1:47 PM, Juergen Roethig
> <roethig@dhbw-karlsruhe.de> wrote:
>> Tab Atkins Jr. wrote:
>>> On Thu, Sep 18, 2014 at 1:01 PM, Juergen Roethig
>>> <roethig@dhbw-karlsruhe.de> wrote:
>>>> 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 ;-)
> 
> I'm really not sure how to take this.  Do you think people actually
> write `* { width: XXX; }` in their pages?  At least, enough to make us
> care about compat?
> 
> You're not raising a theoretical issue, but a practical one.  Whether
> or not this causes a problem in practice is the question, and the
> types of rules you've given as examples aren't going to show up in
> practice.  Is there something you're thinking of that might actually
> show up on real pages?

Ok, I will try to make up a slight variation which might be "useful" for 
(and which therefore might be used by) web authors ;-) Assume we do not 
use the wildcard selector, but a class selector, generic enough not to 
mention the element name, but specific enough to have the high jury's 
decision of being not ridiculous, let's say:

.doo { width: 1000px; } /* also note the multiplication of the relevant 
size by 100 in order not to be too small, i.e. "ridiculous", in the high 
jury's opinion - you might also replace it with your XXX */

Whether this is a really good rule is questionable (due to media 
independency, ...), but in some context, it might appear as the author's 
intent to have several more or less specific HTML "boxes" (p, div, 
whatever) have a specific size. And that size might be complemented by 
other declarations about colours or whatever, that's why this rule might 
also have had a wanted effect on SVG elements belonging to the same 
class (in which case, the "width" declaration was ignored, properly). 
And now, the width becomes a presentation attribute, and all the SVG 
rects become 1000px-sized, ignoring their given specific 
width-attribute. Got it?

>>>>> 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 ...
> 
> In CSS, "ignore" is indeed defined to mean this, but, for example, in
> SVG you can create elements with unknown names, or put unknown
> attributes on elements, and they'll stick around in the DOM and be
> inspectable.  They don't get thrown away at parse time, like CSS does
> for unknown properties.

And that's why those standards (HTML4, SVG1.1, SVG1.2 Tiny, HTML5 don't 
state that such elements must be ignored - they even explicitly state 
that they might have an effect in the DOM, tried to or not being 
rendered (dependent on the specific spec), and that they should result 
in error messages in the user console. Is an error message "encouraging" 
or "discouraging"? All that is not the case for the CSS standard - 
unknown properties must simply be ignored! That's what I already wrote, 
and that's what I repeat once again!

> I'm not sure what you mean by "throw an exception", since CSS doesn't
> have a concept of exceptions.  If you're suggesting it might make
> sense to have CSS simply stop working when it encounters an unknown
> property, I'll remind you that all *new* properties are "unknown" in
> old browsers; forwards compatibility (defining things such that UAs
> handle future additions safely) is also important.

It was "throw an error/exception/whatever" - no specifics intended. 
Replace it by "error message in the user console" if you feel better 
then. And I was not sure what you meant by "CSS is discouraging ...", 
since CSS is just a specification. It's always the UAs behaviour which 
might encourage or discourage an author to do something! And that 
"forward compatibility" issue leads again to my former statement that 
with this version-less web-language handling, many more problems will 
arise (or exist already) than what will be "solved" ...

Juergen Roethig

Received on Friday, 19 September 2014 06:12:17 UTC