See also: IRC log
<nainar> I'm not a member and can't access the details.
<astearns> https://mit.webex.com/mit/j.php?MTID=m34e7a273ee0398395b9408821caaa184 <https://mit.webex.com/mit/j.php?MTID=m34e7a273ee0398395b9408821caaa184
<dael> ScribeNice: dael
<dael> ScribeNick: dael
<astearns> US Toll Number: +1-617-324-0000
<astearns> Access code:640 905 190
astearns: As always does anyone have any extra things to add to the agenda. With the cavet that the CSS 2 issue should go to next week.
<myles> ChrisL: wow you are amazing!
fantasai: Right.
astearns: Anything else?
<myles> thank you ChrisL!
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
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.
... ChrisL where are we on pub for CSS contain?
ChrisL: I'm not sure. I'll get backc to you after 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 contruct the box tree first.
<RachelNabors> Trying to be present. Wifi... failuring...
fantasai: I don't know what you want to do for these things where you're definingin not defined behavior. We can figure out a defintion 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,
<fantasai> https://github.com/w3c/csswg-drafts/issues/1457
<ChrisL> On CSS contain, I need to convince ralph that the security issue he raised is no existent
<astearns> waiting on dbaron response to align issues
<ChrisL> +1 to republish motion path
<fantasai> ScribeNick: fantasai
<astearns> https://lists.w3.org/Archives/Public/www-style/2017Jul/0000.html
<astearns> request to publish motion path
astearns: Just a regular WD
... 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?
RESOLUTION: New WD of motion
<astearns> [css-flexbox] [css-text] Alias "nowrap" as "no-wrap"
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/1537
drat, call dropped
<astearns> all dropped
<nainar> Call dropped
<TabAtkins> oh, cool
<jensimmons> yup
<astearns> 10 people still on
<astearns> 10 people gone
<jensimmons> back
<nainar> im in
<nainar> Github issue: https://github.com/w3c/csswg-drafts/issues/1537
astearns: Last time we discussed,
had 3 alternatives
... 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
... 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
... Alias has a cost, not sure that the benefit is more.
TabAtkins: I mistype this all the
time, and I can't be the only person who does it. It's bad
keyword.
... We should have done it right the first time.
<dbaron> This is CSS1: https://www.w3.org/TR/REC-CSS1/#white-space
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 htat way
astearns: Difference is in CSSOM?
TabAtkins: yeah
... CSSOM will always return nowrap
... Benefit is that older tools will continue to work
... downside is authors might be confused
... Full alias does incur more cost on engine
... parse-time is trivial
Florian: Not a strongly held
belief, but I think 2 is in-between, not really worth it
... Doesn't really give a transition path to a better
world
... 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
... If we go with option 2, then ppl who use dash need to know
that OM doesn't use dash
... 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
... 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
... If we switch to option 3, 30 years from now everyone can
forget this ever happened. No one will use nowrap.
... I'm into 3
TabAtkins: I'm 100% sure
minifiers will remove the dash
... 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.
... I don't have an opinion on 2 vs 3
... 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?
smfr: I would vote for no change
<gsnedders> I agree with TabAtkins.
<smfr> it was me
myles: Me too
<Florian> Favors 3, not as strongly as Tab.
<smfr> basically #apple
<nainar> I'm with Tab on this one. (3 > 2)
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.
<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.
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.
... But pretty hesitant to agree to do it now
gregwhitworth: I'm with dbaron,
no strong opinion. Do know that authors run into it, e.g.
postCSS plugin to fix this
... 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.
... 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 hte others.
RESOLUTION: No change for issue about adding no-wrap
<RachelNabors> I'm here. But waiting on more feedback from the community.
<astearns> 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
... we do a clamping at some point if it needs to clamp to a
particular range
... 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
... for properties that clamp at computed value time
... can clamp through at computed value time
... For properties that clamp at used value time, some things
can clamp at computed value time
... So do those properties clamp both at used and computed
value time, or just at used value time?
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
<birtles> I think we want to clamp as late as possible -- since animation operates on computed values (more or less)
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
... 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
... So I prefer clamp at all times behavior
dbaron: I was going to say I
prefer the other one
... birtles said same thing on IRC, but was thinking about
animations
... I was thinking essentially of things like width: calc(-5px)
vs width: (0%-5px) 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
Florian: If we go that way, pretty important to go the way Tab says for 0%, otherwise discontinuity between 0% and 0.00001%
<birtles> specifically my concern is you want to interpolate using the unclamped values and then clamp
TabAtkins: Don't understand
animations issue
... font-size resolves everything at computed time
already
... So animations should see value of 0 for 0px, don't see why
width should be different
dbaron: You can have a calc()
that's a result of interpolation
... 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
... bouncing ...
... 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)
Florian: None of these allow us to have results earlier, to get fully resolved value at computed value time ..?
<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
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
... 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
... observable in animations as well as OM
... 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
... 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
... wait, this is inconsistent
<TabAtkins> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5257
Myles: : Does the other behavior. never sticks at zero.
TabAtkins: Sounds like no interop
<RachelNabors> BAHAHAHAHA... Tab.
<myles> s/?: Does/Myles: Safari does/
astearns: Think we should kick
this back to github for testing, come back with animation
data
... Anything else to bring up on this topic?
<astearns> github topic: [css-syntax] Trim whitespace around declarations?
<astearns> github topic: https://github.com/w3c/csswg-drafts/issues/774
TabAtkins: This has impact on
what custom property values are
... Because custom properties capture tokens
... Currently the white space before first value token is
preserved
... All of the normal properties serialize out from OM, so they
get normalized white space output
... Some people brought up maybe we should trim the white space
from beginning and end of a token stream
... This would be a tweak to the Syntax spec
... to throw away this white space
... No consequence for ordinary CSS, they will continue to
parse and serialize as usual
... 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
... 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...
... If you're embedding another programming language into CSS
you'll have consequences anyway
... Don't think any other issue
leaverou: So benefit to it, and
not hurting any use case. So I'm hugely in favor.
... Every time I use OM for custom properties, have to use
trim(), it's really annoying.
<ChrisL> +1 to trimming
astearns: Proposal to trim whitespace on either side of all declarations. In favor / opposed?
RESOLUTION: trim white space before / after property value in a declaration.
<gregwhitworth> TabAtkins: can you submit a test for this when you make the change?
<astearns> 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
... better to point to more up-to-date specs
... 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> https://github.com/w3c/csswg-drafts/issues/1397#issuecomment-311471628
TabAtkins: Because it's a wide-ranging change, wanted to get WG approval before making part of spec boilerplate
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?
... Like MQ or Selectors?
TabAtkins: Those either don't
have values section or it worked.
... 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
... 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.
... 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 becaus that
wasn't a thing
... 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 propagae those or discuss further in GitHub
astearns: Proposed to accept this improvement, raise GitHub issues for further improvement
RESOLUTION: New Values boilerplate accepted
<astearns> 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
... Doesn't allow a lot of use cases, but it's simple case and
improves debugging / preview
... Can quickly see the gradient
... Use case of single color image isn't great, because we have
image() function for that
... I'm fine either way
... But would allow it if it was up to me
... 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 somehting,
even though it currently does not, there's a non-trivial risk
of web pages out there relying on it not working
... Maybe not, but could be a case
leaverou: Could we get stats?
ChrisL: People wanted to do solid
colors and animate ...
... 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
... Maybe solicit feedback directly from implementers, if
anyone wants to champion then add back to agenda
... If not, shouldn't go in spec
... Thanks everyone, we're done.
Meeting closed.
<astearns> trackbot, end meeting
This is scribe.perl Revision: 1.152 of Date: 2017/02/06 11:04:15 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00) Succeeded: s/nainar?/nainar/ Succeeded: s/this decision is insans/the correct choice is no change/ Succeeded: s/vs width: (0-5px) // Succeeded: s/?/Myles:/ FAILED: s/?: Does/Myles: Safari does/ Succeeded: s/???/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/ Succeeded: s/.../ is easily written/ Default Present: Rossen_, dael, dauwhe, tgraham, bdc, rachelandrew, astearns, birtles, myles, TabAtkins, fantasai, antenna, gregwhitworth, leaverou, bkardell_, tantek, dbaron, AmeliaBR, plinss, bradk, RachelNabors, melanierichards, ChrisL___really, Florian, ChrisL, nainar, alex_antennahouse, jensimmons, hober, smfr, gsnedders Present: Rossen_ dael dauwhe tgraham bdc rachelandrew astearns birtles myles TabAtkins fantasai antenna gregwhitworth leaverou bkardell_ tantek dbaron AmeliaBR plinss bradk RachelNabors melanierichards ChrisL___really Florian ChrisL nainar alex_antennahouse jensimmons hober smfr gsnedders Regrets: tantek Found ScribeNick: dael Found ScribeNick: fantasai Inferring Scribes: dael, fantasai Scribes: dael, fantasai ScribeNicks: dael, fantasai WARNING: No meeting chair found! You should specify the meeting chair like this: <dbooth> Chair: dbooth Found Date: 05 Jul 2017 Guessing minutes URL: http://www.w3.org/2017/07/05-css-minutes.html People with action items: WARNING: Input appears to use implicit continuation lines. You may need the "-implicitContinuations" option.[End of scribe.perl diagnostic output]