- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 3 Dec 2020 06:19:05 -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.
=========================================
Next F2F
--------
- On the next call the group will decide when to hold our next
virtual F2F. Anyone with thoughts in can send them to the
private list or come prepared to discuss on the next call
CSS Contain
-----------
- The group discussed if creating a way to indicate content which is
not currently visible should be searchable is a problem they
want to solve before going into details of if the proposed
content-visibility: hidden-matchable property is the right way
to do it. (Issue #5595: Proposal: content-visibility:
hidden-matchable).
- The main concern expressed with such a property is that it
removes the optimizations allowed by visibility:hidden and
display:none and could therefore be expensive to the
browser.
- One suggestion to address it was to allow the content which is
content-visibility:hidden-matchable to be lazy-indexed
instead of being indexed on first load.
- Discussion on this and the rest of the issue will continue on
GitHub
- RESOLVED: Have separate keywords for the visible and contained
value vs initial value (Issue #5695: Apply containment
on `content-visibility: visible` ; use `normal` as
initial value)
- The name of the properties will be discussed further on GitHub
and then brought back to the group.
- miriam introduced the current status on the discussion for 1
dimensional container queries (Issue #1031: Do we need size
containment in a single dimension to enable container queries?).
- There are two different, and not necessarily mutually
exclusive, solutions being discussed:
1) The "pinky promise" solution where when you get the width
of the container query you say that you won't do any of
the behaviors which would change the width later.
2) The "plug the leaks" solution is to address issues as
they're discovered. Currently, there are only two known
issues both of which have potential solutions. Given that
people have been thinking about this for a while and only
found two issues, it's likely that there aren't many more
leaks which are unknown.
- Both solutions were discussed and both could be viable
solutions. Discussion will continue on GitHub.
Motion
------
- RESOLVED: Invalid path strings make the syntax invalid at parse
time (FXTF Issue #392: The computed value of
offset-path: path(' '))
- RESOLVED: Empty path is considered invalid (FXTF Issue #392)
Pseudo Elements
---------------
- The desire with spelling-error and grammar-error is to create some
spec text which says UAs may take steps to prevent
fingerprinting and give disallowing loading external resources
as an example. Fantasai will draft up sample language for the
group to discuss and resolve on. (Issue #5731: Privacy
considerations for external resources)
CSS Sizing
----------
- RESOLVED: [The contain-intrinsic-size] property takes 4 longhands,
logical and physical, which have a normal value (Issue
#5432: Allow specifying only one dimension for intrinsic
sizing)
- A separate issue will be opened on github about if there is
value in defining a 'none' property for contain-intrinsic
size.
===== FULL MINUTES BELOW =======
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Dec/0002.html
Present:
Joey Arhar
Rossen Atanassov
Tab Atkins-Bittner
Hui Jing Chen
Elika Etemad
Brandon Ferrua
Simon Fraser
Chris Harrelson
Daniel Holbert
Dael Jackson
Brian Kardell
Vladimir Levin
Daniel Libby
Ting-Yu Lin
Peter Linss
Alison Maher
Cameron McCormick
Tess O'Connor
Florian Rivoal
Alan Stearns
Miriam Suzanne
Jeffery Yasskin
Regrets:
Christian Biesinger
Mike Bremford
Chris Lilley
Morgan Reschenberg
Lea Verou
Greg Whitworth
Scribe: dael
Rossen: It's a couple minutes past the hour
Rossen: We should get going
Rossen: As usual I wanted to ask if folks had additional agenda
items or changes
Rossen: Only extra I have, and we'll discuss next week as well, it's
time to start planning our next F2F/virtual meeting
Rossen: We usually have more people showing up to regular call time
so we'll decide there, but start thinking about times and
drop a link to the private list
<fantasai> Oh, I have an item:
<fantasai> I'm preparing css-text-3 for CR
<fantasai> if anyone has any concerns with that
<fantasai> or wants to do a last review or anything...
<fantasai> just a heads up, I'll be requesting a transition soon
CSS Contain
===========
Proposal: content-visibility: hidden-matchable
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5595
jarhar: Couple of things I'd like to resolve quickly
jarhar: Like to resolve 1) do we have agreement it's useful to have
a way to specify hidden content that's searchable in general
jarhar: 2) Seems like in previous discussions we've talked what
algorithms and things the searching should be exposed to.
I'd like to get resolution that this feature should work for
all methods of searching UA provides and all web APIs for
searching
jarhar: If we get those then we can discuss if
content-visibility:hidden-matchable is right
jarhar: Issues with in general having this feature?
Rossen: Question here, we're talking about searching and a lot of
that doesn't lend naturally to css. Meta question for
searching is if content presented visually is also available
in the DOM so it can be indexed and searched
Rossen: And how does that relate to assistive technologies and other
layers using that approach. Those are the layers to hit
before answering if searchable. Is that fair?
jarhar: Was question about a11y? There has been discussion on GH
about a11y. Earlier Chris mentioned previous discussion
about how a11y tree shows content-visibility:auto or hidden
content
Rossen: My question was if this hidden-matchable is presented to
a11y it sounds like your answer is most likely yes it's
visible so question is about if it's visible to search
chrishtr: Question is if it's good to have a way to have content in
dom which is hidden from visual display but exposed to
ways to search in the document, find in page, reader
modes, a11y tools. Correct?
Rossen: Yes. And how and where does css play a role since it's
mostly visual layer
Rossen: If what you're saying...if all the methods you described
will be able to get to the content besides what we paint on
screen I think the answer lends easily for if it's available
to search
Rossen: I think I got my answer. Want to go to queue
smfr: Two points. One is content-visibility as I understand is
optimization so UA doesn't have to build render tree. Issue
with allowing finding inside is if UA on every page load tries
to look for readerizable content it means every page load your
hidden-matchable content will still need to be figured out
enough to give right answer to indexing code. So you lose the
optimization
<fantasai> [smfr mentions that 'visibility' and 'display: none' need
to be resolved, for example]
smfr: Second, anybody who wrote browser code knows you have to think
about is content hidden by style, hide from APIs not just
visually. display:none does, visibility:hidden sometimes does.
Now we have 2 more and I'm uncomfortable adding more
variations to is this content available in this scenario
chrishtr: Yes, if UA on initial load always indexes and goes into
hidden-matchable subtrees performance advantage is lost. I
would recommend doing it in a smarter way that doesn't
interfere with performance
chrishtr: This is an additional feature which is different and
therefore has a cost of implementation complexity. It is
useful, though, because it's common to have collapsed
sections or offscreen that's not rendered for performance
but should still be searchable. For that reason I think
it's justified
smfr: I think you said for first point that yes UA has to do the
work and in some UAs the advantage can be lost but depends on
what UA does.
chrishtr: I would say it depends on what UA is allowed to do and UA
should be allowed to index. There are definitely
performance footguns to avoid
<florian> [In the abstract, I feel comfortable with the intent of
proposed resolution 1 and 2 as initially exposed, but the
concerns raised by smfr seem very relevant to me]
Rossen: smfr does that satisfy your questions?
smfr: I guess. It seems unfortunate that the UA can trigger
potentially expensive content building in this case
florian: Clarification question. smfr if I'm hearing you in your
view searching and indexing are not separate. Index powers
the search. Or is index for something other than search?
smfr: Original objection was why is ctrl+f special. There's more
indirect methods. Safari indexes and in other parts of OS you
search and get the webpage. And ideally the results would be
the same as you ctrl+F on the web page. That's why we're
saying it should be same results.
TabAtkins: Seems like that's what this is intending to do better.
Something hidden-matchable is intended to be exposed.
ctrl+f is off of dom
smfr: It doesn't. ctrl+f doesn't find display:none things. So we run
off of display:none type things resolved. If you have
display:none inside content-visibility: hidden-matchable
content you don't want that to show
TabAtkins: So you're talking about expensive rendering is pulling
something from dom so it shows up in structure for
indexing
smfr: Right and thats up until you render which is fairly expensive
chrishtr: There is a significant cost, yes. UA should be allowed to
index but do so in a way that doesn't harm performance.
This is an additive thing because shouldn't index things
that are display:none. It's an advantage to a11y but UA
needs to be careful on how you schedule work
florian: Could do most of the page and have hidden-matchable as lazy
parts. People don't search in a millisecond of load
chrishtr: Right, something like lazy background processing
Rossen: We're in the time allocated. I don't hear alignment to
resolve on the two initial asks. I also see lots of
conversation in GH. Happy to give it another 10 minutes next
week if the general consensus is achieved on issue
Motion
======
The computed value of offset-path: path(' ')
--------------------------------------------
github: https://github.com/w3c/fxtf-drafts/issues/392
fantasai: I don't know much on this, but it seemed we should resolve
and fix.
heycam: The ultimate issue is we have path function which takes
string value. string is svg data string.
heycam: Some strings are invalid. What does that mean for validity
of path function. If you use invalid path string inside is
it all parse as invalid and dropped or is string preserved
and invalidity handled later
TabAtkins: If it's valid how to serialize and if not valid clarify
that
florian: Is there precedent in other properties
fantasai: In grid we throw out what's invalid after parsing
florian: Same here?
heycam: No reason not to
florian: No architectural complexity so seems like right thing to do
TabAtkins: Larger question then what's asked in issue. If you have
invalid pass it's a separate question. The empty string
specifically is a valid path per svg grammar but it
disabled rendering of paths. Question is how is it
canonicalized and serialized. In chrome it's serialized
as none. All other paths stay as paths but none doesn't
so doesn't create containing block
heycam: Surprises me. I think it then does not make sense to
serialize as none
TabAtkins: If we decide to treat as invalid that's okay with me and
this solves itself. If we want that we should record it.
It's about if empty path is valid or not.
florian: Is it useful?
TabAtkins: No
florian: Then make it invalid and see if world breaks
TabAtkins: Invalid is probably more consistent with chrome behavior
fantasai: 2 resolutions?
heycam: In issues it's also mentioned strings with only whitespace.
Same?
florian: Suppose so
TabAtkins: Yeah. Regardless of specifics of svg grammar shouldn't
treat different
Rossen: Can someone summarize?
TabAtkins: 1) Invalid path strings make the syntax invalid at parse
time
Rossen: Objections?
RESOLVED: Invalid path strings make the syntax invalid at parse time
TabAtkins: 2) The empty string is an invalid path string
florian: With whoever does the edits being careful for all empty
types
fantasai: Basically 0 length path
fantasai: 0 length path description
TabAtkins: If we say it's empty we can deal with specifics later
florian: Empty path not empty string
Rossen: Empty path is considered invalid
Rossen: Objections?
<heycam> "a string with no path commands in it", maybe
RESOLVED: Empty path is considered invalid
Rossen: Anything else?
CSS Pseudo Elements
===================
Privacy considerations for external resources
---------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5731
TabAtkins: Rune realized that the spec for spelling-error,
grammar-error, and related pseudo has privacy bits about
not detecting spelling dictionary
TabAtkins: As written spec allows you to load a background image
which would allow you to have a trigger on spelling
errors. He proposes we disallow loading of external
resources for styling on spelling and grammar errors
florian: Is there a existing definition of external resources?
TabAtkins: Probably not one we can link to
TabAtkins: I think it's reasonable to gloss over for now
florian: Thinking of things like data urls. If there's an existing
definition we can work from it would be nice
hober: We already have visited. We do a lot of restrictions on what
can do on visited including loading of external resources.
Why not limit in same way?
TabAtkins: I believe visited excludes loading other backgrounds.
Okay with that restriction even if more than we need.
hober: I think consistency is valuable. Even if it's a little more
restricted it simplifies model
fantasai: Isn't visited under-defined?
TabAtkins: Some of details yes but what properties is well defined.
fantasai: I think a lot of your ideas were in a PR we couldn't merge
TabAtkins: That was about how we apply them, not what properties
<fantasai> TabAtkins, https://drafts.csswg.org/selectors-4/#link
doesn't seem to have any details
<TabAtkins> Yeah, you're right fantasai, we don't actually have the
list in the spec, I was misremembering
jyasskin: Wanted to ask how much worrying about Spectre which can
detect color changes. I've heard about partitioning
visited which wouldn't work for spelling
florian: Both are fingerprinting risk but data from visited is
itself valuable independently of fingerprinting. If it's
easy to be consistent that's interesting. But more
important to hide visited
<dholbert> https://developer.mozilla.org/en-US/docs/Web/CSS/Privacy_and_the_:visited_selector
is relevant (to the extent that it's accurate, which I
think it is?)
florian: I'm saying it's related. We're less worried about the
attack then on visited
florian: I think this is privacy sensitive only because
fingerprinting. visited is privacy not just fingerprinting
but the actual data. Protecting the data itself is relevant
on visited. I don't think it is here.
dholbert: I think visited restrictions could be problematic here.
afaict it just limits you to properties that control
colors and wouldn't allow add/remove underline which is
main thing you want with spelling/grammar. It limits you
to a couple properties and doesn't say you can't use
external
Rossen: What do we do with this?
fantasai: I think we can't align with visited. Current definition is
the UA can do stuff to hide the visited-ness of the link.
There's no details.
fantasai: We can be more precise here and say not loading external
resources
fantasai: I can draft up wording what you can do stuff to preserve
privacy such as not loading external resources and then we
can have a more complete definition in the future that's
general and we link to it
florian: wfm
Rossen: Other opinions?
Rossen: Is there a 1 line resolution we need?
Rossen: Or continue in thread
hober: Depends on the text
fantasai: I'll draft up text and we can come back
Problems with styling ::first-letter with punctuation
-----------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2040
fantasai: Let's skip for now.
CSS Grid/CSS Flexbox/Quirks
===========================
Avoid percentage height quirk in new layout models
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5545
Rossen: We'll need to do this in EU-friendly time
CSS Sizing
==========
Allow specifying only one dimension for intrinsic sizing
--------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5432
vmpstr: Added contain-intrinsic-size property. Takes 2 values. Can
take 1 to apply it to width and height. Got feedback it can
be confusing if dev only wants to specify in 1 direction
vmpstr: Proposal is to make contain-intrinsic-size be a shorthand
for additional values like contain-intrinsic-with and
contain-intrinsic-height
florian: Which would have normal value
vmpstr: Yes. And because only during size containment it falls back
to what the size would be
vmpstr: Other is do we add width, height, and block sizes
florian: I'd go logical only. Or maybe all 4
vmpstr: Don't have preference. Feel like fewer is better
florian: I wouldn't do physical only
fantasai: Reason why we're proposing to physical is to be consistent
with size property we end up having. Main reason we don't
have size property is naming conflict.
fantasai: Anticipation is size would have physical. That's why ended
up making physical
florian: Sure. It's a mess so let's stick with the mess. Concept is
reasonable and easy
vmpstr: Logical, physical or all
florian: I think what fantasai said overrides. We're in physical land
vmpstr: Both?
Rossen: I think both
fantasai: There's a size property with all. If we have
contain-intrinsic-size with a longhand it should
presumably have all
vmpstr: Makes sense. That's the proposal
heycam: Confused from comment in issue if you say
contain-intrinsic-size: 500px shouldn't it be like none
vmpstr: Only takes effect during size containment
florian: I think it should be normal or none. Intrinsic size can be
non-0.
vmpstr: I was giving when it would be 0. Should be default intrinsic
width with a specified intrinsic height
florian: I'd go with normal. None seems to override. Normal seems to
be do whatever you'd do if we didn't spec this
heycam: Is there a distinction where you might want to say there is
no intrinsic size?
florian: If you want none you can say 0
heycam: But is that different?
fantasai: I think if there's overflow scroll it's different.
florian: I think we can resolve on normal and come back to if
there's a use case for none
heycam: Sounds good
Rossen: Sounds like we've arrived at resolution. heycam are you
happy now?
heycam: okay
florian: Proposal: Property takes 4 longhands, logical and physical,
which have a normal value
Rossen: Objections?
RESOLVED: Property takes 4 longhands, logical and physical, which
have a normal value
CSS Contain
===========
Apply containment on `content-visibility: visible` ; use `normal` as
initial value
--------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5695
TabAtkins: The issue here is that the hidden-matchable value
switches content between 2 behaviors. One identical to
hidden and one that's indescribable in current spec. That
feels weird, don't normally have auto that goes to
unrepresentable value
TabAtkins: Proposal the other behavior that makes things visible
should have an explicit keyword
TabAtkins: Original proposal in thread is to name that visible and
change the default to normal. Chris points out that it's
been shipped in Chrome so visible may be locked.
TabAtkins: I don't specifically want a name but I think we need the
property
Rossen: Is there data if it should be frozen?
TabAtkins: content-visibility as a property is 1% of page loads.
That gives reasonable sense there would be problems if we
change
fantasai: Cases where likely to break seem unusual. You have to set
it away from initial value and you would have to not be
using containment. Seems like most of use cases you'd use
containment with this or have explicit width and height in
which case no change in behavior if we made this change
fantasai: I don't know for sure, but I think there's a good chance
its safe. If there's a better keyword fine, but I think
the properties are better if we make normal the default
value
TabAtkins: I propose if people think general idea of the mode having
a keyword we resolve on that. Then move back to GH on
name and bring it back in a week or two
Rossen: Works for me
Rossen: Okay, let's continue there
TabAtkins: Can we get the resolution to make a keyword for this
behavior?
fantasai: Prop: Have separate keywords for the visible and contained
value vs initial value
Rossen: Objections?
RESOLVED: Have separate keywords for the visible and contained value
vs initial value
Do we need size containment in a single dimension to enable container
queries?
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1031
miriam: The context is in thinking about container queries and
starting from dbaron's initial proposal a few years back
miriam: Easy to imagine how it works with full size containment, but
doesn't work for most cases. Works in app-like cases but
otherwise falls apart.
miriam: Proposal is 1d containment so can contain width of element
and query against that but allow height to adjust.
miriam: Several cases where height of children changes width of
ancestors. Scrollbars and percentages in padding
miriam: A lot of talk about that making it quite difficult
miriam: Anders and I have been pushing on that.
miriam: Going through the ideas backwards because 2nd one is
thinking through how to address issues as they arise. If we
want 1d can we always trigger scrollbar on ancestors,
resolve percents to auto
miriam: Not full proposals, but want to push conversation forward
miriam: That's a start on how might address issues as edge cases so
1d containment would work
miriam: Anders proposed the pinky promise approach. Idea here is
what if we don't require containment on container queries
and we resolve the query as if we have full size containment
but allow you to make changes so you get different final
size then reported
miriam: Trade offs between but not exclusive of each other. A lot
more to resolve on both. Anders isn't here but that's basic
context
florian: Author usability I think pinky promise works. Cases where
children effect cross axis size are rare and easy to avoid.
florian: Concerned about implications on implementation because
makes layouts effectively stateful. If doing partial layout
you have to do a relayout to figure out size if you hadn't
inserted the children you did insert. Order becomes
meaningful as well which brings us back to having to do a
layout of the anti-page
florian: Not impossible, but could be expensive. I'm concerned. The
plug the leaks one by one seems more possible. We haven't
come up with so many examples. We've so far had 2. Maybe
can plus one by one
florian: Seems that by far dominant of 1d is query inline size, not
block. The leaks for inline and block are not same. Easier
to plug inline leaks. If we just worry about those maybe
slightly easier problem
bkardell: In the pinky promise thing doesn't that wind up negative
auto-height?
florian: No, the pinky promise case you do a container query against
width and then you say I won't do anything in layout what
would change the width of the parents. As long as you don't
have the cases that is does change width of parents
everything is fine
miriam: One other complication is inside of floats that shrink wrap,
container query would return 0 but layout is quite a bit
different
florian: Yeah. But for shrink-wrap this is fundamentally problematic.
<miriam> +1
florian: If there is a use case for that it's a whole different can
of worms
<iank> I'm somewhat not convinced the pinky promise will yield the
results web-developers expect.
Rossen: We're at time. Not sure if we have a resolution we could
call. I would urge you to continue discussing on GH
TabAtkins: Not looking for resolution yet, just general information
Rossen: Thank you all for calling. Talk next week
Received on Thursday, 3 December 2020 11:19:48 UTC