Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SVG should specify what CSS attribute selectors and class selectors match on #328

Open
birtles opened this issue Jun 27, 2017 · 6 comments

Comments

Projects
None yet
5 participants
@birtles
Copy link
Contributor

commented Jun 27, 2017

Background: Mozilla bug 1365472

Given that attributes can be animated in SVG, SVG needs to specify if attribute selectors match on the animated value of the attribute or not. Similarly for class selectors.

Proposal:

  • Attribute selectors match on the base value of the attribute, i.e. the same value as getAttribute returns since SMIL Animation says, "When an animation is running, it should not actually change the attribute values in the DOM." (Note that Chrome appears to have a bug here.)
  • Class selectors match on the set of classes applied to the element which can be affected by SMIL animation (as otherwise being able to animate the class attribute would be meaningless, and being able to animate this is quite useful).

That means that if we have:

<circle>
  <set attributeName="class" to="a"/>
</circle>

Thencircle.a would match but circle[class="a"] would not.

cc @bzbarsky

@tabatkins

This comment has been minimized.

Copy link
Member

commented Jun 27, 2017

That sounds... quite bad? We've never broken the symmetry between class and attr selectors before.

@AmeliaBR

This comment has been minimized.

Copy link
Contributor

commented Jun 27, 2017

Class and attribute selectors aren't perfectly symmetrical, given that class selectors are processed (tokenized). Even if you use the token form of the attribute selector, I'm sure there could be weird edge cases where you get inconsistent results.

In general, attribute selectors always match the literal attribute values, even if those are not valid values for the corresponding DOM properties, so you can get disconnects that way. For example, lang selectors or other pseudoclasses could be out of sync with querying the actual attributes they are based on.

But that said:

I would be quite happy to move towards an interpretation of SVG animation as more a declarative way of changing attributes, so the actual attribute value would change while the animation was in effect (just like it does if you're animating with JS). In other words, if you <set> an attribute on an element, treat it as if it has that attribute for selector-matching.

But I think that goes against the argument for dropping animVal from SVG 2 (and I think some browsers already): there are DOM costs for keeping everything in sync.

@tabatkins

This comment has been minimized.

Copy link
Member

commented Jun 27, 2017

Even if you use the token form of the attribute selector, I'm sure there could be weird edge cases where you get inconsistent results.

No, using [class ~= "a"] should work precisely the same as .a.

@bzbarsky

This comment has been minimized.

Copy link

commented Jun 27, 2017

We've never broken the symmetry between class and attr selectors before

They have different case-sensitivity behavior in quirks mode, for what it's worth.

But also, the behavior @birtles proposes is what Safari and Firefox ship already. Edge doesn't support SMIL, and Chrome has broken [class="foo"] matching; see https://bugs.chromium.org/p/chromium/issues/detail?id=735820 (used to match Safari and Firefox before that bug was introduced). So all browsers that support SMIL already match on the animated value for class selectors.

Conceptually, in spec terms as things stand, the "set of classes an element belongs to" is not necessarily a function of any of its attributes at all; it needs to be defined by relevant specifications that define that element.

@tabatkins

This comment has been minimized.

Copy link
Member

commented Jun 29, 2017

Yeah, that's true. Makes me a little sad, but my sadness is worth nothing in comparison to everyone agreeing.

@boggydigital boggydigital added this to the SVG 2.1 Working Draft milestone Jun 11, 2018

@boggydigital

This comment has been minimized.

Copy link
Contributor

commented Jun 11, 2018

Not blocking updated 2.0 CR publication - assigning 2.1 WD milestone

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.