W3C home > Mailing lists > Public > www-style@w3.org > July 2013

[CSSWG] Minutes Telecon 2013-07-24

From: fantasai <fantasai.lists@inkedblade.net>
Date: Wed, 24 Jul 2013 15:19:00 -0700
Message-ID: <51F052D4.5060209@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
Summary:

   - Discussed botched LC publication of Variables, plan to republish
     soon, probably with additional issues resolved.
   - Discussed use of 'var' as shorthand to reset all custom properties.
   - Discussed plan for updating CSS2.1. Basically, need
       * reviews of errata, to make sure they're correct
       * testcases for each erratum
       * implementation report proving we have impl passes for each erratum
   - RESOLVED: Republish CSS3 Values and Units as CR to update for minor fixes
   - RESOLVED: Drop 'default', introduce 'unset' as "initial-or-inherit"
   - RESOLVED: 'all' shorthand does not reset 'direction', 'unicode-bidi',
               or 'var-*'.
   - Reviewed open Flexbox issues
       http://dev.w3.org/csswg/css-flexbox/issues-cr-2012
   - Hoping to close off last two issues in CSS3 Text (text-align-last
     shorthanding, letter-spacing + justification) next week if possible.

====== Full minutes below ======

Present:
   Glenn Adams
   Rossen Atanassov (late)
   Tab Atkins (late)
   Shezan Baig
   David Baron (left early)
   Bert Bos
   Elika Etemad
   Simon Fraser
   Sylvain Galineau
   Daniel Glazman
   Rebecca Hauck
   John Jansen
   Dael Jackson
   Brian Kardell
   Brad Kemper
   Philippe Le Hégaret
   Chris Lilley
   Peter Linss
   Chris Palmer
   Anton Prowse
   Matt Rakow
   Florian Rivoal
   Simon Sapin
   Dirk Schulze
   Nick Van den Bleeken (late)
   Lea Verou
   Steve Zilles

<RRSAgent> logging to http://www.w3.org/2013/07/24-css-irc
Agenda: http://lists.w3.org/Archives/Public/www-style/2013Jul/0518.html
Scribe: fantasai

CSS Variables
-------------

   glazou: Where are we wrt variables?
   fantasai: LC wasn't published
   florian: It sort-of was. if you add -1 to the end of the url, it's
            published there
   fantasai: Was an announcement posted to www-style?
   <glazou> http://www.w3.org/TR/css-variables-1/
   <florian> not LC: http://www.w3.org/TR/css-variables/
   <florian> LC: http://www.w3.org/TR/css-variables-1/
   fantasai: If it wasn't announced and didn't show up at the old URL,
             I don't think we can consider it published.
   glazou: Was it announced to chairs@?
   plh would have to look into it
   <SimonSapin> http://lists.w3.org/Archives/Public/www-style/2013Mar/0701.html
   fantasai: I would be uncomfortable closing the LC period if no announcement
             was posted in CSSWG channels
   fantasai: and it didn't even show up to replace the old draft
   florian: There's also 3 open issues in the ED
   glazou: Not announced on www-style. This is painful
   plh: My bad
   fantasai: No, it's the editor's responsibility to announce the draft
   dbaron: But nobody tells the editor that the draft has been published

   plh: I would concur with fantasai. If it wasn't announced, redo LC period
   florian: Need to get the links in synch
   ACTION plh: have /TR/css-variables/ alias to /TR/css-variables-1/
   <trackbot> Created ACTION-569
   chrisL: I would just extend the deadline
   fantasai: There were also some significant changes we wanted to make,
             so maybe we should make those changes and republish LC
   ...
   fantasai: There's an issue for example on interaction with the 'all'
             property, and we decided it doesn't reset variables, but
             an 'var' shorthand will reset all variables, so that needs
             to be added to the draft.
   chrisL: Doesn't sound like too much work, could publish on Tues probably
   dbaron: What values does 'var' take?
   SimonSapin: Same as 'all'?
   fantasai: I think Tab proposed <'all'>
   dbaron: Initial/inherit, do they have special behavior in variables then?
   * fantasai doesn't know
   glazou: This seems really hacky.
   <SimonSapin> Does <'all'> makes Variables refer normatively to Cascade?
   <fantasai> yes
   dbaron: If 'initial', 'inherit', and 'default' aren't interpreted,
           then it's special?
   TabAtkins: Yeah, well, we haven't decided on that anyway
   ...
   TabAtkins: The 'var' property isn't a custom property, it's a CSS thing.
              Assuming that we need that.
   glazou: Thought we were going to LC
   glazou:  ...
   glazou: I would like the use case for this
   TabAtkins: Want to block variables inheriting into your little subtree
   <dbaron> I'm inclined to think a 'var' shorthand should take only 'initial'.
   <glazou> dbaron, +1

   florian: So, either we decide this is minor enough to handle as an LC comment
   florian: Or we take advantage of having screwed up LC, make the change,
            and then publish LC
   fantasai: If we want to make this change, would suggest we resolve this
             and republish LC. It's a fairly significant change.

   [argument over publication process]
   <Zakim> -dbaron
   <dbaron> I've had enough of the chair yelling at the WG.

   glazou: Let's prep the document for a new publication.
   glazou: Enough on this topic for today
   * plh doesn't understand why we're pushing a doc to LC that still have
         uncertainties around
   <glazou> plh, +1

Conditional Rules
-----------------

   glazou: dbaron lost, because can't stand ppl being unhappy. Next topic

CSS2.1
------

   Bert: What do we want to do, before republishing 2.1
   Bert: Thought the errata were up-to-date, but some weeks of minutes
         I haven't checked yet.
   Bert: Then there's all the issues in Bugzilla. How many do we want to
         solve? Do we want to set a deadline for solving them?
   Bert: How much effort do we want for those issues
   Bert: Also about testing
   Bert: The changes we made, I've seen 1-2 that have testcases
   Bert: Don't know if others do. Doubt it.
   Bert: We need to make sure the changes we make are supported by testcases
   Bert: Someone needs to do that
   Bert: and also need implementations for those testcases
   Bert: Any idea of how much effort we need, when we could finish,
         schedule updated publication?

   fantasai: Maybe make a schedule where we deal with 1 issue per
             [time period, e.g. week or fortnight]
   fantasai: Wrt testcases, dunno, ask rhauck?

   florian: What about publication? How often do we want to publish?
   fantasai: Need to have tests + impl reports for PER publication
   florian: But how many issues do we want to solve before publishing?
   antonp: Depends on how WG perceives last publish date.
   antonp: If you want to send signal that it's improving, republish
           every 6 months
   antonp^: Not sure makes sense to republish with only 1 erratum, though
   antonp: Sorry for being out of action on this
   <Ms2ger> Six months is ~25 telcons, so if you decide on one issue
            every telcon...

   fantasai: I think the main thing is to make sure the existing errata
             are correct, have testcases, impl report
   fantasai: Once we're there, can publish any time we want
   fantasai: Some of them, might be waiting on implementations to catch up,
             so would incorporate more issue updates while we wait for that
             before publishing. That might set the rhythm.

   JohnJansen: There's also testcases added to the test suite since we
               publish REC. Would need to make sure we have impl passes
               for all of those as well
   florian: Is there a rule for handling such things?
   JohnJansen: Raises question of what REC means if we publish a new testsuite
   florian: It wouldn't make sense to me to block republication of REC on that.
            It's not like we regressed

   Bert: Most concrete thing I heard was to go over the errata that we
         decided on, make sure correct and have tests.
   Bert: Maybe we can assign action items for that?
   Bert: Since I made the errata, I should not check them :)
   Bert: Errata have links to minutes, so should be easy
   florian: Not a lot of work, but can be pretty subtle
   florian: Sometimes wording in errata slightly off from decisions in a
            way that creates a problem
   antonp: Yeah, we have an existing case of that
   ACTION fantasai: Review CSS2.1 errata
   <trackbot> Created ACTION-570
   ACTION antonp: Review CSS2.1 errata

   fantasai: Rebecca, can you and gtalbot look into tests?
   ACTION rhauck: Look into tests for CSS2.1 errata
   <trackbot> Created ACTION-571

dirk's topic deferred to next week

Republishing Values
-------------------

   <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2013JulSep/0051.html
   TabAtkins: Handful of changes, very minor, not worth LC, but good to correct on /TR
   TabAtkins: Changes in changes section of spec
   glazou: What do ppl think?
   SimonSapin: Yes, let's republish
   RESOLVED: Republish Values as CR

Cascade
-------
Scribe: TabAtkins

   http://lists.w3.org/Archives/Public/www-style/2013Jul/0478.html
   fantasai: Two issues that needed final resolution.
   fantasai: First was dropping "default".  Second was adding "unset" for
             "initial or inherit".
   fantasai: Any comments?  Do we want to accept the changes?
   <SimonSapin> sounds good
   <florian> given my understanding, I am fine with it.
   RESOLVED: Accept the default/unset changes.

   <fantasai> next issue -> http://lists.w3.org/Archives/Public/www-style/2013Jul/0508.html
   fantasai: Next issue is somewhat tricky.
   fantasai: The problem with 'all' is that it kills *everything*.
   fantasai: We were like, are there certain rules we really don't want
             people to reset without having explicitly decided to do so?
   fantasai: We went through Firefox's UA stylesheet.
   fantasai: Resetting most things are fine.
   fantasai: But there are two properties which we realized nobody should
             be touching unless they're explicitly going against our
             recommendation not to touch it, for some reason.
   fantasai: Those two are 'direction' and 'unicode-bidi'.
   <ChrisL> almost-all ?
   fantasai: Right now, 'all' will reset those.
   fantasai: Which might be okay on an LTR page, but on RTL it'll break
             things by resetting explicit values.

   ChrisL: Are 'direction' and 'unicode-bidi' the only properties we'll
           do this with?  Should those not have been properties at all?
   fantasai: Yes, those two should not have ever been CSS properties.
   fantasai: They were added because people thought that was the right way
             to handle non-HTML bidi requirements.
   fantasai: Personally I think it would have been smarter to add an xml:dir
             attribute, but we have 'direction' now.
   fantasai: CSS2.1 and CSS3 both say "don't use these properties, use the
             markup instead".

   fantasai: It's *possible* we might add new things, but unlikely.
   antonp: I don't like a property called 'all' that's not actually all.
   [something about other proposed properties to add]
   fantasai: Yeah, that's why I'm less certain we should tie it to other
             cases.
   antonp: The reason the bidi ones are being excluded is because they
           shouldn't have been properties in the first place, but I don't
           think that set should grow.
   * antonp is fine with 'all' that excludes these mistake-properties,
            but doesn't like 'all' that does more

   SteveZ: One thing you said is that direction isn't really part of styling,
           but rather a content quality.
   SteveZ: Perhaps that should be indicated as the reason for the exclusion
           in the spec.
   fantasai: That's already in the spec. ^_^
   http://dev.w3.org/csswg/css-cascade/#all-shorthand

   Bert: Aren't the custom properties also an exception to the 'all' rule?
   fantasai: Yes, because they're not CSS properties.
   TabAtkins: Yeah, Variables already has an issue for this.

   SimonSapin: David Baron just sent an email to the list with roughly the
               same consensus (not liking exceptions, but maybe being okay
               with the two properties).
   TabAtkins: I'm okay with just limiting it to the two properties, and
              not doing [lang] stuff.
   [jokey discussion about changing it to 'most']
   RESOLVED: 'all' does not reset 'direction' or 'unicode-bidi' (or custom
             properties)
   * florian thinks "all" is short enough to not specify all the *what*,
             so I'll just interpret it as meaning "all the properties that
             are reasonable to reset"

   <BradK> Can I set 'all:red' and have it affect everything that takes a
           color as a value?
   <SimonSapin> not per the current spec
   <BradK> Maybe it should. Do you know if this has been discussed on the list?
   <SimonSapin> I think it hasn’t been discussed, but I don’t like it :)
   <BradK> Yeah, there's probably no real value in doing that. Never mind.

Flexbox LC
----------

   http://dev.w3.org/csswg/css-flexbox/issues-cr-2012
   fantasai: There's the DoC, and there's a handful of open issues we're
             still trying to resolve.
   fantasai: People who are interested in flexbox should probably hang out
             in the list and help us out.
   fantasai: I'll summarize the issues...

   http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-3
   fantasai: Issue #3 - why doesn't height:100% on the child of a stretched
             flex item take effect?
   fantasai: We thought there wasn't a good reason that it doesn't work
             for a single-line flexbox with a definite size.
   fantasai: Relatedly, I think MS will honor %ages even if the flexbox
             isn't a definite size - one pass treating the percentages as
             auto, resolve the size of the flexbox, then do another layout
             pass with that as the definite size.

   http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-19
   fantasai: Issue 19 is about the implied minimum size of flex items.
             We resolved to revert it to zero, but there's a thread about
             that maybe not being a good idea.  There's an ongoing discussion.

   http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-21
   fantasai: Finally, if you have two flexbox children that are table-cell,
             should they be converted directly to block (and be independent
             flex items), or first wrapped in an anonymous table and then
             made into a flex item?
   fantasai: There is different impl behavior between FF and webkit/blink,
             at least.

   http://dev.w3.org/csswg/css-flexbox/issues-cr-2012#issue-22
   fantasai: Last is about the static position of flex and grid items.
             We can probably leave that open during the LC, as it doesn't
             necessarily imply a change to Flexbox.

   fantasai: That's an overview of the issues, so it would be good to get
             the opinions of interested people.

   SteveZ: Can you provide pro/cons for the table-cell case?
   fantasai: Right now, if you ever have two adjacent table-cells,
             we'll wrap them in a table.
   fantasai: Flexbox says the same thing at the moment.
   fantasai: If you have a few table-cells mixed with other boxes,
             and you're expecting the anonymous box behavior, that's what
             you want.
   fantasai: On the other hand, you might want to be using table layout
             as a fallback for flexbox, in which case you want the cells
             to be independent.
   TabAtkins: Another arg in favor of anon-box behavior is that for other
              box model things, like run-in and ruby, we will want to do
             box-fixup first.
   fantasai: I totally agree with TabAtkins on run-in and ruby and other
             things
   fantasai: Just for tables, seems like we have good use case for recomputing
             'display' instead, and since anon table box generation is somewhat
             complicated, less likely to be used.
   TabAtkins: I've relied on it in the past. :/

   SteveZ: Is there a way of getting the non-fixup behavior by some other means?
   TabAtkins: You can set display:table instead, if you want.
   Rossen: There's also an expectation of what the fixup is going to be.
   Rossen: In flow layout, if you have two adjacent table-cells, you'll
           get a single wrapper around them.
   Rossen: I think we should make a deliberate decision over whether to
           have same behavior in both layout systems or not.
   Rossen: I'm not saying there's a ton of interop in block layout, but at
           least in these simple cases, there's interop.

   [discusses how to detect the behavior, so we know IE's treatment]
   <fantasai> 
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20flex%3B%20flex-flow%3A%20column%22%3E%0Atest%0A%3Cdiv%20style%3D%22display%3A%20table-cell%22%3EA%3C%2Fdiv%3E%0A%3Cdiv%20style%3D%22display%3A%20table-cell%22%3EB%3C%2Fdiv%3E%0Atest%0A%3C%2Fdiv%3E
   fantasai: In the above, if A and B are next to each other, you do table
             fixup (they're in a single table). If they're vertical, you
             don't do fixup (they're separate flex items).
   Rossen: IE does the fixup.
   fantasai: Mozilla too.
   TabAtkins: Chrome does not.
   fantasai: So unless anyone else has comments, maybe we just stay with
             what we have, and do the fixup?
   SteveZ: Can we delay the decision a week?
   fantasai: Sure.

CSS3 Text
---------

   fantasai: One more thing for next week - I'd like to have Steve and Alan
             and Jdaggett to help solve the last two issues with CSS3 Text:
             text-align shorthanding and letter-spacing. AFAIK, these are
             the last ones holding up LC.
   SteveZ: Do you have suggested text for the letter-spacing justification?
   fantasai: No, but I can write some up.
Received on Wednesday, 24 July 2013 22:19:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 24 July 2013 22:19:33 UTC