Meeting minutes
<melanierichards> https://
https://github.com/w3c/csswg-drafts/pull/6537
<melanierichards> Github: https://
simonpeters: We're working on finalizing the `appearance` property. The CSS Working Group discussed it 2 weeks ago and wanted to get feedback from Open UI.
simonpeters: In particular, how the Open UI styling fits in with the new appearance property. How do they fit together for styling the new widgets?
<zcorpan> PR for css: https://
<zcorpan> PR for html: https://
My mistake, please attribute above statements to zcorpan. My apologies for misspelling Pieters*
zcorpan: There's an `auto` keyword and a distinct set of widgets defined. One for select, radio, checkbox, and so on. These are all the ones needed by HTML widgets today and are implemented in browsers.
zcorpan: If we add a new widget for Open UI, should it just use the `auto` keyword? It would still need a defined kind of widget where the rendering is defined in, either in CSS UI or somewhere else.
zcorpan: That is, if `appearance` is supposed to do anything for the new element. It doesn't do anything for images, for example.
zcorpan: But if you want to be able to toggle native styling vs. author-provided styling, we need to define how `appearance` works for these widgets.
melanierichards: Does anyone need further clarification or time to ponder?
masonf: We don't need to define the specific rendering of a checkbox, we just need a reference to how it's rendering, right?
zcorpan: We can continue being hand wavy for new widgets, too. But it's not a good long term situation to be hand wavy about rendering. It'd be good to more precisely define rendering if possible to get consensus between browsers.
zcorpan: They don't expect it to be fully possible for all widgets, especially with different rendering for different form factors like mobile, watches, etc.
masonf: I'm in favor having a section in the spec describing how to render each widget. But, the UAs across platforms will need to be a little hand wavy. But, in formats we can predict, we can be much more precise.
tantek: From my understanding, the majority of new Open UI widgets don't have a corresponding native UI. If that's true, we should clarify that upfront to simplify this discussion.
tantek: If new widgets are fully stylable and are made to look consistent across devices, rather than fighting against native styling, then we shouldn't need anything besides `appearance: none` or `auto`.
zcorpan: If that's the case, we can say Open UI elements use `appearance: none`, and if developers specificy `auto`, it's the same as `none`, similar to how `<div>` doesn't change.
melanierichards: It depends. We'll have a set of components that are unique to Open UI. They'll be available for authors to use as dependency in design systems. We'll also be contirbuting things back to the web platform, like a more stylable select menu.
melanierichards: It starts in Open UI, we incubate it here, and then take it to HTML. We can say for things that stay in Open UI, `none` is appropriate. For things that we bring to HTML, we need to decide if it uses `auto`, how it should be rendered in the spec, or if we should add a new keyword.
zcorpan: Clarifying question: When you take these widgets to HTML, isn't it still expected that it should be fully stylable with CSS by default?
melanierichards: Yes. Fully stylable with CSS, and does it need to be in the platform, or just be used in a design system.
<tantek> zcorpan made my point with his question and conclusion
zcorpan: Then it could use `appearance: none` (even if it's a native element).
<tantek> +1
masonf: For new elements, such as selectmenu, I'd expect `appearance: none` to lose all styling and look just like a div, and `auto` to be default styling.
<melanierichards> +1 to Mason
masonf: Would `appearance: auto` look just like `none` and look like unstyled div?
zcorpan: It would have whatever is in UA stylesheet.
<tantek> +1 zcorpan
masonf: There's no magic styling, so nothing gets turned off.
<melanierichards> davidluhr: my question is, when new elements are brought to browsers, I'm guessing there's considerations to make the native UA styles look consistent with other unstyled elements. Is that something we would specify, or these els would get handed off to browsers to implement and they would handle style? What does that process look like?
masonf: The process is, that part doesn't get specified, we can put in whatever we'd like it to look like, developers can customize.
masonf: The only thing we might specify is no `!important` rules in UA stylesheet.
melanierichards: My understanding of `appearance: none;` with checkbox, for example, is it would cut through native styles to look like an unstyled `<div>`. How would `appearance: none` applied to new element strip it back to UA styles?
zcorpan: Each element has various UA styles. Button, for example, has background-color, 2px border, some padding, etc. However, `apperance: auto` doesn't look like that. It looks like a MacOS button, a non-CSS button. It's only when specify `apperance: none` or use custom properties, it switches to CSS styling. It doesn't remove UA styles, they cascade. It just renders with CSS styling applied instead of as a native widget.
melanierichards: Do we want to say `appearance: none` is sufficient, and we don't need additional keywords? What's the proposed resolution?
<tantek> +1 zcorpan. that's my understanding as well
zcorpan: For elements without a concept of native appearance, we should use `appearance: none`.
<tantek> +1
<masonf> +1
<melanierichards> PROPOSED RESOLUTION: For elements without a concept of native appearance, we should use `appearance: none`.
RESOLUTION: For elements without a concept of native appearance, we should use `appearance: none`.
masonf: Do we need resolution on individual definitions of checkbox, radio, etc.?
zcorpan: That's already in the PR for CSS UI.
melanierichards: Anything else for today?