Define optgroup base appearance rendering#12201
Define optgroup base appearance rendering#12201josepharhar wants to merge 5 commits intowhatwg:mainfrom
Conversation
The old text didn't explain that there is a shadow tree with an element which renders the label attribute, and that it goes away when the author provides a legend element. The UA styles for rendering the optgroup element with base appearance are still valid. Fixes whatwg#12199
annevk
left a comment
annevk
left a comment
There was a problem hiding this comment.
I think we should also change <optgroup>.label so it actually reflects the legend element when there is one. Seems quite strange the API would not reflect all of this. But that's probably a separate change at this point with its own tests.
source
Outdated
| <span>expected</span> to contain a copy of the text in the <code>optgroup</code>'s <code | ||
| data-x="attr-optgroup-label">label</code> attribute. If the <code>optgroup</code> has a child | ||
| <code>legend</code> element, then the <span>optgroup label element</span> is not | ||
| rendered.</p></li> |
There was a problem hiding this comment.
Why not use a slot with fallback for this? Does the legend element intentionally have different requirements than the button element. It can appear anywhere?
There was a problem hiding this comment.
I also found out today that this optgroup label element is expected to have padding?
There was a problem hiding this comment.
And in Chrome min-height is set to 0 but that should probably be auto? cc @nt1m
There was a problem hiding this comment.
Why not use a slot with fallback for this? Does the
legendelement intentionally have different requirements than thebuttonelement. It can appear anywhere?
It is supposed to be first, so yeah we could do slotting instead: https://html.spec.whatwg.org/multipage/form-elements.html#the-optgroup-element
I'll go ahead and make that change here, in chromium, and WPT.
I also found out today that this optgroup label element is expected to have padding?
Yes, I made it have the same style as the legend element when rendered with base appearance. If we made it a web exposed part-like pseudo-element, which would be awesome, then we could define that in the same style rule as the legend element. Since it isn't, at least not yet, I'll add a paragraph there which says what the expected styles are.
And in Chrome
min-heightis set to 0 but that should probably be auto? cc @nt1m
Ah, my bad I thought that 0 was the default value. I'll change it to something better like unset.
There was a problem hiding this comment.
Maybe we can first agree on the details? Since we’d have to change styles as well presumably. I’m not a 100% sold on either approach yet.
There was a problem hiding this comment.
Sure, how would you like to go about agreeing on the details?
source
Outdated
| <code>option</code> <span data-x="option-base-appearance">is being rendered with base | ||
| appearance</span> and the <code>option</code>'s <code data-x="attr-option-label">label</code> | ||
| attribute is not set, then the <code>option</code> is <span>expected</span> to render all of its | ||
| children rather than by displaying its <span data-x="concept-option-label">label</span>.</p> |
There was a problem hiding this comment.
Ok, I replaced this with an internal shadow tree definition
annevk
added
normative change
topic: rendering
topic: select
2 participants
The old text didn't explain that there is a shadow tree with an element which renders the label attribute, and that it goes away when the author provides a legend element. The UA styles for rendering the optgroup element with base appearance are still valid.
Fixes #12199
(See WHATWG Working Mode: Changes for more details.)
/rendering.html ( diff )