- From: Dael Jackson <daelcss@gmail.com>
- Date: Sat, 16 May 2020 06:41:52 -0400
- To: www-style@w3.org
=========================================
These are the official CSSWG minutes.
Unless you're correcting the minutes,
Please respond by starting a new thread
with an appropriate subject line.
=========================================
CSS Values
----------
- In order to create a shorter syntax for conditional values (Issue
#5009) TabAtkins proposed creating a switch property which
allows authors to set an integer to toggle between values
- There was a desire to see if this can be combined with the other
switch property proposed earlier in the F2F
( https://gist.github.com/bkardell/e5d702b15c7bcf2de2d60b80b916e53c )
in order to avoid two properties doing similar things. There was
a concern about when these switches run being different, though.
- Though this syntax is more terse there was a concern that it's not
easy to read for authors and may not work for every way large
teams set up stylesheets.
- It was suggested that a conversation should be had with
preprocessors to see how they've approached this problem.
- TabAtkins will add to the github issue a more fleshed out version
of his proposal for further discussion and review.
CSS Contain
-----------
- RESOLVED: Add ink-skip-clip-margin property (name tbd) with
non-negative values (Issue #4934: Add
contain-paint-margin CSS property), applying to
boxes with 'overflow: clip' or equivalent.
CSS Parser
----------
- The proposal to allow trailing commas (Issue #4968: Allow trailing
comma in gradient functions (and probably others)) is to alter
the section of the parser for consuming a declaration or
function to accept an optional comma before the final semicolon
or closing parenthesis.
- Concern with doing this broad approach is that it could block in
any future changes and that it doesn't make sense to allow it on
a single value property.
- On the other hand, going property by property was thought to be
bad for authors, because of the likelihood of inconsistencies.
- TabAktins will write up more details for the original proposal and
myles and emilio will look at creating a counter proposal with
more limited effect.
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-four-time-slot-3b
Scribe: dael
CSS Values
==========
Express conditional values in a more terse way
----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/5009
TabAtkins: Right now if you want to change styles with MQ it's
stable for a long time. As long as you're doing a
complete rewrite or tweak small bits it's fine.
Substantial touches like change colors for dark mode it's
awkward. Have to repeat all selectors and if you make
edits to one spot have to do same across all media blocks.
TabAtkins: Jonathan asked for way to better keep conditional things
close together and require less repetition when you need
to modify
<fantasai> https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620766100
TabAtkins: Suggestions in thread. One I liked is a bit down in the
issue. It's a switch function that takes int as first
argument and then ; separated arguments that are
properties. Returns nth of those depending on first
argument
TabAtkins: Intention is if setting up colors for high/low contrast
you can set the MQ to init using switch to call one of
those and the specific properties. Let's you call them
without repeating MQ or selectors. When you need an edit
it's all there
TabAtkins: If adding more cases you go across switches and add stuff
TabAtkins: I think I'm super happy with this. No reason to write it
literally. If you write with a variable as first arg I
like it a lot to push it to values space rather than keep
at rules space
hober: Relationship between this and bkardell's switch() function?
TabAtkins: No direct relation. Functionality feels similar but
selecting on an integer vs container size data are
different. We'll use similar...
TabAtkins: Similar values handling where they're var-like but
there's no direct connection
AmeliaBR: Disagree with that. I don't think there should be two
distinct switch constructs. Original use case of making it
easier to condense parallel declarations for MQ I thought
TabAtkins original proposal looked nicest: to be able to
nest @media conditions in a declaration block.
AmeliaBR: Especially with being able to declare custom keywords,
that's compact and readable.
AmeliaBR: And integer that's a toggle is not something I see as
readable. Could be used for the purpose if a generic
switch function is available. Might be okay because I do
think a generic switch is useful in CSS. But if talking
about generic switch it should be in a generic way.
AmeliaBR: If we're talking about generic switch function it should
be all use cases, including container query use case. Can
we break the proposals into constituent parts we can
combine up?
AmeliaBR: Proposal in container queries a key part is you can access
dimension from layout. If a generic way to access that as
a variable that's resolved at layout or used value time
and a generic case switch function that's not resolved
until layout we can put it together and get bkardell
proposal from last week.
AmeliaBR: But it could also be used with a regular variable.
AmeliaBR: I think by separating the 2 feature requests we can
address both at same time
florian: In the thread I think I see 2 variants of switch. One
that's off the integer with ; separator which looks terse
for short and confusing for long ones. Other is more
explicit that looks more like a select case where you list
florian: If you're listing you switch out a variable and also use
keywords. If you make that explicit you don't have to limit
to integers. Could go the way where you can use tokens and
move into other switch function.
emilio: I had same comment as with switch. I agree it's a good idea
but don't know why different from calc min() and max()
emilio: bkardell proposal becomes an optional value in how it's
resolved later. That way both proposals make sense
emilio: A weight to conditionals in calc has been proposed before.
switch can be that.
emilio: I just don't think we should invent another var-like thing
<bkardell> for reference
https://gist.github.com/bkardell/e5d702b15c7bcf2de2d60b80b916e53c
bkardell: Pasted in a link to last week's proposal. Wanted to point
out the opening and lots of words in there point that it's
not simply about a point size. It's a single generic
function that introduces the ability into the css
lifecycle.
bkardell: Maybe something to what emilio said but there's value in
centralizing it. I don't know if he's done it yet but
original poster said my comments would satisfy use cases.
bkardell: I'll add that lajava has been doing concrete impl and we
think from that standpoint it makes sense to do these
things together
<AmeliaBR> the nested media query example proposal:
https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620726494
jensimmons: I think this is an interesting problem. I understand
some frontend teams put your mobile styles in one file
and desktop in another or in a whole other section. Then
this problems is at its worst
jensimmons: Another way to do it is it's one stylesheet and throw a
MQ at one rule. That way you've got the original idea
with a class of files. Nesting selectors is something
sass has done for a long time. It's thrown people when
they move back to css. I'd advocate for something more
universal like nesting selectors and than you could
write more efficient code. Any of these solutions
require switching from different files.
jensimmons: Teams can do that today and switch their thinking.
Question becomes if we had something like nested
selectors and teams thought of it as one set of styles
with conditionals what else would they need
jensimmons: Agree there's a danger this makes it too complicated
where elegance of MQ is lost. Some teams are really into
math and variables and calculations, which is great but
I don't know if we want central idea of how you do css
to becomes something that is that complicated
jensimmons: Other idea I've seen some teams believe and the web is
neutral on and should stay that way to do it correctly
you should define all the breakpoints and every number
should be those breakpoints. Variables make that more
efficient.
jensimmons: I don't believe that's necessarily the right way and I
don't think we should add anything to css to make it
harder to do any way.
myles: 10 days ago leaverou made a comment why we can't make
variables stronger. I didn't see it addressed. I'd like to
ask same question here.
<TabAtkins> where was this comment?
<myles> https://github.com/w3c/csswg-drafts/issues/5009#issuecomment-620424568
AmeliaBR: [reads]
AmeliaBR: I interpret it as putting onus on author to do calc rather
than having it be a css syntax thing
florian: Doable today but not readable. If you have a MQ at the top
of your sheet and then you have 50 numbers. Then you have
border-top-width: size17.
AmeliaBR: And things you're switching might not be numbers. Might be
grid areas or colors
<bkardell> jon's (the OPs) comments are on the issue now btw
TabAtkins: Accumulating responses
TabAtkins: Not in order. myles and leaverou comment. That's exactly
what I proposed switch would do as long as I'm
interpreting her correctly. She may instead think it's
math formula and I don't think that's always possible. If
just saying use variables to do this that's what switch
function does
TabAtkins: Earlier, I think florian, about nested vs switch. I think
being able to nest MQ into style rules is necessary. If
any changes you want to make based on a MQ are more than
a single properties you want nested MQ. Gives you same
benefit of cluster but lets you link together
<bkardell> +1 to "nesting would also be good"
TabAtkins: When doing single property value for something like
colors it's still more overkill in syntax. I like switch
to be as terse as possible
TabAtkins: Earlier comment about this akin to layout-based switch
from bkardell. This really isn't. Anything based on
layout has to be late in pipeline and limited in what it
can adjust. You cannot adjust display based on layout.
Fox is in the henhouse. But no reason you can't adjust
display based on this. MQ can shift display but changing
where it's assigned.
TabAtkins: Similar conceptually but different in practice. We
shouldn't try and merge them into one thing
TabAtkins: Moving on to this being requested by conditionals in
calc, I kind of agree. Could do via calc conditionals.
var = 1 var = 2 type. People can do move complex things.
That works for me.
TabAtkins: If this is a great additional reason to support
conditionals in calc I can spec that out, it's fine.
<bkardell> if it becomes something that is not called switch, but
fits in calc, I am ok with that too
drousso: One thing I want to point out is this is not the only
situation with a problem but anytime it has to do with
newlines or whitespace it doesn't work well with things
built into browser. Anything that relying on newlines will
not play nice in browser dev tools. Should be considered
TabAtkins: Syntactically no reason, but larger issue is all comma
separated lists. I put bg on separate lines to make it
more readable.
drousso: Agree but devs use the tools to write these things so some
consideration for what the editing experience should be.
Not saying they can't be fixed, but they've been this way
for a long time and we shouldn't make it worse.
<jensimmons> +1 to thinking through what the debugging experience
is. Separate from the specific DevTools concern, I
agree that making this natively quite-complicated needs
to be only done while thinking through the debugging
experience.
<Rossen> +1 on tool working well with CSS!
florian: Continuing on my earlier comment. Conditionals in calc has
been asked. In calc you can express a number of calc, but
we need to express things that resolve to a bool if we do
this. Feels slippery slope and we end up with a new
language in calc since people want complexity. Lisp with a
clumsier syntax isn't something we should do. It's powerful
but let's not jump in accidentally
faceless2: Agree with florian. If you put in calc you restrict to
calc. Conditionals in css is a great idea. Not sure calc
is best place.
faceless2: This must have come up in a preprocessor surely, should
we link to one of them?
TabAtkins: I know multiple have nested MQ, don't know if at value
level
<jensimmons> and reach out to Sass to ask them why they haven't done
this yet. See if they can — to get author experience
<TabAtkins> @jensimmons I'd ask you to do some examples on your own
with light/dark/high-contrast/low-contrast MQs, and see
if you're happy with the amount of MQ repetition you need
<jensimmons> @ TabAtkins — I have written a lot of CSS.
<TabAtkins> jensimmons, yeah, I know ^_^ but i'm asking you to write
out nested-MQs vs switch(), as I think the verbosity
issue for nested-MQs is *not* trivial
<AmeliaBR> Sass has `@if` and `@else` rules:
https://sass-lang.com/documentation/at-rules/control/if
bkardell: Jon works on preprocessor stuff, the original poster. One
of the points has to do with parsing. There's a difficult
parser scenario where like URLs there's a spec but what
people impl in not-browsers is not entirely accurate.
bkardell: Worry about forward harm that can be done if we add new
syntax.
<lajava> TabAtkins, I don't think switch should be restricted to
layout related conditions; I think from the implementation
we can resolve the switch conditions during CSS parsing as
well
Rossen: I don't think we can get to a resolution here.
Rossen: TabAtkins since you brought this topic anything you want to
see going forward?
TabAtkins: Right now happy to go ahead and table. I'll write up a
more fleshed out proposal for my idea and we'll bring it
up in a future call
Rossen: Similar to 2 issues ago seems highly desired functionality
and will take some ironing before we can resolve
<br type=10min>
Rossen: We've got less than an hour so if you have must issues let
me know
<fantasai> TabAtkins, Not arguing that we necessarily don't want
switch, but would it make sense to add nested MQ to CSS
first?
<fantasai> TabAtkins, it's just syntactic sugar, so, relatively easy
<TabAtkins> I think we should do both of them at once, yes.
<fantasai> TabAtkins, I'm not convinced we should both of them at
once. I think it's fine if we do nested MQ now
<fantasai> TabAtkins, and continue to work on switch() proposals.
<TabAtkins> I don't think we should do nested MQs, then wait to see
that reception to decide whether we want something
terser.
<TabAtkins> I'm writing a comment expounding on this exact thing
right now ^_^
<jensimmons> I think we should do nested selectors in general,
first. Nested MQs, and nested selectors.
<jensimmons> It'd be a HUGE improvement in code organization
<fantasai> Proposal: css-nesting-1 to include nested MQ and
@supports only, and get that done quickly because it's
just syntax we already support in the core syntax
<fantasai> keep working on the rest
<TabAtkins> Strong agree with nesting being an important thing to go
forward with.
<TabAtkins> switch() wouldn't be a Nesting topic anyway, it would be
V&U ^_^
<TabAtkins> btw, Sass defines *both* `@if`/`@else` at-rules, *and*
an `if(bool, val1, val2)` function, so yeah, it's got
conditionals on both rule-level and value-level.
CSS Contain
===========
Add contain-paint-margin CSS property
-------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4934
chrishtr: Purpose is to apply a clip so the ink overflow does not
exceed it. Allows UA to detect that it's offscreen so
don't have to paint. This property allows dev to have a
margin to expand the clip. In case devs have certain
amount of ink overflow b/c useful for layout like shadows
or flourishes
florian: Additional use case is outline and accessibility purposes.
If the outline would be in screen and rest wouldn't you
might want to see. Optimizations can work if you just
expand boundary of rectangle a bit. If it works, why not
fantasai: Is contain:paint containing paint of element or contents?
florian: Both
fantasai: Seems weird. Mostly contain is about contents. Why would
you clip box shadows?
TabAtkins: Containing layout is one thing because elements own
layout won't extend but children can so it's fine. But
box shadows can be arbitrarily far away so if you only
clip children you still have to look at element, compute
styles, and care about paint.
fantasai: For ? anyway so you know where it is
florian: Element yes, but the paint. If you have containment you can
say it's offscreen so stop. not check if there's a shadow
and maybe compute that
AmeliaBR: Also when having element on its own layer how big is it an
reserving memory for animations and whatnot
smfr: I think I would understand better if describes how data goes
into compositor. Is it knowing when overlap?
chrishtr: Reducing size of textures is an optimization. Motivation
is allow dev to benefit without being strict about
clipping to size of element.
<TabAtkins> This is basically exactly analogous to the filter margin
concept for SVG filters
florian: fantasai's point about just for children doesn't change
problem. Could have 0 padding 0 border div around something
with a shadow and same problem
* fantasai does not understand florian's comment
dholbert: Similar to shape-margin property but that rounds at
corners. Is that what we're intending?
TabAtkins: Shouldn't be necessary. Just extending rectangular box
fantasai: I'm still skeptical about definition. Would it make sense
to have 'auto' to calc things like default outline width
or outset of border image or (possibly ignoring blur
radius) box shadow distance
florian: Possibly. We have a bunch of cases where win of
optimization is real but small. If you have a bunch of
checks before it defeats optimization
fantasai: It's auto. You don't do every time you paint. You
look at 3 properties and calc outsets once.
AmeliaBR: Animating shadow
fantasai: If you have auto on contain paint that's animated.
chrishtr: But has to be cached and that's a cost. It also doesn't
solve content in subtree issue
florian: If you do width of outline you wouldn't on child of element
that's adjacent so only partly helping.
fantasai: Having arbitrary clip of box doing containment is weird
AmeliaBR: Is the concern default is too strict? Could give a default
of something like margin 16px. Default you assume a little
overflow.
fantasai: Maybe. Having a typical box shadow or border image get
clipped when you 'contain: paint' seems weird
fantasai: Understand about clipping children. But clip box itself is
weird
dholbert: That's not what happens in FF or Chrome. We clip
descendants to padding box
TabAtkins: You should clip box-shadow, not border
florian: I misspoke earlier. Spec says content of element including
paint of descendants must be clipped. Border is not content
so what fantasai wants is what spec says. If it should is
another question, but we're not spec you must clip
fantasai: sgtm
<dholbert> I tested box-shadow, and indeed it's not clipped.
<dholbert> My testcase (shadow isn't clipped in Firefox or in
Chrome): data:text/html,<div style="border: 3px solid
black; box-shadow: 50px 50px black; contain:paint;
height: 10px; ">abc
<dholbert> shape-margin definition, for reference:
https://drafts.csswg.org/css-shapes-1/#propdef-shape-margin
Rossen: Would adding this property address the issues you're aware
of chrishtr?
chrishtr: yes. Adding contain-paint-margin is
florian: You still want this in light of me misunderstanding?
chrishtr: Yeah, I came into it with that believe
fantasai: I'm okay with it, given it only affects content
Rossen: Objections to adding contain-paint margin property to
contain paint?
florian: No objection. We looked at non-0 initial value so with this
understanding lets have default be 0
chrishtr: Can set to non-0
smfr: Can you set negative?
chrishtr: Good question. Not sure there's a purpose
smfr: Should it clamp?
florian: Yeah...
Rossen: When we discussed in context of shape outside resolution was
easy that you want to have shape margin be non-clamped so
you can pull content under
florian: Yes, but this is a lot weirder.
Rossen: Should we clip to non-negative
florian: I think so
fantasai: Start with non-negative and expand to negative if needed
later
cbiesinger: I think you want negative values invalid, not clamped
<astearns> +1 to fantasai
fantasai: Yeah
florian: One number or one or two or three or four numbers?
smfr: Same as margin t/r/b/l
smfr: Do adjacent paint margins collapse?
fantasai: no
smfr: It has margin in the name and it makes me concerned
florian: adjacent margin collapsing has no meaning
smfr: Should it have margin in name or call it outset?
fantasai: We already have scroll-snap-margin so there's precedent
smfr: Okay
TabAtkins: and filter-margin in svg
Rossen: Objections to adding?
fantasai: Scope question
fantasai: Makes sense to have it work with overflow:clip?
fantasai: Why not operate on overflow:clip? So maybe more generic
name.
dholbert: Then same behavior as overflow:scroll...
fantasai: hidden, auto, and scroll are different, create a scroll
container. overflow:clip is different.
dholbert: Yeah, if defined in terms of overflow:clip it would have to
chrishtr: If it's a paint thing that's fine
fantasai: And useful if people don't want full containment
florian: clip-margin?
dholbert: Don't love the name. Clips to a margin is what it sounds
like
AmeliaBR: Or related to clip-path, Yeah. Name to be bikeshed?
AmeliaBR: Need to look more details about complications from
overflow:clip
fantasai: I think it's worth looking at things that clip and which
should hook in
Rossen: ink-margin?
fantasai: I don't think that's how people think about it
<fantasai> overflow-margin?
florian: Doesn't add margin to ink. Visible ink overflow it doesn't
do anything. It's an ink-clip-margin-ish
florian: Bikeshedding to be done
Rossen: Objections Adding ink-skip-clip-margin property (name tbd)
with non-negative values
RESOLVED: Add ink-skip-clip-margin property (name tbd) with
non-negative values
<florian> should it have longhands? logical ones as well?
CSS Syntax
==========
Allow trailing comma in gradient functions (and probably others)
----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4968
TabAtkins: I think we're good. Previous hour was great and now we
have a solid proposal.
TabAtkins: I won't go over the whole thing, just look at issue
TabAtkins: One concern from emilio during conversation is, WG in
general supported trailing commas. Question was how.
emilio concern was wanted it at low level, prefer at
parser so we didn't have to rely on impl remembering to
put it in every place
TabAtkins: At first thought it was weird and my first idea of a
function without a comma was attr() and then I remembered
it has a comma now. My idea of comma-less functions
that get upgraded has happened.
TabAtkins: Same for properties, we've upgraded to be list-valued.
Some like color probably won't change, but we've done
this in the past. My original objection is invalid, I
support em
TabAtkins: I propose we adjust consume a declaration, a function,
and a comma separated so in addition to dropping
whitespace they can drop a single comma token from the
end.
<leaverou> +1, this will also make it easier to generate CSS
TabAtkins: If you have a parse close to syntax this allows it
anywhere without much effort
TabAtkins: Syntax points: consume a declaration, consume a function,
and new consume a comma sep list. All have an amendment
to consume a single comma token
florian: Do you want to include conditional lists and selector lists?
TabAtkins: Yes. the comma separated list thing was for those cases.
I'd then redefine those to use that parsing algorithm.
florian: I suspect compat issues for selectors but let's see
florian: Properties that have comma separated list space and than a
value do we have those?
TabAtkins: Don't as far as I know but they wouldn't be covered by
this change
TabAtkins: Trailing comma is at the end of the entire property
declaration. The algorithm isn't invoked for properties.
florian: Do we have property with comma separated list / other comma
separated list?
TabAtkins: I don't think...
fantasai: / is a more binding operator. If there are properties that
have inverted the order of operation that's really bad.
Comma is usually lowest.
<faceless2> So "display: block,;" is valid?
<fantasai> yes, that's Tab's proposal
myles: Seems reasonable for us to have a single value property today
that turns space separated tomorrow with 2 values where we
wouldn't have a comma in the middle. If we allow comma in all
today couldn't do that
myles: Larger comment is commas make sense on lists not single value
TabAtkins: If we change syntax from one value to two space separated
a comma wouldn't interfere. We wouldn't do something like
counter reset, that was a mistake
myles: We use spaces and commas intentionally. Blanket stating for
all doesn't seem forward-looking
TabAtkins: Looks forward compat. If it was a,; and than we accept
a b a, is fine a b is fine
myles: Not about ambiguity, we design properties and want a comma or
not a comma
TabAtkins: Okay. objection to that, across css comma has been
consistently separator between repetitions of a list.
fantasai: Not true
fantasai: A lot of our functions, it's not a list of thing.
TabAtkins: That's why I said properties.
TabAtkins: Because consistent meaning there and trailing comma fine
at end of one element list and not going to give comma
another meaning when in a trailing position I don't think
it's a forward compat issue
plinss: In favor but one concern.
plinss: If you say 'foo," and nothing. If we define the second thing
gets default value and it's important there are 2 things
that's broken.
TabAtkins: We would not define a repetition can be completely empty.
We don't do that today. A value and a trailing comma is
single value.
plinss: This forces us into never allowing that. Never allow blank
after comma is set in stone.
TabAtkins: Agree
AmeliaBR: How effect parsing of custom properties? When do we drop
the comma? Could be meaningful at end.
TabAtkins: Dropped during parsing. I can see it being confusing but
I'm of the opinion that if you're putting structural
stuff like that in your variable I think you'd in a world
of pain.
AmeliaBR: Real use cases where want custom property to be a list of
repetitions or a blank. In that case don't want comma
where you use custom property because invalid if it's a
blank.
florian: Can we make an exception?
TabAtkins: Doable. A bit weird but not out of question
florian: Since it's a list of tokens it's a natural exception
AmeliaBR: Have an exception where a blank is meaningful
TabAtkins: That's not parser lever
emilio: Not sure initial answer was correct. Parsing at property
consumes all tokens regardless of which.
TabAtkins: Depends on definition. I don't care what declaration's
name is while I'm consuming so parse the same and then
apply grammar. I know browsers do grammar as you go but
it's must simpler mental. That's why I'm okay adding a
check for it it's parsed.
Rossen: Time check, this will take us to the end. We have a queue
and then let's see if we can end
fantasai: Wanted to ask if we weren't going to do this for
everything, the alternative is only where there is a list.
If we drew that up what would it look like and should we
compare?
TabAtkins: Complicated. Simplest is # multiplier allows trailing
comma. But anything that does commas explicitly, which
is a lot of places, would not work.
TabAtkins: Have to go into every property that uses commas and make
sure their grammar expresses it.
myles: I think that makes sense. Property by property is right
<faceless2> +1 to myles
drousso: I agree
<astearns> terrible to do things property by property for authors
TabAtkins: Disagree because it's fine and reasonable to do commas at
end of single in JS. Having to distinguish for a way to
write it easily seems unnecessary burden on authors
florian: I don't like it for rollout, if this is central it is fixed
once. If it's property by property a fix would end up going
out in some places but not all
myles: Difference between css and js is parsing rule isn't different
by property in js. I don't understand argument that js has it
in function calls so we have it everywhere
TabAtkins: Not strict, but reasoning is similar
oriol: Ask about trailing comma. In case there's an ! and if it's
before the !important or if at very end
TabAtkins: Before the !important. End of value space and ! flag is
after that
<tantek> ES also allows it in arrays e.g. test =[1,2,]
<TabAtkins> ES allows it *everywhere* now, yeah. [1,2,], {foo,bar,},
and foo(a,b,)
<tantek> Thanks TabAtkins
<drousso> that's not true TabAtkins something like `let x = 2,;` is
not valid
<drousso> it's only allowed in places where a sequence/
list/"multitude" is expected
<TabAtkins> drousso: Hm, time for a new ES proposal
<drousso> strong disagreee
TabAtkins: I'd like to propose a resolution and see if objections.
<florian> +1
TabAtkins: Proposal: I make the syntax spec changes to allow
trailing commas in general module small changes around
things like !important
Rossen: Objections?
myles: I'm not going to object but seems wrong direction
<tantek> not just functions, as a correction to myles's assertion
that it's only functions
fantasai: Alternative way forward is TabAtkins has his proposal and
myles if you think there's a better way you can draft a
proposal and we compare
emilio: Would myles agree on functions only and decide declarations
at another time?
myles: Yes. Commas at end of lists is valuable
Rossen: TabAtkins?
TabAtkins: I think myles wants opposite of emilio
emilio: Can we defer deciding if we add trailing commas for all
declarations and agree we do it for comma separated list and
function arguments?
florian: I think I would object property by property
fantasai: I propose that TabAtkins drafts a more specific proposal
and myles and emilio discuss and draft a different proposal
TabAtkins: myles are you okay with trailing commas on functions?
myles: No opinions
TabAtkins: Let's resolve on that
smfr: Lists first
fantasai: Let's come back with something written specifically
Rossen: I think that's be best path forward. Let's not resolve by
exhaustion. TabAtkins write your proposal. emilio and myles
if you want a shot at your proposal go ahead and draft that.
<emilio> myles: TabAtkins: florian: My reading of the original
proposal from tab was that it also needed some kind of hook
to define for all "comma-separated lists", in a way that's
not property-specific
<TabAtkins> Specifically, I want to amend
https://drafts.csswg.org/css-syntax/#parse-comma-list
https://drafts.csswg.org/css-syntax/#consume-declaration
and https://drafts.csswg.org/css-syntax/#consume-function
Rossen: That's the end of out first virtual F2F
Rossen: I enjoyed seeing all your faces. We should do this virtual
thing more often.
Rossen: Thank you very much for dialing in and getting up early or
staying up late or whatever you had to do to join. Stay safe
and happy and healthy and hopefully the next one will be a
F2F.
Rossen: We'll have a call next week.
<Rossen> I forgot to thank our virtual hosts - Thank you Google for
hosting us on Meets!!
Received on Saturday, 16 May 2020 10:42:40 UTC