Re: [csswg-drafts] [css-ui] appearance: base to enable interoperable styling of controls/components (#5998)

> Don't we want to have a defined DOM and styles for `appearance: none`?

When initially discussing this with @fantasai and @frivoal in the fall 2020 they didn't want overload `appearance: none` for compat reasons; although that was the initial direction I was heading which is why I actually extend `appearance: none` with the `base` solution. The defined DOM structure I think is actually the least of the concerns for compat in this scenario though because properties that wouldn't have worked prior may begin working due to the standardization of base styles. I'm not entirely sure of a concrete scenario however given how `appearance: none` is most commonly used however. @fantasai @frivoal do you all have one?

> Does using SVG allow more CSS animation than html? Why not use clip path and a background instead?

It provides greater flexibility on the parts (eg: paths) with strokes, joint, etc. Also, the minute you have to reach for background assets you've removed one of the key demos for this base solution which isn't to have to reach for any graphics software. It's also important to note that while SVG is currently being proposed for the checkmark that probably won't be the case for all control/component parts much in the same way that when authors create their own today they don't use SVG for the entire control.

> I am also not against using glyphs, even if different platforms have different fonts. They don’t all have to look identical for this proposal of standardized component parts to be valuable. As long as the author can apply a different font, or use content: "" and a clipping path and background for that part, then it is just as customizable.

I am due to the limitations of styling to text as outlined in the explainer in comparison to SVG.

> I’m not a fan of that being a single design for all eternity

I agree to an extent, this is commonly brought up but if one looks at many of the controls in the platform the models and base UX has remained the same since the webs inception. Upon looking into `<select>`, `checkbox`, `radio`, there are some that have existed prior in the same manner prior to browsers in native OSes and some (eg: checkbox/radio) prior to graphical UI. Some even exist well before mass access to computers existed, here's an [example from 1963](https://texashistory.unt.edu/iiif/ark:/67531/metapth190290/m1/1/full/full/0/default.jpg) with checkboxes, text inputs, date, date-time, etc. The important part to note is that this "design" will be a base but with the standardized DOM & styles they can adjust the look and feel utilizing the powerful layout capabilities we have today provided to us on the web. It will be purposefully plain and simple to give authors a starting point with the expectation that they will/can adjust it interoperably. So while I agree with your position I feel that cow paths are very well trodden in Graphical UI to be able to take a host of controls/components and define their parts and base styles.

> appearance: base-checkbox on something other than a checkbox would not be good.

This is a good point and one we'll need to ensure is accurately informed to authors as well in spec text as it will only apply to an `HTMLInputElement` with a state of `checkbox`; or other elements as we make progress with others. As `appearance: none` works today it removes the native styling but doesn't enforce a DOM nor base styles for that DOM. Does that clarify it?


-- 
GitHub Notification of comment by gregwhitworth
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5998#issuecomment-794305408 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 9 March 2021 18:55:34 UTC