- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 18 Jul 2024 18:31:57 -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.
=========================================
CSS Containment & Conditional
-----------------------------
- RESOLVED: Publish new WD of Conditional 5 (Issue #10433:
Reorganizing the Containment specs)
CSS UI
------
- RESOLVED: When the caret is past the end of a line, attempt to show
the caret even if it overflow, with any necessary
clipping behavior we end up needing to be specified
later. (Issue #10289: caret-shape: block/underscore and
overflow)
CSS Text
--------
- RESOLVED: Specify the -webkit-* values for text-align in the Compat
spec (Issue #10388: Specify HTML alignment as text-align:
-webkit-{left,right,center})
CSS Conditional
---------------
- RESOLVED: Use `named-feature()` as the function name (Issue #9875:
Choose names for keyword-based feature queries in
@supports and names for initial set of queries)
- RESOLVED: Call the keyword `align-content-on-display-block`
(Issue #9875)
CSS Font Loading
----------------
- RESOLVED: Delete FontFaceSet constructor from the spec (Issue
#10390: Remove the FontFaceSet constructor?)
CSS Images
----------
- RESOLVED: Move the missing position fixup to computed value time
(Issue #10374: Gradient interpolation doesn't specify how
to handle positionless stops at computed-value time)
CSS Selectors
-------------
- The group wasn't ready to close issue #3080 (Do we need
:focus-visible-within?) yet, but agreed to remove it from call
agendas until there is more discussion in the issue as to if the
use case can be covered by shadow dom or not.
CSSOM View
----------
- RESOLVED: Add .width and .height as doubles to the layout viewport
interface (Issue #5260: No way to access the viewport
size without losing precision)
===== FULL MEETING MINUTES ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2024Jul/0005.html
Present:
Tab Atkins
Kevin Babbitt
David Baron
Stephen Chenney
Keith Cirkel
Emilio Cobos Álvarez
Robert Flack
Paul Grenier
Chris Harrelson
Daniel Holbert
Jonathan Kew
Ian Kilpatrick
Roman Komarov
Chris Lilley
Alan Stearns
Brandon Stewart
Miriam Suzanne
Regrets:
Rachel Andrew
Yehonatan Daniv
Elika Etemad
Noam Rosenthal
Khushal Sagar
Lea Verou
Chair: astearns
Scribe: TabAtkins
Scribe's scribe: emilio
CSS Containment & Conditional
=============================
Reorganizing the Containment specs
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10433#issuecomment-2231498564
miriam: We resolved earlier to move CQ out of containment and into
conditional
miriam: That has meant, so far, that what has happened is CQ were
removed from Contain and repubbed, but Conditional hasn't
been repubbed yet.
miriam: So CQ doesn't exist outside of ED right now, which seems wrong
miriam: Seems we should publish Conditional
miriam: I don't know what else has happened in Conditional 5, dunno
if I'm the right person to comment on if we can do that right
away
ChrisL: I've gone through the changes on Conditional, doc is ready to
be published
<ChrisL> +1
astearns: Proposed resolution to publish new WD of CSS Conditional 5
astearns: Objections?
RESOLVED: Publish new WD of Conditional 5
astearns: There was some discussion about whether we do Conditional 3
as a retired draft
astearns: I think its current state (just a parking doc that says "go
look at Conditional 5") is fine. We can worry about it
later.
astearns: Any concerns with no action?
ChrisL: Not a concern, but unsure about consequences if we retire and
then want to repub with something in it. Should know, but I
don't. I think "no action" is fine.
astearns: Yeah, expect a discontinued draft being re-continued hasn't
happened before.
astearns: So let's leave Contain 3 as it is.
<fantasai> The reason we introduced Discontinued Draft was to have an
IPR-safe place to park the draft.
<fantasai> FWIW
CSS UI
======
caret-shape: block/underscore and overflow
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10289
schenney: This is the only significant issue blocking Igalia
implementing the feature
schenney: If you have a fixed-size container, and you're editing, and
you have a block or underscore caret-shape
schenney: What happens when it gets to the end of the line and
there's no space to draw the caret?
schenney: Spec isn't clear, I did some investigation but it's not
clear what's happening.
schenney: My argument is for not drawing, or drawing what you can
<TabAtkins> (+1 for drawing clipped; making a new line is wrong)
kizu: Firefox draws regardless and possibly clips
kizu: You can see that with overflow:clip on a parent
kizu: I think I like this better, if it's on the edge of a container
and it's clipped by overflow, the user can't see the caret.
kizu: Easier if it still shows. Still *possible* to be invisible, but
not common.
kizu: I think in general if we can draw the caret, perhaps on the
border of the content, we should. Also agree that wrapping
isn't a good idea.
astearns: So not really option 4 in the issue, but a new option?
Treat the caret as overflow regardless of overflow on the
container?
kizu: No, more like focus-ring in Firefox. It's drawn over everything
(but inside of browser chrome).
astearns: With chair hat off, I'm also in favor of not clipping the
cursor. If you clip it it might not look like a cursor even
if partially drawn.
schenney: I'm coming around to thinking that is the best option.
Anything creating a new line is definitely a bad idea.
emilio: Clarifying firefox - it doesn't skip clipping arbitrarily,
it's just drawn by the containing block of the element. So
it'll skip *some* clipping but not all.
emilio: I implemented this to be compatible with some Chromium quirks.
emilio: I can dig up some history, but yeah, it's not just "don't
clip the caret"
schenney: So one option is we can try implementing with not clipping,
and see what happens. I suspect it's problematic, because
clip is applied to the container.
schenney: But that does seem like the best way to resolve this in the
short term.
emilio: I suspect it interacts badly with scrolling and such if you
scroll off the editable element entirely.
<flackr> +1
emilio: That's why I landed on that compromise in FF
<PaulG> (APA interest here) I agree not clipping (or limited
clipping) sounds better.
emilio: I'd be suspicious with "not clip at all" even being
compatible. Don't think it's most desirable either.
kizu: Just tested in codepen, FF is interesting.
kizu: Still seeing it painting outside of a contain:paint
kizu: [another case]
<kizu> I tested in CodePen: https://codepen.io/kizu/pen/oNrbYPP —
Firefox's behavior is interested, where when there is
overflow: auto, the cursor is visible on the edge, as if it
was “sticky”
astearns: Perhaps have a resolution to attempt to show the caret in
full, in the case this issue talks about, but leave open
exactly what the clipping behavior is until Steven has time
to work things out?
schenney: Yes, sounds reasonable to resolve on that and leave the
issue open for details.
astearns: Proposed: when the caret is past the end of a line, attempt
to show the caret even if it overflow, with any necessary
clipping behavior we end up needing to be specified later.
astearns: Objections?
RESOLVED: When the caret is past the end of a line, attempt to show
the caret even if it overflow, with any necessary clipping
behavior we end up needing to be specified later.
CSS Text
========
Specify HTML alignment as text-align: -webkit-{left,right,center}
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10388
emilio: Websites try to depend on this -webkit value being exposed
emilio: Right now nobody implements the justify-items:legacy stuff
emilio: My original idea was to just spec reality here, which is a
bit underwhelming
emilio: but I'm okay trying to implement justify-items
emilio: But we'll probably need to keep the -webkit value for compat
emilio: So we should probably choose to spec -webkit-left/right/
center either in Alignment or Compat (probably Compat), and
let browsers implement Alignment eventually
TabAtkins: So your proposal is we spec the -webkit in Compat, and
have HTML refer to those, and later see if we can
compat-wise fix to Alignment?
emilio: Yes. We can possibly have HTML refer to Alignment.
TabAtkins: I don't think HTML would take a patch for features that
aren't implemented yet.
emilio: Yeah, possibly.
astearns: So two steps. First, add -webkit value to text-align
because we have to, not because we want to.
emilio: Yes, because widely depended on
astearns: But then a little unclear what the second step is
astearns: Oriol talks about using justify-items:legacy opting into
those values, but I thought the point was sites depending
on the values without using justify-items
emilio: Right, you have to support the text-align values anyway.
emilio: So my preference is to keep them both defined, and then start
with having HTML referring to the text-align values, and
later switch to justify-items once implemented
dbaron: This sounds reasonable to me
dbaron: Given that everyone does the same thing, and it's not
completely clear what the space of changes we can make
compatibly *is*, it seems reasonable to spec what we
currently have, maybe with a note about what we want to
change it to in the future.
dbaron: This legacy thing is defined in a way that's supposed to deal
with this issue, but it's not clear, for example, how much
pages depend on this actually working via text-align
dbaron: Because for example you can override this inherited behavior
by setting another value on text-align. We need to see if
that's something that's ok to break.
dbaron: So I'm supportive of moving closer to reality.
iank: dbaron just said what I was gonna
astearns: so proposed resolution is: specify the -webkit value for
text-align, with a note about what we'd like to do in the
future
emilio: I think we should specify them without a note, and have HTML
take the note about the intended migration
dbaron: Sounds fine.
TabAtkins: Specify in Text or in Compat?
astearns: Compat sounds slightly easier to quarantine
emilio: Sounds fine, don't mind either way
RESOLVED: Specify the -webkit-* values for text-align in the Compat
spec.
astearns: Who's doing the HTML patch?
emilio: I can.
CSS Conditional
===============
Choose names for keyword-based feature queries in @supports and names
for initial set of queries
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/9875
dbaron: About six months ago we had a discussion about adding a
mechanism for one-off things in @supports that don't have an
existing structure to fit in
dbaron: To solve some known problems that would otherwise be
complicated to deal with.
dbaron: We resolved to do it, but not on what to call the things
dbaron: I opened an issue about naming, it has not had much
discussion, but I have proposed names in the issue
dbaron: There was a bunch of disagreement about naming the last time
we discussed it
dbaron: It seems like the sort of thing that might be easier in an
issue but nobody was commenting, so telecon it is
dbaron: Proposal is to call the query function `feature()`
dbaron: And calling the feature for css alignment on blocks as
`align-content-on-display-block`
dbaron: I'm okay with resolving today or taking it back to the issue,
as long as someone actually comments in the issue
astearns: The bit that's possibly not changeable is...
dbaron: It just might be less useful because the thing we want to
detect has already been shipping for a while. So might not be
useful/accurate.
astearns: I agree with the commenter that feature() isn't great,
think named-feature() is slightly better. But don't have a
strong opinion.
<kizu> +1
astearns: But since this isn't meant to be a very used feature, I
think a longer name is fine
dbaron: Fine with named-feature()
<TabAtkins> No opinion from me; lean slightly toward just feature().
keyword seems fine
miriam: I think this is useful, having it matters more to me than
bikeshedding it. Happy with these proposed names
schenney: I'm in favor of named-feature(), makes it clear you're
looking for a special name
astearns: We can resolve on named-feature() and see if anyone
complains afterward
astearns: proposed resolution is to use named-feature()
RESOLVED: Use `named-feature()` as the function name
astearns: Do you want a resolution on the keyword too?
dbaron: We should resolve on the name, then figure out if we still
want it
astearns: Proposed resolution: call the keyword
`align-content-on-display-block`
RESOLVED: Call the keyword `align-content-on-display-block`
CSS Font Loading
================
Remove the FontFaceSet constructor?
-----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10390
TabAtkins: So we have a crbug tracking the missing FontFaceSet
constructor
TabAtkins: but there's not a lot of reasons to have it
TabAtkins: I agree, at the time I wrote the spec I was of the thought
that magic interfaces were a smell
TabAtkins: so I put it in on the assumption that it could be useful
TabAtkins: but the only useful thing is calling .check()
TabAtkins: so fine with removing it, a one-liner in the spec
emilio: Agree with Tab, and also WebKit's the one that wanted to
remove it at the time foolip filed the issue. It actually
caused trouble for them
emilio: So it's unanimous agreement.
RESOLVED: Delete FontFaceSet constructor from the spec
CSS Images
==========
Gradient interpolation doesn't specify how to handle positionless
stops at computed-value time
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/10374
TabAtkins: Right now images defines fixup steps to supply default
positions and shift stops that are mis-ordered
TabAtkins: The second one requires layout-time information
TabAtkins: so that step has to happen at used value time
TabAtkins: for simplicity at the time I put all the fixups over there
TabAtkins: But that means that stops without a position don't have a
position at computed value time when interpolating
TabAtkins: And there's no reason for doing that, can be done at
computed-value time
TabAtkins: Proposal is to split the fix-up between computed-value and
used-value time fixup
TabAtkins: where computed fixup would assign positions
TabAtkins: and used would reorder fixups
<ChrisL> q+ to wonder what the syntax is for the interpolated value
ChrisL: What do you actually get?
TabAtkins: Just calc()s
TabAtkins: Just evenly spacing the missing values
astearns: So proposal is moving the missing position fixup to
computed value time
emilio: My concern is - to be clear, I think every browser does this
at used-value time right now
emilio: This changes the computed value serialization in a somewhat
non-trivial way, hope this isn't an issue
emilio: this is potentially a concern
TabAtkins: I haven't done a test to see if browsers currently
interpolate missing positions or not
TabAtkins: I think the gradient interpolation text doesn't take that
into account
TabAtkins: The serialization one is a meaningful change, we can fix
that if it becomes a problem
emilio: At that point you could just change the interpolation
algorithm right?
TabAtkins: Yeah that'd probably be better
ChrisL: If we're fixing this this, I think a one-stop gradient would
go to a 50% rather than 0 or 100%
TabAtkins: Happy to take that up but let's do this resolution first
<ChrisL> OK, the other issue is #10092
<ChrisL> https://github.com/w3c/csswg-drafts/issues/10092#issuecomment-2230892477
RESOLVED: Move the missing position fixup to computed value time
emilio: Does this _need_ to happen at computed value time? Could be
done at parse time right?
TabAtkins: Yeah, but we usually don't do this at parse time
emilio: Yeah just wanted to clarify whether it could be done or I was
missing anything
ChrisL: Just wanted to make sure we didn't stomp on the other
resolution
TabAtkins: Yeah it doesn't matter very much
CSS Selectors
=============
Do we need :focus-visible-within?
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/3080
astearns: Brian added a comment just asking to close the issue (and
open a different one about shadow dom)
dbaron: I think we should punt, people missing probably have strong
opinions
astearns: Would be great if those strong opinions were written in to
the issue
emilio: I know focus does propagate out from shadow trees
emilio: :has() mostly covers this, just not when shadow dom is
involved
emilio: And for that, :focus works, but :focus-visible... probably
not?
emilio: I think moving it out of the shadow tree would cause
undesired outlines
emilio: So main question is if people are having to work around this
with JS we probably want something like this, but...
emilio: I don't see a way of making it work with shadow dom
emilio: Slightly against closing because there's a use-case that
seems valid, and don't see how it can be addressed without
this
astearns: So punt on this today. Keep the agenda tag on it? or
solicit opinions first?
astearns: Slightly inclined to take the tag off
dbaron: I think taking it off is fine, though I think I'm in the
opposite camp of Brian (I think we should add it)
CSSOM View
==========
No way to access the viewport size without losing precision
-----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5260
emilio: We've discussed in the past, making innerWidth and
innerHeight not round is not compatible, it breaks things
emilio: but we recently decided to add an object to the Window that
represents the layout viewport (mainly for segments stuff)
emilio: But it sounds like a good place to expose the full
double-precision viewport dimensions
emilio: So they'll do the same as innerHeight/Width, but without the
weird rounding
<flackr> +1
emilio: Proposal is to add ... unsure if we decided it to be
window.viewport or window.layoutViewport, but whatever, add
.width and .height
astearns: Idle thought that maybe this should have a slightly
different name to indicate it shouldn't be rounded, but
nevermind, that sounds awful
emilio: Before we had this new object, best proposal I could come up
with was .innerWidthDouble or .innerWidthUnrounded
emilio: but those are bad
emilio: MDN and the spec could have a note about the difference
flackr: Another bad alternative would be to have a gBCR() api on one
of these objects, those also return doubles
emilio: Right, but top and left would be 0 always
flackr: You *could* imagine them being the scroll position...
astearns: That sounds worse
emilio: There's other issues to expose the other layout viewport
things (small/big/etc)
emilio: But I think .width and .height should do the right thing.
emilio: And consider other names for the small/large viewport sizes
astearns: Anyone remember if it's .viewport or .layoutViewport?
emilio: I think we punted on the name in the previous call
astearns: So proposal is to add .width and .height as doubles to the
layout viewport interface
RESOLVED: Add .width and .height as doubles to the layout viewport
interface
TabAtkins: When we have these box sizes, I'm always confused about
whether they have scrollbars or not, do we need variants
to account for that?
emilio: I think right now the way to do that is
document.scrollingElement.scrollWidth, or clientWidth
emilio: Which I agree isn't great
emilio: I'm also not sure if those round or not off the top of my head
emilio: but gBCR() gets around it
emilio: We should have a separate issue
TabAtkins: Agreed
Received on Thursday, 18 July 2024 22:32:31 UTC