- From: Dael Jackson <daelcss@gmail.com>
- Date: Mon, 9 Dec 2024 18:37:33 -0500
- To: www-style@w3.org, 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.
=========================================
OpenUI-WHATWG/HTML-CSSWG Meeting
================================
CSS UI
------
- RESOLVED: Have the same border radius for base appearance for
selects and buttons, conditional on giving others not
present a week to review. (Issue #10857: UA stylesheet
for appearance:base `<select>`)
- RESOLVED: Use transparent background color for base appearance
selects, buttons, and inputs (Issue #10857)
Add support for CSS reading-flow (HTML PR #10613)
-------------------------------------------------
- More discussion is needed on the handling of tabindex before a
resolution can be reached.
- The CSS spec does not yet have a FPWD due to some substantial
questions against the draft, but the interaction with HTML was
clarified.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/10813
Present:
Rachel Andrew
Joey Arhar
Keith Cirkel
Dan Clark
Emilio Cobos Álvarez
Elika Etemad
Mason Freed
Alan Stearns
Anne van Kesteren
Luke Warlow
Scribe: keithamus
Scribe's scribe: jarhar
OpenUI-WHATWG/HTML-CSSWG Meeting
++++++++++++++++++++++++++++++++
CSS UI
======
UA stylesheet for appearance:base `<select>`
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10857
jarhar: We discussed colors last time. Some discussion in the thread;
fantasai made a nice list. I made a recent comment to use the
same background color for both and distinguish with border
radius only
jarhar: I'd like to get a resolution if possible
<fantasai> https://github.com/w3c/csswg-drafts/issues/10857#issuecomment-2515767151
annevk: Tim and Jen aren't here - can we do a tentative resolution to
hear feedback from them?
astearns: We'll often take a full resolution with the caveat in it,
waiting to act until people are able to take a look
annevk: That's workable
astearns: So one at a time, jarhar suggested we _only_ use border
radius, not background or color to distinguish. Can you go
into reasoning?
jarhar: Alternative to using same background to both is inputs having
transparent, and buttons having color mix.
jarhar: In some offline discussions I recall Tim making it fully
transparent, also Tab likes fully transparent more. It sounds
fine.
jarhar: People seem to have a preference for fully transparent.
astearns: So background and background color out because of the
transparency possibility? Border radius was the original
option presented, is there anything beside radius?
jarhar: Good question
astearns: Not opposed, just want to make sure we're deciding right
<fantasai> Could use box-shadow
jarhar: With the objective in mind of trying to use background-color
for select - why I'm interested in this resolution - I'm not
saying we can't make further distinctions but I'd like to
settle on border-radius/background color
lwarlow: My preference would be buttons/inputs/selects all have the
same base style. I'm not sure adding border-radius
facilitates anything?
lwarlow: Background color doesn't change anything... border radius is
going to be changed. I don't think it makes sense to have a
default.
lwarlow: Open question of should we distinguish them; probably no
from me. A uniform look for interactive elements.
lwarlow: Inputs have popups with their own inputs, an input isn't
that different to a select.
keithamus: I'm not disagreeing with Luke but I think border radius is
fine. Other thing is text align right? I imagine that text
align center is on buttons and selects and text align left
is on inputs. Is that something that we're going to do?
masonf: text align start in select, button is unset.
<fantasai> +1 to text-align
<lwarlow> Personally I see text-align start more for selects and
inputs but not for button
astearns: We can certainly consider it as part of the stylesheet but
not a distinguishing mark
<fantasai> +1 to astearns's point
astearns: I think in most cases inputs are start aligned, but text
aligned is inherited from other content - so a UI centered
aligned will have centered aligned inputs
annevk: If you have an input element with an initial value and you
have a button can you distinguish by just looking at them?
annevk: If they just have a border?
masonf: To clarify, we seem to have agreed we're not using the 10%
background and going fully transparent?
astearns: That's my understanding
masonf: The thing I wanted to say, being able to distinguish inputs
vs buttons vs selects - the one that seems special is the
button. Clicking on others isn't destructive, a button _does_
something, you click on it and oops it was a submit button
masonf: Making input/select is fine, and we should focus more on
button for this discussion
jarhar: My goal was to align selects with buttons as opposed to inputs
jarhar: In the interests of distinguishing between the two, border
radius is a good way to do that, since it's on the table
right now. As for text-align I haven't explored in a ton of
detail. Some content to think about.
jarhar: Right now just interested in the border color, background
color, border radius
jarhar: So are people okay with border radius?
astearns: I suspect people are fine with not changing background color
lwarlow: 0.25 and 0 are effectively the same - I can't tell the
difference with my eyesight. If we want to distinguish them
we should also use a color
fantasai: That's a quarter of a font-size. Should be significant
lwarlow: My eyesight might be bad
annevk: 4 CSS pixels? Not a whole lot.
<fantasai> We could do 0.5em
<fantasai> https://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22border%3A%20solid%201px%3B%20padding%3A%200.25em%3B%20border-radius%3A%200.5em%22%3Etest%3C%2Fdiv%3E
keithamus: font-weight: bold might be useful in addition too
masonf: Buttons with more border radius to make it look different -
half an em for the button to show its really rounded could
show it's different.
annevk: I would assume we'd use the same style for button and select
annevk: I'm concerned about the distinction between text controls and
buttons
annevk: Can you click it vs edit it is a thing you might want to tell
by looking at it
masonf: But for the user nothing scary about - if you click it and
nothing bad happens
masonf: For select, you can abort without penalties
masonf: but button is scary
<fantasai> +1 masonf
annevk: But last time we came to the conclusion that select style
impact how we style button
annevk: If we only use border radius to distinguish, is that
sufficient or not?
annevk: The select concerns get grouped with button
annevk: Select could look like a text input... I thought jarhar was
also doing that
masonf: Cursor style tells you a bit about it too
keithamus: Select and buttons have visually distinct style because of
dropdown marker. But also to Mason's point of buttons
doing the dangerous thing, I think it is ambiguous. If we
are deciding based on that factor, buttons don't always do
the dangerous thing. A lot of buttons in websites are to
build select equivalent things. To Anne's point,
keithamus: there is validity in making combobox and select visually
distinct. One of those is editable and one is read only.
There should be a distinction. There's a caret but that's
not sufficient
keithamus: Both points are correct to a degree, but there's probably
additional distinguishing things to add.
keithamus: Text inputs we can have them as border with no border
radius with no background, normal font weight
keithamus: Select could be styled like a button. but we know that
selects aren't going to be dangerous because they have
visual treatment
keithamus: combobox needs to look like a mish mash of the two. have
the triangle but look like an input?
keithamus: Buttons need to have a style but authors can decide how
dangerous they're going to be and they can style them
keithamus: That's how I see it. I think we should have a very
distinguishable style for buttons and selects should look
like buttons. Editable form controls should have a
distinguishable style
lwarlow: keithamus touched on some of what I am thinking; buttons
aren't always dangerous. Customizable select is very
literally a button that opens a popover. I think that we're
using a button element in a select says they should be
treated relatively similar
lwarlow: Border radius alone is _probably_ enough, we just need to
figure out a value
lwarlow: Something masonf touched on around the cursor is a good
point too
fantasai: I think 0.5em would be a better size for border radius
fantasai: masonf's point was compelling on where to use it. That's
all I have
<masonf> So the variables we have available to distinguish input,
select, button are: border-radius, text-align, cursor, and
the presence of ::picker-icon.
astearns: Sounds like we're converging on select and buttons using
the same border-radius
<emilio> +1 on making buttons and select the same
masonf: should background-color be included in that?
<jarhar> proposed resolution: have the same border radius for base
appearance for selects and buttons, conditional on giving
others not present a week to review.
<keithamus> +1
<dandclark> +1
<masonf> +1
<fantasai> wfm
emilio: +1 on making select/button similar, but I am still uneasy
about adding border-radius only on appearance base. The more
computed value time dependencies we add the more we
complicate reasoning about css.
astearns: Can you describe computed value time issue you're seeing?
emilio: Appearance effecting border-radius
emilio: Either with magic CSS that UAs can only use or with magic
adjustments after we've.... it feels very odd
emilio: It makes dependency tracking between properties more annoying
emilio: I'd like to change as little as possible for appearance base
styles
annevk: Yeah I feel like we're revisiting old ground. Appearance base
opts into new ground where you can apply with an internal
at-rule or a value function to open the ability to make a
good default style sheet for these controls
annevk: If we need to litigate each property for the improved style
sheet that's gonna take up a lot of time
emilio: It's something we can do when we think its needed but
border-radius is presentational.
astearns: So while we're not re-litigating the entire idea of a style
sheet we should be conservative about it
masonf: We should think of it as a new control but not be chained to
the past.
<fantasai> +1 to masonf
annevk: The discomfort for me is not so much... the argument from
emilio seems to be implementation difficulty, not that
border-radius is bad for these controls. I have a problem
with that argument, not how conservative we are
annevk: I have a problem with saying no against a property because
it's hard to implement
<emilio> not implementation difficulty
<emilio> More like hardness of reasoning about it as an author
jarhar: Making properties change based on appearance has been
implemented in chrome for some time now, at first it was more
complicated due to the CSS parser changes needed, but Andrej
from the style team did a refactor that made all the magic
parsing go away and we have a new internal base appearance
thing for pretty much any property
jarhar: I did need to set the appearance base to be a high priority
property but it's worked so far and I'm using it a lot and
it's working great. I have no worries with changing any of
these properties we're discussing
masonf: I think authors won't think about the magic required, they'll
just look at the new styles
fantasai: From an author perspective you're switching between two
different style modes. There's no intra-property
dependencies, it's just a different base style sheet.
keithamus: We have two concrete user bases here. one is they're never
going to customize anything and they need sensible
defaults. Anyone who is going to customize these styles,
they're going to customize as much as they need to. If
they need to change the border radius they will
fantasai: It's also an obvious one to change
<astearns> proposed resolution: have the same border radius for base
appearance for selects and buttons, conditional on giving
others not present a week to review.
<keithamus> +1
<masonf> still +1
<jarhar> +1
RESOLVED: have the same border radius for base appearance for selects
and buttons, conditional on giving others not present a
week to review.
<jarhar> proposed resolution: use transparent background color for
base appearance selects, buttons, and inputs
<keithamus> +1
<masonf> +1
<fantasai> +1
<lwarlow> +1
RESOLVED: use transparent background color for base appearance
selects, buttons, and inputs
Add support for CSS reading-flow
================================
github: https://github.com/whatwg/html/pull/10613
Di: Since TPAC we've had good conversations on how to handle cases
for reading flow
Di: We defined what a scope owner is and so forth. Today is to
clarify what we leave to CSS and what we leave to html
Di: Most of the traversal logic is in HTML spec. We're fetching the
CSS display spec to determine container and reading flow sibling
for elements
fantasai: Why are there so many dependencies on the CSS spec? AFAICT
the only thing the HTML spec needs is CSS definition of
order?
fantasai: What are the behavior differences on something having the
reading-flow property?
Di: We don't depend that much on CSS. We are describing a list of
nodes already ordered by reading flow and establishing that on
the HTML side
masonf: The dependencies are as expected: What is a reading flow
container and what order
fantasai: What is a reading flow container?
Di: Flex or grid container and the order of grid rows and columns and
such. We need it so we can switch into a different mode
fantasai: We should have as a principle if the reading flow does not
change the ordering of the container it should be a no-op.
If I set reading-flow: flex-flow and the order of my layout
matches source ordering it shouldn't impact HTML algorithms
fantasai: You're saying if I set it and it matches the order will be
different?
annevk: There is an impact on tabindex if it's set
annevk: tabindex is scoped to the container
fantasai: If we're introducing a feature for scoping tabindex we
should do it where we don't have to flip on one of these
other things; it shouldn't be a side effect of grid layout
following visual order
annevk: This is the only case where we need it; for now they're
coupled. Maybe in the future they can be uncoupled
masonf: The reading-flow property adds new behaviors for tabindex,
it's a focus scope, it scopes tabindex, it turns on a set of
behaviors by using it
fantasai: That behavior should be available without having to change
the order; you shouldn't have to change your ordering to
get that
astearns: That's separate from the issue of how to spec?
fantasai: Then you have two contexts; one is the creation of tabindex
scoping the other is CSS providing a different order for
children than you had original
annevk: We don't want one without the other
annevk: Once you have the container - the container is telling us CSS
is doing something to the children
annevk: It's not clear we want to impact tabindex independently from
that
masonf: The tabindex part of this is to avoid breaking the feature.
tabindex messes up the focus order in specific ways.
Confusing situations bouncing between containers
masonf: I don't think this is a tabindex feature - it's fixing broken
behavior when you're using this feature
fantasai: I feel uncomfortable with turning it on and it not being a
no-op when it's the default order. It shouldn't impose
additional behavior, ideally.
<masonf> You can already scope tabindex with shadow dom or iframes
or...
fantasai: Secondly if there is scoping of tabindex I think that might
be what people want for other purposes but they shouldn't
need to change how their items are ordered in order to get
that
fantasai: If that seems like something people want to do
annevk: Generally tabindex is a misfeature, I'm not sure how much we
want to build upon it. We just need to handle it
masonf: iframes, shadowdom, slots, all create tabindex focus scopes
fantasai: They require changing your HTML. It's not just "add this
extra attribute or container", the document needs
restructuring
masonf: That's true but then we fall back to annevk's argument of
this is a misfeature
fantasai: I don't think we should introduce a new mode for tabindex
solely as a side effect of something that does something
different
astearns: It sounds to me like this is a necessary side effect for
the reading order property, so we have to include it
astearns: but I'm not sure if it's worth making a separable feature
if the use cases aren't justified
masonf: tabindex is a misfeature and a footgun. The reasons we had to
make this a special feature is because otherwise it becomes
worse than the existing footgun. This is to protect users
from really bad things, not a "oh look here's a cool new
feature".
<rachelandrew> +1 to masonf, if we make it a feature it's like we're
suggesting people use it.
fantasai: The tabindex is whatever numbers they are inside that
element, you never jump in and out of the element? It
doesn't interleave?
masonf: Correct, it keeps you jumping between reading flow items
masonf: The UA has put them nicely for you in the correct order, but
tabindex might mess up the ordering in very confusing ways,
including perhaps loops
lwarlow: I don't fully know the ins-and-outs but my understanding is
that it's not doing something completely different to
changing tabindex? It changes the way tab works - tabindex
is defining the ordering within the source; reading-flow is
saying to ignore the source and do something else. So it
doesn't seem completely unrelated.
lwarlow: It seems logical that my source code is now being ignored
for a visual order. That's just my perception
fantasai: I understand if reading flow says you're going to ignore
the tabindex because CSS is overriding it. I also
understand if we say that reading-order is a new source
order, and tabindex operates on top. But scoping tabindex
in this new way when CSS defines a new reading order
feels off
masonf: How would you avoid the footguns then?
fantasai: Can you give me a concrete example?
masonf: A local loop; tabindex jumps you to another item and you jump
back to the one before.
fantasai: That's an abstract example
annevk: The other thing was - in order to land this in the HTML spec
the CSS side needs to be ready. Is it in a WD, is it in
review? Is it going to be renamed? What's the stability
fantasai: We don't have a FWPD of the display module. Issues raised
against it are not insignificant. I don't know if that'll
result in changes to syntax or two different values or
something like that.
fantasai: I wouldn't qualify it as solid/ready to ship
fantasai: How much will it change? I don't know
astearns: We should prioritize FPWD
fantasai: Interaction with HTML though - we can basically say there's
going to be one or more properties in CSS that can change
the desired reading order of a set of children of a box.
annevk: Presumably of a node? Like an element?
fantasai: An element
fantasai: And CSS will define an algorithm going from source order to
reading order
annevk: HTML has that with the container thing... anyway I think I
agree. A good next step for this feature to focus on
keithamus: Why not ignore tabindex in reading-flow?
annevk: We ignore it on the container but it makes sense for it to be
preserved in children
astearns: It sounds like we need more discussions on how scoping
tabindex works, and not doing it causes problems. We'll go
back to CSSWG to work on the draft.
annevk: When you reference the issue - the HTML PR is not the issue
it should go
Received on Monday, 9 December 2024 23:38:05 UTC