- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 19 Sep 2024 15:37:49 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-ui] Define design principles for `appearance: base` stylesheet``, and agreed to the following:
* `RESOLVED: add the principles and examples of use to css-forms-1`
* `RESOLVED: add fantasai and ntim as editors of css-forms-1`
<details><summary>The full IRC log of that discussion</summary>
<chrishtr> jensimmons: design principles are important, guided the HTML5 plan<br>
<chrishtr> jensimmons: the idea behind design principles is to say that we know we're going to get into lots of bikeshedding<br>
<chrishtr> jensimmons: when you're having those discussions in areas with lots of other things happening, then the group might have lots of agreement that was unstated<br>
<chrishtr> jensimmons: in other cases it can be harder. so one good first step is to take a step back and talk about high-level principles. Which will make it easier and more fun to do the details as a second step.<br>
<chrishtr> jensimmons: once you set high-level decisions (including priorities and order of principles), e.g. priority of constituencies on the web, that will help also<br>
<chrishtr> jensimmons: tim and I prepared this draft and thought about it a lot. We'd like to hear from the group what you think and were you're coming from<br>
<jarhar> https://github.com/w3c/csswg-drafts/issues/10866<br>
<chrishtr> astearns: this sounds like it could become an explainer?<br>
<chrishtr> astearns: a document we can refer to as we go through more detailed discussions<br>
<chrishtr> jensimmons: that could be good.<br>
<chrishtr> astearns: skimmed through the issue and it seems people like these principles<br>
<chrishtr> jensimmons: good UA default styles for form controls. what happens by default when appearance: base is set.<br>
<chrishtr> jensimmons: which need to be the same in all browsers<br>
<chrishtr> jensimmons: one principle is that appearance: base controls should look like the control and be usable<br>
<chrishtr> jensimmons: should also pass 100% of WCAG AAA standards<br>
<chrishtr> jensimmons: AA instead might be the minimum instead though, since very high contrast is difficult<br>
<chrishtr> jensimmons: styling should be consistent across controls<br>
<chrishtr> jensimmons: e.g. today appearance: auto mode is not just different across browsers, but even across controls on the same browser<br>
<chrishtr> jensimmons: example: borders should look the same thematically, and also use similar syntax e.g. hex numbers<br>
<astearns> q+ to talk about 4.ii and how it might be better in 5<br>
<chrishtr> jensimmons: should be easy to adjust to a site's preferred styles without a hard-reset style sheet<br>
<chrishtr> jensimmons: we discussed this one a lot internally to webkit, because it could be hard to achieve this<br>
<chrishtr> jensimmons: it should not be surprising to developers why things happen when they try to restyle<br>
<chrishtr> jensimmons: should be as simple and direct as possible<br>
<chrishtr> jensimmons: developers will be mixing their overrides with UA styles, and that should be straightforward<br>
<chrishtr> jensimmons: maybe "wireframes" is a good word to capture this<br>
<keithamus> q+<br>
<chrishtr> jensimmons: font styles for example. should a for set one? I think likely it should just inherit the document font<br>
<chrishtr> jensimmons: therefore inheriting existing styles as much as possible is best<br>
<chrishtr> jensimmons: simplicity is also a goal - avoid drop shadows or other extra effects when possible<br>
<chrishtr> fantasai: pseudo-elements are another thing. hacking up `::before` is not good because it makes it harder for developers to use that pseudo-element for their own purpose<br>
<chrishtr> jensimmons: I can see authors seeing an "align" rule, and then secretly find it in the `::before`. avoid confusing stuff like tehat<br>
<chrishtr> jensimmons: should fit into context well. for example, a form control set as a child of a grid should participate correctly in the grid<br>
<chrishtr> jensimmons: should be comprehensive. Form controls may look simple on the outside but are complex inside. e.g. focus, disabled state, writing modes, OS modes, should all work.<br>
<astearns> ack dbaron<br>
<Zakim> dbaron, you wanted to talk about tension between points 2 and 5<br>
<chrishtr> dbaron: I like this list of principles<br>
<chrishtr> dbaron: at the same time, I think some of the interesting dates are about cases where the principles disagree with each other. For example, if I want to really reduce them, principle 5 says "less styles". Whereas 2 and 6 kind of say "more styles". Balancing them could be tricky.<br>
<chrishtr> dbaron: writing down these principles is valuable, but working through examples will help us to figure out the right balance.e<br>
<chrishtr> astearns: I also like these principles. Thinking about it organizationally, what should happen where is no additional styling is one, and another is what happens when the author adds in styling. So 4.2 should be in 5?<br>
<chrishtr> astearns: may be 5.2 and 3 should be in 4?<br>
<astearns> ack keithamus<br>
<chrishtr> astearns: these are just editorial tweaks not really changes to the principles<br>
<chrishtr> keithamus: contrary to david's comments, I think it's ok that they may appear contradictory. But it helps to keep us on track.<br>
<chrishtr> keithamus: e.g. border-radius may not be needed because it's not necessary<br>
<dbaron> (I don't think it's bad that they're contradictory; I just think we need to recognize that they are.)<br>
<chrishtr> keithamus: for example, the UK government style guide may not look great by default but is quite usable and accessible<br>
<jensimmons> q+<br>
<chrishtr> keithamus: the OpenUI group has done a good job at looking at the intersection of all design systems. We should utilize that research to guide choices made here.<br>
<astearns> ack astearns<br>
<Zakim> astearns, you wanted to talk about 4.ii and how it might be better in 5<br>
<keithamus> q+<br>
<chrishtr> astearns: responding to one thing you said keith: agree that not everyone should agree the base styles are beautiful, but I'd like something about it to be good looking and not just purely utilitarian<br>
<astearns> ack jensimmons<br>
<chrishtr> keithamus: agree with some of that. we can't just take one design system. In fact I do think the UK gov design system is quite beautiful in its simplicity and utility.<br>
<keithamus> ack keithamus<br>
<keithamus> q+<br>
<chrishtr> jensimmons: maybe we should add "be beautiful when possible?" to the design styles?<br>
<chrishtr> jensimmons: agree that the design constraints contradict each other. e.g., border-radius does help some of the principles ("recognizable") but may interfere with others ("minimal").<br>
<chrishtr> jensimmons: drop shadow may have similar tradeoffs<br>
<astearns> ack keithamus<br>
<fantasai> s/tradeoffs/tradeoffs, but land on the other side -- no we need box-shadow to be usable/<br>
<chrishtr> keithamus: one thing I forgot to mention, we can also use these guidelines to look at the complexity of the UA style sheet. WCAG requires minimum sizing. sites often change it based on media queries. but our guidelines could move us away from depending on media queries.<br>
<chrishtr> keitihamus: think we should consider a guideline to avoid media queries in the interest of simplicity and predictability<br>
<chrishtr> jensimmons: agree we should avoid those, but maybe we don't need to mention it specifically in the principles<br>
<astearns> ack dbaron<br>
<chrishtr> dbaron: a related point is that I think being easy to override depends a lot on what we're doing. if it's a border radius or box shadow, developers can probably figure out how to remove them. where it's harder to override are less obvious cases, like media queries or states (if the control have states with default styles, developers might not notice all of them and forget some)<br>
<chrishtr> dbaron: some of the aspects of easy-to-override are about interactions and complexity more than base styles like border-radius or shadows<br>
<keithamus> q+<br>
<chrishtr> jensimmons: that's really important. maybe we need to add to this list or maybe it fits into principle 5<br>
<chrishtr> jensimmons: we need to make sure that the specificity is such that when they override they don't accidentally miss corner cases due to states<br>
<chrishtr> jensimmons: this starts to pair into work that tim is doing to define pseudo elements<br>
<chrishtr> jenseimmons: i f things are getting complicated maybe we need to define a new pseudo element to simplify<br>
<astearns> ack keithamus<br>
<chrishtr> keithamus: don't know if this is going to grow scope, but: if we introduce colors, we should name them<br>
<chrishtr> keithamus: introduce new color keywords for these? tokenizing/variables, so that design systems can change them across the board<br>
<chrishtr> astearns: from a CSSWG perspective then systematic overrides are a good use case that justifies keywords<br>
<chrishtr> ntim: there is going to be a TPAC breakout session on form control defaults, please join!@<br>
<fantasai> https://drafts.csswg.org/css-forms-1/<br>
<chrishtr> fantasai: there is, in the CSSWG repo, a document with ideas at css-forms-1. We could take over that document and put these principles there.<br>
<chrishtr> ntim: we have started a draft of a css forms spec internally to webkit, and hope to bring that to the group<br>
<chrishtr> fantasai: we can start with design principles and then add pseudo elements and so on later<br>
<chrishtr> astearns: I assume we'd also have examples there to highlight the tradeoffs? or the media query example<br>
<chrishtr> astearns: anti-patterns listed would be useful also<br>
<chrishtr> +1 to css-forms-1<br>
<chrishtr> RESOLVED: add the principles and examples of use to css-forms-1<br>
<chrishtr> RESOLVED: add fantasai and ntim as editors of css-forms-1<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10866#issuecomment-2361365895 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 19 September 2024 15:37:50 UTC