Re: Promoting more SVG attributes into properties

On Fri, Jan 25, 2013 at 8:25 AM, David Leunen <leunen.d@gmail.com> wrote:
> I always naively thought CSS was intended to be the presentational part of
> the data.
> i.e optional for a semantic understanding of the data.
>
> If the only rationale for promoting attributes into css properties are
> animations, then isn't it wrong ?
>
> Transitions are ok (purely presentational), but an animation can be part of
> the content : the movement of a character over a landscape, a clock, a game,
> ...
> For these use cases, the data without the animations is meaningless.
> I'd say, if cx and cy are animated, they should be in SMIL, not in CSS.
>
> Is my definition of CSS outdated ?

CSS was traditionally designed for the "style" part of a document, as
separated from "content".  The fact that it's external, and the way
that a11y APIs work, still generally means that it's bad to put
anything really meaningful in CSS, but that's not a hard rule.

However, the definition of what is "content" and what is "style" is
very fuzzy.  HTML decided that text and semantics were content, and
everything else was style.  When SVG adopted CSS, they drew a
different line, decided that "geometry" was content and the rest was
style.  This leads to a weird disconnect when an author used to one
tries to use the other - they're used to being able to use CSS to do a
lot of painting-level things, like add decorations and border and what
have you, which in SVG stray into the "geometry" category.  Since many
more authors are HTML/CSS users, it makes sense to move closer to
their intuition.

It also helps to examine *why* the division exists at all - it means
that a robot can reasonably get the meaning of the document without
having to do much-more-difficult visual analysis. Under this
rationale, SVG's division doesn't make as much sense - the only thing
that needs to be "content" under the division I gave is text itself.

On a more practical note, CSS is also just a useful declarative
language that hooks into the DOM really well.  Moving things into CSS
for convenience and author-usability, even if they don't strictly meet
the division I outlined above, can be a good idea.

~TJ

Received on Friday, 25 January 2013 19:11:02 UTC