You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you considered that instead of an appearance:base property in css (or another css property if we want to avoid adding to the complicated history of appearance), opting into the "base" structure and style might better be achieved with an HTML attribute? I have not thought about this excessively deeply, so I might be completely off the mark, but I find the idea interesting.
<inputtype=checkboxbase>
(This almost certainly needs bikeshedding. I'm keeping the name base for now just because it's the name this feature has had so far, not because I think the attribute ought to be called that)
Maybe you have thought about this already, and if so, it would be good to list in the explainer why that's a bad idea.
Here are some thoughts as to why it might be a good one:
it's not worse that appearance:base when it comes to the behavior in browsers that do not yet support it. In both cases, the attribute / property gets ignored, and you get the traditional behavior
Maybe it helps with the styling / selection circularity discussed in How does the styling work #4. Without a need for impossible selectors or magic origins, and you can write:
input[base][type=checkbox] {
…
}
and there's no circularity. That said, this is weak with regards to graceful degratation in UAs that do not support it, so maybe there should be a pseudo class instead:
input[type=checkbox]:base {
…
}
That's not possible if we're using appearance:base as the opt in, but it is if we're using a markup attribute as the opt-in.
Given how css properties are applied, when we introduce appearance:base, it needs to work at once on all the elements where it will eventually need to work, otherwise people might apply it via overly broad selectors, and then create compat traps when we later try to enable in on elements where it previously had no effect. The css-wg has suggested maybe having a series of appearance:base-checkbox, appearance:base-radio etc to work around that, but it feels clunky. Introducing the base attribute on elements one by one doesn't seem to suffer from that problem, as it gets applied in a more targeted way, and as you'd have the :base pseudo (which wouldn't match on elements where this isn't supported yet) to progressively enhance your stylesheets as support improves
The text was updated successfully, but these errors were encountered:
@frivoal I've referenced this issue in CSSUI issue regarding the base solution. Let's take the convo over there, so I'll close this issue out but made sure to link to your proposal. Feel free to duplicate it if you'd prefer for it to be inline in the issue.
Have you considered that instead of an
appearance:base
property in css (or another css property if we want to avoid adding to the complicated history ofappearance
), opting into the "base" structure and style might better be achieved with an HTML attribute? I have not thought about this excessively deeply, so I might be completely off the mark, but I find the idea interesting.(This almost certainly needs bikeshedding. I'm keeping the name base for now just because it's the name this feature has had so far, not because I think the attribute ought to be called that)
Maybe you have thought about this already, and if so, it would be good to list in the explainer why that's a bad idea.
Here are some thoughts as to why it might be a good one:
it's not worse that
appearance:base
when it comes to the behavior in browsers that do not yet support it. In both cases, the attribute / property gets ignored, and you get the traditional behaviorMaybe it helps with the styling / selection circularity discussed in How does the styling work #4. Without a need for impossible selectors or magic origins, and you can write:
and there's no circularity. That said, this is weak with regards to graceful degratation in UAs that do not support it, so maybe there should be a pseudo class instead:
That's not possible if we're using
appearance:base
as the opt in, but it is if we're using a markup attribute as the opt-in.Given how css properties are applied, when we introduce
appearance:base
, it needs to work at once on all the elements where it will eventually need to work, otherwise people might apply it via overly broad selectors, and then create compat traps when we later try to enable in on elements where it previously had no effect. The css-wg has suggested maybe having a series ofappearance:base-checkbox
,appearance:base-radio
etc to work around that, but it feels clunky. Introducing thebase
attribute on elements one by one doesn't seem to suffer from that problem, as it gets applied in a more targeted way, and as you'd have the:base
pseudo (which wouldn't match on elements where this isn't supported yet) to progressively enhance your stylesheets as support improvesThe text was updated successfully, but these errors were encountered: