- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 May 2021 16:34:59 -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 Overflow
------------
- RESOLVED: Specify option 1; match FF current behavior [the
baseline is calculated the same as for visible] (Issue
#6212: Baseline of an inline-block with overflow:clip)
CSS Box
-------
- There was a strong leaning on the call to address having issue
#4708 (Increase pointer target size independently of element
layout) solved by browser behavior rather than having an
explicit property which can be set. Some more research needs to
be done on cases where current hit testing has issues, such as
buttons with rounded corners, before a decision can be reached.
CSS Contain
-----------
- RESOLVED: Have container MQ not resolve when there is no ancestor
container (Issue #6178: How does @container resolve when
no ancestor containers have been defined?)
- RESOLVED: If there is containment on body or root it stops
propagation from body to root (Issue #5913: :root/body
viewport propagation and containment)
- Within issue #6213 (Need style containment for container queries)
is a motivating use case to do style containment which was
previously missing. Given this new use case to handle counters
and quotations the issue of style containment will be brought
back up with those who previously objected to see if there's now
interest in addressing style containment.
CSS Fonts
---------
- RESOLVED: Start with ex, cap, ic, and ch (Issue #6160: Extend
font-size-adjust to take a pair of values: <metric>
<number>)
- A new issue will be opened to consider adding ascent and possibly
descent to the above list.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021May/0001.html
Present:
Rossen Atanassov
Elika Etemad
Simon Fraser
Megan Gardner
Daniel Holbert
Dael Jackson
Sanket Joshi
Daniel Libby
Ting-Yu Lin
Peter Linss
Ben Mathwig
Cameron McCormick
Myles Maxfield
Morgan Reschenberg
Florian Rivoal
Devin Rousso
Miriam Suzanne
Alan Stearns
Regrets:
Tab Atkins-Bittner
Jonathan Kew
Greg Whitworth
Scribe: dael
Future Meetings
===============
astearns: While we wait does anyone have suggested changes to the
agenda?
Rossen: Do we have any TPAC related things to discuss with the group?
Rossen: Joint meeting type things. It'll be sooner than later we
need to decide. Especially meet before or after TPAC
astearns: Nothing on the books. Suggestion from leaverou about both.
One a few weeks before and one a few weeks after so we can
prepare for joint meetings and then respond to anything
coming out
astearns: That makes sense to me. Other opinions?
Rossen: Sounds good to me as well. Sandwiching TPAC. Hopefully won't
touch with other WG meetings, TAG, AC, and other acronyms.
astearns: Do you know TAG dates? We have a bunch of people on it
Rossen: Try to do TPAC directly. One week before? Right around ABE
time since want to have joint meeting
astearns: We should get going. I'll put a proposal for TPAC and next
long form meeting
astearns: We'll see what people think on the list
CSS Overflow
============
Baseline of an inline-block with overflow:clip
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6212
fantasai: 4 proposals in the issue as far as I can tell. 1. same as
visible even if baseline of clipped text
fantasai: 2. treat like overflow hidden and synthesize baseline
regardless of what's inside
fantasai: 3. use whatever visible text is there. If clipped or below
clipping point stop at clipping point
fantasai: 4. is same as 3 but instead of clamp to clipping area we
clamp to border area because that's how hidden behaves
iank: I think it's margin edge
iank: Unique thing here is inline box us by default last baseline.
Not like first for flex/grid. overflow:hidden if you didn't do
end margin you'd get a funny box
iank: Question is which. We treat like overflow hidden, Firefox
treats as visible
iank: [missed]
iank: Basically, Chrome went way of overflow:hidden for that reason
and adhering to css 3. Firefox went for overflow:visible
behavior. Merits to both. Slightly prefer ours a little
because if you have a lot of content and overflow:clip you'd
have things way off in linebox
fantasai: So long as there's visible content makes sense to align to
that visible content. One of the intentions is to not
trigger a bunch of layout. Line of content and extra room
for floating stuff which you clipped. Want to keep
alignment
fantasai: Clamp to padding edge might make sense because else
aligning to something can't see. overflow:clip to clip
anything outside, if there's content visible want to align
to that
iank: This is also somewhat an issue for last-baseline
fantasai: Also first-baseline
iank: Yes, rare case, but yes
fantasai: Makes sense for last and first baseline to be consistent.
First we want to align to first-baseline when it's visible
astearns: If we clamp to clip area or margin edge...if clip area
doesn't that give you layout changes based on clipping?
fantasai: We wanted to avoid it but idea you're aligning to
something invisible we also want to avoid. Which to avoid
more? clamping to visible makes sense
astearns: Thinking of animated where revealing and aligning to what
you can't see if what you want
fantasai: But in that case usually won't get clipped. Usually
overflowing content you want clipped or not overflow
fantasai: Dynamic visibility you probably don't want to reveal
content overflow
astearns: So option 4 is calculate same as visible but clamp to
margin edge?
fantasai: Yeah. Margin edge is a little weird. Border edge makes
more sense. Had an issue about margin or border earlier.
PDF raster and browsers are inconsistent.
fantasai: I would clamp to the clip edge which is padding edge
iank: Any other opinions? I'm weak on my opinion
florian: A little opinion. If we manage to get behavior that's
really author friendly let's do that. If we're kind of
author friendly but not really it's not worth another
slightly different variant. If we can land exactly what you
want you don't have to debug but elsewise concerned about
subtleties of this being different than other similar
properties
iank: Discovered on Firefox issue tracker and issue thinking Firefox
was wrong. One data point a webdev expected Chrome behavior.
But that's only one data point
fantasai: Pretty strong first baseline we should align to if
visible, even if clip. Makes sense for last to follow that
logic. If and where we clamp is more debatable
iank: Prefer not the clamping behavior. Just pick the baseline, even
if not visible or pick an edge
iank: One thing is people see overflow:clip as a drop in for
overflow:hidden. There's a weak argument to align to
overflow:hidden
smfr: Prefer a behavior such that baseline alignment is same as if
inline block had clip-path: inset(000)
fantasai: That's Firefox?
smfr: That's clip to the box
iank: Why?
smfr: In terms of layout and rendering I consider overflow:clip as
similar to clip-path. Doesn't have effects, but it's a clip
where I don't expect layout implications
fantasai: Fine with that
Rossen: I wanted to pull back on smfr comment and get clearer
picture in terms of behavior he would see in the attached
example from emilio. Would that be, smfr, closer to FF or
chromium?
smfr: Didn't examine. People said it's more like Firefox
Rossen: Which has layout implications
iank: Which does not
Rossen: I was on an older Firefox
astearns: Suggest we resolve to spec option 1, Firefox behavior,
since we have people in favor and iank only with weak
objection. See if we can take that to the bug reporter and
see if it makes sense to them
astearns: Can also talk to PDF reactor about if clamping behavior is
required or they could move to non-clamp
astearns: Proposal: Specify option 1; match FF current behavior
astearns: Objections?
RESOLVED: Specify option 1; match FF current behavior
scrollbar-gutter should not do anything for non-scrollable boxes
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6028
astearns: Discussed a few weeks ago. Hoping to see more on this
issue in GH. Do we think we can get to a resolution?
florian: We can try
fantasai: I think comments in other issue (Issue #4674) interrelate
astearns: Do the other first?
florian: I think largely same thing from different angle
fantasai: Is leaverou on?
astearns: I don't think so. Nor chrishtr
fantasai: Might make sense to defer until they can attend
astearns: Let's skip 2 and 4
CSS Box
=======
Increase pointer target size independently of element layout
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4708#issuecomment-588369114
fantasai: Posted a link to the comment with follow-up
fantasai: Last time had a question for the commenter about it being
a length or larger/normal/smaller
<fantasai> https://github.com/w3c/csswg-drafts/issues/4708#issuecomment-588451067
fantasai: Commenter responded ^
fantasai: Example of 2 buttons side by side and explaining author
would not be able to know distance. Not specify a length
larger. If we made it up to UA maybe there would be overlap
fantasai: That was a concern by the poster. Related, plinss
commented explaining what happens with 2 JS elements with
extended hit area. Don't want to cover another element.
Need more sophisticated logic than extending the hit area
fantasai: These points were brought up. Figured bring back to the
group for discussion on how to move forward
smfr: Question if we need this. Mobile browsers have something we
call area hit testing. When you hit test you look in area
around target that respond to events. One answer is UA should
do it automatically somehow
florian: Tempted to agree because how big hit area needs to be is
not something author can know. Depends on type of thing
used to click, finger or stylus. Ratio between css pixels
and layout. It's guesswork
florian: Probably UA is in better position
myles: Similar. If you pinch zoom finger to page changes. Anything
that's fixed is not right tool
iank: Trying to remember if we had this conversation. We had people
asking for this a while ago. Might be on us to circle back
with what they were after
astearns: Do you mean automatic for "this"
iank: Not auto. A fixed length. I think chrishtr was more involved.
I'm digging from my memory. But I don't think there's more we
can do
florian: Do all browsers do area hit testing or is it apple specific?
smfr: Pretty sure it's all mobile browsers. We do it on mobile WK. I
think Android has
iank: I believe we have similar. Not area of expertise
<fantasai> https://cloudfour.com/thinks/jagged-little-pill-issues-with-rounded-buttons/
fantasai: Illustration from issue ^ Someone writing about rounded
corners on buttons reducing click area and they wanted it
fixed. That's another consideration
fantasai: If we're seeing a lot of people doing this with hacks we
should build in. If browsers can do it automatically and
we don't need hacks that's idea
iank: Potential for that. I have heard border radius reducing hit
test. Argument for authors to opt out, particularly with large
rounded corner. Unlikely there will be other elements
iank: We likely should move on. Not sure how much more we can do on
this today
plinss: I'm in favor of leaving to UA. Might be worth specifying an
algorithm to get interop
astearns: That would start with defining hit testing
florian: I believe there's an action on me for years ago to put
something in spec. I don't think there's a good definition
of it, so it's not in spec
astearns: iank if you can dig up the request that would be great to
add to the issue
CSS Contain
===========
How does @container resolve when no ancestor containers have been
defined?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6178
miriam: Initial proposal was if not container as explicitly defined
we'd fall back. Root element or viewport. Some sort of
fallback for container queries so they always resolve
against something
miriam: Not convinced. When writing a container query assuming it's
close to actual size. Fallback to full viewport will be
dramatically wrong in a lot of cases. If authors are using
current best MQ best practice for smaller layouts inside
they get smaller fallback
<iank> a fallback to something random seems pretty bad to me.(?)
miriam: If can have containment on root you can make the choice
yourself. Popular to do, but risky fallback
miriam: We should not try and salvage container queries when there
is no container
iank: Agree. Sounds pretty hostile to fallback to something
unexpected
astearns: I voted for root in twitter but you have convinced me I
was wrong
astearns: Proposal is have MQ not do anything if no container to
measure against
miriam: Correct
florian: Reasonable
astearns: Objections to have container MQ not resolve when there is
no ancestor container
RESOLVED: Have container MQ not resolve when there is no ancestor
container
:root/body viewport propagation and containment
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5913
miriam: Not the one that raised this but Rune isn't here. Can't
speak for browser engineers. Seems like users that would
want to do containment at root. Would not like to disallow,
but he has a few other proposals
miriam: No strong feelings
iank: There's 3 solutions from propagating direction writing modes.
iank: The first is the giant hammer no one wants which is disallow
on body
iank: Second is when container queries apply we stop body
propagating up to viewport
iank: Third option is to do propagation but don't let it change
after that. Stuck at initial value
iank: Means if you have container query on html element and spec
body under 500px changes writing mode wouldn't work
iank: I think I prefer the 2nd option. When we have containment
applied we don't form propagation. However, 2 valid solutions
florian: Agree with iank. Propagating from body is for compat
reasons. In general containment is not an operation that
changes nothing. It changes layout because contains things.
Saying it contains propagation it's fine. If you need it on
the root, set it there
iank: Not allowing you to dynamically change those properties inside
container queries seems bad to 2nd
fantasai: 2nd is if you apply containment to root or body we don't
do body propagation but do from html root element
florian: If you do on body doesn't prop to root but can't contain
root
florian: No containment on root. On body is possible, but stops
propagate from body
fantasai: Does contain apply to root general?
florian: Not defined
fantasai: If it does it would make sense that would also block
propagation.
iank: Problematic case is html element then body. Put a container
query and the body can change style and propagate to root
fantasai: Yes, not allowed. Containment on root or body should block
body from propagation.
fantasai: Nothing should block root from propagating
fantasai: Assuming containment on root can be done. If it does not
apply if it blocks body no strong opinion
florian: Don't recall talking about containment on root.
miriam: It is a use case people want. Might be able to get close
with body containment. People are wanting the ability
florian: Can you explain why root?
miriam: I don't know people have thought through body or root. Main
case is you could adjust body based on root query. There is
a case to use a container query instead of MQ for viewport
because container lets you respond to actual font size and
dimensions rather than browser or user font size.
iank: Once people get their hands on container queries they won't
think about viewport MQs much anymore. They'll attach
container query to root to adjust viewport
fantasai: Given we're expecting containment to apply to root with an
effect of some kind it should also block body from
propagating
fantasai: Proposal: containment does not block root from
propagating, but it does block body
florian: Containment to the body makes sense. Still confused on root
fantasai: If containing the body and prevents propagation, why
wouldn't containing and ancestor block?
florian: Doing it on outer edge of thing being container. Means root
doesn't effect parent. Doesn't change how things inside are
effected. Might be useful
fantasai: Containment means child doesn't interact with ancestors,
right?
florian: Yeah, okay. I can see it
<miriam> +1 fantasai
fantasai: Interface of container some things apply and some don't,
but child shouldn't interact with grandparent
florian: Body to root maybe should be blocked.
fantasai: Body to root? Does that happen?
iank: Root is HTML element?
florian: Yes
iank: Containment applies to html element fine.
astearns: Proposal: If there is containment on body it stops
propagation from body to root?
florian: On body or root
astearns: Proposal: If there is containment on body or root it stops
propagation from body to root
RESOLVED: If there is containment on body or root it stops
propagation from body to root
Need style containment for container queries
--------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6213
iank: Rune constructed some cases, linked in issue, with counters
which would cause circularity
iank: Way counters work is they walk all over dom tree. With this
example constructed a circularity. We think style containment
is required for container queries to work
iank: Didn't read example in depth to explain how it's circular. If
people are happy with Rune expertise.
astearns: We can believe him
florian: No problem believing him. But I think we had said style
containment was odd and need to get back to it
iank: I think style containment main use case is scoping counters
florian: Yes, and quotations
iank: I think, even that statement that counters can propagate
outside the subtree it's clear you get circularities
astearns: Is style containment impl?
florian: Yes in Chrome
florian: Can't remember if FF impl
dholbert: Not in FF. Work in progress patch where emilio had
objections about usefulness being debatable. I'd lean to
wait until emilio is on. I can point him to the issue
dholbert: I think he has strong opinions. Maybe he wanted a
motivating use case. Perhaps this is the one
iank: Agree with emilio. This is use case that makes it useful. We
could tentatively resolve now or wait for emilio on next call
florian: Either way, not last time we'll talk. Given objections from
emilio we stopped on style containment and kept going on
the rest. If we start requiring it we'll look closer and
find other things to change
astearns: Understand complexity to impl. Seems like one of the
objections to style containment is why would anyone use
it. Wonder if it makes sense to fold in effect of style
containment to existing contain values because gets better
containment and avoid circularity. Or a specific value for
container queries that has this contained
<miriam> https://github.com/w3c/csswg-drafts/issues/6174
miriam: That gets to issue 6174
miriam: Not on the agenda, but if we need style containment it's
more argument to come up with new syntax. Happy to work with
anybody that wants to work on it
iank: Maybe path is ask emilio if he objects to style containment as
a concept given these examples and then separate discussion
about what sort of short hand do we want with miriam issue
about container query style containment
astearns: Anything else before we kick it back to issue?
CSS Fonts
=========
Extend font-size-adjust to take a pair of values: <metric> <number>
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6160
fantasai: I think we can conclude on key parts. Added ability for
font-size-adjust to take metric name and then target
ratio. Question is what are initial keywords
fantasai: Propose add ex, cap, ic, and ch
fantasai: Jonathan Kew agreed. Wanted to discuss ascent and descent.
I would suggest for now adopt the initial set and if we
want to discuss additional do so in separate issue
astearns: Suggesting the short names?
fantasai: Yeah, to match units. And because operate in correct axis
which may be height or width depending on writing mode
fantasai: If we want independent of writing mode would need to add
variants. We can start with this set
myles: Feel like we should add ascent to the set. Cases where it
might give you confusing results. If someone applies more
likely to do good. Valuable to have
fantasai: I think cap will be better in most cases
fantasai: ascent and descent metrics are pretty wild when fonts are
outside of latin. This applies to fallback and system
fonts. You'd get something that works well until it really
doesn't. I think that's a serious concern we don't have a
way to address. Can keep talking. I think this is a good
initial set
astearns: Given that are you okay to start with these 4 myles?
myles: fantasai are you saying you think ascent is harmful?
fantasai: Yes. Someone will use it expecting reasonable and it will
fallback to a system font on someone's machine that is
very different
florian: Arial and Arial Unicode MS are wildly different, to give an
example
fantasai: You'll end up with a font that's much too small
fantasai: Slide 23 on the deck in the issue show and example of
wildly different
myles: I think it will be good in more cases then bad. For metrics
that don't have units I think we should use longer names.
Value of shortnames is proportional to number of times typed.
For the lengths type a lot, but without it's only this one
property. Longer names to make it clear is valuable
fantasai: ic and ch they should respond to writing mode and text
orientation so they could be width or height. We can't use
a longer name for those. If ic and ch have shortnames it
makes sense for ex and cap to also match shortnames
myles: Point I was making about metrics that don't have units that
match
fantasai: We don't have those yet
myles: With ascent we would
fantasai: Yes. But for ones with a unit; 2 have to match because
can't add height or width. Others might as well because
why be different
astearns: Proposal: Add these four to start with. After that we can
add more
astearns: Objections?
RESOLVED: Start with ex, cap, ic, and ch
astearns: myles, can I ask you to add a new issue for ascent and
possibly decent?
myles: You could
astearns: Thanks everyone for calling in. We'll talk next week
Received on Thursday, 6 May 2021 20:35:43 UTC