[css-ui-4] Define appearance:base #10691
Conversation
This was discussed here: w3c#5998
css-ui-4/Overview.bs
Outdated
| <a>native appearance</a> suppressed where CSS can be used to restyle them, | ||
| just like <a>primitive appearance</a>, but also have default styles which are | ||
| usable and interoperable. This is unlike <a>base appearance</a> which can | ||
| cause some <a>widgets</a> to disappear completely. |
There was a problem hiding this comment.
Don't we have to define the style system magic here or elsewhere that makes this possible?
There was a problem hiding this comment.
I wouldn't necessarily define the specifics of it (seems like an implementation thing), but maybe just at least the end result?
There was a problem hiding this comment.
I think it has to define that a widget can have some style sheet associated with it (that is defined wherever that widget is defined) and how resolving that style sheet with the existing user agent style sheets and any author and user style sheets is supposed to work.
There was a problem hiding this comment.
Yeah, I think I agree that we need to define a bit more here, since (unless I'm misunderstanding the current plan) I think this is going to cause some styles to get applied that change the computed values of other properties, both on this element and likely also on observable pseudo-elements inside of it.
(On the flip side, I think the current plan is that appearance: base doesn't change whether any pseudo-elements exist (if such a thing is even detectable) since it doesn't change the UA shadow DOM at all. (But I think it does change whether some parts of the UA shadow DOM are display:none or not.) At least, I think that's the current plan, and it certainly does make things cleaner architecturally even if it requires some local ugliness in places.)
There was a problem hiding this comment.
Oh, yes, the internal shadow tree plan would be good to clarify as well.
There was a problem hiding this comment.
So should I add a paragraph that looks like this?
A widget can have some style sheet associated with it and those styles can change based on whether the widget has a native appearance, primitive appearance, or base appearance.
There was a problem hiding this comment.
It's possible that we only want the style sheet variation to occur between base appearance and the other values. I think the difference between native appearance and primitive appearance has historically not shown up in the computed values of the properties (e.g., border) that are affected. (Though I'm not 100% sure of this.)
There was a problem hiding this comment.
How about this?
A widget can have some style sheet associated with it and those styles can change based on whether the widget has a base appearance. Native appearance and primitive appearance should have the same styles.
There was a problem hiding this comment.
Ok, I added the text I suggested in my last comment
css-ui-4/Overview.bs
Outdated
| <a>native appearance</a> suppressed where CSS can be used to restyle them, | ||
| just like <a>primitive appearance</a>, but also have default styles which are | ||
| usable and interoperable. This is unlike <a>base appearance</a> which can | ||
| cause some <a>widgets</a> to disappear completely. |
There was a problem hiding this comment.
Yeah, I think I agree that we need to define a bit more here, since (unless I'm misunderstanding the current plan) I think this is going to cause some styles to get applied that change the computed values of other properties, both on this element and likely also on observable pseudo-elements inside of it.
(On the flip side, I think the current plan is that appearance: base doesn't change whether any pseudo-elements exist (if such a thing is even detectable) since it doesn't change the UA shadow DOM at all. (But I think it does change whether some parts of the UA shadow DOM are display:none or not.) At least, I think that's the current plan, and it certainly does make things cleaner architecturally even if it requires some local ugliness in places.)
|
I think this PR needs some very prominent ISSUE: text warning not to ship this feature until its stylesheet has been properly and thoroughly defined (and implemented per spec) for all form controls. We don't want an implementer reading it, making stuff up that matches the current high-level description, and shipping their own interpretation of what |
Done |
This was discussed here: #5998