[CSSWG] Minutes Telecon 2018-08-08 [css-inline-3] [css-overflow-3] [css-display] [css-grid] [css-color]

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

Publishing transition updates

  - Editors should have a disposition of comments and changes document
      complied as well as any edits already made before requesting a
      CR publication.
  - After the group resolves to request the CR publication the editor
      should publish a the request to the transitions github. If they
      don't know how or need assistance, chris is happy to help.

CSS Inline

  - RESOLVED: Rename this [inline-content-box-height-calculation-mode]
              to be inline-sizing: normal|stretch (Issue #2989)

CSS Overflow

  - RESOLVED: Match the block followed by inline ordering of 2 value
              pairs for the overflow-x and overflow-y shorthand to be
              consistent (Issue #2988)

CSS Display

  - RESOLVED: Publish a new WD of CSS Display

Be consistent about versioning in ED URLs

  - RESOLVED: Use versioned URLs for EDs (Issue #2941)

CSS Grid

  - RESOLVED: Drop auto from grid line syntax (Issue #2856)

CSS Color

  - TabAtkins will speak to his graphics team to talk through his
      proposal on issue #2722 ("transparent" keyword being a special
      color value, which resolves to rgba(0,0,0,0) by default?) and
      add their feedback to the issue in order to continue the


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Aug/0007.html

  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Garrett Berg
  Dave Cramer
  Alex Critchfield
  Benjamin De Cock
  Simon Fraser
  Tony Graham
  Dael Jackson
  Chris Lilley
  Peter Linss
  Nigel Megitt
  Thierry Michel
  Anton Prowse
  Manuel Rego
  Melanie Richards
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Jeff Xu
  Fuqiao Xue

  Tantek Çelik
  Emilio Cobos Álvarez
  François Remy
  Florian Rivoal
  Jen Simmons
  Sean Voisen
  Greg Whitworth

Publishing transition updates
  link: https://github.com/w3c/transitions/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+CSSWG

  Rossen: fantasai sent us a reminder with a link to 6 publications
          awaiting approval. chris can you give us an update on where
          these are?
  chris: 2 are waiting for CR transition meeting, they were sent on
         Saturday. It was pretty clear on the tags. 2 awaiting
         director are waiting. 2 waiting publication have been
         approved and just waiting to be published
  chris: css fonts 3 had to have a cr and there was a 2 month
         exclusion so we had to wait for that to finish. I asked if we
         really have to wait 2 months and haven't heard back.
  chris: Snapshot I've been pushing on florian who needs to do edits
         and he claims he'll do it next week

  Rossen: Ones waiting for director can you nudge or are you already?
  chris: There's a minimum set of days between when email sent to
         chairs list and when they'll decide to give time for
         objections or comments. We're inside that so we can't go
         faster. Also they do the calls on Fridays and I can't make
         Friday come faster.
  chris: I have prepared CRs for publication already so if there are
         no changes requested I can send them immediately. I'm away
         next week but I've asked xfq to look out for those
  Rossen: Thanks chris. fantasai is there anything else to touch on?

  fantasai: Sounds great. At what point in this process
            generally...when something goes through transition request
            does editor only need to follow up if there's a question?
  chris: The questions if they happen will be on the public repo. If
         the director wants a change it's listed there
  <dauwhe> https://github.com/w3c/transitions/issues/
  fantasai: And once approved does editor need to do anything for it
            to be published?
  chris: Typically no. Only if there's a load of link errors and in
         that case I'll contact the editor.
  chris: It would help if you only put the tag for the next stage
         rather than all following stages.
  chris: One other thing, CSS Paint API took a while, but it's because
         I was on vacation and we had two publishing moratoria.
  fantasai: Okay, as long as things are following through
  chris: I haven't seen something dropped for quite a while.
  fantasai: That's great. Historically CRs have taken a long time to
            publish for that reason.
  Rossen: Thanks chris for pushing on those and thanks fantasai for
          surfacing this and pinging us

  fantasai: chris one question. When we resolve to take to CR what
            would you expect and editor to do?
  fantasai: I want to to be clear to everyone.
  chris: For the last year I've been pushing back when there's an
         agenda item to publish a CR because that's not what we do.
         It's are we ready to request CR meaning do we have updated
         DoC etc. In the past we'd resolve to publish but also say
         editor had to do some things before. We'd have 5 or 6 months
         before it's ready
  chris: Now it's better because we resolve to request transition and
         discuss as a group anything outstanding so it's good to go
         when we decide. Github makes it easier to request. As long as
         you have DoC and changes list and there's not any objections
         you don't have to do anything
  fantasai: Should editor file issue into transitions repo?
  chris: I think if an editor feels comfortable to do that it's good.
         But if an editor isn't I'm happy to show them. That happened
         at Houdini. If people are worried I can help but it's very
  chris: Doesn't have to be me.
  fantasai: Process is if we resolve...to request you need DoC,
            Changes List, any changes to be edited in edited in. And
            then file an issue in transitions repo or ask chris for
  chris: Yes
  fantasai: Sound good to everybody?
  Rossen: sgtm

CSS Inline 3

Need name for inline-content-box-height-calculation-mode property
  github: https://github.com/w3c/csswg-drafts/issues/2989

  Rossen: Nominations are welcome unless fantasai you want to
          summarize the property
  <fantasai> https://drafts.csswg.org/css-inline-3/#inline-box-dimensions
  fantasai: We talked about use case ttml group had for this which it
            does not change layout calc, just where background and
            border are painted.
  fantasai: Current behavior is defined as in css 2. It's possible we
            might want other values at some point. I don't know 2.1
            but it used font metrics or maybe 1em for height of
            content box
  fantasai: At one point a suggestion to have a value that contains
            all glyph bounding boxes. Might want to extend to do that.
  fantasai: Wanted people to think about that
  fantasai: I have no good suggestion. I have a constraint that we've
            had discussions about how line box height is calc. We need
            to be clear that this name is not that
  <dbaron> inline-box-sizing :-)

  nigel: The ttml requirement is that the background areas go to the
         line areas. So if there's a way that line area heights can
         change we need to track that in property values.
  nigel: Made a suggestion a few days ago and someone had another so
         there are suggestions. When I looked at draft spec it make me
         want to call it inline-box-content-height. Going back to your
         point if the line edges might move then maybe the fill value
         should be called line
  fantasai: Another thing is we do have plans to have a height keyword
            called stretch which takes a container and says I want you
            to fill that. Might be another keyword that makes sense.
            Could rename fill to stretch.
  fantasai: Property name there's...it's the content height but
            effects border-box height and shouldn't be confused with
            inline-size. Cannot be mixed up with changing how line
            height or box height are calc.

  dbaron: One thought is inline-box-sizing since it's a mode switch
  fantasai: Not terrible, but looks like might be a long hand of

  nigel: Sizing says width as well as height, but this is only height
  dbaron: Inlines aren't special in width dimension on the other hand
  fantasai: Trying to remember why not a keyword to the height property
  Rossen: If it's only to inlines height is a bit of an overkill.
          You'd also have to add it to all other heights and this is
          just used value
  fantasai: True
  <bradk> It would be width for vertical writing mode, right?

  Rossen: I gravitate toward dbaron's reasoning. This is the switch we
          use for flipping different ways of box model. Also having
          something similar for inline calc which is not bad.
  fantasai: But what if we decide some day we want long hands for box
            sizing? Then we're stuck.
  Rossen: We can make those as optional params and keep as a shorthand
  fantasai: But if we decide we do want longhands this is what they
            would be. We can say inline-sizing, but not
  Rossen: Fair. [missed]
  fantasai: Also haven't decided name for line box height calculation
            mode property. I think that one should be line-sizing or
            maybe line-box-sizing. If we go with that inline-sizing is
            close and it gets confusing
  Rossen: Seems like we have inline-sizing, inline-box-sizing which
          captures it but don't want to use because box-sizing
          shorthand. inline-box-content-height proposed on github and
          also inline-box-mode also from github

  Rossen: Can we narrow down and if we need to change later, well, as
          I said this is a favorite topic for the group so we can
          bikeshed more
  fantasai: I think 'mode' is generic
  Rossen: Let's try inline-sizing and see if we can live with it
  fantasai: Is that okay even if we have line-sizing?
  Rossen: It'll be confusing but will hopefully generate interest
  <bradk> Prefer inline-box-sizing

  nigel: Why are you focusing on inline-ness rather than the content
         area that you're setting. Content area of inline boxes, sure,
         but aren't content areas always inline?
  fantasai: No, all boxes have content area. And we're not only
            setting content area, we're also doing margin and border
            etc. It's the margin area that fills the line box. By
            default the margins padding etc are by default 0, but if
            they're bigger the content box would be smaller
  nigel: Makes sense

  Rossen: I want to see if we can get closer to resolve. Proposal was
          name this inline-size. Value set?
  fantasai: I think normal|stretch and maybe extend to glyphs or
  fantasai: Should be possible to extend value set in the future.
            Maybe glyphs, maybe height of whatever is inside it
  fantasai: but we can start with those two things since they have
            clear use cases.
  Rossen: Reasonable. Objections to renaming this to be inline-sizing:

  RESOLVED: Rename this to be inline-sizing: normal|stretch

CSS Overflow

'overflow' 2-value syntax is in wrong order
  github: https://github.com/w3c/csswg-drafts/issues/2988

  Rossen: This is value ordering and we try to do x then y, but all
          logical properties are block and then inline. What is the
          proposal here?
  fantasai: Proposal is to use the logical order, block then inline.
            Overflow properties do have logical shorthands. Also
            pretty important to make sure ordering matches with
            scroll-snap-align. Having them opposite is fairly confusing
  Rossen: This would apply to...a handful or properties
  fantasai: Just overflow shorthand property. I don't know of any
            others, though they might exist
  <dbaron> how many engines implement 2-value overflow? Gecko does.

  Rossen: Do we keep consistency for position properties?
  fantasai: Once in logical coordinates are block first inline second.
            All the 4 values are block first inline second
  fantasai: Logical 2 value coordinates is mainly background-position
            and that's a rough WD with logical positioning values
  fantasai: Physical are x then y

  dbaron: How many engines impl?
  fantasai: Just Mozilla because we just added in April
  <rego> Chromium has it in M68 I believe
  <rego> https://www.chromestatus.com/feature/5090725653905408
  Rossen: We've had overflow-x and -y since IE 6
  fantasai: We won't change that.
  Rossen: Sorry, though you were talking about long hand
  Rossen: So that means compat risk is fairly small
  fantasai: Yeah

  <bradk> When did we resolve on doing block first? That seems wrong
          to me.
  <fantasai> bradk, awhile back ... when we were working on css-grid
  <fantasai> bradk, I'm not entirely convinced it was a good idea,
             there were good arguments in both directions... but we
             should be consistent here
  <bradk> fantasai: understood

  Rossen: dbaron would you guys be okay with this?
  dbaron: Yeah
  Rossen: Proposal: Match the block followed by inline ordering of 2
          value pairs for the overflow-x and overflow-y shorthand to
          be consistent
  Rossen: Objections?

  RESOLVED: Match the block followed by inline ordering of 2 value
            pairs for the overflow-x and overflow-y shorthand to be

CSS Display

Reconsider if 'inline-block' and 'inline flow-root' should be
    syntactically equivalent
  github: https://github.com/w3c/csswg-drafts/issues/2947

  Rossen: Oriol brought this. We've got more elaborate diagrams
  [trying to figure out if right people on call]
  <astearns> tab sent regrets for this week and next

  fantasai: Since we're stuck on this, can we publish a WD on this?
  Rossen: Yeah, let's go ahead and publish

  RESOLVED: Publish a new WD of CSS Display

Be consistent about versioning in ED URLs
  github: https://github.com/w3c/csswg-drafts/issues/2941

  gsnedders: This is about consistency on using level for ED.
  dbaron: Is this about what the latest version points to or what's in
          repo or...?
  gsnedders: I think this is what the latest version in the draft is
             linked to. The ED link in TR specs. I could be wrong. I'm
             not sure, I can't remember
  Rossen: chris anything to add?
  chris: It wasn't quite the same thing. There's rules for latest
         version, but doesn't cover ED
  dbaron: I think underlying problem is that CSS conditional hasn't
          been published since great renaming. I think solution is
  gsnedders: Underlying issue is to have a versionless string in TR
             data which is API exposed. That's not a CSSWG thing

  fantasai: If this is all pulling from a draft we should prob decide
            if we want versioned URLs for ED links
  gsnedders: Yes
  dbaron: I think versionless is problematic when we have 2 levels
          being worked on which happens a decent amount of time
  <chris> most of the time, I would say
  fantasai: Go with versioned URLs. It's simpler and always correct.

  gsnedders: If use versioned do we want anything linked to a later
             level. Once we publish as CR and start new work on a new
             level do we want to link to that level?
  fantasai: That's what TR latest is supposed to be for
  gsnedders: Do we want to link to a newer ED?
  fantasai: I think no. Let's say grid 1 and 2 are published. Having
            ED link for grid 1 go to grid 2 isn't helpful. If you find
            issues on L1 you should file them on L1. But if you're
            looking for latest you should go to L2. The ED URL
            shouldn't try to negotiate which level you're looking at.
  gsnedders: Also presupposes we publish a FPWD soon after starting a
             new level
  fantasai: We do that frequently. When we don't it's because it's
            really shaky and you shouldn't be referencing it
  Rossen: To avoid the discussion going into publishing management.
          URLs and URL versioning. Last proposal that resonated was to
          stick with using versioned URL. Can we resolve on that?
  Rossen: Objections to use versioned URLs for EDs

  RESOLVED: Use versioned URLs for EDs

  gsnedders: I don't object, but I want to check if there are things
             we haven't published but we should have.

  fantasai: gsnedders do you want to fix the repo?
  gsnedders: I guess I can.
  <dbaron> don't forget fxtf-drafts and css-houdini-drafts!
  fantasai: If one person doesn't do them all something will be
  Rossen: Agree. This is the kind of thing that needs to be done by
          one person

CSS Grid

grid-line custom identifier auto?
  github: https://github.com/w3c/csswg-drafts/issues/2856

  Rossen: eric brought this and fantasai you put this on the agenda
  fantasai: There was an issue against grid asking if the ID auto
            should be excluded from the places where we use custom
            ident to represent named line. Auto has a special meaning
            it doesn't resolve to a named line. We exclude span
            keyword, but not auto.
  fantasai: Question if we should exclude auto in places we exclude
  Rossen: I wouldn't put span and auto in same category for this
          behavior. span is forward looking directive and auto is a
          applied to a single item
  fantasai: You cannot have...if you named a line auto you're just
            going to have trouble, esp. in level 2 where you can
            combine auto with a custom ident. You can see the grammar
            in the issue. If a custom ident can include auto you can
            write auto1 and have that resolve. I'm not sure allowing
            that is helpful
  fantasai: Where we have span <custom-ident> we're planning to add
            auto as a similar pattern. That's a grid 2 issue
  <fantasai> https://github.com/w3c/csswg-drafts/issues/796#issuecomment-385547068
  Rossen: I see your point.
  Rossen: I can live with it.

  Rossen: Anyone from Mozilla that's close to grid impl. dbaron do you
          have an opinion?
  dbaron: No opinion. Have to ask Mats
  Rossen: It's only our impl that allows auto
  fantasai: I think chances of people naming a line auto is pretty
            much 0 unless you're a QA person
  Rossen: How did we end up removing span but not auto?
  fantasai: Don't know. I think there's some syntactic construct where
            one was ambiguous. It said span and a custom ident you
            could do and you want to know that you are consuming a
            custom ident or the span up front. If you write span span
            is it a keyword or an ident. So we prob did for parsing
  Rossen: We allow span int and span custom ident
  fantasai: Yes and auto <custom-ident> will be in L2
  Rossen: Okay, I'm okay with proposed change

  Rossen: Any other opinions? Or do we try to resolve?
  Rossen: Objections to dropping auto from grid line syntax?

  RESOLVED: Drop auto from grid line syntax

CSS Color

"transparent" keyword being a special color value, which resolves to
    rgba(0,0,0,0) by default?
  github: https://github.com/w3c/csswg-drafts/issues/2722

  chris: One point TabAtkins was [missed]
  chris: It's if what TabAtkins did was right [missed] [audio problems]

  TabAtkins: You remember back when we did gradients and there was an
             issue with transparent and I made it so gradients do a
             transition through premultiplied space. That has weird
             implications. All impl do non-premultiplied
  TabAtkins: To fake premultiplied you have to put in a number of
             additional stops to do it they way transparent intends.
  TabAtkins: I've come to regret this because transparent wants to be
             special in more places. When I wrote edits for cross-fade
             from last F2F I realized that crossfading with
             transparent would darken the image half way through. Same
             exact case. When you fade to transparent you expect it to
             become more transparent not change color
  TabAtkins: Don't want a special case where if you leave it blank you
             get a different behavior
  TabAtkins: Solution is slightly change original resolution.
             Transparent retains itself as a special keyword through
             computed value. Some cases use it as meaning something
             special some can be to a more transparent version but
             otherwise it can act the same where it's rgba(0,0,0,0).
             Any opinions or in particular compat concerns?

  dbaron: More concerned about if it's giving right behavior. In
          particular sounds like you define cross fade so not in
  TabAtkins: Most likely, yes. I suspect most libraries we're using
             aren't so we want to match
  dbaron: Not so sure on that. And if you're crossfading 2 images and
          one has area that's almost but not quite transparent you get
          bad results. Suppose you're looking at one region of the
          image and it happens to be mostly a solid. And in another
          image light and opaque and you could get darkening and then
          lightening. Seems not good.
  dbaron: Also I think a lot of compositing is done with premultiplied.
  TabAtkins: Fine with defining in premultiplied
  dbaron: Worth researching
  smfr: Crossfade paints the bottom image with source over operator
  TabAtkins: It's not. It's not a source over it dissolves and plus
  TabAtkins: You're not drawing one and then fading a separate image
             over it. If that's true the first image always shows if
             there's any transparent areas in the second and that's
             not right

  Rossen: We're running out of time. I don't want to go to overtime so
          I encourage people to go back to github
  TabAtkins: I'll talk with graphics people and find out how our image
             fading works in the platform

  Rossen: Thanks everyone for calling in and we'll chat in a week

  <dbaron> ok, yeah, that makes it sound like premultiplied doesn't
           even matter
  <TabAtkins> dbaron: no, it does still matter. You still get the
              darkening effect you mentioned
  <TabAtkins> White 50%, transparent 50% dissolves the white to
              .5,.5,.5,.5 and the transparent to 0,0,0,0, then adds
              the channels together for .5,.5,.5,.5
  <TabAtkins> Aka this is just a porter-duff way of saying
              "weighted-average the channels", same as gradients
  <dbaron> TabAtkins: but aren't the compositing operations precisely
           defined so that you don't have an option of choosing
           premultiplied or not?
  <dbaron> (i.e., they are premultiplied)
  <TabAtkins> dbaron: Hm, the first reference I was using for the
              definition of dissolve made it an unary operator, but
              Wikipedia lists it as a binary op that grabs random
              pixels from each layer in proportion to the weighting (
              which, extended continuously, is pre-multiplied

  <AmeliaBR> Concern: How does this affect partially transparent
             colors? Can you divide an animation from red to
             transparent into a midpoint of #f008 and still get the
             same results?
  <TabAtkins> AmeliaBR: in premultiplied, yes you can
  <AmeliaBR> @Tab, I know. I was thinking about if we switched to the
             special case. Someone had mentioned extending special
             case behavior to animations, and that seemed problematic
             since intermediary values in animation need to be able to
             compute out.
  <AmeliaBR> But, I realize that in animation, the computed value
             would change as soon as you started the animation: as I
             said without thinking about it, the halfway-point from
             transparent to #f00 would be #f008, not #8008, so all
             would be good.
  <AmeliaBR> So, for an animation red -> transparent -> blue, the
             computed values would all be opacity shades of red until
             you hit the exact instant of transparent, then shift to
             shades of blue. So the only special behavior is for that
             exact point. Any explicitly stated partially transparent
             color would behave in the way it is explicitly indicated
             too, which is exactly what we're trying to fix, since it
             doesn't always work that way with the current spec.

Received on Wednesday, 8 August 2018 23:51:47 UTC