W3C home > Mailing lists > Public > www-style@w3.org > September 2017

[CSSWG] Minutes Paris F2F 2017-08-04 Part IV: Multicol, Writing Modes, Advanced Publishing Lab, Inline Layout, CSS Rhythm [css-multicol] [css-rhythm]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 1 Sep 2017 08:50:16 -0400
Message-ID: <CADhPm3tmObDRdt6UUXEckX9LAMuPHHX-TwE_LLh+6sRsMheN9A@mail.gmail.com>
To: www-style@w3.org
  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: rachelandrew to edit multicol

Writing modes

  - RESOLVED: A new CR of writing modes after edits and tests.

Advanced Publishing Lab

  - Florian will keep the working group aware of the Advanced
      Publishing Lab's work https://www.kri.sfc.keio.ac.jp/en/lab/aplab.html

Inline layout

  - Florian will file bugs on the spec and on browsers as a result
      of his testing.  Results here:

CSS Rhythm

  - The group discussed issues around unintentional double spacing.
      - There wasn't clarity as to how bad the unintentional double
          spacing is as there's no usage data.
      - Florian recommended starting work on the block part of
          line-height-step that everyone agrees to be useful and
      - dbaron brought up some work done a while ago that may solve
          use cases by no longer using line height after the grid is
          laid out
  - The double spacing conversation also went into a larger
      conceptual question about the viability of the spec.
      - There were several concerns voices that, as the spec is now,
          it's not robust enough to be truly useful.
      - Some of the issues around ensuring this spec is robust and
          easy to use will not be resolvable until the Inline Layout
          line height issues (see previous topic) are addressed.
      - There was a request to have more East Asian examples as
          currently examples are all Latin which means one of the
          primary use cases isn't well represented.
  - Next the group reviewed a proposal from Tab & Shane
      https://github.com/w3c/csswg-drafts/issues/938 to address some
      of the issues around spacing and line-height. The group was
      fine with Chrome experimenting with this approach, though too
      many doubts were expressed to put it into the spec before more
      experimentation is performed.


Agenda: https://wiki.csswg.org/planning/paris-2017#topics

Scribe: Jet


  astearns: rachelandrew will be editor

  RESOLVED: rachelandrew to edit multicol

Writing Modes

  astearns: Normative change to CR draft.
  <Florian> https://github.com/w3c/csswg-drafts/issues/1391
  astearns: Need a new CR and tests.

  RESOLVED: A new CR of writing modes after edits and tests.

Advanced Publishing Lab

  <astearns> https://www.kri.sfc.keio.ac.jp/en/lab/aplab.html
  Florian: Advanced Publishing Lab started in Keio university
  Florian: Japanese industry driving potentially a new CJKlreq.
  Florian: Group wants to inform CSSWG of their requirements.
  astearns: C & K in scope?
  Florian: Not sure, but likely.
  astearns: Please update the group as needed.

Inline Layout
  github: https://github.com/w3c/csswg-drafts/issues/938

  Florian: From weaknesses of vertical rhythm
  Florian: found lineheight issues from that investigation
  <Florian> https://github.com/w3c/csswg-drafts/issues/938#issuecomment-314690847
  Florian: I did a bunch of testing ^
  Florian: Shows how browsers differ.
  Florian: more interop than expected
  Florian: Safari & Edge are the same
  Florian: Chrome differs
  Florian: Firefox differs.
  Florian: When lineheight is a number or length vs. normal
  Florian: refers to diagram from Tokyo discussions
  Florian: (see github issue for diagram).
  Florian: Can't figure out Chromium baseline alignment-
  Florian: why does chrome behave this way?
  Florian: We should fork the issue for general lineheight.
  Florian: We need to define base behavior of lineheight.
  fantasai: Because the trigger to round up for rhythm depends on
            the computation of line height.
  myles: And you can double spacing in some UAs not others if those
         computations differ.
  fantasai: Right.

  Florian: My goal is general interop on lineheight.
  astearns: Discuss divergence on lineheight:normal.
  Florian: Can isolate individual bugs.

  ACTION: Florian to file bugs with each case

  fantasai: We don't have a spec for these issues.
  astearns: But we have interop except for chrome
  astearns: so Chrome should figure out whether there's a reason to
            diverge, or whether they will fix it
  astearns: and then we can spec the result of that discussion.

  Florian: For lineheight:normal Chrome differs by using the top of
           the tallest used fonts
  Florian: will file a bug on that one.
  koji: We need to see the test.
  Florian: We'll debug later.

  Florian: I had to find fonts with tall ascenders and long
  Florian: Firefox font metrics differ
  Florian: not sure why.
  <dauwhe> Zapfino is a great font to test with, due to its extreme
  <gsnedders> dauwhe unfortunately, licensing doesn't allow us to
              use it in wpt ;P
  myles: If a browser changes the metrics they read from a font,
         every web page will look different. At least for us, that
         would be almost certainly unlikely to happen.
  Florian: In some cases Firefox is the same.
  dbaron: Platform API's differ for metrics.
  koji: Everyone has 3 font metrics.
  Florian: Chrome & Safari same on Mac.
  Florian: Chrome & Edge same on Windows
  myles: Some fonts are just weird.
  myles: For at least fonts on at least one platform, at least one
         of the metrics of the font returned by the system API
         doesn't appear anywhere in the font.
  Florian: The tests aren't clear re: metrics, but does show the

  Florian: I checked the content box for inlines--also no interop.
  Florian: On Chrome, doesn't depend on font metrics or lineheight.
  fantasai: Spec says content box can't depend on lineheight
  Florian: Firefox depends on font metrics and not lineheight.
  * fantasai notes for the minutes that Florian is summarizing the
             comment he linked to earlier, so details are all there
  * fantasai notes for the CSSWG that fixing interop on this issue
             was one of the reqs from TTML
  Florian: [notes Chrome bugs]
  fantasai: Is it 1 em?
  fantasai: 1 em is at least predictable.
  Florian: Not 1 em.
  Florian: More testing needed.

  <dbaron> FWIW, Gecko has 4 platform-specific font backends: (1)
           FreeType (used on Linux and Android), (2) Mac (3) GDI (
           Windows) and (4) DirectWrite (also Windows)
  <myles> dbaron: macOS has CoreText and CoreGraphics and they may
  <dbaron> myles, I think we're using CoreText
  <myles> dbaron: 💯
  <dbaron> myles, er, wait, there's a pointer to both objects :-P
  <myles> dbaron: 💯💯✅
  <dbaron> myles, InitMetrics seems to use mostly CG* APIs
  <dbaron> myles, I think we use Core Text only for fonts with color
           bitmap glyphs

  Bert: CSS2 recommends 1em or height of the ascender to descender
  <Bert> "The height of the content area should be based on the
         font, but this specification does not specify how. A UA
         may, e.g., use the em-box or the maximum ascender and
         descender of the font. "
  <Bert> (This is from CSS2)
  <Bert> https://www.w3.org/TR/CSS2/visudet.html#inline-non-replaced
  astearns: It differs depending on the platform font subsystem.
  Florian: Firefox differs with Outlines
  Florian: outline allows a lot of leeway
  Florian: and Firefox diverges most.
  Florian: Please review the tests.
  astearns: File the bugs and have the browser engineers challenge.
  fantasai: We want interop and sane behavior so file spec bugs not
            just browser bugs.

  fantasai: Resolve on content box height?
  Florian: We have 3 behaviors, Chrome I can't figure out at all.
           Doesn't seem to depend on line height or font metrics.
  Florian: Firefox ....
  astearns: If we file a Chrome bug, we can get interop
  astearns: despite no spec.

  fantasai: We should specify what the TTML folks can use.
  <dbaron> I think there are probably much larger audiences than the
           TTML folks who care about this.
  <fantasai> dbaron, not sure who that is, but pretty sure they'd
             agree on having something controllable and predictable
  Florian: Using ascender/descender lengths is unpredictable.
  dbaron: may be concerns re: e.g., accent marks not hanging out of
          the background
  dbaron: and that might be more important for Vietnamese than for
  Florian: Content box depending on font metrics is very
  Florian: We can resolve on Safari/Edge behavior re:
           lineheight:normal being a bug
  Florian: lineheight != normal returns different sizes
  astearns: Currently not a spec violation
  <astearns> but we should probably make it one
  <dbaron> I think it is a violation of
  <astearns> dbaron: fair - "The 'height' property does not apply
             <to the content area>" does seem to be relevant
  <dbaron> I guess it's violating the "should" that it's based on
           the font

  fremy: We can't resolve if we don't know what to spec.
  fremy: Please file more specific issues.
  Florian: We'll split the topic.
  fantasai: File issues against CSS inline and CSS2.
  Florian: I tested 2 ways: line stacking and with border. Same
  fremy: Spec proposes 2 solutions
  fremy: not sure how we choose either.
  fremy: I need to check Edge code
  fremy: but maybe we consider line-height to be intent from authors
         they want control.
  Florian: interop is fixable.

CSS Rhythm
  scribe: fantasai

Accidental Double Spacing
  github: https://github.com/w3c/csswg-drafts/issues/938

  <astearns> https://groups.google.com/forum/#!msg/mozilla.dev.platform/cnEN_sccXJY/1ddo5XifAwAJ
  koji: I'd like dbaron to explain his opinion.
  dbaron: Current approaches are going to lead to things that are
          fragile wrt behavior between browsers, or even same
          browser on different platforms
  dbaron: where you get double-spacing of lines in unpredictable
  dbaron: There are alternative approaches which would not lead to
          this problem
  dbaron: But I'm not interested in focusing on this right now.

  dauwhe: Are you concerned about just the inline step sizing, or
          all of css rhythm?
  dbaron: Right now not looking at anything.
  dbaron: I'm discouraging ppl from implementing this feature
          because I don't think it's something that should be
  koji: Same issue as double-spacing.
  dbaron: Some of the ways to solve it might be to use an entirely
          different design, whereas github issue is trying to keep
          the same design and trying to find small fixes for
  koji: Your concern is different font metrics causing different
        result is the problem?
  koji: Original issue was line-height normal causing problems.

  Florian: There's a general problem and a specific case of that
  Florian: General problem is when different font metrics or
           different ways to implement line height or things of that
           nature cause the layout to work just fine in one browser
  Florian: and to be entirely double-spaced or randomly
           double-spaced in another browser.
  Florian: That's the general worry.
  <dbaron> or different font availability
  Florian: Within that space, this github issue identifies one case
           where this happens.
  Florian: If this is the only case where this happens, maybe
           dbaron's worry goes away.
  Florian: If there are more instances of similar worries, we'll
           need lots of patches.
  dbaron: Another major case is font availability, where you have a
          font available on one platform and not on others.

  koji: I heard one example
  koji: but dbaron's concern seems to be a different case.
  Florian: It's the same.
  Florian: If line-height-step is a user-defined specific value
  Florian: and line-height is a different user-defined value
  Florian: then this is generally predictable.
  Florian: If line-height is smaller than line-height-step generally
  Florian: If there's one line that has a superscript and double
           spaced that line it's kindof okay
  Florian: but double-spacing entire the page is a problem.
  Florian: If you set [various combinations, various results]
  Florian: Different fonts, different ways to read metrics from the
           font, different implementations of what 'line-height:
  Florian: cause differences.
  dbaron: I'm not sure that even line-height: <number> is
          predictable, requires testing mix of elements
  <dbaron> ... where some have font fallback.
  fantasai: Another case that could cause problems is different line
            wrapping,e.g., if superscript and subscript end up on
            the same line, it could get taller.
  Florian: Point of feature is normalization of line heights so a
           few lines double-spaced probably okay, but all lines not
  Florian: Primary font doesn't have CJK and other font does, then
           many lines with mix of fonts.
  Florian: line-height to specific number, it's okay
  Florian: but if you have spans in the middle of that, you might
           trigger problem often.
  fantasai: It's broken if the author sets something precisely
            expecting no gaps in the general case; they'll be upset
            if they see gaps.
  fantasai: You won't have a case that's extremely painful for the
  astearns: Author shouldn't use this if they can't stand occasional
            double spacing.

  jet: On dev.platform, was a question of whether authors really
       want this feature.
  jet: Haven't heard demand from authors outside Koji here in this
  jet: Do people want that?
  Florian: People do want vertical rhythm, absolutely.
  jet: Chromium has it behind a flag, but have people been building
       websites with it and saying "yes I absolutely want this"?
       Haven't really seen that.
  <myles> jet++
  fantasai: People want vertical rhythm, but is this the feature
            that will solve it?
  fantasai: We want this spec to be robust and integrate with the
            rest of CSS elegantly.
  fantasai: I don't think this feature fits that description.
  fantasai: Our goal for features we design here in the CSSWG is to
            be flexible, robust, powerful, easy-to-use, and
  fantasai: We intend for them to fit within, integrate with, and
            enhance the CSS system
  fantasai: Not be a hacky workaround to some particular issue.
  fantasai: I don't believe this feature fits that design
  fantasai: Additionally, I don't think it does a good job of
            addressing the use cases.
  fantasai: Absolutely, people want control over vertical rhythm
  fantasai: But their problems aren't largely about lines within a
            long wrapped paragraph of text being slightly off-kilter.
  fantasai: The breaks in rhythm are largely introduced by
            block-level interjections in the flow of text.
  fantasai: Things like headings, figures, tables, and block-quotes
  fantasai: This feature does not address these use cases.
  fantasai: It at best allows a hack of turning these block-level
            elements into inline-blocks in order to use this feature
            to control rhythm.
  fantasai: I don't believe this feature is well-designed.
  <myles> fantasai++
  <tantek> fantasai++
  <dauwhe> fantasai+^+^+

  astearns: I absolutely agree that block-level interjections are
            also a problem, but I don't agree that they're worse
            than line box stepping
  fantasai: much of the jitter in line boxes is due to problems
            with our line layout model, which we need to fix

  koji: I thought Kobayashi-Sensei explanation in Tokyo was more
  koji: discussion wasn't
  koji: what he said was what Alan said
  koji: not sure about Latin, but for Japan.
  koji: What he said was when block-level interjection is big enough
        he wants other factors wins over getting back to original
  astearns: My impression was that his opinion was that it was
            acceptable but still not enough.
  koji: I talked with ppl who attended, ppl agreed with me
  koji: maybe translation problem.
  * fantasai suggests digging up the minutes
  koji: What he explained was vertical rhythm when objects intervene
  koji: Should be done like justification, so that each text block
        and image and blockquote are like characters in the "line
        box" of the page.
  koji: Each space to have equal length is more important than
        returning to the rhythm.
  koji: Line grid can do it, or maybe other features, but then have
        to adjust grid after intervening objects
  koji: but line-height-step or block-height-step doesn't have this
  koji: What sensei didn't say, is making block height to step.

  dauwhe: A couple things, one is that I would love to see some East
          Asian examples of how this feature fixes problems of East
          Asian typography.
  dauwhe: Examples have been in Latin, so hard for us to see the
          goal of this feature as designed.
  dauwhe: Also want to say that wrt Latin typesetting in general, I
          agree with fantasai.
  dauwhe: Last thing we want to change is line height of the blocks.
          This is the worst result, lowest priority. Prefer to
          adjust spacing around blocks.
  dauwhe: So I would like to see more targeted use cases for the
          case of East Asian, since in Latin this solution is not as

  Florian: In Latin text, you have ascenders and descenders so the
           visual edges of the line is irregular.
  Florian: Whereas in CJK if the spacing is irregular, it is very
  Florian: So a small superscript that sticks out and slightly
           shifts the line is really bad.
  dauwhe: It's pretty bad in Latin, too.
  Florian: So that is one part.

  Florian: Another response is to fantasai
  Florian: wrt her design goals of CSS.
  Florian: Early incarnations of this feature were very much not
  Florian: We have made changes to decrease its powerfulness to
           increase its robustness.
  Florian: I don't think it's robust enough yet.
  Florian: When I'm done with fixing interop on line height, then
           will look at robustness of this feature.
  Florian: I'm not sure we can make this feature robust enough, but
           either way this depends on how we fix interop of line
           height calculations.

  koji: We seem to be discussing two topics, one is fundamental
        design and the other is this problem of double spacing
  Florian: The design of this feature makes it easy to use in some
           cases and very broken in others. If we can't fix this, we
           can't use this feature.
  koji: Fundamental to vertical rhythm that some authors want to
        take as much step as font metrics says:
  koji: if font is taller, want to take more steps, as much as
        needed to fit font
  koji: whereas in some cases we consider accidental
  koji: and that happens in line grid, too.
  astearns: Same concern about accidental double spacing of
            everything is a problem both for rhythm and for line grid
  astearns: and we can't take either of the proposals if accidental
            double spacing of everything is prevalent enough to be a
  astearns: Accidental double spacing is prime example of the design
  astearns: still talking about double spacing.
  koji: What if double spacing happens in line grid, too?
  myles: I don't think anyone has made the argument that line grid
         should ship instead of this
  myles: people are simply objecting to this feature on its own
         merits (or lack thereof).

  Rossen: First comment about jet's comments
  Rossen: What jet mentioned earlier about lack of examples /
          requests, we've had a lot of requests internally
  Rossen: mostly ppl building multicol based layouts
  Rossen: fairly impossible to make things align in terms of line
  Rossen: To that point, what fantasai said earlier was right on the
  Rossen: Most of the problems aren't due to lines, they're mostly
          due to headings and other blocks that are not multiples of
          line height.
  Florian: jet's comment was looking for evidence that this
           particular solution addresses the use case, not evidence
           that the use case was important.
  Rossen: I was hoping to know, it's been already 1.5-2yrs that
          we've been working on this.
  Rossen: It's certainly the case that in CJK the use cases seem to
          be predominantly based on just lines and lines of text
          without that much blocks or other things in the flow that
          contribute to irregularity.
  Rossen: In those cases perhaps line grid makes sense, maybe that's
          the best thing to do there.
  Rossen: At the same time, most of the objections I hear constantly
          against it
  Rossen: are based on the other sets of requirements
  Rossen: which are for multicol block-level stuff we were talking
  fantasai: No, there's two sets of objections one is the
            block-level concerns, the other is the robustness

  <astearns> headings are not lines?
  <astearns> (I know they're blocks)
  <fantasai> astearns, the reason I'm saying that headings aren't
             lines isn't that they aren't made up of lines, of
             course they are. But generally the problem isn't having
             each individual line snap to a multiple of the base
             line height, it's having the heading as a whole snap to
             that multiple.
  <fantasai> because for headings you don't want to have large line
             heights or gaps between the lines
  <fantasai> astearns, you usually want them quite tightly spaced,
             in fact, because they are a larger font size
  <fantasai> astearns, but you want space around them, and you want
             the total space taken up by the heading -- like the
             total space taken up by a figure or table or blockquote
             -- to fit into the rhythm

  Scribe: TabAtkins

  fantasai: Part of the robustness concerns is all this non-interop
            stuff for line-height in general is part of it.
  fantasai: Other thing is that the way we do line-height calcs in
            general creates jitter.
  fantasai: So even if we have line boxes with same height, that
            doesn't handle the jitter case that CJK needs us to solve.
  fantasai: So even without browser variance, even with a strict
            vertical rhythm, within the linebox the line moves, and
            line-height-step doesn't fix that.

  Rossen: Many of the requests that we (Microsoft) has had for this
          style of feature are caused by interjecting blocks in
          between many flowing lines of text. [myles: therefore
          those aren't solved by this particular solution]
  fantasai: So if your concern is within a paragraph keeping a
            rhythm, we need to fix interop *and* maintain the
            baseline-to-baseline height.
  fantasai: Because of the way we center content in the linebox, if
            the content is slightly larger but doesn't spill out of
            the linebox, it'll jitter.
  koji: If you solve that, even when you do, if the font-size is
        different, you'll still need line-height step.
  koji: So it doesn't seem to be a reason not to do line-height-step.
  fantasai: The only case you need line-height-step is if, in the
            middle of a paragraph, you want to double-size a
            particular line because it includes larger content.
  <dbaron> I could bring back line-box-contain with stepping
           extensions that I think would be more robust, at least
           for some values of line-box-contain.

  tantek: How long has Chrome been shipping this behind a flag?
  koji: A year or so.
  tantek: For a feature we all agree conceptually there's demand
          for, we should have seen at least a handful of
          experimental demo sites using them.
  tantek: We haven't seen that, or if we have, please provide the
  <dauwhe> the only codepen tagged with line-height-step is by

  tantek: Second is, I'm increasingly concerned with shipping
          features that *almost* work, but are fragile and easily
  tantek: Having witnessed all the float/columns confusion, having
          it break easily, that makes people distrust CSS as a whole.
  tantek: Would be unfortunate to have the whole concept damaged as
          a result.
  tantek: So that's why providing the block-level solutions might
          make it *just* dependable enough to make it usable in
  tantek: It won't be perfect, but can it be *reliable enough*.

  koji: I tried to talk to some webdevs; my feeling so far is that
        the experimental flag building sites works in US, but not in
        international, where pops are smaller and people are less
        willing to spend effort helping standardization.
  koji: So they generally say "we'll try when it ships, but can't
        spend much time before that".
  koji: For robustness, as far as I understand, your "robustness" is
        different from fantasai's concept.
  tantek: Could be.
  * fantasai doubts it
  koji: I think you're more about accidental jumping.
  koji: I think earlier we were talking about, when we get the
        future stack thing - if it gets off the grid, it accumulates.
  koji: That part is design - Japanese vertical rhythm is different
        from Latin's.

  Florian: Earlier fantasai was saying that this feature isn't quite
           good enough; while it solves locally the size of the
           line, it doesn't do the position.
  Florian: Earlier feature did address that, but made it more
  astearns: It solved that using the baseline ratio.
  Florian: So that's a bit of the difficulty with this feature.
  Florian: I haven't given up hope, but I don't know if at the end
           of the process it'll still be useful.
  Florian: Currently kinda useful and kinda fragile; was earlier
           more useful and more fragile; will it be useful at all?
  Florian: So we have a feature that's either too fragile and not
           useful enough, or one that's too difficult to figure out.

  Florian: Otoh, there's a simple and useful feature that solves the
           block side of the problem, which we most agree isn't
           quite enough.
  Florian: But I don't think anybody thinks the block feature is
           insufficiently robust, or not useful.
  Florian: So I recommend people start on that, rather than being
  Florian: As to whether this is still useful when it's robust,
  Florian: In parallel, I think it would be nice to try and make
           line-grid simpler in terms of impl.
  Florian: Nobody's been willing to bite the bullet yet.
  Florian: If someone can find a magic solution, prizes!
  <fremy> nice summary, Florian

  * fantasai is reminded of trains. New shiny stops are exciting,
             but maintenance and upgrades like computerized
             signaling are actually more important to a functional
             transit system
  <fantasai> similarly here shiny new line-height-step seems
             exciting, but fixing the interop and jitter (which are
             two separate problems) in line layout in general is
             what will make rhythm functional

  fantasai: I don't think that finding the third solution is as
            impossible as you think.
  fantasai: First, we need to solve the jitter problem.
  fantasai: We're wasting our time if we don't solve that.
  fantasai: Requirement for any solution, and it's not specific to
            line-height-step or line-grid
  fantasai: We just need to fix line layout.
  fantasai: We need to continue and prioritize the work that florian
            has been doing, to fix line layout.

  fantasai: Second, we need examples of where this specific feature
            is a solution to a problem.
  fantasai: I think this is solving a problem of fixing line-heights
            within a wrapped paragraph, by doubling the spacing of
            that line, and I don't think anyone wants that in

  dbaron: I think one thing we should look at to address this is
          having whatever the solution is be a bit more of a mode
          switch than what we're looking at.
  dbaron: To some degree line-grid is such a mode switch.
  dbaron: 14 years ago I had a proposal for line-box-contain, in the
          ED for linebox for a decade, shipping in Safari for a
  dbaron: That tried to add all the detail for how to consider what
          should affect the linebox.
  dbaron: But to a good extent there's only three values that are
  dbaron: One is what we do in quirks mode, one is what the specs
          say, one is what devs actually want.
  dbaron: It's a little complicated, but it's in the spec, hard to
  astearns: So in addition to box-sizing, we should have line-sizing?
  dbaron: Not where I was going.
  dbaron: One of the things is that you have a property that says "I
          want a line grid at a certain size". Whether it's a
          full-fledged grid or a slightly weaker thing.
  dbaron: I suggest that, once that grid is established and for all
          the blocks that use it (presuming you can turn it off for
          some descendants), we switch line layout to another mode.
  dbaron: We stop stupid things, like honoring line-height on
  <fantasai> dbaron+++++++++++++++++++++++++++++++++++++
  myles: +++++
  dbaron: Only honor line-height on boxes. Honor border or
          margin-box size on inlines, so if they actually overflow
          the line, they make it bigger.
  dbaron: But if you're at line-height:1.25, you don't get the 1.25
          buffer on them.
  dbaron: And from there we can figure out baseline alignment to the
  dbaron: So I think having a non-inherited property that
          establishes a line grid or step-sizing space, is better
          than an inherited mode switch, like line-box-contain was,
          because it serves another purpose as well.
  dbaron: While it has some mode-switching purposes, mode-switches
          aren't that great. Doesn't cascade well.
  <gsnedders> dbaron++++++++
  dbaron: Has some of the effects of a mode switch, but not all of
  iank: A new inline layout...
  dbaron: Not that different. Still doing inline layout.
  dbaron: line-box-contain had a bunch of values that were like
          "block", "inline", "replaced", "text", "ruby", "glyphs"...
  dbaron: When you did your linebox height calc, you looked at the
          list and only considered those.
  dbaron: The standard behavior is "block inline repalced" i think
  <Bert> https://www.w3.org/Style/Group/css3-src/css3-linebox/#LineStacking
  <Bert> (A public link:
  dbaron: Quirks mode is more like "text replaced" or something
  dbaron: But people don't really want inlines considered at all,
          you just don't want glyphs to overlap by default.
  dbaron: The principle isn't complicated, it's just a new step in
          line layout that controls what you consider.
  dbaron: The mode switch would be about changing what you consider
          in that step.
  myles: I think it's still in WK prefixed...
  iank: It's removed from Blink.
  astearns: See if it helps enough for this use-case?
  myles: Which use case? ^_^

  Florian: Having discussed a variant of this for several times, I
           think coming back in a few months with the same
           discussion isn't helpful.
  Florian: I think it's clear that koji and fantasai disagree on
           whether robustness is important/etc.
  Florian: I think it's important if koji could show sites using
           this feature in ways that trigger double-spacing, and say
           "yes, this is what the author wants".
  fantasai: No, you want sites using the feature that show why this
            is good, and the other alternatives can't solve it.
  astearns: We want to evaluate the shipping solution, to see if it
            addresses the use-case.
  astearns: We have a shipping solution, we should have evidence
            that it's enough for some set of people.
  Florian: And specifically, I want to see these examples hit the
           corner cases, without authors getting bad results.
  astearns: Whether the extant examples hit the corners or not, we
            can use them to push them into the corners.
  Florian: Other than that, I don't think it'll be useful to have
           fantasai tell koji it's not useful, and koji saying it
  koji: I'm saying that robustness is different between Latin and
  Florian: Sure, I'm not trying to rephrase; it's just that
           rehashing the same discussion without new info isn't

  Florian: In the meantime there are concrete things we can work on,
           like improving lineboxes. Maybe dbaron's stuff.
  Florian: In the meantime just rehashing is harmful, it blocks us
           from doing useful things on this topic.
  tantek: I think this conversation has brought up some new stuff.
  fantasai: My and dbaron's points were brought up in Tokyo.
  <gregwhitworth> Decent amount of vertical rhythm libs in CSS & JS:
  tantek: I think some new stuff, like examples that use it
  astearns: And I think line-box-contain is new.
  tantek: So I think it's not fair to say it's a complete rehash.
  astearns: But I agree we need examples, "this community won't turn
            on a flag" isn't a good enough response.
  <dauwhe> https://github.com/w3c/csswg-drafts/issues/1257

  koji: Why doesn't printed material show this?
  astearns: We need examples of *this particular solution* trying to
            solve things.
  Florian: Looking at print doesn't help here; it illustrates there
           is a problem to solve, but not that this solution in
           particular solves the problem.
  koji: Word isn't print - if you look at a word doc with different
        installed fonts, you get a similar problem.
  Florian: Usually that happens because of switching between Word
           and OpenOffice, and people hate it.
  Florian: I'm saying that showing examples of *other* things
           doesn't help us see if *your* solution solves stuff.
  koji: If you require that of every i18n feature, we'll never get
        it done...
  Florian: We're not asking for everything, just for controversial
  myles: And there's another possible solution - dbaron's l-b-c.
  <myles> I meant line-grid in addition to dbaron's idea
  astearns: Even without another, this particular solution has
            enough controversy that we want to see successful use of
            it in the wild.

  astearns: Anything else to go into?

  <gregwhitworth> worth noting -webkit-line-grid is on chromestatus
  <gregwhitworth> none of the rhythmic sizing props are
  <gregwhitworth> ^ not sure if chromestatus shows experimental flag
                  items or not

Proposal to adjust 'normal' to value based on line-height-step
  scribe: fantasai
  github: https://github.com/w3c/csswg-drafts/issues/938

  koji: Yeah. There are multiple issues in here.
  koji: One issue has a proposed solution, shane and tab came up
  koji: It's about avoiding accidental jumps.
  koji: I understand it doesn't solve all, but I want people to
        understand the proposal and see if it solves part of the
  TabAtkins: So the ultimate problem is that when line-height is
             normal, it's unpredictable
  TabAtkins: So if you set a line-height-step anywhere near the
             normal value, might look good on your screen not on
  TabAtkins: Proposal is that if line-height is normal and result of
             that would give you a light-height slightly over your
             normal line-height
  TabAtkins: based on some UA threshold of fuzziness.
  TabAtkins: Instead of doubling spacing, reduce to line-height-step.
  TabAtkins: It should hopefully correct any accidental slight
             overlap that you run into.
  astearns: Why UA-defined squishiness?
  TabAtkins: Figure out the right value later.
  *fantasai suggests (normal-1em)/2
  TabAtkins: If we can agree on one later, great, but otherwise
             don't want to sink the proposal by arguing over value
             right now.

  Florian: I believe I understand the proposal but don't understand
           why it helps.
  Florian: If one browser normal is slightly smaller than step, and
           in other browser slightly larger, then it helps
  Florian: But if in your browser it's slightly larger than normal,
           but in other browser it's even more larger than normal
  Florian: then you get single spacing in yours and double sizing in
           the other.
  Florian: So it changes the numbers that trigger the problem, but
           it doesn't make the problem go away.
  TabAtkins: Think set of cases that get fixed are going to be more
             common than set of things that get broken.
  TabAtkins: In order to get broken as you say, you need to set
             line-height-step smaller than your line-height.
  fantasai: Line height normal is unpredictable though.
  Florian: Line height: normal isn't between 1-1.2, it comes form
           the font. It might be 2.7.
  Florian: Within i18n contexts it varies a lot, even though you
           don't see it that much in Latin (aside from fantasy
  TabAtkins: Ignoring fantasy fonts and Zapfino.
  fantasai: i18n
  TabAtkins: You said there's larger variation in the consequences
             of the line box size due to non-Latin character set
             default fonts.
  Florian: I believe so, and I think Koji claimed that before I did.
  fantasai: I suspect you're more likely to get that variation in
            Tibetan and Thai and other fonts that have lots of

  myles: I agree that fuzzy matching is a good way to solve language
  myles: Implementation knows exactly where all the lines go, so
         implementation has all the information it needs
  myles: rather more than the author even, cuz author doesn't have
         font metrics.
  myles: So reasonable to have implementation make lines fit well.
  myles: Previous conversation needs to be resolved before we take
         this though.
  TabAtkins: Might want to evaluate solution with this in mind tho

  koji: I agree with myles that the accidental jump issue has needs
        to deal with some heuristics
  koji: because in some cases we want to squash really tall fonts.
  koji: Implementation can experiment and maybe a few years later we
        find very good values and want to standardize it but at this
        point better to experiment and get feedback
  astearns: Your experimental implementation, if you can get people
            to use you can get data on utility of squishiness.
  koji: Does that solve previous concerns?
  * fantasai thinks not

  astearns: Would anyone object to experimenting with this?
  astearns: 2nd, would squishiness as described make anyone more
            interested in this feature?
  myles: Not for us.
  astearns: So this squishiness doesn't help other implementers be
            interested in line-height-step, but seem to be no
            objections to Google experimenting with it.
  Florian: No objection to experimentation, less certain about
           adding it to the spec.
  koji: If not in the spec, we can't ship it.
  Florian: I don't want to ship this without a flag unless we have
           strong evidence that it is less dangerous than people
           have expressed worries about.
  Florian: Changes to the spec discussed so far don't make me
  koji: Why can't you at least suspect it helps?
  Florian: I suspect it does not.
  Florian: I expect it breaks some fixes some and it's a wash.
  Florian: If it fixes lots and breaks few, pls demonstrate.
  myles: Do we need a resolution for Chrome to experiment behind a
  Florian: No, they want it in the spec so they can ship it without
           a flag.
  astearns: They don't need our permission to experiment, would need
            permission to add it to the spec even though the
            consensus of the group is not that the feature is at a
            point that is OK to ship without a flag.
  koji: Issue was browsers hard-coded differences in line height
        calculations triggering different steps, we're trying to
        solve that, so Chrome doing it doesn't help.
  astearns: You didn't convince Florian, but myles seems to agree it
            might help.
  dbaron: I agree with Florian's concern that it seems to mostly be
          moving the threshold and not actually fixing the bug.
  Florian: I didn't mean that in the long run Chrome should have it
           and others shouldn't add it, I'm suggesting that the only
           implementation we have experiment.
  myles: 100% of implementations will experiment.
  Florian: Add squishiness, come back and tell us if it improves the

  fantasai: Koji's pointing out that we want to find out if there's
            a problem with interop. Chrome can't find a problem with
            interop by itself.
  TabAtkins: To simulate differences in how normal gets interpreted,
             swap around the font list.
  fremy: Or switch from Mac to Windows.
  astearns: OK, think we're done with rhythm.

  Meeting closed.
Received on Friday, 1 September 2017 12:51:12 UTC

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:05 UTC