-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Details and summary styles don't match implementations. #8610
Comments
This comment was marked as resolved.
This comment was marked as resolved.
That's how browsers behave, and what I'm proposing, unless I'm missing something? |
nope, not missing anything. rather i was missing the fact that the styles i was seeing were due to revised default styling from normalize.css which i didn't realize was referenced form the file i was testing. so... i'll just excuse myself from this and go file a bug over there. sorry about that. |
This preserves the revert keyword behavior. This doesn't match the spec to the letter, see whatwg/html#8610, but I think it's probably ok to keep behavior for now. Changing to match the spec would avoid duplicating the details.css summary rule. Differential Revision: https://phabricator.services.mozilla.com/D164439 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1804925 gecko-commit: 5c61586b4d42a68cb9d49e2afa5db3c4efc3004b gecko-reviewers: TYLin
…TYLin This preserves the revert keyword behavior. This doesn't match the spec to the letter, see whatwg/html#8610, but I think it's probably ok to keep behavior for now. Changing to match the spec would avoid duplicating the details.css summary rule. Differential Revision: https://phabricator.services.mozilla.com/D164439
This preserves the revert keyword behavior. This doesn't match the spec to the letter, see whatwg/html#8610, but I think it's probably ok to keep behavior for now. Changing to match the spec would avoid duplicating the details.css summary rule. Differential Revision: https://phabricator.services.mozilla.com/D164439 bugzilla-url: https://bugzilla.mozilla.org/show_bug.cgi?id=1804925 gecko-commit: 5c61586b4d42a68cb9d49e2afa5db3c4efc3004b gecko-reviewers: TYLin
…TYLin This preserves the revert keyword behavior. This doesn't match the spec to the letter, see whatwg/html#8610, but I think it's probably ok to keep behavior for now. Changing to match the spec would avoid duplicating the details.css summary rule. Differential Revision: https://phabricator.services.mozilla.com/D164439
On the triage call, everyone was leaning toward changing the spec to match browser behavior, but we took an action item to read up a bit more to confirm. Upon doing so, I think changing the spec to match browser behavior is indeed the best path here. That makes the styling consistent with the behavior. (Everything in https://html.spec.whatwg.org/#the-details-and-summary-elements except the stylesheet mentions "first summary element child", and https://html.spec.whatwg.org/#summary-for-its-parent-details also requires it to be the first element child.) So, a PR and test updates would be lovely from my perspective. |
Somewhat related, I think we should have a pseudo-element selector for the default |
There's not any mention of the fallback summary which is rather unfortunate? Fixes whatwg#8610
https://html.spec.whatwg.org/#the-details-and-summary-elements has:
However a quick test like this:
shows that the rules browsers actually use are different. The selectors are something like
details > summary:first-of-type
anddetails[open] > summary:first-of-type
, with extra similar styles for the anonymous summary.I think we could change browsers to follow the spec if needed, but it might be better to make the spec match reality?
The text was updated successfully, but these errors were encountered: