- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 13 Nov 2019 18:29:14 -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.
=========================================
CSS Text L4
-----------
- RESOLVED: Publish new WD for Text 4
CSS Fonts L4
------------
- RESOLVED: Republish Fonts 4
Grid L2
-------
- RESOLVED: Pick option 2; effectively subset the grid area into the
subgrid (Issue #4411: Subsetting grid-template-areas in
subgrids)
- RESOLVED: Start L3 with all work that is in L2 but not about
subgrid
- RESOLVED: Publish Grid L2 as CR
CSS Values 4
------------
- The group was interested in seeing specific details for changing
attr() to be more var()-like (Issue #4482: Switch advanced
attr() to being var()-like) so TabAtkins will write up spec text
for review.
CSS Grid 1
----------
- RESOLVED: Give the 2nd option a chance and see if there are compat
reasons to instead keep current behavior (Issue #4475:
Resolved values of grid-template-rows/columns don't
round-trip)
- TabAtkins will look into what the Gecko and Chromium devtools
expose about grid to see if something similar can be specified
as a future enhancement.
- RESOLVED: Specify serialization as proposed in
https://github.com/w3c/csswg-drafts/issues/4335#issuecomment-548962309
[When serializing either the specified or computed value
of a <<string>> value of 'grid-template-areas', each
null cell token is serialized as a single "." (U+002E
FULL STOP), and consecutive cell tokens are separated by
a single space (U+0020 SPACE), with all other white
space elided.]
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Nov/0005.html
Present:
Rachel Andrew
Rossen Atanassov
David Baron
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Tantek Çelik
Dave Cramer
Elika Etemad
Simon Fraser (IRC only)
Dael Jackson
Chris Lilley
Peter Linss
Theresa O'Connor
Manuel Rego Casasnovas
Florian Rivoal
Christopher Schmitt
Jen Simmons
Alan Stearns
Scribe: dael
Rossen: It's 2 minutes past, let's start
Rossen: Wanted to call if there are extra agenda items or items to
change
fantasai: Brief announcement
<fantasai> https://www.w3.org/wiki/Process2020
fantasai: We posted an explainer to process changes and edits at
this wiki^
<fantasai> https://lists.w3.org/Archives/Public/spec-prod/2019OctDec/0007.html
fantasai: If you have comments on improving, like the changes,
dislike the changes, let me know about problems. If you
have opinions forward them to spec-prod
<tantek> quick summary, Process2020 explainer is looking quite good.
Only nit is I don't think the Registries piece is mature
enough as compared to the rest. I'd advise splitting that
out and giving it more time to iterate/develop, perhaps for
2021.
<tantek> everything else I'm looking forward to reviewing closely
(actual process doc changes), and quite optimistic about. :)
astearns: TabAtkins wanted first item to be postponed slightly on IRC
Rossen: I see Chris will be a bit late for fonts 3
astearns: TabAtkins will be at least 15 minutes late
Publications
============
Rossen: Text level 3
florian: Text 4; fonts 3
fantasai: fonts 4 as well; fonts 3 is REC isn't it?
Rossen: It is.
Rossen: Let's do text L4
Text Level 4
------------
Rossen: Is it editorial?
florian: Not only. At previous F2F we discussed word boundary in
spaces, the text was added. It was announced and review
requested. We're not getting to CR, but it's been in the ED
for a while and it should go into an official space
florian: It's been a year since it was published. Sounds like good
timing
Rossen: And the edits are in?
florian: They are. It's the things I talked about at last F2F. Maybe
some editorial tweaks
Rossen: Great.
RESOLVED: Publish new WD for Text 4
Fonts Level 4
-------------
Rossen: Fonts 4 should we wait for Chris?
fantasai: Chris is on IRC
<ChrisL> Please wait until later
fantasai: I think we publish since he requested
<ChrisL> Ok great
RESOLVED: Republish Fonts 4
Grid L2
=======
Subsetting grid-template-areas in subgrids
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4411
<fantasai> https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-548945615
fantasai: Summary comment^
fantasai: Two proposals, make grid-template-areas a thing and
exclude names from inheriting. Currently grid-templates
make start and end and those would not inherit into subgrid
fantasai: Other option is we take those names and instead of saying
don't inherit in, they do inherit in and if there's
partial overlap we clip start or end so they exist in the
grid and you can position to the overlap
fantasai: Slight inconsistencies for both. If we exclude then a
manually created grid area such as named lines as
foo-start I implicitly create foo which I can position
into. Kinda works on a subgrid; if both lines overlap.
True in both cases
fantasai: Question is do we want...we didn't want to create
inconsistent behavior for templates. Want to say either
set to part it overlaps or exclude all lines. Those are
the two options.
fantasai: Would like to hear from other preference
<fantasai> A) Exclude parent template and its implicit line names
from subgrid
<fantasai> B) Subset parent template to the part where it overlaps
the subgrid, allowing it to be usable
Rossen: Prefer second option.
Rossen: Having the grid-template-area lines not available from
subgrid is quite weird given that rows and columns are
available
Rossen: I would lean toward the second solution if we have to pick
from these two
dbaron: Looks like Mats preference was first, but seems reasonably
okay with either. Seems he had impl of 2nd and changed to
1st.
fantasai: He originally wanted B, then did A when we weren't sure
Rossen: dbaron do you know why he switched?
rego: It was not impl in all cases. I had example in issue that was
different in 2 cases where should be same. He didn't have
whole impl. I think he did the simplest thing
<fantasai> Mats's comments
https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-542292465
Rossen: If we go with option B (the second option)
Rossen: Would that be okay dbaron if you're representing Mats?
dbaron: I'm only reading his comments in issue
jensimmons: Still trying to wrap my head around. Seems like Miriam
Suzanne and rachelandrew were advocating for A
Rossen: A in TabAtkins summary is option 2
<rachelandrew> option 2 for me (don't think my mic is working)
fantasai: rego I think case with a difference is case of explicit
line names creating implicit area.
fantasai: TabAtkins and I discussed and concluded there wasn't a
good way to make that work. Would require changes to how
line names were handled. Couldn't figure out how to not
cause changes to normal grid
fantasai: Concluded line names from template are special and special
for subgrids but explicit line names don't. Which means
you can handle the partial overlap nicely for template
areas, but not for area with explicit names
rego: So original impl from Mats is final?
fantasai: Yeah. Either way the line names created by template area
need to be special so we either notice they're excluded or
clamped for partial overlaps. Seems second is more useful
rego: Still don't like difference in the example. I understand it's
useful so maybe it's good enough. I think the difference can
create confusion.
fantasai: Ideally we would solve both, but didn't find a good way.
<fantasai> rego, see
https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-542288855
for problems with the other options
Rossen: Not hearing strong opinions, but more people toward option 2
Rossen: Objections to resolving on "Subset parent template to the
part where it overlaps the subgrid, allowing it to be
usable" unless there's additional comments
<fantasai> Example of option 2 -
https://github.com/w3c/csswg-drafts/issues/4411#issuecomment-543174237
Rossen: Objections to Option 2: Subset parent template to the part
where it overlaps the subgrid, allowing it to be usable?
RESOLVED: Pick option 2 effectively subset the grid area into the
subgrid
Publication
-----------
fantasai: That's last subgrid so I'd like to propose every
non-subgrid feature goes to L3 so we can go to CR
<fantasai> https://drafts.csswg.org/css-grid-2/#alignment
fantasai: There's a bunch that haven't been edited in. We'd defer
this ^
fantasai: There's a handful where we resolved to add features and I
propose we start a new WD with those and put subgrid L2
to CR
fantasai: We didn't edit them in because Grid 1 was a little
unstable. But none of those features are as urgent as
subgrid
<ChrisL> +1 on CR for Grid L2
<tantek> +1 on CR for Grid L2 with only subgrid added
Rossen: Proposal: Break Grid L2 down to only contain subgrid
features. Take L2 to CR. Start L3 with all things moved
<dbaron> presumably L2 will have the L1 stuff too?
<tantek> dbaron, that was my assumption too
<jensimmons> +1 Let's get going on Lvl 3 baby! All the ideas about
how to make Grid better!!!
RESOLVED: Start L3 with all work that is in L2 but not about subgrid
fantasai: Question for ChrisL. Grid 2 is a diff spec and doesn't
have L1 content. There's a lot in Grid L1 that aren't
posted to CR.
fantasai: I don't think I can copy it over yet. Is it okay to
publish CR as a diff?
<tantek> I'd be ok with CR as a diff
<tantek> would rather than CR as a diff than have to wait until "L1
done"
astearns: I'd wait until we have L1 done. CRs are meant for review
and diff is hard to review
<ChrisL> Agreed, delta specs are harder to review
fantasai: It's easier because it's one fairly isolated feature.
We're adding this thing. I think it's okay as diff, but I
want to fold in eventually
florian: Another is publish subgrid L1 as a CR
fantasai: No, not making this another spec.
fantasai: I'll wait if we want.
<tantek> agree with keeping this as grid L2
<ChrisL> But okay if explicitly stated all of L1 will be included
<tantek> I get the feeling most people here are ok with L2 as a diff
CR
fantasai: We're waiting on a handful of Grid L1, but we're hung up
on not having tests
florian: CR should be acceptable as REC and a diff isn't. We should
wait
jensimmons: I wonder if there's people that love grid enough they'd
write tests
fantasai: I think a lot are written and we need to figure out where
they are
Rossen: We can wait until next week. It would be nice to make
progress
fantasai: If it's up to me to do tests I won't get to it until
mid-Dec at least
Rossen: Let's get them in 2019 at least
<tantek> I'd also be ok with L2 as another diff WD with explicit
status stating we believe the additions are all CR-worthy,
and that the only change expected before CR is the
incorporation of all of L1
Rossen: Reading ChrisL in IRC that he's okay if explicitly stated
all L1 included. I guess republish with a note? Not sure
what that looks like for CR
florian: Not convinced process allows that
Rossen: Objections to moving grid L2 as CR? We'll figure out format
but we can resolve to do it now
Rossen: And from previous resolution it means Grid L2 is the delta
of 1 and subgrid
Rossen: Objections?
fantasai: Union of 1 + subgrid
RESOLVED: Publish Grid L2 as CR
Rossen: We'll work with ChrisL to figure out exactly what it looks
like
<tantek> 🎉
Rossen: That's awesome because Grid is awesome
CSS Values 4
============
Switch advanced attr() to being var()-like
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4482
TabAtkins: Several years ago we defined the more complicated attr()
functionality where it supplies the type. If you say
foo=5px we parse as length.
TabAtkins: No one impl. I realized why.
TabAtkins: It ends up being high cost for low value. Type checking
eagerly so at parse time we can reject it it means every
thing that does grammar checking have to account for
possibility of attr() being there
TabAtkins: Lots of fiddly detail work.
TabAtkins: We did it because we don't have valid at parse time but
rejected later. We now have that for var(). The var()
machinery and building on that gives us a lot of tools
that didn't exist earlier which make attr() easier
TabAtkins: Precise details of grammar aren't laid out, but core is
we make attr() act like var(). It makes property
automatically valid at parse time and we do parse at
computed time. We validate at that time.
TabAtkins: Specifying type lets you validate you put the right thing
in the attr(). Handling attributes elsewhere tends to
allow garbage and ignore. We maintain that and check type
and make sure it works.
TabAtkins: If we base on var() it's the same functionality for
authors and a significant decrease in implementation
complexity.
TabAtkins: I'd like to pursue this change and the impl wants to
experiment in it
TabAtkins: Is WG amenable?
<fremy> I strongly support this!
emilio: I'm not opposed but concerned about type checking token
string and then doing parsing again. When I looked at impl
attr() I suggested doing it like variables in bugzilla.
emilio: Complexity of doing attr() didn't seem so high either. I'm
concerned about parsing, tokenization, and then parsing on
performance.
emilio: Other concern is XSS but that happens either way
TabAtkins: Reason why I don't think first bit is a concern is it
ends up being identical to custom values and properties
API. Ideal is it works that way but it's inline
emilio: I think that's also a concern with custom properties. I
don't want to block on it, it's mostly theoretical
TabAtkins: Never say never but I doubt used in performance sensitive
ways
AmeliaBR: My first concern would be how can we make it work
logically with the existing use of the attribute function
in the content property
AmeliaBR: You've been talking as distinguishing if an explicit type
is set. More I'm thinking maybe not necessary. If you
don't have an explicit type the type is assumed string and
any attribute can be parsed as a string, returned in a
string. So maybe not an issue because string is always
valid in content
AmeliaBR: I'd like to see the exact write up and make sure it makes
sense in backwards compat without special behavior
TabAtkins: Not possible w/o any backwards compat because assume
valid at parse time. Content properties currently invalid
but use attr() become valid at parse time. It is a
behavior change if we make unspecified type attr() use
this.
TabAtkins: Not sure what's best if we split parsing into separate
function rather then flag it as attr() here. Puts you in
2 parsing modes based on detail of function grammar.
TabAtkins: If we think it's okay for behavior change in content
where you wrote an invalid with a fallback and you're
relying on that that seems minor. Otherwise good with
your option.
TabAtkins: There's some possibilities there, we can experiment
AmeliaBR: Your example of something suddenly valid is if something
else in content property would be a parse error. Like
using slash syntax with alternative text in a browser that
doesn't support makes a difference if it's parse time error
TabAtkins: Exactly. You'd no longer have the fallback
AmeliaBR: I would lean toward having a separate function for the
type version and use attr() for how it's currently
supported. Might be problematic for UA that support attr()
more widely
TabAtkins: No idea if various printers support. I know no web
browsers do. I'm not sure impl quality of whole thing
TabAtkins: But this is a behavior change. It will be off if there's
a current impl. It's a custom thing or breaking change
TabAtkins: If no other questions just want to check for objections
for me creating a full write up of changes. I can do that
for review next week
Rossen: Objections?
fantasai: Summary?
TabAtkins: There's a lot of possible ways how, but it's a change in
validation to make it more var() like
TabAtkins: I'll have a write up fully next week. What's in the issue
is the right gist
TabAtkins: It's switch attr() to var()-type validation rather than
strict parse time validation
emilio: The fallback might be able to be fix for attr(). Unfortunate
to add new type of attr() that can't be detected. Nice if
forced to a valid type. Worth thinking about
TabAtkins: Yep.
Rossen: Objections to the approach of switch attr() to var()-type
validation rather than strict parse time validation
<astearns> +1 to try this out
fantasai: Not sure, but let him write it up
Rossen: TabAtkins there's no objections. Go ahead and write it up
and we'll look when you're ready
CSS Grid 1
==========
Resolved values of grid-template-rows/columns don't round-trip
--------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4475
<fantasai> See
https://github.com/w3c/csswg-drafts/issues/4475#issuecomment-548908448
TabAtkins: As spec grid-template-row/column when you asked for
resolved value you get width of implicit tracks as well
as explicit. Given you can't spec implicit tracks this
doesn't make any sense at all.
TabAtkins: Getting the width of implicit tracks is worthwhile.
Functionality is reasonable, but a number of useful grid
things it would be great to get from layout that aren't
in properties right now.
TabAtkins: In past proposed things that would require new grid API
to get
TabAtkins: Resolved value of grid-templates does not round trip.
TabAtkins: Options; 1) leave as is. Resolved value is not a valid
value and confusing because unless you know number of
implicit rows you don't know where explicit starts
TabAtkins: 2) Change to only reflect explicit rows on resolved
values. implicit we leave for a more explicit API
TabAtkins: 3) Continue to allow grid-template-rows to express
implicit but change grammar so it's valid. There is some
value because only explicit are used for auto positioning
by default. Being able to give bounds to auto while
sizing outside could be worthwhile
TabAtkins: Would need to be able to spec when the explicit grid
starts and stops which would also need to return in the
resolved value
TabAtkins: We leave as is, change return of gCS for this so that it
allows round-tripping either way
TabAtkins: Need to decide, this was an accident. If we leave as is
need to be more explicit
TabAtkins: I prefer changing to be just explicit tracks. I could
accept any of the 3.
fantasai: Web compat is a substantial concern. Might be stuck with #1
emilio: Also I also prefer 2 if we can get away with the compat issue
TabAtkins: Web compat is always a concern and we might be stuck with
1. Between 2 and 3 is group okay if we try for 2 and
revert if web compat proves otherwise?
oriol: In issue I propose feature which allows define where grid
line could be. It could place it in another place. I think
something like this could have its own uses outside this
issue. However I agree this probably needs more thought and
be in something like Grid 3.
oriol: If we want to fix round-tripping we need more urgent for L1
so it's reasonable to try and remove implicit tracks
TabAtkins: Your suggestion was option 3, but as you say requires
additional work. How it interacts is unclear right now
and a breaking change anyway. If breaking, might as well
do one that's easier to work with. If we ever want
explicit/implicit we can do that later
TabAtkins: Any strong preference for keeping current behavior? Or is
everyone okay with trying to change gCS and falling back
to no change if there's web compat problems?
<dbaron> please make it round-trip correctly :-)
<florian> I like the proposal
Rossen: Try it out. It makes sense.
fantasai: We don't have syntax for that right?
TabAtkins: Not for 3. No one is suggesting widen the grammar first.
This is keep as is and have gCS report explicit only or
have gCS report more accurately
<fantasai> sorry, I was confused
Rossen: Resolution would be for give the 2nd option a chance and see
if there are compat reasons to instead keep current
Rossen: Other opinions or objections?
emilio: No objections but I want note sure both Gecko and
Chromium...info from gCS is not useful. Both Chromium and FF
have special dev tools because gCS is not enough.
Rossen: We can look at extending OM for grid
Rossen: I think you're pointing out more general issue. I don't
disagree
<emilio> https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl
fwiw
TabAtkins: Point is valid in that what's currently returned is not
enough for current use cases. So we're not losing
anything and we should look into more advanced on
Rossen: Agreed
Rossen: Objections?
RESOLVED: Give the 2nd option a chance and see if there are compat
reasons to instead keep current behavior
<TabAtkins> emilio, I'd love to with with you and jensimmons or
anyone interested in this to figure out what devtools is
using and how we could expose that to users.
<emilio> TabAtkins: fwiw, this is the API exposed to devtools:
https://searchfox.org/mozilla-central/source/dom/webidl/Grid.webidl
via https://searchfox.org/mozilla-central/source/dom/webidl/Element.webidl#322
Spaces in grid-template-areas serialization
-------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4335
fantasai: Want to clarify how spaces are handled. There's no
compatibility. We said serialize between tokens we do a
single space no matter if it's needed
fantasai: Want to confirm with WG
astearns: Makes sense to me
emilio: Seems weird to change string because we don't change string
in other places
TabAtkins: You do change the string somewhat. You don't if parsing
splits tokens correctly. But you trim spaces at end and
collapse many to one
oriol: In issue #3261 we resolved against preserving precise string
in favor of normalizing. Just wasn't clear on what to do with
spaces
TabAtkins: Thanks
astearns: emilio?
emilio: No objections
astearns: Other concerns?
astearns: fantasai has comment at end with proposal
astearns: Objections to this?
RESOLVED: Specify serialization as proposed in
https://github.com/w3c/csswg-drafts/issues/4335#issuecomment-548962309
Received on Wednesday, 13 November 2019 23:29:46 UTC