- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 4 Oct 2019 18:50:25 -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.
=========================================
F2F Scheduling
--------------
- RESOLVED: Igalia meeting time is 10am-7pm
- RESOLVED: CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020,
Houdini afterward (pending booking confirmation)
[Location: Cork, Ireland]
- Tentatively there will be a late July meeting in NYC
CSS Contain
-----------
- RESOLVED: PR of css-contain-1, dropping style containment (at-risk)
- RESOLVED: FPWD css-contain-2 being copy of css-contain-1
(including at-risk features)
rendersubtree
-------------
- chrishtr introduced the proposal for a rendersubtree attribute.
Proposal text:
https://github.com/WICG/display-locking/blob/master/README.md
Proposed PR: https://github.com/whatwg/html/pull/4862
Github issue: https://github.com/whatwg/html/issues/4861
- The 'rendersubtree' attribute controls whether the subtree is
laid out and rendered or not, in order to allow browsers to be
more performant and authors to reserve space for an element that
is not yet loaded. This also introduces an "activation" concept
which allows the browser to choose to render.
- Several members expressed concern that this felt more like a CSS
property. The reason it was not written to be is because the UA
is allowed to overwrite it.
- The use case for 'invisible' and not 'activatable' is so the author
can prevent not-yet-rendered content from being shown. It was
suggested the default should be 'activatable' since authors might
not think through all cases of 'invisible' if it's the default.
- It was suggested to add callbacks for the activation actions so
authors could listen for the changes.
- The difference between this and 'contain: all' is that this would
prevent animations from loading. Meanwhile, the difference to
'display: none' is that the layout work is still done in this
case.
- More info at https://github.com/whatwg/html/issues/4861
Sizing L4
---------
- RESOLVED: Add proxy-width/height/inline-size/block-size with
values legacy | auto | <length> (Issue #4229:
content-size)
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/tpac-2019#agenda
Present:
Rachel Andrew, Fronteers
Rossen Atanassov, Microsoft
L. David Baron, Mozilla
Amelia Bellamy-Royds, Invited Expert
Christian Biesinger, Google
Brian Birtles, Invited Expert
Oriol Brufau, Igalia
Tantek Çelik, Mozilla
Emilio Cobos, Mozilla
Emil A Eklund, Google
Elika Etemad, Invited Expert
Jihye Hong, LGE
Koji Ishii, Google
Sanket Joshi, Microsoft
Brian Kardell, Igalia and Open JS Foundation
Eugene Kashida, Salesforce, Observer
Rune Lillesveen, Google
Chris Lilley, W3C
Peter Linss, Invited Expert
Stanton Marcum, Amazon
Myles C. Maxfield, Apple
Cameron McCormack, Mozilla
Nat McCully, Adobe
Chase Phillips, Google
Florian Rivoal, Invited Expert
Dominik Röttsches, Google
Devin Rousso, Apple
Peter Rushforth, Natural Resources Canada, Invited Expert, Observer
Hiroshi Sakakibara, Beyond Perspective Solutions(BPS)
Simon Sapin, Mozilla
Dirk Schulze, Adobe
Markus Stange, Mozilla
Alan Stearns, Adobe
Aleks Totic, Google
Matt Woodrow, Mozilla
Fuqiao Xue, W3C
Scribe: fantasai
Scribe's Scribe: florian
F2F Scheduling
==============
Rossen: January is already in the books
Rossen: Jan 22-24 hosted by Igalia
fantasai: Should we resolve on Rego's suggestion to run 10-7pm?
florian: Reason was local schedules, restaurants don't open until
8/8:30pm
RESOLVED: Igalia meeting is 10-7
Rossen: Dates from Apple?
astearns: Tess said she's trying to reserve April 27-30
astearns: Don't have an update on if she succeeded
Rossen: Just want to try to sort it out asap, so people who are on
tight schedules can finish their scheduling for the spring
skk: Will there be a Houdini meeting?
Rossen: Not in Spain, in April there will be one
Rossen: Possible Summer locations are Kyoto, France, NYC
Rossen: Anyone up for sponsoring F2F meeting?
florian: France is a misunderstanding, can't offer to host in
France, but can host in Kyoto but not in July+August
Rossen: NYC would put two consecutive in USA
astearns: Maybe. April might be in Ireland
Rossen: So looking at July 20-24 or July 27-31, last two weeks of
July
<birtles> July+August is also Olympics in Tokyo, so not a good time
to visit Japan
dbaron: That is not the ideal time for Japan, not only because it's
warm but also Tokyo Olympics are then
hober: I have dates!
hober: Did we want to have Houdini, also?
hober: I have three days confirmed, 4th not confirmed yet
hober: Booked for Monday 27 April - 29, in Cork, Ireland
Rossen: Sounds great
RESOLVED: CSSWG meeting Monday 27 April 2020 - Wed 29 April 2020,
Houdini afterward (pending booking confirmation)
Rossen: Back to summer
Rossen: Who was offering to host in NYC?
dbaron: Think it was Una (Google)
TabAtkins: We can probably do it
Rossen: Ok, check about it and let us know
<dauwhe> +1 to NYC for a meeting where I won't be jetlagged :)
TENTATIVE: End of July 2020 in NYC
CSS Contain
===========
Rossen: Proposed to publish a PR of CSS Contain 1
<dbaron> https://drafts.csswg.org/css-contain/issues-2019-cr.html
<dbaron> https://drafts.csswg.org/css-contain/implementation-report-2019-09
<dbaron> https://drafts.csswg.org/css-contain/annotated-2019-09-05.html
<dbaron> https://github.com/w3c/csswg-drafts/labels/css-contain-1
<dbaron> https://drafts.csswg.org/css-contain-1/
florian: Afaict, it's complete
florian: All tests pass in 2 browsers, except those which depend on
other less-mature specs
florian: So I think we are ready for PR
florian: One more note, all tests pass if we don't count the at-risk
feature
florian: style containment is not implemented properly anywhere
florian: but that's why we marked it at risk
florian: So my request is to drop it, go to PR, and publish FPWD of
Level 2 which just contains that feature
Rossen: So PR version will have 3.3 dropped from Level 1
Rossen: Objections on resolving to publish PR of CSS Contain 1 with
dropped section?
dbaron: Is the state of style containment that implementations are
shipping support and not passing tests, or not shipping
support?
eae: Combination of both
florian: Chrome ships a buggy one, and Gecko doesn't ship iirc
heycam: We don't recognize the value
smfr: Are the two implementations blink and gecko?
florian: Yes
Rossen: Hearing no objections,
RESOLVED: PR of css-contain-1, dropping style containment (at-risk)
florian: For Level 2
florian: if we add new features, need fpwd, but if not adding a new
feature can go directly to CR
Sizing L4
=========
content-size
------------
github: https://github.com/w3c/csswg-drafts/issues/4229
<astearns> explainer:
https://github.com/WICG/display-locking/blob/master/explainer-content-size.md
chrishtr: Posted a new explainer
chrishtr: content-size is a new CSS property
chrishtr: If 'contain: size' is specified, content-size is treated
as intrinsic size of contents
chrishtr: Proposing that be able to set intrinsic width/height
passed to intrinsic sizing algorithms
chrishtr: Reason we believe it's useful is that you can use it when
a subtree is not yet ready or you don't want it to have
its own layout
chrishtr: can express a placeholder sizing for it
chrishtr: Allows communicating that placeholder sizing, so that flex/
grid/table/etc can take that into account
chrishtr: If we've skipped rendering as an optimization, dev can use
to communicate placeholder sizing
SimonSapin: Would this property apply without 'contain'?
chrishtr: When you don't have 'contain: size', no
chrishtr: Only applies when 'contain: size'. Reason is that
'contain: size' causes no competing intrinsic size
chrishtr: 2nd reason is that it fits neatly with render subtree
attribute proposal
florian: Can you expand on the second point? I'm not familiar
with that
florian: In isolation proposition makes sense, but not sure why it's
not coupled with a more generic intrinsic size feature
TabAtkins: One reason was that, as chrishtr said, that means you
have competing information. We don't think that's useful
to have two sources of truth there
TabAtkins: Seems like only time you need to provide a better
intrinsic size is when you're contain sizing already
dbaron: I'm skeptical of that
dbaron: I think there are a bunch of cases, where intrinsic sizing
doesn't provide good results and devs might want to
provide it
dbaron: Talked about some of those cases in the past
dbaron: Some cases devs want to override only in one dimension
TabAtkins: Bad behavior of intrinsic scrollers maybe?
TabAtkins: flexboxes blowing up
dbaron: Didn't have that in my head, but sure
TabAtkins: That's intriguing
AmeliaBR: Also cases we've had where certain modes cause things to
collapse down to zero, and might be better not to
AmeliaBR: Lots of cases there might be a demand for it
AmeliaBR: Wrt naming, 'content-size' might be interpreted as size of
content-box
AmeliaBR: Also, if there is a limitation, should be good reasons
for it
TabAtkins: Yes, happy to come up with better name
TabAtkins: Cases that fantasai and I identified where boxes get too
big in intrinsic sizing, and currently don't have a way
to opt into better behavior
TabAtkins: In some cases can inflate intrinsic size, others might be
able to shrink
TabAtkins: good idea
fantasai: Support florian and dbaron, this should probably be a
generic mechanism
fantasai: The value space would be legacy | auto | <size>
cbiesinger: What is the difference between legacy and auto?
fantasai: scrollers collapsing to 0 or not
fantasai: If inside a flex item, there is an overflow:scroll pre
element with a very long line, the min-content size is the
size of the very long line, that makes the flex item be
very large, even though we could just have made it into a
scroller
[ this is https://github.com/w3c/csswg-drafts/issues/1865 which
seems unfixable ]
TabAtkins: Semantics are still a bit funky, if you provide a size
wouldn't do anything unless you're contain: size
fantasai: Well, I think it would
dbaron: I would also note that there are cases where intrinsic
sizing provides sizes that are too small, e.g. in cases with
percents
fantasai: If you specify an explicit size here, that takes over and
you ignore the content
TabAtkins: Could do that... was wondering if you wanted to max them
AmeliaBR: Doing a max or min doesn't work if we want to accept both
use cases of dealing with cases where intrinsic size is
too big or too small
AmeliaBR: Just say if you specify a value, you wanted to override
chrishtr: All these examples that were alluded to but not explicit,
please write into issue
fantasai: Based on discussion, this doesn't go into contain, goes
into Sizing level 4
Rossen: Anything else on this topic
TabAtkins: Discussion was good
chrishtr: Point Florian raised about, what are you talking about wrt
render subtree
chrishtr: Maybe wait until we talk about that
chrishtr: but 5min background on render subtree, though it's on the
HTML spec
chrishtr: Package, how they fit together matters, so just want to
mention
Rossen: We can put that topic next
chrishtr: Just want to give an overview of what it is, what use
cases are, how it functions
chrishtr: so can get some feedback
<chrishtr> Explainer that contains rendersubtree:
https://github.com/WICG/display-locking/blob/master/README.md
Rossen: So content-size, or whatever we're going to call it, will go
to size level 4
Rossen: Any objections to add it?
TabAtkins: Maybe call it intrinsic-size
fantasai: Nobody wants to spell that
TabAtkins: true
fantasai: There was a suggestion that this be split into width/
height not one property for both dimensions
fantasai: Seems to be the proposal is foo-width/height/inline-size/
block-size
iank: legacy as initial value?
PROPOSAL: Add proxy-width/height/inline-size/block-size with values
legacy | auto | <length>
RESOLVED: Add proxy-width/height/inline-size/block-size with values
legacy | auto | <length>
CSS Contain
===========
Contain level 2
---------------
florian: We could go CR directly, but we might want to change things
so maybe fpwd is better
florian: Some suggestions, e.g. single-axis contain, etc.
florian: Might want to add
RESOLVED: FPWD css-contain-2 being copy of css-contain-1 (including
at-risk features)
Rendersubtree
-------------
chrishtr: I posted a link to an explainer earlier
<chrishtr> Explainer that contains rendersubtree:
https://github.com/WICG/display-locking/blob/master/README.md
<chrishtr> https://github.com/whatwg/html/pull/4862
chrishtr: PR for spec idea
chrishtr: render-subtree attribute is an attr you can put on any
HTML or SVG element
chrishtr: Has one or more keywords that are space-separated
<bkardell> ... or mathml?
chrishtr: ex. rendersubtree=invisible
chrishtr: What that means is that it is invisible, but takes up
layout space
chrishtr: and also is designed so that UA doesn't need to do any
render work for that subtree
chrishtr: No heuristics to figure out whether needs to render that
subtree
chrishtr: You load a web page
chrishtr: bunch of content not on screen atm
chrishtr: You want that page to load quickly, not have extra layout
cost
chrishtr: not load external resources
chrishtr: etc.
chrishtr: for stuff that's not on screen right now
chrishtr: Common because scrolling is common on web, and large
websites
chrishtr: What does attribute do when set to invisible?
chrishtr: First, it applies layout, style, and size containment
chrishtr: Layout containment is good, content below can't escape
layout of the element at the root of the subree
chrishtr: Size containment for similar reasons:
chrishtr: don't need to know layout to compute layout of the page
chrishtr: so don't need to do layout, don't need to paint it,
chrishtr: not painted to screen and not hit-testable
chrishtr: so don't need to do any work as UA to process that DOM
subtree
chrishtr: it is present, but doesn't cause any work
chrishtr: That's the core value-add of the 'rendersubtree=invisible'
chrishtr: Other values you can add
chrishtr: If you say that rendersubrree is invisible and
activatable, what that means is that UA is allowed to
mutate that attribute to be empty string
chrishtr: to render the content
chrishtr: e.g. wikipedia, stuff below the fold
chrishtr: wikipedia makes as activatable
chrishtr: and invisible
chrishtr: When user or a11y API wants to look at that content
chrishtr: or user wants to do find-in-page operation
chrishtr: and UA notices the content is below the fold off-screen
content browser would be able to cause the content to
render
chrishtr: which has effect of causing it to render
chrishtr: and script can observe the mutation of the attribute
through a mutation observer
chrishtr: Takes some action to help
chrishtr: or in simplest cases, content is just rendered
chrishtr: Important because lots of UA algorithms not controlled by
author
chrishtr: e.g. a11y, anchor link navigation, tabbing between
focusable elements
chrishtr: scroll-int-view operation, find-in-page
chrishtr: Finally, two additional keywords
chrishtr: One prevents external resources from being loaded
chrishtr: image wouldn't be loaded until whole-loads keyword is
removed
chrishtr: avoids blocking network pipeline for stuff below the fold
chrishtr: Useful for feeds of info like fb, twitter, also for page
with lots of images off-screen
chrishtr: This is a lazyloading feature similar to what chromium is
trying to ship
chrishtr: Finally, web component element upgrades
chrishtr: If you have custom elements defined in your registry,
chrishtr: if element was registered, runs create callback
chrishtr: Allows dev script to participate in rendering the custom
elements
chrishtr: but if elements are off-screen, then cost isn't desirable
chrishtr: dev would prefer not to run script until content is
on-screen
chrishtr: Way this fits in with content-size is that if you set the
render subtree attribute to 'invisible'
chrishtr: has containment
chrishtr: therefore content-size would take over sizing of
unrendered content
chrishtr: This way, when content is subsequently rendered via UA
action or dev activation
chrishtr: layout doesn't jump around
chrishtr: contain: size is only applied when invisible
chrishtr: When not invisible, then it will no longer have
'contain-size', automatically uses actual size
chrishtr: Intrinsic size without size containment might be
compelling enough to drop this connection, but that's what
we were thinking
chrishtr: 'display: none' doesn't help for off-screen content
because it doesn't take up layout space
chrishtr: 'visibility: hidden' doesn't stop layout, and also can be
overridden by descendants, so have to render through the
subtree
Rossen: 'display: none' + 'contain: size"
chrishtr: display: none box is gone
chrishtr: rendersubtree=invisible, the box is still there, only its
contents are gone
chrishtr: You could have e.g. a spinner rendered in the element, or
a pseudo-element, but don't actually render the subtree
smfr: What's the behavior when element with visible subtree changes
to invisible
chrishtr: If you just add `rendersubtree="invisible"` to element
chrishtr: it'll apply contain: style layout size
chrishtr: and not render the contents
chrishtr: but element itself will still read
chrishtr: Script can still read style, could cause layout thrashing
smfr: So toggle from visible to invisible ...
smfr: does it give you a stale value?
chrishtr: Will do the work to get you the right value
chrishtr: Doesn't cause it to render, but has to do calculations
smfr: Seems a bit magic, like a hack
smfr: Seems like maybe it should be a CSS value, e.g. new keyword to
'visibility'?
chrishtr: If it was a CSS property, would be weird if UA overrides it
chrishtr: Made it a attribute so UA can remove automatically
smfr: Worried about circularity about activatable
smfr: e.g. user hits Cmd+F to start a find
smfr: I think you have to bring in the subtree in order to search it
smfr: because have to e.g. check for 'display: none'
chrishtr: Don't have to show on screen, but have to compute style
smfr: Activatable has side-effect of removing the attribute?
chrishtr: If you try find in page, UA will do the work necessary to
compute the display: none part of pipeline
chrishtr: If it matches query, would activate the subtree
smfr: Worried there are some things that are not specified that end
up affecting the activation behavior
smfr: Spec says activation depends on UA behaviors, different
browsers will have different activation policies if we don't
standardize
chrishtr: Explainer lists which actions cause activation
chrishtr: Scrolling doesn't, JS scrollIntoView does, a11y access does
Rossen: We have built up quite a queue
florian: Maybe I missed something, one part I'm confused about
florian: what's the use case for invisible without activation?
florian: I think author will probably miss some important cases if
it's not activatable
florian: Also, feels like it's something like a delayed or sync
value for visibility
florian: You're allowed to delay, but once on screen please show
florian: Most benefits when combined with contain,
florian: but conceptually could be separate
florian: You're allowed to load the assets later
florian: wouldn't need to override the value, just permission to do
it later
florian: maybe that covers requirement for running scripts?
florian: Rest feels like it could be in CSS somewhere along the
lines that smfr was talking about
florian: Would like to also know why have a version that's not
activatable
chrishtr: Suppose you have content that is not fully loaded, don't
want to show to user. That's why you don't want it to be
activatable
chrishtr: Wouldn't be visibility: hidden because not performant,
layout subtree still applies
myles: If you want to leave space for it, you can set visibility:
hidden for it, will leave space
myles: If you do want the pop, can set display: none
florian: Would combine visibility: hidden with contain, to reduce
jank
TabAtkins: Will have jumping because the content hasn't loaded either
florian: But would use 'contain' and 'content-size' as well
florian: Why needs an HTML attribute
TabAtkins: Doesn't allow us to not do layout
TabAtkins: Which is a problem if wanting to load 10,000 nodes worth
of content
florian: So would want 'visibility: ...', which would allow delaying
TabAtkins: Recall reason chrishtr just said about having invisible
but not activatable
TabAtkins: Element is in state where it's waiting for stuff to load
TabAtkins: don't want to allow activation until finished
AmeliaBR: Had same question
AmeliaBR: but final comment, might want to consider making
activatable the default
AmeliaBR: Authors might *think* they know when to activate, but
haven't considered things through very well
AmeliaBR: so suggest to make default activatable, author has to
explicitly request non-activatable
<AmeliaBR> e.g. `inert` version for non-activatable
myles: Might be problematic to have elements callback in
unpredictable order?
chrishtr: Can use this feature to automatically activate content
which is below the fold, or not even actually visible
chrishtr: e.g. tabbed UI or content hidden behind a ? that can be
opened by the user
chrishtr: e.g. details element
chrishtr: Still want user to be able to find that content and
navigate to it
chrishtr: currently, that's not really possible
chrishtr: e.g. you have content in another tab of the ui, or
subwidget
chrishtr: nm, another reason for activation
heycam: two things: one, want to echo what smfr said
heycam: I feel like behavior when subtree isn't rendered seems like
CSS kind of feature
heycam: Recognize that overriding the style value of some property
doesn't feel great
heycam: but otherwise feels like some new 'display' value, like
'display: placeholder' which only generates frame and not
contents
heycam: Some kind of solution where it's somehow reflected in CSS
property display would be nice
heycam: 2nd point was about automatic activation behavior
heycam: have you considered solution where you have strict callbacks
for events for these types of activation behaviors?
heycam: so dev can choose to catch events and decide whether to flip
activation
chrishtr: So suggesting that script should be able to observe
activation
heycam: Wondering if that's a design that you've considered
chrishtr: Did consider that design
chrishtr: and prototyped in chromium
chrishtr: The event for this, which we called activate event, wasn't
in spec proposal
chrishtr: but makes sense and is convenient to add
chrishtr: Technically can be implemented with mutation observer, but
might be inconvenient
heycam: One advantage of that might be that you could then have a
new display property value that does the actual work of that
heycam: and let the author change the value of that property
chrishtr: So tell dev that "I would like to activate this, please
help me out"
chrishtr: problem is default behavior is not good
heycam: Author specifying 'display: placeholder', on you to complete
the solution
chrishtr: Comments about flipping default activation, should make it
easy as possible to adopt feature without unintentionally
breaking accessibility
TabAtkins: copy-paste two-line activation script on every page that
uses this feature
TabAtkins: that's not so great
TabAtkins: If they don't want it to activate, they can use the don't
activate value, and have that work as intended
automatically
TabAtkins: Back to display values, while I wouldn't fight too hard
if we decided to add a display subproperty
TabAtkins: but doing none-typed things in 'display' itself is
problematic because lose typing
TabAtkins: this is really bad
chrishtr: Want UA to be able to activate for you
chrishtr: with recent testing with partners etc, does seem to be a
use case for controlling things with a style sheet
chrishtr: Sometimes convenient to do via CSS
<TabAtkins> aka you can't set "display:flex" on the element without
paying a *lot* of attention to specificity, or else
you'll accidentally override the hide-contents value
<fremy> @chrishtr: added some notes over here:
https://github.com/WICG/display-locking/issues/78
fantasai: Same concern as AmeliaBR about making the activatable
version the default
fantasai: It would also be good to have the attribute map to some
css construct, instead of having the HTML do its own magic
chrishtr: Less magical means harder to cleanly spec, and some use
cases are lost
myles: I see the readme and whatwg pull request, how do I comment?
chrishtr: I think the pull request has a corresponding issue in
whatwg, good place to ask questions
chrishtr please paste the issue
SimonSapin: Similar to 'display: none', but different in that only
contents are hidden
SimonSapin: How is this different from 'display: none' on children?
TabAtkins: Text content that are direct children can't be styled
TabAtkins: but also 'display: none' implies a lot of things
Rossen: Animations, do they run on your subtree?
chrishtr: No
Rossen: So that's also same as display: none
chrishtr: Subtree boxes do have CSS boxes
chrishtr: Conceptually are laid out, just don't need to do work
unless forced by script
mattwoodrow: What is additional constraint that we get over
'contain: all'
mattwoodrow: Couldn't UA optimize by not rendering anyway?
chrishtr: It's an explicit API
chrishtr: rather than combo of CSS values
TabAtkins: off-screen 'contain', animations still run
TabAtkins: You will fall down accidental performance cliffs
mattwoodrow: So it will block animations?
TabAtkins: Among other things, yes
bkardell: I could be misreading this and not understanding, but
sounds like the intent is for the UA to actually change
the attribute?
chrishtr: Yes
bkardell: Is there a precedent for doing that?
TabAtkins: There's one precedent
bkardell: Think there's been 1000 times that's been suggested, and
push to not do that
TabAtkins: One precedent: details
TabAtkins: For similar reason to details, nice thing about directly
manipulating attribute than a hidden state
TabAtkins: don't need to expose a new way to report actual value
TabAtkins: and don't need to expose to CSS using custom selector
TabAtkins: just use regular attribute selector
TabAtkins: As long as attribute value is easy enough to work with,
and this one will be simple,
TabAtkins: there are usability benefits that come with this for free
cbiesinger: Value attribute of input?
TabAtkins: Those don't change
Rossen: OK, thanks for introducing topic, chrishtr !
Rossen: People wanting to participate, please do so at links provided
<chrishtr> Issue for rendersubtree: https://github.com/whatwg/html/issues/4861
<br duration=25min>
Received on Friday, 4 October 2019 22:51:19 UTC