- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 Mar 2025 19:42:53 -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
================================
Connect HTML spec up to new CSS `interactivity` property
(WHATWG PR #10956)
---------------------------------------------------------
- There were a few questions on the proposal and a concern about the
property name itself, but generally the group agreed to proceed.
- CSSWG will discuss internally how best to signal the required
property is stable.
- There is still a desire for further implementor feedback on the
property.
Margin Collapsing (WHATWG PR #10296)
------------------------------------
- There were concerns expressed with removing the quirk as previous
tests had revealed that would result in meaningful breakage.
However, a good goal could be to emulate the quirk with current
properties.
Walkthrough of the new CSS Forms spec
-------------------------------------
- The new CSS Forms ( https://drafts.csswg.org/css-forms-1/ ) spec is
close to a request for FPWD.
- Feedback was positive around the draft and generally said it was in
the right direction, though still had issues which will need to
be addressed.
- The draft separates releasing features in a way that not everyone
felt was clear or the best path forward and will need further
discussion. There was a focus on how can we make it so authors
can opt in to future functionality as its released incrementally.
===== FULL MEETING MINUTES ======
Agenda: https://github.com/whatwg/html/issues/11059
Present:
Panagiotis Astithas
Emilio Cobos Álvarez
Hidde de Vries
Elika Etemad
Mason Freed
Tim Nguyen
Olli Pettay
Simon Pieters
Jen Simmons
Alan Stearns
Anne van Kesteren
Luke Warlow
Scribe: hdv
OpenUI-WHATWG/HTML-CSSWG Meeting
++++++++++++++++++++++++++++++++
Connect HTML spec up to new CSS `interactivity` property
========================================================
github: https://github.com/whatwg/html/pull/10956
masonf: Quick intro… this is two sets of specs (CSS, HTML) for a new
property called `interactivity`, works like `inert` in HTML,
there's a spec PR in HTML that connects this up
masonf: Both sides have some control here… HTML has a way to make
things inert, CSS does too now, HTML can interconnect the two
masonf: and make sure overriding works as expected
masonf: This was editorially reviewed, am looking for implementor
support
masonf: for both parts, HTML and CSS
annevk: What I'd like input from CSSWG… at the moment we take
something with dependencies on HTML spec, it's the equivalent
to CR spec in W3C land, taking a dependency in your work, if
it breaks something you're invalidating implementations
fantasai: If something is in CR, it's definitely very stable. If not,
it's not clear where it is in terms of stability
fantasai: We do have CSS snapshots, to show where things are
fantasai: Also have capability in Snapshot to show for individual
features, 'these things are not in CR but stable enough to
ship'
fantasai: kind of the only tool we have to indicate stability beyond
CR flag
fantasai: Sometimes a feature was worked on by one team but others
haven't seen it yet, that conversation prompts people to
look at it and they might find design issue or issues that
weren't paid attention to
fantasai: If you want something at the level of super stable, we can
have that conversation
lwarlow: The property name seems ambiguous
lwarlow: makes me feel iffy re: what it wants to do in the future and
if this naming allows it
lwarlow: Maybe interactivity is clearer and I haven't read enough…
interactivity doesn't _just_ mean is it inert or not… eg see
focusability… there's a desire to have a CSS way to cover
focusability, is that part of it or separate?
emilio: One of the comments on the PR was regarding the model
emilio: It feels iffy to deal with some things via CSS and with
others, have it automatic, like auto
emilio: makes it a bit harder to reason about
emilio: if you're fine with that, seems fine implementation wise
masonf: Pretty strong push from the a11y folks, reason the value is
auto is… for somebody to be able to do body { /* set it to
auto */ } would break all sorts of accessibility
emilio: There are other ways to do that… eg you could set important
but would be annoying
emilio: If the spec could make that clearer, eg this is weird but
this is why it is weird, would be ok. It's a bit annoying
implementation wise, but it's okay
emilio: No concerns
masonf: Can't really use !important either, you need to be able to
re-inert a modal dialog via CSS
emilio: Yes is weird
emilio: Right now, webkit effectively has inherit bit in the style
object, basically an internal property
emilio: Now, with a value on top of that… doesn't inert in HTML have
similar concerns?
masonf: But then it's a developer side thing, modals are a bit more
special I guess
emilio: Not sure if I agree but its ok
masonf: Just parroting what I've heard
panos: So this room's consensus is this is ok to move forward with?
emilio: I'm okay with that
smaug: If you make something inert and focus is in that area, what
happens to the focus?
emilio: Same as if you make it visibility hidden or something else
annevk: What did you mean with move forward?
panos: Is everyone ok with CSS side of things?
masonf: Comment on weird side of things probably belongs in HTML
annevk: Luke brought op the name of the property, that seems
essential for both specs
annevk: and we probably need good idea of what stability means on the
CSS side
annevk: At TC39 we know stability/consensus within the group; it'd be
trivial to organize the HTML stuff around that, but in CSS
it's less clear
fantasai: I think we can make it more clear, just need to use
Snapshot more rigorously?
masonf: Does TC39 refer out to other specs and if so how? what we're
discussing here is interdependencies of specs?
annevk: How?
masonf: Release process was independent in the past
annevk: At TC39 usually have dependencies but one way, we know at
which point it has a state where TC39 is happy about it
annevk: We want to avoid building on quicksand in this situation
past: Is it okay for CSS WG to discuss internally and give out a
signal that WHATWG can use as a stability indicator?
astearns: Personally I think we should be careful about referencing
something in a CSS spec assuming it is stable
astearns: Lack of issues is one thing, usually issues come up when
people try implementing something. I don't think this
property has prototypes yet
masonf: It's fully implemented in Chromium and there are WPTs
astearns: In that case my concern is less, may be stable enough to
reference
fantasai: I think it should be put in a snapshot… changes happen in
response to implementation, but also in response to more
people looking at it… putting it into a snapshot could be a
way to get people to chime in
<fantasai> https://www.w3.org/TR/css/#CR-exceptions
astearns: We also had things ready to ship even if the whole module
is not ready completely yet
past: Any other thoughts or feedback?
past: This seems like a question for CSSWG to answer
past: Sounded like you were waiting for implementor feedback, masonf ?
masonf: Yes
emilio: Without my mozilla hat on, sounds good to me
smaug: I need to review the PR
Margin Collapsing
=================
github: https://github.com/whatwg/html/issues/10296
emilio: I'm in support of the margin collapsing idea. Implementation
wise, how hard it is depend on how much we can kill it
past: We're discussing issue #10296, about slowing reducing the
margin collapsing quirk
annevk: Like I said last time… if end goal is to completely remove
quirks, would be interesting but I would fear compat issues
annevk: but not sure if that would help developers much, we'd still
need to teach them
past: This is carry over from last week's WHATNOT
past: Forgot to add it to this TF's agenda
fantasai: I don't think we can remove this quirk, there are a lot of
existing websites that depend on how it works today
ntim: Has there been a compat analysis before?
fantasai: Yes, which has confirmed it is not trivial
fantasai: Sites most likely to break are older ones, we shouldn't
break those either
zcorpan: Curious if it's possible to emulate the quirk with the new
margin trim properties
zcorpan: in the UA stylesheet
fantasai: Yes I think so, but think we can't remove the quirk entirely
<emilio> I agree the goal should be at least to explain it with
regular CSS (that is, without the Gecko-specific selectors,
and without qems)
Walkthrough of the new CSS forms spec
=====================================
ntim: In a nutshell, main point of base appearance is so that authors
have less things to override when they work on top of it
ntim: I added some examples that show how easily you can override
fonts and colors
ntim: it will just inherit if you put appearance:base on them
ntim: The spec also introduces pseudo elements, including for
pickers, and for specific parts of the most common parts of
different form controls
ntim: I'm curious to get this group's feedback. Curious to know if
this is going in the right direction. Main reason I am asking
is because I'd like to push this to first public working draft
<fantasai> https://drafts.csswg.org/css-forms-1/
masonf: Haven't had a chance to review it in detail, I did skim it.
Looks great in terms of covering all the controls and the
styles look good.
masonf: My concern is that the anatomy that the pseudos use is
defined so that you know x is inside of y and can understand
whether something could be, like, flexbox container
annevk: Wouldn't composability require markup changes as well?
masonf: Yes, different HTML
annevk: I thought we discussed that in the past and landed on making
new markup changes… if at that point appearance:base was
already there we'd need to move the base stylesheet with
those changes
masonf: Technically speaking I think you're right, but the difficult
part is the confusing developer. There'll be a fanfare when
this launches, if we launch one range control now and another
a few weeks later would be confusing?
annevk: If now we introduce 'you can style form controls that you
already know', and then introduce 'we now added new features
and everything is compat with before'
ntim: Re: mason's earlier question: the structure is defined, more
precisely for form controls, less so for others, goal is to
have them defined
ntim: I think it's worthwhile to focus on pseudo elements as a first
step. So that authors use as many of the tools as possible
before we implement the inside of the control
ntim: One possible issue with that is accessibility, often custom
markup can mess up accessibility
ntim: so I want to make sure we give developers simpler tools first
and then the more advanced tools
lwarlow: I read through the draft in detail… I think it is going in
the right direction, even if there's details to work out
lwarlow: In terms of extra markup, for me the two key bits… select
and data list (combobox style thing), provided we can get
the markup bits there, which we can because not void
elements, that would be great
lwarlow: While not super dynamic, it probably addresses most of what
developers would want
lwarlow: provided content properties work on in most places that'd
cover most use cases I've come across
masonf: Thanks for working to define the anatomy, great news
masonf: I agree with your comment tim, that it's enough to do the
pseudos first
masonf: Should we add, to our design principles, what percentage
we're aiming for?
masonf: personally I think it's like 95%, that should be doable, and
that's probably what we can do
masonf: I'm still worried about doing this in two steps, for select
we did markup and pseudos at the same time
zcorpan: Haven't read in detail yet, but wanted to say I agree with
the direction of the spec, looks like a useful set of
features for web developers
zcorpan: As for discussion on when to support markup changes: seems
reasonable to be able to do that later for some controls
jensimmons: Interesting question regarding how much we do in stages…
to my team it's really important to do the
'appearance:base' at once across all form controls and
not control by control
jensimmons: Open UI has come up with a really good way to make select
happen first
jensimmons: but other kinds of major revisions, can and should happen
whenever they happen to work out well
jensimmons: Tim's draft doesn't include popovers, we don't want to do
all work at once
smaug: people really want to customise @@@
<smaug> https://2024.stateofhtml.com/en-US/usage/#html_functionality_features
ntim: Regarding timing… I don't think developers will be confused if
the new things we do later are clearly new capabilities that we
do independently
masonf: If we ship appearance:base for all these things and later
more… like meter, we don't know how to add parts in there, we
might find out later… how do we make it opt in?
masonf: Would you later opt in to it with, like
appearance-meter:base ?
masonf: How do we opt in to future good stuff?
ntim: If you think there are use cases that are not addressed with
current proposal for in page control, feel free to file issues
against the csswg repo
ntim: Ideally we want to do all this at once so that there are no
separate opt ins
lwarlow: For inputs, if we did markup changes, that would by
definition HTML ways to opt in… so really would be nonvoid
els like meter
lwarlow: Don't think base appearance opt in is really the opt in for
composability?
masonf: It changes the style though
lwarlow: There's nothing stopping appearance auto doing something
with markup
annevk: That's a big thing we pushed for, to have things separate,
markup changes on their own independent of how things are
styled
annevk: so that we can have incremental changes to control. This also
applies to how we “reimagine redoing select”
<fantasai> +1 annevk
jensimmons: It was strange to me to hear masonf articulate the opt in
mechanism for select… the idea of having to use
appearance:base-select to get HTML to work, seems like a
violation of separation of concerns, can't think of
anything else that works that way
jensimmons: if select is working this way, that opens up the freedom
to change HTML and add capabilities to HTML
jensimmons: that developers can use without worrying about changes
fantasai: We should think about not does it solve all problems, but
focus on does it fix the problems we already have with the
HTML we already have. As we extend HTML, then of course the
CSS model will expand, too.
fantasai: I'd like everyone to think about… is this a draft that is
going in the right direction? obviously there is lack of
detail and there are open issues
fantasai: But are we ready for publishing and official First Public
Working Draft? Let's try to answer that in the next week
or two.
fantasai: FPWD is a statement to the world that we are working on
this, and in this rough direction. It's just the start of
continuing work.
fantasai: But we want to have a draft that shows clearly the scope of
that continuing work, and the direction it's going in.
Received on Friday, 7 March 2025 00:43:25 UTC