Re: question about "presentation attributes"

Hello Tab,

Thursday, March 20, 2014, 2:45:25 AM, you wrote:

> On Wed, Mar 19, 2014 at 6:23 PM, David Dailey <ddailey@zoominternet.net> wrote:
>> b)      When it says that “the plan is to allow all SVG elements to be
>> stylable” does this mean that all elements should be selectable by CSS?

> All elements are already selectable by CSS - they exist in the DOM,
> and Selectors can grab any of them.


Yes.

> You might be asking about whether
> all elements *generate boxes* ("box" being a technical term in CSS for
> "something that appears in the layout tree, and will probably be
> rendered", roughly), and the answer is no.
(I suspect David was not asking that).

> I'm not actually sure what the issue is trying to say - all elements
> are styleable already, in that they can all receive CSS properties,
> and you can observe this via inheritance.

Tab is correct that stylesheets (external CSS stylesheets, the content
of style elements, and the content of style attributes) can already
set all properties on all elements.

What the issue is referring to is presentation attributes. In the
early development of SVG there was considerable tension between the
XML-centric (and particularly, DTD/schema-centric) view that each
element should have a carefully chosen set of appropriate attributes,
and the CSS-centric view that all properties have a value on all
elements (but some properties only affect certain elements, effect in
the sense of doing something).

Normally those two views don't conflict. In the case of presentation
attributes, they did conflict. The result is that SVG 1.0 had some
carefully worked out set of presentation attributes chosen so that
their value might plausibly affect that element or any of its allowed
descendent elements.

However, that was pretty much wasted work because its possible toset
those properties using a style sheet, so it merely ends up penalising
people who set them in attributes and then find, occasionally, that
their SVG doesn't validate. (Implementations in practice accept all
presentation attributes on all elements, since in most cases it is
shared code with CSS).

Thus the plan is to move away from that carefully chosen but pointless
grouping of presentation attributes by element, to the simpler and
more regular position that all elements can take all presentation
attributes.


>> d)      Does that mean that all attributes (and their values) should be
>> animatable through CSS?

> No attributes are animateable through CSS.  All the properties that
> the presentation attributes map to are, though.

Right.

Some of that is a good thing. Some of that is an unfortunate
workaround of a deficiency in CSS animation (it animates only
properties) compared to SMIL/SVG animation (it animates both
attributes and properties, which requires some careful spec wording
when some properties are expressed as attributes).

This caused a rush to make as many SVG attributes into properties as
possible. Some of those were a good fit for CSS, some not.

Web Animations is a nicely worked out harmonization of CSS Animations
and SMIL/SVG animations, using a consistent underlying model for both.
This should reduce the pressure to make things which are clearly not
suitable as properties, into properties just so they can be animated.
http://dev.w3.org/fxtf/web-animations/
http://www.w3.org/TR/web-animations/


-- 
Best regards,
 Chris                            mailto:chris@w3.org

Received on Friday, 21 March 2014 18:11:59 UTC