W3C home > Mailing lists > Public > www-style@w3.org > April 2016

[CSSWG] Minutes Telecon 2016-04-06 [mediaqueries] [css-grid] [css-sizing] [css-flexbox] [css-values]

From: Dael Jackson <daelcss@gmail.com>
Date: Wed, 6 Apr 2016 19:03:40 -0400
Message-ID: <CADhPm3vfPtQV_SQnTeyQOPn9370eUS-ciyYT=DfO7YpKGDtp7w@mail.gmail.com>
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.

Upcoming F2F

  - Everyone was reminded to add their information to the wiki if
      they're coming to the F2F and book their travel if they
      haven't already.

Media Queries

  - overflow-block and overflow-inline will be combined into
      overflow with properties to specify inline and block direction.
      - fantasai will write up proposed text for the new properties.
  - RESOLVED: Add infinite value to resolution MQ.
  - Florian will write up a proposal for a raster MQ.


  - There wasn't much desire to add grid-template back, but there
      wasn't much objection either.
  - fantasai will focus on making the grid shorthand more robust and
      solicit more author feedback.

Publication for Sizing

  - RESOLVED: Publish Sizing

Flexbox DoC

  - Everyone was actioned to review the entire Flexbox DoC.
  - The items that need the most attention are issue #3 and an
      additional paragraph added to order accessibility to
      address concerns from the accessibility working group.

Serialization of calc()

  - RESOLVED: Accept TabAtkins proposal for calc() serialization and
              add a note that there remains a concern about editors
              getting access to the bare string.

Test Suite

  - Everyone was asked to please contribute to the email thread on
      the test suite.

Specification Status Wiki

  - fantasai introduced a wiki compiled by Nick Guarino listing all
      resolutions and actions regarding each spec:


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Apr/0083.html

  Tab Atkins
  David Baron
  Bert Bos
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Ian Kilpatrick
  Peter Linss
  Myles Maxfield
  Edward O'Connor
  Anton Prowse
  Matt Rakow
  François Remy
  Florian Rivoal
  Alan Stearns
  Ian Vollick
  Greg Whitworth
  Steve Zilles

  Dave Cramer
  Daniel Glazman
  Chris Lilley
  Michael Miller
  Jen Simmons
  Lea Verou

Scribe: dael

Upcoming F2F

  astearns: We'll give people another minute or so and we'll start.
  astearns: Any extra to add to the agenda?
  Rossen: I want to do a quick nudge about upcoming F2F for Houdini
          and CSS.
  Rossen: It won't be more than a minute.

  Rossen: I wanted to remind people we're meeting in about a month.
          If you haven't booked travel, please do so. Hotel
          availability is disappearing.
  Rossen: If you haven't planned, do it soon or ping Florian who is
          doing airBnB.
  Rossen: I only see a dozen who have signed up on the wiki. I'm not
          sure if this is representative.
  Rossen: Perhaps you haven't added your name, but I wanted to
          remind everyone.
  <Rossen> https://wiki.csswg.org/planning/san-francisco-2016
  Florian: I haven't booked yet, but will soon. If you want in let
           me know.
  astearns: Thanks.

Media Queries

naming overflow-block/inline

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Feb/0043.html
  Florian: As we move to media features, print typically paginates.
           We had a pair of properties to say what we do in inline
           and block directions. fantasai pointed out a few naming
           issues. I'm okay with her suggestion. If anyone is
           interested we can discuss.
  Florian: So I'll just do it.
  Florian: Renaming property itself, we have overflow-block and
           overflow-inline. fantasai points out block is more
           interesting and we should have a shorter name. I think
           fantasai suggested a shorter name.
  fantasai: I was thinking for now since there isn't a great demand
            for an inline check, we can have these with just
            overflow. If we want a switch that checks we can have
            additional values. So overflow: scroll and overflow:
            scroll-inline are both valid. Same with page/page-inline.
  Florian: And you'd have inline-none?
  fantasai: I think we could. You would check the combination.
            overflow: none means not in the block. You would assume
            not scrollable if it's paginated, but it could be in
            which case it's true. overflow: scroll probably means
            both dimensions.
  fantasai: It's similar to multi-value property, but you only do
            one at a time.

  Florian: The only thing that bothers me is, is overflow: none in
           block, or both directions?
  Rossen: Currently none includes the other one, right?
  Florian: It doesn't compute to anything, it's a MQ.
  Rossen: Sure.
  Florian: Right now we have overflow-block: none and
           overflow-inline: none. If you merge, what does none mean?
           Both or block because that's what people care about?
  fantasai: It can be both.
  Florian: And block-none is separate?
  fantasai: If needed.

  Florian: So do we put all in and some at risk or limit?
  fantasai: I think there's no need for all. Generally people don't
            like to scroll inline. As long as we make it clear the
            author should assume no inline.
  Florian: I have a use case and a UA. If you take the specs,
           normally you don't want overflow in inline, but sometimes
           you have a big table. For a UA Vivliostyle paginates but
           on screen. So if you know you have inline-scroll you can
           skip doing the painful things to squeeze horizontally.
           It's not ideal, but there.
  fantasai: That's not a bad case. In that case let me draw up a
            concrete proposal and we can come back.
  Florian: I think the general direction you propose is worthwhile.

  ACTION fantasai draw up a proposal for overflow MQ
  <trackbot> Created ACTION-763

Infinite Resolution

  <astearns> https://lists.w3.org/Archives/Public/www-style/2015Jun/0131.html
  Florian: Resolution MQ. It assumes you have a resolution. However,
           if you print you're not often to a printer, but a PDF
           which is vector and has no resolution or is infinite. We
           don't define.
  Florian: TabAtkins and I concluded resolution MQ should have a
           infinity value that would match vector. So if you're
           doing if resolution > 200 dpi it shouldn't work on vector
  Florian: TabAtkins and I agree. Group?
  fantasai: Makes sense to me.

  astearns: Can you test?
  Florian: It's a keyword. You ask if it's infinite and it tells you.
           Otherwise you use inequalities.
  astearns: Okay. I didn't see it in the thread.
  Florian: It's a long thread.
  astearns: Objections to adding this?

  RESOLVED: Add infinite value to resolution MQ.

  Florian: Even when outputting to infinity, your vectors stay
           vectors. If you have raster graphics and you print to PDF
           often they will have a max resolution. You may want to
           query on this.
  Florian: The main resolution feature doesn't. We're proposing a
           new media feature that lets you check to what point
           raster images are down sampled. It's either equal to the
           resolution or lower if there's such a processing.
  frremy: This seems to be something only printers know, not browser.
          Do printer drivers expose this?
  Florian: When browsers print to PDF it's not necessarily through a
           printer driver. There's a lot of borrowed libraries, but
           it's not necessarily from an OS stack. So I assume
           there's some cases where you can know and some where you
  <gregwhitworth> this feels like something we should investigate

  astearns: Seems to me like next step for this bit is write a
            proposal and send for review.
  <tantek> astearns++
  Florian: Idea was discussed on the thread, but specific syntax may
           need to write.
  astearns: Can I action you?
  Florian: Yes.

  ACTION Florian write up a proposal for raster MQ
  <trackbot> Created ACTION-764

  <tantek> Florian does this mean we have enough resolved to do
           another WD of MQ4?

grid-template removal

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Mar/0345.html

  fantasai: We discussed the grid and grid-template and noted
            anything you want to say in template you can do in grid.
            Eric Meyer posted that in some cases that's not what
            wants. He wants to set some parameter of the grid up top
            and then use grid-template shorthand. So, should we add
            this back? It was removed last month.
  astearns: The argument makes sense to me. Other comments?

  frremy: I'm checking the spec now. We didn't remove
          grid-template-row and grid-template-column, right? His use
          case is covered by those properties. It doesn't seem you
          need grid-template to do it, but I'm fine with it.
  Rossen: Eric admits the same thing. My personal take is Eric was
          used to grid-template, not grid-template-row and
          grid-template-column. So that habit made him go to the
          shorthand which didn't work. I'd like more feedback from
          others before we add it back. Given we can use
          grid-template-row and grid-template-column directly that
          should be fine.
  Rossen: I also wouldn't push much back on adding it back in. I'm
          kind of impartial.
  fantasai: I think the main case where it really makes a difference
            would be if you had a template and the syntax for rows
            and columns is quite different. But I'm okay to hear
            from more people.

  gregwhitworth: We saw a lot of issues in flex where people using
                 the shorthand solved a ton of author issues. I
                 agree we should get more feedback, but I was
                 thinking we should lean on the history of author
                 confusion with long hand because the reset helps
                 most authors do modern layouts.
  astearns: So because in most cases we'd rather have them use the
            grid shorthand, this case from Eric is enough of an edge
            case it's okay to force him to long hands.
  gregwhitworth: Yeah. This is mostly just because the issues we had
                 from flexbox where if people just used flex it
                 would work. I'd rather not add long hands where
                 there's a true use case where we can't solve with
  fantasai: In this case we have long hands and a short hand. This
            is an intermediary hand. I understand the flex case and
            this isn't quite the same.
  gregwhitworth: Okay.

  Rossen: Would it be worth reaching back to Eric and getting more
          feedback before we decide to add this back in?
  fantasai: That makes sense. There's another comment where the grid
            shorthand is limited, but I don't know how to solve that
            quite yet.
  Rossen: I'd rather solve that and make the shorthand really good
          than have secondary short hands.
  <gregwhitworth> agreed +1
  fantasai: Okay. We'll come up with more expressive shorthand
            syntax and get more feedback on if the intermediary is

Publication for Sizing

  <astearns> https://lists.w3.org/Archives/Public/www-style/2016Apr/0048.html
  Rossen: Yes please.
  astearns: Does anyone object to publishing a new version?
  <tantek> ship it!

  RESOLVED: Publish Sizing

Flexbox DoC

  <astearns> https://drafts.csswg.org/css-flexbox/issues-cr-20160301
  astearns: First is people should look. I'd like to action the
            group to review the DoC and bring up issues next week.

Issue 3

  <astearns> https://drafts.csswg.org/css-flexbox/issues-cr-20160301#issue-3
  astearns: There's a specific item to review, which was issue #3

  fantasai: Christian pointed out we had discussed what the min size
            of auto does for the resolution of percentages inside a
            flex item. We didn't discuss the reverse where it's
            inside auto.
  fantasai: We discussed and concluded the right answer is when
            you're calculating an intrinsic size you treat the
            percentages as if the size was auto which generally
            causes percentages to fail and it's treated as auto. We
            put that in the spec, but we wanted people to sanity
            check and make sure it's clear. We think it's what we
            want but we want to make sure because it's fairly
            impactful change.
  <fantasai> The reverse = the impact that percentage sizes have on
             the resolution of min-size: auto
  astearns: Has anyone had a chance to review this change?
  Rossen: I haven't and I really want to. So I will.

  ACTION Rossen review flexbox issue 3
  <trackbot> Created ACTION-765

  gregwhitworth: Does this make Chrome match FF?
  fantasai: I don't know.
  gregwhitworth: I think FF and Edge are doing the right thing there.
                 I was trying to do the mental visualization...I can
                 go look. I was just curious if you knew.
  fantasai: I don't off the top of my head.
  gregwhitworth: We can check offline.
  Rossen: Yeah, it's definitely worth looking into. We'll look and
          follow-up over mail. That okay, fantasai?
  fantasai: Yep. I'm happy to give people time to review.

  astearns: Christian is which engine?
  fantasai: Chrome
  astearns: Has anyone from Gecko looked?
  fantasai: I don't know if dholbert has replied. I'll look. His
            feedback has been super helpful.
  fantasai: He did reply in the thread. Mostly with my edit being
            not quite correct. We fixed that.
  astearns: Anything else on this one?

order accessibility additional paragraph

  <fantasai> https://drafts.csswg.org/css-flexbox/#order-accessibility
  fantasai: The other thing for WG review is the addition of a
            paragraph for a11y.
  fantasai: We can just make sure it's the right thing to do.
  fantasai: It's the very last note in that section.
  <tantek> fantasai++ this is great work. Thanks!
  <tantek> really well written

  Rossen: We need to circle back with the a11y group on that.
  Rossen: Get their blessing.
  astearns: Has this been sent to their ML?
  fantasai: A bunch was resolved on their call. I CCed the person
            making most of the comments asking for this note. I
            haven't heard from her.
  Rossen: I'll make sure she replies.

  astearns: We'll come back to this DoC maybe next week or week
            after. Please do look.

Serialization of calc()

  astearns: I know TabAtkins and Rossen have things to say. Anyone
            else on the call with an opinion they'd like to express?
  <dbaron> maybe :-)
  fantasai: I think it would be good to hear from authors. That's my
            main concern.
  <fantasai> has opinions, but mostly defers to dbaron and authors
  TabAtkins: There is 0 author talk about this. So negative
             attention. Authors have clearly not spoken.
  fantasai: We have some in the WG that haven't spoken.

  Rossen: What I was saying is when I brought this up last week, I
          want to make sure...there have been cross threads on this
          for the last week...I want to make sure we understand what
          we're talking about and my concern. We're only talking
          about specified values and the serialization of those. I'm
          not pushing back on computed and simplification of those.
  Rossen: The thread that astearns started summarizing and
          differentiating the approaches between serializing the
          longhand as the author spec or simplifying before
          serializing. I thought it was a really good summary on who
          benefits from which approach.
  Rossen: I have personally discussed how people mentally map
          different models in their heads into calc(). I was working
          with our internal designers making winJS.
  astearns: Before you go further, I want one clarification. We're
            talking specified values in the OM. THe only time
            serialization is invoked is when OM needs to provide a
            value. This isn't dev tools or how browser represents
            specified value as you look. As far as I can tell dev
            tools in a browser aren't doing anything. It's only when
            accessing through an OM this is in play, right?
  Rossen: Correct.

  Rossen: I'm assuming in dev tools you serialize what's in your
          style sheet, right?
  TabAtkins: I don't know exactly. I know our dev tools let you at
             invalid tools. So it's an early level of parsing.
  iank: That's right.
  astearns: In the vast majority of cases, people are using the dev
            tools to tweek the values and what we define as calc()
            serialization for OM has no effect.
  TabAtkins: I just confirmed in Chrome even though we'll serialize,
             in the dev tools it shows what you wrote.
  dbaron: In Gecko we do show specified values in dev tools except
          in a few cases where we preserve extra data, but else wise
          we show specified.
  Rossen: That's why we try and keep specified as close as possible
          to author. We have a few code paths for dev tools that
          preserve rollbacks, but we've been keeping dev tools and
          OM the same.
  Rossen: Again I'm trying to find the best path. I'm fine with your
          proposal for the computed value. For specified if we're
          going to fork and have one for tools and one for OM, this
          is going to be a burden on our implementation, but it's
          solvable. Is that the final proposal we have here?
  Rossen: Or maybe I misunderstood.
  astearns: [notes TabAtkins lost connection]
  * TabAtkins is back
  astearns: That seems to be to be the way to move forward. It's an
            extra burden on you to take extra data into account so
            you can give the right thing to dev tools, but I don't
            see how to make typed OM for calc() specified values
            unless we define this serialization.
  astearns: So it's extra work for you to implement TabAtkins'
            proposal, but it's just not workable to leave things as
            Edge has them impl.
  frremy: I'm not entirely agreed. It's possible to have the same
          typed OM for specified value. So if you get pixel value
          you get it at the same time and you get the same value. So
          you can do the same thing at typed OM level. If you don't
          ask for typed OM you get the value as is and if you don't
          you get the value at that moment. I'm not sure it's
          necessary to simplify.
  frremy: It's easier and leaner, but not necessary.

  Rossen: I think it summarizes to this being implementation detail
          at this point. The point you're making is that the typed
          OM has to have the representation TabAtkins mentions and
          the rest of the serialization keeping the long hand is
          better editing
  TabAtkins: That requires us to hold a bunch of data just to
             serialize the legacy string which we don't want to
             encourage. This is just how you serialize when people
             ask through the OM. You can have two representations,
             but when you call whatever code stringifies it - it has
  Rossen: I think that makes sense. and that's what frremy was
  TabAtkins: There's 0 functional difference between holding the
             long and simple expression. For CSS data it doesn't
             care how you represent internally, but this is how you

  gregwhitworth: Have we reached out to people that want to show the
                 specified style in the specified form?
  TabAtkins: I did a search and couldn't find a person complaining
             about it even though several browsers have done this
             for years. Maybe someone cares, but it's not important
             enough for people to complain on stack overflow.

  astearns: Will the Parsing API solve this?
  TabAtkins: Mayyyybe,
  gregwhitworth: I'd like to not stack hypothetical specs. Typed OM
                 is getting close.
  astearns: I'm saying that that case where editors want to show
            what's in the style sheet may be a proper use case of
            the Parsing API. If we put the use cases in the right
            specs, it's good.
  frremy: I kind of agree, but you cannot access the stylesheet from
          the JS side if it's on a different origin,
  frremy: So you cannot read the file. Even if you have a buffer you
          can't get to the file. I'm not sure if this is really a

  Florian: Did glazou say anything?
  Rossen: He was mostly agreeing with the point I raised. That was
          about it.
  <frremy> devtools in the browser
  <frremy> http://www.vorlonjs.io/#getting-started
  <frremy> https://getfirebug.com/firebuglite

  Rossen: I'm not looking to stall this forever, I want us to move
          forward. As long as everything laid out on the table has
          been throughly examined we can have a group consensus.
  Florian: Only thing is when we say dev tools can do it, it's only
           ones built by browsers.
  <gregwhitworth> Florian, exactly
  <gregwhitworth> http://vorlonjs.com/
  Rossen: Absolutely. And what I was speaking about was things like
          winJS and the office team that has their own minware. They
          do everything from public OM. And if this is moving in
          unexpected ways it'll make debugging hard. Florian is
          right, debugger isn't in browser.
  astearns: This is why I was suggesting what's currently in typed
            OM about CSS text having the actual string makes perfect
  frremy: But if you call style.padding-left = 3px you can't return
          the original string. You still have to serialize at some

  iank: I've got one small data point. I was looking through
        internal JS apps. One thing for having a normalized
        serialization, one thing we do a lot is check to see if the
        width = some string. There aren't a lot of calc()s or maybe
        not any. If you don't have a normalized string it breaks the
        calc() use case.
  iank: It's another data point.
  <iank) There are a few libraries which also do checks like:
         node.style.width === node.style.height (dojo does this in a
         graphics library)

  astearns: Sounds to me Rossen proposed we resolve on TabAtkins
            proposal for calc() serialization but there remains a
            concern about editors getting access to the bare string.
            Can we resolve on TabAtkins serialization with that
            concern noted?
  TabAtkins: Yep.
  astearns: Objections?
  Florian: I'm tempted to agree. This isn't the first time we ran
           into this. We have a lot of places where we run into this
           and we need to address this properly. We're not blocking
           anything here not blocked elsewhere.
  fantasai: I agree considering actual editors is out of scope
            because there's a lot of places. Setting that aside, I
            defer to dbaron.
  TabAtkins: dbaron agreed two weeks ago.
  astearns: dbaron might be muted.
  dbaron: I don't have a lot to say now.

  RESOLVED: Accept TabAtkins proposal for calc() serialization and
            add a note that there remains a concern about editors
            getting access to the bare string.

  Rossen: So what happens next?
  fantasai: TabAtkins and I need to make edits to the spec
  Rossen: I think the note says hey authors we heard you and ignored
          it, but we may revisit.
  <fantasai> Yeah, not sure a note in the spec is needed
  <fantasai> Note to the CSSWG maybe
  astearns: I think more developers of dev tool kits.
  astearns: I'm going to call that closed.

  astearns: We have 4 minutes.

Test Suite

  astearns: gsnedders you there?
  astearns: He said he might not make it.
  astearns: Please note there is a thread on the test suite about
            having the test suite able to be imported by browsers
            and run more regularly. I'd like to add this to next
            week and maybe the F2F so there's attention paid

Specification Status Wiki

  <fantasai> https://wiki.csswg.org/planning/status
  fantasai: There's a page on the wiki tracking outstanding action
            items and resolutions for the spec. I didn't know about
            transitions and animations, so I just compiled those. So
            if you're not sure the status of your spec or if you
            made edits, they're here.
  astearns: It's biiiiiig list.
  gregwhitworth: Is this auto-gen?
  fantasai: All manual. And everything I know is done is crossed off.
  astearns: This is cool.

  astearns: Anyone else have a 1 or 2 minute thing?
  astearns: Let's call it. Thanks everyone.
Received on Wednesday, 6 April 2016 23:04:40 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC