[css-ui] Define design principles for `appearance: base` stylesheet

[nt1m]

For the appearance: base stylesheet, it would be good to formulate a set of design principles that everyone can agree upon. It would be good to think about those holistically across all form controls, and not just in the context of a single control.

Here's an initial cut at it, open for feedback:

Good default UA styles for form controls should:

1. be completely identical in every browser
2. be recognizable and usable on their own, without additional styling
3. pass 100% of WCAG 2.2 AA standards
4. be consistent across controls
   1. in look & feel
   2. how they are defined in code
   3. in sizing and interaction
5. be easily morphed into the site’s branding, without needing complex reset stylesheets
   1. use minimal code and be easy to override
   2. not have a strong voice & tone of their own, be visually as simple as possible
   3. inherit page styles rather than define new styles whenever possible
   4. be straightforward and non-hacky, easy to understand
   5. be resilient to adjustments
      1. when changed itself (e.g. changing font, border, layout)
      2. when put in context (e.g. ready to be flex or grid children)
6. be comprehensive
   1. covering all states for each control
   2. supporting all writing modes and color schemes

[josepharhar]

Thanks for creating this! Mind if I add it to the agenda of the next joint meeting?

2. how they are defined in code
3. in sizing and interaction

What do these mean?

I agree with all other points, they sound great!

[nt1m]

Mind if I add it to the agenda of the next joint meeting?

Seems fine. Not sure a 1h zoom meeting will be enough, but we can try.

be consistent across controls in how they are defined in code

The whole thing must be coherent, a violation of this would be using width to define sizing in one place, and using padding in another for instance.

be consistent across controls in sizing and interaction

Mostly ensuring the sizes are consistent to a reasonable extent, the current state of things is a violation of this principle:

<textarea></textarea>
<br>
<input>

As for interaction, scrolling would be an example, but also pressing/etc.

[jensimmons]

Good default UA styles for form controls should be consistent across controls, including how they are defined in code

This means the way CSS is used to style the controls should be consistent across form controls. We shouldn't style one with one approach / technique, and then use a different approach for another. The code should be consistent. (If color is defined one way for one control — perhaps with relative color syntax — then color should be defined that way for all controls, etc.) In addition, we should reuse as much code as possible.

Good default UA styles for form controls should be consistent across controls, including in sizing and interaction

All form controls should use the same approach to sizing and layout. And the same approach for interactions (focus, etc). Right now, the form controls are not consistent. Different controls were defined in different eras, and it makes it that much harder to style them.

Just look at how different the sizes of the default text boxes are:

We should fix that. Every control should use a similar kind of layout. If we decide to make them flexible (with width: 100% for example), then they should all be flexible (where appropriate) — and not make half the text boxes fixed-width and half flexible for seemingly no particular reason. Or if we make one of the text boxes a fixed width of 25ch, then everything that's similar should be a fixed width of 25ch, not one 25ch, another 10em, another 300px, etc.

These things might seem obvious, but part of the reason to create design principles is to make sure everyone is on the same page, operating from the same set of assumptions. It's easier to sort such things out at the beginning, then to find out later some of the parties involved have completely different thinking. For instance, perhaps there is someone who thinks it's more important to be consistent with the past — and keep the inconsistency in layout — than making a bigger change, and changing all the controls to use the same approach to layout.

Let's discuss the principles, and come to consensus. Then, when we are bike shedding details of code later, we can refer back to the principles we've set. They will help us make decisions.

[jensimmons]

Something to remember — we are not just designing the look and feel of the new default UA styles for appearance: base, we are designing the developer experience of overriding some of those styles while allowing others to cascade into their page's design.

We are not designing the forms for a website. We are not even designing a design system. We are creating the foundation for all future websites to use when styling their forms. And the DX of the result of this work is likely the most important thing to consider.

[mfreed7]

For the appearance: base stylesheet, it would be good to formulate a set of design principles that everyone can agree upon. It would be good to think about those holistically across all form controls, and not just in the context of a single control.

Thanks for putting this together! This is a great list, and I think we broadly agree with most of the points listed.

I do think it'll be good to discuss this live at TPAC, so we can maybe get it "completed" as a first draft.

We are not designing the forms for a website. We are not even designing a design system. We are creating the foundation for all future websites to use when styling their forms. And the DX of the result of this work is likely the most important thing to consider.

This is also an excellent point. We should be considering what work is required to use one of these controls within a design system - it should hopefully be close to trivial. Similarly it should be close to trivial to just "tweak" the base styles by a bit, changing borders or colors, for example.

On the other hand, I do think an important point to add to the list is that the controls should also work well for users when no developer CSS is used. I.e. just a plain <select> without a stylesheet should still be completely usable and accessible. This point might mandate (or influence) things like borders and drop shadows, if those are needed for usability and accessibility.

[nt1m]

On the other hand, I do think an important point to add to the list is that the controls should also work well for users when no developer CSS is used. I.e. just a plain <select> without a stylesheet should still be completely usable and accessible. This point might mandate (or influence) things like borders and drop shadows, if those are needed for usability and accessibility.

That's the second point on the list :) Form controls should be recognizable and usable on their own.

Regarding removing the drop shadow for the select picker, this is linked to the 5th point, in general, we shouldn't try to add styles that not absolutely necessary (dialog & popover only have borders, no box-shadows).

[mfreed7]

That's the second point on the list :) Form controls should be recognizable and usable on their own.

Ahh you're right. Perhaps we could add "on their own, without developer CSS" or something?

Regarding removing the drop shadow for the select picker, this is linked to the 5th point, in general, we shouldn't try to add styles that not absolutely necessary (dialog & popover only have borders, no box-shadows).

Yeah, I suppose I agree with this. I'm not a UX expert though, and I've heard some experts say drop shadows are functional and "required" for UX. But perhaps not at the level of the standardized stylesheet. I'm ok with no drop shadow.

[jensimmons]

To drop shadow or not to drop shadow? That will be a question to bikeshed later. Hopefully by setting some principles first, those discussions later will be easier, rooted in share understanding & agreement.

Because, yes, there are two ideas here that might align or might pull in separate directions. We want to 1) make the controls work without any author styles, and 2) make it easy for authors to override styles.

If we agree both are important priorities, then when we discuss a detail like a drop shadow, we have a discussion framework (of design principles) to help us best thread the needle between the two ideas and land on the best solution. Hopefully something that accomplishes both. While meanwhile quickly discarding possibilities that accomplish neither.

[jensimmons]

Add this??

7. Be beautiful when possible.

Do we need something more explicit to make sure the cascade is structured in such a way that overriding one aspect doesn't override states unexpectedly — making certain states useable by accident.

[css-meeting-bot]

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

The full IRC log of that discussion

<chrishtr> jensimmons: design principles are important, guided the HTML5 plan
<chrishtr> jensimmons: the idea behind design principles is to say that we know we're going to get into lots of bikeshedding
<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
<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.
<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
<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
<jarhar> https://github.com/w3c/csswg-drafts/issues/10866
<chrishtr> astearns: this sounds like it could become an explainer?
<chrishtr> astearns: a document we can refer to as we go through more detailed discussions
<chrishtr> jensimmons: that could be good.
<chrishtr> astearns: skimmed through the issue and it seems people like these principles
<chrishtr> jensimmons: good UA default styles for form controls. what happens by default when appearance: base is set.
<chrishtr> jensimmons: which need to be the same in all browsers
<chrishtr> jensimmons: one principle is that appearance: base controls should look like the control and be usable
<chrishtr> jensimmons: should also pass 100% of WCAG AAA standards
<chrishtr> jensimmons: AA instead might be the minimum instead though, since very high contrast is difficult
<chrishtr> jensimmons: styling should be consistent across controls
<chrishtr> jensimmons: e.g. today appearance: auto mode is not just different across browsers, but even across controls on the same browser
<chrishtr> jensimmons: example: borders should look the same thematically, and also use similar syntax e.g. hex numbers
<astearns> q+ to talk about 4.ii and how it might be better in 5
<chrishtr> jensimmons: should be easy to adjust to a site's preferred styles without a hard-reset style sheet
<chrishtr> jensimmons: we discussed this one a lot internally to webkit, because it could be hard to achieve this
<chrishtr> jensimmons: it should not be surprising to developers why things happen when they try to restyle
<chrishtr> jensimmons: should be as simple and direct as possible
<chrishtr> jensimmons: developers will be mixing their overrides with UA styles, and that should be straightforward
<chrishtr> jensimmons: maybe "wireframes" is a good word to capture this
<keithamus> q+
<chrishtr> jensimmons: font styles for example. should a for set one? I think likely it should just inherit the document font
<chrishtr> jensimmons: therefore inheriting existing styles as much as possible is best
<chrishtr> jensimmons: simplicity is also a goal - avoid drop shadows or other extra effects when possible
<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
<chrishtr> jensimmons: I can see authors seeing an "align" rule, and then secretly find it in the `::before`. avoid confusing stuff like tehat
<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
<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.
<astearns> ack dbaron
<Zakim> dbaron, you wanted to talk about tension between points 2 and 5
<chrishtr> dbaron: I like this list of principles
<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.
<chrishtr> dbaron: writing down these principles is valuable, but working through examples will help us to figure out the right balance.e
<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?
<chrishtr> astearns: may be 5.2 and 3 should be in 4?
<astearns> ack keithamus
<chrishtr> astearns: these are just editorial tweaks not really changes to the principles
<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.
<chrishtr> keithamus: e.g. border-radius may not be needed because it's not necessary
<dbaron> (I don't think it's bad that they're contradictory; I just think we need to recognize that they are.)
<chrishtr> keithamus: for example, the UK government style guide may not look great by default but is quite usable and accessible
<jensimmons> q+
<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.
<astearns> ack astearns
<Zakim> astearns, you wanted to talk about 4.ii and how it might be better in 5
<keithamus> q+
<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
<astearns> ack jensimmons
<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.
<keithamus> ack keithamus
<keithamus> q+
<chrishtr> jensimmons: maybe we should add "be beautiful when possible?" to the design styles?
<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").
<chrishtr> jensimmons: drop shadow may have similar tradeoffs
<astearns> ack keithamus
<fantasai> s/tradeoffs/tradeoffs, but land on the other side -- no we need box-shadow to be usable/
<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.
<chrishtr> keitihamus: think we should consider a guideline to avoid media queries in the interest of simplicity and predictability
<chrishtr> jensimmons: agree we should avoid those, but maybe we don't need to mention it specifically in the principles
<astearns> ack dbaron
<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)
<chrishtr> dbaron: some of the aspects of easy-to-override are about interactions and complexity more than base styles like border-radius or shadows
<keithamus> q+
<chrishtr> jensimmons: that's really important. maybe we need to add to this list or maybe it fits into principle 5
<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
<chrishtr> jensimmons: this starts to pair into work that tim is doing to define pseudo elements
<chrishtr> jenseimmons: i f things are getting complicated maybe we need to define a new pseudo element to simplify
<astearns> ack keithamus
<chrishtr> keithamus: don't know if this is going to grow scope, but: if we introduce colors, we should name them
<chrishtr> keithamus: introduce new color keywords for these? tokenizing/variables, so that design systems can change them across the board
<chrishtr> astearns: from a CSSWG perspective then systematic overrides are a good use case that justifies keywords
<chrishtr> ntim: there is going to be a TPAC breakout session on form control defaults, please join!@
<fantasai> https://drafts.csswg.org/css-forms-1/
<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.
<chrishtr> ntim: we have started a draft of a css forms spec internally to webkit, and hope to bring that to the group
<chrishtr> fantasai: we can start with design principles and then add pseudo elements and so on later
<chrishtr> astearns: I assume we'd also have examples there to highlight the tradeoffs? or the media query example
<chrishtr> astearns: anti-patterns listed would be useful also
<chrishtr> +1 to css-forms-1
<chrishtr> RESOLVED: add the principles and examples of use to css-forms-1
<chrishtr> RESOLVED: add fantasai and ntim as editors of css-forms-1