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

[CSSWG] Minutes Tokyo F2F Thu 2017-04-20 Part I: Repeated Headers, Line Breaking, Line Height Calculations [css-text][css-inline][css-rhythm]

From: fantasai <fantasai.lists@inkedblade.net>
Date: Fri, 26 May 2017 20:46:52 -0400
To: "www-style@w3.org" <www-style@w3.org>
Message-ID: <069b4660-55e3-92ac-b23b-2fd17cc1c164@inkedblade.net>
   These are the official CSSWG minutes.
   Unless you're correcting the minutes,
  Please respond by starting a new thread
    with an appropriate subject line.

Text Track

Repeated Headers and Footers

   - Florian introduced an idea for generalizing the repeat-on-each-page
     behavior of table headers and footers to other elements.
     It seemed to need more work before being adopted as a WG work item.

CSS Text 3

   - The usage data is too high on word-break: break-word for Chrome
       to remove it, so group is waiting on Edge folks to reply about
       adding it for compat.
   - RESOLVED: Put an issue in the spec about whether overflow-wrap
               should apply regardless of whitespace.
   - Xidorn/i18n were actioned to see if breaking punctuation but English
       is a case used in Chinese, to see whether it is necessary to
       support that case as well. (Apparently line breaking tailorings
       are expensive to add to certain commonly-used libraries.)
   - RESOLVED: add line-break: break-all to the spec, definition depending
       on i18n report on required behavior(s)

CSS Rhythm

   - In trying to solve the issue to avoid double spacing, bugs were
       filed on other specs to fix inconsistent on confusing behavior
       that was making this problem harder to solve.
   - The group agreed that they should make step-sizing safer, but
       they did not reach an agreed approach to addressing the issue.


   - RESOLVED: Fix the erroneous conclusion in section 10.8 (in
               reference to https://github.com/w3c/csswg-drafts/issues/391)


Agenda: https://wiki.csswg.org/planning/tokyo-2017#topics
Note: The group split the morning of the 20 April on two
       tracks: FX and Text.

   Rachel Andrew, Invited Expert
   Rossen Atanassov, Microsoft
   Tab Atkins, Google
   L. David Baron, Mozilla
   Brian Birtles, Mozilla
   Bogdan Brinza, Microsoft
   Rick Byers, Google
   Tantek Çelik, Mozilla
   Emil A Eklund, Google
   Elika Etemad, Invited Expert
   Rob Flack, Google
   Simon Fraser, Apple
   David Grogan, Google
   Jihye Hong, LG Electronics
   Dean Jackson, Apple
   Toru Kawakubo, Vivliostyle
   Ian Kilpatrick, Google
   Vladimir Levantovsky, Monotype
   Chris Lilley, W3C
   Myles Maxfield, Apple
   Jack Moffitt, Mozilla
   Shinyu Murakami, Vivliostyle
   Xidorn Quan, Mozilla
   Florian Rivoal, Vivliostyle
   Hiroshi Sakakibara, BPS
   Simon Sapin, Mozilla
   Alan Stearns, Adobe
   Shane Stephens, Google
   Surma, Google
   Lea Verou, Invited Expert
   Jet Villegas, Mozilla
   Philip Walton, Apple
   Johannes Wilm, Vivliostyle

   Scribe: iank

Text Track

Repeated Headers and Footers

   <astearns> https://specs.rivoal.net/css-repeat/
   Florian: Tables are special, table headers and footers repeat
            across headers.
   Florian: Sometimes you want this on other things apart from tables.
   Florian: So based on a need in a vivliostyle project, we'd like to
            generalize this, and can be applied to things other than
   Florian: So the stand-in name is repeat-on-break.
   Florian: Only applies to one element, ignores other elements which
            have this property.
   Florian: First repeatable footer will move to the bottom, first
            repeatable header will move to the top.
   Florian: This follows tables, that the basic idea.
   Florian: So we've implemented this, its early, but its possible,
            we find this useful, I'd be interested in having an
            editors draft.
   Florian: Most useful if you do a lot of fragmentation.
   Florian: Parts of the tables spec could be offloaded to this.

   plinss: If we can explain the current magic of tables with a UA
           stylesheet instead of auto?
   Florian: I remember thinking about this, I can't remember why we
            went for auto.
   Florian: I'll need to think slowly through it, but if it can be
            done, why not?
   Florian: One advantage of the auto keyword it allows you do to a
            lvl 0 implementation.
   plinss: I don't know what your syntax looks like, but would be
   Florian: <explains syntax>
   <fremy> @plinss @Florian: The conversation diverged but I wanted
           to mention that I don't think you can get rid of auto and
           define this in a UA stylesheet. Because one can set
           display of table-header-row on any kind of element, and
           the author doesn't set the new property yet still get the
           repeated behavior right now. So there must be some magic
           to tie the two together somehow.
   <astearns> thanks, fremy
   <fremy> @astearns: No problem, I'll send feedback on github

   Tantek: Repeating headers and footers were dropped from HTML,
           nobody implemented this, and it got dropped....
   Florian: Prince, vivliostyle, and anntenahouse all implement the
            repeating headers and footers.
   tantek: Do any of those members participate in that WG?
   Florian: I'm confused as to why HTML WG talks about layout.
   fantasai: The HTML spec right now shouldn't be specifying that.
   fantasai: CSS spec should specify how that renders.

   Florian: I'll check that, it is implemented.
   tantek: But not in any browser.
   Florian: I disagree with interactive, vivliostyle is interactive.
   Florian: Either most/all don't have this.
   tantek: If I was looking at this from an outside perspective, this
           is incubation.
   fantasai: I don't think we generally do this.
   Florian: The incubation approach sounds reasonable, but don't want
            to do this in WICG.
   tantek: Not saying this should be in WICG, I think we should do
           this (incubation) in CSSWG.
   Florian: ED is relevant topic, globally sane approach, FPWD is
            without any time commitment this is something most folks
            would be able to implement.
   astearns: I suggest b/c of time constraints, we don't discuss

   Florian: Realizing that this isn't a group commitment to do this -
            would folks like an ED.
   <dauwhe> Prince will repeat thead/tfoot/caption on every page, but
            otherwise requires using page margin boxes for repeating
   <dauwhe> Lots of people ask Prince for such functionality, though
   astearns: I would like gregwhitworth & fremy to look at this, as
             they are revamping tables spec, would like to get their
             opinion if we'd have this as an ED.
   fantasai: I think we need the whole group's opinion.

   astearns: I'm very interested in how this works with grid layout.
   Florian: Yes, but with caveat we don't know how grid fragmentation
   fantasai: Would this apply to a grid-item?
   Florian: <discussing how this may work with grid>
   fantasai: We do placement before we do layout in grid, because you
             need to know how wide the columns are, i.e. know which
             column something is in.
   Florian: Will that work when pages have different sizes?
   fantasai: Gets trickier, but you still need to know content of
             whole grid.
   fantasai: Intrinsic constraints, carry through across all pages.
   Florian: It seems there are cases with grid where you would want
            this to work.
   Florian: I'm not entirely convinced we want to fragment the grid.
   fantasai: ok, thats a different thing (discussion).
   Florian: Not sure if we want to do this, may need to figure out
            grid fragmentation first.

   Florian: But we are time-boxed, doesn't sound like we can resolve
            on ED yet.

   ACTION: Florian to talk with gregwhitworth & fremy about how this
           interacts with table spec.
   <trackbot> Created ACTION-848

   <tantek> FYI: in general I'm in favor of a fairly low political
            bar for starting an ED, but we should consider, per
            incubation, if it is something that we wouldn't mind
            seeing it prototyped
   <tantek> i.e. ED = start incubating, and IMO FPWD should mean we
            have sufficient evidence of incubation (e.g. prototypes
            that seem to at least somewhat work as expected)
   Florian: For the record had a 10s conversation, TabAtkins said
            looks ok.
   iank: We'll look at this from a blink perspective at some stage.

CSS Text 3
   Scribe: rachelandrew

word-break: break-word
   <fantasai> https://drafts.csswg.org/css-text/issues-lc-2013#issue-94

   fantasai: The first issue we were waiting to hear back from
             Microsoft on word-break: break-word
   Florian: Google is finding it impossible to remove.

   fantasai: As an aside, no-one understands any of the white space
             properties, and I don't know how to make it better /
             easier to understand; I can't come up with anything.
   Florian: If we add it it would be for webcompat reasons which
            makes it doubtful we can rename it.

   iank: Our use counter for this property is that we are at 20% of
         every page load.
   fantasai: Seems we are over the threshold, so this feature needs
             to be added somehow so Firefox and Microsoft can have that
             ability, whether authors would be willing to switch over
             to a better name.
   Florian: We did a bit of whiteboarding on a better name yesterday.
   iank: I'm just looking to see if it is feasible to add a use

   tantek: We had an open bug on implementing at Mozilla, it has
           caused compat issues in the past but there are old
           complaints but no new ones.
   fantasai: If Mozilla isn't under pressure to add it, and Edge
             isn't then we can at least try to come up with something
             better and phase that in. All of the line breaking
             properties are very confusing.
   tantek: It needs to be a lot better or we may as well stick with
   <tantek> our bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1296042 to implement "word-break: break-word"

   fantasai: The usability problem is we have the same keyword on 2
             different properties meaning different things.
   astearns: I don't think we can resolve need to hear back from
   fantasai: Use data is high enough that it's scary.
   tantek: Is this something authors are actually using, or is Word
           just sticking it in or something?

terminal-style line breaking (break anywhere)
   github topic: https://github.com/w3c/csswg-drafts/issues/1171

   Florian: There are many variations on how to wrap text, one thing
            is wrap everywhere, get to the end of the line break and
            do a new one (terminal-style)
   Florian: The main difference between this and word-break:
            break-all is that the latter allows wrapping points
            between letters but not punctuation
   (Basically, 'word-break: break-word' treats all letters letters like CJK.)
   fantasai: This value was intended for Japanese.
   Florian: This doesn't do what you want if you want the terminal

   fantasai: Right now the word-wrap property acts on letters and
             symbols not punctuation.
   fantasai: The line-break property deals with punctuation rules
   fantasai: so we have logical separation of the two properties.
   fantasai: Adding a new value to word-break is weird as that isn't
             what it does.
   fantasai: So we might want to add a value somewhere else, maybe
             line-break: break-all.
   Florian: The alt way to approach that is the overflow-wrap
            property, if things do overflow and you do overflow-wrap:
            break-word it allows the overflow to be anywhere.
   fantasai: overflow-wrap says pick some arbitrary place near the
             end of the word to wrap.
   Florian: [writes on the whiteboard]

   fantasai: So make overflow-wrap work regardless of the white-space
   fantasai: It does make sense that overflow-wrap is allowed to
             apply as this is basically emergency breaking.

   fantasai: We might also want to add a break-all value.
   fantasai: We should add line-break: break-all and also make
             overflow wrap apply regardless of the white-space value.
   fantasai: I think that both behaviors are useful.
   koji: Why do we need two things to do the same thing?
   fantasai: Currently overflow-wrap can allow breaking or
             non-breaking of a word.
   fantasai: This doesn't change your intrinsic sizing.
   fantasai: The other properties actually change the line-breaking
   fantasai: I think the behavior you would get for adding line-break
             is different to the behavior you will get from
   fantasai: We need a value that says break all, everything. But we
             might also want to set the intrinsic size according to
             normal line breaking rules.
   koji: I think people want to change the intrinsic size, but not to
         change overflow behavior.

   iank What about properties that override intrinsic sizes.
   fantasai: This is about how we calculate the size of overflow text.
   Florian: We want at least one of the two.
   fantasai: We definitely need line-break: break-all.
   astearns: I have concerns about overflow.
   fantasai: I think we can resolve on the one, we should keep in
             mind the other question whether overflow should wrap
             regardless of white space.
   astearns: Resolve to put an issue in the spec for overflow: wrap
             to apply regardless of whitespace?

   RESOLVED: Put an issue in the spec for overflow: wrap to apply
             regardless of whitespace.

   astearns: To add a value to line-break that will say break
             anywhere with regards to punctuation.
   fantasai: Then maybe add a shorthand to make this all easier.
   fantasai: break-all is one possibility, anywhere is another
   koji: It's strange because line-break is a CJK property.
   fantasai: line-break is a property for different levels of
             punctuation strictness in different languages.
   Florian: They forbid line breaking in various places.
   fantasai: word-break does letters and symbols, line-break does
   astearns: So to get the terminal effect you would set line-break
             and word-break to break-all.
   koji: If we were to respond to original request it is easy, it is
         just to change one thing.
   koji: break-anywhere is easy, break-anywhere at punctuation is a
         new thing.
   myles: We would implement it at the system level.
   myles: webkit doesn't want to be in the business of understanding
          all this stuff.
   koji: In Android we define the priority of which to support and
         cut some of them.
   koji: this new mechanism is more complex.

   fantasai: I think it would be worth finding out if the combination
             is needed in Chinese (don't break a Latin word but break
             punctuation anywhere)
   Florian: I think the Japanese style of document, do English words
            get broken.
   koji: It does get broken.
   fantasai: If we find out if we need to add it then we just need to
             pick a syntax.

   ACTION xidorn to see if the case where you break at punctuation
          but not through English words is used in Chinese
   <astearns> based on that result, solve this issue with line-break:
              break-all (that allows that) or with a solution that
              breaks everywhere including punctuation

   fantasai: I'm leaning to the syntax being line-break: break-all
   fantasai: We have to pick a property, and line-break already
             affects some letters word-break whereas does not deal
             with punctuation.
   astearns: Can we resolve to put line-break: break-all in the spec
             for the purpose of the terminal use case, if it does
             that use case only or if it does it with the other
             property depends on investigation?

   RESOLVED: add line-break: break-all to the spec

CSS Rhythm

Avoiding accidental double spacing
   github issue: https://github.com/w3c/csswg-drafts/issues/938

   Florian: This is about avoiding accidental double spacing. This
            might happen if an author sets line height step to 1.3em
            and the default font using line-height: normal turns
            out bigger than 1.3 em.
   Florian: In another font the line-height might be calculated at
            double height.
   Florian: The previous proposal was to make the height deterministic
   Florian: but koji pointed out that line-height: normal is useful
            as it avoids overlap with long ascenders and descenders.

   Florian: I have a proposal for this:
   Florian: when you have something with a tall line-height you want
            it to be double, when it inherits this is a feature.
   Florian: When you set it, you never want to accidentally make the
            line-height step smaller than the natural line-height.
   Florian: Sometimes you want to do it on purpose.
   Florian: I'm proposing to add a safe /unsafe keyword pair
            defaulting to safe.
   Florian: Current behavior is the unsafe one.

   dbaron: I understand but think it is a problem.
   dbaron: The check is whether the line-height step is smaller than
           the line-height and if so make the step bigger.
   dbaron: The 2 pieces I am concerned about, 1 is that normal is a
           computed value of line-height
   dbaron: having that go back and influence line height step doesn't
           seem as if it will work.
   dbaron: We do sometimes have font metrics influence computed
   Florian: You need to take the line-height unit value as the lh
            unit depends on it.
   dbaron: So maybe that is ok, the other thing is that if you use
           text for more than one font we claim you end up creating a
           box of the size of the line-height around both sets.
   dbaron: Creating a height that is larger than the line-height.
   fantasai: That's a general problem.
   Florian: Does this change what line-height normal means?

   dbaron: [to the whiteboard]
   dbaron: [demonstrates lining up characters on the whiteboard]
   dbaron: [draws a Chinese character and a Latin letter]
   dbaron: suppose these come from different fonts
   dbaron: [draws the ascent and descent on the Chinese character]
   dbaron: [then draws the ascent and descent on the Latin letter,
           which is a little bit lower]
   Florian: Which is the primary font and which is the fallback?
   dbaron: It shouldn't matter as per the spec.
   fantasai: I think there is a conflict in the spec.
   dbaron: The number line-height is 1.26 font size 16px, so we want
           a 20 pixel box round each of these.
   dbaron: [demonstrates where the line-height boxes are around the
           two characters]
   <fantasai> (dbaron is using a numeric line height in place of
              normal, because normal could result in varying line
              heights; didn't want to deal with the complexity yet)
   dbaron: End up with a line box height bigger than the line-height
   [dbaron notes that because the ascent plus descent plus
           half-leading of each adds up to 20px, but they are offset
           by 1px, the total line height is 21px]
   [fantasai says the CSS2.1 spec says two contradictory things, one
             of which is what dbaron described]

   Florian: In this case if you started with a line-height step of 30
            pixels you wouldn't get double spacing
   dbaron: The designer might have fonts that have the same box and
           others have different boxes and get the double spacing.
   Florian: For it to fail that way you need multiple fonts falling
            back to each other.

   <fantasai> https://github.com/w3c/csswg-drafts/issues/391
   fantasai: I think this point is really important, it is a critical
             flaw in how it works.
   fantasai: When you have boxes of the same height, the CSS2.1 spec
             says 2 different things
   fantasai: you get that result (21px including the offset) and *also*
             get 20px, depending on which part of the spec you read.
   fantasai: So we need to fix that
   fantasai: in order for line-height-step to be at all robust and
             not flaky we need to fix it to yield 20px
   <fantasai> (The spec says two contradictory things, and supports
              both Gecko and WebKit's interpretations depending on
              which sentence you read in the paragraph describing

   myles: Gecko and spec agree with dbaron's example, WebKit would
          calculate the height and add spacing to either side to make
          it equal.
   <dbaron> I don't think that's actually what Gecko does
   dbaron: oh, yeah, that is what the spec says -- add the
           half-leading after unioning the character heights
   <dbaron> Here's the thing I drew on the whiteboard:
   <dbaron> (although as myles pointed out, I was wrong)

   astearns: This is one crucial instance, but initially you were
             talking about making step sizing in the safe mode that
             would increase itself if it encountered a large
   Florian: Where you have set your step size accidentally smaller
            than the computed value of line-height.

   fantasai: Can we resolve on fixing this 2.1 issue?
   <astearns> fantasai there's a bug for css2 on this?
   <fantasai> https://github.com/w3c/csswg-drafts/issues/391
   <astearns> then let's get that on the agenda and resolve this
              separately - I don't want to move off rhythm right now

   koji: How do you compute line-height normal to pixels?
   <general disagreement about the spec>
   dbaron: It's more like a number than any other kind of value but
           it does a thing based on the font.
   myles: It is based on the default font.
   <astearns> the point I wanted to make that you use step sizing to
              create vertical rhythm. Creating a 'safe' version that
              avoids double spacing and breaks the rhythm is

   Florian: Is there a definition for the used value of line-height,
            if you have normal and know the font?
   fantasai: At computed time the lh unit needs to map to an actual
   dbaron: I think you get it from the first available font.
   Florian: The value of the line-height property, does it change
            based on content on the line?
   Florian: Does that property vary per line?
   myles: No properties do not vary per line.
   Florian: You can't change the primary font per line.
   dbaron: I think Florian is talking about multiple lines splitting
           the same element.
   dbaron: The computed value of line-height normal is normal
   dbaron: so if you are asking what lh does, when you have
           line-height normal use the first available font in the
           font list.
   Florian: Not only is the value normal, but the value of
            line-height 1.2 is 1.2.
   dbaron: Let's file a spec issue.
   <dbaron> ok, filed https://github.com/w3c/csswg-drafts/issues/1253
            on css-values-4

   Florian: What makes this impossible?
   dbaron: Spec needs to say how to compute to an abs length,
           probably using the primary font.
   Florian: Do you need to do layout to figure out the pixel value of
   dbaron: For the lh unit or for layout?
   Florian: Not talking about the line box.
   Florian: what does the UA pick the number based on?
   fantasai: I think you assume this gets computed by a number and
             used as that number for layout calcs, used as a length
             to figure out the leading
   fantasai: That conversion happens per font in the text.
   myles: webkit does this.

   fantasai: If you don't have a value for the entire run, how can
             you work out the line-height for a single value?
   myles: (answering q) We do a bunch of stuff for the width then we
          calculate heights and place vertically.
   fantasai: For each char you find ascent and descent, get a value,
             if it is not the line-height increase or decrease on
             both sides to get the line-height.
   dbaron: Do you then use the normal?
   dbaron: Use line-height: normal, a single element on the line, font
           fallback is happening in the line, fonts have different
           metrics for line-height: normal and ascent and descent ...
           you take the ascent and descent, where do you get the
           number for normal
   myles: We don't; we take that value with no extra leading.
   dbaron: Gecko includes the external leading.
   Florian: How is this not a violation of 2.1?
   koji: This sentence contradicts other parts of the spec.
   dbaron: That sentence was written in the olden days.
   dbaron: It assumes defaulting to what the font says.
   <dbaron> https://drafts.csswg.org/css2/visudet.html#inline-non-replaced

   koji: Describes content box height.
   fantasai: The content box height has no effect on layout.
   dbaron: It matters re leading around it.
   fantasai: But this section is not related to line-height normal/
   dbaron: It can change the size of things, because the leading
           changes the content height, the middle of where the
           content height is does matter to layout.
   <dbaron> ok, filed https://github.com/w3c/csswg-drafts/issues/1254
            on line-height:normal definition in CSS 2.1

   astearn: We're not really addressing the rhythm issue here, though
            we found bugs in other specs.
   Florian: Do we have an issue to define the line-height unit based
            on primary font.
   dbaron: Pasted such an issue earlier.
   Florian: The issue I proposed is to define the same way.
   koji: This is based on font metrics of the primary font in safe
   Florian: When it inherits, is specified. It doesn't depend on the
   astearns: You set your vertical rhythm for body text but the
             heading is bigger what happens.
   Florian: The line step height will double to keep the rhythm
   Florian: gets the unsafe value from the pixel
   Florian: not magic, doing this based on a keyword, unsafe is
            current behavior. safe will cause the bigger line-height
   koji: Does this change based on inheriting?
   Florian: No magic with inheriting
   Florian: how well this works depends on how we fix 2.1, it doesn't
            make things worse.
   koji: I don't see it saves much, maybe some cases people think it
         is better.

   fantasai: Might want a keyword on line-height-step to use line-height.
   astearns: That would make double spacing more likely.
   Florian: You don't want to be exactly the line-height, needs to be
            just a bit more.
   astearns: Step sizing could be a percentage of line-height.
   Florian: Either line-height is a number and works, or it isn't.
   Florian: If you want to set your step smaller than the
            line-height, set it explicitly with unsafe then it will
            not get adjusted up.
   Koji: On web, due to small screen real estate, people set grid to
         fraction (half) of the desired line height.
   astearns: That happens in print as well.
   koji: I understand some cases it helps, given complexity vs

   Florian: It is very frustrating when people won't use a browser if
            it breaks, the outcome of not dealing with this could
            cause problems with different sized fonts, in one browser
            double heights might happen based on default sizing.
   fantasai: Having a layout system that breaks badly when fonts get
             substituted is bad.
   fantasai: Double spacing is bad.
   dbaron: Authors should not have to write a number in their CSS
           that has to be right based on the font the user has.
   Florian: The feature currently requires users pick a value.
   <dauwhe> I had an example where double spacing could be triggered
            purely by switching font family from serif to fantasy
   dbaron: The dev currently has to write line-height 3 or 20 pixels,
           Chrome might switch to double spacing based on one value,
           Firefox might pick another value, a subtle difference
           means you get double spacing in one browser and not
   dbaron: Gecko has had to reduce line-height they compute for
           webcompat issues.
   fantasai: We don't want more of these situations.
   astearns: Should we come up with a way of making step sizing
             safer, we haven't come up with a resolution on that.

css2 fixing
   github topic: https://github.com/w3c/csswg-drafts/issues/391

   fantasai: Suggested resolution is to fix the erroneous conclusion
             in section 10.8

   RESOLVED: Fix the erroneous conclusion in section 10.8
Received on Saturday, 27 May 2017 00:47:42 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:52:59 UTC