- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 21 Sep 2024 12:42:41 -0400
- To: www-style@w3.org
- Cc: public-open-ui@w3.org, pastithas@google.com
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS UI
------
- RESOLVED: Add the principles and examples of use to css-forms-1
(Issue #10866: Define design principles for `appearance:
base` stylesheet)
- RESOLVED: Add fantasai and ntim as editors of css-forms-1 (Issue
#10866)
- RESOLVED: Do not add a pseudo-element for the user-agent fallback
select button (Issue #10717: Pseudo-element for select's
UA button)
- RESOLVED: Font properties won't be set in the UA style sheet (Issue
#10857: UA stylesheet for appearance:base `<select>`)
Content Model
-------------
- There was interest in expanding the PR for WHATWG issue #10317
(Content model and 'what' to render for stylable <select>
elements) to capture many more types of elements.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/10609
Present:
Adam Argyle
David Baron
Keith Cirkel
Emilio Cobos Álvarez
Elika Etemad
Chris Harrelson
Sanket Joshi
Tim Nguyen
Olli Pettay
Jen Simmons
Alan Stearns
Scribe: chrishtr
Scribe's scribe: keithamus
CSS UI
======
Define design principles for `appearance: base` stylesheet
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10866
jensimmons: Design principles are important, guided the HTML5 plan
jensimmons: The idea behind design principles is to say that we know
we're going to get into lots of bikeshedding
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
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.
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
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
astearns: This sounds like it could become an explainer?
astearns: A document we can refer to as we go through more detailed
discussions
jensimmons: That could be good.
astearns: Skimmed through the issue and it seems people like these
principles
jensimmons: Good UA default styles for form controls. What happens by
default when appearance: base is set
jensimmons: which need to be the same in all browsers
jensimmons: One principle is that appearance: base controls should
look like the control and be usable
jensimmons: Should also pass 100% of WCAG AAA standards
jensimmons: AA instead might be the minimum instead though, since
very high contrast is difficult
jensimmons: Styling should be consistent across controls
jensimmons: e.g. today appearance: auto mode is not just different
across browsers, but even across controls on the same
browser
jensimmons: Example: borders should look the same thematically, and
also use similar syntax e.g. hex numbers
jensimmons: should be easy to adjust to a site's preferred styles
without a hard-reset style sheet
jensimmons: We discussed this one a lot internally to webkit, because
it could be hard to achieve this
jensimmons: It should not be surprising to developers why things
happen when they try to restyle
jensimmons: Should be as simple and direct as possible
jensimmons: Developers will be mixing their overrides with UA styles,
and that should be straightforward
jensimmons: Maybe "wireframes" is a good word to capture this
jensimmons: Font styles for example. Should a for set one? I think
likely it should just inherit the document font
jensimmons: Therefore inheriting existing styles as much as possible
is best
jensimmons: Simplicity is also a goal - avoid drop shadows or other
extra effects when possible
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
jensimmons: I can see authors seeing an "align" rule, and then
secretly find it in the `::before`. avoid confusing stuff
like that
jensimmons: Should fit into context well. For example, a form control
set as a child of a grid should participate correctly in
the grid
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.
dbaron: I like this list of principles
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.
dbaron: Writing down these principles is valuable, but working
through examples will help us to figure out the right balance.
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?
astearns: May be 5.2 and 3 should be in 4?
astearns: These are just editorial tweaks not really changes to the
principles
keithamus: Contrary to David's comments, I think it's ok that they
may appear contradictory. But it helps to keep us on track.
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.)
keithamus: For example, the UK government style guide may not look
great by default but is quite usable and accessible
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: 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
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.
jensimmons: Maybe we should add "be beautiful when possible?" to the
design styles?
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").
jensimmons: Drop shadow may have similar tradeoffs, but land on the
other side -- no we need box-shadow to be usable
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.
keitihamus: Think we should consider a guideline to avoid media
queries in the interest of simplicity and predictability
jensimmons: Agree we should avoid those, but maybe we don't need to
mention it specifically in the principles
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)
dbaron: Some of the aspects of easy-to-override are about
interactions and complexity more than base styles like
border-radius or shadows
jensimmons: That's really important. Maybe we need to add to this
list or maybe it fits into principle 5
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
jensimmons: This starts to pair into work that Tim is doing to define
pseudo elements
jenseimmons: If things are getting complicated maybe we need to
define a new pseudo element to simplify
keithamus: Don't know if this is going to grow scope, but: if we
introduce colors, we should name them
keithamus: Introduce new color keywords for these? Tokenizing/
variables, so that design systems can change them across
the board
astearns: From a CSSWG perspective then systematic overrides are a
good use case that justifies keywords
ntim: There is going to be a TPAC breakout session on form control
defaults, please join!
<fantasai> https://drafts.csswg.org/css-forms-1/
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.
ntim: We have started a draft of a css forms spec internally to
webkit, and hope to bring that to the group
fantasai: We can start with design principles and then add pseudo
elements and so on later
astearns: I assume we'd also have examples there to highlight the
tradeoffs? or the media query example
astearns: anti-patterns listed would be useful also
<chrishtr> +1 to css-forms-1
RESOLVED: add the principles and examples of use to css-forms-1
RESOLVED: add fantasai and ntim as editors of css-forms-1
Pseudo-element for select's UA button
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10717
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.
jarhar: Propose not to create a pseudo-element for the select button
<fantasai> +1
<ntim> +1
RESOLVED: do not add a pseudo-element for the user-agent fallback
select button
UA stylesheet for appearance:base `<select>`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10857
jarhar: There has been good discussion in the issue, and I've created
two sub-issues for some topics
jarhar: Don't know if there is anything specific to resolve in the
issue right now?
fantasai: We could resolve to inherit the font?
<dbaron> yeah, +1 to inheriting the font
ntim: Think it could be good to delay this discussion to after or
during TPAC
fantasai: Agree in general
fantasai: Also for all form controls and not just select
jensimmons: Would be best to discuss then/later
jarhar: I'd like to discuss things like which pseudo elements we
should add, how to specify colors, ...
fantasai: Let's reschedule so that the breakout agenda is rescheduled
into the OpenUI joint meeting?
astearns: We could have tentative discussions at the breakout and
then finalize them at the group later
<sanketj> https://github.com/whatwg/meta/issues/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> 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 :)
<ntim> (or not setting the font at all)
<jarhar> +1 to using unset for font properties
RESOLVED: Font properties won't be set in the UA style sheet
Content Model
=============
Content model and 'what' to render for stylable <select> elements
-----------------------------------------------------------------
github: https://github.com/whatwg/html/issues/10317
jarhar: This issue was created because accessibility experts are
concerned about authors ending up with inaccessible structures
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
jarhar: and legend elements as child of optgroup to replace label
jarhar: this has the same a11y mapping but is more styleable
jarhar: My HTML spec PR is ready to go so from my perspective it's
ready. Should we go with this approach?
<astearns> pr: https://github.com/whatwg/html/pull/10586
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?
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.
emilio: Hoping we don't have to do any of that
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
fantasai: On the PR: it says div and span, but not various other
elements like em or bdo. Why not?
jensimmons: There are so many other elements that seem reasonable?
fantasai: Ruby also
jarhar: These are good points and should be included within option
elements. These rules are about content outside option
elements.
jarhar: Maybe we can use a more broad rule for inside-option parts
fantasai: Span or other inline elements don't belong outside option
fantasai: Div allowed but not span because span is inline
astearns: Are there tests?
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.
Received on Saturday, 21 September 2024 16:43:13 UTC