Cascading Style Sheets (CSS) Working Group Teleconference -- 05 Jul 2017

<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

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.
... 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

nowrap vs no-wrap

<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.

[css-timing] reconsider name of frames() timing function

RESOLUTION: No change for issue about adding no-wrap

<RachelNabors> I'm here. But waiting on more feedback from the community.

[css-values] Computed value of a negative calc unit that doesn't allow negative lengths.

<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?

[css-syntax] Trim whitespace around declarations?

<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.

[css-align] Values section shouldn't point wholesale to CSS Level 2

<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

[css-images-4] Gradients with a single color stop

<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.

end

<astearns> trackbot, end meeting

- DRAFT -

Cascading Style Sheets (CSS) Working Group Teleconference

05 Jul 2017

Attendees

Contents