[CSSWG] Minutes Telecon 2016-06-29 [css-grid] [css-align] [css-flexbox] [css-inline]

Previous Topic Next Topic
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view

[CSSWG] Minutes Telecon 2016-06-29 [css-grid] [css-align] [css-flexbox] [css-inline]

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

What happens with grid line names when dropping tracks?

  - RESOLVED: Accept option C: keep the tracks in the track listing,
              but force them to be zero-sized and suppress any
              gutters between adjacent collapsed tracks.

Removing restrictions on baseline-aligning things that have block-axis
    baselines (due to containing orthogonal content)

  - No one has had time to fully think through the best way to
      address this problem, but fantasai, TabAtkins, Rossen,
      rachelandrew, and Mats are interested in investigating.
  - The first step is for fantasai to add more diagrams to the spec
      and everyone else to review the baseline-aligning sections of
      the spec.

Should we spec required prefixes directly in the relevant spec?

  - RESOLVED: Link to the compat spec in the Snapshot and specs with
                relevant entires and monitor for problems in the

First and Last Baselines

  - There were five possible solutions to the combinatorial
      1. Explode alignment-baseline.
      2. Use last and baseline as separated keywords in align/
           justify-self/content as well as alignment-baseline.
      3. Use last-baseline in align/justify-self/content and last
         baseline in alignment-baseline.
      4. Introduce a new property to choose first vs last for
           vertical-align, and have last-baseline decompose to last in
           that property plus baseline for alignment-baseline.
      5. Introduce first-baseline and last-baseline to
           alignment-baseline(to match Align), but also allow first
           and last space-separated prefixes for all values of
           alignment-baseline(to avoid explosion). (This means that
           both first-baseline and first baseline would be valid)
  - The group rejected options 1 & 3 and fantasai will add some
      examples to clarify the difference between the remaining


Agenda: https://lists.w3.org/Archives/Public/www-style/2016Jun/0174.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Tony Graham
  Dael Jackson
  Brian Kardell
  Brad Kemper
  Ian Kilpatrick
  Chris Lilley
  Peter Linss
  Myles Maxfield
  Anton Prowse
  Liam Quin
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth

  Angelo Cano
  Alex Critchfield
  Simon Fraser
  Daniel Glazman
  Michael Miller
  Florian Rivoal
  Ian Vollick
  Steve Zilles

Scribe: dael

What happens with grid line names when dropping tracks?

  astearns: Let's start.
  astearns: Does anyone have anything aside from the agenda?

  <astearns> https://github.com/w3c/csswg-drafts/issues/172
  TabAtkins: We did get to that. I noted at the end it was accepted
             at telcon.
  Rossen: We had said we would discuss this week to give a chance to
  astearns: That's what I saw in the minutes.
  TabAtkins: Okay.
  Rossen: Should I summarize?
  fantasai: We did last week, we were waiting on you.

  Rossen: There were two options initially...dropping tracks
          completely and dropping names as well or B was keeping the
          line names though tracks are dropped.
  Rossen: With those two options, B is preferable.
  Rossen: And you said another option was keep the tracks but
          resolve them to 0 width. Basically the empty tracks are
          empty by size but there for referential integrity. I find
          that weird, keeping all the stuff around having empty
          tracks that are there for lines with names.
  Rossen: Our preference is B.
  fantasai: The reason we went with the 3rd wasn't just named lines.
            It was also because when positioning abspos and using
            names or numbers you want the references to be the same
            column you're referencing if you hadn't dropped tracks.
            Otherwise if positioning to 5th track in normal and then
            use abspos they won't end up in same tracks.
  fantasai: Layout-wise we're collapsing because auto-fit is to get
            rid of the extra space, but we want to make sure the
            abspos coordinates remain stable and identical. That's
            why we're using C and I strongly believe that's the way
            to go.
  Rossen: I hear you and I see your preference. We would be able to
          live with C. I wouldn't object. We'd prefer B. That's our

  astearns: So does that mean are going to live with C or is there
            possibility other people's preferences can move to B?
  * fantasai is not switching preferences, believes the abspos
             coordinate thing is more significant than other
             concerns mentioned so far
  Rossen: Seems like the conversation died off. I don't know if
          there's anything else we can add from our side. We can
          proceed to unblock the spec with a call for comments or
          quick straw poll. I don't mind that.
  <rachelandrew> C makes more sense to me, thinking about using it
                 as an author.
  astearns: Okay for fantasai?
  fantasai: Yes.
  astearns: Let's straw poll in IRC. If you prefer type B or C. No
            need to abstain if no preference.
  Straw poll results:
    <TabAtkins> C
    <fantasai> C
    <rachelandrew> C
    <gregwhitworth> B
    <Rossen> B
    <gsnedders> C, I think
    <plinss> C

  astearns: Alright. Smallest straw poll I've seen, but it's
            slightly toward C. More commercial entities for C. Let's
            go with C.
  astearns: If that becomes a problem in the future, Rossen bring it
            up again.
  Rossen: It'll add implementation complexity, but like I said we
          can live with it.
  fantasai: Implementation-wise it's easy until gutters and than
            it's complicated. You short circuit track sizing and say
            it's 0. That's not hard.
  Rossen: Let's leave it at that.

  RESOLVED: Accept option C: keep the tracks in the track listing,
            but force them to be zero-sized and suppress any gutters
            between adjacent collapsed tracks.

Removing restrictions on baseline-aligning things that have block-axis
    baselines (due to containing orthogonal content).

  fantasai: I'm still trying to wrap my head around this. Is anyone
            else interested in looking into this so I know who to
  <TabAtkins> Yeah, this needs fantasai and I to noodle over in a
              workday, haven't gotten to it yet.
  Rossen: We're interested.
  astearns: You and TabAtkins and Mats.
  fantasai: K.
  <rachelandrew> I'd be happy to be involved

  astearns: Is that a I'll look and put it on next week Rossen?
  Rossen: I didn't say that. It was who else is interested and we'll
          have to see later. I'm not sure why you inferred to next
  astearns: If you want to talk now please do.

  <astearns> https://github.com/w3c/csswg-drafts/issues/161
  <astearns> https://github.com/w3c/csswg-drafts/issues/197
  fantasai: Basically what things have baselines and what axes. Are
            the baselines synthesized and what's real. I don't have
            a clear explanation yet. But if the people interested
            want to review baseline alignment sections of align spec
            that's great.
  Rossen: Would this go into grid or alignment?
  fantasai: I'm not 100% sure. Grid has text explaining grid
            container baselines. That may or may not need changing
            depending on the issues. I don't know because I don't
            know what the changes are. Some interesting cases are
            there's 3 items on the line 2 with vertical writing mode
            and 1 with horizontal writing mode text, who gets
            aligned where?
  fantasai: What if you put a grid in some inline content, what
            happens with the line. I have questions, but no answers.
  Rossen: When you have items with mixed writing mode directions I
          don't see why it's different than if they're inline
          blocks. That's how we treat them.
  Rossen: For the next issues where the grid participates in
          multiple directions as long as the two main baselines of
          the grid are defined I don't anticipate any issues unless
          I'm missing something.
  <TabAtkins> Yeah, let's discuss this further offline - it's got
              some subtleties that aren't easy to see immediately.

  fantasai: I think the current Flexbox spec says if You have a flex
            line and 2 horizontal text and 1 vertical text the
            vertical text is just start aligned. So with your
            interpretation we need to change Flexbox. I don't know
            if that's a good idea.
  Rossen: Riiight...um.
  fantasai: That's not a likely case interop-wise so I don't think
            there's a compat problem. But if we need to make this
            change do we want to.
  Rossen: We'll have compat problems soon if we don't define.
  fantasai: It's defined, but your expectation and spec don't match.
  Rossen: I think what you said which is in the case of having
          vertical modes match start for baseline is what would
          happen to an inline block anyway.
  fantasai: Inline blocks are really weird. It would align with the
            first baseline unless it's a table and if it is we
            ignore it.
  fantasai: And if there's no content, we use the margin edge, which
            is weirdly discontinuous.
  fantasai: If you're interested in baseline alignment, please
            review the sections of the spec. I don't think anyone
            has really looked at it besides me and TabAtkins
  Rossen: Sure thing.
  <tantek> agreed with fantasai, baseline alignment is hard

  astearns: Sounds like all of this it would be useful to have test
            cases so we can more concretely think about the cases
            and not get lost in theory.
  <fantasai> +1 astearns, I think that's a very good idea
  <TabAtkins> From the agenda: https://github.com/w3c/csswg-drafts/issues/211
              is the primary issue. It links to the other two that
              are slightly more specific takes.
  Rossen: There are multiple issues. I don't think there will be a
          blanket solution and it's better to separate them.
  astearns: I see fantasai, TabAtkins, Rossen, rachelandrew, and
            Mats are interested. Anyone willing to take a task to
            write a test case or two?
  fantasai: I think my first job is to make illustrations for the
  fantasai: Rossen if you guys could go through the spec and raise
            specific issues as you find them that would be great. It
            hasn't had detailed review.
  Rossen: Yep. We'll definitely do it.
  astearns: Anything more on this issue this week?

Should we spec required prefixes directly in the relevant spec?

  <astearns> https://github.com/w3c/csswg-drafts/issues/247
  * fantasai agrees with Florian's approach
  <BradK> Link to compat spec?
  <tantek> yes I'm ok to just link to compat spec
  <tantek> I mean, someone else is already doing the work, so why
           fight that?
  <BradK> What is the url?
  <tantek> compat.spec.whatwg.org

  TabAtkins: The quick thing is we've got a bunch of the required
             -webkit prefixes listed in the WHATWG doc. Given that
             we don't like to send people to other documents it's
             odd that we're letting other people maintain this. If
             we have required prefixes we should do it like other
             deprecated features and have it somewhere unobtrusive
             like where we do deprecated features.
  TabAtkins: We do this in a few spots. UI has prefixed thing for
             user-select and it's fine. So when we need to doc a
             required prefix we do so in the spec that requires them
             is my prop.
  <bkardell> this should be a short lived problem right? nobody
             should be kicking out more prefixed things?
  plinss: I'm opposed to having them in our specs. The list is a
          business issue not a technical one. I don't want them
          enshrined in our specs because it's dynamic and changing.
          I don't care if it's WHATWG or someone else, but not in
          our specs. I don't mind a link in the spec or a note.
  astearns: I don't care where they go, but the point was made these
            should be handled like deprecated property and I don't
            think that's correct. Deprecated properties had been
            speced in the past, these did not have an actual spec
            definition. The set that needs to be handled is fluid,
            as plinss said. Having that tracking of what needs to be
            implemented for web compat outside our specs and in
            something easier to change is good.

  tantek: The point about deprecated: there have been numerous
          examples where we've deprecated something that hasn't been
          speced, like embed element. Those were proprietary before.
          That being said this group has a lot to work on and I'm
          not sure why we'd want additional workload where another
          group is doing it and they're doing a fine job.
  <fantasai> tantek++
  tantek: I sympathize with the concern, but this seems like
          optimizing something that's way down on the list of things
          to do. The current system is working fine.
  fantasai: We can link to their spec from the snapshot.
  tantek: I agree. This is the Web, let's just make it a hyperlink.
  astearns: The point about errata is that no one reads them because
            they have to go elsewhere is actually what we want.
  tantek: That's true. For the web authors that read the specs
          there's no need to pollute their minds with prefixed

  astearns: Points or rebuttals?
  <bkardell> Just food for thought: if the idea is really that
             authors will have a harder time finding it if it is
             only a link, very few authors read specs anymore -
             they've gotten pretty dense
  * BradK agrees with tantek
  dbaron: One concern is what happens in the long term? I think it's
          just one person maintaining the spec. We may have to deal
          with it then.
  tantek: We can keep an eye on it. If it gets out of date or causes
          problems later let's deal with it later.
  <rachelandrew> agree with linking
  <bkardell> +1 to linking
  <TabAtkins> Yessss, I'm ok with linking in each spec.
  astearns: fantasai says we can link to the compat in the snapshot.
            I think it also makes sense to link from our specs that
            have relevant entires. We can keep track of that on a
            spec by spec basis. If something falls out we can handle
            the change. If the compat spec doesn't have something
            that's something to show we need to re-access what we're
  tantek: astearns: I think that's an excellent suggestion.

  RESOLVED: Link to the compat spec in the Snapshot and specs with
            relevant entires and monitor for problems in the future.

First and Last Baselines

  astearns: fantasai you had an extra issue on baselines again? Did
            you want to talk about that?
  <astearns> https://github.com/w3c/csswg-drafts/issues/210
  fantasai: This is syntax.
  fantasai: The problem we ran into was the alignment spec has
            last-baseline and baseline as a keyword.
  <fantasai> <baseline-alignment-keywords> = baseline | last-baseline
  fantasai: That's fine for alignment spec, but less fine for inline
            layout alignment property which is a shorthand of
            alignment-baseline and baseline-shift.
  <fantasai> 'vertical-align' = { 'alignment-baseline' |
             'baseline-shift' }
  fantasai: alignment-baseline lets you choose your alignment
            baseline and that gives us a combinatorial problem. It
            becomes a lot of keywords that really seems excessive.
            Usually we take advantage of allowing multiple keywords.
  fantasai: We've got some questions about how do we deal with this.
            Do we go to alignment and change 'last-baseline' to be
            'last baseline' or do we do something else?
  fantasai: There's five options in the issue and I want to know

  astearns: I'm in favor of the optional keyword but in the quick
            read I'm not seeing the differences in the five options.
  fantasai: 1st explodes alignment baseline. 2nd is switch
            last-baseline to last baseline
  <fantasai> switch baseline | last-baseline to last? baseline
  fantasai: 3 is to be inconsistent.
  fantasai: 4 was a separate sub-property of vertical-align. It
            would have baseline-shift alignment-baseline and a third
            to say first or last baseline.
  fantasai: That lets you cascade your baseline preferences
            independently of first/last preference.
  fantasai: 5 is to have both first and last baseline as prefixed
            and space separated in the vertical alignment
  fantasai: I prefer either 2 or 4.
  fantasai: But the main difference between those is if the
            first/last preference is an independent property
  fantasai: or folded into the ideographic vs. alphabetic property.
  fantasai: I can take comments or we can end.

  astearns: I would prefer 2, 4, or 5. I don't like 1 or 3.
  astearns: Other opinions?
  <BradK> 4 sounds good. Set it on the body and let everything
          inherit it.
  <fantasai> BradK: I don't think it would inherit...
  <BradK> Doh!
  <fantasai> Bradk: alignment-baseline defaults to using the
             'dominant-baseline' of the container, which does inherit
  <gsnedders> 4, I think. But my internet connection is dying.

  astearns: Is there much use of last-baseline in the wild?
  fantasai: No, it's new. It wasn't in Flexbox and we haven't
            release grid or alignment yet.
  astearns: That's good.

  astearns: I could add this to the github issue, but it might be
            useful to reject 1 and 3 and have examples of the
            differences between 2, 4, and 5.
  fantasai: Okay.
  <TabAtkins> Yeah, easy to draw up some examples.
  <TabAtkins> I or fantasai can do that today, and revisit next week?
  astearns: Anything else on this issue?
  astearns: I'll take that as a no.

  astearns: For other business, you can see on the private list
            we're trying to get the charter submitted next time W3C
            management meets.
  astearns: Hopefully that will go well.
  astearns: Anything else?
  astearns: Thanks everyone.