[CSSWG] Minutes Telecon 2015-01-14

Counter Styles

  - RESOLVED: Add Tamil back to Counter Styles spec


  - The discussion of 'order' affecting tab order and speech order
      will wait until Bo Campbell is on the call.

Grid Layout Issues

  - RESOLVED: Re-add the mandatory minimum of 1 million tracks
  - RESOLVED: Drop the "stack" value from Grid
  - RESOLVED: Allow "auto" in minmax(), have it look at
              min-width/height for value, using same "auto" behavior
              as flexbox
  - RESOLVED: Accept repeat(auto, ...) syntax
  - Deferring on a decision about justifying grid tracks to give a
      chance to consider the implications

unprefixing min/max-content keywords

  - RESOLVED: Unprefix min/max-content keywords

:lang() Issues

  - RESOLVED: Require quoting :lang() values as a string if they
              have asterisks.

'direction' propagation from <body>

  - There was some concerns about the implications of this change,
       but due to the limited amount of time remaining on the call,
       nothing was resolved or decided.


  Rossen Atanassov
  Tab Atkins
  David Baron
  Bert Bos
  Adenilson Cavalcanti
  Tantek Çelik
  Alex Critchfield
  Elika Etemad
  Sylvain Galineau
  Daniel Glazman
  Toru Kawakubo
  Brad Kemper
  Chris Lilley
  Peter Linss
  Shinyu Murakami
  Simon Pieters
  Florian Rivoal
  Simon Sapin
  Ian Vollick
  Greg Whitworth
  Steve Zilles

  Bo Campbell
  Dave Cramer
  Simon Fraser
  Dael Jackson
  Brian Kardell
  Michael Miller
  Anton Prowse
  Dirk Schulze
  Mike Sherov
  Lea Verou

  Scribe: fantasai

  plinss: Anything to add to agenda?
  fantasai: Tamil list numbering?
  plinss: No.
  fantasai: K, let's do that one first. Should be quick.
  plinss: Please suggest items for CSSWG / Project Houdini agendas

Counter Styles

  TabAtkins: Recently it was pointed out that when we added counter
             styles for Indian languages, added 8/9 Indian numbering
  TabAtkins: Seems like an unintentional slight.
  TabAtkins: Tamil is the missing one; implemented by only one
             browser, Firefox,
  TabAtkins: Which is why we left it out,
  TabAtkins: But I think we should add it in for completeness, and
             not unintentionally slighting anyone.

  Florian: I'm usually in favor of trimming specs down, but this
           seems perfectly valid reason to add it.
  bradk: What about exit criteria?
  TabAtkins: It's not yet implemented by two, but adding a new
             counter style is very quick
  bradk: In that case, I have no objection.
  plinss: Any objections?

  RESOLVED: Add Tamil back to Counter Styles spec

  <dbaron> We also have a resolution to go to CR from about a year
  <fantasai> Yeah, but that one kindof got overtaken by xidorn's
             long list of issues.
  <dbaron> ... which were the result of implementation experience...
  fantasai: Hang on, for counter styles, we have a resolution from
            last month to go to CR
  fantasai: Is that in progress, or fell off of the to-do list?
  ChrisL: No idea
  ChrisL: Will look at it
  <ChrisL> I see
           where tab says "Yeah, I'm supposed to publish it as CR.
           Just haven't gotten around to it yet."
  <fantasai> ChrisL,
  <fantasai> ChrisL,
  <ChrisL> fantasai, and the disposition of comments is where? was a
           transition request ever sent?
  <fantasai> ChrisL,
  <fantasai> ChrisL, no idea about transition requests. The editor
             sent a request to transition (disguised as a request to
             publish, but still)


  <Florian> http://www.w3.org/mid/CAAWBYDAoGDQGZ9J42nA2zHNWMjJ5WfxDQ=XbuvqBSyM-P4geog@mail.gmail.com
  Florian: A request raised again about 'order' affecting tab order
           and speech order.
  Florian: It was pointed out that there was a reason for this
  Florian: And we pushed back to ML/wiki
  Florian: There was an answer there, but it doesn't really address
           the reasoning presented for how it currently works.
  Florian: So, we're not really making progress...
  TabAtkins: I'm still of the same opinion of the WG, that the spec
             is right as-is.
  Florian: I agree. They may have a point, but not really making it.
  Rossen: I'm on the same page as well.

  plinss: We should come back to it when Bo Campbell is around.
  Rossen: Will this hold the spec back? We're trying to get the spec
          back to CR soon.
  fantasai: I think it's important to get all the other fixes
  fantasai: I'd prefer to publish and take this up as an issue
            against the new CR.
  Rossen: I don't want to hold publication hostage to this issue.

  Scribe: TabAtkins

  plinss: How close to publication?
  fantasai: Just need to finish up DoC and cross-check.
  plinss: Ok. We'll come back to this issue with Bo on the call.

Grid Layout Issues

  <plinss> http://lists.w3.org/Archives/Public/www-style/2015Jan/0168.html
  fantasai: Tab and I went through all the issues and made a bunch
            of fixes and such. We need to get WG approval.
  fantasai: First is about clamping overlarge grids.
  fantasai: We needed to add a section for what to do if you can't
            handle a gigantic grid.
  fantasai: The rule we came up with is that the start and end
            edges, whichever is outside the bounds, gets shoved back
            into the grid in the last possible position, while
            maintaining a span of at least one.
  fantasai: So if you're totally outside the grid, your span gets
            truncated to 1 and you're shoved inside. If you're just
            partially outside, the dangling side gets shoved inside
            {shrinking your span).
  <fantasai> http://dev.w3.org/csswg/css-grid/#overlarge-grids
  fantasai: One wrinkle, if you have a huge grid due to a huge
            repeat(), should you stop the repetition on a whole
            number of repeats, or just let it stop when you hit the
            limit, even if it means only a partially-completed
            repetition at the end.

  plinss: The text seems fine. It looks like there's no recommended
  TabAtkins: I previously had text giving a recommended minimum of 1
             million tracks. Looks like that was removed.
  fantasai: I don't think it was really intentional.
  Rossen: Let's just add it back; it'll make the feature more
  Rossen: I think I remember something in Flexbox limiting something
          to two bytes?

  RESOLVED: Re-add the mandatory minimum of 1 million tracks

  fantasai: Next issue is dropping the "stack" value.
  fantasai: It's not a great value. We think we should just drop it.
            MS will need a value that puts things in slot 1,1 anyway
            (which doesn't match "stack" behavior), so they can just
            keep an MS-specific value for that in their UA

  RESOLVED: Drop the "stack" value from Grid

  fantasai: Next is about minimum size of grid tracks.
  fantasai: In the Grid spec, if you have an auto or flex-sized
            track, you use the largest of the min-contents of the
            things in the track as the "minimum size" of the track,
            and then grow it or flex it from there.
  fantasai: This doesn't work well for items that have a specified
            minimum size.
  fantasai: We have a min-*:auto value from Flexbox. The idea is to
            have Grid behave the same way.
  fantasai: Default behavior would stay the same, due to "auto", but
            let people override.
  fantasai: This allows "auto" in minmax() - minmax(auto, foo) means
            "use the specified min-* property value", and that
            "auto" on its own expands to "minmax(auto, auto)".

  plinss: Seems fine, but it look like there's a few subtleties I
          haven't wrapped my head around.
  fantasai: I had Peter Salas look over the algorithm, and made some
            fixes. I think the algorithm ends up fine.
  plinss: Any implementors have any opinions?
  Rossen: We were part of the discussion, and were fine with it.

  RESOLVED: Allow "auto" in minmax(), have it look at
            min-width/height for value, using same "auto" behavior
            as flexbox

  fantasai: One issue in many grid systems is to allow as many
            columns as there is space.
  fantasai: But right now repeat() only allows a fixed number of
  fantasai: We propose adding repeat(auto, ...) to solve this case.
  TabAtkins: For example, a catalog display that auto-flows things
             into a grid; each item is 200px, but you don't know how
             many columns that would end up using.
  fantasai: And it is easy to calculate, because things are fixed-

  plinss: Makes sense.
  plinss: One thing that might make sense is [missed].
  TabAtkins: Send an email with an example?
  <gregwhitworth> yeah an email would be nice
  plinss: Having one auto-sized track, and then filling the rest of
          the grid with auto-counted track,
  plinss: Number of auto-counted tracks would depend on the width of
          first track,
  plinss: But maybe it's too complex for now.

  RESOLVED: Accept repeat(auto, ...) syntax

  fantasai: Next is justifying grid tracks.
  fantasai: An implementor brought up application of 'stretch' and
            'space-between'/etc in Flexbox, and whether they apply
            to Grid.
  fantasai: In Grid we originally treated the entire grid as a fixed
            box that got centered or whatever, but it was pointed
            out that it's useful to be able to justify the tracks.
  fantasai: So if you have X tracks taking up *almost* the
            container's width, it's useful to fill the leftover
            space between the tracks.
  fantasai: So we changed the spec to make the individual tracks be
            the alignment subjects.
  fantasai: The "line" separating tracks can have "thickness",
            sorta, with the distribution values.
  fantasai: For "stretch", you add a little bit more space to all
            the tracks at the end, similar to Flexbox.

  plinss: I'm okay as long as this isn't the default behavior.
  fantasai: It's not.
  plinss: Also, how does this interact with gutters?
  fantasai: Specified gutters would end up being a minimum
            separation between tracks.
  fantasai: You run the grid sizing algorithm to find the size of
            the grid tracks, then increase the size of the tracks to
            handle stretch. This gives you the final grid areas into
            which you lay out the grid items
  <fantasai> Actually, we might need to clarify that point :)

  Rossen: Can we defer resolving this? I'd like more time to think
          about it.
  fantasai: You were on the call when we discussed it in December,
            but sure, if you need more time.

unprefixing min/max-content keywords

  fantasai: We've got this Sizing spec which needs a good bit of
            work yet to get fully stable; there's a lot of
            complicated sizing stuff that's not very well-reviewed,
            with some parts missing, etc.
  fantasai: It'll take a while to get a lot of the definitions
            stable and correct.
  fantasai: But the syntax of min/max-content keywords and what they
            mean is stable.
  fantasai: The Grid Layout spec is also using these keywords in
            grid-template-rows/columns, so once Grid advances a bit
            we can't change them anyway.
  fantasai: And min/max-content concepts show up in the engines
            already (despite some occasional inconsistencies).
  fantasai: So the keywords are super-useful. It would be nice if
            people could use them. So since we know roughly what
            they mean, and we're already exposing their potential
            incompatibilities through layout, we should go ahead and
            unprefix them now.
  fantasai: Or possibly wait until Grid goes to CR to unprefix them.

  dbaron: I'm not sure the definitions in the block direction work
          in all contexts.
  fantasai: Yeah, I'm unsure what the correct answers always are in
            the block dimension. In the inline dimensions it's very
            clear what they mean.
  dbaron: I think they depend on layout, and I think there are some
          things that depend on them not depending on layout.

  TabAtkins: height:min-content is basically just "the height after
  Rossen: Yeah, height always depends on width in block layout. That
          shouldn't be anything new.
  Rossen: I think we had this discussion in the past, and it was
          mostly related to orthogonal flows, and what min/max-
          content mean in that context.
  Rossen: We can't get around having some layout dependency for the
          cross dimension, in logical terms, but the main dimension
          should always be independent of layout.

  Rossen: So are you currently concerned with them being unprefixed?
  TabAtkins: Well, Firefox doesn't implement the keywords for
             'height' right now.

  dbaron: I'm a little worried about them ending up as something
          that makes sense in Flexbox and Grid and doesn't make
          sense in Block, in the height dimension, but I guess I'm
          okay with unprefixing them. Though I don't think the block
          dimension will be very interoperable for a while.
  fantasai: Yeah, if we could unprefix them for just the inline
            dimension, we would, but that's effectively impossible.
            We could put a warning in the spec that says that using
            it in the block axis might be unstable. Most people will
            use it in the inline dimension anyway.

  plinss: I'm a little concerned about having them defined in a spec
          that won't be ready for years.
  fantasai: Well, the entire point of this spec is to define these
            keywords, moving it around won't help.
  fantasai: The issue is the complexity in intrinsic sizing in a
            bunch of edge cases. Table layout is mostly complicated
            due to intrinsic sizing.

  RESOLVED: Unprefix min/max-content keywords

:lang() Issues

  <TabAtkins> https://lists.w3.org/Archives/Public/www-style/2014Dec/0177.html
  TabAtkins: Previously we resolved to allow asterisks in :lang(),
             but per my email (above) I think we shouldn't. The
             legacy language behavior for ident-ish things can stay,
             but as soon as you need an asterisk, which breaks ident
             parsing, we should require use of strings.
  TabAtkins: In general, terms defined from outside CSS are
             represented with strings, as it avoids parsing
  fantasai: I think problems with asterisks is something that will
            be very rare for authors to run into, but I don't have
            objections if y'all have a strong opinion.
  Florian: Mini-grammars not inside quotes tend to get painful
           eventually (see recent issues with unicode range), so I'm
           with tab
  plinss: So, any objections to requiring string?

  RESOLVED: Require quoting :lang() values as a string if they have

  <SimonSapin> TabAtkins, so :lang() syntax is still `<ident> |

'direction' propagation from <body>

  zcorpan: It seems that browsers are propagating 'direction' and
           'writing-mode' always from <body>, even if it's set on
           root element as well.
  <zcorpan> https://codereview.chromium.org/758073003
  zcorpan: So we should just specify the implemented reality.
  <zcorpan> probably

  fantasai: I wonder what happens when you make the <head> visible?
  fantasai: Does it use the <body> direction/writing-mode?
  dbaron: Gecko does different things in different places. There are
          2 or 3 places in our code where we care about the
          direction on the root, and they're inconsistent with each
  <zcorpan> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/3366
- visible head, dir on body

  Florian: In general, I think we should avoid making <body> special
           unless there's compat.
  fantasai: I want to keep writing-mode consistent with direction.
  fantasai: I don't *mind* making them inconsistent, but...
  fantasai: I think the important one to consider here is direction.
  <zcorpan> in blink direction and writing-mode are consistent with
            each other i think
  <dbaron> for Gecko doing different things, see

  tantek: Does it affect the title element?
  TabAtkins: Yes, the one on the page. I'm unsure what happens in
             the browser tab.
  TabAtkins: In Chrome, <title> in the tab doesn't pay attention to

  fantasai: What is the percentage of pages that have dir=rtl on the
            body and not on html tag?
  Rossen: You can have the same thing specified with properties.
  fantasai: Yeah, but it's rare and bad practice.

Received on Thursday, 15 January 2015 01:57:49 UTC