– DRAFT –
Cascading Style Sheets (CSS) Working Group Teleconference

<chrishtr> github-bot: take up w3c/csswg-drafts#10866

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

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10866.

<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> w3c/csswg-drafts#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

<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

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

<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?

<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

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

<Zakim> astearns, you wanted to talk about 4.ii and how it might be better in 5

<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

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

<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, 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

<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

<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

<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

RESOLUTION: add the principles and examples of use to css-forms-1

RESOLUTION: add fantasai and ntim as editors of css-forms-1

<chrishtr> github-bot, take up w3c/csswg-drafts#10717

[css-ui] Pseudo-element for select's UA button

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10717.

<chrishtr> jarhar: I finished implementing the removal of the buttons and replacing with div w/text in Chromium. Then fonts are inherited well. So I think it works well.

<chrishtr> jarhar: propose not to create a pseudo-element for the select button

<fantasai> +1

<ntim> +1

RESOLUTION: do not add a pseudo-element for the user-agent fallback select button

<chrishtr> github-bot, take up w3c/csswg-drafts#10857

[css-ui] UA stylesheet for appearance:base `<select>`

<github-bot> OK, I'll post this discussion to https://github.com/w3c/csswg-drafts/issues/10857.

<chrishtr> jarhar: there has been good discussion in the issue, and I've created two sub-issues for some topics

<chrishtr> jarhar: don't know if there is anything specific to resolve in the issue right now?

<chrishtr> fantasai: we could resolve to inherit the font?

<dbaron> yeah, +1 to inheriting the font

<chrishtr> ntim: think it could be good to delay this discussion to after or during TPAC

<chrishtr> fantasai: agree in general

<chrishtr> fantasai: also for all form controls and not just select

<chrishtr> jensimmons: would be best to discuss then/later

<chrishtr> jarhar: I'd like to discuss things like which pseudo elements we should add, how to specify colors, ...

<chrishtr> fantasai: let's reschedule so that the breakout agenda is rescheduled into the OpenUI joint meeting?

<chrishtr> astearns: we could have tentative discussions at the breakout and then finalize them at the group later

<sanketj_> whatwg/meta#326

chrishtr: while we do want consistent styles, `<select>` is being worked on this year and we need to ensure we don't unreasonably delay decisions based on that.

chrishtr: we can use it as a place to set precedent for the others

astearns: So here is the precedent, but if we make a mistake we can change them as we integrate into the larger set?

chrishtr: sure we can make changes later.

<ntim> (can't talk right now) I'm hoping that TPAC gives enough time to resolve most things regarding UA stylesheets! My goal is more to help drive select's direction not block its progress :)

<jarhar> +1 to using unset for font properties

<ntim> (or not setting the font at all)

RESOLUTION: font properties won't be set in the UA style sheet

<chrishtr> github-bot, take up whatwg/html#10317

<github-bot> chrishtr, I can't comment on that github issue because it's not in a repository I'm allowed to comment on, which are: w3c/csswg-drafts w3c/fxtf-drafts w3c/css-houdini-drafts w3c/svgwg web-platform-tests/wpt WICG/animation-worklet WICG/construct-stylesheets WICG/scroll-animations WICG/custom-state-pseudo-class.

Content Model

<chrishtr> jarhar: this issue was created because accessibility experts are concerned about authors ending up with inaccessibile structures

<fantasai> github: whatwg/html#10317

<chrishtr> jarhar: we should discuss which are allowed so as to preserve accessibility. I worked with accessibility experts from OpenUI and came up with a list of elements which should be allowed within select: divs, spans, img, text within options but outside

<chrishtr> jarhar: and legend elements as child of optgroup to replace label

<chrishtr> jarhar: this has the same a11y mapping but is more styleable

<chrishtr> jarhar: my HTML spec PR is ready to go so from my perspective it's ready. should we go with this approach?

<chrishtr> emilio: curious if we're going to have special rendering for legend like we have for fieldset, or are there any other special rendering rules?

<astearns> pr: whatwg/html#10586

<chrishtr> emilio: if you put a legend into a fieldset the the rendering is quite special. the first thing gets moved up to the top regardless of where it is in the DOM, and other layout tree reparenting.

<chrishtr> emilio: hoping we don't have to do any of that

<chrishtr> jarhar: my preference is also not to do anything special. didn't come across any need to have special rendering in prototyping in Chromium. I just set up the a11y mappings and changed the rendering of the optgroup element so it would stop rendering the label attribute part when there is a legend child

<chrishtr> fantasai: on the PR: it says div and span, but not various other elements like em or bdo. why not?

<chrishtr> jensimmons: there are so many other elements that seem reasonable?

<chrishtr> fantasai: ruby also

<chrishtr> jarhar: these are good points and should be included within option elements. these rules are about content outside option elements.

<chrishtr> jarhar: maybe we can use a more broad rule for inside-option parts

<chrishtr> fantasai: span or other inline elements don't belong outside option

<chrishtr> fantasai: div allowed but not span because span is inline

<chrishtr> astearns: are there tests?

<chrishtr> jarhar: the tests for the content model: not sure how to do that. in the Chromium implementation, we render everything but use developer tooling to guide people towards accessible outcomes. tl;dr I don't know how to test it in WPT.