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!

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.

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.

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.

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.

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).

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.

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.

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.

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