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

[CSSWG] Minutes San Fransisco F2F 2017-11-06 Part IV: Values and Units, Contains, Line Grid, Line Heights (CSS Inline & CSS2.1) [css-values] [css-contain] [css-inline] [css21]

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 4 Dec 2017 19:29:12 -0500
Message-ID: <CADhPm3s1V1K4bLXKKvHoNj5r7ywzrSO=Gy0y5DoqjVG1fA0rkA@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.

Values and Units

  - astearns requested review of his calc() clamping tests from


  - RESOLVED: Use principal box as the box to which we do paint
              containment clip. (Issue #1809:
https://github.com/w3c/csswg-drafts/issues/1809 )
  - Discussed whether style containment should be affecting pagination
      controls within the element. Tab will clarify what style
      containment is supposed to accomplish in principle so that this
      issue can be resolved accordingly.
  - RESOLVED: Create new counter scopes at style scoping root for
              style containment.
  - The suggested way to address issue #1457
(https://github.com/w3c/csswg-drafts/issues/1457 )
      would be that 'contain' would apply to neither inline nor ruby.

Line Grid

  - The group reviewed dbaron's proposal to comprehensively address
      line spacing:
  - The group wanted to make sure that it covered all necessary use
      cases, but a preliminary pass suggested it would.
  - No one was ready to completely replace existing spec test with
      this proposal, but it will be used when attempting to fix the
      current spec.

Line Heights (CSS Inline & CSS2.1)

  - RESOLVED: Take florian's proposed change to definitive line
  - RESOLVED: Take florian's proposed change for line-height normal:
  - RESOLVED: To define first available font more strictly in the
              fonts model and leave it undefined in 2.1
              (https://github.com/w3c/csswg-drafts/issues/1798 )
  - RESOLVED: Change the wording such that 2.1 is saying you should
              define the content area based on the first available
              font and only that font.
(https://github.com/w3c/csswg-drafts/issues/1804 )


Agenda: https://wiki.csswg.org/planning/tpac-2017#proposed-agenda

Scribe: TabAtkins

Values and Units

  Negative calc() clamping
  github: https://github.com/w3c/csswg-drafts/issues/434

  astearns: I wrote some tests, and modified them before I checked
            them in, and now they're bad tests.
  astearns: As far as I can tell, we have no interop at all. EVery
            browser clamps at a different time, depending on whether
            the animation goes up or down...
  astearns: So I want impls to check on it.

  Scribe: fantasai

To which box does paint containment clip?
  github: https://github.com/w3c/csswg-drafts/issues/1809

  TabAtkins: Whenever element generates more than one box?
  TabAtkins: Which box do we clip to?
  TabAtkins: Suggestion is principal box, that sounds great to me.
  fantasai: The principal box is the box that contains the content,
            seems like the right call.

  florian: List markers?
  TabAtkins: They get clipped if they're outside markers.
  fantasai: Just like for 'overflow: hidden'.
  dbaron: Table captions?
  fantasai: Table wrapper box is principal

  RESOLVED: Use principal box.

Clarify style containment
  Github: https://github.com/w3c/csswg-drafts/issues/1872

  TabAtkins: Question is, why does style containment restrict break
  TabAtkins: Reason why I have these things set is I want to ignore a
             style tree for style computation purposes.
  TabAtkins: Should be able to completely ignore that subtree.
  TabAtkins: Break property if allowed to work would violate that.
  TabAtkins: Break properties propagate up.
  fantasai: They don't affect computation tho.
  TabAtkins: But they affect layout further up the tree.
  fantasai: break-inside doesn't propagate up, only forced breaks do.
  fantasai: Also sounds pretty bad in terms of fragmentation if you
            can't honor 'break-before: avoid'.
  TabAtkins: Avoiding breaks should work, yeah...
  fantasai: ...

  florian: Since contain property is ahead of css-content, should put
           the bookmark-* / string-set prose into the css-content spec.

  dbaron: I'm trying to understand model of possible optimizations
  dbaron: I don't see anything for which this is relevant
  dbaron: Still doesn't feel like style containment to me.
  fantasai: Also if disallowing break-*, then why not margin-*?
  dbaron: It seems like you're trying to introduce something but not
          really worked out what.
  dbaron: Maybe write out what that optimization is to make that clear
  dbaron: and discuss others.
  fantasai: Also pretty sure if break-* needs to be disallowed the
            margin-* collapsing should also... but that sounds more
            like layout containment.

Scoped Counters
  github: https://github.com/w3c/csswg-drafts/issues/1887

  TabAtkins: If you have a style scoped element, which says counters
             are scoped to the subtree
  TabAtkins: does counter-increment create a new counter?
  TabAtkins: Or does it increment the existing counter from the
  <fremy> +1 on this one
  TabAtkins: I think it should implicitly create a new counter scope
             at the style scoping root.
  fantasai: And so counters() would reveal a new level of counter?
  TabAtkins: Yes.
  TabAtkins: Don't want to fuss with the subtree when calculating
             counters further down in the document.

  fantasai: So you're disagreeing with Oriol's comment?
  TabAtkins: Yes.
  astearns: Write a test?
  astearns: So proposed to implicitly create new counter scopes at
            style scoping root for style containment.

  RESOLVED: Create new counter scopes at style scoping root for style

Becoming a formatting context root
  github: https://github.com/w3c/csswg-drafts/issues/1457

  TabAtkins: We addressed this a bit in the past, text we had was bad.
  TabAtkins: Layout containment needs a formatting context root
  TabAtkins: wanted to say that the element ends up being an FC root
  TabAtkins: only a few places where that's difficult.
  TabAtkins: Some are easy:
  TabAtkins: flow root, table, flex, grid, all satisfy condition.
  TabAtkins: For display: flow, becomes flow-root

  TabAtkins: Next issue is with ruby.
  TabAtkins: Ruby is effectively inline element.
  TabAtkins: Wanted to create a ruby inline block flow-root thing.
  florian: We don't have that yet. If it's not useful, do we really
           want to add it?
  TabAtkins: Better to fill the boxes, so this is consistent and
  fantasai: How about saying layout containment doesn't apply to
            inlines, ruby or otherwise? If you want it to apply,
            turn it into an inline block.
  Xidorn: Create a wrapper box?
  TabAtkins: Wrapper boxes are scary and bad.
  fantasai: We have block ruby, it just creates a wrapper.
  TabAtkins: Make something block-like, either inline-block or block
             or something.

  fantasai: For most of these layout modes, the FCR-ification doesn't
            have much effect. Layout is fundamentally the same
  fantasai: but for inlines and ruby, it's a very significant change
            to layout
  fantasai: I'd rather say that layout containment just doesn't apply
            here, so the author is making an explicit decision about
            the layout change they're getting, rather than getting
            such a significant side-effect from a “performance tweak”.

  TabAtkins: My two constraints for this problem is that contain
             should work on ruby because it works on inline, and that
             whatever effect it has should be possible to get without
             using 'contain' for its side-effect.
  florian: Suggestion is to apply contain to neither inline nor ruby.
  fantasai: That is my suggestion, yes.
  astearns: We don't have contain and inline ruby.
  astearns: Is there a use case for contain on inlines?
  fantasai: You can't get that. It turns into inline-block.
  astearns: So if we choose not to apply contain to inlines, what do
            we lose?
  TabAtkins: Just that authors have to take an extra step of declaring
  fantasai: I'm arguing that's a feature, not a bug.
  fantasai: If the author wants to have an inline-block, should be
            explicit about it. If they didn't, then they're not going
            to be happy anyway.

  TabAtkins: Internal table elements?
  florian: We already resolved they don't apply.

Line Grids
  Scribe: eae
  Topic: https://lists.w3.org/Archives/Public/www-style/2017Oct/0013.html
  <dbaron> https://github.com/dbaron/css-line-spacing/blob/master/explainer.md

  dbaron: Based on the discussions we had in Paris. We were talking
          about rhythmic sizing and the connections to line box
          contain. We've also had the line grid module which was
          designed to address many of the same issues and rhythmic
  dbaron: What I've been trying to do is look at the two and come up
          with a minimal viable product for line spacing in css and
          address existing concerns about line spacing.
  dbaron: I've tried to separate out the important pieces, as
          described in doc linked above.
  dbaron: Some people have raised concerns that I have addressed in
          the doc, others have raised concerns that I did not address.
  dbaron: Not interested in talking about naming. More interested in
          important use cases and what developers and designers really
          need form line spacing.
  dbaron: That requires distinguishing what existing tools actually do
          versus what developers actually want.
  dbaron: Figuring out what we need for line-spacing in css requires
          more knowledge about what these requirements are than I
          know. I think we have people in this room that know more
          about this than I do.
  dbaron: People are welcome to read and comment on the doc. There is
          also a github page.
  dbaron: More importantly, I want to determine what the requirements

  florian: I'm not the ultimate expert but have thought about it a
           fair bit. All use cases I want to address are equally
           addressed by your proposal.
  florian: If it is a simplification I'm all for switching to it.
           There are tweaks that might make it better but lets leave
           that to the side for now.
  florian: Fundamental problem shared with line grid.
  florian: From my point of view, if it helps implementation I'm in
           favor of this proposal over line grid.
  dbaron: I don't now what the key differences are. I don't think
          implementability was a key factor.
  florian: I didn't notice anything I missed during the removal
  iank: Is a line grid shared between formating contexts?
  dbaron: I think it is shared.
  florian: Issue I want to tackle later.
  dbaron: I think a lot of the key use cases are driven by things that
          are pretty separate.

  fantasai: One thing that was dropped which we might be able to
            re-add later was to have every other or every third line
            snap to the line grid.
  fantasai: Not super important right now but is issue that comes up.
  fantasai: For instance if you have different font sizes, i.e. line
            with smaller text size that takes up 1/3 the space.
  dbaron: I think of that as establishing a new grid.
  florian: Don't think it is especially critical.
  myles: You're totally right, making an inner line grid that has a
         size of 1/2 is common and something we should eventually
  dbaron: Some ways to approximate it. You could establish a new line
  dbaron: In order to snap baselines you need to be careful in how it
          relates to the other grid.

  myles: Voicing weak support for your proposal. We haven't seen broad
         adoption of existing line grid spec. If this can get better
         support I like it
  florian: Reverse question. Does switching to this increase the
           chance of getting it? What are we gaining?
  dbaron: One thing we're gaining is the changing of the line hight
          model itself.
  florian: I'd argue we should add that as a separate thing as people
           might want it without the grid.
  dbaron: Agree but syntax will be tricky.

  fantasai: From what I understand from previous discussion: there are
            a variety of different levels of strictness re aligning to
            grid behavior.
  fantasai: 1) I want a sane inline model, no grid.
  fantasai: 2) Concept of really strict line grid, like physical pages
            where you can see things from the other side or facing
            pages. Multi-col in general. Where you want text to align
            across columns. Being stricter about grid in those cases
            is more important.
  fantasai: 3) If you gave a large single column of text and an
            intrusion then a consistent set of margins is more
            important than covering an integral number of grid items.
            Readers might not see whether it aligns to a grid in this
            case, so consistency in width of margins might be more
            noticeable. In those cases having a strict grid isn't
  fantasai: We might need both approaches.

  fremy: Whether we'll be more likely to implement. Questions around
         BFC. Flexible columns snap to grid, how would that work?
         Needs to be cleared before we proceed.
  florian: On agenda for later.
  iank: Echo your concerns. As it stands I can't say whether we're
        happy with this proposal. Seems okay but we'd want to limit it
        with regards to bfc, flexbox etc. When line hight changes etc.
        Lots of remaining issues.

  koji: I agree with fantasai that it should be available without
        grid. I also agree that we need a strict grid model.
  koji: I think dbaron's proposal is a little different. We need a
        less strict model as well. I think the flow model works better.

  astearns: Any other concerns or comments on David's proposal?
  nmccully: I also agree that it seems like a good proposal. I have
            concerns about baselines defined in other specs and how
            they relate. You mentioned dominant baselines being used
            to align, other specs talk about other baselines and flow.
            I have use cases that need support for setting different
            baselines. Being able to specify the baseline to snap to
            the grid.
  astearns: Those use cases are next on the agenda.
  fantasai: I think that David's proposal can handle this. Allows use
            of first or last baseline, you also have the option to use
            hanging baseline, etc using alignment-baseline property.
            You cannot have it align the alphanumeric baseline with
            the cap height though, for instance.

  koji: Question to David. The item 4 in your proposal looks like a
        possible solution to double spacing?
  dbaron: I think the changes to the line height calculation reduces
          the double spacing problem depending on ... hard to say if
          it fully solves it but in many cases when used well it'll
          solve it.
  dbaron: E.x if you're going to set a large line height it'll solve
          it more than a small line height. You're now applying the
          height on the line as a whole rather than the little pieces
          thus less likely to exceed height. If small line height more
  florian: If you're setting the size of the grid independently from
           the size of the font then it increases the risk. The
           problem isn't there in your proposal,

  koji: That item 4 can then be applied to line-grid or rhythmic
        sizing? It's a general approach?
  fantasai: Yes.
  fantasai: No syntax for it in the proposal but the feature could be
            made generic by adding such syntax.
  <fantasai> This is listed as the first Open issue
  koji: Thanks.
  astearns: I think it would be interesting to try to apply that to
            the rhythm model and see what comes from it.
  * fantasai agrees with koji & astearns on this point

  astearns: More comments or should we go on to use cases?

  astearns: Both the line grid and the rhythm proposals should take
            David's explainer into account.

  fantasai: I think we should try to fix the inline layout problem,
            helps everyone regardless of grid. This is the #1 priority
            in relation to fixing inconsistent line heights in a
  fantasai: We should continue to work on line-grid and rhythm,
            as both solve different use cases that people want.
  fantasai: block step size is probably easier, would work on that
            first, before line grid.
  fantasai: We should go through use cases and get a clear idea.

  florian: Question. Do we want to try to resolve on replacing
           existing line grid with David's proposal? Or should we
           postpone that decision until after.
  fantasai: Should put note in spec to point to the alternative.
  myles: We shouldn't resolve to replace existing spec without first
         going through fixing to existing spec.
  fantasai: We need to fix the inline model, need a loose grid and
            need a strict grid.
  fantasai: We have a step sizing proposal and a line grid proposal.
            Would work on step sizing next as it is better understood.
            Then to line-grid later.
  koji: ok

  nmccully: Have a couple of use cases for grid snapping. I looked at
            the baseline spec, and there are a couple of overloaded
            terms. There is central but it is not obvious whether which
            opentype baseline it maps to.
  nmccully: Depending on the font and the font design are going to be
            quite different.
  nmccully: Projecting, for CJK layout the relevant metrics are the em
            box. Differ from bounding top/bottom.
  nmccully: Mapping between latin and CJK font metrics are overloaded
            and the interaction between western and CJK content is not
            up to designer. Would like to see more baselines or
            explicit ones for Japanese fonts to allow pairing between
            CJK and Latin with layout as expected. Would like these
            baselines to be available for all fonts.

  nmccully: These baselines are critical for aligning. The metrics top
            center and bottom are then snapped to a grid.
  nmccully: There are different snapping behavior beginning to be
            supported in css. The possibilities where you snap lines,
            whether body grid with 14pt and letting with 21pt and a
            title between two paragraphs where it is larger. You want
            to center that on two grid lines. The options of how you
            position glyphs within that tall line, whether you
            consider the taller one to be the line-hight or the large
  nmccully: You're aligning glyphs within a line and the taking the
            line and aligning it to the grid. Each visible in
            different types of design. All possible variations might
            not be possible with the proposal.
  nmccully: Snapping the first line of a paragraph, two use cases. 1)
            Body text paragraph followed by smaller size one, first
            line is snapped to grid smaller ttype one is not.
            Following one is re-snapped to grid. Subtleties around
            what you do with the smaller line. Whether it is centered
  nmccully: ...two examples. First one is snapping to the top. Second
            one snapping to center.
  nmccully: Is not an even leading amount in first case.
  nmccully: Both cases have adjacent flow that is top aligned in main
  nmccully: This type of snapping, two flows snapping to grid, is one
            of the goals of this proposal
  florian: Would this be solved using a line grid on the larger block
           and disabling it for the smaller one?
  fantasai: If you know the relative sizes of the fonts you can make
            that work.
  fantasai: In the first case you'd have a zero margin or line gap as
            needed, the second case you'd have that plus half the
  florian: You align the stepped block on the dominant baseline.
  fantasai: If you're able to align baselines that is easy to do. If
            you are in a context without relationship and UA can't do
            baselines alignment you'd have to compute the margin.

  myles: Are everything you've shown here is common and valuable and
         are things the css spec need to support?
  nmccully: Yes, I don't think any are edge cases.
  koji: I agree that em top/bottom are important. Can't comment on
        line grid at the moment. em top and em bottom are not well
        defined today.
  koji: I wish we defined it better and how it relates to dominant
  koji: When we tried to do underlines for CJK there was no font
        metrics we could use for it. We computed em top and em bottom.
        Are not defined.
  koji: This might be a good opportunity to finally define them
  nmccully: I agree. One of the things we did in OpenType was to add
            metrics like this. ICF box top/bottom and em top/bottom to
            allow type designers to specifying them for layout engines.
  nmccully: Agree that having the metrics available is essential for
            layout engines.
  koji: It's great to have the metrics, is ill defined.
  myles: If you don't have them, you synthesize?
  nmccully: Yes, have synthesized in engines I've worked on.
  <koji> The OpenType algorithm to synthesize em box is here

  <nigel> sorry to throw this in from another room, but if you can
          define em top and bottom, how about defining the content
          rectangle height? https://github.com/w3c/csswg-drafts/issues/814
  * fantasai notes https://drafts.csswg.org/css-inline/#baseline-synthesis
             probably needs some review from competent people

  myles: It seems that none of the three proposals have anywhere near
         enough details to explain the difference between the grids.
  nmccully: Would greatly improve matters if line-heights and glyph
            placement were more controllable.
  nmccully: The existing baselines aren't sufficient, glyphs can shift
            today, being more explicit is important even if that
            requires adding more baselines.
  nmccully: Defining how layout engines should use these baselines to
            position glyphs needs better definition. Smaller group
            should discuss this.

Meta Bug for Line Height (CSS Inline & CSS2.1)
  github: https://github.com/w3c/csswg-drafts/issues/1796

  florian: This is a meta issues, many issues linked from it. Want to
           work on that css 2.1 doesn't define how line height is
           calculated. It tries to but contradicts with itself.
  florian: I've written a bunch of tests to see what browsers actually
           do. Much more interop between browsers than expected.
  florian: I'm not talking about which font metrics are used. Separate
  florian: I'm also not talking about when we have multiple inline
           elements within a line. Several fonts with different glyphs
           within a line, how are they aligned? That is what I'm
           talking about.

Position of the baseline inline-level boxes with non-normal line-height

  florian: There are two general cases where line height is normal or
           has a value, resolves to specific size. Then there is
  florian: In case where it is a size, you get exactly that size. Not
           clear from spec. Some spec text suggest it should be union
           of that per font, no browser does that.
  florian: The baselines from the first font is used and everything
           else is aligned from there. Not what the spec says but it
           is what all UAs do. That is good.
  astearns: Is it worth resolving to change spec to match that?
  florian: Yes.
  florian: Have proposed wording. If enough people have looked at my
           tests to verify them I'd be happy to resolve.
  florian: We have to be very specific when patching css 2.1
  florian: Happy to craft detailed diff if we agree on the high level
  eae: Matches our behavior.
  myles: We should just make the change and revisit if it causes
  florian: The specific proposal is listed in issue 1801 at the bottom.
      When the value of the line-height property is something other
      than normal, determine the leading L to add, where L =
      'line-height' - AD of the first available font. Half the leading
      is added above A of first available font and the other half
      below D of first available font, giving the glyph and its
      leading a total height above the baseline of A' = A + L/2 and a
      total depth of D' = D + L/2. Glyphs from fonts other that the
      first available font do not impact the height of the inline box.
  <florian> https://drafts.csswg.org/css2/visudet.html#leading

  dbaron: I was still looking at the previous issue.
  florian: One is about size, the other about alignment.
  dbaron: I think that seems reasonable. You might even want to say
          height or baseline of the inline box.
  dbaron: There might be some cases where that is not what we do but
          think that is for normal line height. Seems reasonable to me.
  astearns: Next step would be?
  florian: Resolve if we agree.
  astearns: And then we can review that pull request?

  RESOLVED: Take florian's proposed change to definitive line heights.

Height of an inline-level box with line-height:normal using primary
    and fallback fonts
  github issue: https://github.com/w3c/csswg-drafts/issues/1802

  florian: CSS 2.1, in some cases, claims that line height normal
           behaves the same way as defined with a specific value.
           Probably between 1 and 1.5. Not what browsers do. What UAs
           do is take all fonts that are used, plus the first font,
           even if not used. That is what everybody does. Not what CSS
           2.1 claims.
  dbaron: I have a vague memory of gecko doing something odd in some
          cases. If there is a simpler impl I'd be happy to change.
  florian: Only case I could find that skipped first font if unicode
           range is used for the first font. Chrome and Gecko have
           different behaviors. Other then that and the case where the
           first font' doesn't have the space glyph there is full
  astearns: Has anyone reviewed these tests?
  florian: fremy said he did.
  astearns: Is Edge fine with taking this change? And Chrome?
  eae: Yes.
  myles: Let's do it!
  dbaron: Go ahead, trying to figure it out will take awhile.

  astearns: Any objections?
  dbaron: I'm pretty sure the gecko behavior is too weird. Might be
          worth having test coverage.
  florian: There is 2.5 browsers doing one thing, 1.5 the other.

  RESOLVED: Take florians proposed change for line-height normal.

  dbaron: Want to go back to line height normal. In some cases we use
          different font metrics.
  dbaron: The text in the proposal was very specific about the metric.
  florian: Will update it to be more clear about the specifics and
           that the font metrics in question isn't defined.
  dbaron: What metrics are used should be looked at separately. Will
          add comment.

  <dbaron> FYI, I did figure out the crazy Gecko behavior I was trying
           to remember:

Behavior differences when the primary font does not contain U+0020
  github issue: https://github.com/w3c/csswg-drafts/issues/1798

  florian: We discussed whether the first font in the fallback list
           should count as the first available font even if it doesn't
           have a space glyph. We did not specify whether it should
           also apply to line height.
  florian: Safari, Edge, and FF half the time considers it even if it
           doesn't have a space glyph.
  florian: Safari and Chrome do not.
  fantasai: The “first available font” should have a strict consistent
            definition across specs.
  florian: Is not consistent across implementations.

  florian: Happy to change if implementations are willing to change.
  florian: I don't really care strongly, arguments on both sides.
  florian: Are edge and safari ok with that?
  fremy: I didn't run all of the tests but I think we do the same
  florian: So there are three compat implementations?
  florian: The first available font wording is used in 2.1 just not
  astearns: Might be acceptable to not test the presence of space in
  florian: Define it in fonts3 and then have that definition apply to
           all cases where we mention first available font
  Proposed Resolution: To define first available font more strictly in
           the fonts module and leave it undefined in 2.1

  RESOLVED: To define first available font more strictly in the fonts
            module and leave it undefined in 2.1

Height of the content area of inline level boxes
  github issue: https://github.com/w3c/csswg-drafts/issues/1804

  florian: All browsers agree that the size of the content area
           depends on the size of the primary font, even if no
           characters from the primary font are used.
  florian: The specification doesn't define the behavior, say "may do
           A or B".
  florian: Should remove "may do A" as no browser does that.
  florian: Suggest we remove suggestion saying that one may do
           something that nobody does.
  dbaron: Would argue it should be a SHOULD rather than MUST instead
          of a MAY.
  myles: Content area also depends on the line-gap property
  florian: Just depends on font metrics.
  florian: Spec says "do whatever you want, here are two suggestions".
           Doesn't mandate a specific metric.
  myles: Shouldn't say ascent or decent, have specific meaning.
  dbaron: I don't think this ones includes line gap, only asc+dsc.
  florian: There is a paragraph saying that if more fonts are used the
           height of the area isn't defined but we suggest... I
           propose we remove that.

  Rossen: What about overflow?
  florian: People don't do that for background I think.
  Rossen: I'll follow up with a test case.
  astearns: Let's continue making tests given the number of questions
  fantasai: This is about where the background is painted for inline
            elements, very specifically about backgrounds.
  Rossen: I might be miss-reading the issue.
  fantasai: The question is how tall is the background painted behind
            the text. Can't set overflow on inlines. Has to be set on
            containing block.

  florian: I'm not an editor for any of these specs, there will be
           pull requests not in spec.
  florian: Would like to move forward.
  Proposed resolution: Change the wording such that 2.1 is saying you
           should define the content area based on the first available
           font and only that font.

  RESOLVED: Change the wording such that 2.1 is saying you should
            define the content area based on the first available font
            and only that font.

  [end of day]
Received on Tuesday, 5 December 2017 00:30:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:09 UTC