- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 2 Dec 2021 07:14:37 -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.
=========================================
Highlight API & Contain
-----------------------
- The proposal to solve issue #4598 (Static ranges and css-contain)
was to have static-range-backed custom highlights paint across
paint-contain boundaries and allow changes in static range
validity to also invalidate the intersection. On the call there
were concerns expressed that this did not address cases where the
paint-contain area is offscreen. Discussion will continue on
github to work through this use case.
CSS Cascade
-----------
- RESOLVED: Accept suggested behavior, where `revert-layer
!important` in style attr only reverts the style-attr
origins and the animations origin, ignoring other author
origins (Issue #6743: `revert-layer` keyword in style
attribute)
- RESOLVED: Reject this proposal; unlayered styles have a specified
location in the layer stack which can't (currently) be
controlled (Issue #6323: Allow authors to explicitly
place unlayered styles in the cascade layer order)
- RESOLVED: Cascade 4 to CR
- RESOLVED: Cascade 5 to CR
CSS Values
----------
- RESOLVED: Spec FF/WK behavior of eager simplification (Issue #4399:
What should non-calc() math functions serialize to when
they're fully resolved?)
CSS Scrollbars
--------------
- RESOLVED: Change SHOULD to MUST in the normative text about UAs
ensuring the scrollbars are wide enough to interact with
(Issue #6675: Some scrollbars aren't accessible for
interactions)
- RESOLVED: Publish Scrollbars as a CR.
CSS Images
----------
- RESOLVED: object-fit affects the rendering of iframes with
expressed intrinsic sizes (Issue #6817: Layout of iframes
with content intrinsic sizing that does not match the
<iframe>)
- RESOLVED: object-position applies to iframes in the above case as
well (Issue #6817)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2021Dec/0000.html
Present:
Rossen Atanassov
Tab Atkins
David Baron
Bo Cupp
Elika Etemad
Robert Flack
Simon Fraser
Chris Harrelson
Sanket Joshi
Vladimir Levin
Peter Linss
Cameron McCormick
Jen Simmons
Alan Stearns
Miriam Suzanne
Regrets:
Jonathan Kew
Chris Lilley
Lea Verou
Scribe: TabAtkins
Scribe's scribe: fantasai
Rossen: One agenda request about CSS images
Rossen: Any other changes?
<dandclark> Can we bump the highlight issue to the first 30 mins? I
think Sanket is only available then
chrishtr: Admin request: #6464, shared element transitions, could
people please read the new explainer and provide feedback?
chrishtr: We're having incubation community meetings that anyone can
come to, let me know
Highlight API & Contain
=======================
Static ranges and css-contain
-----------------------------
github: https://github.com/w3c/csswg-drafts/issues/4598
sanketj: There was discussion in a previous meeting to just add a
paint step that ignores static ranges that cross a
containment boundary
sanketj: It didn't seem like it was something unique to the highlight
api
sanketj: Selection also adds ranges, and they're allowed to cross
containment boundaries
sanketj: so if this should be disallowed for highlights, it should be
done at a more general level
sanketj: So Dan's proposal is that we shouldn't need to handle this
case in the Highlight API specifically
sanketj: but there's also a question of what forum this question
should be taken up in
dandclark: Even for live ranges today, if I'm using a live range to
paint a selection, I can use the range API to make it
encompass a paint-contained element and cause paint
changes inside that contained element
dandclark: So we already don't really pay attention to paint contain,
and that makes sense - they're not really bound to the
tree hierarchy
dandclark: Before we were looking at this the wrong way - if I have a
range across a paint boundary, and I remove the element
that one end is on, we have to invalidate it and that
requires more invalidation than seemed reasonable
dandclark: But really this sort of invalidation is akin to live range
invalidation
<dandclark> Proposed resolution: Allow static-range-backed custom
highlights to be painted across paint-contain boundaries.
Changes in static range validity can invalidate an
intersected element with paint-contain. This is OK, and
we will document this interaction in the highlight spec.
dandclark: So proposed resolution [above]
florian: I think I disagree
florian: Problem is not whether something crosses a paint boundary.
Crossing is fine
florian: The initial problem with static range is that if it starts
outside the paint contain and goes inside, and the dom
changes within the paint-contain area, and the paint-contain
area is offscreen, then in that case there is part of the
range inside and outside
florian: The part that is outside isn't changing, it still goes up to
the edge, but the part inside does change, because you
changed the DOM. But that breaks an invariant of paint
containment, that you don't need to worry about the painting
of a contained element that's offscreen
florian: I think that's different from your examples
florian: If you have a live range that you change, so the part that's
outside should be different, well you changed it, of course
you have to repaint
florian: With selection it's the same - if you change the selection,
surely you have to repaint it
florian: also, paint containment allows browsers to skip painting,
and paint-based invalidation. it doesn't allow browser to
skip dom updates.
florian: So if dom updates you do still have to handle that
florian: So that's why the live vs static range is important
florian: live ranges are effectively part of the dom, so modifying
the dom modifies the live range
florian: but the point of the static range is that it doesn't get
updated; the author is meant to take care of that
florian: and it might get inconsistent where the entire thing
shouldn't be painted
florian: So statics can give us an inconsistent state that live
ranges can't
florian: Just not painting ranges that cross paint boundaries might
not be right, we can explore this space more
BoCupp: In both cases, it's the state of the range that's changing.
The range that's intersecting an element with paint
containment needs to be able to invalidate inside that
boundary
BoCupp: Misleading us is that we're using nodes that are inside or
outside the containment, to trigger changes in the range.
BoCupp: I don't think it matters that the state is computed for
static ranges so you can tell they're valid or invalid, or
you change the start node so it moves from inside to outside
the containment
BoCupp: So we don't think there's a new case here. We might need to
dig more into what florian is bringing up
BoCupp: Ultimately this is about optimizations browser can pursue,
and rather than put in complicated rules, put the onus on
browsers to pay attention to ranges that might intersect
containment
florian: That invalidates the point of contain, though. Point is that
it removes several things that it no longer needs to pay
attention to.
BoCupp: It only requires them to pay attention to this one thing,
ranges.
Rossen: Sounds like this discussion should continue on GH, there's
more detail to be ironed out before we're ready for
resolution.
CSS Cascade
===========
`revert-layer` keyword in style attribute
-----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6743#issuecomment-971826541
miriam: We talked about this a few weeks ago, and resolved that the
revert-layer keyword in a style attr should only revert the
style attr.
miriam: but that becomes complex and unclear when thinking about how
style relates to normal and important layers
miriam: We've drawn some diagrams in the thread about different ways
this could work
miriam: Main question is: if you use `revert-layer !important` in a
style attr, is that still only revert the style attr, and
maybe the animations layer, but no author layers? Or is it
also reverting important author layers, taking you down to
normal author layers?
miriam: I think we meant the former, but there's some confusion there.
miriam: Proposal is that setting `revert-layer !important` in the
style attr, it reverts the style-attr layer, the animations
layer, and nothing else
fantasai: Looking at the ascii diagram from Xiaocheng, most revert
behaviors cut from the important to the normal origin, and
remove everything between those two points
fantasai: but because style attr is weird, on top of both normal and
important, if we similarly cut thru like that, it'll remove
important styles from layers but not the normal styles from
those layers
fantasai: So I think because it's likely to break expectations of
someone writing a layer to remove the important part but
not the normal part, I think it's better to do this
skipping behavior
fantasai: A little concerned about how this plays out in impls, but
since Xiaocheng wants it, I think we should go with it
TabAtkins: Looked it over before the meeting, and with you all and
Xiaocheng agreeing, I'm happy to go with this
Rossen: objections?
RESOLVED: Accept suggested behavior, where `revert-layer !important`
in style attr only reverts the style-attr origins and the
animations origin, ignoring other author origins
Allow authors to explicitly place unlayered styles in the cascade
layer order
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6323
miriam: We left this at taking back to the thread to discuss syntax,
and a lot happened
miriam: two frontrunner proposals
miriam: (1) unlayered styles are like any other layer, we just have a
name for that layer and allow you to place it
miriam: That's the simplest option conceptually
miriam: it means the final page author always has control over
layering, as they can place the unlayered style wherever they
want
miriam: But it could cause problems if people explicitly need their
styles above or below the default
miriam: If we need that...
miriam: (2) track two layer stacks, one above and one below the
default unlayered styles
miriam: If we need that, fantasai and I came up with a syntax, you
can put a slash in your @layer to designate whether your
layers are in the "below default" or "above default" stack
miriam: Think this'll work well, but you're conceptually tracking two
layer stacks
fantasai: Third option is close no change, and just leave unlayered
at the top of the layer stack
jensimmons: I talked with Elika about this a lot recently. I think I
agree with Elika that the simpler version won't work.
jensimmons: Think about a team with a complex custom design with
their own styles, then they pull in bootstrap or other
third party complicated lib
jensimmons: And you crush those two together, there's a lot of room
for unintended consequences
jensimmons: But as we talk thru the more complex versions, it's too
complex
jensimmons: Layers are meant to make the cascade more understandable,
and I think making these two stacks, plus the combo with
important vs normal, I think it'll be too hard
jensimmons: and there is a way - I'd need a diagram to fully explain
- for the 3rd party framework to say "hey I want to
rearrange the order of the layers" and end up overriding
layers the custom stack doesn't want overridden
jensimmons: As soon as I started to understand how this could happen,
I just said NOPE
jensimmons: So right now I'm okay with option 3, just leave the
unlayered styles at a specified point. We can revisit in
the future if we think we really need it.
TabAtkins: I was not a fan of the 2-stack approach
TabAtkins: while there are use cases for control, I'm fine with
leaving no change for now
miriam: wfm
Rossen: Anyone object?
RESOLVED: Reject this proposal; unlayered styles have a specified
location in the layer stack which can't (currently) be
controlled
CSS Values
==========
scribe: fantasai
What should non-calc() math functions serialize to when they're
fully resolved?
---------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4399#issuecomment-949067282
TabAtkins: Should be a small clarification
TabAtkins: Previous resolution didn't quite hit this
TabAtkins: Issue is, when you have a unit that is not a canonical
unit in a math function
TabAtkins: when precisely does it turn into the canonical unit?
TabAtkins: eg. when do you turn 1in into 96px?
TabAtkins: Browsers all differ on this matter
TabAtkins: Safari and Firefox canonicalize eagerly
TabAtkins: Chrome only does this during the simplification process,
sometimes.
TabAtkins: For specified styles it won't always fully simplify
TabAtkins: for computed values will sometimes simplify
TabAtkins: It's weird, calc(1in + 1in) becomes 2in
TabAtkins: but calc(1in + 10px) becomes 106px
TabAtkins: I think we should go with Firefox and Safari's behavior
TabAtkins: What Chrome is doing is complicated and unnecessary
TabAtkins: and two browsers are doing eager simplification already
Rossen: Any other opinions?
RESOLVED: Spec FF/WK behavior of eager simplification
CSS Scrollbars
==============
scribe: TabAtkins
Some scrollbars aren't accessible for interactions
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6675
Rossen: Do we need Greg?
florian: I'll try.
florian: Two parts to the issue
florian: Some people complain that scrollbars found on the web were
weird or unusable
florian: Those were ::-webkit-scrollbar, not thru our specced
properties
florian: The spec doesn't need to write about how to use those, since
we consider them to not exist
florian: The part we do need to talk about is that the spec currently
says that narrow scrollbars "should remain wide enough to be
usable". Greg says this should be a MUST.
florian: At least, when the user begins interacting.
florian: I'd skip that last part, because we're not really specifying
that the narrow scrollbar has a dynamic width; browsers can
do whatever.
florian: But going from "should be usable" to "must be usable"... why
not? Not sure it's enforceable, but a browser deciding its
narrow scrollbars don't need to be usable would be odd.
florian: WCAG, note, says that the minimum size to be interacted with
is 40px, and wide scrollbars aren't ever anywhere near that,
so what it means to be "wide enough to be interacted with"
seems difficult to understand
florian: For overlay scrollbars, having them dynamically change size
is fine, but layout scrollbars you probably don't; I don't
think we should exclude it though.
Rossen: Just moving the SHOULD to MUST and leaving the text otherwise
the same makes sense
flackr: I raised this in OpenUI - even if the scrollbar isn't
visually large enough, we do "fuzz" touches on buttons, and
could do the same thing for the scrollbar, so as long as your
finger touches near the scrollbar it considers you to be
touching it
flackr: I think it should be a reasonable way to have a narrow
scrollbar that's still usable
florian: Perhaps we can include this in a note - if you're overlay,
feel free to enlarge it on hover; if not, maybe fuzz hit
testing. Nothing normative, just suggestions
Rossen: Stepping back, from pure a11y, the change makes sense.
Rossen: Said many times - we shouldn't be specifying how the UI
frameworks should work.
Rossen: But if we've already gone to the extend of adding normative
text about "scrollbar width must be large enough", changing
that to a MUST makes sense
<TabAtkins> +1
Rossen: Objections?
RESOLVED: Change SHOULD to MUST in the normative text about UAs
ensuring the scrollbars are wide enough to interact with
Publication
-----------
florian: At this point all issues are closed, all horizontals are
complete, security review has timed out
florian: Which means that once I double-check that changes and doc
are up-to-date, we're ready for CR. Can I ask for that?
<fantasai> +1 to CR
Rossen: Any objections to moving Scrollbars to CR?
RESOLVED: Publish Scrollbars as a CR.
CSS Cascade
===========
Publication
-----------
fantasai: At this point we're zero open issues aside from small
editorial tweak
fantasai: So would like CR transition for Cascade 4 and 5
florian: Horizontal kicked off?
fantasai: Yes, though Security never got back to us
Rossen: Consider it a timeout
Rossen: Objections?
RESOLVED: Cascade 4 to CR
RESOLVED: Cascade 5 to CR
CSS Images
==========
Layout of iframes with content intrinsic sizing that does not match
the <iframe>
-------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/6817
chrishtr: About iframes with content size different from the iframe
element
chrishtr: Currently not possible
chrishtr: But two upcoming features that might change this
chrishtr: fenced frame that prevents iframe content from changing
size after loaded, to avoid info leaks
chrishtr: And cooperative iframe sizing, which may let the content
document size differently from the iframe element
chrishtr: I propose we apply object-fit semantics to this, and
default to object-fit: contain
chrishtr: (thus letterboxing the iframe)
fantasai: Does this mean you'll shrink/zoom out the iframe if it's
smaller than the document?
chrishtr: Yes
chrishtr: I think that would look the best, if they differ.
smfr: not sure I agree - flashes of scaled content are weird
smfr: Could just attach it to start-start corner
chrishtr: So two potential resolutions: one is whether object-fit
works, and second is what the default value is
TabAtkins: Applying object-fit makes sense, it's designed to handle
this kind of thing
TabAtkins: No reason not to work as it does elsewhere
TabAtkins: No strong opinion about default value
TabAtkins: If question between losing data because doing object-fit:
none and overflowing in some way
TabAtkins: or making something very small, either squished or zoomed
out
TabAtkins: they're both pretty bad
TabAtkins: I'm not sure which is best for the user
chrishtr: None would cut off content
chrishtr: There's also "smaller" - only transform if you have to make
it smaller to fit
chrishtr: "scale-down"
smfr: Is this a frozen iframe?
chrishtr: For a fenced frame, this would persist for the life of the
frame - they'd interact with it potentially
chrishtr: These are for, like, ads - the 3rd party doesn't see what
size the iframe ends up being
chrishtr: Authors should avoid having this happen, but when it does
we need some dfn for the behavior
dholbert: This have any effect on regular iframes?
TabAtkins: no, they continue to have no intrinsic size and work as
they do today
Rossen: What's the scenaro?
dholbert: <iframe src="giant-image.jpg">
dholbert: Chrome displays at full res, Firefox does scaled down but
you can click it to go full, unsure what webkit does
Rossen: Given we don't have interop...
dholbert: That's what I'm getting at, does this have any effect on
these
chrishtr: This shouldn't have any effect on today's iframes, only on
the new stuff the cited proposals can bring up
chrishtr: Only situations where there is an expressed intrinsic
sizing (iframes today don't have it at all) and there's a
mismatch
Rossen: Objections?
TabAtkins: Should we resolve separately on whether to apply the
property and what the default should be?
RESOLVED: object-fit affects the rendering of iframes with expressed
intrinsic sizes
chrishtr: I'd like the resolution for the second now, if possible
Rossen: We can change in the future
dholbert: object-position should also be relevant
TabAtkins: Oh yeah I assumed it would be
Rossen: Objections?
RESOLVED: object-position applies to iframes in the above case as well
Rossen: Please work out the defaults in the issue and we can resolve
next week
Rossen: We have a long call next week, Alan provided some details in
the private list
Rossen: We'll have a gh project with the issues to discuss
Received on Thursday, 2 December 2021 12:15:18 UTC