- From: Dael Jackson <daelcss@gmail.com>
- Date: Thu, 6 Jul 2017 20:11:40 -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.
=========================================
Request to Republish Motion Path
--------------------------------
- RESOLVED: New WD of Motion Path
Alias "nowrap" as "no-wrap"
---------------------------
- Conversation started with the three options the topic had
previously narrowed down to:
1. No change at all
2. Add dashed version as a parse-time alias
3. Add dashed version as a new values that behaves the same as
nowrap
- The group was divided on if the change was a good idea so
conversation mostly focused on option 1 vs either 2 or 3.
- There was very little interest to implement the change quickly
or at all from vendors so it was decided to close this for now
and let the advocates see if they can convince anyone else of
the need.
- RESOLVED: No change for issue about adding no-wrap
Computed value of a negative calc unit that doesn't allow negative
lengths
------------------------------------------------------------------
- The group did some on the call test cases that showed there
wasn't currently any interop on this behavior.
- birtles brought up some concerns around Animations that needed
further consideration before a decision is reached.
- Discussion will continue on github.
Trim whitespace around declarations?
------------------------------------
- RESOLVED: trim white space before / after property value in a
declaration.
Values section shouldn't point wholesale to CSS Level 2
-------------------------------------------------------
- RESOLVED: New Values boilerplate
(https://github.com/w3c/csswg-drafts/issues/1397#issuecomment-311471628)
accepted.
Gradients with a single color stop
----------------------------------
- There was no one strongly championing this proposal, so it will
stay out of the spec until it finds an advocate.
===== FULL MINUTES BELOW ======
Agenda: https://lists.w3.org/Archives/Public/www-style/2017Jul/0001.html
Present:
Tab Atkins
David Baron
Dave Cramer
Alex Critchfield
Elika Etemad
Simon Fraser
Dael Jackson
Chris Lilley
Myles Maxfield
Rachel Nabors
Theresa O'Connor
Naina Raisinghani
Melanie Richards
Florian Rivoal
Jen Simmons
Geoffrey Sneddon
Alan Stearns
Lea Verou
Greg Whitworth
Regrets:
Rachel Andrew
Rossen Atanassov
Bert Bos
Tantek Çelik
Benjamin De Cock
Tony Graham
Vlad Levantovsky
Rachel Nabors
Anton Prowse
Shane Stephens
Scribe: dael
astearns: As always does anyone have any extra things to add to
the agenda. With the caveat that the CSS 2 issue just
raised should go to next week.
fantasai: Right.
astearns: Anything else?
astearns: One thing to point out is we have a month before Paris
meeting. If people can add agenda items and add yourself
to the wiki that would be great.
<dbaron> https://wiki.csswg.org/planning/paris-2017
Rec next steps
--------------
astearns: Is anyone blocked or have progress not on ML?
Florian: In terms of extra progress fantasai has done quite a bit
of the review I asked for. I need to respond to her
comments, but progress is made.
Florian: ChrisL where are we on publication for CSS contain?
ChrisL: I'm not sure. I'll get back to you after the call.
fantasai: What are we publishing?
Florian: CSS Contain to CR.
fantasai: Ah. I just found some issues.
Florian: That's good. Do you want to report them on CR or delay CR?
fantasai: I don't know. It's possibly a major problem. It's about
how the paint containment is defined. It says becoming a
formatting context and that's not defined. It changes
the display value at use time which you can't do because
you have to construct the box tree first.
fantasai: I don't know what you want to do for these things where
you're defining in not defined behavior. We can figure
out a definition or say contain doesn't apply to certain
elements.
Florian: Not sure I want to fix that off the top of my head, but
sounds like it needs to be addressed.
<fantasai> Florian, https://github.com/w3c/csswg-drafts/issues/1457
[missed some discussion due to scribe connectivity issues]
<ChrisL> On CSS contain, I need to convince ralph that the
security issue he raised is no existent
Request to Republish Motion Path
--------------------------------
Scribe: fantasai
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Jul/0000.html
<astearns> request to publish motion path
<ChrisL> +1 to republish motion path
<fantasai> +1!!!!!!!!!!!!!!!!!!!!!!!!!!
astearns: Just a regular WD.
astearns: Lots of updates since last WD, so we should republish.
Any comments?
ChrisL: Might have to be done manually, since FXTF is nominally
between two WGs. If so let me know, and I'll republish
manually.
<birtles> I'm pretty sure I've been able to publish Web Animations
(FXTF) automatically
ChrisL: In practice, CSSWG has taken up FXTF work atm, but anyway,
let me know if it fails publication automatically and I'll
do it manually.
astearns: Objections to new WD?
RESOLVED: New WD of motion
Alias "nowrap" as "no-wrap"
---------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/1537
astearns: Last time we discussed, had 3 alternatives
astearns: 1 No change at all
astearns: 2 Add dashed version as a parse-time alias
astearns: 3 Add dashed version as a new values that behaves the
same as nowrap
astearns: There was some discussion on the issue since, but no
conclusion.
hober: I'm mildly opposed, which is to say that I'm for option 1.
hober: Alias has a cost, not sure that the benefit is more.
<dbaron> This is CSS1: https://www.w3.org/TR/REC-CSS1/#white-space
TabAtkins: I mistype this all the time, and I can't be the only
person who does it. It's bad keyword.
TabAtkins: We should have done it right the first time.
TabAtkins: Would have preferred if we had no-wrap in flexbox and
nowrap in white-space with additional white-space:
no-wrap keyword.
nainar: I'm with Tab, we have multiple people making this error
within a week.
TabAtkins: parse-time alias is low-cost. I'm fine with just doing
it that way.
astearns: Difference is in CSSOM?
TabAtkins: yeah.
TabAtkins: CSSOM will always return nowrap.
TabAtkins: Benefit is that older tools will continue to work
TabAtkins: downside is authors might be confused.
TabAtkins: Full alias does incur more cost on engine
TabAtkins: parse-time is trivial.
Florian: Not a strongly held belief, but I think 2 is in-between,
not really worth it.
Florian: Doesn't really give a transition path to a better world.
Florian: If we go with option 3, we can eventually forget nowrap
ever existed.
ChrisL: Agree with Florian.
dbaron: Both option 2 and option 3 have a substantial cost to
developers.
dbaron: If we go with option 2, then ppl who use dash need to know
that OM doesn't use dash.
dbaron: With option 3, then it depends on who wrote the CSS rather
than just being the developers with a dash habit.
astearns: Your JS has to check for both in option 3.
dbaron: With option 3 we're imposing cost to developers for a long
time.
TabAtkins: So all three put cost on developers
TabAtkins: None seem obviously better.
hober: If it's a toss-up between all three, the correct choice is
no change.
jensimmons: I am always thinking where is CSS going to be in 30
years.
jensimmons: If we switch to option 3, 30 years from now everyone
can forget this ever happened. No one will use nowrap.
jensimmons: I'm into 3.
TabAtkins: I'm 100% sure minifiers will remove the dash.
TabAtkins: Option 1 puts mental load on everyone who uses CSS.
Option 2 only puts it on ppl who deal with OM, which is
a much smaller class.
TabAtkins: I don't have an opinion on 2 vs 3
TabAtkins: But do feel strongly about 1
<jensimmons> +1 for what Tab just said. Most people writing CSS
aren’t also writing JS handling that CSS
Florian: This is also not a property value that is commonly
manipulated through JS
astearns: One person in favor of #1, anyone else?
* hober thought dbaron made a good argument for no change :)
smfr: I would vote for no change
<gsnedders> I agree with TabAtkins.
myles: Me too
<Florian> Favors 3, not as strongly as Tab.
<nainar> I'm with Tab on this one. (3 > 2)
<dbaron> I think I lean towards no change; I don't think getting
rid of the 'nowrap' value at some indefinite point in the
future is realistic.
astearns: So Apple against change, Google for some kind of change,
and some arguments for change being #3 in order to make
future of CSS make more sense.
hober: My impression was also dbaron was arguing no change?
dbaron: I lean towards no change, but I see both sides so not that
strongly in that camp.
dbaron: But pretty hesitant to agree to do it now
<leaverou> I'll abstain from this poll, no strong opinion either
way. I've never ever typed no-wrap personally, or seen
any student who did, but it doesn't come up all that
often.
gregwhitworth: I'm with dbaron, no strong opinion. Do know that
authors run into it, e.g. postCSS plugin to fix
this.
gregwhitworth: I wouldn't be in a rush to implement.
astearns: Sounds like we have no consensus to add no-wrap at this
time, in either version.
astearns: One engine interested, and others not so interested, so
not something to bite off today.
fantasai: I would add that if we have one engine add and others
don't, we're in a really bad world, because authors
using that engine will think it works and in other
engines it won't.
astearns: OK, so I'm saying we close this as no change, and the
ppl who want it can try to convince the others.
RESOLVED: No change for issue about adding no-wrap
Computed value of a negative calc unit that doesn't allow negative
lengths
------------------------------------------------------------------
github topic:
https://github.com/w3c/csswg-drafts/issues/434#issuecomment-310183908
TabAtkins: Spec text previously said that you can put negative
numbers into calc(), it's fine, because we can't in
general tell if it's negative or not
TabAtkins: we do a clamping at some point if it needs to clamp to
a particular range.
TabAtkins: Spec previously said that clamping happens at computed
value time, but you can't always tell, e.g. width has
to happen at used value time (and font-size has to
happen at computed value time).
TabAtkins: fantasai and I discussed and realized there are two
possible interpretations of this conclusion:
TabAtkins: for properties that clamp at computed value time
TabAtkins: can clamp through at computed value time.
TabAtkins: For properties that clamp at used value time, some
things can clamp at computed value time.
TabAtkins: So do those properties clamp both at used and computed
value time, or just at used value time?
<birtles> I think we want to clamp as late as possible -- since
animation operates on computed values (more or less)
Florian: So for multi-stage examples if you can't clamp, you keep
a calc() expression, right?
TabAtkins: If you're width is calc(5px-5%) it'll stay as that at
computed value, clamps at used value.
Florian: But if you clamp at calc(5px-5em) can clamp at computed
value.
TabAtkins: If we clamp only at used value time, we need a
definition of which property is which kind of
computation.
TabAtkins: And then, if we ever add a unit that does used value
time computation to a property that currently clamps at
computed value time, it would change behavior.
TabAtkins: So I prefer clamp at all times behavior.
dbaron: I was going to say I prefer the other one.
dbaron: birtles said same thing on IRC, but was thinking about
animations.
dbaron: I was thinking essentially of things like width:
calc(-5px) vs width: (0%-5px) vs vs width: (10%-5px)
TabAtkins: You can't add 0% to 1s, so while we technically can
resolve zero immediately, we would treat it like any
other percentage.
dbaron: Still worth thinking about animations.
<birtles> specifically my concern is you want to interpolate using
the unclamped values and then clamp
Florian: If we go that way, pretty important to go the way Tab
says for 0%, otherwise discontinuity between 0% and
0.00001%
TabAtkins: Don't understand animations issue.
TabAtkins: font-size resolves everything at computed time already
TabAtkins: So animations should see value of 0 for 0px, don't see
why width should be different.
[missed]
dbaron: You can have a calc() that's a result of interpolation.
dbaron: If one of the end points does different things than the
intervening value..
TabAtkins: If the values are different, then the middle value will
always be a valid value anyway.
TabAtkins: If it's a used value time unit involved, then it'll
always stay as a calc()
<dbaron> (bouncing meaning timing functions that go outside 0-1)
<birtles> e.g. if you support calc() for opacity and interpolate
between calc(-1) to calc(3) you'll get different results
if you clamp the endpoints before interpolating
Florian: None of these allow us to have results earlier, to get
fully resolved value at computed value time ..?
TabAtkins: Just feels nasty and weird if font-size can clamp its
values at computed value time, but width can't even if
it uses the exact same value.
TabAtkins: And also, as I said before, if we add a used-value time
unit to a computed-value-time-only property, it would
change behavior
TabAtkins: observable in animations as well as OM.
TabAtkins: If we say that a property only has computed value time
units, then it can never gain a used-value time unit.
Florian: Why?
TabAtkins: Because it will change from clamping at computed value
time to clamping at used value time, seeing raw calc()
value in the animation
TabAtkins: Difference is e.g. animated from -1000px to 1000px,
would stay at 0 for first half if doing used value
time, and would animate from 0 to 1000px over full
range if doing computed value clamping.
dbaron: What do implementations currently do?
[TabAtkins writes some tests]
TabAtkins: Looks like in Chrome at least, appears to delay width
clamping to used value time right now
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5256
TabAtkins: Spends half of the animation sitting at zero
TabAtkins: wait, this is inconsistent
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5257
Myles: Safari does the other behavior. never sticks at zero.
TabAtkins: Sounds like no interop.
astearns: Think we should kick this back to github for testing,
come back with animation data
astearns: Anything else to bring up on this topic?
Trim whitespace around declarations?
------------------------------------
github topic: https://github.com/w3c/csswg-drafts/issues/774
TabAtkins: This has impact on what custom property values are
TabAtkins: Because custom properties capture tokens.
TabAtkins: Currently the white space before first value token is
preserved.
TabAtkins: All of the normal properties serialize out from OM, so
they get normalized white space output.
TabAtkins: Some people brought up maybe we should trim the white
space from beginning and end of a token stream.
TabAtkins: This would be a tweak to the Syntax spec
TabAtkins: to throw away this white space.
TabAtkins: No consequence for ordinary CSS, they will continue to
parse and serialize as usual.
TabAtkins: It may or may not have an observable difference on
serializing a rule of a style sheet... I think they
generally reserialize from internal structures.
<gregwhitworth> basically this saves authors from writing trim()
when manipulating custom props
TabAtkins: Would have desired difference on serialization of
custom property value when ppl write with typical
whitespace after colon.
TabAtkins: Saves authors from writing trim(), right, and also from
forgetting to write trim() because they never have to
write that for any other property.
leaverou: Is there any use case where you want the white space?
TabAtkins: If you're embedding an esoteric language...
TabAtkins: If you're embedding another programming language into
CSS you'll have consequences anyway.
TabAtkins: Don't think any other issue.
leaverou: So benefit to it, and not hurting any use case. So I'm
hugely in favor.
leaverou: Every time I use OM for custom properties, have to use
trim(), it's really annoying.
astearns: Proposal to trim whitespace on either side of all
declarations. In favor / opposed?
<ChrisL> +1 to trimming
<fantasai> in favor
RESOLVED: trim white space before / after property value in a
declaration.
Values section shouldn't point wholesale to CSS Level 2
-------------------------------------------------------
github topic:
https://github.com/w3c/csswg-drafts/issues/1397#issuecomment-311471628
TabAtkins: Issue raised by dbaron on css-align, the values section
pointed straight to CSS2
TabAtkins: better to point to more up-to-date specs.
TabAtkins: This text shows up in many of our specs, so we went an
updated all of them... we can revert or change as
necessary.
TabAtkins: Because it's a wide-ranging change, wanted to get WG
approval before making part of spec boilerplate
[New Text:
This specification follows the <a
href="https://www.w3.org/TR/CSS21/about.html#property-defs">
CSS property definition conventions</a> from [[!CSS2]].
Value types not defined in this specification are defined in
CSS Values & Units [[!CSS-VALUES-3]].
Other CSS modules may expand the definitions of these value
types.
In addition to the property-specific values listed in their
definitions, all properties defined in this specification
also accept the <a>CSS-wide keywords</a> keywords as their
property value.
For readability they have not been repeated explicitly.
Florian: Seems to work for vast majority of specs. Have you
checked it makes sense for specs that don't define
properties?
Florian: Like MQ or Selectors?
TabAtkins: Those either don't have values section or it worked.
TabAtkins: One or two specs had an extra line of text, but
everything that had a value section could take this
without any addition.
Florian: If put in bikeshed boilerplate?
TabAtkins: Defer that question to later.
TabAtkins: Just wanted to verify the text, and if ppl ok to me
updating all the specs.
dbaron: I'm okay with the replacement, but think it could use
further improvement.
dbaron: E.g. in Animations we define Animation line, CSSOM defines
another line...
fantasai: I think we should have an updated propdef explainer
somewhere, e.g. snapshot.
dbaron: Can just make everything hyperlinked.
fantasai: Yeah, but should have more explanation than just a
hyperlink
...
Florian: Did any of the sections to be replaced have anything
about what dbaron mentioned? If not, it's a strict
improvement and we can deal with that later.
TabAtkins: It was definitely outdated, e.g. didn't link to
CSS-wide keywords because that wasn't a thing.
TabAtkins: Definitely better than what we have, could improve
further.
astearns: So you want approval of the changes.
fantasai, Tab: Yes
fantasai: And also if there are specific changes desired, resolve
to have us propagate those or discuss further in GitHub.
astearns: Proposed to accept this improvement, raise GitHub issues
for further improvement.
RESOLVED: New Values boilerplate accepted
Gradients with a single color stop
----------------------------------
github issue: https://github.com/w3c/csswg-drafts/issues/1576
leaverou: Intended to be allowed in images 3, was prose in the
spec...
fantasai: Actually, no, the CR of gradients did not include it in
prose or grammar.
leaverou: But anyway, would like to relax in Images 4.
leaverou: Doesn't allow a lot of use cases, but it's simple case
and improves debugging / preview.
leaverou: Can quickly see the gradient.
leaverou: Use case of single color image isn't great, because we
have image() function for that.
leaverou: I'm fine either way
leaverou: But would allow it if it was up to me.
leaverou: Thoughts?
<dbaron> seems reasonable to me if there aren't compatibility
issues -- and if implementations can update in a
reasonably synchronized way
Florian: Since it's a syntax you could easily accidentally write,
hoping for it to do something, even though it currently
does not, there's a non-trivial risk of web pages out
there relying on it not working.
Florian: Maybe not, but could be a case.
leaverou: Could we get stats?
ChrisL: People wanted to do solid colors and animate ...
ChrisL: There were people who wanted to have a single color
gradient.
leaverou: We have image(<color>).
ChrisL: Which way should we move people, towards image() or
linear-gradient()?
TabAtkins: Would prefer to move ppl to image(), much clearer and
shorter.
ChrisL: It's also unintuitive to get that effect.
Florian: If you use it as a start point for an animation, though,
then linear(blue, blue) is easily written.
TabAtkins: For animations, you need to match up number of stops
anyway.
leaverou: So the main use case seems to be debugging / tooling.
astearns: We are over time, not hearing any implementers lining up
for this.
astearns: Maybe solicit feedback directly from implementers, if
anyone wants to champion then add back to agenda.
astearns: If not, shouldn't go in spec
astearns: Thanks everyone, we're done.
Meeting closed.
Received on Friday, 7 July 2017 00:12:45 UTC