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

Update :active and :hover definitions #7465

Merged
merged 3 commits into from Feb 10, 2022
Merged

Update :active and :hover definitions #7465

merged 3 commits into from Feb 10, 2022

Conversation

domenic
Copy link
Member

@domenic domenic commented Jan 5, 2022

This removes the disabled condition for :active, matching Gecko and WebKit. The condition was added to the spec in 9985973 but not implemented uniformly. As discussed in #6635, it doesn't work very well and is inconsistent with other similar pseudo-classes, like :hover.

This also removes the consideration of <link> elements with href="" attributes for :active, since they no longer have activation behavior as of 1e0ee7f.

Finally, this updates the definitions of both :active and :hover to be based on the latest Selectors spec, which notably includes the ancestor condition over the flat tree at the CSS layer, instead of having HTML handle that. This required splitting up "being activated" and "matches :active", as well as "designated" and "matches :hover".

Closes #6635, although note that there remain other interop issues with :active, tracked in #7578.

(See WHATWG Working Mode: Changes for more details.)


We could consider resolving the <input type=radio> case alongside this one in a single PR, but for now I'm tackling this alone.


/semantics-other.html ( diff )

This matches Gecko and WebKit. The disabled condition was added to the spec in 9985973 but not implemented uniformly. As discussed in #6635, it doesn't work very well and is inconsistent with other similar pseudo-classes, like :hover.

This also removes the consideration of <link> elements with href="" attributes, since they no longer have activation behavior as of 1e0ee7f. And it updates the definitions of both :active and :hover to be based on the latest Selectors spec, which notably includes the ancestor condition over the flat tree at the CSS layer, instead of having HTML handle that.

There remains some lack of interop around elements such as <input type=radio> which have activation behavior but are not on the list of elements for which "in a formal activation state" is considered. #6635 stays open to track that case.
@domenic domenic added normative change topic: rendering topic: forms interop Implementations are not interoperable with each other labels Jan 5, 2022
@annevk annevk requested a review from emilio January 6, 2022 10:10
Copy link
Contributor

@emilio emilio left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good.

@domenic domenic requested a review from annevk January 6, 2022 18:16
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think the change for :hover works. This would mean that any ancestor of a labeled control of a label element that matchines :hover would also match :hover.

I'm also surprised these use the flat tree, though I suppose that makes some sense given the way events work.

@domenic
Copy link
Member Author

domenic commented Jan 7, 2022

Yeah, indeed that is not the case. https://jsbin.com/dibasoqali/edit?html,output

I guess we need to separately define "matching :hover" (works on labels) and "while the user designates".

@domenic domenic changed the title Update :active definition to not consider disabledness Update :active and :hover definitions Jan 7, 2022
@domenic domenic requested a review from annevk January 7, 2022 17:54
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes to :hover look good. It seems however that we need corresponding changes for :active. Sorry for not spotting that at the same time.

source Outdated Show resolved Hide resolved
Copy link
Member

@annevk annevk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks!

@domenic domenic added the needs tests Moving the issue forward requires someone to write tests label Jan 13, 2022
@domenic
Copy link
Member Author

domenic commented Jan 13, 2022

Alright, I filed https://bugs.chromium.org/p/chromium/issues/detail?id=1287171 and hopefully that will cause some WPTs to get written, so we can merge this.

@josepharhar
Copy link
Contributor

WPTs here: web-platform-tests/wpt#32804

@domenic
Copy link
Member Author

domenic commented Feb 10, 2022

Yay, thanks so much! I'll merge this now.

@domenic domenic removed the needs tests Moving the issue forward requires someone to write tests label Feb 10, 2022
@domenic domenic merged commit df8aaaf into main Feb 10, 2022
@domenic domenic deleted the update-active-pseudo branch February 10, 2022 19:06
mfreed7 pushed a commit to mfreed7/html that referenced this pull request Jun 3, 2022
This removes the disabled condition for :active, matching Gecko and WebKit. The condition was added to the spec in 9985973 but not implemented uniformly. As discussed in whatwg#6635, it doesn't work very well and is inconsistent with other similar pseudo-classes, like :hover.

This also removes the consideration of <link> elements with href="" attributes for :active, since they no longer have activation behavior as of 1e0ee7f.

Finally, this updates the definitions of both :active and :hover to be based on the latest Selectors spec, which notably includes the ancestor condition over the flat tree at the CSS layer, instead of having HTML handle that. This required splitting up "being activated" and "matches :active", as well as "designated" and "matches :hover".

Closes whatwg#6635, although note that there remain other interop issues with :active, tracked in whatwg#7578.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
interop Implementations are not interoperable with each other normative change topic: forms topic: rendering
Development

Successfully merging this pull request may close these issues.

:active pseudo-class specification doesn't account for children/labels of disabled form elements
4 participants