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

[CSSWG] Minutes Paris F2F 2017-08-04 Part II: CSS Text 3 [css-text]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 1 Sep 2017 08:50:01 -0400
Message-ID: <CADhPm3vFi4Hf2ORcT3bAEGknQCvJA3bX2RVD4bpuP1j9jNzNKQ@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.

CSS Text 3
  - The group agreed that what is in the spec for letter-spacing is
      right, but that there hasn't been any move to implement,
      partially based on a concern over breakage. There were three
      options to get over this barrier:
      1) Someone implements & ships
      2) Someone does a web crawl to get actual statistics of usage
      3) Everyone ships at once
      - Myles is going to investigate implementing this part of the
          spec to see if it works without breakage and fantasai will
          write test cases.
  - RESOLVED: No change (on applying line-spacing on a bidi-mixed
              string), Blink/Gecko require bugfixes.
  - RESOLVED: bidi reordering that would split an inline given
            infinite space will always create separate fragments
            even if the two fragments end up adjacent due to line
            Note: Behavior for letter-spacing (and other things
            affected, like box-decoration-break), falls out of this
            definition: in this case, if the two letters end up
            adjacent but are part of different fragments, the spacing
            between them will be given by the parent (according to
            the letter-spacing rules that control letter-spacing at
            element boundaries). This avoids the measuring problem.
  - RESOLVED: Rename line-break:break-all to line-break:anywhere.
  - RESOLVED: After edits from this meeting, publish new WD of
              Text 3.

text-spacing fullwidth punctuation collapsing

  - RESOLVED: Accept change matching JLReq's punctuation spacing,
              put a note into the spec about maybe needing more
              complex stuff, follow up with JLReq about the topic.
              (Issue #1668)

Orthogonal Flow Constraint: viewport vs scroller

  - RESOLVED: Add "size of nearest fixed scrollport" to the list of
              things you clamp orthogonal flow inline sizes to,
              editing the CR. (Issue #1391)


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

Scribe: TabAtkins

CSS Text

  github: https://github.com/w3c/csswg-drafts/issues/1518

  koji: Text 3 letter-spacing specifies that the letter-spacing
        after the last character of an element should be eliminated.
  koji: Concern that, while this is better, it may not be web
  koji: Our team prefers it be opt-in, so existing pages still work
        but authors can choose the better model.
  koji: It looks like Sebastian and Fran├žois agrees.

  fantasai: I know it's different, I wanna know if it actually
            causes a problem.
  fantasai: Adding extra switches is extra cognitive load on the
            author; it would be better to just do the right thing.
  koji: We have a bug requesting this feature for years.
  koji: He wants to stop using negative margin to cancel the space.
  koji: If we change things, his pages' compensation will instead
        ram the characters together.
  fantasai: Right, question is how many people will have that
            problem, vs how many will be *fixed* by the change.
  fantasai: If you have a large amount of letter-spacing to cancel,
            so large negative margin, and there's text after, that's
            a problem.
  fantasai: But if it's a small letter-spacing, it'll have less than
            ideal spacing but still *okay*--and lots of other pages
            will have improved letter spacing.
  koji: I think it's a little self-contradicting - people that want
        this feature care about it, and people who care can apply
        negative margin today.
  myles: I don't think that's necessarily true
  TabAtkins: I've never realized I needed to deal with this case
  myles: There's a difference between caring about letter-spacing,
         caring and noticing there's a problem, and caring,
         noticing, and trying to fix it with this hack.
  myles: What's stated in the spec is generally the correct result.
         I'd like to implement it, but I share fantasai's hesitation
         that we don't know how much will break.
  fantasai: I'm not hesitant, I think we should try it.

  fremy: letter-spacing is used everywhere on the web, so even if a
         tiny fraction care enough to use the hack, it'll still be a
         lot of web pages.
  fremy: And browsers are mostly interoperable today. I don't think
         it's a huge problem to keep current spec, add new
         glyph-spacing property that works properly, and tell
         authors to use latter.
  myles: glyph-spacing is bad name.
  fremy: Sure, anything works.
  myles: I think making two solutions, one broken and one working,
         isn't great. We should investigate fixing the one.
  fantasai: Someone has to ship it then.
  myles: Or crawl for it.
  myles: Look for letter-spacing and negative-margin on the same
  Florian: Hard to tell automatically if it's bad.
  fantasai: Have to investigate the *inherited* letter-spacing
            value, and if negative margin on the element.
  fantasai: That's the pages that are trying to work around it.
  fantasai: But there's also millions of pages that aren't trying to
            fix it, and will look better when we change it.
  fantasai: So it's a balance of how much bad it is.
  fantasai: Slightly worse appearance, or readability is affected.
  fantasai: So you have to actually look at the page.
  <fantasai> If it's mostly just slightly worse appearance, we're
             winning: there are many many more pages that aren't
             trying to compensate.
  bdc: Huge letterspacing is bad design by default, while negative
       letterspacing is often used for proper kerning.
  bdc: So there, we'd have the opposite issue - if we remove the
       space after last letter, we'd have bigger space between words
       than we currently have.
  fantasai: If you apply letter-spacing to whole paragraph, no
            impact, since you won't run into this edge case.

  dbaron: This isn't the first time it's brought up - maybe web
          compat, don't know, a little afraid of it.
  dbaron: If it is web-compatible we should stick to the current
  dbaron: If we wanna conclude it's not, we need more evidence than
          brought so far that it's not.
  dbaron: Until we have evidence that it's not, we should stop
          trying to discuss it every six months.
  <astearns> +1 to dbaron
  <myles> I think dbaron made the point I was trying to make, but
          much more elegantly than I did

  fremy: I've seen a lot of websites using letter-spacing for not
         letter-spacing itself; icon fonts and aligning,
         letter-spacing of 1px because "it looks better on my
         PC", ...
  fremy: I'm concerned it'll be a lot of webpages, but I'm not sure
         how to figure it out.
  TabAtkins: Do a good collection of affected pages via a crawl,
             then we can just sample them to whatever accuracy you
             want. Basic stats.
  <tantek> or at least provide URLs to illustrative examples (didn't
           see any in the issue)
  <tantek> (illustrative real world examples, not artificial data
           URls etc.)

  koji: I'm not clear on the next actions.
  koji: I think someone has to do a collection and figure out
        whether it's problematic or not?
  myles: Someone somewhere has to prove that an impl that follows
         the spec is not web-compatible.
  TabAtkins: WG likes the current spec, and puts burden of proof on
             implementations to prove that it's not Web-compatible
  TabAtkins: Need to evaluate pages where they have negative right
             margin that matches to the letter-spacing
  TabAtkins: And then see if they are actually broken.
  koji: So who will do this?
  myles: Whoever wants to change the spec.
  koji: Spec has been there for five years so far...
  fantasai: Yeah, nobody has stepped forward to implement this.
  fantasai: We want a spec and impls that match.
  fantasai: So first option is somebody impls and ships and sees
            what trouble they have.
  fantasai: Second is somebody does a crawl and checks the stats.
  fantasai: Broken vs slightly suboptimal; we don't care about
            latter, because we'll fix a bunch more pages.
  fantasai: Third is we do what we did with control characters,
            where we all ship at same time.
  Florian: Option 1 where things just ship, there are release
           channels for early info...
  bdc: I don't see how the crawl is possible really - the margin
       might be a little different than the spacing, they might have
       negative spacing and positive margin...
  fantasai: positive margin is fine; it doesn't cause overlapping
            that hurts readability, just puts in a larger gap.
  bdc: So I'm in favor of just keeping the spec as it is.
  fantasai: So in favor of moving forward, do impls have a pref on
            which strategy to use?

  koji: To me this is a nice feature, but not worth spending a week
        doing a crawl.
  koji: So I'd much rather have another property that does opt-in
        and see the usage.
  fantasai: That won't give us useful information.
  fantasai: Majority of people aren't paying attention to this, or
            aren't caring enough to do anything about it.
  myles: I think, going along with fantasai, you can track the # of
         times you encounter a website that uses it, but that's only
         useful as a fraction, and you don't know the denominator.
  myles: I can say 1k websites use the property, but we don't know
         how many sites considered it and didn't use it because it
         was bad for them.

  fantasai: [repeats three options]
  fantasai: And I think the WG is generally agreeing that changing
            the spec isn't a valid fourth option.
  Bert: Gradual change; reduce it by half this year, then quarter
        next year, eventually it's nothing. :)
  Rossen: So I don't think we did very good with the third option.
  Rossen: Anyone want to do option #1?
  Rossen: Anyone wants to crawl?
  Rossen: So we're at same position as before.

  fantasai: Question on #1 - we had zero interest in impl and
            shipping it.
  fantasai: But if someone was to give you a patch, you just had to
            ship it, then what?
  myles: I'm happy to investigate it, I want to make this work. I'll
         impl and see if it doesn't work.
  Rossen: Sounds good.
  <dbaron> I think Gecko would be happy to try taking a patch.
  <dbaron> Probably don't have the resources to do it in the near

  ACTION Myles to investigate changing letter-spacing impl to match
         spec regarding spacing at start/end of element.
  <trackbot> Created ACTION-857

  ACTION: fantasai to write test cases
  <trackbot> Created ACTION-858

  <br dur=15min>

letter-spacing and word-spacing applied to which side
  github topic: https://github.com/w3c/csswg-drafts/issues/1517

  koji: Problem from user perspective is that when letter-spacing is
        applied to a bidi-mixed string, Blink and Gecko has
        sometimes do l-s, sometimes double l-s, it's hard to predict.
  koji: WK and Edge add even letter-spacing.
  koji: It's not specced in CSS2, CSS3 defines quite different
        algorithm that solves this problem.
  koji: But it requires some complex impl.
  fantasai: CSS3 just says letter-spacing is applied after bidi
  myles: If we end up shipping what we resolved in the last topic, I
         think that'll mean that the Blink behavior of switching
         which direction you add l-s to, you won't need anymore
  myles: because then letter-spacing isn't on "left" or "right",
         it's on "inside".
  fantasai: 2.1 defines it as "between characters" - double or
            nothing is just wrong.
  <fantasai> https://www.w3.org/TR/CSS21/text.html#spacing-props
  <fantasai> CSS2.1 defines letter-spacing as "between" characters
  fantasai: CSS3 is more precise "between adjacent typographic
            characters, after bidi reordering". No ambiguity.
  <fantasai> https://drafts.csswg.org/css-text-3/#letter-spacing-property

  myles: So what's the proposal, making it legal to have double/
  koji: Proposal is to match WK/Edge.
  myles: Oh, okay, great.
  myles: So that's what the spec already says, right?
  koji: If spec says between chars, this might be an impl issue.
  koji: Most impls apply it to the left or right of characters.
  koji: Edge and WK apply it to the line-right direction, so always
        "to the right" regardless of direction.
  fantasai: And if we apply the previous topic's resolution, the
            user can't tell whether it's line-left/right.
  koji: Blink/Gecko apply it to end edge of resolved bidi direction.
  Florian: Can't you detect it with backgrounds?
  fantasai: No, l-s doesn't occur at a boundary; the l-s at a
            boundary is determined by the element containing both of
  dbaron: I think the current spec is solid, just a decent bit of
          work to implement.
  astearns: So reading of issue is just that Blink/Gecko need to
            change behavior to match spec?
  koji: Yes.

  RESOLVED: No change, Blink/Gecko require bugfixes.

Applying letter-spacing after line breaking
  github topic: https://github.com/w3c/csswg-drafts/issues/1509

  koji: As fantasai just mentioned, difference between CSS2 and CSS3
        is that 3 says apply l-s after bidi-reorder.
  <fantasai> CSS2.1 implied after bidi-reorder. L3 specifies
             explicitly to avoid confusion.
  koji: But bidi-reorder applies after line-breaking,
  koji: Which can change the number of "between" spaces there is to
        add letter-spacing.
  koji: So after we add letter-spacing, the line width can change,
        shorter or longer.
  koji: So I think this is a worse issue than what it's trying to
  fantasai: You have to include the letter-spacing when figuring out
            spacing and line-breaking.
  fantasai: This is same as kerning.
  koji: We don't redo kerning after bidi.
  koji: Because changing line widths after break is really bad.
  fantasai: Yeah, def don't want to change line-width afterwards,
            that's bad.
  fantasai: So that means you have to consider letter-spacing before
            breaking the line.
  fantasai: But since bidi-reordering happens after breaking the
            line, you won't know where the letter-spacing goes until
            after doing the reordering.

  myles: Do you have an example of this breaking?
  koji: [looks it up]
  koji: Last bit of example 16 in Text.
  koji: There's a 2em spacing between the characters in the span,
        but reordering separates the letters.
  myles: I understand now.
  fantasai: If you have that example, bidi-reordering puts two
            letters next to each other that weren't next to each
            other logically, do you perform shaping and kerning
            between them?
  myles: Ours won't cross bidi boundaries.
  koji: We're trying to do better at shaping across element
        boundaries, but only in logical sequences, before bidi
  koji: I believe we're trying to match Gecko's behavior.
  fantasai: Yeah, difficult; we're splitting up letters in an
            element, so where does the letter-spacing go?
  fantasai: Per spec, you don't put the letter spacing between
            letters of the element and letters outside the element.
  fantasai: So I see you point that it's hard to measure correctly.
  koji: If we follow Edge/WK impl and resolve the previous l-s
        topic, there should be 2em space on the right of C.
  TabAtkins: line-right edge - in logical order, it separates the
             letter from the next logical letter.
  fantasai: Example: you have a para with 1em letter spacing. Inside
            you have a span with 0 l-s. Between the last letter of
            the span and first letter outside the span, there's 1em
            letter spacing, where does that attach?
  Example: <p>f_o_o_<span>bar</span>_f_o_o</p>
  fantasai: Another span with borders and padding. You do
            linebreaking calcs.
  fantasai: Then you cut the line and do bidi reordering, but it has
            b-d-b: clone. Now you have two pieces with padding
            around them, where before you had only one. Now what?
  koji: I was reading b-d-b for the first time this morning, and
        thought of that exact problem.
  dbaron: Okay, at bidi *resolution* time, the element would split
          into two separate fragments, and thus both get borders.
  koji: But you don't know how linebreaking will happen yet.
  TabAtkins: If there's only enough room for 4 letters, so the "c"
             and the aleph are next to each other, is that still two
             independent spans?
  dbaron: We don't unclone them - they stay separate fragments.
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Aspan%20%7B%20border%3A%20medium%20solid%20blue%3B%20background%3A%20aqua%3B%20%7D%0A%3C%2Fstyle%3E%0A%3Cp%3Eab%3Cspan%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%D7%91%D7%92%3C%2Fp%3E%0A%3Cp%3Eab%3Cspan%20style%3D%22box-decoration-break%3Aclone%22%3Ec%D7%90%3C%2Fspan%3E%3Cbr%3E%D7%91%D7%92%3C%2Fp%3E
  <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5292
  dbaron: That might not be an intentional decision; they might have
          thought about it as normal linebreaking and this behavior
          just falls out.
  fantasai: I think it's okay to allow impls to do that.

  TabAtkins: So the c and aleph would still be considered separate
             fragments, even though they are adjacent
  TabAtkins: and the letter-spacing between them would be controlled
             by the parent.
  fantasai: I like this solution.
  TabAtkins: Wouldn't be too complicated, and would give sensible
             results in most cases and sensible-enough results in
             the rest.
  TabAtkins: During bidi resolution, you split them into separate
             fragments, and behavior falls out from that.
  koji: So we'll lose the letter spacing between bidi runs.
  TabAtkins: If the bidi runs are in the same element, yes - they'll
             use the parent's letter-spacing.
  <fantasai> Proposed that bidi resolution would result in splitting
             an inline in infinite space will always create two
             fragments, even if they end up adjacent due to line
  RESOLVED: bidi reordering that would split an inline given infinite
            space will always create separate fragments even if the
            two fragments end up adjacent due to line breaking

line-break: break-all
  github topic: https://github.com/w3c/csswg-drafts/issues/1561

  Florian: line-break:break-all isn't a great name. Should we find a
           better name?
  Florian: I think all names are bad, but I can't come up with a
           good one.
  Florian: This value allows line-breaks everywhere.
  Florian: word-break:break-all allows for breaks between letters,
           but not between punctuations, spaces, etc.
  Florian: line-break is terminal wrapping, word-break is just
  Florian: Trying to do better ignoring web constraints is hard,
           trying to do better *with* web compat is near impossible.
  Florian: line-break:break-all is the newest one, with best chance
           of renaming.
  Florian: Unfortunately it's got the best name, I think.
  koji: I don't mean it's badly named, just that same keyword on
        similar property doing differently is confusing.
  koji: Particularly if we have a shorthand for both of these.
  fantasai: shorthands can do custom syntax; we'll definitely
            redesign the whole thing if we do a shorthand
  fantasai: Shorthand would be *great*, we can make it all make sense

  koji: I understand it's possible, but if we're naming now, why
        choose "break-all"?
  fantasai: We didn't have a better one.
  koji: Line-break:terminal?
  Florian: how about line-break: anywhere?
  Rossen: anywhere?
  Rossen: any?
  Rossen: all?
  TabAtkins: That would force a break between every character
  [a few people like anywhere]
  Rossen: anyone care?
  [several other ppl care]
  TabAtkins: I think re-using the keyword is bad

  Rossen: So from the people paying attention, any objections to
          renaming break-all to anywhere?
  dbaron: How widely implemented?
  fantasai: Nowhere, it's new, we added it this year.

  RESOLVED: Rename line-break:break-all to line-break:anywhere.

  Florian: I have a PR for this change; other than me changing this
           keyword, can the editors approve it or tell me what's
  fantasai: Yeah, at lunch.

  RESOLVED: After edits from this meeting, publish new WD of Text 3.

text-spacing fullwidth punctuation collapsing
  github topic: https://github.com/w3c/csswg-drafts/issues/1668

  Florian: In CJK, full-width punctuation takes a full-width box,
           but they visually fill half to fit
  Florian: Japanese expects that when they're next to each other (
           like two close-parens), there will not be a big space,
           they'll be collapsed visually.
  Florian: The font contains space, but it needs to be canceled out
           in some cases.
  Florian: We have a rule in Text 4 that says when to do this.
  Florian: One rule is overcomplicated. We did it wrong because
           JLReq wasn't specific enough.
  Florian: Case is where you have a closing punct followed by an
           opening one: `)(`.
  Florian: If you did nothing it's 2em long, we want 1.5em long.
  Florian: Closing, half-space, opening.
  fantasai: Collapse away the adjacent half space.
  Florian: We specced that each is .75em long.
  Florian: Proper is to keep all space on closing one, remove all
           space from opening.
  Florian: Difference is barely observable, we should match.

  fantasai: Did the people working on those things consider the case
            of different-sized fonts?
  fantasai: Second paren is half the size of the first one, then
            what should happen?
  Florian: That's where it becomes observable.
  fantasai: I think probably 75% on each side isn't the right
            answer, so we should change it, but also not convinced
            we should always use the first.
  Florian: Unsure. Murakami says to do it the other way, and
           InDesign does it the other way, so we should match.
  fantasai: One thing we often do is look at print examples, and
            find where they're not handling cases.
  fantasai: I think we should choose one or the other; we could use
            innermost or outermost...
  Florian: They're same level.
  fantasai: Always use bigger one?
  myles: That'll cause space to change when font-size animates?
  TabAtkins: It'll do that no matter what.
  Florian: I think we should match publishers, with a note about if
           someone has cases not considered, let us know.
  fantasai: Korean mixes font sizes a lot; rather than ruby they
            just reduce font-size for such annotations
  Florian: But they use Latin punctuation, not full-width, so this
           doesn't apply.
  myles: I think it makes the most sense to do what everyone else
         does as a first pass.

  fantasai: Happy with that if we follow up with JLReq to make sure
            they think about this case.
  Rossen: Are you current JLReq liaison?
  Florian: Not yet, I have something later about that.
  koji: I think previous spec is ambiguous, just says "put a half
        space between them".
  Rossen: So can we resolve to accept change, put a note in, and
          follow up with JLReq?

  RESOLVED: Accept change matching JLReq's punctuation spacing, put
            a note into the spec about maybe needing more complex
            stuff, follow up with JLReq about the topic.

Renaming the dynamic and static profiles of selectors

  <Rossen> https://lists.w3.org/Archives/Public/www-style/2017Jul/0039.html
  <fantasai> https://www.w3.org/TR/selectors4/#profiles
  Rossen: Mail sent last Saturday.

  TabAtkins: So I've seen enough feedback by now that I agree that
             "static/dynamic" is confusing. Dynamic makes people
             think of JS. Let's talk about it over lunch and come

Orthogonal Flow Constraint: viewport vs scroller
  github topic: https://github.com/w3c/csswg-drafts/issues/1391

  fantasai: We resolved to use the nearest scrollport height for
            orthogonal flow fallback height.
  fantasai: But that can be auto. ICB is always fixed; we want this
            to be fixed as well.
  <dbaron> Should it be the nearest scrollport that's non-auto
  <astearns> nearest scrollable definite-height ancestor?
  <astearns> dang, dbaron beat me to it
  Rossen: When I was working on this, the logic I added was to keep
          looking for the nearest ancestor that imposes a fixed
          height or scroller, and if scroller is height:auto I think
          I keep going up.
  Rossen: You can go figure out the viewport size, but that doesn't
          buy you much.
  fantasai: I think you want it to be a size you can calc without
            doing layout.
  Rossen: Which is doable if you find a fixed ancestor.
  fantasai: If you look for fixed size and subtract intervening mbp,
            you run into problems we saw before with stretch, where
            you get so much accumulated mbp you're zero size.
  fantasai: Also, our goal if you're doing autosize is to not make
            it larger than what you can see in one screenful; goal
            is to fit a line of text they can comfortably read.
            Nearest fixed container might be larger than the
  Rossen: But then you'd have that problem with other things.
  TabAtkins: The other things are intended to scroll vertically.

  fantasai: It's very important that a line length is less than the
            size of the viewport, so you don't scroll back and forth.
  fantasai: So nearest fixed container might violate that.
  fantasai: This is why we used viewport instead of some random
  TabAtkins: If it's as big or smaller than the viewport, then even
             if it's not perfectly nice, the user can scroll it into
             place and be able to read comfortably
  fremy: You're preventing people from using transforms. They might
         want large initial size, then scale it down. You'd prevent
  TabAtkins: For transforms all bets are off.
  TabAtkins: We could clamp to smaller of the scrollport and the
  Rossen: Using smaller of fixed-height ancestor or viewport sounds
  fantasai: If your parent is fixed size, we already clamp by that.
  fantasai: But when we don't have a fixed size, we don't want to
            look up thru multiple layers of auto and find a size
            bigger than auto.

  Proposal: orthogonal flow fallback height is min(100vh, nearest
            fixed-size scrollport ancestor's height), no caring
            about mbp or anything.
  * dbaron notes that this proposed resolution needs to be
  + logical swap for other ordering.
  + available size of immediate container, which normally controls
  <fantasai> min(100vh, nearest fixed-size scrollport, available
  fantasai: Looking at spec, you choose smaller of "containing block
            size" and "ICB size", and the issue/discussion was about
            replacing ICB size.
  <fantasai> current CR is min(100vh, available size), previous
             resolution was min(available size, nearest scrollport)
  TabAtkins: So just adding one more bullet to that list, for
             nearest fixed scrollport.

  RESOLVED: Add "size of nearest fixed scrollport" to the list of
            things you clamp orthogonal flow inline sizes to,
            editing the CR.

  <br type=lunch dur=1hr>
Received on Friday, 1 September 2017 12:50:56 UTC

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