- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 22 Jun 2022 19:27:35 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
Summer F2F
----------
- RESOLVED: CSSWG F2F in NYC Aug 1-3, further details incoming on
private list
- Please RSVP as soon as possible if planning on attending in
person or virtually in order to get logistics confirmed:
https://wiki.csswg.org/planning/nyc-2022
Color 4
-------
- RESOLVED: Republish Color 4 and 5 (Issue #7393: CSS Color 4 to
Candidate Recommendation)
- RESOLVED: Color 4 to CR when timing permits (Issue #7393)
Images 4
--------
- A resolution for republishing will be called next week so that
people have time to review the changes (Issue #7043: Long overdue
for republishing)
CSS Contain
-----------
- RESOLVED: Initial value is `none` (Issue #7066: Revisit decision to
make style the default container type)
- RESOLVED: All elements are style containers by default (Issue #7066)
CSS Pseudo
----------
- RESOLVED: Go with Delan's option 2 [For ::highlight pseudos, we
redefine the "inherited value" of 'color' at the root, so
instead of being the initial value (as normal) it is
currentColor]. (Issue #6774: Defaulting ‘color’ in :root
highlights)
Fullscreen
----------
- RESOLVED: Fullscreen elements should inert the stuff behind them,
and match :modal (Issue #7311: Should :fullscreen be a
modal state?)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Jun/0014.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins Bittner
Delan Azabani
David Baron
Mike Bremford
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Megan Gardner
Brian Kardell
Jonathan Kew
Vladimir Levin
Rune Lillesveen
Chris Lilley
Peter Linss
Eric Meyer
François Remy
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Bramus Van Damme
Lea Verou
Sebastian Zartner
Regrets:
Daniel Holbert
Scribe: TabAtkins
Summer F2F
==========
Rossen: We've tallied the summer f2f results
Rossen: Decided to hold as much of an f2f as possible in person
Rossen: For those who can make their way to NYC
Rossen: For everyone else, we'll make sure we have proper virtual
facilities for participation
Rossen: Picked timing and place based on allowing other participants
to allow TAG f2f, as well as having a geo location that's
okay for global participation
<astearns> This will also allow us to test out substantial virtual
participation pre-TPAC
Rossen: No one's going to be perfectly satisfied unless they're
already in east coast time zone
Rossen: Putting it earlier would be hard for lack to warning for
travel and location
Rossen: So fyi to everyone
Rossen: Also wanted to give a chance to talk about hosting
<jensimmons> Aug 4-6 are the proposed dates
TabAtkins: 4-6 wasn't the dates proposed, 1-3 was
jensimmons: Rossen sent 4-6 in the email
Rossen: Oh I got confused, was looking at July
<TabAtkins> DATES ARE AUGUST 1-3
TabAtkins: Plan is to rent a loft in Tribeca with excellent
ventilation, able to host 20 ppl in common spaces
TabAtkins: Need confirmation on dates and location in order to
confirm the venue
lea: Is this an fyi on date/location or are we still deciding?
Rossen: This is the current proposal. If you have a hosting proposal
elsewhere we can consider...
florian: There's not much time to hesitate
fantasai: I have all the logistics ready, all I need is absolute
confirmation
TabAtkins: I have about a day and a half to cancel the reservation if
we go elsewhere
Rossen: Okay so this is time-sensitive. If anyone has another
proposal this is when to surface it, otherwise I'm calling
for resolution
fremy: Do you know how many people will make it in person vs remotely?
Rossen: Looks like more than a dozen people from confirmations
lea: Note that speculative survey responses are different from actual
confirmations
fantasai: We're very time-sensitive, can we do a survey on this call?
we need to make a call on this particular venue
STRAW POLL: (1) will attend in person in NYC Aug 1-3 (2) will not
attend in person
<astearns> 1
<smfr> 2
<faceless> 2 - dateclash, sorry
<lea> 2
<jensimmons> 1
<jfkthame> 2
<chris> 2
<dandclark> 2
<Rossen> 1
<vmpstr> 2
<emilio> 1
<futhark> 2
<TabAtkins> 1
<florian> 1, probably
<fremy> 2
<fantasai> 1
<plinss> 1, tentative
<bramus> 1
<argyle> 1 tentative
<miriam> 1, tentative
<emeyer> 2 (most likely)
<bradk> Virtual for me
<dbaron> likely 2, though remote chance of 1 if I hear more details
about ventilation etc. in venue
<delan> 2
<TabAtkins> (8 attendees on call, with 3 tentative attendees)
<fremy> sounds like a good enough group to me
Rossen: So that answers the participation question, and this'll be as
hybrid as we can make
<jensimmons> Like dbaron I'd love to hear details about ventilation.
(Link to Airbnb venue would be one way to do so. I'm
presuming it has windows that open.) It'd be good to
agree about masking policy as well.
<astearns> I suggest we start with TPAC plans for vaccination
requirements, inside masking, etc.
Rossen: This looks like a reasonable number. Final call for
resolution.
<TabAtkins> https://wiki.csswg.org/planning/nyc-2022 for details
<TabAtkins> https://www.airbnb.com/rooms/53428467?source_impression_id=p3_1655914572_%2BSlp4jp%2FDP%2B%2B8OJl
RESOLVED: CSSWG f2f in NYC Aug 1-3, further details incoming on
private list
fantasai: Tab just linked to wiki page, plz register asap to
participant list so we can get logistics together
fantasai: Let us know dietary restrictions so we can make sure
everyone has food
fantasai: Allergies but also dislikes are fine
<fantasai> (please distinguish which!)
<fantasai> (and level of allergy)
<castastrophe> late logging onto IRC but I'm a 1 for attending as well
Color 4
=======
CSS Color 4 to Candidate Recommendation
---------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7393
Rossen: Looks like you wanted to ask for additional resolutions?
chris: Last week we made some Color 4 and 5 resolutions
chris: I wanted to request a new WD
chris: Not many changes from a couple months ago, but want an
up-to-date WD
chris: Takes at least a week for CR
Rossen: So repubbing Color 4 and 5, what changes?
chris: Some changes we agreed on last week; Color 5 punted
color-contrast() to Color 6
Rossen: Objections to republishing?
RESOLVED: Republish Color 4 and 5
chris: Color 4 has good test results and is being implemented, we
should get CR quick
Rossen: Anyone need more time to look over test results?
Rossen: In order to move Color 4 to CR? If not we can resolve today
Rossen: Objections for Color 4 CR?
RESOLVED: Color 4 to CR when timing permits
<chrishtr> Congratulations!
Images 4
========
Long overdue for republishing
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/7043
chris: We just resolved to ship something in Images 4 and the spec
hasn't been updated in 5 years, come on
TabAtkins: Chris, you're married to one of the editors
fantasai: Need to evaluate the changes list, which I can do and we
can revisit next week?
chris: I've updated the changes list
fantasai: Okay I'll review. I'm okay with provisional resolution to
repub.
Rossen: Let's do it next week when there's been review. Taking the
resolution isn't hard.
Republishing Tasks Permathread
==============================
github: https://github.com/w3c/csswg-drafts/issues/6900
chris: That was color 4 and 5
CSS Contain
===========
Revisit decision to make style the default container type
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7066
miriam: There's been more discussion. I left a summary, well, longer
than that, at the end of the thread. No responses since.
<fantasai> https://github.com/w3c/csswg-drafts/issues/7066#issuecomment-1158184820
miriam: So same question as last time - last time we talked about it
it split into several questions.
miriam: 1) Do we need style queries? I think we do, I argued for it.
miriam: 2) If we have them, should every container be a style
container by default. I think answer is yes for authors,
question is perf.
miriam: In convo with emilio it seems the perf issues are less (maybe
not none) if the impl first matches selectors then looks for
containers
miriam: If you're going the other way and matching containers first,
and everything's a container, you don't get much filtering.
miriam: Those perf issues are only for people using broad container
queries (not using name, etc) and broad selectors.
Multiplying those together means lots of searching
miriam: I don't know how bad that perf hit would be, so hard for me
to judge on that.
miriam: Proposal moving forward is [missed]
miriam: If we start now with an initial value of none, browsers can
release size queries, and I think that's the right syntax
miriam: Other question: people will set container types in various
places, also names
miriam: Suggestion was to set type in another longhand. But that
doesn't work for names.
miriam: I think the general solution is an additive cascade. No
specific solution, need general solution here.
Rossen: Any further comments?
<astearns> read the comment and support the suggested resolution
futhark: I'm supportive, I said so on her writeup
futhark: Positive to the proposed resolutions
futhark: Important thing now for chrome and safari is to end up with
the initial value of `none`, will let us ship CQs without
having to worry about whether everything's a style container
futhark: We're exploring style queries; right now it doesn't sound
that bad to have them as default
fantasai: I'm in favor of miriam's points
Rossen: Miriam could you summarize?
miriam: First resolution, initial value is `none`
Rossen: Objections?
<chrishtr> +1 to Miriam's proposed resolution.
<SebastianZartner> +1 from me, too
RESOLVED: Initial value is `none`
miriam: Since style queries are in the spec, probably need a
resolution for every element being a style container by
default. We'll spec that out and adjust as needed as impls
start showing up.
fantasai: Resolution is that every element *is* a style container,
regardless of `container-type`.
emilio: Still skeptical about this.
emilio: Gecko's CQs are like Blink's. It's a little more annoying to
have every element be a style container.
fantasai: Argument is a lot of people will do that anyway because
it's useful to query, so you'll take that hit on a lot of
pages anyway.
fantasai: That's our expectation.
emilio: I don't know if my expectation matches, but you know more
about CSS authors. Okay with that for now, guess I don't
object.
RESOLVED: All elements are style containers by default
<SebastianZartner> Congrats Miriam!
<bramus> Nice!
<fantasai> Side question, should 'none' be 'normal' now since
everything's a style container?
CSS Pseudo
==========
Defaulting ‘color’ in :root highlights
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6774
<delan> https://github.com/w3c/csswg-drafts/issues/6774#issuecomment-1083055006
delan: For highlight pseudos, setting color:currentColor means the
color doesn't change when you highlight with that pseudo,
compared to the original color underneath
delan: Editors agreed this is what should happen if color hasn't been
set anywhere for a highlight
delan: I think the way this is achieved isn't actually specified. My
best interp of Cascade is that we don't actually do that, and
the spec says the default color of a highlight pseudo becomes
black
delan: Three steps
delan: First, when you have an inherited property (all props are
inherited for highlights), they do the defaulting by way of
"inherited value"
delan: Second, inherited value is value from parent, unless you're at
root, in which case it's initial value
delan: Third, initial value of color property is CanvasText
delan: Which is generally black (in light mode)
delan: So this raises the question of how to fix it
delan: Which step we add an exception for affects what happens when
you use initial/inherit/unset
delan: One option is to say that for highlights, the initial value
isn't CanvasText, it's currentColor
delan: Here if you set color to initial/inherit/unset, they'll become
currentColor
delan: Second option is for highlights, the inherited value isn't the
initial value at root, but instead currentColor
delan: So when you set color to inherit/unset you get currentColor,
but initial means canvastext
delan: I like this the best
delan: Third option is to change defaulting for highlight pseudos and
say that for root highlights, you don't inherit, we just set
the value.
delan: So all the keywords would become canvastext
delan: Not sure my understanding is correct, but it's how I see
things. What should we do?
fantasai: That was a great explanation of a complicated issue
fantasai: I think either first or second makes sense to me
fantasai: If no one has a reason to do something different your pref
makes sense to me. I suspect your pref is the easiest to
implement.
delan: I think all three are possible to implement. I preferred 2
over 1 because in option 2 you can say color:initial and get
black, and I feel like that intuitively makes sense.
emilio: Doesn't 2 change the - fix the weirdness around currentColor
in highlights?
emilio: If we change how it inherits doesn't it fix all the
shenanigans about what currentColor means in highlights?
emilio: Or is this orthogonal
delan: I don't think it does
delan: Are you talking about where we have the exception for
currentColor where it means this special thing for highlights?
emilio: yes
delan: Then no, this actually relies on that.
delan: Unless we don't literally use the word "currentColor" in our
fix and just say that it "keeps the same color"
delan: But as worded it relies on that currentColor behavior
emilio: More generally, currentColor refers to the computed value of
the color property, how can you inherit it?
emilio: In impls the color property is special bc you don't want to
resolve currentColor by walking all the way to the root
emilio: and currentColor disappears at computed value time, before
inheritance
emilio: But if this is just an impl detail, eh, this just makes color
more special, but given previous things we're past that point
Rossen: So hearing some gravity towards options 1 and 2, particular 2
as delan's fave. Is this something we can resolve on?
delan: Restating option 2: For ::highlight pseudos, we redefine the
"inherited value" of 'color' at the root, so instead of being
the initial value (as normal) it is currentColor.
<fantasai> currentColor does not disappear at computed value time...
that's one of the important things about it
Rossen: Objections?
RESOLVED: Go with Delan's option 2.
<fantasai> WFM
CSS Backgrounds
===============
The shape of box-shadow should be a circle for a box with
border-radius:50% and big spread
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7103
[looking for Oriol on the call]
fantasai: Let's push to next week
Fullscreen
==========
Should :fullscreen be a modal state?
------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7311
chrishtr: We introduced :modal, which brought to our attention that
Chrome impl of FullScreen makes it modal (stuff behind is
inert) but other impls don't do that
chrishtr: Think we should resolve on whether fullscreen is modal,
which both affects inert and whether :modal applies to it
chrishtr: Don't have a strong opinion on how we go
ntim: I think it makes sense to make the stuff behind fullscreen inert
ntim: But not sure webdevs would expect :modal pseudoclass tomatch in
this case
<TabAtkins> Aka *my exact argument for why we should have named it
:modal-dialog*
emilio: Unsure what webkit does for fullscreen
ntim: webkit's impl is old but if we redid it I'd make it inert
emilio: In firefox you can interact with stuff behind it; you can set
pointer-events:none and then interact with the page
ntim: I don't have strong opinion, but it seems unexpected that you
can do that
emilio: I don't particularly mind either way, was just pointing out
that you can, unless you do the chromium thing of making the
underlying page inert
fantasai: This is less of a style question. I think the inertness is
less significant
fantasai: Think we need to understand if there are use-cases for
being not inert
fantasai: Unsure we're equipped to resolve on this during this call
fantasai: probably need info from people authoring fullscreen stuff
and see if it's necessary to fullscreen something that
doesn't take up the whole screen
ntim: This issue aside, it seems unexpected either way for :modal to
apply to fullscreen elements, regardless of whether stuff
behind is inert
ntim: :modal comes from modal dialogs
fantasai: They might not, but we decided it means things with modal
qualities. Fullscreen might not be first in mind, but if it
has those qualities it should match
<flackr> +1
<masonf> +1
flackr: If the content behind wasn't inert it would be in tab order
as well, which could be confusing if you could tab out of the
fullscreen element
emilio: fair
jensimmons: This raises a11y memories, if visually a fullscreen
element covers everything, so assumption is the stuff
behind isn't accessible, having it not be inert could
make it different for people using other a11y tools
jensimmons: I'm wondering what the use-cases would be for making the
contents behind a fullscreen *not* inert
jensimmons: Maybe there should be a way to toggle it off, but default
should be for inert
fantasai: I buy that
<bkardell> agree
<masonf> +1
Rossen: strong agree
<bramus> +1
<chrishtr> Agree on inert making sense given these arguments
<SebastianZartner> +1 for what jensimmons said.
emilio: fair point. Then :modal should apply to fullscreen.
<florian> +1 to Jen
fantasai: Right, so decision is whether it's inert, and whether
:modal applies is a consequence
masonf: Strong agree with points, think fullscreen should inert the
rest of the page
masonf: Do we include special provisions for fullscreen escaping that
inertness, like dialogs have?
masonf: Like if you inert the entire page the fullscreen shouldn't be
inert, need provisions for that
ntim: That's what fullscreen does
masonf: Sure just want to make sure it's captured
Rossen: additional thoughts or objections?
plinss: In context of dialogs there's clear spec in html of what puts
the dialog into a modal state
plinss: in my mind that is what puts into a :modal pseudoclass
plinss: Think it's important to not just catch things that are
modal-ish
emilio: Yeah fullscreen spec should define the modalness
plinss: So as long as it's defined that fullscreen puts it into this
state just like dialog, unsure that we should just auto-apply
it because it resembles modalness
Rossen: So if I understand, fullscreen elements *are* modal from html
behavior like dialogs, and rely on same behavior. Is that
clarification?
plinss: I'm saying :modal shouldn't apply unless something is
*defined as* "being modal", not just because it's kinda
modal-ish in some respects. HTML is very clear about modal,
need to respect that.
plinss: So if fullscreen uses that same definition it's fine.
<ntim> https://html.spec.whatwg.org/multipage/interactive-elements.html#is-modal
<SebastianZartner> Maybe we can at least resolve on fullscreen
elements making the reset inert.
masonf: +1 to that
masonf: Note that HTML doesn't define "being modal", it defines how a
dialog becomes modal. But that can probably be pulled out
into a proper definition.
RESOLVED: Fullscreen elements should inert the stuff behind them, and
match :modal
Received on Wednesday, 22 June 2022 23:28:16 UTC