- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 23 Apr 2020 06:15:54 -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.
=========================================
Virtual F2F
-----------
- The virtual F2F will be two days, April 29 and 30. There are two
possible time slots so working group members are asked to mark
on the wiki ( https://wiki.csswg.org/planning/virtual-spring-2020 )
what time zones work for them and what topics they would like to
attend. This will allow the chairs to decide which timeslots to
use and how to schedule the agenda topics.
- The F2F will be held over Meet with links sent out to the private
list once the timeslots are decided.
CSS Position
------------
- TabAtkins and fantasai will be added as editors to CSS Position
CSS Values & CSS Images
-----------------------
- There was wide interest in allowing trailing commas in many or all
functions (Issue #4968: Allow trailing comma in gradient
functions (and probably others)).
- Selectors have a higher risk of compat problems so may need to be
excluded.
- Media lists of @media will also allow trailing commas.
- Trailing commas will be omitted for serialization.
- Trailing commas only are allowed at the end of a block, not in the
middle.
- Since handling trailing commas is something done by some
preprocessors research will be done to see the popularity of the
functionality.
- TabAtkins will write up proposed text for review and resolution.
CSS Contain
-----------
- RESOLVED: Accept the comment at the end of
https://github.com/w3c/csswg-drafts/issues/4946
(editorial: Paint Containment description is
incomprehensible)
- "The contents of the element including both the paint of the
descendants and their geometry" becomes "The contents of the
element including any ink or scrollable overflow"
- "This is as if overflow: visible was changed to overflow: clip
at used value." becomes "The behavior is described in this
paragraph is equivalent to changing overflow:visible into
overflow:clip at used value time, while leaving other values
of overflow unchanged."
- The above resolution will be added as an errata to Contain L1 once
some other editorial items raised have also been resolved upon.
- RESOLVED: Move what is known as subtree-visibility into CSS
Contain L2 (Issue #4843: subtree-visibility CSS property)
- RESOLVED: Make vmpstr a co-editor of CSS Contain L2
- RESOLVED: Rename subtree-visibility to content-visibility
CSS Sizing
----------
- The proposed text to handle scrollbars when intrinsic-width is >
width needed to take into account when the scrollbar size is
affecting the intrinsic-size.
===== FULL MINUTES BELOW ========
Agenda: https://lists.w3.org/Archives/Public/www-style/2020Apr/0015.html
Present:
Rachel Andrew
Rossen Atanassov
Tab Atkins
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Dave Cramer
Elika Etemad
Simon Fraser
Megan Gardner
Chris Harrelson
Dael Jackson
Brain Kardell
Brad Kemper
Vladimir Levin
Chris Lilley
Peter Linss
Myles Maxfield
Florian Rivoal
Cassondra Roberts
Devin Rousso
Jen Simmons
Alan Stearns
Miriam Suzanne
Scribe: dael
Rossen: Let's get started
Rossen: Any extra agenda items?
fantasai: TabAtkins and I would like to take on editorship of CSS
Positioning modules
Rossen: Okay. Other topics?
Virtual F2F
===========
<Rossen> https://wiki.csswg.org/planning/virtual-spring-2020
Rossen: Before we jump into topics- I wanted to talk about next week
Rossen: We sent out an email to the private list. There will be a
couple of 4 hours time slots that are intended to be kind of
okay for most people.
Rossen: Time slots are Apr 29th which is around this time and on Apr
30th. Take a look at the F2F page I pasted above.
Rossen: Please add yourself to participation table. If you're adding
topics to the wiki please add your timeslot preference to
the agenda item table so we can shuffle topics on their date/
time preference
Rossen: Questions or comments?
<fantasai> https://wiki.csswg.org/planning/virtual-spring-2020
Rossen: One last thing, we didn't resolve on virtual meeting
software.
Rossen: Lost time we had a conference call with the Font Loading
folks Hangouts seemed to work fine. We propose sticking with
it unless there's strong opinions or reasons.
<chris> +1 to Hangouts
<dbaron> Isn't this "Hangouts Meet" rather than just "Hangouts"
<astearns> meet
<dbaron> aka meet.google.com
Rossen: It's called Meet, sounds like.
Rossen: When we set up the links we'll send out the Meet links
CSS Position Editors
====================
Rossen: I'm fine with adding TabAtkins and fantasai
Rossen: I'm the sole editor and haven't had time to work. Happy for
them to do it.
Rossen: Opinions or objections?
Approved: TabAtkins and fantasai editors to CSS Position
CSS Values & CSS Images
=======================
Allow trailing comma in gradient functions (and probably others)
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4968
Rossen: TabAtkins or AmeliaBR?
AmeliaBR: I can talk about it if no one else wants to
Rossen: Are we prepared? This was added by fantasai
AmeliaBR: Some in issue discussion
AmeliaBR: Feature request is to support a trailing comma in comma
separated lists. Example was in a gradient function where
adding or removing function stops and in course you have
to fuss with making sure last item doesn't have a comma.
That's annoying and can make diffs on version control more
confusing
AmeliaBR: I commented that it's not just inside gradient functions.
Same irritation when editing background or text-shadow
lists
AmeliaBR: Remove one item and commas are all messed up
<castastrophe> +1
AmeliaBR: Valid comment from oriol is sometimes things get confusing
in syntax in that we don't just have comma separated list.
We have a comma separated list followed by something else.
Like BG where final includes the color which is different
AmeliaBR: Will be some fiddly issues about getting best way to
define without breaking.
AmeliaBR: More general concern about trailing commas?
<dbaron> Is the proposed rule "allow just one trailing comma", or
will there be other extra commas allowed?
TabAtkins: Note my comment that oriol's concern isn't something to
worry about. We already have possibility of successive
commas in grammar. If you have a # multiplier followed by
extra comma it's invalid 2 commas next to
TabAtkins: General is # multiplier for comma list allows trailing
comma. Any property with explicit comma or function with
explicit allows final comma after syntax.
TabAtkins: I think that ends up covering everything. I think we can
define without special case.
AmeliaBR: You'll write up?
TabAtkins: Definitely. Very much in favor because JS supports this
everywhere. I support having a similar syntax in CSS
<chris> sounds great, do it Tab
florian: Anyone looked at compat?
TabAtkins: It makes invalid things possibly valid which we're
usually fine with. Because it looks weird if you're not
doing it I would be surprised at accidental usage
florian: If you say it's in JS and people want it it seems there's
demand for syntax and disappointed it doesn't work. Could
be left in stray stylesheets. I'm concerned because if
you're trying to do this on a whole bunch of properties and
functions if it's compatible in most but not all we end up
inconsistent
TabAtkins: I suspect number of cases is 0. Even if non-0 but low
number I'm okay with it. As long as it's small number of
weird cases just like we have some functions allowing
0deg without unit I'm okay with a few exceptions. I don't
think we'll need to
chris: Benefit outweighs risk of an oops somewhere.
emilio: Does that allow inside [missed]?
TabAtkins: I think it should. For same reason to allow easy re-order
I suspect it should allow
emilio: Seems weird to special case comma but I guess it's most
common
TabAtkins: Only separator we use in this case.
TabAtkins: Slash is a one off. Not used like commas in a way it
would benefit
fantasai: The only other separator we use for lists of undefined
lengths is a space. That's the other one
florian: About selectors it does make me worry about compat. I've
done it multiple times. Probably some stray ones where I
forgot to remove and I doubt I'm alone
chris: Trying to get rid of commas but allowed like rgb with a
trailing comma acceptable?
TabAtkins: Comma form of grammar, yes
TabAtkins: To florian's point- reasonable. If it ends up being that
we can't do selectors I'm okay with that.
dbaron: If we're going to do functions and selectors should we do
media lists for @media?
TabAtkins: commas are allowed?
florian: Yeah, old syntax for "or"
dbaron: @supports doesn't have commas, but @media does
TabAtkins: Then yes, that too
smfr: Seems weird to allow for bounded lists. If you do rgba it's
weird for comma after. I guess this doesn't propagate into
computed style, right?
<fantasai> +1 to smfr
TabAtkins: Computed style - correct we omit from serialization.
TabAtkins: First point, I don't agree limit to unbounded. In JS it's
allowed in function argument which are usually bounded.
Worthwhile to take long items and have trailing comma. I
think it's reasonable here.
TabAtkins: True most color functions are short so no reason to put
it there, but if everything else allows you want to be
consistent
smfr: Mental model is comma is you can add an extra thing and that's
not bounded list
TabAtkins: Should be comma is a potential item. Basically same as ;.
It separates properties but we think of it as an ender
fremy: You can also re-order them. If the last one doesn't have a
comma you have to remove it. Even for lists where you can't
add you can re-order arguments
<astearns> This seems like a good candidate for a preprocessor
feature. Is it widely used in any preprocessors? If not,
is that a reason not to add it to the language proper?
drousso: What about when you can omit last semicolon in rule?
<dbaron> We also allow "color: red;;; background: blue"
TabAtkins: Can you elaborate in terms of the problem?
drousso: If you had something like a list of box-shadows as last
rule. Allow trailing comma without semicolon after?
TabAtkins: Yes. Totally fine and not a syntax problem
drousso: Okay
AmeliaBR: Closing brace is the endpoint. Comma has no special meaning
<Rossen> minmax(10, 20, ) is odd
<castastrophe> q: If the syntax is accepted, does that necessarily
mean that's how it appears as the computed value? If
you view the computed values of a property that has a
function with a trailing comma, would the comma be
stripped?
<astearns> castastrophe: I heard earlier that the comma would be
stripped from the computed value
<castastrophe> astearns +1 makes sense
oriol: Concern with trailing comma if grammar has something after in
the list. Could create ambiguous grammar. If you have a list
of items separated by comma and at end you have a final
optional item. Right now if value is a,b,c it's a 3 item
list. If you have a,b c you have c as final item
oriol: Optional comma with a,b,c it's not clear if you have list of
3 items with last omitted or if there's 2 and the , after b
is trailing.
<AmeliaBR> example for oriol's point: a `background: url(image.png),
blue` is different from `background: url(image.png) blue`
oriol: Not clear what we gain from allowing comma after any list.
Better to allow at end of function before parentheses or
value of property before ;
<fremy> @oriol: yeah, but that's bad design in the first case ^_^
TabAtkins: Case you outlined I don't believe exists in CSS. Ignoring
comma it's a bad design to have suffix implicitly separate
AmeliaBR: Have example, bg list
TabAtkins: Comma separates final layer. oriol talking about a #
multiplier, a space, and than more stuff.
AmeliaBR: Because bg list has a literal comma that literal comma
would superseded the optional trailing comma for parsing
and any other properties with that pattern need similar
syntax?
TabAtkins: Not quite. Because literal comma it's comma separate list
with final item having different grammar. In oriol's case
we have comma separated list with then more stuff but no
separator. Have to recognize list has ended. Could be
less clear with final comma. If grammar of stuff and
comma separated items is potentially ambiguous looks like
one more item in the list
TabAtkins: Theoretically valid, but I don't think we do it
dbaron: Similar is font shorthand. Explicitly the comma separated
list is last
TabAtkins: We do that a few times. It's not made ambiguous by this.
Suffix thing we don't do
oriol: I think that we are not gaining anything by letting this and
we get potential ambiguity. If we allow trailing comma after
trailing we get he same without the ambiguous.
TabAtkins: I think you're right. Given they're at the end of the
grammar just allow at end if fine
emilio: Prefer that. Lower level we define the less random interop
bugs we'll find. Like someone handling parsing forgot the
trailing comma. If we define they're at the end of the block
that's much preferable than sprinkling it around
Rossen: Point of order. There's a bit of excitement to have this.
There's a number of cases that have to be discussed before
we see the final shape of where trailing commas are allowed.
With that we can resolve on adding the trailing commas and
see what details are after you've spec text
<castastrophe> What about putting together a table of examples?
Rossen: Also we have a queue.
astearns: To back up a bit. I've heard people talking about details
on how it's possible but didn't hear much about motivation
so I'm not sure people are enthusiastic. Seems this could
be a pre-processor feature and I"m not sure it's been
impl. Does anyone use this for CSS in preprocessor?
<miriam> yes, it works in Sass
TabAtkins: Do not know. This is preprocessor-able
astearns: miriam says it works in Sass
<jensimmons> could miriam talk about this a bit?
astearns: Should look at how it impl in Sass and see if it's
popular. If it's not popular don't know why we should add
<miriam> at least in many cases, I'd have to look closer at every
instance
TabAtkins: I was going to suggest, it was useful to get general
support. I'm happy to explore further in issue and get
resolution later
miriam: I know it's popular in many Sass places. I don't know all
the use cases. Would have to look closer in where we allow
it. That can also happen later.
Rossen: Great, thank you
<castastrophe> Now I'm wondering if postcss supports it
Rossen: We'll get a resolution with a more concrete proposal.
Ideally miriam you can help with Sass popularity
CSS Contain
===========
editorial: Paint Containment description is incomprehensible
------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4946
florian: Mats has found there's places we're vague and non-standard.
First is we mention things that must be clipped include
content and paint and geometry of description. Not defined
terms. I think it was ink and scrollable overflow
florian: Should replace the phrasing
TabAtkins: Yeah
florian: Second part is in a note we say as if overflow:visible was
changed to overflow clip as used value. Proposing we
replace with "The behavior is described in this paragraph
is equivalent to changing overflow:visible into
overflow:clip at used value time, while leaving other
values of overflow unchanged."
florian: I'll tweak to be explicit about overflow-x and -y in case
it's different values
Rossen: Sounds great
smfr: Is scrollable overflow defined?
florian: Yes
smfr: Descendants you need to be clear paint order? containing block?
<fantasai> smfr, definitions of overflow:
https://www.w3.org/TR/css-overflow-3/#overflow-concepts
smfr: I mean z order descendants. Stacking context
florian: If we mean all do we need to disambiguate?
smfr: All is unclear. dom node? A child can break out if position
absolute. I may not paint as descendant if it has z-index
<chris> +1 to smfr say which tree they are descendants in
florian: I think we're talking about all starting from dom. Whether
positioned or painted they're part of all
smfr: Then have to create containing for positioned and stacking
florian: Think it does
smfr: And containing block for fixed?
<fantasai> https://drafts.csswg.org/css-contain-1/#containment-paint
dbaron: Does for fixed and abs and stacking contexts. Bullets 2 & 3
in ^
Rossen: Any other questions or opinions or good to resolve?
florian: One question. Correct phase to say all descendants? All DOM?
fantasai: All ambiguity resolves to same thing doesn't matter.
florian: We have later bullets to say if it's all it works.
fantasai: What's the interpretation that doesn't mean all? Ambiguous
about can't resolve to anything that's not what you meant
so it doesn't matter
smfr: It's fine
<Rossen> https://github.com/w3c/csswg-drafts/issues/4946#issuecomment-614501289
Rossen: Objections to proposal here ^
florian: Proposal: Accept the comment at the end of
https://github.com/w3c/csswg-drafts/issues/4946#issuecomment-614501289
RESOLVED: Accept the comment at the end of
https://github.com/w3c/csswg-drafts/issues/4946#issuecomment-614501289
fantasai: Want to resolve to update recommendation?
Rossen: This is WD
florian: L1 is a rec
florian: L2 is a WD, but L1 is rec and phrase is in both
Rossen: oooh
chris: Should be an erratum. Are there any others we can roll in to
a publish?
florian: I need to check
florian: Let's move on with agenda and I'll get back about if there
are more in the queue
<AmeliaBR> No errata for contain 1:
https://www.w3.org/Style/2019/REC-css-contain-1-20191121-errata.html
subtree-visibility CSS property
-------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4843#issuecomment-611131666
<fantasai> topic of conversation is
https://github.com/w3c/csswg-drafts/issues/4843#issuecomment-616206403
Rossen: Before we jump into issue we have vmpstr who is new to the
group and going to co-edit. Welcome.
Rossen: Objections to add vmpstr as co-editor?
RESOLVED: Add vmpstr as co-editor
TabAtkins: Asking to put property into contain L2 which than vmpstr
is the co-editor of
Rossen: Last resolution was moving it on its own. So this is going
to go in to...
fantasai: Last resolution didn't say where. I flagged and suggested
move into CSS Contain L2
vmpstr: Can we change the name to content visibility?
fantasai: Let's do separately.
Rossen: Add it first and then rename. And than name again during
LC :)
Rossen: Objections to moving the spec into CSS Contain L2?
RESOLVED: Move what is known as subtree-visibility into CSS
Contain L2
Rossen: We'll make vmpstr a co-editor. Objections?
RESOLVED: Make vmpstr a co-editor of CSS Contain L2
Rossen: Last request was rename into content-visibility?
vmpstr: Yes
<fantasai> +1
Rossen: Opinions? Concerns? Objections?
RESOLVED: Rename to content-visibility
Rossen: Is that it on the issue?
Errata for L1
-------------
florian: For the republish REC there's another open issue from Mats
so let's wait to wrap that up.
CSS Sizing
==========
Scrollbars when intrinsic-width is > width?
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4415#issuecomment-614345165
fantasai: Does the phantom content area thing also effect scrollable
area? If it does only the contained element or also
contents outside of the element?
TabAtkins: Cases for first is your container is 100px x 100px and
overflow:auto Set contain-intrinsic-size to 200x200 We
say you did your child and results in 200x200 and you
have scrollbars. We believe you should get them.
Objections in issue were from a previous definition
TabAtkins: If you have overflow:visible and contain-intrinsic-size
to be overflowing value does it set scrollbars elsewhere
AmeliaBR: Clarification: does the contain-intrinsic-size otherwise
trigger containment or are you expected to set type and
then size?
TabAtkins: Only applies if size-containment is on
AmeliaBR: So it's separate property. Doesn't size-containment
already have effects on if you're triggering scrollers on
ancestors?
TabAtkins: No, layout does.
AmeliaBR: My instinct is keep it as simple as possible and require
containment property to spec any trapping of scrolling and
whatever
TabAtkins: So it should cause overflow in those cases?
AmeliaBR: Behave same as if child contents had been laid out and
generated that intrinsic size
vmpstr: Combined with actual child content? Union of 2?
TabAtkins: For scrollbars calculation yes. It does get combined with
actual children
cbiesinger: When you say calc scrollbars do you mean presence?
Scrollbars can effect size.
TabAtkins: Scrollbars don't increase size of element, just content
AmeliaBR: Came up on issue, is intrinsic with or without size of
scrollbars. Do you add it on top?
TabAtkins: Scrollbars decrease size of content area.
cbiesinger: It can in the block axis. It can also get larger in the
inline axis, at least in chrome, if it is
shrinkwrapped-sized
TabAtkins: Can't be the case...wait...if you turn on overflow scroll
then scrollbar adds to content area. If you have overflow
auto that will never increase area in a way problematic
here.
TabAtkins: Only time it will trigger is if you have fixed height
cbiesinger: Auto height and you set multiplier overflow in inline
axis increases size in block axis
Rossen: Only if height is fixed so it is stable
cbiesinger: Why is height fixed?
Rossen: Because for intrinsic size purpose you always fit if auto
fantasai: Scrollbars increase in opp size of scroll. cbiesinger is
correct
TabAtkins: So yes, if you trigger scrollbar on bottom of element the
height would be contain-intrinsic-size height + scrollbar
cbiesinger: Still doesn't matter if has to be union because you
don't know actual content size. If guess that's the
answer is you don't use the union for purpose of
scrollbar presence
TabAtkins: Yeah.
TabAtkins: Actual content should not effect the size for purpose of
telling if have scrollbars...i guess...once you do...
TabAtkins: Back up. I think this is a diversion. Need to answer, but
I don't think effects current q. Should
contain-intrinsic-size if larger than spec size trigger
scrollbars
AmeliaBR: I think my argument is same, it should behave same as if
you had one child element of that size and anything about
scrollbars fall out of that
cbiesinger: So against using union of actual size and
contain-intrinsic-size?
AmeliaBR: Whole point of contain-intrinsic-size is replace calc
actual size of child content
florian: Not sure it's equivalent. If regular block yes, but
multicol for example...
TabAtkins: She misspoke. It's the result of laying out your content.
AmeliaBR: Yeah.
TabAtkins: Not on children, it's just easy to say accidentally
Rossen: We're about 5 minutes before and fantasai wanted to go over
F2F. Can we close on this or continue in issue?
TabAtkins: There's further detail question, but should not effect
how actual content of a contain-size element. If actual
content can pop a scrollbar that will continue to. If
can't will continue.
florian: TabAtkins I stopped watching on GH a while back. Your
assertion that my concern used to be valid I don't
remember. Can I just trust you?
TabAtkins: I think you can. It was about images not triggering
scrollbars.
fantasai: I suggest we pick this up later and do F2F
Virtual F2F
===========
fantasai: There were error in timezone conversions. They were chosen
to max participants. Timeslot A is really unworkable for
heycam but okay for everyone else. Timeslot B we get
heycam but lose a lot of EU.
<dbaron> I'd note that this teleconference is a biased sample. :-/
<dbaron> since the people who can't make slot A also can't make this
call
fantasai: Wanted to ask if people wanted to use first timeslot for 2
days or maybe shift it one hour earlier and that might
give us an hour with heycam.
fantasai: I don't know how many people would drop for 10pm-2am in EU
but maybe worth a different time slot.
<fantasai> https://wiki.csswg.org/planning/virtual-spring-2020
<florian> I'm neutral
<dbaron> The other possibility is using something like slot B but an
hour or two earlier
<rachelandrew> as an early bird I'm not going to be any use in
timeslot B :)
Rossen: One of the attempts to order topics on timeslot preference
would have given us that picture of do we need timeslot B.
No topics set with preference. With heycam not here
fantasai: dbaron timeslot B earlier was your suggestion but heycam
said 6am+. Might as well be in timeslot A if timeslot B
not useful
fantasai: Would be good if everyone filled out survey on wiki
fantasai: Should think about if it makes sense to use timeslot A both
Rossen: If people vote with timeslot availability and topics desired
it will be easy to make a decision. Please fill out the
wiki. That will make the decision quickly.
dbaron: It's worth asking heycam explicitly about a 5am start.
Rossen: Please go and move topics around in terms of timeslot
preferences if it's a topic you want to be there for. That
will help us organize it.
Rossen: Alright, until next week. No conf call next week, but first
session of F2F. We will send the actual meeting details to
the private list with a link to the Meet.
Rossen: That's everything for today. Thanks for calling in and be
safe.
Received on Thursday, 23 April 2020 10:16:46 UTC