W3C home > Mailing lists > Public > www-style@w3.org > March 2015

[CSSWG] Minutes Telecon 2015-03-04

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 4 Mar 2015 20:41:02 -0500
Message-ID: <CADhPm3v4G_o+ZQexB5UZ+Msm3A6c4_1ARbX9NdfAj-ac4o0aOg@mail.gmail.com>
To: www-style@w3.org
CSS Grid Publication

  - RESOLVED: Publish a new working draft of CSS Grid.

Animations Editorship

  - RESOLVED: TabAtkins and dbaron are co-editors for Animations.

Abspos Change Compat Risk

  - RESOLVED: Do not change the current spec for now knowing the
              compat risk with the change in abspos handling.


  - RESOLVED: Publish a new WD for CSS3 UI.
  - Everyone, especially implementors, were actioned to review
      Florian's proposal (available here:
      for a more precise description of how box-sizing works. There
      will be three weeks to review the proposal before the issue is

Reverting vertical % padding/margin to match block

  - The argument for reverting was for consistency in the odd things
      about CSS so people only have to learn a weird rule, not a
      weird rule and its exceptions.
  - The argument against reverting was to allow grid and flexbox to
      work in a way that was more intuitive to app developers that
      are relying on these tools.
  - A compromise was raised to create a switch, such as creating ph
      and pw, so that authors can choose their behavior of choice
      instead of forcing one group or the other to think outside
      their desired approach. This idea met with favor.
  - The implementors will hold a conversation to find out more about
      who is willing to implement what while discussion continues on
      the mailing list to further flesh out people's opinions and

Behavior of Selectors not in Fast Profile

  - RESOLVED: We keep selectors not in the fast profile and not
              implemented as invalid and we clarify it in the spec.


  Rosssen Atanassov
  David Baron
  Sanja Bonic
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Dave Cramer
  Alex Critchfield
  Elika Etemad
  Simon Fraser
  Daniel Glazman
  Tony Graham
  Koji Ishii
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Chris Lilley
  Peter Linss
  Mike Miller
  Edward O'Connor
  Anton Prowse
  Florian Rivoal
  Andrey Rybka
  Simon Sapin
  Alan Stearns
  Lea Verou
  Steve Zilles

  Tab Atkins
  Bo Campbell
  Sylvain Galineau
  Simon Pieters
  Greg Whitworth

  Scribe: dael

  glazou: I suppose we have to start
  glazou: Any additions?
  Florian: Tantek and I just just mentioned two. One is a new WD for
           CSS3 UI, another is a request to review an e-mail.
  glazou: We can do the first first, the second after item 3.
  Florian: We should wait for tantek to be on the call for both. I
           think he'll join soonish.
  glazou: Okay. Anything else?

CSS Grid Publication

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0162.html
  <astearns> (the member-only link above mainly just links to
             and http://dev.w3.org/csswg/css-grid/#changes )
  fantasai: TabAtkins and I put in pretty much everything we
            resolved on, so we thought we should publish a new WD to
            get it up to date. The current draft is up to date with
            the issues filed to mid-January.
  fantasai: It's a major improvement, so I think the TR should get
            up to date. Most of the other comments since our update
            were editorial.
  glazou: I'm in favor. Thank you for maintaining an up to date list
          of changes.
  Rossen: Sure.
  <SimonSapin> +1
  <Florian> +1
  glazou: Other comments?

  RESOLVED: Publish a new working draft of CSS Grid.

  glazou: fantasai you'll deal with it?
  glazou: The publication stuff?
  fantasai: I don't know when/how with the new system.
  glazou: ping Bert.
  * Bert hasn't done the new system yet either, but we'll find out
         how it works :-)
  <tantek> Bert new system requires hotpatching after bikeshed.
  glazou: Is tantek on yet?
  * tantek is running bikeshed

Animations Editorship

  <glazou> https://lists.w3.org/Archives/Member/w3c-css-wg/2015JanMar/0165.html
  glazou: This is a request from sylvaing saying we should have
          another editor for the spec.
  Florian: And the other should be TabAtkins?
  glazou: That TabAtkins would be put on and dbaron would help.
  glazou: I guess TabAtkins is okay with it. dbaron?
  dbaron: It's fine with me.
  Rossen: What was the motivation for this?
  glazou: I have no idea.
  dbaron: I think sylvaing doesn't have time to work on it.
  Rossen: So he wants help and is looking for someone to take over.

  glazou: One question. dbaron you're available to help? As
  dbaron: I'm already co-editor. I've been focusing on other things.
  glazou: So any objections?

  RESOLVED: TabAtkins and dbaron are co-editors for Animations

  glazou: Still no tantek?

Abspos Change Compat Risk

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Feb/0411.html
  glazou: We wanted to revisit this after a week, but gregwhitworth
          isn't on. Rossen, can you speak on this?
  Rossen: I'm here, but I don't think this was an ask for us.
  glazou: Okay.
  fantasai: I think this was an "FYI there could be problems". No
            one has yet said there is a problem significant enough
            to revert.

  Rossen: If this is rehashing...We're fine with the change and
          agree this is the way to go about it. We did see some
          compat issues. We raised awareness with the group.
          TabAtkins said they were aware and fine with it. We wanted
          to circle back to the group and make sure everyone is
          fully aware of the compat risk.
  Rossen: I don't think there's anyone waiting on us. I think it was
          more raising awareness.
  Rossen: If we have no problems, let's resolve and continue on.
  glazou: There's apparently no comments.
  Rossen: So can we resolve to not change the current spec knowing
          the compat risk?
  * dbaron tries to figure out what this change is
  <fantasai> dbaron, it's the change from "abspos static position is
             where the placeholder would be if it were a zero-sized
             flex item" to "static position is as if the abspos were
             the only item in the box"

  glazou: Objections?
  glazou: dbaron has a question.
  dbaron: Not really.
  glazou: So no objections?
  fantasai: It's not an issue, just a warning

  RESOLVED: Do not change the current spec for now knowing the
            compat risk.

  glazou: tantek you're here?
  <tantek> glazou - have had trouble with my comms - trying dialing.

Behavior of MouseEvent.offsetX/Y

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Feb/0506.html
  glazou: This was raised by Robert O'Callahan. It was under
          specified. There was a short discussion on the mailing
          list, but didn't seem to resolve. I thought we would have
          to discuss.
  glazou: Unfortunately, zcorpan sent regrets.
  glazou: Is this something to discuss now? Do we wait to have
          zcorpan? Have some time to review? Whatever?
  glazou: No reactions?
  Rossen: Let's do it next week.
  glazou: Let's defer.

CSS3 UI Publication

  glazou: tantek are you connected?
  tantek: Let's see. Can you hear me?

  tantek: I've done all the edits for open issues except the
          remaining big issue where Florian has done a lot of work.
          I think we should publish as is and then take the time to
          review issue 69 because those issues effect some
          fundamental things and it's important to get correct.
  glazou: The last WD is one week old, right?
  tantek: It'll take a week to publish because we've had problems
          with new system.
  Florian: Last WD is a week old, but we've been trying to get that
           out for a month so there's lots of changes.
  tantek: Almost 2 months.
  Florian: There are a bunch of differences and the new one is

  fantasai: I'm in favor of publishing often. No problem with
            publishing another draft.
  glazou: Other comments?
  <astearns> +1 to publishing more often
  <SimonSapin> publish early, publish often
  glazou: No objections?

  RESOLVED: Publish a new WD for CSS3 UI

  <Florian> https://lists.w3.org/Archives/Public/www-style/2015Feb/0445.html
  tantek: The issue is the box-sizing fixes. This is a thing that
          took a lot of time during FX portion of the F2F. This
          deserves a lot of review for anyone involved in layout.
          Florian has done a lot of work, so please look at his
          proposal. We're touching a lot of stuff that's hard to
          touch without breaking.
  Florian: The spec changes are about disambiguating what height
           refers to when it's something else than content box. I
           believe there isn't anything particularly hard, but
           they're tedious and if something is wrong it'll be bad. I
           made a bunch of tests and they conform to what I expect
           in most browsers, but there appears to be a few bugs.
  Florian: Review would be very appreciated. The prose is dry, but I
           was aiming for correct.
  * dbaron also submitted some new css 2.1 tests to cover the
           Firefox min-width/height bug that we were discussing
  <dbaron> (which is now fixed in nightly)
  <dbaron> https://hg.csswg.org/test/file/eeefc17e6d6c/vendor-imports/mozilla/mozilla-central-reftests/css21/replaced-sizing/

  Rossen: Where are the test cases?
  Florian: I just pasted in IRC the e-mail with the tests.

  glazou: How much time do people need for review?
  tantek: Longer than a week. We have box-sizing where there was
          interop problems with previous versions. I would suggest 3
  Rossen: I'd second. Box-sizing is widely used.
  tantek: I'm okay with longer. 3 week minimum.
  Florian: I'm not suggesting drastic changes. It's mostly
           clarification. For example, the things in the F2F where
           one browser seems to be buggy and there was no test to
           clarify, I'm clarifying. This isn't breaking existing
  Rossen: So drastic or not, little changes can take down a product.
          It's about how widely a feature is used. I'm agreeing with
          tantek this should be taken seriously. It's in many, many
  Florian: I agree with that.

  glazou: Rossen, you're OK with 3 weeks?
  ACTION everyone to review this for three week timeline

  tantek: I'd like to explicitly hear from the implementors with a
          thumbs up or down.
  tantek: We'll be reviewing at Mozilla as well.
  Rossen: I was going to ask if you have reviewed, but it sounds
          like you haven't.
  tantek: I need to review with other engineers, especially Boris.
          I'm optimistic, but I want to make an explicit call for
  Florian: Yeah. We don't want to get this wrong.
  glazou: So we'll revisit in 3 weeks.

Reverting vertical % padding/margin to match block

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Feb/0521.html
  glazou: Next item is from TabAtkins but he's not here.
  fantasai: I can take it. We changed to have % reference the height
            instead of width, in block layout we did in both
            directions. This gets you equal padding.
  fantasai: For things like flexbox and grid we went with you get %
            in dimension you referred to. This change to flexbox
            from initial CR we did because we realized Microsoft had
            this with grid.
  fantasai: We wanted to make grid and flexbox consistent so we
            decided to backport the behavior. It's more intuitive
            for app layouts where you have a fixed height. For
            document mode you usually have auto height and the %
            resolved to 0.
  fantasai: Microsoft and Firefox have implemented this behavior.
            Chrome hasn't. Chrome developers have said it's a
            performance concern because they have to do a virtual
            function call every time. They don't think it's
            important and authors prefer our behavior. That's where
            we're at.

  fantasai: dholbert found some bugs recorded against FF and these
            are mainly for cases where there is an auto height. So
            we have to talk to the Chrome dev to find the exact
            holdup. For the authors having these % go to 0 with auto
            height isn't useful.
  fantasai: We were thinking of changing auto referencing behavior
            to refer to containing block. That's for us to think
            about. The editors for Microsoft and Blink and Webkit
            will need to talk about Blink architecture.
  fantasai: We'll talk to implementors. For the WG to discuss, what
            are our thoughts to defining as it's relative to the
            height if the height is definite. Relative to the width
            if it's not?

  Rossen: I'll repeat myself. How we arrived where we are with grid.
          I agree with what you said, but it puts bias toward the
          document flow behavior which is resolve % out of
          containing space on width.
  Rossen: How we arrived there for grid was driven by that grid and
          flex are layout for apps more than anything. Traditional
          app dev coming from other platforms are expecting symmetry
          in their layout for properties that are constraining and
          handling horizontal properties and the same for vertical.
  Rossen: When grid came along that was the feedback. People were
          surprised that padding/margin was resolving from width.
          There was strong pushback. That's how grid came about.
  Rossen: The same thing will be true for any implementor, anyone
          that comes with implementation experience starting from
          grid will be on the same page as us since having symmetry
          with grid is a lot more useful than flex.
  Rossen: My fear is even if we added some relaxation in flex spec
          we'll be having the discussion in another year when
          everyone is working on grid.
  Rossen: That's what I wanted to say before we decide.

  fantasai: We have 3 options.
  <fantasai> A) Keep vertical percentages against height
  <fantasai> B) Revert vertical percentages to be against width
  <fantasai> C) Keep vertical percentages against height, except
             when it's auto, make it against width
  <astearns> is anyone asking for C?
  <dholbert> astearns, we have objections to A and B; C is a
  * fantasai is suggesting it as a way of getting useful behavior
             for auto-height cases
  * fantasai currently they fold to zero
  hober: Given those 3 options, I prefer B to have it against width.
         This is a weird thing about CSS, but consistent weird you
         only learn once.
  hober: If we make it different in flexbox the weird is weirder. C
         is the worst because you can't predict when the weird
  hober: I think the status quo is weird, but it's simple and weird.
  Rossen: When you're in the prospective of app layout it doesn't
          make sense. It's the exact other way around from document
          developers. We're pushing web to be app as well as
          document, so stepping backwards and pretending everything
          is a doc is a step in the wrong direction.
  Rossen: I sympathize, but I think this is the wrong way going
  <dbaron> I agree that (C) is probably too weird

  Rossen: There's an option D which will be potentially something to
          explore. It would be some kind of box sizing that would
          control how margins are resolved inside a container. For
          impl that would be more work.
  Rossen: It would be something we can make everyone happy with and
          also give doc dev to use doc layout and app dev to make
          app layout.
  Rossen: I wouldn't be excited about it, but I would lean there.
  fantasai: I would do it with new units: pw + ph.
  <dbaron> we could have pw for percentage-of-the-width, ph for
           percentage-of-the-height, and px for percentage-of-the-
           same-axis :-P
  <dholbert> so the point of adding a switch would be to enable us
             to do "A" (making vertical % resolve against vertical
             size), while still allowing authors to ask for the
             other behavior (e.g. for aspect-ratio hacks), yes?
  Rossen: Either way...having the switch somehow, somewhere. The
          switch is better because you want the units to be the same.
          Dialing down to the unit means you're statically assuming
          where the content would fall and if this is a component
          model you can control from the root level.

  hober: I don't think I buy the distinction between the two types
         of authors and we'd do a disservice by making it harder to
  dbaron: I think I do buy the distinction. doc layout systems are
          set up differently: they assume width as an input and
          height as an output.
  hober: I don't hate the ph and pw unit to distinguish.
  hober: I thought that was a good idea, fantasai.
  Rossen: This comes down to, the way the Blink team came to the
          issue, they were firm in saying they won't implement. You
          guys ship, there will be two implementations conforming so
          you can get to REC, but Blink won't implement. ph and pw
          would also be moot if blink will take that tone.
  <dbaron> It's not clear to me that their objection applies to ph
           and pw, since the issue sounded like it was related to
           *switching* behavior
  <dholbert> dbaron, (I think part of their objection is that
             "authors want the old behavior at least as much as they
             want the new behavior". pw/ph (or equivalent) would let
             them switch to the new behavior, while still letting
             authors ask for the old behavior)

  Rossen: I propose we wrap now and talk with TabAtkins or we wait
          until impl get together and discuss why this is difficult
          for Blink and then we review.
  glazou: I suggest both. We revisit with TabAtkins and we rely on
          the mailing list to have implementors discuss.
  Rossen: And I believe there will be a one-off call between
          implementors too.

  glazou: I think we have to defer item #6.

Behavior of Selectors not in Fast Profile

  <glazou> https://lists.w3.org/Archives/Public/www-style/2015Mar/0015.html
  glazou: This popped up several times and we need to fix or clarify.

  bkardell: I think this is the first time we have something that
            could not parse and still be valid?
  dbaron: I would assume they don't parse.
  bkardell: But if you do support in fast profile...don't they share
            a parser?
  fantasai: It could, but you shouldn't parse things you don't
            support. If you support in one context and not another,
            you parse where you support.
  SimonSapin: Even if we do have parsing code, we can still reject
              at parse time.
  <SimonSapin> ...in some contexts.

  BradK: What's the advantage of throwing away the whole rule?
  SimonSapin: We could make it parse, but never match.
  dbaron: In general if a selector isn't supported it's like a
          syntax error so authors only have one model of not
  dbaron: It's not the best form of fallback, but it allows some.
  <tantek> dbaron +1
  bradk: But if the media on the style sheet you might want to pull
         out both. [?]
  <bkardell> I'm mostly interested in this question in how/whether
             it applies to the houdini parser effort... would it be
             entirely outside that, or would that cause issue?

  smfr: I think the suggestion was selectors on the slow profile
        should be allowed to match while printing. They might have
        enough that they want them to match in terms of visual media.
  SimonSapin: If implementations are fast enough, maybe you should
              move things into the fast profile?
  smfr: Are UA allowed to decide for themselves what's in the fast
  SimonSapin: That's a good question.
  <leaverou> Yes please. These selectors are sorely needed in
             publishing and the consistency argument against
             allowing them in print is very weak.
  Florian: I don't think that's a good idea. Having people catch up
           is fine, but having people say they will and others say
           they won't isn't helpful. So the fast profile shouldn't
           be UA specific.

  bkardell: Did someone address whether print stylesheets should
            support fast profile?
  * BradK had assumed that print was part of the slow profile in the
          same UA.
  <bkardell> bradk, that's what I'm asking - is that specified? I
             don't think it is.

  Florian: We have a blurring difference. There's print, web and in
           between. Once you throw the print at an epub there's an
           expectation it'll work the same. When the computing
           difficulties do apply to on screen print equivalent
           rather than fully developed websites. It's a continuum.
  glazou: You mean tweaking the doc from inside the doc? That
          depends on the rendering engine for the reader. Some use
          browsers to render and that's yes, some are proprietary,
          then no.
  SimonSapin: Does EPUB support dynamic DOM updates?
  glazou: In some implementations, not all.
  <ChrisL> @media{fast}

  Bert: It's not currently defined which UA does fast, is there a
        way for the stylesheet author to find out which is used,
        probably by a MQ?
  smfr: I think that needs to be a question about a specific
        selector. I hope we can over time move selectors into the
        fast profile. It seems that should be the long term goal:
        everything is in the fast profile.
  glazou: Profiles here are the burden here more than anything else.
  smfr: Yeah. Can someone explain where they are from?
  glazou: Concerns about selectors especially in level 4 and the
          ability to batch process.
  <tantek> especially interactive user agents vs. batch user agents

  bkardell: I wanted to offer that I think the idea is there are
            certain selectors that aren't a problem as a one off in
            JS, but during initial load that's a lot of evaluation
            going on and they would prevent your ability to reason
            about selectors as traditionally done.
  bkardell: Doesn't flexbox and grid have this problem too?
  bkardell: The problem grid has is a mutation can make the whole
            thing re-evaluate.

  <BradK> Ebooks would be considered interactive, right?
  <glazou> BradK: not always
  <glazou> BradK: you can print ebooks
  <BradK> Or would the ebooks UA get to decide?
  <glazou> using a batch
  <BradK> Maybe some ebooks do batch processing when the book is
          opened, and then doesn't allow JS or mutations or content

  glazou: I think we need to revisit this section. I understand the
          original rationale but I understand why some implementors
          have concerns about some selectors. Our discussion today
          shows the unity needs to remain a value for us.
  glazou: If something is so risky for an interactive environment
          that browser vendors won't implement, may it is going to
          be a problem anyway. Batch processor won't use it. It
          wouldn't be main stream.
  Florian: The slow profile isn't meant for batch processors. It's
           only for JS. I'd be against it in batch processors
           because I don't want to have normative 'use' and
           normative 'must not use'. If we can get things into UA
           I'd be happy with it being off the slow profile.
  fantasai: We had this exact discussion in the past and we changed
            it so batch are not allowed.
  Florian: As long as we have to have the slow profile, it's
           important to do it this way. If we can do away with it,
           even better.

  glazou: It seems we won't resolve this now. If we leave that
          section in the doc untouched, we'll need to resolve this.
          We'll need to provide an answer to this question. We don't
          have a solution, but this should stay on the radar.
  glazou: What do we do about selectors not in the fast profile, not
          implemented by the given implementation.
  glazou: What do they do if they encounter such a selector in a
          style sheet.
  fantasai: Throw it as invalid. It's not supported by the CSS UA.
            It may be by the JS UA, but that's a different UA.
  SimonSapin: I agree threating as invalid is the only thing that
              makes sense.
  ??: Yeah.
  <bkardell> fantasai, at a minimum, I just think that needs to be
             made clear in the spec about why that makes sense
  <fantasai> bkardell: yes, Tab and I accept to clarify this in the
  * dbaron agrees that treating unsupported things as invalid, as
           always, is the only thing that makes sense

  glazou: Do we have consensus?
  Rossen: What would be the summary of the resolution?
  glazou: Selectors not in the fast profile not implemented are
          invalid and rejected at parse time.
  fantasai: Yeah, exactly. That's what is in the spec in the
            conformance section. We can make it more explicit.
  <bkardell> any fast profile moving into the slow would be done
             behind a flag presumably?
  smfr: I have an issue with it. I think it prevents UA from moving
        things into the fast profile when they have a good
  SimonSapin: When they do, they can discuss with us.
  smfr: The browser would still have to wait for the spec to be
        updated. I think UA should be able to improve by just making
        things faster. I'd prefer a solution where UA can decide if
        it's fast or slow.
  fantasai: I think it's easier for browsers to do that. One browser
            decides to do that and the others have to decide to take
            it up. The goal is to have interop. The pushback is
            implementors saying this will be crappy and we can't do
            this for performance.
  Rossen: Is the current profile in the spec supposed to be the
          subset of all interoperable features so you have something
          able to spearhead in one impl, it doesn't go in the spec
          until everyone catches up?
  fantasai: I think the problem is for a batch processor they can
            just do this now and it's easy. We have a block from the
            dynamic impl where they can't do that. If we didn't have
            this dichotomy, we could do it. So we're putting an
            artificial block on batch processors to make CSS
  smfr: But people in JS are still able to call selectors and make
        it slow.
  dbaron: What makes the selector slow is what needs to be done to
          handle a dynamic change. If you do a DOM mutation here,
          where do you need to reevaluate and can you reasonably
          track that.
  smfr: And you're saying that means it's okay to call these from
        JS, but using them in a style sheet is wrong.
  dbaron: It won't be fast, but it's an entirely separate problem.
  BradK: The parsing isn't slow, right?
  dbaron: But that would treat it differently than everything else
          that doesn't work.
  fantasai: We do that for a good reason. It lets authors write
            fallback and lets them plan better.
  glazou: We're far past the hour. The only objection is from smfr.
          smfr, given what dbaron said, do you accept the resolution?
  smfr: I can live with it?

  RESOLVED: We keep selectors not in the fast profile and not
            implemented as invalid and we clarify it in the spec.

  glazou: That's it for today. Sorry about the extra 5 minutes. Talk
          to you next week.
Received on Thursday, 5 March 2015 01:41:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:05 UTC