- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 30 May 2018 20:35:23 -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 Grid
--------
- RESOLVED: Accept proposed edits in
https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268
to amend grid algorithm.
- RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2697
(add align-content content distribution for this specific
case (all rows have definite max size) to the row
estimation heuristics for step 1).
- RESOLVED: Close this issue, won't fix. (Issue #2270)
- The group felt it was too early to create a shorthand and that
more time was needed to figure out which of the many ways to
set equally sized columns/rows should be represented in a
shorthand.
- RESOLVED: Accept this change but keep the issue open and don't do
edits until there's an implementation commitment. (Issue
#2681)
CSS Images
----------
- RESOLVED: Always expand gradient syntax in serialization. (Issue
#2714)
Values & Units
--------------
- The changes to allow unit algebra in calc() have been put in the
spec and anyone interested was asked to review.
Spec: https://drafts.csswg.org/css-values-4/#calc-type-checking
Issue: https://github.com/w3c/csswg-drafts/issues/545
Selectors 4
-----------
- RESOLVED: Make specificity of :not() :has() and :matches() not
depend on matching. (Issue #1027)
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2018May/0047.html
Present:
Rachel Andrew
Tab Atkins
David Baron
Amelia Bellamy-Royds
Garrett Berg
Tantek Çelik
Emilio Cobos Álvarez
Alex Critchfield
Benjamin De Cock
Elika Etemad
Simon Fraser
Tony Graham
Dael Jackson
Chris Lilley
Myles Maxfield
Thierry Michel
Liam Quin
Melanie Richards
Dirk Schulze
Jen Simmons
Alan Stearns
Lea Verou
Eric Willigers
Regrets:
Rossen Atanassov
Dave Cramer
Michael Miller
Manuel Rego
Florian Rivoal
Jeff Xu
Scribe: dael
Agenda Setting
==============
astearns: Let's get started
astearns: Is there any changes to the agenda to make?
<TabAtkins> The one change I sent to the thread?
<leaverou> https://github.com/w3c/csswg-drafts/issues/2714
leaverou: I was wondering if we could add ^ to the agenda?
leaverou: It's gradient serialization so hopefully fast.
astearns: Let's try and do that after grid.
astearns: TabAtkins you mentioned a change I think I made.
astearns: TabAtkins was that adding editors?
TabAtkins: The change I requested isn't in the agenda.
astearns: Change you wanted?
TabAtkins: Adding editors.
astearns: It's first
Adding editors to specs
=======================
astearns: Fergal Daly is going to be editor for shadowparts. Chris
Harrelson will be compositing and geometry
astearns: They both joined.
TabAtkins: Approved for adding Fergal Daly for shadowparts. The work
Chris will do is much needed.
astearns: So that's mainly informative.
astearns: Their first task will be adding themselves as editor.
TabAtkins I expect you'll help.
TabAtkins: Yes.
CSS Grid
========
Applying 'justify-content' content distribution is in the wrong place
in the overall grid sizing algo
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2557
<fantasai> https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268
fantasai: Summary is here ^
fantasai: When we size the grid we do all the sizing account for
items etc. and at end align the track or justify them.
Problem is that sometimes this increases size of gap so
spanning item has more space.
fantasai: Mats said we should integrate alignment into sizing algo
more close so that you have alignment effects on sizing
accounted for when doing sizing.
fantasai: Seems like everyone agrees this is a good idea so bringing
to WG for approval.
fantasai: Questions?
astearns: Comment you linked to has...does it have both 1.5 and 2.5
that are in further discussion?
fantasai: 1.5 is second sentence in 1.
astearns: And 2.5 is second sentence in 2?
fantasai: Yes and so on down.
astearns: Other comments to add?
astearns: Objections to accepting
https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268
RESOLVED: Accept proposed edits in
https://github.com/w3c/csswg-drafts/issues/2557#issuecomment-385571268
to amend grid algorithm
Applying 'align-content' content distribution to row estimation in
step 1 in Grid Sizing algo
------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2697
fantasai: Follow-up we have a heuristic to get rough sizes and we
need to also change the heuristic
fantasai: Technically different issue.
fantasai: I think this is a matter of getting it correct.
astearns: Additional comments?
astearns: Objections to accepting
https://github.com/w3c/csswg-drafts/issues/2697
or do people need time?
RESOLVED: Accept proposal in https://github.com/w3c/csswg-drafts/issues/2697
Shortcut syntax for repeat(M, 1fr)
----------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2270
leaverou: I found that I was using grid template columns and rows
numbered by accident and realized that's not how you make
equal columns and I was wondering if we can add shortcut
syntax so the error becomes correct because I suspect
other people would write this.
leaverou: TabAtkins raised point that because we allow unitless
lengths grid-template:0 has a meaning. It doesn't mean
it's not possible, but it's confusing in that case.
leaverou: People have discussed a new unit, I don't remember names,
but people discussed units or functions like efr. I'm not
a huge fan because I wanted to prevent this error and
other syntax would get people to make errors. But I guess
a shortcut for this is still a net gain.
fantasai: My main concerns where that there's lots of sizing
functions you can have and I'm not sure fr is what you
always want.
leaverou: My point was a shortcut to spec equal width columns. It
can be a shortcut to whatever you think it should be. You
know grid better then me.
TabAtkins: The point isn't one better, but it's that there isn't a
single obvious choice. It's hard to justify one with a
blessing of a shorthand.
jensimmons: I'd hesitate to put a thumb on the scale for which
syntax should be used by giving one approach a special
short hand. I feel industry needs a couple years to come
up with a bazillion ways to do things.
astearns: I wonder if we should let it sit, see if preprocessors
come up with a shorthand of their own we can adopt.
rachelandrew: Agree. I don't see huge confusion. I see people that
love shorthands, but I don't see this as a mistake. I
see a lot of not working grid and this hasn't come up.
jensimmons: I see people trying to systematize and it's early for
that. They don't understand power of grid and what a fr
is. I think there's a long way to go before we create a
system of shortcut.
astearns: Is there anything we can do about the mistake case?
fantasai: I think we leave as invalid. We could revisit a shorthand
in the future but I think for now it's not the right time.
fantasai: Related: one frustration raised in thread is way fr units
are calc and people are frustrated you can't use direct
because auto min is often wrong. We need to fix those
cases. They have to set a 0 min. That's #1865. We need to
do something about it.
<fantasai> https://github.com/w3c/csswg-drafts/issues/1865
astearns: leaverou are you okay closing this for now and taking some
of this over to 1865?
leaverou: Yep, fine. I was fine since TabAtkins pointed out grammar
inconsistency.
astearns: We'll leave it there and not do anything for the moment.
We'll see what people do with fr and make shorthands.
RESOLVED: Close this issue, won't fix.
gCS() of grid-row-start/etc properties should return used values?
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2681
TabAtkins: Someone brought up question of, it would be useful to
know what row and column a grid element ended up in for
scripting.
TabAtkins: The requests are all solvable if we solve this. In
particular if you do auto placement. Clearest way to do
this is make sure used values are actual lines the
properties end up with. Changing gCS() to return used
value.
TabAtkins: This is a change for all impl, they all return computed.
It is more consistent with all other grid properties.
Solves a useful use case without us having to add an API.
With luck compat is low and huge benefit, but I want to
get WG opinion.
astearns: Used value is a line number index?
TabAtkins: Yes
<fantasai> +1 to the change, per TabAtkins’ rationale
emilio: Do implementations preserve that info after layout? not sure
they do
TabAtkins: Don't know, but they have it at some point.
dbaron: Not a fan of interesting things in gCS(). I see used value
as legacy not to repeat. Slight pref for separate API but
not strong
<gsnedders> I am +1 of dbaron's point here
TabAtkins: Separate API one thing is a bit awkward to compute. He
wanted to know how large implicit grid is. I'm okay with
either way. Thought pile into gCS is easier, but okay
with both.
astearns: There are other things in grid returning used?
TabAtkins: grid-template properties give used values
TabAtkins: That's because it's how Microsoft and Chrome did it
initially
fantasai: Microsoft asked to keep because it was compat for them. We
put in spec so Chrome & Firefox did it.
fantasai: I think a special API for grid to get interesting things
is good. It will take a while to figure out what it should
look like and where it goes and do we want layout mode
APIs for other modes. It's a big project. Modifying gCS()
gets us most of what we want. Information you're otherwise
losing doesn't seem like it's that valuable. You can't get
used values at all.
fantasai: Since we're already returning used for other things if we
switch we let people build the APIs they need to explore
the grid.
fantasai: In general I prefer less exceptions but in this case I
think the usefulness and the time it would take to go the
other route I think it points that we should change gCS()
astearns: Summary: because it would take too long to do it right we
should do it wrong
TabAtkins: Not exactly wrong.
fantasai: If gCS() wasn't already a mix of used and computed I would
say don't do that. It is a mix and it's largely legacy
driven we may was well go with utility.
frremy: I think I agree with proposal. It's useful and not complex
to do. Makes sense.
astearns: Houdini APIs when you ask computed you'll get computed?
TabAtkins: Yes.
fantasai: And that's true in all cases where we return.
dbaron: If you're making a change incompatible with all impl you
need to have someone commit to try it soon rather then
sticking it in and hoping someone will implement in a few
years. We don't want dependencies on that decision.
TabAtkins: Valid, yes.
<tantek> right, who is willing to provide an intent to implement
this?
frremy: I'm not technically worried. Right now you get auto. If
you're trying to do something with that you'll get a right
value. I don't think it's a compat problem. I agree we
should impl sooner rather then later.
astearns: Are you volunteering?
frremy: Don't know about that. But don't think it's complex. We
should do it.
astears: Any volunteers?
TabAtkins: I'll ask Igalia folks and bring it back.
astearns: dbaron has a point that longer it sits in spec moldering
the worse it'll be.
astearns: We can wait on resolving until a commitment. We can
resolve and revisit in a month and if not move to impl
revert?
TabAtkins: Resolve to do the change, not change spec until commits,
and add edits in a month if someone adds
<AmeliaBR> There probably needs to be at least a resolution that
implementers can point to in their bug trackers.
astearns: prop: Accept this change but keep the issue open and don't
do edits until there's an impl commitment
astearns: Objections?
RESOLVED: Accept this change but keep the issue open and don't do
edits until there's an implementation commitment.
astearns: AmeliaBR has a point it would be great if people could put
an issue in your own bug tracker
emilio: I looked at other grid properties. it's kind of slow but it
works. I'll file and CC him. If no strong opinion I can impl.
TabAtkins: Since gCS requires compute up front that is an argument
for separate API. Then we can lazy compute
dbaron: It doesn't require computing everything up front because
it's a live object
emilio: Right. You only compute when do getPropertyValue call
TabAtkins: Right, nevermind.
astearns: Should we reverse resolution?
TabAtkins: No.
<fantasai> We should add an issue note in the draft tho
CSS Images
==========
Clarify how gradients should be serialized in presence of the
double-position color syntax
-------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/2714
leaverou: A few weeks ago we cleared the 2 position color stop for
shipping. Right now chrome serializes any gradient with 2
colors stops with same color Chrome uses this syntax.
Worried will break code.
leaverou: Options either gradient read back as it's specified or
canonicalize gradients. If 2 color stops have same color
they're compressed. Or never canonicalize and always use
the expanded syntax
leaverou: No strong opinion. Worried about canonicalizing existing
not spec this way. It could break parsing code. I would
vote for another. Probably return expanded syntax in all
cases. No strong opinion.
<AmeliaBR> I'd also lean towards serializing with the older/explicit
syntax, instead of the newer one. The new syntax is just
sugar for declarations.
dbaron: I think 2 principles on how to define serialization. 1 is
that you want to try and serialize to shorter form. That's
weaker in this case. Other is a syntax that's evolved over
time you want to serialize to older.
dbaron: I think the older form principle should win over shorter.
That still leaves remember how it was spec or always expand
syntax. No strong opinion between those.
TabAtkins: How long ago did we ship always collapse?
emilio: Hasn't yet.
leaverou: Intent to ship was a few days ago. It's Chrome 69.
emilio: It needs the three LGTM's to ship. Needs to be resolved on
this.
<leaverou> Correction: That's conic-gradients that will ship in 69.
The 2 position syntax may ship later.
TabAtkins: I was hoping we had shipped with no compat. Then I vote
always expanded because keeping track of syntax is an
extra bit on every stop that's not otherwise needed.
frremy: Always expand seems better.
leaverou: Agree.
emilio: Seems good to me. Forget everything at parse time.
TabAtkins: I assume that currently we're forgetting at parse time
then eagerly collapsing and then going back and we can
delete that bit and make it simplier
astearns: Objections to always expand gradient syntax?
RESOLVED: Always expand gradient syntax in serialization.
CSS Align
=========
Rules for align/justify-self on static position of
absolutely-positioned boxes need more detail
--------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1432
fantasai: We discussed this last week or the week before.
TabAtkins: 2 weeks.
fantasai: Issue was defining impact of various align. I think
discussion had some confusion about I don't want sizing to
depend on alignment.
fantasai: To clarify we have the sizing of an abspos item depends on
direction property of static pos containing block.
fantasai: Suggesting to look at justify-content property instead on
that containing block so author can control behavior
without effecting bidi. No change in element looked at,
just what element.
fantasai: One case not covered is there's a center value in
justify-content and we had to define a value for center.
fantasai: To revisit the behavior if you have a static pos you use
as the containing block size you use the start edge of the
static pos containing block and end of abspos containing
block.
fantasai: That depends on direction
fantasai: TabAtkins and I decided that since we can get the behavior
for both then for centering both should key off the static
containing block for both sides.
fantasai: That's a summary.
astearns: I see Rossen was involved 2 weeks ago, but he's not on
this week.
frremy: I don't have the right context to talk. We should probably
wait for Rossen to be back
astearns: fantasai and TabAtkins was Rossen adding useful things or
moderating?
fantasai: dbaron and Rossen had definite opinions. He was
participating.
astearns: You okay waiting until he's back?
fantasai: Sure.
astearns: We'll postpone again.
Values & Unites
===============
Allow division of same types in calc()
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/545
astearns: Looks like there's a change for this.
TabAtkins: I think all that's left is...I wanted review by WG.
TabAtkins: I added the resolution from months ago to allow unit
algebra in calc(). dbaron gave me review which I hadn't
seen yet. I'll resolve those. Any other comments or
concerns please let me know. It's in the spec
frremy: I'm wondering how you decided the final unit value of a
calc. You probably have to back track. I think we have to
change how we do this. Seems fine by me, but it requires
keeping track of more things
TabAtkins: Yep, how to determine type it resolves to is in the spec
and you need the algorithm to do Typed OM. I leaned on
Typed OM as much as possible because I think I got it
right.
chris: This is the correct thing to do. It's compatible with typed
OM we should do this.
astearns: This edits is a result of a resolution?
TabAtkins: Yes. We've had multiple resolutions to do this. dbaron
found one in 2014. This is just a review request.
astearns: Sounds like dbaron looked. chris and frremy are okay. I
think we're good. Anyone else wanting to look please do.
<TabAtkins> frremy: https://drafts.csswg.org/css-values/#calc-type-checking
for details on how to resolve the type (final resolution
step is below the <dl>, but relies on the machinery
defined above it)
Selectors 4
===========
reconsider specificity rule for :matches()
------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1027
dbaron: I originally filed this, but don't have a strong opinion on
decision. Spec needs to be clear on which.
<fantasai> List of options for considerations -
https://github.com/w3c/csswg-drafts/issues/1027#issuecomment-354655842
TabAtkins: Other people have argued one direction: :matches() can
introduce some thorny issues on selector inheritence.
:matches() specificity is as specific as the most
specific branch. More than one :matches() with
combinators in the branches...you get...you get a
combinatorial explosion. You get 100s or 1000s of
selectors without going deep
TabAtkins: Naive calc() is expensive for memory and unbounded costs.
TabAtkins: Suggestion was don't bother with that. Resolve it the
same as :not() and :has() where its specificity of the
most specific branch. So if you put an ID or a tag it'll
be that. That's straight forward and matches other
similar pseudo classes.
<dbaron> wait, :not() and :has() do that?
TabAtkins: Only problem is that pre-processors doing :matches()
ahead can only do it with expanding. @extend in SASS will
result in a specificity change. It's not a backwards
commpat issue but may be a problem with people or SASS
trying to switch to doing the new stuff.
astearns: [reads dbaron comment]
TabAtkins: I believe it's correct.
fantasai: :not() takes specificity of most specific argument that
didn't match.
TabAtkins: :not() takes a full selector list
TabAtkins: There's a note. "is replaced by specificity of most
specific element" Also says it has the exact behavior of
:not(:matches(argument)), which is a lie. That's not true
according to spec.
ericwilligers: Pointed out a few lies in my comment on the issue.
TabAtkins: If you look at section 16 :matches() and :has() uses the
branch that matches and :not() uses the most specific
regardless of matching.
frremy: I have another proposal, we don't allow combinators inside
:matches()
fantasai: We had that for a while. Original :matches() had
everything. Implementors said too complex, we took it out,
impl then said they want it. So I think we have
implementations that handle complex selectors
fantasai: [some confusion about combinators vs commas]
frremy: Commas is the whole point of :match() I said combinators
TabAtkins: Combinators are the difficulty
frremy: :matches() without combinators is easy.
TabAtkins: Without combinators, just making it compound, doesn't
simplify. Still have branches. Look at HTML on list
bullets. It's a big list. If you do a simple :matches()
rule you still have combinatorial branching.
emilio: Removing combinators makes it simpler.
<TabAtkins> `:matches(a, #foo) :matches(a, #foo) :matches(a, #foo)`
<= naively expands to 8 choices anyway
<TabAtkins> `:matches(a, #foo, .bar) :matches(a, #foo, .bar) :matches
(a, #foo, .bar)` <= naively expands to *27* choices
anyway
<TabAtkins> `:matches(.a .b .c, .d .e .f)` expands even faster, of
course - expands to over a dozen combination, don't
wanna compute the actual number right now because it's
non-trivial
dbaron: Thing that's still hard is if you leave commas and you can
have multiple matches and have you have backtrack to find
the right one. As you walk up ancestors you might match the
first on the element and a match for the second with ID but
have to try ID ID path
frremy: Oh, I see.
emilio: Making specificity a property of the selector is nice, I
think.
TabAtkins: I see the difficulty and I'm happy to simplify it
frremy: I think proposal is in the right direction. Easier to impl
if only compute specificity of the selector as a selector. I
can see why people would be confused, but I think it's
simpler.
ericwilligers: Same for :not() and make it most specific if it
matches or not?
frremy: Yes
dbaron: I'd be more concerned with this proposal if I thought
specificity was more useful, but I think most people fight
with it.
astearns: I'm hearing at least 3 things.
astearns: 1) places where current spec lies. Need resolutions on
those?
TabAtkins: Won't be a lie once we resolve.
astearns: 2) Removing combinators in :matches()
TabAtkins: I'd like to keep that separate and reject it.
astearns: 3) What we're doing for :matches() and :not(). Is there
consensus?
dbaron: Consensus to make specificity is only a function of the
selector and not the element.
astearns: Specificity on :not() and :matches() depends on selector
and not any possible matching.
TabAtkins: Should do for :has() as well.
astearns: Do not consider matching when determining specificity of
:not() :matches() and :has()
<TabAtkins> proposed resolution: :matches() and :has() should only
consider their selector arguments (using most specific
argument) rather than which branch matched, like :not()
currently does.
ericwilligers: Doesn't know why :has() needs specificity
TabAtkins: You can't right now, but in theory an impl could allow it.
astearns: Having a non-testable assertion is annoyi.ng
fantasai: Of course has needs specificity.
TabAtkins: You can only use it in JS so specificity doesn't do
anything.
fantasai: but if we ever use it in stylesheet
TabAtkins: Current spec has an assertion, we should make it
consistent.
astearns: Objections to making specificity of :not() :has() and
:matches() not depend on matching
RESOLVED: Make specificity of :not() :has() and :matches() not
depend on matching.
astearns: Thanks everyone for calling in and we'll talk next week
Received on Thursday, 31 May 2018 00:36:21 UTC