- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 25 May 2022 17:40:19 -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.
=========================================
TPAC & Longform Meetings
------------------------
- The deadline for TPAC meeting requests is the end of May. Please send
any preferences for meeting days to the private list.
- Next week there will be an extended meeting to cover the Selectors
topics.
- There have been some suggestions to have a hybrid in person/remote
session over the summer. If there is interest please reach out
to the private list.
Anchor Positioning
------------------
- iank introduced the concept of CSS Anchor Positioning to allow
positioning elements relative to other elements in the DOM.
- There were some initial questions and positive feedback. Discussion
will continue on the private github (
https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element
)
until the proposal is formally moved into the working group's
scope. Any substantial changes will also be noted in github
issue #7282 (Introduce CSS Anchor Positioning).
CSS Text Decor
--------------
- More examples will be added of the current unexpected behavior
mentioned in issue #7251 (Composition of inset shadows). astearns
will also do research into if there is already examples we can
follow in the Adobe products.
- RESOLVED: Leave text-shadow spread details undefined right now,
with possibility of specification later after impl
experience (Issue #7250: Text shadow spread corners)
CSS Text
--------
- RESOLVED: No change (Issue #7249: Make U+0000 invisible?)
- Bugs will be filed with the browsers to see if they are willing to
align to the spec on issue #6542 (text-align: match-parent on the
root element with direction: rtl doesn't match browsers). If the
browsers have specific reasons to not conform to the spec the
group will consider changing the spec.
CSS Color 5 & Images 4
----------------------
- The features listed in issue #7310 (Are these features ready to
ship?) are not ready to ship yet, but there is interest in
prioritizing them to become ready to ship.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022May/0008.html
Present:
Rossen Atanassov
Tab Atkins Bittner
David Baron
Oriol Brufau
Daniel Clark
Emilio Cobos Álvarez
Elika Etemad
Robert Flack
Simon Fraser
Mason Freed
Chris Harrelson
Daniel Holbert
Brian Kardell
Brad Kemper
Jonathan Kew
Ian Kilpatrick
Daniel Libby
Peter Linss
Alison Maher
Ben Mathwig
Florian Rivoal
Jen Simmons
Alan Stearns
Miriam Suzanne
Scribe: TabAtkins
TPAC & Longform Meetings
========================
astearns: Administrivia, need to decide what times we're going to
meet for TPAC
astearns: Two options on the private list
astearns: Have to give the meeting organizers a preference by end of
month
astearns: If I don't hear strong opinions we'll probably default to
our standard, two long days Mon-Tue
astearns: If any prefs or other suggestions, please respond on the
list
astearns: Second, our agenda is getting long again
astearns: A bunch of interrelated issues in Selectors 4 that have
been tagged
astearns: Should probably have a breakout session on those issues,
there's enough to fill a meeting
astearns: I suggest next week we have the normal time meeting, and
also have a Selectors 4 meeting at the European time
astearns: If anyone has an objection to two meeting in a day, lmk,
otherwise that's the plan
<TabAtkins> Sounds good.
<TabAtkins> I'm available next week, but *not* the week following, if
timing is adjusted.
plinss: I'm not available that time next week, and are interested in
being present
<plinss> you can do the selectors breakout without me...
astearns: Third, some people have suggested before TPAC we should
have a hybrid longform meeting that would include getting a
few people together in person
astearns: If anyone's interested in that, we should start a thread on
the private list and/or the meeting planning pages on the
wiki
astearns: Could probably meet somewhere in NA, anyone interested in
traveling could meet, but we'd need a venue with very good
remote capabilities.
astearns: So if there's interest, let's please talk about it.
astearns: Any other admin topics, or agenda changes?
Anchor Positioning
==================
scribe: fantasai
Introduce CSS Anchor Positioning
--------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7282
iank: Quite a lot of interest in positioning an element relative to
another element in the DOM
<astearns> explainer:
https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/CSSAnchoredPositioning/explainer.md
iank: What we're proposing here isn't a new idea, people have had
variants of this idea for over 10 years
iank: a post on Tab's blog in 2012, etc.
<TabAtkins> (the old post: https://www.xanthir.com/blog/b48H0)
iank: This is basically an extension to absolute and fixed positioning
iank: in that we can set the inset properties, left/right/top/bottom
iank: and interpret that relative to another element
iank: We've got a prototype of this, and found it to be pretty
powerful
iank: you can create popups with this, all sorts of things
iank: Tab's written up a basic spec for this, with details of how
application works, how this modifies the abspos/fixedpos scheme
iank: and how also the rectangles propagate
iank: Couple of interesting point in that one thing we think is ?? is
that when you propagate up the positions of the anchor elements
iank: we think it should roughly follow the same propagation as
static elements, in that it ignores transforms and ???
iank: So that you can still have composited text and not affect
layout (?)
iank: I think that's roughly it
TabAtkins: There's a limitation on which elements can be targeted
with anchor
iank: Roughly speaking, abspos/fixedpos happens right at the end of
laying out a container, so you already know where all your
in-flow children are
iank: you get some really nice properties if you restrict it to
elements within that containing block subtree
iank: [missed]
iank: When we get to abspos/fixedpos positioning, you can reference
things that we already know where they are
iank: The other thing is @position-set
iank: When you examine the popup/anchor use-cases, necessary to be
able to say "I don't fit in this position, I'd like to try an
alternate position"
iank: So you might want to be on the right of the anchor, but if
there isn't space I"d like to be below, or the left. That's \
what @position-set is for
iank: @position-set lets you specify @try blocks setting top/left
etc, and if those don't work (cause overflow) we advance to the
next @try and use those instead.
TabAtkins: Possibility of exponential explosion in layouts when you
have chained anchors means we want to impose a strict
limit on how many @try blocks can be used
Rossen: Generally I'm favorable to the scenario and the overall
approach
Rossen: Couple of questions not clear to me, if I heard you right,
you said that you can anchor yourself to any other element's
box
iank: In the containing block subtree that's already being positioned
iank: abspos/fixedpos has its containing block
iank: Anything that has already been positioned within that
containing block subtree
iank: so you can't reference something further up the DOM
<astearns> which is an *ancestor* in the containing block subtree
<TabAtkins> See
https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element
for details
Rossen: This was exactly my question here
Rossen: and think it's really important in order to prevent some of
the really circular dependencies
Rossen: Question is still, is the assumption that such element will
not contribute to the overall bounds of the containing block
iank: Right, this will only apply to abspos/fixedpos elements
iank: So they won't change the containing block size
<TabAtkins> (but presumably would change scrollable overflow area)
Rossen: This feature you describe is almost exactly the feature we
proposed called "position: float" or something like that
Rossen: except that you're anchoring to elements, not allowing the
rest of the positioning constructs to apply
Rossen: My question was answered, you're basically scoping the
anchoring to the containing block, which makes a lot of sense
Rossen: Only other question is, you can affect scroll bounds for your
containing block still, even for those elements?
iank: Yes
Rossen: So behave like normal abspos
iank: Yes
iank: You're right that you need to make the scrollbars predictable,
but this isn't a new problem
Rossen: Not different than if just an abspos
Rossen: Last bit, are you scoping only to anchoring, or anchoring
plus... can I say anchor me next to the left border + some
offset?
iank: These anchor queries you can use in a calculation expression
iank: so you can do calc(this + this)
iank: We had some fun with our happy prototype, where you could do
minimum of this anchor's left and this other anchor's left
smfr: Is there potential for circular references?
iank: We want to avoid exactly that
iank: so anchor-positioned things assigned to the same containing
block can't reference each other
<iank> https://tabatkins.github.io/specs/css-anchor-position/#target-anchor-element
iank: Tab's got all the rules written down in the spec
TabAtkins: Very certain not a problem
<chrishtr> Anchoring can only apply *down* the containing block
chain, which makes it clear that there are no cycles.
smfr: Because constrained to something in the containing block, if
authors want a global ability they'd have to anchor ...?
iank: Have to use fixedpos or something like that
TabAtkins: No need to reparent, because fixedpos containing block is
the ICB
smfr: ...
iank: But then there's things where you want it to work more locally
iank: There's also a proposal which is related to adjusting the
scroll position
iank: but that's separate from this
dholbert: I was wondering, seems like it's ID-based right now, I
wonder if that could be ... how do you imagine using this
if you want to have multiple in a single page?
TabAtkins: Where are you seeing this?
dholbert: Looking at explainer
TabAtkins: Ah, MS explainer is earlier draft
TabAtkins: look at this spec
TabAtkins: We use the anchor-name property, look for the first thing
in tree space with that name
<astearns> ah, I only read the explainer - not the spec yet :)
dholbert: Okay
iank: We've got some flexibility in how we do that
iank: I personally like anchor-name solution
iank: requirement is reference things within this containing block
subtree
fantasai: Whatever scoping rules we use here we should be consistent
with scroll animations, which has a similar named
attachment method
<fantasai> (and vice versa, they're both early proposals so we switch
to whatever's the best method for both)
astearns: Suggest to read the spec and fiddle with details in the spec
iank: If anyone wants to play with the prototype lmk
TabAtkins: We anticipate asking for ED soon-ish, not just yet
TabAtkins: so keep informed
astearns: I assume there'll be some discussion in your personal repo
for awhile, but if significant changes or questions raised,
might be good to update the issue we have on introducing
this
astearns: so people can follow along without following your repo
TabAtkins: Happy to track issues in both repos
TabAtkins: and move issues later
fantasai: Why not move it now?
TabAtkins: No particular reason
fantasai: better to move now then, your private repo isn't backed up
by W3C
astearns: Let's give people time to review
<TabAtkins> The scoping rules for anchor-name are just "the subtree
that is allowed to contribute an anchor due to the
positioning rules", which may or may not match up with
what scroll animations exactly want
CSS Text Decor 4
================
Composition of inset shadows
----------------------------
github: https://github.com/w3c/csswg-drafts/issues/7251
fantasai: I wanted to ask what we should do with inset shadows -
what's their stacking order wrt stroke?
fantasai: Expectation is probably that it's between fill and stroke
fantasai: But then are we compositing the text decorations with their
text before shadowing? If so we can't layer shadows between
fantasai: You'd have to shadow each letter and decoration
independently to do that
smfr: Issue says Chrome and Firefox have somewhat surprising
behavior, so [...missed]
fantasai: Sebastian said "from author's perspective, expect inset
between fill and stroke", but outsets should be below both,
so that would require them to be treated differently.
fantasai: If you have a semi-transparent shadow on text with spread/
blur, don't think you'd expect it to be darker where
letters are near each other - you'd want them to be
shadowed as a whole. That requires compositing text *then*
shadowing.
fantasai: We might not have an answer today, just wanted thoughts on
it.
astearns: If we don't have opinions from the surprising-behavior
browsers, do we know who to ask? Is there a Blink engineer
we could talk about?
emilio: What's webkit behavior?
fantasai: Less interested in current behavior, want to know what we
actually want. Changing now isn't going to be a compat
question, as we don't have inset shadows yet, and the
behavior changes are subtle for outsets anyway (but real)
fantasai: So question is what authors want, what's possible to
implement, and what's the intersection of those two.
astearns: So I suggest we come up with that definition so impls have
something to chew on
astearns: I think you have the outline of possibilities, but not yet
a firm decision on what authors would prefer
fantasai: Right, it's just me and sebastian
smfr: Is there prior art in InDesign or similar?
astearns: I could go take a look
astearns: This is not anything I've looked at before tho, not sure if
Photoshop/etc behavior is necessarily what we want. I'll
take an action to go look.
fantasai: Might be interesting to ask people on those teams, who have
probably thought about it
smfr: I'd like to see some more artistic examples rendered with
Chrome and Firefox in the issue, to show the bad behavior more
clearly
astearns: So let's take back to the issue and get more clarity on
what we want to specify here.
astearns: And I'll take an action to see if I can divine any intent
from my company's tooling
Text shadow spread corners
--------------------------
github: https://github.com/w3c/csswg-drafts/issues/7250
smfr: Issue here is that when you specify spread on a text shadow,
the only way UA can implement is by stroking a line with a
wider width and shadowing the result.
smfr: That has implications for corners and miters
smfr: So we need impl experience, need to implement spread on text
shadow and see if there are any problems, not sure if there are
right now.
astearns: I remember we specified increasing the padding of shapes to
avoid these kind of spikes
astearns: Do you think having a similar algo for shadows might make
sense?
smfr: Would have to see what that algo is
smfr: Concern is that the font might be the one to specify the miter
limit, but I don't think it does
smfr: If you have a path, maybe the UA can decide the miter limit
when drawing the path. Just want confirmation that it's
implementable.
astearns: Anyone with opinions, or people we shoudl tag?
<TabAtkins> Without examples of what's up, no opinion here since I
don't have enough context.
fantasai: I'm happy to leave it undefined, just want to know what to
put in the spec.
astearns: Lacking opinions, think we should leave it undefined
smfr: Might be okay to specify you get rounded corners. If we find
it's impossible we can come back to it
fantasai: Might be opinions on better ways to do it, looking at
miter-limit prop or whatever.
fantasai: Think I specced it as rounded corners because, at the time,
seemed easiest to implement.
<astearns> shape-margin solution:
https://drafts.csswg.org/css-shapes-1/#shape-margin-property
astearns: So maybe see if that's an implementable thing for shadows.
smfr: Think it might be a little more complex than that description.
Prefer to have it specified the way impls would do it, which is
to stroke a path with a wide stroke width and use that edge to
shadow
astearns: I think there was an issue about shape-margin property too;
if there's a better way to specify we can do it in both
places
astearns: I was trying in that section to be slightly vague to not
restrict the particular algo
smfr: Briefly playing with it, sometimes in some fonts you'd get a
hole due to winding rules.
smfr: Reason for impl experience, fonts have weird data.
fantasai: So maybe we just make it undefined for now, and can define
it with more impl experience
smfr: Fine with that.
astearns: proposed resolution is to leave it undefined for now, open
to specifying it with experience later
RESOLVED: Leave text-shadow spread details undefined right now, with
possibility of specification later after impl experience
CSS Text
========
Make U+0000 invisible?
----------------------
github: https://github.com/w3c/csswg-drafts/issues/7249
fantasai: Do we have Myles and jfkthame on the call?
astearns: Have jfkthame, not Myles
smfr: Can probably speak for Myles
astearns: So we had previous resolution to make all the CC characters
visible
smfr: We had an issue on one Apple website, the text had U+0000 bytes
in it
smfr: I'm guessing it's not *that* uncommon to have 0 bytes by
mistake, due to server bugs? But we'd probably be okay with no
change.
astearns: So you're suggesting close no change, and continue to
specify they're displayed?
smfr: Think that's okay unless we have evidence the problem is more
widespread.
emilio: I don't recall seeing issues with this in Nightly/Beta and
we've had it for a long time
jfkthame: Also think we should ship it. Do occasionally see
characters show up in Nightly that are invisible elsewhere,
but it's rare.
jfkthame: And in all cases the users are better served by sites
fixing their broken data
fantasai: We'd previously discussed doing a coordinated ship of this
behavior - that was years ago, guess this didn't happen?
florian: Think we prepped coordinating but didn't pull the trigger.
florian: Firefox impl'd, Chrome impl'd partially (but leaves it to
the font to render), Safari didn't impl.
astearns: But I think we can agree to resolve on this issue.
astearns: Any objections to no change on rendering of U+0000?
RESOLVED: No change
astearns: What can we do to coordinate making this part of the spec
interoperable?
jfkthame: Think we need Blink to fix impl to not depend on the font's
rendering.
astearns: Do we know if there's a blink issue?
jfkthame: There is, don't have it offhand
<fantasai> Maybe send that issue link to chrishtr and he can
coordinate?
<TabAtkins> Yes, chrishtr is the right contact for coordinating this
astearns: Suggest we find the issue number and post it here, see if
we can get a response from Blink engineers
smfr: We might be in a similar situation to Blink where it depends on
the font, not sure
smfr: But this seems rare enough that I don't think coordinating
shipping is necessary, seems hard to do for us in WebKit anyway
fantasai: I think we should open a separate issue for the coordination
astearns: So we can close this issue with the resolution we got, and
continue coordination discussion later on.
text-align: match-parent on the root element with direction: rtl
doesn't match browsers
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6542
florian: match-parent on text-align does as the name implies, matches
the parent's alignment
florian: Different form just inheriting, as the meaning of start and
end might have switched if the direction switches. With
match-parent it doesn't flip, it definitely matches the
parent
florian: So the question is what to do on the root. The spec has an
answer that I think makes sense, but doesn't have interop.
florian: But not sure I'm aware of significant real problems
triggered by this, so if we have a sensible behavior in the
spec that doesn't cause real issues I think it's okay to
leave it as-is and consider non-compliance a bug, but
zcorpan didn't see it that way
fantasai: zcorpan wanted us to either change the spec to match impls,
or get a commitment from browser engines that they want to
fix this bug
fantasai: My personal take is that this is a very low-priority fix,
but it should be considered a bug so when someone is fixing
that area of the code they could fix it too.
fantasai: Don't think we should require anyone to prioritize fixing
it. Super low priority, possibly lowest priority I've ever
seen. But don't think we should change the spec, I think
the spec is more correct.
astearns: Assume there's not bugs filed on this?
florian: Not sure.
astearns: So part of zcorpan's request is to get bugs filed. I agree
with him.
fantasai: I can take an action to make sure bugs are filed.
astearns: And once bugs are filed, we'll see if we can get evals from
impls on the bugs themselves.
astearns: But like fantasai said, don't think a timely fix is
strictly required for this.
fantasai: Well is it okay to close the bug, with the understanding
that we have bugs filed and impls plan to fix it at some
point?
astearns: Right, let's file the bugs and get to the next part
emilio: Gecko behavior here is intentional. I'd need to investigate
why it's a special case, I didn't write the code.
florian: That's relevant, if browsers have specific reasons for
differing from the spec it would be good to report so we can
see if the spec should reflect that. But if it's just
accidental we should know that too, so we can be confident
of keeping the current spec.
astearns: So next step is writing bugs.
CSS Color 5 & Images 4
======================
Color functions and RCS: Are these features ready to ship?
----------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/7310
jensimmons: These are all part of Interop2022, are they ready to
ship? Are specs good enough, or are they unstable?
emilio: I'd love to ship some of these, but there's a lot of open
questions
emilio: I don't think there's any complete impl of these features.
emilio: WebKit implements a bunch, but doesn't support currentColor
at all. Gecko also has trouble with currentColor.
emilio: There's some question about resolution timing that I filed
last week.
emilio: So don't think things are quite ready to ship yet.
jensimmons: So question really is if the spec is gonna significantly
change after shipping happens.
jensimmons: I think your issue highlights that some things still need
to be defined. Maybe we can make this a priority to
finish the spec?
emilio: Think that would be great. Haven't been working actively,
been spending free time on it.
emilio: I can tell from Firefox usage - we enabled color-mix() in
trunk and it's used extensively, over a thousand uses
immediately.
emilio: So I think it would be great to prioritize.
astearns: So we're at time, please put your thoughts in that issue.
astearns: Agree I'd like to see one complete impl before making the
decision that it's shippable.
fantasai: Sounds like this isn't ready to ship *yet*, but we should
try to get it there soon.
emilio: What I'd love is to avoid interdependencies on these features.
emilio: weinig commented that they'd prefer color-mix() to serialize
with new color syntaxes unconditionally; I'm not opposed to
that, but it requires us to have new colors to ship
color-mix(). Makes me a little sad because it's more work to
get this in the hands of authors, but they feel strongly
about that.
emilio: It'd be great to work out a way to minimize interdependencies
so we can ship incrementally.
<emilio> thanks for bringing this up jensimmons :)
astearns: Please discuss on the list about the meeting next week.
Received on Wednesday, 25 May 2022 21:41:00 UTC