- From: Dael Jackson <daelcss@gmail.com>
- Date: Wed, 20 Nov 2019 18:43:15 -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.
=========================================
Scheduling
----------
- The next F2F is in about 2 months so anyone planning on going
should make travel plans.
- There is an email on the private list to coordinate which calls
need to be canceled around the end of year holidays. Another one
will be sent to see if we need to cancel next week due to US
Thanksgiving travel.
CSS UI
------
- RESOLVED: Remove implementation warning and add a note about
possible changes to list of values for webcompat.
Wording at editors discretion (Issue #1250: Remove
warning about 'appearance')
CSS Values 4
------------
- RESOLVED: All math functions aggressively simplify their
calculations as far as possible for a given
value-computation stage. (Issue #4399: What should
non-calc() math functions serialize to when they're
fully resolved?)
- RESOLVED: If numeric simplification of a math function results in
a single value, the serialization is that value wrapped
in `calc()` (Issue #4399)
- Work will continue on defining how unit canonicalization works
CSS Grid & CSS Flexbox
----------------------
- RESOLVED: Accept edit in
https://github.com/w3c/csswg-drafts/commit/0db00e1870bcb74bd820f89beed168514d9a6ec5
(Issue #4065: Blockification section should use the
computed value, not the box of the element)
- A separate issue will be opened to look and see if the same issue
exists in the Houdini Layout API
Transforms 2
------------
- RESOLVED: Working group is fine with translate, rotate, and scale
shipping (Issue #4515: The readiness of shipping
individual transform properties - translate, rotate,
scale)
- RESOLVED: Move the 3D Transforms to a level 3 of Transforms
- After the call there was IRC chat that concluded separating the
individual properties from 3D Transforms would remove value from
the individual properties and will likely need to be revisited.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2019Nov/0008.html
Present:
Rachel Andrew
Rossen Atanassov
Amelia Bellamy-Royds
Christian Biesinger
Oriol Brufau
Tantek Çelik
Emilio Cobos Álvarez
Dave Cramer
Elika Etemad
Javier Fernandez
Simon Fraser
Dael Jackson
Chris Lilley
Peter Linss
Stanton Marcum
Myles Maxfield
Simon Pieters
Anton Prowse
Manuel Rego Casasnovas
François Remy
Florian Rivoal
Devin Rousso
Jen Simmons
Alan Stearns
Eric Willigers
Scribe: dael
Scheduling
==========
astearns: Are there any changes people would like to the agenda?
astearns: I'd like to add that we do have a F2F in ~2 months. People
should start making plans for travel.
astearns: There's also an update on the private list about a dev
meetup. If anyone has something to present please start
talking to people about it
Rossen: Also wanted to draw attention to the schedule for holidays.
Started a thread on the private mailing but haven't seen
engagement
<fantasai> proposed schedule wfm
Rossen: Given 25th Dec and 1 Jan are on Wednesdays it means we have
2 weeks off from calls. Wanted to see if people needed extra
time before or after
Rossen: If you have strong desire to take the 18th off we should
decide soon
astearns: Thanks Rossen
astearns: Anyone with additional constraints should bring them up.
astearns: I don't see TabAtkins on yet
astearns: Then let's skip calc() until he's on
CSS UI
======
Remove warning about 'appearance'
---------------------------------
github: https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-492759907
florian: I can unless whomever added it wants it
florian: Design of appearance property is proceeded by a warning
that we don't know if it's webcompat. What's specified is a
combination of none and auto and a few compat things. It
seems that design works and people are trying to implement.
I have been asked to remove the warning.
florian: I support removing the warning. If we agree I will remove
the giant note that says this isn't good to implement
dbaron: Who has shipped support?
florian: I think Google is trying to ship support for this. I don't
know the state
florian: I think Mozilla is also trying
tantek: Presumably someone is trying to ship or else it wouldn't be
a compat problem
florian: It was a compat concern. The work zcorpan did showed it was
likely to be web compatible. We never know until everything
is finished
tantek: Comment says it's for webcompat. The legacy keywords are for
web compat
florian: The spec is for web compat
tantek: Then that means someone must have implemented it.
fantasai: Is zcorpan on?
florian: It was designed in order to handle web compat. zcorpan
researched it and I believe he concluded it was. It has not
shipped
<fantasai> +1
Rossen: Any reason not to remove the warning? Warning was pending
someone attempting to impl. Seems there are attempts to impl
and experiment. If that's the case let's remove warning
fremy: Makes sense. If there's a problem when people impl we can
change the spec. No reason to think there is so we can remove
the note.
dbaron: I'd prefer to leave something but remove the warning it's
not okay to ship. I think we should still have a warning
saying we're not sure this is going to work.
Rossen: Are we sure anything will work before we ship?
dbaron: I think we're particularly unsure
<fremy> this => Rossen: Are we sure anything will work before we
ship it?
astearns: Could change to something that says set of values other
than none needs to be evaluated. Need to figure out if
this is the correct set
florian: Agree but we have spent time investigating. It won't be
over until shipped, but it's not that it hasn't started
astearns: Something like as far as WG understands this is the set of
non-none values, but more input is welcome
tantek: I think your first wording is right, but change the tense to
be that we are evaluating and continuing to evaluate
astearns: zcorpan evaluated and we came to a conclusion
tantek: He says the list is being tweaked so I think that's not final
florian: He requested the removal
tantek: But I wouldn't dispute what he's saying
<fantasai> Replace current wording with "ISSUE: We are evaluating
Web-compat of this feature's list of values. Please send
any relevant feedback to the CSSWG" ?
<fantasai> or maybe even s/ISSUE/NOTE/
astearns: Proposal: We have a note suggesting people impl and try
this out, but we are open to more input on what the
necessary set of values are. Let the editors wordsmith
that.
dbaron: Sounds fine
astearns: fantasai suggests it's an issue not a note?
fantasai: No opinion, I just wanted to put wording
fantasai: Leaving to the editor and moving on is okay
* fantasai doesn't mind either way
tantek: Because it's an open question still about normative text I
think it deserves to be an issue. Note implies nothing
normative will change
<fantasai> let's resolve on issue, since Tantek cares, and move along
astearns: We often put notes in L3 drafts saying things might change
in L4
astearns: Would you object to leaving as a note tantek?
tantek: I can live. Just indicating preference
astearns: Proposal: Remove implementation warning and add a note
about possible changes to list of values for webcompat.
Wording at editors discretion
RESOLVED: Remove implementation warning and add a note about
possible changes to list of values for webcompat. Wording
at editors discretion
CSS Values 4
=============
What should non-calc() math functions serialize to when they're fully
resolved?
---------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4399#issuecomment-554535978
TabAtkins: I brought up a question about when a non-calc() math
function is fully resolved what should it be serialized
as? We have old calc rules that say if you do 1px+1em you
combine at computed value and serialize as 17px. If you
have min(10px, 20px) what should it serialize as? We can
resolve it to 10px or should we preserve it was a min
calculation?
TabAtkins: I'm neutral to where we go. Current text simplifies
everything as far as possible which might land on a plain
number. Simon preferred preserving root node's identity.
TabAtkins: I can do that, not a big deal in spec text. Just some
annotation. I want to know what the other impl opinions
are
<AmeliaBR> Do we ever need to keep at least a function wrapper for
the same reasons as `calc(-10px)` needs to keep a wrapper?
smfr: Need to have a distinction between specified and computed.
Most of my questions were about specified value. Text about
simplification implies it's on specified value.
smfr: How much simplification happens on the specified value and
then what happens on computed. I prefer computed simplified as
much as possible to a bare value if possible. Specified value
is how much do you want to round trip or is it okay to
collapse redundant mins?
<AmeliaBR> Agree with smfr: if simple serialization converts
`calc(200px/4)` to `50px`, then it makes sense to do the
same with simple mathematical min/max
TabAtkins: In spec I do full simplification on specified. I realize
from your comment I'm too aggressive. Still have the
question about what is the best to do with a min that has
identical units? Does it retain its structure at spec
value time?
TabAtkins: I can go either. I can do light that combines identical
units like old calc did or I can do more aggressive and
not canonicalize units.
emilio: Browsers do canonicalize units, right?
TabAtkins: At specified value I don't think calc(1in) becomes px
emilio: calc(1px+1q) I get 10.something px.
smfr: Different units get canonicalized
TabAtkins: So the tests from smfr were wrong?
smfr: Lots of non-compat behavior. WPT have a mixture of behaviors
so I don't think we should go on what those tests are doing
smfr: One of the considerations for specified value is are there
authoring tools that expect nested calc to be preserved. I
know glazou was concerned back in 2017 because it would break
authoring tools.
TabAtkins: At time we resolved getting rid of nested calc was fine.
The loss to authoring tools was considered to be fine due
to simplifications in impl and easier for end user.
TabAtkins: Don't want to revisit that if possible. Still a range of
stuff we can do. I don't want to preserve more than the
old calc. I prefer preserve as little as possible
fantasai: calc if nested is equivalent to parenthesis. Switching min
or max is a little different. Not quite the same situation
TabAtkins: I would argue same as distributing multiplication across
properties. That's a re-write of algebraic structure
which seems similar to simplifying away a min
* emilio agrees with TabAtkins
fremy: I was hearing emilio and I found Chrome behavior is weird. If
you set border calc(1inch) you get back calc(1inch) but
calc(1in+1px) you get 97px. I think ther'es not web compat
and we an do what feels right
TabAtkins: That's super weird, that feels like us going we're done
and can exit early
<fantasai> fremy, post testcase?
<emilio> fantasai: document.body.style.left = "calc(1q)";
document.body.style.left
<fremy> fantasai well my favorite test website is down...
<fremy> but ok
<emilio> Firefox behaves the same as Chrome here, but agreed it
feels weird
<emilio> fremy: fwiw what happens on Firefox is that as soon as we
need to canonicalize `<length>`s we simplify both to px
<fremy> @ fantasai emilio : testcase : https://jsfiddle.net/aj7qL95r/
TabAtkins: Proposal: Since calc in general does do aggressive
simplification we preserve that through the new math
expressions. At specified value time we simplify down.
Maybe preserve root node at specified time, but that's
thrown away at computed value time
TabAtkins: Does that sound fine and, if so, which way on the root
node?
smfr: Prefer preserve the root node. If you have calc with a nested
min and you could reduce, I don't know if you should
smfr: Keeping root node as a function is right. And simplify as much
as possible for computed
TabAtkins: Will argue to get rid of nested things. min is a binary
operator square root is. Preserving the later things as
functions seems inconsistent to me
smfr: That implies if you have a calc with min inside you'd replace
the calc with a min?
TabAtkins: No, the root node retains at specified value.
smfr: Doesn't change function type?
TabAtkins: Yeah. Preserved. Everything under simplifies as much as
possible. calc(min(px,%)) stays. calc(min(px,px))
simplifies
emilio: I'm fine with dropping root, but I don't mind
AmeliaBR: I agree with arguments, but I think we lost them a long
time ago. I don't like that we do a lot of math
simplification at serialization with calc, but we do.
calc(10px/3) reads back as calc(3.333px).
AmeliaBR: Similar logic in the other functions seems to be a
consistency thing. Important to keep the wrapper that says
this is a math function because rules about clamping.
AmeliaBR: That would presumably happen with other math functions
too. If you say in spec value min(10px,20px) it should
still read back with functional wrapper of min(10px) as
simplified.
AmeliaBR: You want to keep because what happens if it's min and a
value is negative and negative is invalid in that context.
We need the wrapper
TabAtkins: If you forget the root node it serializes as a calc.
AmeliaBR: Do we turn all simplified math functions into a calc
wrapper is the question?
TabAtkins: Yep
AmeliaBR: Then yeah, simplifying...if the result is a single value
it makes sense as a single value with a calc wrapper
rather than preserve min/max when we can't do that with
other functions
astearns: We're proposing to simplify functions like we do calc and
change calc specified value to retain the wrapper
TabAtkins: Changing the new stuff.
TabAtkins: The root node of a calculation tree retains it's identify
astearns: If root is calc function?
TabAtkins: Then it's a calc
TabAtkins: That's preserved in specified. At computed it goes away.
astearns: Functions simplify the way calc does. Outer most function
context is maintained for new functions.
AmeliaBR: I have a problem with the second. Should we get the first
resolved?
TabAtkins: I'll write proposed resolution
<TabAtkins> Proposed resolution 1: All math functions aggressively
simplify their calculations as far as possible for a
given value-computation stage.
astearns: Objections or continued discussion on proposed resolution
1?
RESOLVED: All math functions aggressively simplify their
calculations as far as possible for a given
value-computation stage.
astearns: TabAtkins will you type the 2nd?
<TabAtkins> Proposed resolution 2: At specified-value time, the root
of a calculation tree retains knowledge of what type of
function it is and serializes accordingly, even if it
could be simplified to a single number. (At
computed-value time, they'll turn into a plain number if
possible.)
AmeliaBR: Problem with root of calc tree retaining knowledge is some
function types are math operators like power. If you
simplify square root of 4 it means erase function wrapper
TabAtkins: The be precise here I would not simplify root node, start
simplification at children of root node
AmeliaBR: If I have sqrt(4) inside a calc it's simplified, but sqt4
is not simplified?
TabAtkins: Correct. It's either all or none. I don't want to keep
min but not sqrt
<TabAtkins> calc(sqrt(4)) => calc(2); sqrt(4) => sqrt(4)
AmeliaBR: Considering sqrt and power anything simplified to a single
value simplifies to that wrapped in a calc.
TabAtkins: That's in the spec today. smfr expressed desire to keep
root node around. Easy to do spec wise.
smfr: I think AmeliaBR is suggesting sqrt(2) that becomes
calc(1.41...). You replace sqrt with calc.
TabAtkins: That's spec today
<AmeliaBR> yes, serialization of `sqrt(4)` would be `calc(2)`
florian: Does spec say [missed]
TabAtkins: No
florian: I think that's what AmeliaBR is suggesting
TabAtkins: AmeliaBR are you suggesting extra calcs?
AmeliaBR: If we need a wrapper use cal
florian: calc(sqrt(4)) what is that?
florian: calc(2) or calc(calc(2))
<AmeliaBR> Also `min(10,20)` serializes as `calc(10)`
AmeliaBR: You just need the outer wrapper
florian: That is current spec
AmeliaBR: I think we're at the point where everyone understands, but
not consensus on strategy
TabAtkins: I think we've converged. I was arguing smfr wants exact
ID but that's not the case. We fully simplify. At
specified value time we need to wrap it in a calc if it's
single number. So no change to current rules for
calculation trees
smfr: Root function might be a calc. Might still be a min/max
TabAtkins: Yes, if you can resolve min it's a min.
smfr: I like that calc is way to signal out of range things
TabAtkins: We can go with no change to current rules for calculation
trees if no objection?
AmeliaBR: I'm writing down a version
<AmeliaBR> Proposed resolution: if numeric simplification of a math
function results in a single value, the serialization is
that value wrapped in `calc()`
smfr: Current rules is ambiguous.
TabAtkins: New version of spec shouldn't be ambiguous. I'll put in a
note that it stays a calculation tree is clear. It's in
spec, but easy to go past.
smfr: I meant there are 3 specs and not sure which people are
talking about.
smfr: ED right?
TabAtkins: Yeah
astearns: TabAtkins is AmeliaBR proposed resolution what you're
thinking about?
TabAtkins: Fine
TabAtkins: End result is no change, but the explicit wording works
smfr: Spec could be if you encountered bare math you open calc
TabAtkins: I'll work with you in the issue to make it super clear
smfr: Still want clarity on unit canonicalization happens
TabAtkins: We'll continue that in issue
astearns: Objections to if numeric simplification of a math function
results in a single value, the serialization is that value
wrapped in `calc()`
RESOLVED: If numeric simplification of a math function results in a
single value, the serialization is that value wrapped in
`calc()`
astearns: Please do continue about unit canonization in the issue
CSS Grid & CSS Flexbox
======================
Blockification section should use the computed value, not the box
of the element
-----------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4065
astearns: TabAtkins put this on?
TabAtkins: This should be quick. We made edits to the issue a few
weeks ago. Checked with emilio and he's good. Final call
for objections from anyone that's reviewed. It's CR so we
need resolution
TabAtkins: We rephrased blockification to talk about display values
rather than rely on box tree. Behavior difference is
minuscule but makes it easier for implementations and
more similar to other cases.
TabAtkins: If someone hasn't reviewed we can delay now or revisit in
future
<fremy> Just took a look, LGTM
astearns: Looks like we have 3 reviews. Anyone want more time?
oriol: Not an objection. I think Houdini custom layout has same
problem and needs update.
TabAtkins: Probably because Ian copied the text. Can you open an
issue pointing at this one and we'll take care of that
astearns: Proposed: Accept edit in
https://github.com/w3c/csswg-drafts/issues/4065
RESOLVED: Accept edit in https://github.com/w3c/csswg-drafts/issues/4065
CSS Grid
========
Overflow with auto-repeat and minmax()
--------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4043
astearns: fantasai do you want this?
TabAtkins: I'm happy to do it
TabAtkins: We missed where if you do a minmax function and a repeat
autofill or autofill we previously based it on max track
sizing function. You had to give a real length.
minmax(100px, 50px) we would tile columns based on
filling 50px and then at layout they're all too big.
TabAtkins: We now floor the max with the min. Need review from impl
if they want. Otherwise should be relatively rubber stamp.
astearns: This has had review. Anyone want time?
astearns: Objection to Accept change in
https://github.com/w3c/csswg-drafts/issues/4043 ?
RESOLVED: Accept change in https://github.com/w3c/csswg-drafts/issues/4043
CSS Grid
========
How should spaces be treated in markers?
----------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4448
TabAtkins: I haven't reviewed
* fantasai suggests item 9
<fantasai> that might be time-sensitive?
CSS Transforms 2
================
The readiness of shipping individual transform properties - translate,
rotate, scale
----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4515
astearns: Gecko is ready to ship. Any concerns about that?
<fantasai> I would like us to get the spec to CR soonish
<fantasai> would it make sense to drop the 3D Transforms section
to L3
<fantasai> ?
<fantasai> and then make L2 be 2D transforms + this feature?
astearns: [reads fantasai IRC] should we drop 3d transforms for that?
<fantasai> Just push to level three
smfr: Transforms 1.5 which is 1+individual functions
TabAtkins: I'm fine with punting items to L3
astearns: Is there another impl of individual functions soon?
<fantasai> We're not in CR yet, so it's about the spec, not impl
status
fremy: I think they were behind a flag in old Edge
<fantasai> if spec for individual functions is done, let's push it
to CR and defer the rest to L3
astearns: I wouldn't mind moving the 3D transforms. Wondering what
other small things will drop to L3.
fremy: Old Edge has a flag to enable individual transforms. So we
have impl to move the spec forward
<fantasai> Propose several resolutions
<fantasai> First resolution, clear these to ship
<fantasai> 2nd resolution, push everything other than these features
(unless someone thinks there's something else close to
CR) to L3
smfr: Interaction with motion path I'm forgetting about?
astearns: Can anyone answer that yes or no?
<fantasai> I don't think so
emilio: Motion path adds transform-ish stuff but the order is well
defined.
myles: There's an order. Apply transform properties and then motion
path. Might have it flipped, but it's well defined. No
interaction
astearns: First proposed resolution is clear these to ship
astearns: Not hearing concerns. Objections to Working group is fine
with translate, rotate and scale shipping?
<TabAtkins> Yeah, the total effective transform is <motion-path>
<translate> <rotate> <scale> <transform>
RESOLVED: Working group is fine with translate, rotate, and scale
shipping
astearns: 2nd is move the 3d transforms out to a new level. Any
concerns?
<AmeliaBR> ship, ship, ship! Take down the flag & sail that ship!
<dbaron> also transform-origin somewhere in there
<TabAtkins> (with perspective/transform-origin bodged into the
<transform> bit there)
<TabAtkins> Or wait, dbaron's right, transform-origin goes before
<translate> and after <transform>
<dbaron> also perspective is a little bit fun
RESOLVED: Move the 3D transforms to a level 3 of Transforms
astearns: I think we should take it up in a call soon about taking
L2 Transforms to CR
astearns: I don't think that's something for 4 minutes
<fantasai> probably need to wait for edits :)
<fantasai> also maybe republish both as WD/FPWD
astearns: IRC question about transform-origin?
TabAtkins: No, just chatting about effect, but it's well understood
Scheduling
==========
astearns: Thanks everyone for calling in.
myles: Is next week on?
TabAtkins: I'm on vacation
myles: I am too
* fantasai is available
<smfr> regrets
tantek: Regrets
Rossen: I think many US folks are going to be on vacation
astearns: Let's take it to private list
<dbaron> should we do a yes/no doodle or something like that?
Rossen: Let's take it to the list with other meeting/time off
discussion
astearns: Sounds good. Thanks everyone
Transforms 2 - Post Call IRC
============================
<ericwilligers> With moving 3D transforms to L3, are we saying
individual transforms would be in L2 but as 2D
properties? I don't think anyone would want to ship
them as 2D.
<astearns> hmm - good question, ericwilligers
<dbaron> perhaps that suggests moving 3-D to level 3 doesn't
actually help anything?
<TabAtkins> Ah, true
<TabAtkins> astearns: Can we do an async re-do of the resolution on
the www-style list, then, making it clear that the WG is
fine with shipping the individual transforms ahead of L2
being CR?
<astearns> I'll comment on the issue
<astearns> The ship resolution was independent of pushing L2 to CR
<AmeliaBR> Yeah, those transforms resolutions are not so good in
retrospect. It would be a big hassle to spec a 2D-only
version of the individual transform property. And it
would be a much bigger hassle to split the
implementations and ship 2D versions unflagged but keep
3D versions flagged (especially since the rest of 3D
isn't flagged), so probably best to keep them all
together.
Received on Wednesday, 20 November 2019 23:43:57 UTC