[CSSWG] Minutes Tokyo F2F Fri 2017-04-21 Part V: Containment, Scroll Anchoring, Line Height Calculations [css-inline][css-contain]

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

CSS Contain

   - RESOLVED: Style containment works on internal table boxes,
               size containment does not work on internal table boxes,
               other containments only work on table cells.
   - RESOLVED: CSS Contain to CR

Scroll Anchoring

   - RESOLVED: Request to graduate from WICG to CSSWG

Testing user agent stylesheets

   - There was general agreement that there should be test for UA

CSS Inline: Line Height Calculations

   - RESOLVED: Add leading to union of ascent and descent.
   - RESOLVED: Replace definition of 'line-height: normal' with
               vaguer definition, errata CSS2.
   - Investigation on what browsers do and what we all should do
     will continue.


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

Scribe: surma

CSS Contain

   Florian: Last issue was what to do if contain is on an internal
            table element
   <Florian> http://www.w3.org/mid/55BA836C.6060404@mozilla.com
   Florian: We have different containment modes, each needs an answer
            for which tables parts. Style containment: should apply.
            paint containment: should apply. Size containment: should
            never apply
   dbaron: Including cells?
   Florian: Including cells! We could make it work, but it would be
            undefined behavior. We could define it, but probably not
            worth it.
   Florian: If we say size the call as if empty, and then do in-flow
            content is not an operation that currently exist.
   Florian: The use case for containment on cells is for
            spreadsheet-style sites. You could do the cells
            independently and place them on the grid.

   iank: Does paint containment make sense on table rows?
   Florian: Why not.
   Florian: I’d also be okay with allowing it on cells, but not rows.
   [general agreement]
   <fremy> @Florian @iank Right now I doubt because the background
           color of the table row is clipped by the cells which can
           come from other rows due to spanning

   dbaron: We need to define how paint containment works with
           collapsing borders.
   Florian: As a general rule we should disallow containment if the
            implementation is not obvious.
   iank: So paint containment on the table or the cells, but not on
   Florian: Yes.
   Florian: The same for layout containment.
   iank: Same for size containment?
   Florian: Yes. Only style containment on all elements.

   <Florian> proposed resolution: style containment works on table
             parts, size containment does not work on table parts,
             the two other kind of containments only work on table
   <astearns> fremy: OK with this?
   <fremy> yes

   fantasai: Fixed tables dont have any of this weirdness, right?
   dbaron: Content can be bigger. I think it gets clipped, but it can
           be bigger.
   Florian: Are we interested in this nuance?
   dbaron: I am not.

   RESOLVED: Style containment works on table parts, size containment
             does not work on table parts, the two other kind.
   RESOLVED: CSS Contain to CR

TAG review of scroll anchoring
   Github issue: https://github.com/w3c/csswg-drafts/issues/676

   <rbyers> Video: https://blog.google/products/chrome/taking-aim-annoying-page-jumps-chrome/
   rbyers: Gave a presentation on it at TPAC.
   rbyers: Wanted it to be opt-out, not opt-in.
   rbyers: This is a feature to avoid jumping while the page is
           loading. We talked about it at TPAC. We didn’t want it to
           be opt-in, so we needed to make sure the heuristics are
           good. We have written all the details in the spec. Shipped
           in Chrome 55. We see it used on 10% of pages views on
           Android. The pages that use it hit the heuristics 5 times
           per page load.
   rbyers: We wanted to check if theres other interest. We can still
           make changes.
   [general signals of interest]

   rbyers: People didn’t notice they had this problem. Now that
           Chrome corrects it, it might get worse in other browsers.
   rbyers: Should we warn on console about hitting the heuristics?
   rbyers: We are careful about spamming warnings

   dbaron: I‘d want this to work when I resize a window, too. That
           shouldn't issue a warning.
   [rbyers checks if it is tied to resizing too]

   Rossen: Let say you have implemented snap points. How much can be
           built on top of this.
   TabAtkins: Nothing.
   rbyers: This lets you customize what is considered an anchor. Snap
           points set the anchors.

   Florian: Is this writing-mode aware?
   rbyers: It should be

   Florian: The interesting part is that the implementation is
            complex, but the api is small, so changes can be made in
            the future to the heuristic.

   fantasai: We should publish a FPWD through CSSWG
   TabAtkins: Since Google is a member of the group, any Googler can
              continue work on the draft, even if the person
              themselves is not a member of the group. Correct,
   ChrisL: I think so, yes.
   ChrisL: If they are not a member, tho, what if they start doing
           whatever they want.
   astearns: We take them off as an editor.
   fantasai: Its better for the editor to be a member of the group
             for access to all the tools etc.
   fantasai: No requirement of him showing up to meetings etc.
   rbyers: We’ll ask him to join.

   Rossen: This is in WICG, no? What is the migration process?
   Florian: We just did it
   Rossen: Not sure that is the case.
   astearns: We don't have a clear handoff process.
   Florian: We take the spec, put it in our repo.
   rbyers: We’ll ask cwilso how to migrate.
   Rossen: We’d like to know as well for future WICG migrations.
           There used to be a high bar, I don’t want to just ignore/
           circumvent that.
   TabAtkins: Worst case I’ll be co-editor
   astearns: It could be nice to have the editor on calls to have
             their expertise.

   RESOLVED: Request to graduate from WICG to CSSWG

Testing user agent stylesheets
   GitHub topic: https://github.com/w3c/web-platform-tests/issues/5625

   astearns: Should we have tests for UA stylesheets?
   dbaron: It’s a good idea. But some results might be an issue
           against the HTML spec rather than the UA.
   fantasai: Maybe the UA stylesheet statements should migrate to HTML

   xidorn: test cascade level?
   dbaron: There are a lot of known issues where what's in the UA
           level vs. the pre-hint level doesn't match the spec, since
           the reverse engineering didn't really consider that, I
           don't think.
   astearns: So general agreement?

CSS Inline: Line Height Calculations
   scribe: fantasai
   github topic: https://github.com/w3c/csswg-drafts/issues/1254

   [This is a grossly-exaggerated diagram of the discussion below:
   The boxes represent glyphs from two different fonts
   whose baseline metrics don't quite match up,
   so their ascent/descent from the shared baseline differs.]

   Florian: We were trying to do things that depend on normal and it
            didn’t match reality.
   dbaron: Spec says that when you have glyphs from multiple fonts,
           where the fonts have different ascent and descent, the
           glyphs end up with different boxes.
   <jet> see Mozilla bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1358377

   [dbaron draws Chinese character and capital B, to represent glyphs
       from two fonts]
   dbaron: spec says that when you draw the background you use the
           lowest bottom and the highest top
   [dbaron draws misaligned boxes, representing the two different
       fonts that are triggered by fallback]
   [dbaron labels height of tallest top to bottommost bottom as
       "content box"]
   dbaron: You add half of the leading to each side (top/bottom) of the
   [dbaron draws leading on each glyph; shorter glyph gets more
       half-leading on each side than taller glyph]
   [dbaron labels distance from topmost edge of leading to bottommost
       leading edge as "line box contribution"]
   dbaron: Spec for normal says to use a value between 1.0 and 1.2 as
           normal line-spacing.
   dbaron: This is not the Gecko behavior.
   dbaron: This is what the spec says.

   Florian: Spec contradicts itself.
   dbaron: Spec describes this behavior, and then says "therefore you
           get X" where X is not what you get out of this behavior.
   [confusion about earlier resolution from yesterday]
   Florian: The other option was to reduce this line box contribution
            to just the value of the leading
   Florian: which was, iirc, what Safari does,
   (which is what Florian and fantasai thought we had resolved on
   myles: We never add padding to individual boxes. We do ceiling and
          flooring and then add leading at the end.
   dbaron: I'm fine with resolving on this, does make this other
           issue simpler.
   myles: I thought we resolved already.
   Florian: dbaron and Alan thought we resolved the other way.
   <astearns> the previous resolution was RESOLVED: fix the erroneous
              conclusion in section 10.8

   dbaron: 3d paragraph on 10.8.1 says to add half leading to each
           glyph. We're saying to add it to the content box.
   fantasai: Content box is not well-defined.
   dbaron: It's in 10.6.1.
   fantasai points at the spec
   dbaron: I guess it's not actually defined.
   dbaron: So define that you add leading to union of ascent and
   fantasai: What's an em box?

   RESOLVED: Add leading to union of ascent and descent.

   dbaron: The thing we resolved gets you 15px lines, but only if you
           don't have a <span> in your line.
   dbaron: What we're talking about is per inline box fragment.
   dbaron: Goal was to make lines 15px high.
   dbaron: This resolution will accomplish that given font fallback,
           as long as you have no markup whatsoever and every line is
           just a single box fragment.
   dbaron: The moment you have both markup and different font
           fallback in the different elements, it fails.
   dbaron: If you have for example:
             Get a taxi with <span>京B</span>
   dbaron: Now you're computing the line-spacing for first piece
           separate from second piece.
   * fantasai is so happy to have this lecture by dbaron <3

   koji: In Blink, we use primary font to resolve content box.
   dbaron: We decided not to do that because wanted to consider all
           the glyphs.

   myles: If you have an element ... your entire line is that element.
   myles: What's primary font vs secondary font?
   koji: If this is the example and no stying on <span>
   koji: Then these two have same font family, then primary font is
         the same.
   koji: Even if this span starts from different font family, use the
         same font.
   dbaron: So you're saying you use the first available font.
   koji: If line height is not normal, yes.
   myles: Are you saying that you ignore the metrics of the
          non-primary font?
   koji: yeah.
   myles: That's not what WebKit does.
   myles: At least I don't think so.
   koji: When we say we compute only once per inline box fragment,
         compute is based on which fonts?
   Florian: Union of all the boxes
   [more confusion]

   [dbaron redraws]
   dbaron: Let's say these are 16px glyphs and you want 20px line
   dbaron: With union thing, we take the tallest top of glyph, and
           lowest bottom of glyph:
   dbaron: Distance here is 19px
   dbaron: To get to 20px, we add .5px to top and to bottom.
   dbaron: In some ways this isn't great, because it gives you
           baseline jitter when you have font fallback
   dbaron: If you use only the primary font and not the others, you
           will not get baseline jitter.
   Florian: But you may get overlap.
   Florian: I think baseline jitter is preferable to overlap.
   dbaron: Generally the variation is not a lot, so unlikely to get
           overflow in most cases.
   dbaron: Unless you push your line height really close to 1.0.
   astearns: ?
   myles: If you a really big paragraph, many lines of text, and one
          line in the middle has a character from a fallback font.
   dbaron: That will push the baseline of that line down, because
           centering union within the line height (19px) rather than
           just the primary font (16px).
   myles: Webkit does that; we just have a little bit of jitter.

   dbaron: One other factor here...
   dbaron: If we did only primary font, line-height-step would give
           you evenly-spaced baselines
   dbaron: But if we don't, then even line-height-step won't give you
           evenly spaced baselines.
   myles: So the problem then is that if you use line-height-step,
          this middle line with the character, might trigger a
          double-spaced line.
   astearns: Sounds like maybe previous resolution, we don't want
   dbaron: Also could consider whether content-box should use primary
   dbaron: Let me finish.

   dbaron: Explanation:
   dbaron: There's a value called normal
   dbaron: In theory this is a number
   dbaron: But actually this is not what Gecko does.
   dbaron: Font has a metric that says what they think the line
           spacing should be.
   myles: Field is called line gap.
   dbaron: You could get the metric from the font and apply it to the
           glyph in that font, and then do the same with the other
           font to the other glyph.
   dbaron: And that would be easy with the previous behavior with
           per-glyph leading instead of union leading.
   Florian: Could do per-glyph leading and union it.

   dbaron: What gecko does is more horrible.
   dbaron: Gecko for line-height: normal
   dbaron: Does per-glyph bounding box computation without external
   dbaron: Then unions that with external leading of the primary font
           added to the glyph height of the primary font.
   dbaron: I don't think this was intentional.
   dbaron: So Gecko will take union of glyph boxes, and then unions
           that with leading box of the primary font.
   fantasai: Maybe not so bad, gets you more regular spacing line to
             line, while still trying to avoid overlap by considering
             union of all glyph areas.

   Florian: I thought Koji had brought up earlier that for some
            languages there are very tall glyphs, and you may have
            that kind in the fallback.
   Florian: So might have something very tall and has external
            leading to get that to look nice.
   Florian: In these cases glyph can go beyond ascent and descent.

   Florian: Are these font metrics reliable?
   myles: Let's not discuss that.
   astearns: So...........

   Florian: So spec says "line height number is like a number, you
            just get to pick the number". This is not true.
   koji: Says use value that's appropriate to the font.
   koji: ...
   koji: Second sentence is very questionable.
   dbaron: The sentences might have been written 10 years apart, as
           we edited CSS2.
   koji: “font of the element” is not defined.
   koji: Earlier paragraph says UA may take all the fonts used in the
   koji: This sentence doesn't make sense to me (second sentence)
   koji: so I ignored it.
   koji: You read second sentence.
   myles: Should be fonts, not font, of the element.
   Florian: That's an improvement, but still undefined.
   <tantek> Indeed this has felt underspecified to me too
   Florian: Based on it, but based how?
   astearns: Vague is better than wrong.

   astearns: Let's resolve to remove wrong parts.
   [Florian quotes spec]
   discussion of prose
   [Spec is all wrong]
   [Need to replace the entire definition]
   [alan asks where new prose goes]
   fantasai: Errata CSS2, define in css-inline-3

   myles: The reason we're discussing all of these computations is
          because if they were to differ you might get double spacing
          with line-height-step.
   myles: Because font metrics differ between browsers *and*
          platforms, will still get differences.
   Florian: Because we don't have a foundational model from which to
            discuss issues.
   koji: Changing definition for non-normal case is easier... doesn't
         change layout.
   koji: Just changes glyph position within the line
   koji: but if we change definition of normal, might break lots of
   astearns: Well, we need to change the definition in the spec in
             any case, because it's not matching what browsers do
   astearns: So proposed resolution is to remove wrong definition of
             normal, and replace with more accurate definition
   fantasai: Will need to be vague.
   astearns: Any objection to a vague but not wrong definition of
             'line-height: normal'?

   RESOLVED: Replace definition of 'line-height: normal' with vaguer

   dbaron: Basically need to say that 'normal' does something based
           on the font that overrides algorithm for number.
   myles: Say all the fonts may be consulted, and line gap of all the
          fonts may be consulted.

   ACTION fantasai: make wording
   <trackbot> Created ACTION-849

   Florian: Previous resolution, koji said it's not what they do.
   dbaron: Matches Safari, not blink or gecko.
   dbaron: Makes rhythm better wrt what spec previously said, but
           worse wrt blink/gecko
   dbaron: Also only helps if you have no elements.
   [discussion of what's better than what]

   dbaron: It could lead to glyph box overlap where there wasn't
   dbaron: You could end up now with negative half-leading
   dbaron: Because before leading would definitely be positive.
   astearns: My understanding was that we were going to size on the
             content box.
   dbaron: content-box is should, not definite.
   astearns: need to discuss content box...
   astearns: Does that affect the previous resolution?

   dbaron: Other factor with content box
   dbaron: tend not to have padding and border, but backgrounds is
   dbaron: Whether to include fallback glyphs in content box...
   dbaron: Do you want fallback glyphs to potentially overflow
           content box?
   dbaron: Or do we want to make sure content boxes are consistent
           across multiple elements?
   koji: I would really want to make heights of lines consistent.
         Don't care so much about positioning within the line.

   Florian: If we don't do the resolution we've just taken, the line
            height may be bigger than the one you asked for. With
            this resolution, if you say line-height: 20x, you always
            get 20px
   [koji doesn't believe this, so Florian is trying to explain it
   <tantek> There is an inevitable design tension between "do exactly
            what I said" and maintaining a strict rhythm, and
            avoiding overlapping pixels / text. Not sure how that
            tension can be resolved in a predictable way. Especially
            with cross-platform/browser font differences, font
            substitutions etc.
   <tantek> I don't have a specific suggestion, but I'm curious what
            methodology the group uses to try to resolve this tension.
   <fantasai> tantek, in general we tend to go with "make it
              readable" over "make it pretty"
   <tantek> fantasai, I agree with that. I'm more wondering about the
            "[ CSS is Awe ] some" type problems

   [There are several diagrams on the board now
   Blue one represents "use the primary font for size and position"
   Black one is "apply leading to each glyph and take union of all"
   Red one is "union glyph boxes and apply leading (could be
   In blue and Red cases, could get overflow...
   in blue case the overflow is all wrt primary font. Red case clips
       a bit from tallest and lowest bits of the combination]

   dbaron: Red and blue will both give consistent line sizes, but
           blue will give consistency even when you have <span>s
   [Florian summarizes and asks Rossen, who suspects they don't
            ignore fallback so probably black or red]
   [dbaron notes this is for non-normal values]
   astearns: We should have description in CSS2.1 with what browsers
             do, so we're actually describing reality.

   ACTION Rossen Verify what is done by each browser (by checking
          Edge and putting on WG to-do list for everyone else)
   <trackbot> Created ACTION-850
   astearns: Anything else?

Meeting closed.

Received on Saturday, 27 May 2017 01:03:49 UTC