Hr Gwea | 24 May 19:38 2016

[css-animations] Should really a reversed animation use the reversed timing function?

The current draft says the following about reversed animations:
"When an animation is played in reverse the timing functions are also reversed"

Assuming that current browsers' implementation of the draft are correct, then when using animation-direction:alternate what happens is the following (tested on Chrome and Firefox):

i.e. the timing function (which in this case is approximately a cubic-bezier(1,0,1,0)) is reversed into a cubic-bezier(0,1,0,1).
At first I doubted that this was the intended meaning of "reversed timing function", but seeing that Chrome and Firefox do the same, I guess that must be it.

However, I wonder, wouldn't it be more useful and intuitive to do it like this:
i.e. to use the same timing function as is, without reversing it.

Let me show you an example that illustrates why this second approach could be more useful.
When you are using a step function like step-start, the sequence of forward and reversed animations look like this:

The function step-start is reversed into a step-end alternately and the result is that the animation stays at the end state all the time.
But, obviously, this is not what you want when using animation-direction:alternate.

What you really want is this:

i.e. the same step-start function is used for both the forward and reversed animations all the way.
I hope it makes sense. Please give it a thought.


Prashant Kisanrao Nevase | 25 May 05:19 2016

[dip] Proposal for display size and density independent pixel.

Dear CSS Working Group,


There are many displays for different devices available for rendering the contents. e.g. big screens, projected screens, TVs, computer monitors, tablets, IVI displays, phablets, phones, wearables, etc. These displays have different sizes and different resolutions and number of pixels or dots per inch (display pixel density or simply called display density) varies for different displays. Due to this writing the contents which will work across different displays seamlessly or with less modification has become difficult and content developer has to consider many different displays e.g. different contents for mobile devices, desktop monitors, etc.


I want to propose "pixel", making it independent of "display size" and "display densities". Many mobile platforms (Android, iOS, WinMo, Tizen, etc.) support display density independent pixel, but display size (pixels measured diagonally) is not taken care any of the platform. Hence contents rendered gets occupied differently on different displays. Also desktop platforms do not support this. So web page opened on 12 inches display looks different than it opened on 21 inches display.


Making this css standard will help web pages render with similar layout on any display.


It proposes having new meta name "pixel" as given below -


<meta name="pixel" content="baseline-density=640;" ></div>


Then pixel scale factor for computing DIP (display independent pixel) is as given below -


device_baseline_density = baseline_density / display_size;
pixel_scale_factor = dots_per_inch / device_baseline_density;



baseline_density = Value of baseline-density property [input from web page]
display_size = Display size in inches (measured diagonally) [taken from platform]
device_baseline_density = Baseline density for the target display on which web page is to be rendered. [output]
dots_per_inch = Number of pixels per inch on the target display. [taken from platform]
pixel_scale_factor = Scale factor for pixel for target display [output]


By multiplying the css pixel by pixel scale factor, we get similar layouts for the contents.


For more details, kindly have a look at


~ Prashant Nevase


Rossen Atanassov | 25 May 06:53 2016

[csswg] Agenda conf call 25-May-2016

Time/Phone/WebEx details available to WG Members in w3c-css-wg.

US Toll Number: +1-617-324-0000

For local times, see:

0. Extra agenda items and other digressions

1. [css-grid] Reduced Subgrid Proposal - 1-axis subgrid 

2. [css-grid] Auto-repeat inside grid-template shorthand 

3. [css-grid] heuristics issue

4. [css-grid] Error-handling preferences issue here:  

5. [css-text] what level should break-spaces go to

6. [css-overflow] Clarify padding-bottom; publishing a new WD? 

Dael Jackson | 25 May 01:35 2016

[CSSWG] Minutes San Francisco F2F 2016-05-09 Part IV: CSS Content, Testing [css-content]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

CSS Content

  - The conversation started based around an issue that, as written,
      cross-references have the potential to create infinite loops.
      - plinss suggested solving this using a similar approach to
          how footnotes are handled traditionally and Florian agreed
          to investigate it.
  - The group then moved onto a more philosophical discussion on the
      future of the spec. Topics discussed included:
      - How can we ensure that browser vendors are okay with the
          approach so that they can implement it in the future?
      - Is the spec too big to publish?
      - How much attention should this spec get as it's not likely
          to be prioritized and/or implemented by browsers? Or
          should browsers be more interested in this?
      - Should epub have a special time on a F2F agenda like the FX
          meeting slots?


  - RESOLVED: Drop requirement for author or reviewer metadata
  - RESOLVED: Move to primary <link> to spec+section being inferred
              from directory structure. Supplemental <link>s must be
  - RESOLVED: spec-shortname/N-levels-of-ignored-subdirectory-
  - RESOLVED: Remove any title requirement, other than having one
              (implied by validity of HTML requirement)
  - RESOLVED: testharness.js tests don't need a meta assert (but
              reftests still do)
  - Moving to Github, move all of our tests to WPT repo, and
      stopping future use of Shepherd were discussed, but tabled for
      future conversation.



Scribe: fantasai

CSS Content

Page Number References

  Florian: With regard to cross-references
  Florian: It looks like this:
  <Florian> a::after { content: target-counter(attr(href, url),
            page); }
  Florian: Implemented in Antenna House, Prince, and PDFReactor
  Florian: Vivliostyle looking into implementing.
  Florian: Major issue right now is that as specified, it could be
           infinite passes.
  Florian: If you have something reference at the very end of 109
  Florian: You do re-layout, and then now it's at page 110.
  Florian: This goes back to page 109.
  Florian: In most cases you do N passes and it eventually stabilizes.
  Florian: 20 minutes is okay for print.
  Florian: 20 minutes is better than infinite minutes.
  Florian: I've never run into infinite loops in the wild, but
           multi-passes happens.
  Florian: It's already terrible.
  Florian: N passes of laying out several hundred pages is a bad idea.
  dauwhe: If N is 2 it's not too bad.

  <ojan> is there a spec for what we're discussing or just the
         mailing list threads?
  <fantasai> no spec for this issue

  plinss: It's only infinite if you allow the race condition to
  plinss: There's other fun things in paged layout that can create
          race conditions.
  plinss: Can apply a generic solution, detect if you are racing and
          stop racing.
  Florian: Detecting a loop and stopping is one way out of the
  plinss: Do layout, then check if it moved, then it stays there,
          don't bring it back.
  Florian: Problem is you end up with incorrect table of contents
  plinss: No, do second page layout. If it ends up on 110, you treat
          is as a widow.
  plinss: Leave it out at 110.
  plinss: Don't re-layout.
  dbaron: You do one pass, do references, say this has to be on at
          least this page
  dbaron: And shift things to later page.
  dbaron: But not earlier page.
  Florian: With a forced break priority.
  dbaron: Well, might want to do a priority with some ...

  Florian: Alternative solution, similar to manual fix-ups
  Florian: On first pass you have a placeholder.
  Florian: First do pass with a placeholder.
  Florian: Then do layout, fill in the text.
  Florian: If it's smaller, do some alignment within the placeholder
  Florian: If it's larger, might have ink overflow.
  [skepticism of this approach]
  plinss: This is a generic problem. Could have same problem with
          widows and orphans.
  plinss: This is a generic problem. Gonna run into the same problem
          in all sorts of other ways.
  plinss: Think we should have a generic solution.
  plinss: Not have an author-specified placeholder.
  dbaron: The solution is similar to standard solution to footnotes,
          which is if you push ...
  plinss: If your footnote grows, starts to push marker off, stop
          growing at that point.
  plinss: Same principle.
  plinss: Just before it would create a race condition, you stop.
  Florian: Okay, I hadn't thought about that one.

  Florian: We have this on our roadmap, not interested in infinite
           loop solution.
  Florian: We also think that having CSS properties that are
           acceptable for print formatters but not Web, is bad.
  Florian: Many passes is not good.
  plinss: There are other problems that require multiple passes.
  plinss: But most can be done in 2 passes, tops.
  Florian: So, way you suggested, no need to change syntax.

  Florian: One side advantage of placeholders, if you have long
           document and it takes awhile to render, have something to
           show in the meantime.
  dauwhe: Could do that as an author by putting placeholder content
          in HTML and then replace with generated content in CSS.
  [missed how]
  Florian: So most of the time you get 2 passes.
  plinss: Most of time you can do in 1 pass.
  plinss: Sometimes have to go back and do it again, then stop.
  plinss: You might have a rippling effect, but not a looping effect.
  plinss: Might have to do nlogn.

  ojan: We won't implement any of this, ever.
  ojan: It involves laying out the entire document in order to
        figure out what page something is on.
  ojan: Never doing that.
  esprehn: We treat generated content as DOM.
  esprehn: So this is going to be an infinite loop for us.
  ekimber: Certainly the case that in context of print, potential
           for infinite lops is unavoidable.
  ekimber: We might not be doing in this context, but then maybe you
           move stuff to a different page cuz not enough space, but
           that creates enough space, so move it back.
  ekimber: So only solution is to have a "stop trying" solution.
  esprehn: In our case, at a fundamental level layout can't affect
  esprehn: You can't say "do layout, and then set attribute based on
  plinss: Layout should never affect DOM. But you don't have to
          implement this as modifying the DOM.
  plinss: It's not DOM tree, it's layout tree.
  plinss: You have some situations, but you deal with it.
  plinss: But this is implementation details.

  myles: We're all agreeing here.
  plinss: Nobody is saying that layout affects DOM. I'm saying you
          don't have to implement generated content by affecting the
          DOM. If you do, can't implement these kinds of features.
  gsnedders: If we have 2 implementations, we're fine.
  <gsnedders> (sidenote: I was mostly being sarcastic about the fact
              that no browser will support it and our 2 impl
              requirement, given minutes don't capture tone)
  Florian: We have 3.

  TabAtkins: How do we deal with things that will not be implemented
             by browsers, but are implemented interoperably by other
  TabAtkins: How do we indicate to authors, that this won't work in
  Florian: Making clear to authors is useful.
  Florian: But one goals of what we're doing at Vivliostyle is to
           explicitly stop having CSS for Web and CSS for Print
           being two different things.
  Florian: Want to be integrated.
  Florian: We know browsers won't prioritize these features, but
           want to make sure they are implementable if they become
  hober: Florian wants the solution to be something we could
         theoretically accept.
  tantek: We will never implement vs. this is not a priority, those
          are two very different things.
  esprehn: They should just do it in Houdini.
  Florian: Risking a longer debate.
  TabAtkins: Similar to static vs dynamic profile of Selectors.
  TabAtkins: We have something that will fundamentally not be done
             in CSS processing.
  TabAtkins: But works fine in batch processors and JS.

Ebooks vs. Web

  Florian: I'm talking about ebook readers.
  Florian: Not batch processors.
  TabAtkins: We've already made a somewhat principled split between
             main Web stuff for CSS and other stuff.
  TabAtkins: Speccing that, and doing it well.
  TabAtkins: Fine to do that for ebook or whatever.
  TabAtkins: As long as a) it's clear, as in Selectors, that it's
             not expected to work in Web pages right now (though
             could change in future)
  TabAtkins: and also b) scope amount of time we spend on this.

  Florian: Jen has some good talks about this, Web design now be
           incredibly poor and boring cmp print
  Florian: Fantastic design on magazines, not done on Web.
  Florian: Web designers should look for inspiration elsewhere than
           the Web.
  Florian: Maybe pagination isn't part of that.
  Florian: Maybe mostly print, but having on the Web might be fine.

  esprehn: We should provide primitives, so people can make
           libraries, and if it's super popular we can backport to
           the Web.
  esprehn: Core of Web should be small, and libraries should
           implement these things.
  Florian: That is okay, but saying " this is for print " don't want
           to do.
  esprehn: Should say "this is for libraries"
  ojan: Being a standard and a spec isn't coupled to whether shipped
        in Web or print formatters
  ojan: Being a spec doesn't say where it gets implemented. That's a
        good thing.
  ojan: If we treat the whole room as caring about all the issues [??]

  plinss: I think I agree with all of you guys.
  plinss: What products implement what features? Depends on the
  plinss: Doesn't mean we can't standardize how these things should
  plinss: Whether implemented in browser vendors or libraries or
  ojan: Why have browsers in the room?
  astearns: Because the CSS expertise is in this room.
  astearns: We want to avoid the situation like EPUB 3 where they
            made up stuff for CSS that was badly designed.
  Florian: Also obvious that browser vendors get priority on topics,
  Florian: Then again, a whole bunch of people here who are not
           browser vendors.
  gsnedders: Also worthwhile to point out that a lot of people in
             this room have a good idea what can be performantly
             implemented within the larger CSS model
  gsnedders: regardless of whether implemented in browser or not.
  gsnedders: And that's a good thing.

  jensimmons: It feels like some of this also is about giant billion
              dollar companies saying "this isn't in our interest,
              therefore shouldn't be in wg"
  jensimmons: But there are smaller vendors, smaller groups that
              have other interests
  jensimmons: I don't think it's fair to say that if Google will
              never implement, we shouldn't spend time on it.
  jensimmons: There are some things that are super worth our time to
              make sure specced well.
  jensimmons: Things that epub and print needs, and a lot of other
  jensimmons: Tension between reality of who pays us and let's make
              it the Web. Web is cool.

  dauwhe: I would just drawing back and looking at question in hand,
          this spec is about generated content in general.
  dauwhe: Talking about the value of one particular type of counter.
          But this applies to a lot of different counters, and there
          are a lot of web stuff in this spec.
  dauwhe: We reach some resolution on the particular issue, might
          not end to specify width for placeholder for page counters
          in this circumstance.
  dauwhe: As we gain implementation experience we can perhaps
          revisit the issue.

  Florian: plinss suggestion is maybe a more interesting solution to
  Florian: Given obvious priorities of browsers I think it's fair to
           timebox this type of non-browser discussion.
  Florian: But definitely don't want it to be on a separate track.
           That has been a disaster.
  Florian: When liam came to us to say that "I'm sorry to shut down
           XSL:FO, but would be ok if CSSWG takes on our use cases"
  ojan: Don't have a problem with CSSWG taking on these specs
  ojan: Do have a problem with having this whole room to discuss
        spec where only 5 people are talking.
  ojan: We need to fix that.
  dauwhe: General problem.
  tantek: That's a scheduling problem.
  Florian: Also, Tab and fantasai are always in the discussion.

  ojan: I would feel very differently if this was a javascript
  ojan: Forcing whole page to re-layout would be fine for a JS
  ojan: Fine feature, serves user purpose
  Florian: Our UA is a giant JavaScript library.
  ojan: Understand about tracks... but how about splitting such
        things off into a separate day... houdini ...
  astearns: Houdini topics [...]
  Florian: Some are native implementations, not JS.

  esprehn: What about the rest of the spec?
  esprehn: This spec contains a bunch of stuff. Datetime and
           document-url, leaders, etc.
  esprehn: From our perspective belongs in a library
  esprehn: Think it should be in a JS library
  esprehn: Be really nice to publish a spec that describes what
           browsers really do.
  fantasai: That was 2.1.
  esprehn: But it didn't.
  fantasai: What's missing?
  Florian: I put this one on the agenda because we want to
           implement, but not how it's been implemented by the other
           print formatters.

  dauwhe: I came into the WG just as Håkon was leaving, and took
          over editorship of GCPM.
  dauwhe: Much of it was a .. junkyard.
  dauwhe: Stuff just collected in GCPM.
  dauwhe: Over past few years, resolutions to move things into their
          respective specs.
  dauwhe: Moved GC features into GC.
  dauwhe: Also now a spec hadn't been published in 13 years, full of
          cool and interesting ideas from Håkon and Ian Hickson.
  dauwhe: Many things important to the Web, would like to publish.
  dauwhe: What we have now is an early-stage ED.
  dauwhe: fantasai and I did some work on this to bring it to state
          where we can present to WG and publish a new WD.
  dauwhe: Beyond that it really is WG decides.

  tantek: I'm agreeing what Elliott is saying, if we want to publish
          the WD, need to shrink it.
  tantek: If we want to publish REC track document, need to have a
          concerted effort to split the features that are being
          actively developed vs. junkyard features into next level.
  fantasai: This *is* a trimmed down spec, it's just not trimmed
            down to "browsers only" set of features.
  fantasai: If the working group is not taking that as being trimmed
            down then the WG is not browser only.
  fantasai: We're working towards trimming it to get it to REC.
  dbaron: We shouldn't look at Ebook things as being separate from
          browsers. Ebooks being in a browser is maybe a good thing.
  dauwhe: W3C and IDPF are working towards more integration.

  skk: We also creating epub viewer, based on Blink, creating page
       generation with C++.
  skk: I think generated content spec is not for web browsers, but
       for Ebook viewers.
  skk: But if we have a chance, but we are using Blink so we want to
       talk with Google web browser team to generate the page numbers.
  skk: Page numbers are async generated.
  skk: We already did the implementation now, but the collaboration
       API specified between Blink and us would be very useful.
  skk: Also Gecko, better if API is specified.
  skk: Such kind of discussion is productive between Web and Ebook.
  skk: From Ebook viewer implementer perspective.

Alt Text for Generated Content

  dauwhe: One thing in the spec that hasn't been implemented is
          trying to design a mechanism to make generated content
          more accessible.
  dauwhe: Which is a critical point.
  fantasai: Not about exposing generation content to a11y--that's
            already required.
  fantasai: but about some generated content is symbols or pictures,
            needs different text for speech.
  dauwhe: Our idea was that the content property takes this endless
          trying of various bits of strings or replaced elements.
  dauwhe: We're proposing that at the end you can put a slash and
          then alt text.
  dauwhe: Potentially empty, if the string is decorative (e.g.
  TabAtkins: Previous proposal was an 'alt' property.
  fantasai: It was bad because it doesn't cascade together with
  dauwhe: This would also allow us to provide alt text for images
          inserted via content.
  plinss: Instead of using URL, maybe using image function?
  plinss: ... and put alt text inside that function

Ebooks vs web cont.

  ojan: Ebooks as part of the Web is a good future.
  ojan: That's why I think speccing these things is important.
  ojan: But think of it similar to SVG-CSS day.
  ojan: Where it's a special cross-functional meeting.
  ojan: To have an explicit Ebook Track, not necessarily in
        parallel, but be explicit about that section of the F2F.
  Florian: I think that's fine, a bit concerned about the boundary
           being fuzzy.
  ojan: I think being explicit about that might change what's
        plausible, practical to implement.
  ojan: E.g. target-counter() is great as a feature, but not as a
        built-in browser feature.
  TabAtkins: Could have JS api about getting the counter value.
  Florian: I'm happy about being explicit about scheduling this in
           sections, less happy about putting it into the spec.
  TabAtkins: I don't like specs that web authors look at but don't
             know what to use.
  TabAtkins: I think authors should know whether such features will
             ever be useful.
  plinss: I don't want to be picky about language, but going to be
          picky about your language.
  plinss: Have no problem with your fundamental point "this is
          what's expected to be in browsers today."
  plinss: But I have a problem with saying "this is never expected
          to be on the Web ever."
  plinss: Saying up front "We don't ever expect this to work in a
          browser", that's going to change the future.
  plinss: That's a bad way to scope the future.

  astearns: Has to be put in language that the current efforts are
            going to be in script, but that they may move into the
            browsers. And we don't have a good set of terms to talk
            about that migration purpose.
  Florian: I'm not sure it's bad to get peoples' hopes up.
  Florian: If there's a lot of people that think people really want
           it, then it pushes forward.
  esprehn: GCPM didn't move forward for many years.
  Florian: Because it was a lousy spec.
  Florian: I don't want to have that again.
  Florian: People just didn't pay attention to junky spec "for print"

Page Number References cont.

  Florian: target-counter(), when it doesn't refer to pages, I don't
           see any reason why it wouldn't be useful on the Web.
  Florian: Can do "See Figure 17", nothing wrong with having that on
           the Web.
  Florian: Until you care about pages, might not do page counter
           references, though.
  TabAtkins: Mark it at-risk
  ojan: What if we had two specs. "here's generated content as it is
        in browsers today" and "here's generated content for
  * fantasai thinks we're arguing over this wayyyy more time than
             we're spending on the technical work

  plinss: If you say never gonna implement this, I think you're
          going to be wrong. Can't tell your business interests 5
          years from now.
  plinss: But also, you're not the only browser.
  esprehn: If you have something doing layout totally different, e.g.
  esprehn: We're not going to spec that, you can't do that.
  esprehn: I think making the string thing, take the text content
           value of a node, it's a cycle in algorithm, violates
           fundamental constraints of how the system work.
  Florian: I agree with that, and that's why I want this discussed
           here so that we spec it in a way that doesn't violate
           fundamental constraints.
  [repetition of existing points]

  fantasai: Also Elliot I think you're missing the point,
            target-counter() can be used for other things than page
  esprehn: We're not going to ever add more features to counters.
  esprehn: We want people to write JS for counters.
  plinss: CSS doesn't define what's implemented in C++.
  esprehn: HTML had a sorting algorithm, was never implemented, and
           it was removed, and people can implement it in JS.
  tantek: That was also before incubation and stuff.

  <leaverou> esprehn: Do you realize that there are tons of CSS
             authors that do not *know* JS?
  <leaverou> esprehn: you are complicating the web platform for
             authors with this kind of thinking.
  <shane> leaverou: implemented in JS won't mean unusable by CSS
          authors - the whole point of Houdini is to open CSS up to
  <leaverou> shane: Using libraries has a ton of overhead. First you
             need to find the best library, you need to bear the
             bandwidth cost, you need to learn its documentation,
             often switch to another library halfway through etc etc
  <leaverou> shane: Libraries are not the solution for essential
             functionality. Library authors are not spec writers and
             will often create worse APIs
  <TabAtkins> leaverou: Yes, of course we realize that. We also
              realize that the stdlib *cannot* be extended
              infinitely, nor do we want to forever hijack *every
              feature forever* on how quickly browsers can cycle
              their implementation.
  <leaverou> TabAtkins: Then allow people to conditionally import
             modules, but standardize said modules instead of having
             them hunt down libraries which could be terrible.
  <leaverou> it seems to me that Houdini is used as an excuse to not
             implement anything Google devs don't like

  fantasai: This is a draft, you can cut this down we get to the
            point that browsers need to consider implementing it.
  tantek: If that is true then call it something else.
  fantasai: We are replacing those drafts with something new, and
            we're going for a FPWD from the old scope of that module
            and should have the same shortname, etc.
  tantek: I want to suggest a path forward, if there's a dispute wrt
          implementability, indicate in the draft
  tantek: e.g. put a box explaining the implementation experience
  tantek: and caveat of whether it's stabilizing, or is very shaky
  tantek: Give authors anyone else reviewing spec a chance of what's
          the context of evaluating this feature.
  tantek: This feature has some print implementation, but no browser
          implementations yet, pls send feedback, at least that's
          conveyed to authors.
  tantek: Rather than mis-conveying any intent.
  tantek: E.g. features that are widely-implemented vs not
          implemented at all labeled separately to help with
  tantek: So my request is to put per-feature, implementation
          experience and suggestions for feedback.
  dauwhe: We have a mechanism for doing that already: test results
          per browser.
  dauwhe: If we extend that a little bit, can see that Prince/AH/etc.
          that are passing, that gives you the information you need.
  dauwhe: If you see that the tests pass in blink/safari/edge,
          useful information too.
  astearns: Script that does the annotations could be more verbose.
  dauwhe: You can filter on that information, all sorts of things.
          This is data we can get.
  dauwhe: Might make us write more tests, all sorts of things.

  dbaron: plinss said something earlier about not wanting the spec
          to say that a spec was intended for print.
  dbaron: My general feeling is that we do not write enough of what
          our intent was into the specs, and that hurts our ability
          communicate with the ppl reading the specs and trying to
          understand them.
  dbaron: I think we should have more informative text in specs
          saying why what's there is there and what it was intended
          for and so on.
  dbaron: And one of the other worries I have is, if we don't say
          that things are intended for print, then essentially
          there's an incentive for me to try and make things not be
          in the spec because I'm worried about the risk that some
          junior developer at Mozilla will try to implement a thing
          that they shouldn't spend time on.
  dbaron: But they saw it in the spec and thought we should
          implement it.
  <tantek> exactly the problem
  <tantek> or you get some advocacy groups pushing for something

  jensimmons: I just wanted to toss in that I think we should be
              careful not to assume what a browser is.
  jensimmons: Not say "there's real browsers and there's ebook
              readers, and there's print, and we don't care about B
              and C".
  jensimmons: There are lots of experiments happening around what is
              a browser.
  jensimmons: This is going to come up a lot. What a browser is
              is going to change.
  * ojan just wants to clarify that noone said "real" browsers or
         that we don't care about ebooks

  gregwhitworth: Lea commented in IRC.
  gregwhitworth: She was saying that there are a lot of CSS devs
                 that don't know JS, and we're over-complicating
  ChrisL: Lea doesn't disagree with Houdini existing. Disagrees that
          Houdini should be used as a blunt hammer for everything.
  <leaverou> yup
  <leaverou> I've seen it used way too much as an excuse to not
             implement or spec things that authors need.

  TabAtkins: The circular ones should be dropped from expectation
             for browser implementations.
  <leaverou> TabAtkins: depends on what you define as a browser. Is
             a print formatter a browser?
  <TabAtkins> For the purpose of this discussion, "a browser" is
              "the things developed by the browser vendors here in
              the room".

  fantasai: I'm happy to keep discussing technical issues, but I
            would like to close the scoping issue.

  Florian: Other topic, not GC, is interaction between Media Queries
           and  <at> page { size }
  Florian: Anyone want to discuss this now?
  Florian: Probably should talk about something other than pages,
           because everyone is hating on pages right now.
  dauwhe: 3D transforms? :)


  gsnedders: We basically have consensus on getting rid of a lot
  * fantasai wants a WG resolution on test metadata so to move
             forward with conversions
  gsnedders: If we want to get browsers actually running the test
             suite, then we need to get browser vendors to actually
             talk about this.
  gsnedders: The metadata thing is actually smaller bit.

  gsnedders: Big thing I want to discuss is stuff like how we want
             to deal with test review in the future.
  gsnedders: How we want to deal with issues on tests in the future.
  gsnedders: Because at the moment we have this weird split system
             with pull requests on GitHub which get reviewed before
  gsnedders: Whereas other things are just pushed directly to
  gsnedders: In principle, sometime in the future, but realistically
             never, they get reviewed.
  gsnedders: In my opinion it makes sens to move everything to
             github PRs with review before merging.
  gsnedders: Realistically, there's no motivating factor for people
             to review tests before they're landed.
  gsnedders: We saw this with 2.1 as well.
  gsnedders: Just moved everything to approved, thousands of tests
             never gonna review.
  gsnedders: Would like to avoid ending up in that state again.

  <tantek> first piece of feedback, no content in HTML/SGML comments
           please. e.g. "<!-- YYYY-MM-DD -->" bad. Instead, slap it
           on the end of the title attribute, e.g.
           title="NAME_OF_REVIEWER, YYYY-MM-DD"
  <tantek> (kind of like how people sign documents)
  <tantek> could
           cite the previous documentation of the CSS WG test suite
  <tantek> what happened to atomic vs basic tests as Hixie and I had
           distinguished so you could check whether something
           implemented anything at all?
  * tantek digs up
  <gsnedders> tantek: we badly need to sort out the fact we have
              contradictory documentation all over the place…
  <tantek> gsnedders: could you start by citing the previous
  <tantek> (I mean inline in the css-metadata doc)
  <tantek> ah this is the one I was looking for
  is a
           good predecessor to cite for css-metadata.html
  <tantek> e.g. that guidelines.html has the rel=author, and
           rel=help aspects

  astearns: Got a bit of history because we had tons of tests
            waiting for review in Shepherd, that we new would never
            get fixed.
  astearns: Tests hanging as Github PRs isn't great either.
  dbaron: I don't think reviewing tests is particularly a good use
          of time. Particularly the way they have been reviewed so
  dbaron: Certain test reviewers have given feedback that ends up
          more or less meaning "go away".
  dbaron: Also best way to to review tests is to write an
          implementation, and to see if the tests pass.
  dbaron: And the important thing to check for is that the test
          tests what it thinks it's testing.

  fantasai: Three things to check:
            1) Test pass when it's supposed to pass
            2) Test fails when it's supposed to fail
            3) Tests what it thinks its testing
  Scribe: iank
  fantasai: I've seen some tests which only pass sometimes, for
            example when it depends on the width of the window.
  dbaron: Implementers are probably going to catch #1.
  fantasai: You can have tests which are mis-labeled.
  fantasai: I think that dbaron has a good point that (1) is going
            to be checked by browsers, (2) & (3) you should check
            for, you may as well check for everything.
  dbaron: I think that web platform tests have worked out a model
          that works here.

  dbaron: I'm pretty close to telling people to create a folder in
          the wpt repo at the moment. This is largely due to
          preprocessing issues.
  fantasai: In terms of review process to we review then land or
            visa versa?
  fantasai: Agree that this is an issue we should fix, but back to
            gsnedders issue on review.
  dbaron: For wpt as a Gecko dev, I can just check in the repo, and
          a Mozilla dev will deal with it working.
  <gsnedders> in w-p-t there's an extra motive to review: you start
              running them when they land
  <gsnedders> in csswg-test, there isn't that if the test is already
              in the repo
  ojan: We have chrome folks that are working on better wpt
        integration tests.
  zcorpan: WPT, review from the browser vendor means you just merge
           the tests.
  ojan: Doing future things in wpt will be good for us.
  <gsnedders> for w-p-t, the browser vendor review must be public
              for free landing.

  Florian: Simply the review process, decrease the amount of
           meta-data, remove the build system, and once we've done
           that we've done a lot. If we do this, then we can
           re-evaluate if we need to do other things. I would not
           want to start by dropping things that we know that have

  ChrisL: Should keep the metadata, as difficult for people to know
          what the test is testing.
Scribe: fantasai
  gsnedders: WPT has loose rule that the reviewer must be able to
             understand what the test is doing.
  gsnedders: How you communicate that to the reviewer, isn't really
  gsnedders: Can put in an HTML comment.
  gsnedders: Could be completely obvious cuz it's a 2-line test
  gsnedders: No point in actually stating forms of how it must be.
  gsnedders: Merely gate it on the review
  gsnedders: but that only works if you do the review before merging.

  fantasai: For our purposes, having links to the sections test
            helps us a lot.
  fantasai: Not just for review, but also to generate test coverage
            reports, implementation reports, and to know which tests
            need to be updated when the spec changes.
  fantasai: So I think having this in a fixed format is useful and
            important to try to keep.

  fantasai: With regards to other metadata,
  fantasai: WPT have slightly different format because they use a
            lot of JS tests that are combined in one file, so having
            HTML comments etc. as documentation makes sense, per-
            file data is not going to be as useful.
  fantasai: Whereas in reftests, more granular per test.
  fantasai: I don't see a problem with pulling out the comment on
            the test, having it in a standard format rather than
            just in a random HTML comment somewhere.
  fantasai: Comment being the documentation of what it's testing.
  fantasai: Just as a function has a formalized comment at the top
            saying its purpose and its parameters,
  fantasai: So that it can be used and understood and reimplemented
            if necessary, so should a test.
  fantasai: This is independent of clearly-written code with good

  Florian: On the assertion itself, I think that's one of the things
           that we may need to come back to later
  Florian: if it's getting in the way.
  Florian: But I don't think we should do this until we've cleared
           out all the other problems
  Florian: and have determined that it's still a blocker. Not a good
           place to start from.
  Florian: FWIW, this is less necessary in JS tests. Because you
           have an assertion written as code.
  Florian: But in CSS tests, that's not the case.
  Florian: We might need to drop that description eventually, but
           let's not start here.

  Florian: As for what we can do, with regards to links to specs, I
           think we can sort of have best of both worlds.
  Florian: You store your test in predefined directory structure,
           points to the right part of the spec.
  Florian: But should you wish to link to extra information to link
           to other sections of the spec, then you can add more such
  Florian: Not blocking.

  Florian: Another bit of metadata is the title;
  Florian: HTML requires a <title> so we have to have one, but can
           say put anything in it.
  Florian: With regards to author/reviewer, leave that to source
  Florian: With regards to flags, I think we can get rid of most of
  Florian: Make them a niche occurrence.
  Florian: Spending something like 10-15 min going through the list
           might be useful,
  Florian: but should do that.
  Florian: I think we do that for title, keep assert meta, get rid
           of author meta etc. simplify flags, simplify reviewer
  Florian: If we just do these bits then we'll have done a lot.
  Florian: Then we can discuss why not.
  Florian: But not to do more than that
  Florian: yet.

  <tantek> I don't think it's useful to brainstorm this realtime here.
  <tantek> I'd rather read a proposal, e.g. a delta on what
           gsnedders has already put forth.
  <gsnedders> tantek: as would I, but there's almost no replies on
              the mailing list to much of what I say :(
  <tantek> gsnedders, yes, I understand why you brought it to the
           f2f agenda, that part makes sense
  <tantek> my point is that if someone here wants to take the time
           to make counter proposals beyond "here's a simple fix"
           (e.g. see my suggestions above ;) ) then they can be
           actioned to write up a longer proposal

  zcorpan: In WPT, you can put link to the spec using <link> element
  zcorpan: But can also infer from directory structure
  zcorpan: by spec/id.
  fantasai: I'm ok with this, as long as that information is
            available and people writing tests for cross-section or
            cross-spec interaction are able to add <link>s.
  zcorpan: OK with requiring assert for reftests, but less so for
  [Florian and fantasai agree]

  [discussion of where to track reviewer information]

  plinss: I would argue against removing any existing metadata, but
          remove requirement to put it in.
  <tantek> +1
  gsnedders: Question remains, how do we flag that a test has been
  plinss: If there is a reviewer flag, shepherd will mark it
          reviewed. But otherwise Shepherd will track it.
  plinss: Merging GitHub PR also counts as a reviewer.

  RESOLVED: Drop requirement for author or reviewer metadata
  RESOLVED: Move to primary <link> to spec+section being inferred
            from directory structure. Supplemental <link>s must be

  <tantek> not hearing consensus
  plinss: Do we have nested sections?
  fantasai: No. Just spec/fragID.
  fantasai: We move sections around or change their nesting level.
            But we keep the fragID stable.
  plinss: So I propose we have shortname + leafesectionid and N
          levels in between.
  plinss: We ignore the levels in between, they can be named anything.
  fantasai: I don't think there's a need for intermediary directories...

  RESOLVED: spec-shortname/N-levels-of-ignored-subdirectory-

  RESOLVED: for 2.1 use css2/filename/frag-id-of-section
  <dbaron> ?: or for 2.1 we can require help links
  (remove previous RESOLVED)
  plinss: If spec doesn't match this format (e.g. 2.1 which has
          chapters) then have to use <link>

  RESOLVED: Remove any title requirement, other than having one
            (implied by validity of HTML requirement)

  tantek: Want to say, don't keep content in HTML comments.
  <tantek> can we get a resolution on not putting content in HTML
  * fantasai didn't understand your comment, tantek

  RESOLVED: testharness.js tests don't need a meta assert (but
            reftests still do)

  <tantek> PROPOSED: Drop any requirements or even suggestion to put
           test meta info into HTML comments
  <tantek> ^^^ yes this is about reviews

  gsnedders: Basic agreement on the flags to keep/drop on ML.
  gsnedders: For WPT, if there's a public review, you can use that
             to upstream it to WPT repo.
  gsnedders: I think that only affects Edge now :)

  Florian: I'm in favor of that, one thing that we're losing if we
           move away from Shepherd way of doing things.
  Florian: If you are using Shepherd to review, you have access to a
           view of tests,
  Florian: You don't have that view in GitHub,
  Florian: We're assuming people will be diligent and look at the
           test on their own machine.
  fantasai: I think the biggest thing is being able to understand
            the test when reviewing it.
  fantasai: For me at least, I understand better when I can see the
            output and try to connect that to the code I'm looking at.
  fantasai: So it's much harder for me to review tests from a GH PR
            than to pull down the repo and look at the test locally.

  gsnedders: For WPT, PRs by some people ...
  zcorpan: I'm on the whitelist, so if I make PR, my PR gets
           mirrored on
  zcorpan: In a subdirectory, where I can run it.
  zcorpan: Right now there's no automatic link in the PR itself, but
           we could add that.
  zcorpan: So could add a link directly.
  zcorpan: I agree it's useful to be able to easily run the tests
           without having to checkout.
  Florian: So you can also whitelist PRs from other people.
  zcorpan: The whitelist is there to avoid security problem
  astearns: So it wouldn't be a problem to take anyone that's
            interested in reviewing tests on the whitelist.
  Florian: I think having a system like that is valuable, not sure
           about blocking on it.
  Florian: gtalbot feels pretty strongly against a system which
           doesn't have that (ability to easily run the tests).
  gsnedders: I think that's fine, practically already have it for
             WPT, should make it explicit.
  zcorpan: Should make it easier to get there, from the PR,
  zcorpan: e.g. have a bot add a link.

  Florian: Are we resolving to move to GitHub, review then merge,
           and also to merge the system?
  Florian: Or is the system a dependency on moving to GitHub?
  gsnedders: Should be easy to set up as long as don't need to build.
  fantasai: Shouldn't need to build except in [weird very rare cases].
  astearns: So seem to want to move to GitHub.

  plinss: Suggestion to move all of our tests to WPT repo.
  gsnedders: That's a long-term goal shared by browser vendors
             (except Microsoft hasn't said anything).
  Florian: Short term or long term goal?
  plinss: Long term goal since beginning of WPT.
  plinss: Block has been our dependency on build system.
  plinss: If we eliminate that, then no reason not to move to other
  plinss: I'm happy doing that. Takes Shepherd out of the feature. I
          can maintain the historical data, but won't run against
          WPT for a long time if ever.
  plinss: Would need to keep build system and parts that help us
          generate implementation reports.

  [Meeting closed.]
  [discussion deferred to later]

Dael Jackson | 25 May 01:35 2016

[CSSWG] Minutes San Francisco F2F 2016-05-09 Part II: Counters, Values & Units [css-lists] [css-values]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: Add new syntax (TBD) to control counter scoping and
              consider reversing too.
  - TabAtkins will write a proposal for this new syntax.

Values & Units

  - plinss will file an issue with TAG to fix the general pushState/
      url reference problem in the DOM.
  - RESOLVED: Add hidden state to hash-reference-only URLs so that
              they can always resolve locally in presence of
  - RESOLVED: Adapt the element() function so that it can be used to
              refer to always-local references



Scribe: Shane


  TabAtkins: Ran into a fun example, author commented on what he
             thought was a mistake in list spec.
  [TabAtkins] draws a diagram
  <fantasai> Tab writes:
  <fantasai> <ol>
  <fantasai>   <li>
  <fantasai>   <li>
  <fantasai> </ol>
  <fantasai> <div>
  <fantasai>   <ol>
  <fantasai>     <li>
  <fantasai>   </ol>
  <fantasai> </div>
  TabAtkins: interesting thing is if you manually set up counters
  TabAtkins: and use the counters() function

  dbaron: You're supposed to counter reset on ol:before, not ol. I
          think that avoids the bug you're about to describe.
  TabAtkins: IT DOES!
  [the crowd goes wild]
  <SimonSapin> dbaron: even if ::before has display: none?
  <SimonSapin> or content:none
  TabAtkins: So we should just adjust the spec to say ol:before
             instead of ol?
  dbaron: Assuming :before exists though.

  TabAtkins: Counter established by counter-reset on the first ol
             counts its siblings until the first one that resets
             but the next ol is a cousin, so it nests instead.
  TabAtkins: Few ways around it. (1) instead counter-reset on first
             li or on :before. Then scope only covers the list.
  TabAtkins: (2) explicitly resetting a counter when it came from
             something that wasn't in the ancestor chain then reset
             instead of nesting.
  Florian: Wouldn't that fail with headings?
  TabAtkins: No?
  dbaron: Yes.

  dbaron: The rule is that a later sibling replaces an earlier
          sibling's counter, but not if it's a descendant of the
          later sibling.
  TabAtkins: If you're using heavy sectioning content then you've
             got nesting and it'd probably break.
  dbaron: With sections you should be fine, as long as sections &
          headings line up.

  dbaron: There was another problem, solution was counter-set
  dbaron: I don't remember the problem.
  TabAtkins: The value attribute on li. Already in spec.
  dbaron: I was trying to remember if other problem relates to this
          one, it doesn't.

  ekimber: Question: what's the use case for having the counter
           apply to following siblings?
  TabAtkins: Headings. You set up one counter at the top of the
             document and run it right down through the whole thing.
             If you have a flat document structure where headings
             are siblings then you can reset H1 and H2 counters,
             which will operate until next H1, next H2, etc.
  dbaron: You reset your H2 counter *at* your H1.
  ekimber: Given that, response would be "HTML is broken, so what."
  ekimber: So this is user error.
  ekimber: This is an unavoidable consequence of having to support
           this flat list.
  TabAtkins: Not necessarily, only if you want to support *all* of
             what HTML can do.
  TabAtkins: If you have an H1 as a child of body, and a div wrapper
             around the H2 that sets up a subsection.
  TabAtkins: Then that would break with the suggestion I'm making.
  ekimber: Implication seems to be - be consistent, otherwise things
           will mess up.
  Florian: Also the header element, can use for header of page OR
           title with subtitle.
  Florian: Not consistent, so nesting will be varying,

  esprehn: This change would be observable, right?
  esprehn: ol resets the counter. If you put the value attribute on
           an li which lets you explicitly number, then there's a
           reset there too.
  dbaron: That's a set.
  TabAtkins: Something something bug.
  esprehn: Does anyone implement?
  esprehn: We support counter but both value and reset are the same.
           So doing this changes the behavior.
  TabAtkins: But current behavior is very unexpected
  dbaron: <li><li><li value=5> - counter value inside each one,
          without set you'd have 1, 2, 2.5
  TabAtkins: So yeah it'll fix it to 1, 2, 5, which is actually good.

  Florian: Given earlier thing with header, does that rule out
  TabAtkins: Makes it less attractive. Another option: add a
             property to counter-reset or another property that
             changes scope
  TabAtkins: to descendants only instead of descendants & siblings.
  TabAtkins: Problem with :before is that it may not get created.
  dbaron: I like the new value or property idea
  plinss: Putting the :before rule with reset property doesn't
          trigger :before?
  TabAtkins: Nope.

  <zcorpan> "This specification does not yet define the CSS-specific
            rules for rendering li elements, because CSS doesn't yet
            provide sufficient hooks for this purpose."
  zcorpan: Question: is it possible with counter spec to specify how
           <ol> and <li> are supposed to work?
  TabAtkins: You can as long as nesting isn't observable.
  TabAtkins: Except for reverse
  TabAtkins: but if nesting is exposed somehow then the naive
             mapping is wrong and can't be done in CSS.
  zcorpan: I think we should make the counter spec usable by <ol>,
  TabAtkins: Yup.
  fantasai: Yup.
  TabAtkins: Shall we go with the idea of a new value or property
             that scopes only to descendants?
  <TabAtkins> ol > :first-child
  <zcorpan> including <ol reversed> (ideally)
  Florian: but we can just ol :first-child { counter-reset: blah }.

  [Tab draws a waaay better diagram]

  Scribe: fantasai

  Florian: So one proposal was use ::before if it exists, or
           :first-child of the list
  Florian: to reset the counter.
  TabAtkins: It works for HTML, but it is weird overall, because you
             have to be concerned with the first child who is being
  TabAtkins: Setting on the container is much cleaner.
  TabAtkins: So one proposal is to cut counter [...]
  TabAtkins: Better one from dbaron is we have some syntax for
             indicating on counter-reset that counter will only
             scope to its descendants.
  TabAtkins: The counter would then end its scope at the end of the
  Florian: Seems a lot cleaner, but worried it will be very obscure
           and nobody would know about it.
  Florian: Is it better to have a simple system with ::before or a
           complex system with lots of switches?

  Scribe: shane

  TabAtkins: I wouldn't have designed counters this way.

  fantasai: One use case that should work - sometimes you start a
            list, then close and want to continue later.
  <zcorpan> <ol start>
  dauwhe: This is super important for us.
  Florian: Can't just use a class?
  TabAtkins: You need to establish counter in ancestor.
  dbaron: dauwhe, does it sound OK if browsers implement list
          numbering using counters, you could do it by having a div
          higher up that contains all the lists you want to number
  dbaron: explicitly resetting list counter on that div, then
          removing on individual lists. Would this work for you?
  dauwhe: That makes sense to me and I think I can explain it OK to
          people too.

  TabAtkins: This is explicitly what we use in the flex algorithm.
  TabAtkins: Multiple OLs crossing sections that number
             subsequently, put a counter on body and use that one

  Florian: Either if we have a simple but surprising system, or a
           complex system, people aren't going to understand and
           will need to look at stack overflow.
  TabAtkins: Can put into UA stylesheet and make prominent in spec
  TabAtkins: if you're doing headings, do it like this, etc.
  Florian: Probably cleaner with complex but unsurprising system.
  fantasai: If it's a syntactic switch then it'll be in the spec.
  fantasai: People who are using counters are going to look it up.
            It'll be fairly obvious

  fantasai: so add a keyword to counter-reset?
  TabAtkins: We can't extend counter-reset. It's multi-valued
             without commas between each value.
  TabAtkins: Can't tell whether a keyword is a second counter or not.
  Florian: So multiple counters, might want to scope each one
           differently. So need a list in the parallel property too?
  fantasai: Can have a second property which does the same as
            counter-reset but with the other behavior. OR a property
            that switches the behavior.
  dbaron: Want other options too, in particular reversing.
  TabAtkins: Currently can't be expressed in the counter model.

  RESOLVED: Add new syntax to control counter scoping and consider
            reversing too. (Syntax TBD.)

  <dbaron> (Tab to propose syntax)
  <zcorpan> (This needs to be directly usable by HTML spec's UA
            stylesheet for <ol>, <ol start>, <li value>,
            <ol reversed>...)
  [discussion about resolutions, resolution reversion, and
  <dbaron> (and counter-resolutions)

Values and Units

  TabAtkins: Say you have a background image 'url(#svgfrag)'.
  TabAtkins: Clearly points to something local.
  TabAtkins: Once you absolutize the url
  TabAtkins: you notice it points to same doc, go find it,
             everything's cool.
  TabAtkins: But say you do push-state to update the URL, the page
             changes it's URL
  TabAtkins: we don't go an re-absolutize the images
  TabAtkins: (in all browsers, interoperably).
  TabAtkins: So that's an issue. pushState means the reference is no
             longer local.

  <zcorpan> history.pushState()
  <zcorpan> or insert a <base href>
  <SimonSapin> this is an inline stylesheet, right?
  <SimonSapin> <style> not <link>

  dbaron: Why didn't that change when the document's URI changes?
  TabAtkins: Because everyone absolutizes at parse time and nobody
             changes it.
  fantasai: Can't we fix it?
  TabAtkins: No. It's good behavior.
  TabAtkins: If the ref is relative to to the slash path then do
             pushState that just changes local position in doc tree
             would result in local references being probably wrong.
  TabAtkins: If you start out at and reference
  TabAtkins: then pushState to
  TabAtkins: then we're now referencing
   , which probably
             doesn't exist.
  TabAtkins: So don't want to update in this case.

  fantasai: This is super messed up. Could have 2 different refs to
            same target that point to different things because of
            statefulness of pushState.
  zcorpan: I think it's too expensive to re-resolve all the urls in
           the universe when a pushState happens.
  plinss: If you pushState to a new URL then you should be able to
          reload from that URL and get back to exactly the same state.
  TabAtkins: In practice doesn't always work, and can use middleware
             to fix the problem anyway.
  plinss: I'm not concerned about case where middleware masks a bug.
  TabAtkins: I don't think it's a bug that you should have to
             rewrite references on pushState.
  plinss: But it is a bug that you can't reload a pushState and get
          back to the same state.
  plinss: I want to see data that we can't fix that bug.
  TabAtkins: Someone should say we *can* do it first.
  TabAtkins: It's an HTML problem.
  plinss: It's a cross-spec problem really.
  zcorpan: From browser vendor's POV the burden of proof is in other
           direction. Won't risk breaking pages without data saying
           it won't break pages.
  plinss: If it was a minor change that's fine. But fundamental
          architectural issue so different stance.
  hober: Would love to see data on compat issue, but given that
         absent data implementors are unlikely to change, who's
         volunteering to collect data?

  TabAtkins: I want to move on to issue. Not absolutizing is bad for
             local references that become remote.
  TabAtkins: So e.g. pushState from to
    #svgFrag no longer resolves as
             local because the URLs don't match.
  TabAtkins: My proposal: '#' is a very clear indication that you're
             doing a local reference. So if a url is JUST a hashref
             then we store state that indicates the reference is
             definitely local, and never absolutize.
  TabAtkins: If we can solve the more general problem then we don't
             need to do this.
  plinss: Sounds like a hack on a hack.
  * glazou agrees with plinss
  [A general rehashing occurs. Rehashing. Hah]

  astearns: If there is a compat issue with fixing this the right
            way, isn't this going to trigger that too?
  TabAtkins: No. This definitely always wants to be local.
  Florian: But it's not clear for files because you don't know
           whether they want to be relative or relative relative
  hober: Are you proposing that hidden state be exposed to CSSOM? Or
         via syntax to explicitly opt in? Or via URL object?
  TabAtkins: Currently just if URL string starts with '#'. Can
             detect by asking for computed value because it should
             serialize back to just a '#' instead of abs value for
             round tripping purposes.
  plinss: In general, TAG is facing another issue where we need to
          assign additional information to a URL to make it useful.
          Tim hates this. Fundamentally URLs should be standalone,
          without magic. This is going to <elided> Tim.
  TabAtkins: We could introduce new function that is identical to
             url but only accepts local references
  TabAtkins: but that doesn't fix existing pages
  TabAtkins: or upon parsing this could computed value to local only
  plinss: Yuck.
  plinss: Shouldn't make an assumption based on presence or absence
          of parts of the url.

  TabAtkins: There's a couple of options; we need to fix it somewhere.
  TabAtkins: (A) get DOM to fix everything
  TabAtkins: (B) hidden state on urls
  TabAtkins: (C) new local-only url function
  fantasai: How is that better than fixing A?
  TabAtkins: Because A will break things
  TabAtkins: e.g. your URL is "foo.svg" and you pushState to
             something with a different URL segment then your page
             will break.
  plinss: But right now it'll break on reload anyway.
  TabAtkins: We should decide on (A) assume DOM will fix everything
             and make no change or (B) make *some* sort of change.
  fantasai: What about (D) try to get (A) to work and in the
            meantime do (B).
  fantasai: I prefer (D)
  astearns: Me too, but I don't know how fixing the actual problem
            is going to happen?

  hober: Comes back to: "who's going to provide the data"? Haven't
         heard any volunteers.
  fantasai: If you do it correctly, relative URLs aren't going to
            change unless you wanted them to change. If you're
            depending on the broken-ness then it's going to change
            and you'll need to fix your URLs.
  plinss: I'll file (A) as an issue with the TAG. It's bigger than

  astearns: Does anyone object to pursuing a temporary solution
            while that happens?
  <fantasai> Proposed resolution: Make local fragment URLs magically
             always relative; file issue against TAG to fix this
  Florian: (B) is a temporary solution that silently disappears if
           we fix (A) so it's better than (C)
  fantasai: yeah, agreed.

  plinss: I'd rather have a different function - i.e. (C)
  Florian: Why would you prefer a different function?
  plinss: So you can say what you mean. getElementByID should be a
          new thing, not the existing thing,
  plinss: and the parameter should be an ID, not a URL fragment.
  hober: I think esprehn's saying that functionally, fragment
         references currently are getElementByID.
  esprehn: Right. It's already live in that we can swap out elements
           and the reference updates.
  zcorpan: Special casing URLs with only a fragment already exists.
           Navigating special-cases fragment changes vs. other
  Florian: In this case we specialize fragment behavior to do the
           right thing. So fixing behavior in the subcase. i.e. like

  dbaron: One of the other cases for having something that isn't url
          function is to be able to move styles that reference an ID
          in a document into an external stylesheet.
  dbaron: We added an element() function as an image value. Is
          basically this.
  TabAtkins: element() might be a reasonable choice then.

  hober: This is a garbage fire. Browsers screwed up AND authors
         screwed up. (B) seems reasonable then but both plinss and
         dbaron have made reasonable arguments for adding (C) *as
  ChrisL: SVG has a concept of a URL that's restricted to the local
          document. Originally had idref but the TAG told us to stop.

  TabAtkins: Current proposal: Add hidden state to URL *and* make
             sure element() can be used to just refer to local
  hober: I'm a little unsure about expanding element() beyond
         existing use as an image source. Probably fine.

  ACTION: Peter Linss to file an issue against the TAG to fix the
          general pushState / url reference problem
  <trackbot> Created ACTION-769

  RESOLVED: Add hidden state to hash-reference-only URLs so that they
            can always resolve locally in presence of pushState
  RESOLVED: Adapt the element() function so that it can be used to
            refer to always-local references

  <br type=lunch>

Dael Jackson | 25 May 01:35 2016

[CSSWG] Minutes San Francisco F2F 2016-05-09 Part III: Media Queries, Sizing, Flexbox, CSS Containment [mediaqueries] [css-step-sizing] [css-flexbox] [css-containment]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.

Media Queries

  - Discussion around syntax for overflow (scrolling vs paged) MQ,
    and possibly having a multi-value MQ.
  - Discussed difference between returning false and unknown
  - Discussed the need for a way to truly negate a MQ to create
    two complementary code blocks, since (given unknown being
    different from false) the current syntax doesn't give that


  - RESOLVED: Intrinsic sizes that don't require layout to
              recalculate are treated as definite.


  - The decision on how to handle percentages will wait on use cases.
  - The group discussed how to handle layout when there's a column
      multi-line flexbox that's floating and has a column wrap.
      - There's a fast and performant and clearly broken and useless
          approach done by Chrome or doing actual layout as done by
      - People were uncertain which approach was best and concerned
          that whatever is decided would still work years down the
      - TabAtkins wanted more time to think about a solution, so the
          discussion was tabled.

CSS Containment

  - RESOLVED: Publish FPWD of css-contain-1 after edits on overflow



Scribe: dauwhe

Media Queries

  astearns: Let's get started.
  astearns: Overflow stuff isn't prepared yet, is there anything
  astearns: The other topic is flexbox, but we're waiting until 2:30.

  Florian: We can try to do MQs.
  Florian: One MQ thing is also about colors.
  Florian: Light-level media query?
  fantasai: We resolved to defer.
  Florian: Simon said that he might not like it at all.

  Florian: Since it's been in spec for a while, I'd like to hear the
  myles: First objection: fingerprinting
  myles: A website will know if I'm outside or inside.
  myles: Second is that it's an OS thing.
  myles: Third, OS has night mode that might interfere.
  Florian: For the 3rd thing, I don't think it would fight.
  Florian: Given the adjustments already made, are we in a mode that
           needs boosting?
  Florian: You have to take into account the display and the
  Florian: LCD would be different than e-ink
  Florian: so you can take into account OS stuff then.

  <fantasai> resolution on deferring light-level ^
  fantasai: Here's the resolution... move light-level to next level
            of MQ.


  TabAtkins: Overflow
  fantasai: I had action item for proposal.
  fantasai: I'll try on the fly.
  fantasai: The questions were:
  fantasai: there's a block and inline axis
  fantasai: can be scrolled or clipped
  fantasai: block can be scrolled, paged, scrolled and paged.
  fantasai: We had overflow inline and overflow block
  fantasai: but you don't care about everything
  fantasai: so you'd have overflow and can just ask about block
  fantasai: or do separate query for inline
  fantasai: so syntax would be superset of keywords.
  overflow: scroll | page | scroll-page | none |
            scroll-inline | scroll-block | clip-inline | clip-block

  dbaron: Don't know what you mean by overflow-inline.
  dbaron: Does it have two different values but matches either?
  Florian: It doesn't have a value, it answers yes or no.
  dbaron: All the features have a value.
  dbaron: Just because a spec is written a certain way doesn't mean
          the concept isn't there.
  Florian: If you include undefined, then yes
  Florian: some MQs always return false.
  dbaron: Either they have a particular value or no value.
  dbaron: I'm not totally against, but it's a little weird.
  fantasai: Can you specify them together?
  fantasai: Is the syntax going to be (writes on whiteboard)
  fantasai: <block> | <inline>
  Florian: Less risk by having one value then combining.
  fantasai: That works for me.
  Florian: Scroll pages is the ??? one?
  Florian: We can spend forever on bikeshedding, but this makes sense.

  Rossen: If you want to constrain to match only block
  Rossen: then having it match scroll and not scroll.
  fantasai: You can say (overflow: scroll) and (overflow:
  Florian: Between multivalue MQ and separate overflow-inline MQ.
  Florian: Either way you type the same words,
  Florian: which one is easier for impl, for extensibility.
  fantasai: They're both easily extensible.
  Florian: Having two properties is less work.
  Florian: MQ so far don't have multivalue.
  Florian: You may need to change your code.
  Rossen: Sure.

  fantasai: (writes) overflow: scroll | page | scroll-page | none
  fantasai: scroll-inline | clip-inline
  fantasai: scroll-block | clip-block
  fantasai: I just want this first set to work because those are the
            common cases.
  Rossen: What is scroll-page.
  fantasai: You can scroll but get new pages on forced breaks.
  Florian: Or can break on infinite scroll.
  TabAtkins: The presentation case is good.
  astearns: Do we do the top box on this level, do the rest later?
  fantasai: That's ok.

  esprehn: Who has scroll-page?
  fantasai: Presto.
  esprehn: Scroll and page seem obvious, but the others...
  TabAtkins: We had at least one implementation that had behavior of
  hober: That impl won't be updated for MQ.
  TabAtkins: But we know it's been useful to someone.
  esprehn: We're trying to spec someone's experience. What about
  fantasai: They page.
  TabAtkins: The user agent is the one answering these questions.
             flipboard can do whatever it wants as a web app.
  Florian: The inline direction is relevant to our user agent
  Florian: both scroll-inline and clip-inline are used.
  esprehn: It seems bad to define all these things here.
  fantasai: This is about whether fragmented or not.
  esprehn: What if there's an expando triangle at the bottom.
  TabAtkins: Give us an existence proof.
  fantasai: If you can do that on any page, it's effectively scroll,
  fantasai: you're not fragmenting.
  esprehn: I want clip.
  dbaron: That's a scrolling UI.
  fantasai: There's a continuous scrollable area and you can view it.
  dbaron: You can look at the other part of the layout, but you're
          not changing the layout.
  fantasai: If you have paging, it changes layout, because you have
            to space content away from the breakpoint. That's

  Florian: For inline, scrolling and clipping we understand
  Florian: but we don't have inline fragmentation because we don't
           understand what it is.
  Florian: The rest are things sensible UA's want to do
  Florian: why exclude them?
  Florian: If your UA doesn't do them, just say no.
  <dbaron> I think some UAs may have had table printing code that
           did inline-direction fragmentation
  esprehn: I think there's a lot of dead stuff in css
  esprehn: like a monochrome display with only green.
  esprehn: There's a matrix one.
  TabAtkins: Some versions of lynx need that.

  Rossen: What is your main objection?
  esprehn: Every new print person will want more.
  esprehn: It's an enumeration of possible user experiences.
  dbaron: It's an enumeration of the way the content can be laid out
          in css.
  Florian: The things that are not defined in css are not in this
  hober: Can we add scroll-page but make it at risk?
  fantasai: Just say no,
  hober: As a reader of the spec, I'd like to know that no UA does
  fantasai: But there's a decent chance there are some UAs
  fantasai: I don't think at risk makes sense.
  Florian: By not implementing it you are implementing it.
  hober: Just spec as returns false :)

  esprehn: What UA can only display the initial viewport?
  Florian: Digital signage.
  TabAtkins: Digital signage is currently bad about this.
  Florian: If you know your UA doesn't show overflow, then you need
           to know this.
  shane: How many pages do you expect will show digital signage?
  TabAtkins: There's a news site that's designed for both--web and
  TabAtkins: content is the same,
  TabAtkins: their content is amenable to MQ.
  hober: My understanding of esprehn's point is hinging on that.
  plinss: If you don't parse it you're ok.
  dbaron: MQs are intended to be more speculative than other stuff
          in the platform.
  dbaron: "are you doing this familiar thing, or might you be new"
  esprehn: I wish my toaster supported css.

  astearns: This is not sounding productive.
  Florian: Are we ok with having this in spec and not implementing?
  esprehn: I object to the fact that the platform has stuff you
           shouldn't use as an author.
  esprehn: I have to wade through a lot of useless stuff.
  Florian: We've removed some useless ones already.
  TabAtkins: We should do better with examples and education.
  TabAtkins: We can do more than the maximally useful.
  astearns: Do block overflow now and inline later.
  Florian: We know what we want to write, and someone wants to
           implement, why wait?
  astearns: Do we split into levels? or do we put the whole proposal
  astearns: I don't care. Straw poll?
  fantasai: I want to keep scroll-page.

  dbaron: Should none be called clip?
  fantasai: None triggers falsiness.
  TabAtkins: That's how MQs work.

  astearns: A straw poll. A: overflow: scroll | page | scroll-page |

  jensimmons: So we're doing things that no one wants to do now?
  astearns: This allows implementation later.
  myles: If it never gets hit, how do you know it works?
  myles: That's a recipe for untested code.
  dbaron: You write a query that says "do you have the feature"
  dbaron: Everyone returns false.
  dbaron: Later you can use it.
  TabAtkins: We wouldn't write code today
  TabAtkins: but if anyone does do it, the ability to discriminate
             is useful
  TabAtkins: and we know it's been done in the past or niche.
  TabAtkins: So it's reasonable.
  Florian: You can return unknown instead of false
  Florian: but then there's problems with boolean logic.
  Florian: If you know you're not doing it then say false.
  plinss: It doesn't help now.
  gsnedders: What happens if you give an unknown keyword?
  TabAtkins: It stays as unknown.
  TabAtkins: If it gets to top level it becomes false.
  Florian: Overflow (not scroll-page) is the issue.
  gsnedders: ah.

  jensimmons: You're interested in the inline things?
  Florian: Yes.
  Florian: We haven't implemented yet but it's in the plan.
  Florian: We're also thinking about scroll-page.
  Florian: As dbaron says, these are not theoretical UI modes, they
           are css layout modes
  Florian: and we know how they work.
  Florian: This is stuff we do in css today.
  Florian: We know what these things do.
  Florian: Not all of them are implemented in mainstream things.

  bradk: If we have A, what is purpose of third line?
  Florian: I don't understand it either.
  fantasai: Third line if you want to explicitly query block axis.
  fantasai: If you're scrolling does this query return both axis.
  fantasai: there are few question:
  fantasai: is it block scroll, or both, or either?
  Florian: Didn't used to be a problem.
  fantasai: For scroll-page, if you query the media type about
            scroll, it should probably say yes.
  TabAtkins: Can always return true for scroll.
  fantasai: We do not page.
  TabAtkins: Requiring negative query for common cases is not good.
  fantasai: Scroll page ua would want to fall under scroll.
  TabAtkins: Let's not over-think. Match one thing or another.

  Rossen: Back to straw poll?
  astearns: Do everything at once, or split into levels?
  fantasai: Option C: keep spec as-is, with overflow-block and
            overflow-inline as separate.
  Florian: overflow-block is too verbose.
  bradk: I like the way it is, it's explicit about which direction.
  Florian: People stopped doing  <at> media print, when they were talking
           about pagination.
  * gsnedders suspects most web developers will just keep using
               <at> media print…
  fantasai: We're breaking out paginated part of print, like for an
  TabAtkins: Webkit and chrome don't want to implement values they
             won't use in the future.
  esprehn: Because false and undefined are different, we'd still
           have to implement.
  fantasai: You'd still return false on tactile.
  esprehn: So your binary has to contain things you don't support.
  Florian: You will always have to do that with MQ.
  esprehn: That's why I'm objecting to shipping speculative stuff.
  Florian: They're both on my road map.
  plinss: If any UI shipped, would you implement the MQ?

  dbaron: The fact that the new boolean thing isn't right is a
  dbaron: It doesn't do what we want to do.
  dbaron: We want to make it possible to "if this matches, do stuff,
          if not do other stuff"
  dbaron: If it's unknown neither block run
  dbaron: People want "or else"
  dbaron: and the old MQs give you that, well it fails at a higher
  plinss: Let's put an else rule in MQ
  plinss:  <at> else.
  hober: In a world where some browsers return unknown
  hober: you have to write rule so unknown ends up false.
  hober: Will be in practice indistinguishable.
  dbaron: Unknown and false behave the same
  dbaron: not unknown and false behave the same.
  dbaron: If you're using the not to be else.
  dbaron: Maybe MQ need a syntax for is this thing supported in MQ.

  gsnedders: Often you can make an assumption... more likely scroll
             than page
  gsnedders: it's probably going to be right.
  Florian: You write your non-conditional code for what is most
           probable and then test.
  dbaron: Having to write non-conditional code and then override is
          a huge pain.
  <fantasai> +1 to dbaron
  Florian: The problem with else.
  Florian: we need syntax that makes the else apply in things that
           don't support it.
  TabAtkins: This is something that doesn't transition well.

  jensimmons: Do we need to allow MQ in  <at> support?
  jensimmons: If you support foo, then I'll ask some questions about
              whether foo is supported.
  gsnedders: It makes sense to treat MQ separately from  <at> support
  dbaron: It's useful to have is a MQ supported so you can used and
          and or
  dbaron: is it supported AND is it true
  dbaron: you keep the unknown.
  jensimmons: What if they don't support the test and the feature?
  dbaron: Then it doesn't work.
  dbaron: Just like  <at> supports.
  TabAtkins: We can explore that.
  gsnedders: Supports is better than  <at> else.
  fantasai: We should make it easy to see if this is supported and
            true, or unsupported or false.
  Florian: Supported and true is good.
  fantasai: You need the opposite of supported and true.
  dbaron: you could have a function that captures the unknowns
  gsnedders: can we call it supports
  <jensimmons> Can you put a media query inside a feature query?
  <jensimmons> (currently)

  ACTION: TabAtkins to look into supports on MQ
  <trackbot> Created ACTION-770

  <dbaron> The function is, I think, known-and-true()

Percentage sizing issues

  astearns: We're talking about percentages.
  fantasai: Bigger one is filed against grid and abspos.
  fantasai: The thing Christian and Igalia folks wanted answered
  fantasai: this is what we want to tackle first.
  fantasai: Everything else depends on this.
  TabAtkins: I can summarize;
  TabAtkins: resolving % on children when container size is
  TabAtkins: for float that shrink-wrap, if we have child 50%.
  TabAtkins: We will do normal shrink, then child will be 50%
             against that.
  dbaron: Intrinsic width is separate from layout.
  dbaron: Intrinsic width doesn't know %.
  dbaron: In layout you have input width, it takes that.
  dbaron: It's interoperable across lots of things.
  fantasai: It's undefined in 2.1.
  dbaron: shrink-wrap is undefined in 2.1.
  TabAtkins: Now it says % is never resolved, we want to change.

  fantasai: If you do same in height, then % are treated as auto.
  fantasai: If you have the same situation in height axis, that
            percentage is not resolved, is treated as auto.
  fantasai: So we have an inconsistency, how will we resolve?
  fantasai: Which parts of flex and grid do we make consistent with
            2.1 width.
  TabAtkins: These calculations happen separate from layout.
  TabAtkins: You need to run real layout to figure out height.
  cbiesinger: I like the principle.
  cbiesinger: Width calcs should require layout
  cbiesinger: for intrinsic size calcs.

  fantasai: In css 2.1 we didn't run into this.
  fantasai: Orthogonal flow breaks the assumption of width input
            height output
  fantasai: then you have to perform layout to find intrinsic size.
  fantasai: Grid and flex and multicol and writing modes allow
            switching of the axes.
  fantasai: That's the complication.
  fantasai: And we've tried to make flex and grid consistent.
  fantasai: Right now the axes are not consistent in block layout.

  ojan: To be fair, there are other ways in which flexbox treats
        height and width differently.
  Rossen: Not really.
  Rossen: If you assume all you have is flexbox.
  Rossen: Can we make it symmetric?
  Rossen: When you hit it, you are bound to do this measuring.
  Rossen: For flexbox and grid, their measuring should be symmetric.
  Rossen: How do you deal with block layout when there are flex or
          grid heights.
  Rossen: Is there a reason we need to change anything?
  Rossen: I don't think there's a need.
  dholbert: This is about percent on something that happens to be in
            a flex container.
  dbaron: Some of the issue is that sizing is attempting to define
          for block.

  TabAtkins: We can special-case as appropriate, but right now
             they're not correct.
  TabAtkins: If we do adopt this, right now we don't allow
             intrinsics to be definite.
  TabAtkins: If we correct for float and make a general principle.
  TabAtkins: Then min-sizing are definite.
  dbaron: Things for floats are true for abspos,
  dbaron: You need a mechanism for when things that were indefinite
          are definite.
  dbaron: Percentages inside table cells for example.
  TabAtkins: It's not hard to have in spec, in this case this length
             is indefinite.

  TabAtkins: Just trying to figure out what default should be.
  TabAtkins: If we define that intrinsic sizes are considered
             definite by default, then that fixes our issue.
  TabAtkins: We can then simply text in flexbox.
  Rossen: What would be a simple example?
  TabAtkins: Treat intrinsic sizes as definite when they don't rely
             on layout, by default.
  TabAtkins: Shrink wrapping would be definite for resolving
             intrinsic sizes on children.
  TabAtkins: If you say height: min-content that requires layout, so
             would be indefinite.
  astearns: Any objections?

  RESOLVED: Intrinsic sizes that don't require layout to recalculate
            are treated as definite.


Percent Sizing

  TabAtkins: This will be covered by general sizing behavior.
  astearns: Are we going to republish?
  dholbert: Should we reopen percent padding discussion?
  dholbert: Would be useful before we republish.
  dholbert: We have several more bugs this week.
  dholbert: Currently spec says browser decides.

  TabAtkins: If we want to start on this I have numbers.
  TabAtkins: People using percentage in margin or padding: .035%.
  TabAtkins: This is any usage, including usual hacks.
  dholbert: Most people using margin/padding are expecting
            traditional block behavior.
  TabAtkins: Nobody cares and we should do what is consistent.
  tantek: There's different opinions on what is simplest.
  dholbert: I want to change.
  dholbert: I want to see if Microsoft is still concerned.

  jensimmons: If this group that thinks it's a rare use case that
              people use percentage in margins, you're wrong.
  jensimmons: Every person using responsive web design uses this.
  jensimmons: Using best practices
  jensimmons: every single person is using percents in margins and
  TabAtkins: Our calculations were looking for percentage margin on
             a flex item.
  dbaron: A percentage of what.
  jensimmons: The relevant is what percentage of people using flex.
  ojan: It's 11%.
  ojan: The most useful thing would be examples.
  ojan: The question is does it resolve against width or height.

  tantek: If you were to use flex in responsive design, would you
          use percentage margin/padding?
  tantek: If the answer is yes, then I'd ask what your expectations
          would be.
  TabAtkins: Beyond bug reports asking for block behavior.
  tantek: There are lots more new authors, and simplifying model for
          them is more important than maintaining past behavior,
  shane: Support for responsive design is separate from backwards
  jensimmons: Are people going to need to use percent in flex?
  tantek: It's an orthogonal question.
  ojan: Maybe jen can come back with examples, and we can discuss.
  ojan: And it doesn't sound like MS has changed their behavior.

  astearns: Anything else for flex?
  TabAtkins: That's all we needed.

Running layout to compute intrinsic sizes in the width axis

  TabAtkins: There's one more.
  TabAtkins: Running layout to compute intrinsic sizes in the width
  TabAtkins: Two chrome implementations have run into this;
  TabAtkins: have a column multi-line flexbox
  TabAtkins: that you're floating,
  TabAtkins: it has column wrap.
  TabAtkins: To find width of column wrap flexbox you need to do
             real layout
  TabAtkins: and that's problematic.
  TabAtkins: Edge does this correctly.
  TabAtkins: Chrome does not.
  TabAtkins: So things are clearly broken from authoring perspective
  TabAtkins: but it's performant and consistent.
  gregwhitworth: We brought this up two years ago.
  gregwhitworth: In some cases you do want to do actual layout.
  gregwhitworth: I think it's worth taking the effort to do it in
                 performant manner.
  TabAtkins: So performant easy stupid one? or the harder one that's
  esprehn: Doesn't servo do this in parallel?
  esprehn: So they would object.

  fantasai: This problem exists for a lot a things in css
  dbaron: Only things from the past few years.
  fantasai: Orthogonal flows have existed for awhile
  TabAtkins: The similar examples that work are multicol
  TabAtkins: but flex can have different widths in column wrap.
  fantasai: But you need to know how many columns in multicol,
            so it's the same problem.
  iank: This is if auto-width.
  <fantasai> First draft of CSS Writing Modes was published in 2012.
             It said that logical heights are sized to fit the

  Rossen: Where are you going with this?
  Rossen: Are you proposing we allow layout-based measuring?
  TabAtkins: Yes, otherwise you can't float a multi-col flexbox
  TabAtkins: If other browsers are not willing to do it...
  <SimonSapin> Yes this is all a big problem for Servo and I don’t
               know what to do about it :(
  plinss: It doesn't matter if you're performant if you're always
          delivering the wrong answer.
  ojan: I feel torn. There's the obviously correct one... in chrome
        we won't be able to do this anytime soon.
  cbiesinger: We are considering a rewrite of our layout engine.
  ojan: But this is two years away.

  dbaron: A few years ago, intrinsic width was a rather clean concept.
  fantasai: That no one understood.
  dbaron: There was some architectural sense to it.
  dbaron: I'm concerned about what's been happening to it
  dbaron: and how it's tying web tech to current implementations.
  dbaron: Like how Servo has something that works with stuff two
          years ago, but not current stuff.
  dbaron: Especially as it aligns with how processors are evolving.
  Florian: The number of cores is stagnating.
  esprehn: This isn't the right forum to discuss if Servo is the
           right thing.

  Florian: But doing this doesn't invalidate Servo.
  Florian: We shouldn't make everything parallelize-able even at the
           expense of author expectations.
  dbaron: Servo parallelizes that breaks up the tree.
  dbaron: Start at top, pass info to leaves, return other info up.
  dbaron: There's a cost to passes.
  dbaron: Pass one moves information
  dbaron: pass two is the layout
  dbaron: more passes are costly.
  SimonSapin: What dbaron just said.
  SimonSapin: In some cases we already need to sequentialize layout,
              like floats and counters.
  SimonSapin: Doing intrinsic width requiring layout is probably not
              impossible without throwing it all away.
  SimonSapin: I don't know yet how complex this will be.

  TabAtkins: We might allow the JS plugin for sizing to rely on
  iank: This is a houdini topic.
  plinss: There are a lot of other layout problems that css hasn't
          done yet
  plinss: and they mostly fall into this category
  plinss: and if we cut this off now, it's very short-sighted.

  TabAtkins: IE is ok, we're torn, Servo doesn't like it but can
             slow-path it.
  TabAtkins: Authors 100% have a preferred behavior.
  dauwhe: And w3c has principles to answer this question.

  astearns: Is there a gecko consideration?
  dholbert: It will take some work
  <TabAtkins> Test case:
  <TabAtkins> ^^^ if the dark green expands to fill under both lime
              boxes, you do layout to calculate intrinsic sizes

  plinss: Authors will always be able to blow things up.
  dbaron: We also want web performance to be predictable.
  plinss: I remember when it took 30 seconds to resize 4 levels
          of nested tables.
  plinss: If we're not giving authors what they need, what are we
  plinss: The authors expectation is to do the right thing.
  shane: Yes.
  plinss: They're giving a bullshit answer for performance.

  gregwhitworth: 99% don't know the predictability that you know
                 because you work on the engines.
  dbaron: And floats were defined for something other than what
          people are using them for.
  gregwhitworth: Had we addressed this two years ago... IE11 laid
                 out floats to get size.

  gregwhitworth: I do want to back what plinss said.
  gregwhitworth: In case of conflict, consider users over authors
                 over implementors over specifiers over theoretical
  dbaron: There was no consensus for layout, and there was consensus
          for doing what we knew how to do.
  gregwhitworth: Can we start, though? I know there's a burden of
                 work. But for the authors and the platform, we need
                 to do this in performant ways.
  fantasai: This is even more clear than the float case.
  dbaron: I think this is a rewrite the layout engine thing.
  dbaron: We don't have the resources to do this.
  dbaron: There might be other ways to fix the broken behavior.

  (looking at test case link above)
          <-- content occlusion

  TabAtkins: The spec mandates edge's behavior
  TabAtkins: so do we leave it alone, or do the stupid fast thing?
  dbaron: The way I'd look at describing an intrinsic width
          mechanism to do this
  dbaron: a column wrapped flexbox is an orthogonal flow.
  dbaron: So if you have one of those things floating, you compute
          intrinsic heights, then do width as output.
  cbiesinger: Blink doesn't deal with that, doesn't need height
              until layout.
  dbaron: I think that's looking at it backwards.
  dholbert: In the test, there's a set width and height on the flex
  dholbert: If it was text you'd have to do layout.
  dbaron: That depends on what heights or widths are specified.
  dbaron: If there are few enough, you're not going to get a
          sensible layout anyway.
  gregwhitworth: What do you mean?
  dbaron: You're not going to like the results.
  gregwhitworth: You're assuming everything is auto.
  dbaron: Right.

  dbaron: Part of the problem that led us into this is not treating
          the orthogonal flexbox as orthogonal.
  TabAtkins: Possibly.
  dbaron: I think some of that weird behavior is from the same
  TabAtkins: The weirdest behavior is to avoid t-shaped documents;
  TabAtkins: like auto height of 100vh for mixed direction things.
  TabAtkins: A column flex box should not have those fix-up things
             that apply
  TabAtkins: to text.
  TabAtkins: There might be some stuff from orthogonal flows we
             could import
  TabAtkins: but the general case won't give us good results.
  dbaron: 'cause that's the way they flow
  dbaron: Flexbox today has so many patches to get good results.

  <dholbert> FWIW, here's a testcase with no specified heights on
             the items, and with multiple lines of text in each:
  <dholbert> Edge gets that "correct" (per authors' expectations) --
             no overflow ^

  fantasai: I don't understand what you mean by “act like orthogonal
  TabAtkins: They do height first, then width.
  cbiesinger: This is different because it's doubly orthogonal.
  dbaron: It's two layers of orthogonal nesting.
  dbaron: Getting orthogonal stuff only makes sense with widths.
  fantasai: It won't wrap unless there's a constraint on the
  fantasai: In the case of writing modes, we impose the 100vh rather
            than calculating as max content
  fantasai: but column wrap flex uses max content.
  dbaron: The problem is not that you want width on layout, but you
          want the auto size calc for column wrapping flexbox in
          that dimension
  dbaron: rather than in the other way.
  gregwhitworth: However you want to solve it is fine.
  dbaron: I would really like intrinsic widths to be not dependent
          on layout
  dbaron: and I think there are good ways to do that;
  dbaron: except for floats
  dbaron: except for block formatting contexts that contain floats
          and texts.
  TabAtkins: I'd be happy to defer
  TabAtkins: until we can prepare some ideas.
  TabAtkins: I don't want to put dbaron on the spot right now.
  TabAtkins: I want more time to think.
  dbaron: OK.

  astearns: The original question is do we want to do anything
            before we publish flex
  astearns: and the answer is no, we publish.
  astearns: So let's take a break
  astearns: we do need some topics from tue and wed.

  <break duration="NaN">

Scribe: fantasai

CSS Containment

  Florian: Why don't we have a public working draft?
  TabAtkins: We were waiting on layout and ?, but I'm cool with that.
  dbaron: I have an open bug.
  dbaron: On the title of the spec.
  dbaron: Should be level 1 rather than level 3.
  TabAtkins: There's also an open issue about overflow: clip
  TabAtkins: Can I publish a WD of css-contain-1?

  RESOLVED: Publish FPWD of css-contain-1 after edits on overflow

  <dbaron> BTW, the reason I noticed the level being 3 rather than 1
           was that we submitted *tests* for the spec, and Shepherd
           complained that they weren't associated with the spec!
  <dbaron> (And that one bug report was based on having it on for
           nightly & aurora but off for beta & release.)

Control Characters

  <dbaron> gregwhitworth, fwiw, we have one bug report on visible
           control characters,

  TabAtkins: So, on control chars.... we lost the data
  TabAtkins: It was on Emil's server, but then he shut it down and
             it's gone.......
  gregwhitworth: {///}
  gregwhitworth: We're not surprised people are running into problems.
  gregwhitworth: That's why we wanted to announce and do a
                 coordinated PR push.
  gregwhitworth: And why we want everyone to have it behind a flag,
                 so that we can coordinate a release.

Dael Jackson | 25 May 01:35 2016

[CSSWG] Minutes San Francisco F2F 2016-05-09 Part I: Flexbox, Box Alignment, Grid [css-flexbox] [css-align] [css-grid]

  These are the official CSSWG minutes.
  Unless you're correcting the minutes,
 Please respond by starting a new thread
   with an appropriate subject line.


  - RESOLVED: Issue 1 the text for a11y is accepted.

Box Alignment

  - RESOLVED: Apply justify-content to columns in multicol elements
  - RESOLVED: Make “smart safe” alignment the default for handling
              overflow; but put at risk with a note saying to
              contact CSSWG if there is a problem regarding compat.


  - RESOLVED: Keep the spec the way it is in regards to issue #3
              (Abspos item placement in degenerate grids)
  - RESOLVED: Keep spec as is in regards to issue #24 (Drop empty
              tracks at ends or also in the middle?)
  - Rossen was tasked with reviewing issue #39, missing 'auto'
      changes for span>1
  - RESOLVED: subgrid proposal accepted in the at-risk section

===== FULL MINUTES BELOW =======


  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Daniel Glazman, Disruptive Innovations (only IRC)
  Daniel Holbert, Mozilla
  Jihye Hong, LG Electronics (only IRC)
  Koji Ishii, Google
  Brad Kemper, Invited Expert
  Ian Kilpatrick, Google
  Chris Lilley, W3C
  Peter Linss, HPI
  Myles Maxfield, Apple
  Edward O'Connor, Apple
  Simon Pieters, Opera
  Florian Rivoal, Vivliostyle Inc.
  Andrey Rybka, Bloomberg
  Hiroshi Sakakibara, Beyond Perspective Solutions
  Simon Sapin, Mozilla (only phone)
  Jen Simmons, Mozilla
  Geoffrey Sneddon, Invited Expert
  Alan Stearns, Adobe
  Shane Stephens, Google
  Lea Verou, Invited Expert (only IRC)
  Greg Whitworth, Microsoft

  Dael Jackson, Invited Expert
  Hyojin Song, LG Electronics

Scribe: gregwhitworth


  fantasai: As we mentioned, pretty much everything is fixed.
  fantasai: We asked for people to review issue 1 and 3.
  fantasai: We're asking for official resolution of those two, the
            rest are editorial.
  fantasai: You're happy to review them. After resolving we would
            like a CR.

  fantasai: Anyone need more time for issue 3?
  dbaron: The resolution for issue 3, is it independent of percent
          sizing with intrinsic widths?
  fantasai: Good question.
  astearns: That is one thing that does not have a time slot, that
            can be breakout session.
  dbaron: I just want to make sure that we're not tying this to
          something that isn't compatible with the web.
  fantasai: This one I believe is about the intrinsic minimum sizes.
  florian: Is it flex specific?
  dbaron: No.
  florian: If there is a side convo please try to include me.

  hober: If the dependency graph includes the percentage issue, then
         we should resolve that first.
  dbaron: I'm not saying it does, I'm just asking.
  fantasai: I'm not sure... yeah I think there is somewhat a
            dependency so we should resolve on those together.

  fantasai: So issue 1: a11y wording.
  Rossen: Do we have text for issue 1?
  fantasai: Yes.
  <fantasai> Note at the bottom of
  dauwhe: Are the a11y wg happy with it?
  fantasai: Cynthia is, she reported it.
  Rossen: I think the wording is exactly how we decided it, we
          should be fine. I'll follow up with Cynthia and close the
          loop with Richard and the rest of the WG.

  RESOLVED: Issue 1 the text for a11y is accepted.

Box Alignment

Application of justify-content to multicol columns

  fantasai: Tab and I went through the spec and updated the baseline
            alignment stuff to the best of our ability.
  fantasai: Anyone that's interested please take a look at it.
  fantasai: One open issue is whether the justify-content property
            applies to column boxes.
  fantasai: The other is the default value of overflow.

  fantasai: The justify-content property: in grid it justifies the
            tracks and in flex it justifies the flex lines.
  fantasai: [gives example of how justify-content works]
  fantasai: The goal of this spec is to allow alignment to work for
            all layout models.
  fantasai: Should justify-content apply to the columns or not?
  TabAtkins: No - justify-content can't because it applies to one
             line of things.
  florian: It sounds interesting, but do we have any wiggle room?
  fantasai: We can say that the normal value is doing what multicol
            already does,
  fantasai: for blocks it does nothing for them.
  florian: It sounds interesting to me.

  dbaron: It still doesn't make sense to me why it doesn't apply to
  TabAtkins: There is only one flow of stuff, so you can't justify
             its items - you can justify self.
  fantasai: If you think in terms of flex, block is like having one
            flex line.
  fantasai: There is no line in a block.
  dbaron: I was confusing justify-content and justify-items.

  jensimmons: If you specify the width of the col at 200, if we
              change this would you be able to do this and add the
              power to keep it at 200 and distribute from that fixed
  fantasai: Yes, this adds power to multi-col.
  florian: We cover step sizing a little bit later.
  dauwhe: This makes sense.
  TabAtkins: The mechanics are all there, this just allows you to
             control those gaps.

  RESOLVED: Add justify-content to multicol

  florian: Now we have column rules in the middle of column gaps
  TabAtkins: just like grid the things on the side are not gaps

default overflow-alignment value

  fantasai: The next issue is the initial handling of
  fantasai: We have safe and unsafe keywords, e.g. with 'unsafe'
            if you say center it will absolutely center it even
            if that causes it to overflow both sides, so the 'safe'
            keyword restricts overflow to the end side.
  fantasai: But a lot of times what you really want is true
            centering, except you want to keep it inside of the
            scrollable region.
  fantasai: The user wants to be able to see the content and they
            should be able to get to the content.
  fantasai: The initial behavior we're proposing is to do the unsafe
            behavior up until you would overflow the unscrollable
            container and then switch to the safe behavior.

  dbaron: That is very expensive on the layout engine.
  dbaron: I would prefer for people to have to ask for the slow path.
  fantasai: The people that need this won't know they'll need to
            change this. So it won't be useful as a default.
  fantasai: Only if you have overflow do you need to re-layout this.
  dbaron: I don't buy that there isn't overflow the majority of cases.
  dbaron: We can't change the default for block.
  fantasai: Block already does safe alignment.
  fantasai: This is all new stuff.
  fantasai: The only legacy is flex box.
  fantasai: Once this spec is implemented it will apply to
            everything and will only work if you set the alignment

  esprehn: I want to talk about the feature.
  esprehn: Someone showed a layout where the content is
           inaccessible, we need to solve it.
  dbaron: I prefer safe rather than true for that reason.
  esprehn: The example we had was a video in an iframe and the top
           was cut off and you could only scroll down.

  dbaron: A lot of layout issues deal with how a parent deals with
          its children.
  Rossen: Once you start nesting you're going to have very bad
  Rossen: This sounds like a weird position: sticky-ish.
  TabAtkins: This is still scrollable and only goes back if you
             overflow out of your scrollable bounds.
  dbaron: I agree with Rossen.
  Rossen: The benefit of sticky, you can keep it on the compositor
          and not re-layout.
  shans: This is about the negative bounds, not the scrollable region.
  Rossen: This is how I understood it, if you begin layout and you
          center align some items you start overflowing you have to
          redo layout to fix it.
  shans: On resize you re-layout anyways.

  fantasai: [draws a diagram]
  fantasai: [explains drawing]
  fantasai: This is all about the scrollable region, when the
            shifting occurs and it's outside the scrollable bounds
            this will change the box's alignment position to allow the
            content to be visible.
  fantasai: If you have a box that is a flexbox and it has a flex
            item that will have an item that goes into the
            unscrollable area then you flag it.
  fantasai: This only triggers when you have overflow in the
            scrollable direction.
  florian: Is this a third value?
  florian: Yes it's a third value.
  TabAtkins: It's kinda safe.

  zcorpan: You want this to happen in any direction right?
  fantasai: Yes.
  dholbert: This will affect any container with any alignment props
  fantasai: I think you could probably optimize this mostly away.

  dbaron: I think in theory that's fine, but it will take 10 years
          to find all the bugs.
  fantasai: We would like to put it in the spec and put it at risk,
            we don't expect it to be implemented soon.
  fantasai: Our content dependency is with flexbox.
  fantasai: The change in behavior may look a little bit worse on
            some pages, but for pages (like esprehn's example)
            where users can't scroll to see the content, this will
            fix those pages.

  bradk: Why not just make it so that you can scroll to the content?
  TabAtkins: That's the idea.
  hober: I don't want an infinite scrollbar because someone
         positioned something way out on the left for cargo cult
         a11y reasons.
  dbaron: What UI do you do when the scrollbar position is somewhere
          random in the middle?
  bradk: In a non-perfect world it seems like a good solution.
  dbaron: I looked into implementing it about 10 years ago and
          realized that it was too much of a compat risk.
  zcorpan: It would need to be opt in.
  TabAtkins: People use negative margins to hide stuff off the start
             edge of the document.

  fantasai: Any other comments?
  dholbert: Maybe an idea to work out later, but relpos/abspos would
            need to be taken into account.
  Rossen: The point is you should not start in a positive, safe will
          take you to the origin of that box, we don't want to move
  fantasai: We'll make you less unsafe until you're safe.
  florian: If you make this the default and at risk, please be clear
           in the spec what to do if you're not willing to implement

  TabAtkins: We still need a name.
  Rossen: un-safe-ish
  Rossen: scrollport

  fantasai: Does that sound like a reasonable plan?
  TabAtkins: Default to unsafe and put it at risk.

  dbaron: What happens to flex?
  fantasai: It will cause a behavior change where items are aligned
            such that they are not fully within the scrollable area.
  fantasai: This will probably fix more pages than it breaks.
  dbaron: I'm not sure I buy that.
  fantasai: But it only affects things that are aligning items into
            unscrollable regions.
  esprehn: Every time we change flex, we get yelled at - let's
           change and see how loud the yell is.
  hober: Also put a note that if you change and get yelled at let us

  RESOLVED: Put it into the spec, put at risk with a note saying to
            contact specs if you hear from authors regarding compat.

  <dholbert> fantasai/tab: we'd need to also be sure this
             "scrollsafe" alignment thing would interact nicely with
             layout containment
  <dholbert> In particular, layout containment probably needs to
             block aligned things from finding their nearest
             scrollable ancestor
  <dholbert> (for the purposes of this keyword)
  * fantasai likes the name scrollsafe :)

  fantasai: We'll publish next week.
  fantasai: Probably.

  dbaron: How much do we need to add to custom layout to make that
          work in Houdini?
  Rossen: Not much I think, you would need to add the origin and
          it's nearest ancestor.
  Rossen: You're always avoiding the origin for scrolling purposes.
  iank: I'm trying to catch up
  dbaron: I think if the nearest scroller is in another writing mode.
  Rossen: It still has an origin.
  dbaron: OK, you're right.
  Rossen: It's implementable.
  Rossen: Now that I understand it, it's not that scary.

  <iank> This seems fine for Houdini at a first glance, in your
         constraintspace at the moment you know at which point
         you'll trigger a scroll, and can adjust off that; but I'd
         have to have a little more of a think.



abspos items in degenerative grids (Issue 3)

  TabAtkins: We have a couple things that we need approval first.
  TabAtkins: Abspos items in degenerative grids.
  TabAtkins: The question here was what to do when you have a grid
             with no tracks whatsoever and how to place abspos items
             as a result; they care where the grid is.
  TabAtkins: There is no grid items, just some abspos and the grid
             has one grid line but no tracks, where should this line
  TabAtkins: The spec says it's against the start edge in both axis.
  astearns: Does anyone have any issues?
  astearns: Any objections?
  hober: What do the implementations do?
  TabAtkins: Don't know.

  RESOLVED: Keep the spec the way it is in regards to issue #3

Repeat function with auto-fit and auto-fill keywords (Issue 24)

  TabAtkins: The repeat function with auto-fit and auto-fill keywords.
  TabAtkins: If you have 1000px to work with and auto-fit with 10
             tracks it will adjust accordingly, with auto-fill and
             you don't have enough columns it will drop them.
  TabAtkins: Which columns should you drop?
  TabAtkins: These columns in the middle are not being used, do you
             drop them?
  TabAtkins: We don't have a strong opinion on this, currently it's
             defined at the end.
  fantasai: We spec it currently based on what's implemented.

  jensimmons: Correct me if I'm wrong, I want empty columns in the
              middle and they don't want them to go away.
  fantasai: No this is for the auto-fill not auto-fit within the
            repeat() syntax.
  jensimmons: I just want to get what I've defined.
  fantasai: We'll do that,
  fantasai: But sometimes when you want to center columns and that
            contradicts with the amount of columns available, do you
            drop the tracks at the end and middle, or just the end.
            So we have an 'auto-fit' keyword to allow for that option.

  fantasai: Can anyone come up with a use case and behavior that
            people prefer?
  TabAtkins: Unless anyone has any strong opinion, we'll keep it the
             way the spec is.
  TabAtkins: Which is to drop all empty tracks.
  dholbert: The counterintuitive part is you can have something in
            col1 and col10 and then remove all the empty ones when
            you wanted them apart.

  RESOLVED: Keep spec as is in regards to issue #24

Missing 'auto' changes for span>1 (Issue 39)

  TabAtkins: The counterintuitive part is why you would ask for auto
             generated rows and then explicitly set them into cols.
  fantasai: We need very competent people to take a look at this one.
  astearns: Anyone?
  TabAtkins: We think the spec is correct, but we would like for
             someone to take a look.
  Rossen was voluntold.

  ACTION Rossen to review issue 39 of the grid spec
  <trackbot> Created ACTION-768


  TabAtkins: The previous position on subgrid was complex so we
             removed it. That said, there are use cases that can't
             be done in current grid.
  TabAtkins: So we've put together a much simpler proposal that
             covers the majority of use cases.
  fantasai: Here's the feedback we got on subgrid:
  <jensimmons> Rachel Andrew on subgrid, her response:
  fantasai: What are the things we need to address and how simple
            can we get it?
  fantasai: There were things we could get rid of, e.g. the subgrid
            auto sizing itself based on its contents.
  fantasai: So now you can't have any overflow tracks in the subgrid.
  fantasai: You can have overflowing content however (due to sizing),
            so they are still scrollable.
  fantasai: It won't affect the sizing of the parent grid however.

  <fantasai> Current proposal -
  TabAtkins: [shows example of the subgrid]
  TabAtkins: You declare an item to be a subgrid by giving it
             display: subgrid
  TabAtkins: This makes it a grid container but grid-template-
             columns/rows do nothing on it.
  TabAtkins: The children on the subgrid position themselves on the
             parent's grid.
  TabAtkins: The subgrid still lays out.
  TabAtkins: The margin/padding/border they get applied accordingly
             magically to apply the declared amount.

  florian: I assume this does the right thing no matter the writing
  TabAtkins: Yes.
  TabAtkins: It works the same way in nested subgrids.
  TabAtkins: You cannot get implicit tracks from the subgrid.
  florian: Can you use display: contents?
  TabAtkins: Sure, if you don't need a wrapper at all, then use
             display: contents.
  TabAtkins: You can't set grid gaps on a subgrid.
  florian: Anyone implementing grid not implementing
           display: contents?
  TabAtkins: We plan to, but will take awhile because we need to
             refactor a lot of code. FF has an implementation of it,
             webkit has  a prototype I think.
  florian: I'll write a blog post,
  florian: to convince everyone to implement display: contents.

  TabAtkins: That's the proposal.
  TabAtkins: Does the WG feel this is a good direction to with?
  TabAtkins: Overflow still applies.

  astearns: You were going to go over the single dimension case that
            this doesn't support.
  TabAtkins: Right.
  TabAtkins: Let's say you have a subgrid and your parent is 2x2
             square but you don't care about the rows of the
             parent's grid,
  TabAtkins: and you don't know how many rows itself will have.
  TabAtkins: This particular case is easy to hit with HEADER,
             CONTENT, FOOTER and then you want to fill in the
             content with your catalog items.
  TabAtkins: However, this makes it very complicated to handle.
  TabAtkins: The case is relatively small, and you can use a nested
             grid to allow for this so long as track sizes are not
  TabAtkins: If people demand a lot of this we may try to address it
             in the future.

  Rossen: By current subgrid proposal, this is not possible?
  TabAtkins: Yes, it can't work.
  Rossen: Good, I think this keeps it quite simple and keeps the
          mental model of the grid intact and symmetric.

  florian: Have you heard from the authors?
  fantasai: Yeah, I think this addresses the majority of the issues.
            Wanting to interweave the subgrid lines with the
            parents lines is very hard, and is not covered here.

  fantasai: There is an issue we marked, subgrid only takes affect
            if it is a grid item and the grid-template properties
            are set.
  fantasai: This gives us an extension point that allows us to use
            subgrid to ensure that the grid properties are set to
            none which they don't affect and later may affect it in
            the future it could break it.
  fantasai: The goal of adding the condition is so that the grid
            WILL break so that we can improve subgrid later.
  astearns: What do you do in this case then?
  fantasai: Maybe just treat it as block.
  dbaron: You're intentionally making it not work unless things are
          set for extension later then you should say so it in the
          spec and then also suggest implementations give console
  dholbert: We risk authors being ok with the "broken" behavior.
  florian: There's always a risk of that, but grid is so central to
           your layout that I think if it breaks then we won't have
           as much compat risk.
  astearns: If people do depend on it, we would need to come up with
            another way to solve it.

  astearns: We basically heard from all implementors saying 'subgrid.
            This is crazy.', have thoughts changed?
  TabAtkins: Igalia said their opinion on the list,
  dholbert: I spoke to Mats, and he feels this is still complex as
            you need to keep track of overflow for the items.
  fantasai: We would be ok with computing overflow to visible always
            if that is a concern.

  TabAtkins: Another issue is paint order.
  fantasai: I expect authors to be able to control z-index from
  dholbert: With that change, it may make it simpler.
  fantasai: You won't have to keep track of scrollers, etc
  dbaron: z-index also applies to all graphical stuff as well,
          masks, transforms, etc.
  fantasai: I think everything should just work as normal unless
            stated otherwise.
  dbaron: This is odd that it's basically an element that doesn't
          have a box.
  dbaron: This is similar to an element that doesn't have a box.
  TabAtkins: We're getting more explicit about the box.
  dbaron: But does the spec on filters or mask define whether this
          applies to elements or boxes, thus would impact a subgrid.
  esprehn: I don't think we should have another table row problem
  fantasai: I agree, it should get a box and we will on purpose
            exclude stuff from it to ease implementer complexity.
  dbaron: So it gets a box?
  fantasai: Yes.
  dbaron: This is well defined how the positioning/margin/border/
  TabAtkins: Yes.

  <Rossen> plinss, so you're saying that for layout purposes the
           subgrid is considered empty but has a size independent of
           its children sizes?

  jensimmons: I am an author and feel very strongly that subgrid
              should be included with grid, and I'm hoping that this
              is simple enough to ship it.
  jensimmons: From my experience they're going to be very confused
              that they can't align everything to the parent grid.
  jensimmons: I'm not sure this will cover all use cases, mainly
              because haven't had the time to play with it.
  jensimmons: In most cases they're going to be thinking about the
              explicit grid, not the implicit grid and I hope that
              this is simple enough that vendors will implement this.

  fantasai: I think we can resolve that overflow is at risk and say
            it computes to visible.
  astearns: So an at-risk within the at-risk section.
  astearns: Is there anything more people want to add?

  RESOLVED: subgrid proposal accepted in the at-risk section

[break=15 minutes]

Manuel Rego Casasnovas | 23 May 11:40 2016

[css-grid] auto-repeat inside grid-template shorthand


this is a similar mail to the previous one.

In the current syntax for grid-template [1] we have:
  [ <line-names>? <string> <track-size>? <line-names>? ]+
  [ / <track-list> ]?

This means that the following declaration would be invalid:
  grid-template: "a b"
                 "a b" / repeat(auto-fill, 100px);

I guess that as you are defining the grid areas,
you know the number of columns and don't need auto-repeat.

However, you can do something like this:
  grid-template: "a b"
                 "a b" / repeat(5, 100px);
  grid-template: "a b"
                 "a b" / 400px 200px 100px 50px;

And this is valid from the syntax point of view.

Do we really want to have an exception for auto-repeat here or not?

FWIW, right now it's valid in all auto-repeat implementations (Blink,
Webkit and Firefox).



Manuel Rego Casasnovas | 23 May 11:03 2016

[css-grid] Line names before auto-repeat


with the current syntax [1]:
  <auto-track-list> =
    [ <line-names>? [ <fixed-size> | <fixed-repeat> ] ]+ <auto-repeat>
    [ <line-names>? [ <fixed-size> | <fixed-repeat> ] ]+ <line-names>?

The following declaration would be invalid:
  grid-template-columns: [first] repeat(auto-fill, 100px);

We don't see any good reason why this is invalid, actually this is right
now working in all the auto-repeat implementations (Firefox, Blink and

Are we missing something or it's just an oversight?



fantasai | 19 May 22:05 2016

[CSSWG] Insignificantly Updated WD/CR Publications

The CSSWG just published insignifcantly-updated copies of a few modules:

CSS Cascade Module Level 3 Candidate Recommendation
   No changes, just markup fixes.

CSS Positioned Layout Level 3 Working Draft
   Added an informative table and and removed 'position: page' and
   'position: center' (which had never been approved for publication
   in the first place). It is otherwise no more or less correct/
   up-to-date than it was previously.

I'll post to this thread as we toss up more drafts that are more or
less just regenerated. Actual updates will continue to get their
own announcements!

who is on a publishing spree ;)

fantasai | 19 May 21:56 2016

[CSSWG][css-grid] Updated WD of CSS Grid Layout L1

The CSS WG has published an updated Working Draft of the
CSS Grid Layout Module Level 1:

This module defines a new type of layout manager, the grid, which
makes it extremely easy to specify complex, responsive 2-dimensional
layouts for a page or components.

Significant changes since the last draft are listed at:
and a Disposition of Comments is available at:

This is effectively a Last Call Working Draft; the one significant
issue still open is:
and, um, I need to delete lots of red text that's talking about
solved or deferred issues. :]

Please review the draft, and send any comments to this mailing list,
<www-style <at>>, prefixed with [css-grid] (as I did on this message)
or file them in the GitHub repository at

For the CSS WG,