- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Feb 2022 06:37:26 -0500
- 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.
=========================================
Backgrounds and Borders 4
-------------------------
- RESOLVED: Add Sebastian as co-editor to backgrounds and borders 4
CSS Ruby
--------
- RESOLVED: Writing mode of a ruby annotation is forced to vertical
rl if the parent ruby position is inter-character (Issue
#1773: Propose to treat rtc with orthogonal writing-mode
to be inter-character rather than using ruby-position)
CSS Inline & Pseudo
-------------------
- RESOLVED: Root inline box is inside all the ::first-line pseudo
elements (Issue #1384: Interaction of root inline box and
::first-line)
CSS Contain
-----------
- RESOLVED: Allow static range backed custom highlights to be painted
across paint contain boundaries (Issue #4598: Static
ranges and css-contain)
- RESOLVED: Accept proposal to in all cases use originating element
(Issues #5984 (CQ vs shadow boundaries) and #6711
(Container Queries and pseudo elements))
CSS Overflow & Scroll Snap
--------------------------
- RESOLVED: Accept the proposal for scroll-start and add to scroll
snap L2 (Issue #6986: Proposing scroll-start: allowing
overflow scroll to not always start at 0 on 1st layout
pass)
- RESOLVED: Add argyle as a co-editor of scroll snap L2
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2022Feb/0000.html
Present:
Adam Argyle
Rossen Atanassov
Tab Atkins Bittner
David Baron
Oriol Brufau
Daniel Clark
Bo Cupp
Elika Etemad
Robert Flack
Chris Harrelson
Daniel Holbert
Dael Jackson
Rune Lillesveen
Ting-Yu Lin
Peter Linss
Alison Maher
Cameron McCormack
Alan Stearns
Miriam Suzanne
Zheng Xu
Regrets:
Jonathan Kew
Una Kravets
Scribe: dael
astearns: I assume you saw the request to possibly skip items 4 and 5
Rossen: I did
Rossen: I think we have enough folks but I don't see florian
miriam: I was confusing 4 with a different one. We can delay 5
without delaying 4
Rossen: I saw your note and I lumped together related issues. Happy
to rearrange
Rossen: We can get going
Rossen: Welcome
Rossen: Any agenda items you want me to change in the current agenda?
Rossen: Plenty of overflow so won't run out of topics
Rossen: Let me know if there's something we should skip
Backgrounds and Borders 4
=========================
fantasai: Quick, propose Sebastian as co-editor of backgrounds and
borders 4
Rossen: Objections?
RESOLVED: Add Sebastian as co-editor to backgrounds and borders 4
Rossen: miriam feel free to tell me which to skip. I think you're
talking about 4 and 5
miriam: Only skip 5
Rossen: Other changes?
CSS Ruby
========
Propose to treat rtc with orthogonal writing-mode to be
inter-character rather than using ruby-position
-------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1773
<fantasai> proposal at
https://github.com/w3c/csswg-drafts/issues/1773#issuecomment-775694005
fantasai: I figured we would go over proposal and decide if we want
to accept
fantasai: Proposal is here ^
fantasai: It's that writing mode of ruby annotation computes to
vertical rl if the ruby position of parent is
inter-character
fantasai: Type of ruby that goes down side of element. Picture link
<fantasai> https://www.w3.org/TR/css-ruby-1/#ruby-position-inter-character-annotation
fantasai: No matter text they're always on right and always top to
bottom
fantasai: Had difficulties to get writing mode and ruby position to
interact. Proposal is to use the ruby position of the
annotation container rather than annotation because
container easier to look up
fantasai: Proposing that if this box is a ruby annotation and it's
parent, annotation container, is inter-character the
writing mode of this box computes to rl
fantasai: Odd cases you can get into. For example, set
inter-character and have anonymous boxes.
fantasai: For the most part think works in most cases
fantasai: Proposal to change spec to say this. Want to ask if there
are concerns or a better solution
florian: Xidorn finds that it would work. That was encouraging, but
about a year ago
fantasai: Don't have to resolve today but should resolve
iank: All this means is that for computing writing mode we depend on
the tag name and the parent style if it has interstyle set?
fantasai: Did you say tag name?
iank: Just the display of the box?
fantasai: Display of box and parent
iank: Okay. Seems fine from style adjuster
florian: Interaction slightly annoying, but no loops
Rossen: Other opinions or questions?
Rossen: I prefer if we try and have a resolution here. Even if we
have to revisit later
florian: Would be nice if spec could have latest thinking. Can always
speak again
Rossen: It's been a year and no other suggestions put forward. This
will be good forcing function
Rossen: Treating rtc with orthogonal writing mode to be
inter-character?
fantasai: Prop: Writing mode of a ruby annotation is forced to
vertical rl if the parent ruby position is inter-character
Rossen: Objections?
RESOLVED: Writing mode of a ruby annotation is forced to vertical rl
if the parent ruby position is inter-character
CSS Inline & Pseudo
===================
Interaction of root inline box and ::first-line
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1384
oriol: I can explain unless florian prefers
oriol: The idea is that in css 2 we had concept of the strat that
forced the line height to be at least the value of the line
height in block container
oriol: Replaced with root inline box, but not clear how that
interacts with first line. Root inline is anonymous inline box
that contains inline level contents in first line.
oriol: The first line is behaving as an inline level is it inside the
root inline box? Inside the first line pseudo?
oriol: This was more theoretical but had practical implication we
resolved in issue 2282
oriol: There resolved in first line pseudo element you can set line
height to a value smaller than in block. This should reduce it.
oriol: Implication of this is that first-line pseudo element cannot
be inside root inline box. Has to be the opposite
oriol: Then florian proposed that what we could do is unify the boxes
and say first-line pseudo is exactly the fragment of the root
inline box in the first line. Don't think this works because
can have multiple first line pseudo elements
oriol: At most what we could do is innermost is the frag of the root
inline box. Otherwise we do need nesting
oriol: Only possibility we have is that the fragment of the root
inline box is inside the innermost or it's equal to innermost
florian: Makes sense. My proposal was because it seemed simpler but
you have a case where makes a difference. Given that we're
left with one possibility and go with that
fantasai: Proposal: root inline box is inside all the first line
pseudo elements?
oriol: Yeah
Rossen: Other opinions?
Rossen: Objections?
RESOLVED: root inline box is inside all the ::first-line pseudo
elements
CSS Contain
===========
Static ranges and css-contain
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/4598
dandclark: This is a issue regarding if custom highlights backed by
static range should paint of cross boundaries
<dandclark> Proposed resolution: Allow static-range-backed custom
highlights to be painted across paint-contain boundaries.
dandclark: Would like to allow static range backed to be painted
across boundaries. Think it's better user and dev
experience. For user won't have issues when things
disappear when crossing arbitrary boundaries
dandclark: TabAtkins had point that this is outside of what paint
contain requires. If element is offscreen you can skip
painting. This doesn't follow the definition. Skipping
offscreen we would not break
dandclark: Did due diligence in chromium. We believe optimizations
lost would be minor since we would just need to do
validity checks. When painting we invalidate all nodes and
can still skip when doing painting step if offscreen
dandclark: Overall the pros outweigh the cons
<sanketj> SGTM
florian: I've been convinced I'm wrong. Thank you for doing the
diligence to give me confidence in the solution
Rossen: Any others who were in florian's camp?
Rossen: Proposal?
dandclark: Allow static range backed custom highlights to be painted
across paint contain boundaries
Rossen: Objections?
RESOLVED: Allow static range backed custom highlights to be painted
across paint contain boundaries
Container Queries and pseudo elements
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6711
futhark: I wanted to take issues 4 & 6 at same time. Have proposal
for both
futhark: Easy to explain for pseudo elements. When on selectors the
originating element is closest query container
futhark: Spec currently doesn't say anything about pseudo elements
futhark: For issue with shadow dom property is establish query
container as the shadow including and having the originating
element of the select be the first one poss to query
futhark: Proposal is in the shadow dom issue for that
futhark: There's the explanation for how this fits with slotted,
before, after, etc
<miriam> this comment:
https://github.com/w3c/csswg-drafts/issues/5984#issuecomment-980694443
futhark: TabAtkins do you have a better way to explain?
TabAtkins: All in all 3 cases to worry about. First is ordinary tree
abiding ::before and ::after. That's simple, originating
element. Act like they're children already
TabAtkins: 2nd is shadow dom like ::part. Refers to element in
shadow, but originates in host. If there are query
containers between them will they be seen? We believe no
because would expose internal details of the shadow.
TabAtkins: If users want to query on the dom they see, they won't get
that
TabAtkins: Again use originating element
TabAtkins: Final is non-tree like ::first-line and ::first-letter.
TabAtkins: Example where div for first-letter is used. Actual markup
is a <p> that's a query container. I think again this is
not seen because otherwise exposes where in the tree the
non-abiding pseudo is. We've keep them away from answering
for various reasons
TabAtkins: By saying for purpose of query containers we use the
originating element and skip the <p> it's nice and simple
TabAtkins: In all cases use originating element. Straightforward and
easy to understand
fantasai: I think proposal makes sense.
futhark: One thing not sure about is multiple pseudo. What's the
originating div before marker. Is the originating of the
marker before?
futhark: Attempted to spec final originating element
fantasai: Yes. Term is ultimate originating element
TabAtkins: And agree that's what we want to use
Rossen: Hearing agreement
Rossen: Anything we're missing here? Other opinions?
Rossen: Obj to accept this proposal?
RESOLVED: Accept proposal to in all cases use originating element
miriam: Skip issue 5, we've covered 6. futhark talked about proposal
in 6. Separate resolution?
futhark: Explanation from TabAtkins was on issue 6.
CQ vs shadow boundaries
-----------------------
github: https://github.com/w3c/csswg-drafts/issues/5984
RESOLVED: Accept proposal to in all cases use originating element
CSS Conditional
===============
Rename @when to @if
-------------------
TabAtkins: Opened by leaverou
TabAtkins: Should we push?
Rossen: agree
CSS Overflow
============
Proposing scroll-start: allowing overflow scroll to not always start
at 0 on 1st layout pass
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6986
argyle: Goal, we did survey asking devs about experience in scroll.
Starting to write explainers
argyle: Scroll-start has overlap with fragment navigation
conceptually. But that is more magical because has more work
to do and integrations to things like page refresh
argyle: This wants to bring a portion of that power to move someone.
Example is tabs to swipe between and want to start on a
midway tab so it lays-out at that tab
argyle: All solutions to do this now take extra time and additional
work
argyle: Tucking a search bar above the fold is common. Spotify does
this where you don't see search until you scroll up
argyle: Proposal is advocating for way to do that in css using links
as default. scroll-start 20px from top. Could also use %
argyle: This would only apply if fragment navigation isn't used and
user hasn't interacted with scroll. Waiting for it to go
through a check listed in explainer to make sure it's
untouched
argyle: If so on first layout layout at this position
argyle: Adds scroll-start:target which is where you can have a child
as a target for scroll. Akin to scroll-snap where you can
snap on first layout. But after that you can't scroll anywhere
argyle: People hack around this by setting a keyframe. Have a snap
child, wait a keyframe, and then remove an animation to
remove the snap so you can move
argyle: Offering something simple for this
argyle: Property on the child where child in scroll container says
snap to me if user hasn't interacted with page
argyle: Additional details in the proposal, but how is that for a
first pass?
smfr: I like proposal. Useful functionality. Like that it's
element-based target
smfr: Question is if we can define first layout pass. If page toggles
display none and then goes back does that trigger first layout?
If the layout tree is destroyed is that first layout?
argyle: Nice. I hadn't articulated the proper timing. Makes sense as
a request for the explainer. Thank you
fantasai: I think the idea of doing this makes a lot of sense.
fantasai: Being able to choose and element and have it be focus makes
sense
fantasai: Agree with TabAtkins's comment in the issue it should be
property on element not scroll container
fantasai: Have a similar problem with baseline alignment and aligning
to child. 1339 issue
fantasai: Should make them consistent in how they lookup
fantasai: Makes sense overall and I support working on it
argyle: So in favor of child property but don't agree with scroll
port property of scroll-start?
fantasai: Not sure if we need opt in for scroller, but scroller
shouldn't pick position
argyle: Absolutely
fantasai: In terms of figuring out how element aligns in port we
should reuse snap. I think alignment question is handled by
scroll-snap. You do have question of first or last element
that qualifies
fantasai: Another interaction, content alignment can effect initial
scroll position. Have to figure out how that interacts
argyle: Thank you. Taken notes
argyle: In explainer does say if parent and child both have or
multiple children have snap target it has how to resolve.
Currently first in dom
fantasai: Good answer. First in dom makes a lot of sense. Want to
think about if an element can block it's children from
participating in that
argyle: Thank you
heycam: Wondering what should happen when the page is loading slowly
or content is added to scroll container and first layout
happens before target offset is reached. Keep reevaluating to
determine if we do a scroll until condition is met?
<dbaron> Not just lazy addition from script, but also a large page
that does the first layout of the container when only some
of its content has been loaded.
argyle: Current mentality is this is easy to interrupt. It's a
request. In case of something being lazy I would assume...say
it's scroll-start:left 200px. If it did first layout and
nothing has happened I would say if a scroll-start shows up
later it's ignored. Scroll position is set
heycam: A little worried authors would test on fast connection, get
desired behavior, and then publish and scroll position isn't
updated so looks weird
fantasai: I think we should use logic for scrolling to :target and
this would be the feature defining how that works
TabAtkins: Going to say the same
<dbaron> The logic for scrolling to targeted elements isn't very good
-- I really wanted to try to improve it about 15 years ago
but never got around to it. :-/
argyle: And point of this is prevent jank and be there first. Misses
it's mark if containing scroll port has been created and
there's no children.
argyle: I'm assuming Java is appending, but maybe even a really long
document. I'm inclined to say trying to prevent jank and we
want to do it all before a user sees it
iank: It's possible that your html can slowly trickle in. I think
that's heycam slow connection
flackr: I wanted to reply to smfr and heycam points. In my mind see
this as substitute for assumed 0 default scroll. So should
reapply any time we would start at position 0. Probably not
same as fragment navigation because that waits
flackr: For css any time something introduced with scroll it
shouldn't jump
flackr: When an element becomes a scroll container we should look for
this and jump to that unless doing other fragment navigation
<TabAtkins> +1 to flackr's points
dbaron: Related to what flackr just said. My opinion is fragment
navigation is not very good. Had plan to fix around 2007 but
kept postponing
dbaron: Thing that happened 3 or 4 years ago that had some
improvements. I would have liked to see fragment navigation
try to scroll to fragment more frequently and have a state to
say if it should keep trying
dbaron: Not what happened and might not be web compat
dbaron: Maybe doing same as fragment navigation is okay, but I think
it's not that great and could be better for users
chrishtr: Had a thought similar to flackr and others. What if instead
of spec some default offset you spec what scroll anchor
target is at the beginning. And that remains until user
does something. If page takes a while to load browser knows
what target should be and as it loads browser centers it on
screen
<fantasai> +1 to not specifying an offset; should choose an element,
and align it based on properties in css-scroll-snap
argyle: Sounds interesting. Sound like overlap with scroll-start
target. Maybe target should behave as described
fantasai: I think if we go with idea that scroll-snap-target aligns
the same as scroll snap properties. Scroll padding and
margin and align can determine the position. I think that
should handle the offsets. Not sure there's a use case for
offset at start not being the same as if you were targeting
to the element
<iank> What about for a large <canvas> within a scroller where you
don't have an element to target?
argyle: Hearing advocacy for scroll-start:target and no scroll-start
because in general want to scroll an item into view
argyle: There are people that wanted keywords or end and center that
are 100% or 50%
argyle: See what you're saying that length would be less used.
argyle: Does seem like it should be an offering. Like I know my
header is 50 px and what to be under that
<TabAtkins> Agree we *sometimes* want an explicit offset.
<smfr> maybe this should also cover the “always scrolled to the
bottom“ case for chats etc
fantasai: You want to target the thing under the heading so that you
can change the font on your heading and have it still work
fantasai: You can already to top of bottom with align content
TabAtkins: There's a use case in chat where you can't do offset.
Large canvas in a scroller
fantasai: Can see that. Can also see if doing fancy with canvas you
want to define snap areas. More to be done with canvas
<chrishtr> Re large canvas: there should be a way to specify a
position relative to that element
argyle: Another is shopping where image takes up show screen. Start
with that in center and then you can pan.
fantasai: I believe align content is defined to do that
<fantasai> https://www.w3.org/TR/css-align-3/#overflow-scroll-position
Rossen: Seems like have positive consensus to adopt this proposal
Rossen: Sure, there are details to work out
Rossen: I see smfr is adding some of those to the issue
Rossen: Assuming you're looking for resolution to adopt?
argyle: Correct. Want way forward to prototype. Have demos and stuff
for scroll-snap we're hoping to add scroll-start
fantasai: My recommendation to draft this as scroll snap level 2.
it's going to work closely with properties to determine
position
Rossen: Prop 1: Accept the proposal for scroll-start and add to
scroll snap L2
Rossen: Objections?
fantasai: No objection but would like to hold off on adding the
offset and start with the element. Should look at use cases
Rossen: If we have this in its own draft much easier to tease out
issues
Rossen: Didn't hear objections
RESOLVED: Accept the proposal for scroll-start and add to scroll
snap L2
Rossen: Question 2, who will do this? Do we need to add argyle as an
editor?
TabAtkins: Good idea if he's okay
argyle: Happy to join in
Rossen: Objections to add argyle as a co-editor of scroll snap l2?
RESOLVED: Add argyle as a co-editor of scroll snap L2
argyle: Plenty more to come
Rossen: We're at the top of the hour. Plenty of issues for next week
Rossen: Thank you for joining us and we'll chat next Wednesday
Received on Thursday, 3 February 2022 11:38:07 UTC