Minutes Telecon 2017-05-31 [css-variables] [CSS22] [css-display] [css-ruby] [css-text-decor]

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


Specs to Rec
------------

  - ChrisL will review the pending changes from gregwhitworth to
      Variables.
  - RESOLVED: Add gsnedders as editor to CSS2.2

Does inlinification really need recursion?
------------------------------------------

  - RESOLVED: Blocks are turned into inline-blocks.

Blockification doesn't seem backwards-compatible for inline-blocks
------------------------------------------------------------------

  - RESOLVED: We are provisionally going with option b (inline-block
              -> block; inline flow-root -> flow-root).
  - TabAtkins will open a new issue to decide if you maintain
      separate computed values for just this one case or the whole
      possible space of values. Depending on that discussion the
      previous resolution may need to be revisited.

Propagation of text-decoration with display:contents
----------------------------------------------------

  - RESOLVED: Define this as a box-tree concept.

Should anonymous boxes always inherit through the box tree?
-----------------------------------------------------------

  - RESOLVED: Let's try it out, go forward with the diff
              (https://github.com/w3c/csswg-drafts/issues/1118#issuecomment-301942276)

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

Agenda: https://lists.w3.org/Archives/Public/www-style/2017May/0059.html

Present:
  Rachel Andrew
  Rossen Atanassov
  Tab Atkins
  David Baron
  Tantek Çelik
  Dave Cramer
  Benjamin De Cock
  Elika Etemad
  Tony Graham
  Brad Kemper
  Chris Lilley
  Myles Maxfield
  Anton Prowse
  Liam Quin
  Melanie Richards
  Jen Simmons
  Geoffrey Sneddon
  Alan Stearns
  Lea Verou
  Greg Whitworth (IRC only)

Regrets:
  Bert Bos
  Daniel Glazman
  Vlad Levantovsky
  Peter Linss
  Florian Rivoal

Scribe: tantek

  astearns: Next week we are trying a AUS friendly time for telcon -
            7 hours forward
  astearns: 16:00 Pacific time
  astearns: any more items?
  (silence)

Specs to Rec
------------

  astearns: Things going to REC. Chris gave an update on Fonts.
            Still waiting for info on Writing Modes impl & test
            report.

  astearns: 3 things I see.
  astearns: 1 bunch of things with resolutions but editing has not
            caught up, like values & units.
  astearns: smfr or bogdan here?
  astearns: I will ping them separately to get transforms edits done.
  Rossen: bogdan is out sick today, belated regrets.

  astearns: Another thing, we expect a bunch of tests in Mozilla to
            contribute to test suites, but dbaron?
  dbaron: No [progress].
  astearns: What can we do to move it along?
  dbaron: Probably difficult in next month or two.
  astearns: Someone we can delegate to?
  dbaron: Organizationally, lots happening in next month or two
          taking up everyone's time.
  astearns: Noted.

  astearns: Another, gregwhitworth is looking for test review of
            submission for variables-
  astearns: he has pinged a few people in the github pr.
  astearns: Any volunteers to look at those and get them into the
            test suite? tab? chris?
  astearns: Just a review of a submission.
  TabAtkins: I can review them then.
  ChrisL: What bits? variables tests?
  <gregwhitworth> yes
  ChrisL: I started looking at them, didn't finish reviewing them, I
          can look at them
  astearns: Tab you're off the hook. ChrisL will get to them in the
            next week or two.
  <gregwhitworth> please do - I'd love to wrap this up :)

  astearns: Last thing, pending edits to CSS2.2
  astearns: gsnedders suggested adding an editor
  astearns: because Bert is on vacation.
  astearns: CSS2.2 is an odd duck
  astearns: in terms of editing.
  ChrisL: I would be happy to add gsnedders
  ChrisL: It is an odd duck because it uses the old pre-processor.
  ChrisL: We cannot use bikeshed because it is a multi page document.
  astearns: It is a monumental task to convert even if bikeshed
            could.
  astearns: gsnedders you sure you want to take this one?
  gsnedders: yes? not sure about time, but so little has happened. i
             can certainly start getting through some of the back log
  <dbaron> For what it's worth, I *used* to have the old spec
           preprocessor working locally, although various distro
           updates broke that...

  astearns: I think adding an editor is something I can do by fiat
  <ChrisL> +1

  RESOLVED: add gsnedders as editor to CSS2.2

  astearns: Not sure when Bert is back but it is in noted in the
            mailing list.
  <ChrisL> 5 weeks
  gsnedders: What is the name? css 2.1 second edition?
  astearns: I forgot. As editor, please figure that out.

Does inlinification really need recursion?
------------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1341

  astearns: let's get to the first github issue on the agenda
  astearns: inlinification and recursion
  TabAtkins: I can take it.

  TabAtkins: our current ... does ... but not ...
  TabAtkins: In order to keep certain inline layout modes in
             particular ruby from being broken up by blocks showing
             up
  TabAtkins: we use inlinification
  TabAtkins: but as currently defined in the display module it might
             be too aggressive.
  TabAtkins: In particular it turns plain blocks (not bfcs) into
             inlines
  TabAtkins: which preserves the inliniciation but almost certainly
             messes up your intended layout.
  TabAtkins: Blocks become inlines.

  TabAtkins: The other way we could do it:
  TabAtkins: make all types of blocks, flow root or flow, turned
             inline blocks.
  TabAtkins: This would preserve display a bit more closely to what
             intended
  TabAtkins: inline block
  TabAtkins: but is a little more complicated in the spec.
  TabAtkins: On the other hand we probably have to do the opposite
             for blockifications, turning inline blocks into block
             flow, not block root.
  TabAtkins: If anyone knows of any impl difficulty one way or
             another, let us know.
  TabAtkins: Otherwise we may go the latter way, inline blocks
             turning into plain blocks.
  <fantasai> in favor of inlifying into inline-block

  <Rossen> <div> text <span> more text <div>am I inline?</div> end
           text </span></div>
  Rossen: I have a question and just pasted an example
  Rossen: (describes example)
  TabAtkins: Inlinification is not triggered by that
  TabAtkins: but if instead of a span you had a ruby.
  TabAtkins: It would no longer be a block.
  Rossen: What does inlinification apply to?
  TabAtkins: Ruby bases and text, and I think there is one more
             context, run-ins?
  Rossen: In that case if it is only tied to those 2-3, then it
          shouldn't be much of a problem.

  <dbaron> Isn't part of the problem here that there's not
           inline-block variant that *isn't* flow-root -- and that
           such a thing doesn't necessarily make sense?
  <dbaron> But inlinification of block -> inline-block does seem to
           make sense, as long as there aren't compatibility
           problems.
  <fantasai> dbaron, I think the complexity here is that 'flow' for
             blocks can mean flow-root depending on various external
             things, and historically these cases have a display
             type of 'block' not 'flow-root'.
  <dbaron> What do implementations do?
  TabAtkins: dbaron, they do inconsistent things, bc run-in not impl
             yet, ruby spec describes different thing that is broken
             in its own way, because it doesn't stop blocks from
             breaking things, so it is doing something, but
             inconsistent with many things, unclear what impls
             actually do.

  fantasai: One thing to keep in mind for ruby, the only impl that
            even remotely follow the spec is Firefox, the other two
            impls are tag-based hacks in layout that hook into
            inline-layout code.
  fantasai: As far as we are concerned there is only one impl of CSS
            Ruby spec.
  Rossen: How many impls follow HTML ruby spec?
  Rossen: Ruby spec as it is not ready for imply in our opinion that
          is why we are not impl it
  * fantasai would agree the css-ruby spec is not really ready for
             implementation :) Lots of outstanding issues.
  Rossen: re: ruby interop, HTML ruby interop is good.
  Rossen: Then there is the spec in the works which it is hard to
          argue what is interop and what is not.

  Rossen: Question, do we know what is from the author / content
          point of view the expected behavior?
  Rossen: Do we not break anything in the ruby context e.g. blocks?
          or do we need to blockify?
  fantasai: The general case is that ruby is not expected to contain
            block level content, generally just text, not enough
            text to wrap, though there are some pathological cases
            where the text does wrap.
  fantasai: We are trying to stop the bleeding.
  fantasai: We don't want to have to deal with how do you break ruby
            annotations across lines
  fantasai: so we are inlinifying.
  fantasai: Similar for run-ins
  fantasai: e.g. if you have a headline and want to run into the
            next paragraph
  fantasai: if you stuck a block in that headline, then it's not
            going to run-in properly.
  fantasai: We could say if you have a block inside, then you could
            say it does not run-in
  fantasai: but then you have to inspect all the way down.
  <jensimmons> +1
  fantasai: We just want to check the element its properties and
            parent(s)
  fantasai: ... inline-block ...
  fantasai: or we ... to turn into inlines
  fantasai: ... everything is contain in a bfc that is now inline
  <TabAtkins> (A simple test-case:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5218.
              Chrome's rendering is *incoherent* here, so our
              behavior can't be depended on.)
  Rossen: I agree with that logic
  <jensimmons> what fantasai just said sounds right to me. Turn it
               into an inline block.

  Rossen: Is this an error case?
  Rossen: In which case I expect exceptions or something more
          dramatic
  Rossen: so as an author I can see something wrong and go fix it
  Rossen: rather than us trying to make it sorta work.
  <jensimmons> as an author I would expect that is the ‘right’
               behavior
  Rossen: If this is an error, let's make this very obvious.
  Rossen: Otherwise if we patch it up so it sorta looks ok, then
          it's not going to be as good.
  <ChrisL> I agree with Rossen on this
  fantasai: Whatever we come up with is going to look weird.
  dbaron: To some extent, inline is a more obvious error than
          inline-block for something that was originally a block.
  fantasai: But is also more work
  fantasai: and I don't see that that is necessary.
  <liam> not sure about "let's break existing pages" - can't assume
         people will fix it

  fremy: what about display none?
  fantasai: Absolutely not.
  fantasai: This is the web platform and we do not make things
            disappear as an error case [except for XML draconian
            heads :P ]

  Rossen: Inlineness down recursively...
  Rossen: I would be in favor of either inline-block or block.
  jensimmons: I hear about things breaking more badly, but in a
              practical reality, most authors struggle to understand
              inline-block vs block vs inline does.
  jensimmons: I think make it inline-block make it seem less broken.
  jensimmons: Feels like make the outer inline while everything
              stays block is how it supposed to work?
  jensimmons: Authors are already struggling. Making it more broken
              for them is not going to help.
  fantasai: It is not really an error case
  fantasai: but we need to do something with it.
  TabAtkins: While doing inline-block is a little more complicated
             from the spec perspective, it is fairly insignificant,
             it's fairly straightforward, I'm happy to go with what
             makes more sense.
  astearns: I am hearing people are ok with either inline or
            inline-block
  astearns: but some pref for inline-block
  astearns: so we should resolve inline-block and see how it goes.
  astearns: Any objection to inline-block in this instance?

  RESOLVED: inline-block because they're awesomeish

Blockification doesn't seem backwards-compatible for inline-blocks
------------------------------------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1246

  <fantasai> issue under discussion
https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-301634850
  TabAtkins: Exact opposite case
  TabAtkins: When you blockify an inline-block what happens?
  TabAtkins: Right now blockification just changes the outer display
             type to block
  TabAtkins: in particular for an inline-block, it becomes a block
             flow root
  TabAtkins: which when you ask its display type it says block flow
             root
  TabAtkins: but for legacy reasons it has to be block.
  TabAtkins: We probably need to do same sort of exception.
  TabAtkins: When you blockify an inline-block, it becomes a plain
             block
  TabAtkins: now that we have the opposite thing, it is reasonably
             consistent.
  fantasai: This is on the agenda because it is more complicated
            than that.
  <TabAtkins> https://github.com/w3c/csswg-drafts/issues/1246#issuecomment-301634850
  <TabAtkins> Two possibilities ^^^
  fantasai: We can treat inline-block and inline-flow-root as the
            same
  fantasai: alternatively we can treat ... as ...
  <fantasai> Treat inline-block and inline flow-root as
             syntactically equivalent. Make both of them blockfy as
             display: block. Treat inline-block and inline flow-root
             as syntactically distinct. Make inline-block blockify
             as display: block; inline flow-root will blockify as
             flow-root.

  fantasai: The advantage of first approach, is that the inline-foo
            are all syntactic equivalents.
  fantasai: The advantage of the second approach is ...
  <jensimmons> I vote (b). It makes sense that the flow-root-ness
               would stick around, imho.
  Rossen: The 2nd approach will round trip nicer through the OM
          right?
  TabAtkins: Doesn't matter yet.
  Rossen: The distinction between display outside and inside, which
          one will round trip more gracefully.
  fantasai: We have defined all the inline-* to all the
            inline-space-* etc.
  fantasai: We didn't have the display module in time to avoid the
            inline-... and inline-...
  fantasai: if you have a inline-space-table and read it back out in
            the OM it will take the shortest most compat form and
            return inline-table.
  fantasai: If we want the 2nd approach we have to not convert,
            maintain as a separate thing, e.g. inline-flex two ways
            to syntactically define it and would not collapse.
  Rossen: If we blockify a display block rather than inline flow
          root, and you read back the display and set it back on the
          same element, you are now going to turn an inline block
          into a block.
  fantasai: Yes that happens right now
  fantasai: for flexes and other things that blockify
  fantasai: happens in 2.1 and flex and grid.
  <fantasai> (via abspos, floats, etc.)

  Rossen: My understanding is ... blockification as opposed to flow
          root in terms of where positioned, it will try to be block
          as much as possible.
  TabAtkins: I am confused about what you are trying to say Rossen
  TabAtkins: anything inline-ish becomes blockish
  TabAtkins: inline-root becomes flow-root
  TabAtkins: inline-block becomes block.
  Rossen: The inline block will become a flow root?
  TabAtkins: Yup.
  Rossen: If I read back (static) what will be different.
  Rossen: Which one of those will be (static) be better (siren)
  Rossen: which of those two if re-parented, if any will have more
          expected behavior.
  TabAtkins: The flow root one will
  TabAtkins: that is the reason why blockificiation turns a
             inline-block into a flow root
  Rossen: ok that is why I am leaning more towards flow root.
  TabAtkins: So that sounds like you are suggesting 2nd one:
  TabAtkins: inline-block becomes block for legacy reasons
  TabAtkins: but inline flow root becomes block flow root.

  <fantasai> Option A: inline-block -> block; inline flow-root ->
             block
  <fantasai> Option B: inline-block -> block; inline flow-root ->
             flow-root

  astearns: Any other conversation on this?
  astearns: Any obj to inline space flow become inline flow root?
  fantasai: Main concern, we no longer treat inline-* and inline
            space * as equivalent.
  TabAtkins: For this specific value.
  astearns: In part for legacy reasons.
  TabAtkins: Entirely for legacy reasons.
  fantasai: But that means if you compute inline foo ...
  fantasai: But now we have to keep them distinct in the OM as well.
  TabAtkins: Yeah we will have to.
  astearns: Is your desire for syntactic equiv an obj?
  fantasai: No, just wanted to make it clear.

  dbaron: It is an extra point of confusion in that before we could
          say these two things are equivalent
  dbaron: but it is now more complicated because in this one case
          they are not.
  dbaron: The other question is whether you maintain separate
          computed values for just this one case or the whole
          possible space of values.
  TabAtkins: hmm.
  astearns: I would expect we would maintain equivalent where we can
            and this is the exception that proves the rule.
  <dbaron> I'm not crazy about the idea, but I'm not objecting to
           it...

  astearns: So.
  astearns: Do we resolve to use option b and work through the
            details? or shall we spend some more time working the
            details in the issue and come back to this?
  TabAtkins: I think we should resolve on b and I can open a
             separate issue on the point that dbaron just raised.
  TabAtkins: I'll open a separate issue for that.
  fantasai: My concern is that if we go with option b and then we
            have the other discussion, then we find we don't like
            and want to come back to option a.
  fantasai: b implies at least two things that a does not in terms
            of how other values behave
  fantasai: but that was not discussed in the issue in terms of a vs
            b.
  astearns: fantasai do you want to postpone making the resolution?
            or ok to have provisional resolution for b?
  fantasai: That is a more important discussion to have
  fantasai: and then decide this issue because I think it is less
            important.
  fantasai: The resolution here should depend on that discussion.
  TabAtkins: I disagree but I have no problem with changing the
             resolution later
  TabAtkins: if based on another discussion we decide we resolved
             wrong.
  astearns: When you open the new issue TabAtkins please link back
            to this one, so once we decide on the other one we can
            see if this resolution still holds.

  ACTION TabAtkins open new issue on what we are doing with the
         syntax equivalencies and linking back to this issue so we
         can revisit this resolution
  <trackbot> Created ACTION-852

  astearns: Any objection to resolving on option b for current issue?

  RESOLVED: We are provisionally going with option b.

Propagation of text-decoration with display:contents
----------------------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1136

  astearns: Propagation of text-decoration.
  TabAtkins: Question: how do text-decorations propagate? on what
             tree do they propagate? they are not inheritance.
             something after inheritance. on box tree? element tree?
             or something else magic?
  TabAtkins: There are several arguments for box tree, in particular
             compat constraints.
  TabAtkins: If you have an inline with an underline
  TabAtkins: if you have a span underline ...
  <TabAtkins> <span underline>foo <div>INTERRUPTION</div> bar</span>
  TabAtkins: If you have this^
  TabAtkins: the foo and the bar get underlined, the INTERRUPTION
             does not
  TabAtkins: because the block has broken the span apart.
  TabAtkins: If the decorations propagated through the element tree
             then the div would get the decoration
  TabAtkins: but if propagate through the box tree then that is what
             we see.

  dbaron: It is already specified in terms of the element tree, and
          just specifies that case
  <fantasai> https://drafts.csswg.org/css-text-decor-3/#line-decoration
  TabAtkins: It is not well specified from what we can see.
  dbaron: I believe we implemented it from a spec that was
          relatively clear.
  fantasai: I believe that was 2.1
  fantasai: which does not distinguish between elements and boxes
            very well.
  dbaron: It was readable in terms of elements, and describes that
          case as don't do this thing
  dbaron: It explicitly said that.
  <fantasai> https://www.w3.org/TR/CSS21/text.html#decoration
  TabAtkins: That implies that display:contents as implications on
             how we treat that
  TabAtkins: whether that affects the decision.
  fantasai: It shouldn't make a difference element vs block tree in
            general, but it will affect once we have display:content
  fantasai: Question is whether you can propagate to text nodes
            which are new thing now.

  TabAtkins: Side question if you specify it on a display:contents
             element does it propagate to its contents?
  dbaron: In terms of that we impl on the box tree.
  TabAtkins: According to r... so do we.
  astearns: Any other interop data?
  <dbaron> we walk up the box tree, but through placeholders for
           out-of-flows
  fremy: Technically I can try... in IE.
  TabAtkins: I got it the opposite.
  TabAtkins: Fix up will interrupt decoration.
  fremy: example?
  <TabAtkins> https://bugs.chromium.org/p/chromium/issues/detail?id=553174
  TabAtkins: Yes I have a CR example^
  TabAtkins: This is interruption due to inline table. We are
             propagating, other browsers do not.
  dbaron: Beware of tables when testing text-deco because there are
          quirks mode diffs.
  fremy: ... apparently ...
  <dbaron> The Gecko code is at
https://searchfox.org/mozilla-central/rev/b318c7dca7392bd16c0b11929f55b1be133f0b31/layout/generic/nsTextFrame.cpp#5373

  TabAtkins: What about the 2nd case? where element is an inline
             table?
  TabAtkins: (describes bug)
  fremy: I see what you mean.
  TabAtkins: Our impl is inconsistent.
  TabAtkins: The fact that these two cases should be identical in
             any sensible interpretation implies that it should be a
             box tree concept possibly with some nods to the element
             tree e.g. block that splits inline.
  fremy: I don't know either we would have to change something
         either way.
  astearns: Sounds like we need to spec this as box-tree concept and
            file bugs on browsers.
  TabAtkins: Chrome has a bug filed.
  astearns: Any objections to defining this as a box-tree concept?

  RESOLVED: Define this as a box-tree concept.

Should anonymous boxes always inherit through the box tree?
-----------------------------------------------------------
  github topic: https://github.com/w3c/csswg-drafts/issues/1118

  TabAtkins: This is about inheritance, not normal inheritance.
  TabAtkins: Do they inherit through box tree or element tree?
  TabAtkins: We have a diff in the thread there as a suggestion.
  TabAtkins: Aside from a few nits we don't have obj. well we have
             anti as disagreement.
  TabAtkins: Also says webkit could impl without much trouble.
  TabAtkins: It touches several specs
  TabAtkins: the implication of it is that in the example, first
             post in the thread
  TabAtkins: using the code provided where section provides a color
             and div provides a color
  TabAtkins: but div is display contents, the text will still be
             green
  TabAtkins: it won't turn red just because there is display
             contents involved.
  astearns: But if the div had an underline?
  TabAtkins: Decorations are weird and should not impinge on this.
  TabAtkins: This is just about normal inheritance.

  TabAtkins: Recall these two examples:
  <TabAtkins> <section color:red><div color:green display:contents>
              Foo</div></section>
  <TabAtkins> <section color:red><div color:green display:contents>
              <span>Foo</span></div></section>
  TabAtkins: First example, should text be green or red.
  TabAtkins: Second example, there is an absolute correct answer,
             and no way to question it.
  TabAtkins: 2nd example span inherits from div in ordinary way, and
             then foo gets its color from span.
  TabAtkins: It's just the 1st ex that we have question about.
  TabAtkins: Putting in an empty span like that shouldn't change how
             inheritance works
  TabAtkins: so the edit we put together, makes node text be stuff
             in the tree.
  TabAtkins: We have text nodes in the element tree, text runs in
             the box tree
  TabAtkins: means inheritance works the same in both cases
  TabAtkins: (describes color and boxes)

  astearns: I have not reviewed the diff, but I like the concept as
            described, would like to go forward.
  TabAtkins: If people feel they need more review that would be fine
             but if they are ok with it I would like to commit it.
  fremy: For us I think it would be fine.
  astearns: Any obj to going fwd with diff?

  RESOLVED: let's try it out, go forward with the diff

  astearns: Almost to the hour. that's it for today.
  astearns: Thanks everyone for calling in.
  <astearns> REMEMBER that next week's meeting is shifted to 4PM PT

Received on Wednesday, 7 June 2017 12:21:35 UTC