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

Minutes Berlin F2F 2018-04-11 Part III: CSS Scroll Snap, CSS Text 3 [css-scroll-snap] [css-text-3]

From: Dael Jackson <daelcss@gmail.com>
Date: Thu, 17 May 2018 03:32:22 -0400
Message-ID: <CADhPm3vNUmT99MLBYXxgn0s_8Qks6wxiwWsQ0Htmv=YQMesaiQ@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 Scroll-Snap

  - The group agreed that the focus should be encouraging users to
      reference the new version of Scroll Snap and that writing a
      guide to what can be done in both old and new would not move
      toward that goes (Issue #2523)

CSS Text 3

  - RESOLVED: Defer this (word-break:break-word) to next level. (Issue
  - RESOLVED: Normatively state that text-transform does not apply to
              plaintext paste. (Issue #627)
  - RESOLVED: Make text indent percentage relative to the content box
              of the element. (Issue #2394)
  - RESOLVED: Define hanging punctuation as scrollable overflow in all
              cases. (Issue #2398)
  - RESOLVED: Requiring language for hyphenation to take effect.
              (Issue #869)
  - RESOLVED: Treat lone CRs as 0 width spaces. (Issue #855)
  - The group needed more time to look at current behavior for Issue
      #1597 (intrinsically-sized box with text-indent) so it will be
      covered on a telecon.
  - RESOLVED: Clarify spec to say control characters should be always
              visible even if fonts don't provide a glyph. (Issue
  - RESOLVED: Defer this (font-relative letter-spacing) to text L4.
              (Issue #2165)
  - RESOLVED: Keep rule to collapse white spacethrough bidi formatting
              chars, don't mark at risk. (Issue #2233)
  - RESOLVED: Defer this (hanging-punctuation: last applying to colons
              and dashes) to L4. (Issue #2392)


Agenda: https://wiki.csswg.org/planning/berlin-2018#schedule

Scribe: dael

Schedule Note: During this time block the group split into two
    sessions, one for CSS Animations (see Part IV of minutes) and this
    session based on Text and Fonts

CSS Scroll-Snap

Path to interop among implementations
  github: https://github.com/w3c/csswg-drafts/issues/2523

  majidvp: Chrome we're impl scroll-snap. We're close to shipping. I
           tried to understand what other browsers impl. They're
           completely different.
  majidvp: In 2016 WG resolved to fundamentally change the spec. Older
           spec is mostly coordinate based and new is element based.
           New model I think is fundamentally better because it lets
           UA make a better decision.
  majidvp: At the time I think all impl agreed it's good and spec is
           in CR.
  majidvp: Only Safari implementation matches spec. Mozilla ships
           unprefixed old spec and I see a bug a few years ago for
           that. Same with Edge/IE they're an even older version of
           the spec.
  majidvp: 2 vendors impl old, Safari is close to new, Chrome will
           ship close to Safari but probably cover more of the spec.
  majidvp: Wanted to see if there's updates from other vendors.

  fantasai: I'd like to mention it's important that whoever impl
            scroll-padding and ships impl the behavior spec to apply
            to containers without snapping turned on. If we want that
            to ever work it needs to work when you turn on
            scroll-padding so people can detect it exists via

  astearns: Comment from Edge folks?
  Rossen: Looking for current status.
  florian: I think it says you plan to do it.
  Rossen: We haven't started work. Under considerations.
  dbaron: I think updating we looked at doing in the medium term.
          Possibly in next year, not next few months.
  <tantek> For reference: our (Mozilla) bug to update to the
           scroll-snap CR: https://bugzilla.mozilla.org/show_bug.cgi?id=1231777
  <tantek> It's also in our 2018 priorities though we're not sure
           we'll get to it in 2018: https://wiki.mozilla.org/CSS#2018_Priorities
  majidvp: I wouldn't be surprised that since there's an implementor
           saying that switching to element based won't be hard to do.
           Safari I think managed to switch the model. Seems
           reasonably straightforward.
  smfr: Impl wasn't too bad. Some compat problems.

  majidvp: Seems that for next year the old impl will exist. Next
           topic is if we should have explicit comments on how to
           migrate from the old snap points syntax to migrate to the
           new and if there's a subset of old that can be used.
  majidvp: For example, old had scroll-snap-destination and
           scroll-snap-coordinates and they would align the two points.
           Similar enough to the new spec that if you impl you can use
           the old and new models at the same time.
           We should have comments that this is safe to do, but don't
           use old.
  tantek: I'd rather not encourage authors to use any old syntaxes to
          reduce compat shadow we create as a whole. I don't think we
          should recommend older syntaxes.
  florian: I've made demos that work in both old and new and you have
           to use both syntaxes but that's all you can do.
  tantek: We don't want to support old going forward and if someone
          uses it because there's documentation on how to do it, it
          increases the risk.
  tantek: You increase the risk people create more stuff on the web
          with the old stuff .
  astearns: That they'll create stuff with old and new so it doesn't
            break when you move.
  majidvp: But it would be hard to measure they used both. I think I
           agree encouraging using both may not be right.

  astearns: Anything more?
  majidvp: One last thing, spec didn't have tests. As we impl we added
           tests, but I wanted to make a suggestion to other impl that
           as they impl it would be nice to have more tests.
  florian: I'm not impl but considering writing some tests. It's nice
           you've got basic and I'll ping you to get a review when I
           write for edge cases.

CSS3 Text - All Open Issues

  astearns: I want to timebox this a bit. Let's go to 3:15 and have a
            break and we'll switch to fonts. We'll leave the rest for
            the afternoon.
  <fantasai> https://drafts.csswg.org/css-text-3/issues-lc-2013

word-break: break-word
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-94
  github: https://github.com/w3c/csswg-drafts/issues/2390

  fantasai: Last time we talked we'd say add only if necessary for
            compat reasons. Do we have enough information? Or are we
  florian: I talked about this with Rossen and they felt comfortable
           postponing for now. They're not sure they're doing it yet.
  fantasai: So continue to defer. Useful to know.
  florian: There is a FF bug about impl because it was in the spec at
           some point. We were clear that seeing it in a spec is not
           enough justification for impl.
  fantasai: And we removed it from the spec.
  fantasai: So closed as deferred?
  astearns: Objections?

  myles: In L4 isn't there another property that does same thing?
  fantasai: There's an existing property that's word-wrap: break-word
            and that's different behavior.
  astearns: And even with identical behavior there may be a web compat
            reason to put it in L4.
  astearns: Objections?

  RESOLVED: Defer this to next level

  florian: Follow up question to Blink. Usage is quite high so your
           default answer is no.
  koji: We contacted some site owners and they said the think the
        different behavior is important so they won't change.
  koji: About computing [missed] widths. It breaks line only if it
        overflows so if an author sets it in the table cell it
        expands. The scenario to not extends makes it more difficult
        to us.
  myles: min-width is different.
  florian: But if we implement line-break:anywhere would that work?
  fantasai: No because word breaking is normal unless there's overflow;
            with line-break:anywhere breaking is anywhere regardless.
  astearns: This is now a text L4 issue.

text-transform on copy/paste
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-108
  github: https://github.com/w3c/csswg-drafts/issues/627

  myles: I've since flip-flopped. Last time I said text-transform
         should apply to copy/paste, but I've changed.

  fantasai: Prop: text-transform doesn't apply to plain text copy paste
  fremy: There could only be manual tests.

  RESOLVED: text-transform doesn't apply to plain text copy/paste.

  koji: ...
  fantasai: If I say ::first-line text-transform:uppercase if I copy
            paste that to a text document, it doesn't make any sense.
  koji: I have internal feedback that we have different behavior then
  fantasai: innerText or innerHtml?
  koji: Don't remember.
  fantasai: I think applying text-transform is seriously problematic.
            Because you lose information when you copy out that text.
  koji: It's not my opinion. I'm trying to find what they define.
  plinss: If they're defining how text-transform works they shouldn't
          do that.
  florian: They apply to innerText.
  koji: It says [reads]
  <koji> From the HTML spec: If node is a Text node, then for each CSS
         text box produced by node, in content order, compute the text
         of the box after application of the CSS 'white-space'
         processing rules and 'text-transform' rules
  TabAtkins: InnerText is not the same as innerHtml. InnerText
             takes weird css already.
  tantek: So it's weird legacy and don't build on it.
  fantasai: There's many things wrong with that spec text. We
            shouldn't build on that.

  astearns: Given that innerText isn't a precedent should we resolve?
  koji: He wanted to object, JS editors use innerText and want to be
        same as copy behavior.
  florian: plain text copy?
  koji: They're using plain text.
  astearns: I am inclined to unless you object have us resolve in this
            way and let editors come back with spec bug or objection
            in the issue.
  astearns: Is that okay?
  koji: [nods]

  fremy: I don't know what Edge is doing but we won't change for what
         the spec says. I think the spec says what Edge is doing. We
         try very hard to work. I'm fine resolving because I'm pretty
         sure we match.
  <rego> it seems Edge is doing what's resolved (not applying
         text-transform on copy&paste) :)

  fantasai: So, am I putting this in the spec?
  astearns: I'm hearing no objections. fremy says he may keep a bug
            against the text.
  fremy: I don't think copy/paste should be in scope of CSS. If you
         want it in CSS that's fine.
  astearns: We have 2 options. 1 is state that text-transform doesn't
            affect plain copy/paste and other is be silent in spec.
  koji: Their opinion is not to define.
  astearns: How about a non-normative note that we believe it should
            not apply to plain text paste but we're not sure it's web
  fremy: We don't apply.
  fantasai: This isn't an issue raised from outside WG and people
            posted to www-style unhappy that some browsers have this
            behavior, asking us to define it.
  koji: For Chrome we have a bug saying don't apply. I believe FF has
        bugs saying apply.

  myles: Hearing 2 things. Everyone with opinions believe same on
         issue. I'm also hearing we don't have jurisdiction to say it.
         So we should just say it.
  astearns: That's my non-normative note.
  florian: Let's say it.
  astearns: So we should say it.
  tantek: We have interop.
  astearns: Objections to normative stating that text-transform does
            not apply to plain text paste.

  RESOLVED: Normatively state that text-transform does not apply to
            plain text paste.

Percentage on text-indent
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-113
  github: https://github.com/w3c/csswg-drafts/issues/2394

  fantasai: Issue is percent on text-indent. In CSS 2 it was defined
            as relative to containing block and FF interpreted as the
            containing block of element it's set. Chrome it's the
            containing block of the text being indented. If you
            interpret as on the parent the behavior differs on if you
            generate anon blocks or not, which is problematic.
  fantasai: Proposal is to make the text-indent relative to the
            context box width of the element itself.
  fantasai: Means you don't expose anon block structure.
  florian: I think percent text-indents are relatively rare.
  fremy: People use -100% to hide text. Only case I've seen.
  astearns: Edge would have to fix?
  fantasai: FF
  <fantasai> original post from dbaron at
  <fantasai> Jonathan Kew requesting the spec (and Gecko) to change in
  <rego> http://jsbin.com/yodarulizi/1/edit?html,css,output
  <rego> edge and firefox have the same behavior, which differs from
         chromium and webkit

  koji: Do we know how often this is used?
  florian: I don't have data. We know it exists and it's different in
           different browsers. Probably not too much compat constraint.
           We're suggesting FF aligns with Chrome which typically
           doesn't break web.
  koji: Only not compat when anonymous block exists?
  koji: I implemented and there was a test case with repeat that all
        browsers pass.
  florian: If you're not careful in a test case and all boxes are same
           size it's all the same.
  fantasai: If test case was from hixie it was probably evil.
  <fantasai> (as in, doing a very good job of triggering tricky cases)
  koji: It has differences.
  koji: I'm willing to simplify just wondering how much data we can
  astearns: Any more to discuss?
  fantasai: Jonathan Kew (Mozilla) was asking for spec to change.

  fantasai: Prop: make it relative to content box of the element.
  fantasai: Simple behavior, no weird edge cases.
  astearns: Objections to make percentage relative to content box of
            element for text indent?
  dbaron: Both Edge & Chrome do that?
  fantasai: Don't remember.
  florian: I believe Edge does.
  fremy: Test case?
  dbaron: I found a web compat bug on percentage text compat on
          overflow:hidden because when there's 2 boxes we do the same
          thing as edge and we got a web compat bug. Or had. Probably
  <dbaron> https://bugzilla.mozilla.org/show_bug.cgi?id=1306590
  <dbaron> and also https://bugzilla.mozilla.org/show_bug.cgi?id=908706
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5888
  fantasai: Test case ^

  astearns: rego posted a jsbin that for me shows difference from FF
            and Chrome.
  rego: My example was from the issue.
  fremy: On the fiddle we have same as FF
  rego: It's Chrome and Webkit for the other behavior.
  fremy: Should the two lines be the same per the spec?
  <koji> https://github.com/w3c/web-platform-tests/blob/master/css/css-text/text-indent/text-indent-percentage-001.xht
  koji: This is in web platform tests ^ and passes in all browsers.
  fantasai: So we want it the be the same for both lines. That makes
            more sense.
  fantasai: Having text indent reference width of parent doesn't make
  koji: [missed]
  fantasai: Depends on what percentage is about. It's specified
            against containing block and it's not clear if it's the CB
            of element itself or the text inside it.

  dbaron: I'm fine changing. I don't understand the deal with the
          compat bugs.
  <fantasai> http://jsbin.com/yodarulizi/1/edit?html,css,output
  rego: This has a paragraph, the other one doesn't.
  fremy: Why should the text indent be same if the width inside the
         box is smaller?
  dbaron: There's a p inside so both the lines are in the inner box.
  dbaron: I'm fine changing. If that's what Chrome does it'll be fewer
          total compat issues.
  <rego> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5888
is interoperable
  <rego> but http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5889
is not
  astearns: Chrome behavior makes more sense to me.
  fantasai: Yes.

  astearns: Proposal: Make text-indent percentage relative to the
            content box of the element
  fantasai: It's possible what was trying to be clarified by css2 is
            that if it's a float it's still the same amount.
  koji: Are you proposing...?
  fantasai: Make everyone match Chrome.
  koji: What we do is different...I believe we have code with
        containing block and there might be difference in details.
        This is probably different then what we do.
  fantasai: We're proposing to say FF is wrong. When there's no floats
            we should do what Chrome does.
  florian: If you can find what's different between what we spec and
           what you do let us know.
  dbaron: Part of the old problem is people looked at different spec
          text and thought different things.

  RESOLVED: Make text-indent percentage relative to the content box of
            the element.

hanging-punctuation and overflow
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-123
  github: https://github.com/w3c/csswg-drafts/issues/2398

  fantasai: This is about if hanging punctuation is ink or scroll
            overflow. Current proposal is that it must be treated as
            ink in the general case and scrollable when editable.
  astearns: Threading the needle.
  fremy: Test case?
  fantasai: I'll try to make one.

  florian: Overall ink is preferable, especially Japanese punctuation
           marks. If you make them scrollable authors are in trouble
           because if they have 1/2em overflow you have invisible
           text. However when you're editing you want to get to
  myles: Would there be a case for less them 1em?
  florian: Yes because it doesn't look 1em. The glyph is 1em and the
           ink is not.
  myles: If hanging punctuation is 1 character.
  florian: Characters that hang don't fill box.
  myles: Ink doesn't. I want to look at actual examples because my
         intuition is that because a character hangs there would be 1
         em of actual space.
  florian: The intuition of kobayashi-san is that it would be less. It
           is not a full width character and should have the size ink
           indicates and the rest is a historical accident back to
           typing with blocks. People thinking of it as the space it
           consumes. But I don't have data.
  florian: Expert opinion. Not data.
  koji: Hanging punctuation in CJK looks more natural in ink but David
        Hyatt did the scrollable overflow.

  florian: I think scrollable will trigger a bunch of scrollbars.
  fantasai: When you have a scrollbar you don't want text to run
            against the edge of the scrollbar. You want breathing room
            which is typically >1/2em. A bunch of text in a scrollable
            container would likely have at least an em of padding
  florian: A container that's overflow:auto with intent that the
           scrollbars will never appear.
  myles: If fear is we'll create a bunch of scrollbars let's try and

  florian: Another piece of issue is that we're also saying preserved
           white space when there's too much it's treated as hanging
           and you would also cause scrollbars.
  fantasai: Advantage of scrollable overflow is when you're trying to
            select them you can see them.
  myles: If there's not collapsible spaces you should be able to get
         to the spaces.
  myles: Having non-collapsed spaces and being editable are separate.
  florian: For editing they must be scrollable. If that's true in the
           general case I worry about scrollbars allover.
  koji: Only webkit impl. If webkit can try it out.
  fantasai: You treat it as ink overflow?
  myles: I believe so.

  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0A%40supports%20(hanging-punctuation%3A%20last)%20%7B%20html%20%7B%20background%3A%20green%3B%20%7D%20%7D%0A%3C%2Fstyle%3E%0A%3Cdiv%20style%3D%22width%3A%204em%3B%20border%3A%20solid%20silver%3B%20hanging-punctuation%3A%20force-end%22%3E%0A%E4%B8%80%E4%BA%9B%E6%B1%89%E5%AD%97%E3%80%82%20
  fantasai: Test case^
  fantasai: Add overflow scroll to it.
  myles: Not scrollable.
  [fiddling with test case]
  myles: Inconclusive. I can't get anything to hang over.

  florian: From PoV of editing with a single punctuation overflowing
           it won't be a big different. It's preferable scrollable.
  myles: So it should be scrollable overflow and if it's a problem we
         can come back.
  astearns: Sounds like we have consensus to define hanging
            punctuation as scrollable overflow.
  astearns: Do we want a note about concerns?
  fantasai: I think people can complain about it.
  astearns: Objections to define hanging punctuation as scrollable
            overflow in all cases?

  RESOLVED: Define hanging punctuation as scrollable overflow in all

Should 'hyphens: auto' work if lang is not declared?
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-133
  github: https://github.com/w3c/csswg-drafts/issues/869

  myles: Hyphenation requires a dictionary. The dictionary selected
         should be informed by lang. Without lang hard to pick
         dictionary. In webkit we pick the OS dictionary.
  myles: I believe that's right.
  myles: We have seen a lot of untagged content.
  dbaron: I think this was intentional decision by WG to encourage
          content to be written in a way that works worldwide.
  dbaron: Gecko impl what the spec says, where we only auto-hyphenate
          with a declared language.
  astearns: Seemed like terrible things could happen if you use a
            dictionary without a lang.
  fantasai: Also, if they think their page works, but only on their
            computer that's bad.

  florian: If hyphens was meant to be applied but doesn't that's not
           good but it's readable. Auto hyphens would make text
           confusing. It's encouraging authors to not lang tag and you
           might hyphen wrong which is worse then no hyphens.
  myles: For the first part our thought is about existing content. For
         new content we should encourage correct tags. We're worried
         about breaking large websites.
  florian: You'd have graceful degradation.
  fantasai: The pages are broken in browsers that don't have the
            behavior you have, so it's already broken. This just makes
            it more obvious by being broken in the author's browser
  astearns: Aren't you concerned you get German hyphens on English
            text? Seems like a reason to change this preference.

  richr: If you have a http header with a language?
  fantasai: That counts as a language.
  myles: I won't object.

  <dbaron> https://html.spec.whatwg.org/multipage/dom.html#attr-lang
  astearns: Anyone else?
  astearns: Objections for requiring language for hyphenation to take

  RESOLVED: Requiring language for hyphenation to take effect.

Lone CRs
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-138
  github: https://github.com/w3c/csswg-drafts/issues/855

  fantasai: Jonathan Kew reports, per spec a lone CR is just like a
            lone line feed and it's a segment break. But browsers
            discard the carriage returns. If you put them in your
            source they're  transformed. However if you inject it via
            JS into the dom text content then it disappears.
  fantasai: If they used dhtml and not escape it would happen. We
            accepted the change to make them invisible
  fantasai: And then when I tried to edit in, I realized that making a
            character invisible is under defined.
  fantasai: Does it break shaping?
  <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%D8%B4%D8%AA%0AVA%3Cbr%3E%0A%D8%B4%26%23x000c%3B%D8%AA%0AV%26%23x000c%3BA%3Cbr%3E%0A%D8%B4%26%23x000d%3B%D8%AA%0AV%26%23x000d%3BA%3Cbr%3E%0A%D8%B4%26%23x200b%3B%D8%AA%0AV%26%23x200b%3BA%0A%0A

  myles: Can we pretend it never existed?
  fantasai: Or treat similar to zwsp.
  myles: For kerning you want it not to be similar to zwsp
  fantasai: I think this is a weird edge case.
  myles: You're saying because it's an edge case we should do the
         simple thing.
  fantasai: For pages authored with CRs they're taken care of by html
            parsing algorithm. This is just people who stick a
            CR in the text content via JS.

  fantasai: Gecko treats like zwsp and chrome drops. Someone help
            me decide between the 2 behaviors.
  florian: Dropping seems simpler.
  myles: Harder to implement because changes size of data structure.
  koji: Difference between drop and zwsp?
  fantasai: Shaping between adjacent chars. There's a test case.
  myles: In an impl where strings are never copied you'd have to
         remove the character and shift the future to pretend it
         doesn't happen.
  astearns: We have 1 browser with zwsp and another inclined.

  fantasai: fremy what does edge do?
  fremy: I can't load page.
  eae: We wouldn't object.

  myles: There are other characters treated as zwsp.
  astearns: fremy do you care?
  fremy: I don't know what Edge does.
  fantasai: There's an IRC test case.
  fremy: It's so broken we need to fix it.
  astearns: Prop: Treat lone CRs as zero-width spaces.

  RESOLVED: Treat lone CRs as zero-width spaces.

intrinsically-sized box with text-indent
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-156
  github: https://github.com/w3c/csswg-drafts/issues/1597

  fantasai: What impact does percentage text-ident have on intrinsic
  myles: If there's no web compat risk can we use a model for what
         happens in other situations?
  fantasai: Treat as 0.
  florian: Risk is if you want to treat it as -999% to get it out.
  fantasai: You resolve, but for computed size calculation we treat as

  [everyone looks at test case: https://wptest.center/#/0jcvq1 ]
  fantasai: It treats it as 0.
  myles: Everyone does 0?
  astearns: No, Chrome and Edge are using parent size according to
            fremy comment.
  florian: Going to the parent?
  myles: Parent can also be shrink wrapped.
  fremy: If available is if you're not sizing the parent as
  myles: Else it's 0?
  fremy: Yes.
  myles: We should just always 0. This is just a corner case.

  fantasai: If we have 2 impl we might as well align. I'm not sure
            what this comment means.
  fantasai: Chrome and Edge use parent size in min-content if
  florian: If parent has definite size work from that if not 0?
  fantasai: We're resolving against element itself.
  fremy: New version of Edge is completely different. We use 0 all the
  fantasai: We'll cover this one on a telecon.

Shipping visible Cc
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-161
  github: https://github.com/w3c/csswg-drafts/issues/1990

  astearns: This time we'll synchronize.
  myles: Didn't have a date and it failed. We shouldn't show them
  fantasai: We need it all implemented behind a flag first and
            *then* all flip on.
  myles: That's fair, but has always been true.
  fantasai: Didn't some people just release?
  florian: They impl something... not what we speced?
  fantasai: Comment from xidorn was we wanted to coordinate shipping
            this together so that authors know it's an intentional
            thing for the platform.
  eae: For us it's font dependent. If the font has a glyph it shows.
  myles: I think that's what we do too.
  astearns: So people sync shipping thiiinnngs...

  fantasai: Previous spec said control characters are invisible.
            People wanted it visible, I changed the spec, we were
            going to coordinate and it shipped.
  eae: We had a flag and there was a rough time period.
  fremy: We were supposed to do it and we did not.
  fantasai: I think goal was ship on a particular day. Anyone who
            shipped on proposed schedule had no one with them.

  astearns: However this happened. What's before us right now is how
            to deal with spec. Do we leave it in that we want control
            characters visible? Change spec to match what's interop?
  florian: We no longer have full interop. Some browsers are visible
           or not depending on font.
  astearns: Any browsers always visible?
  florian: I think that's behind FF flag.
  astearns: Edge has not shipped it. Safari?
  myles: [missed]
  florian: Blink basic font for windows has control characters so it's
           there but on iOS it doesn't so they're not.
  Rossen: We shipped when we said it would.
  fremy: Did we?
  ??: We have 2 interop impl on windows.
  dbaron: Based on what I'm reading FF nightly has had it on for a
  <dbaron> (though I'm less sure than usual that I'm reading correctly
           since somebody just rewrote a bunch of pref stuff...)
  <xidorn> (dbaron: I just had a look at the code and I don't think we
           enable it right now on nightly)
  <dbaron> xidorn, layout.css.control-characters.visible seems to be
  <xidorn> (dbaron: on, I see, yes, we enabled that in nightly)

  astearns: This being in the spec is not gated on the simultaneous
  florian: Clarify spec that we mean visible visible.
  ??: What character do you use
  fantasai: Missing glyph replacement.
  florian: You put a visible thing so people fix it.
  astearns: So this issue is basically close and clarify that it
            should be visible. But the coordination conversation is
            not relevant

  astearns: Objections to clarify spec to say these characters should
            be always visible ?
  eae: First browser will look broken. It'll be worse if we force to
       always. I'm not opposed but a little unpleasant.
  astearns: Still better if coordinate.

  RESOLVED: Clarify spec to say these characters should be always
            visible (regardless of whether any font has assigned a

font-relative letter-spacing
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-167
  github: https://github.com/w3c/csswg-drafts/issues/2165

  fantasai: This was a feature request. Worth a quick look. Might have
            to go in L4 unless someone has a quick solution.
  fantasai: We can add unitless values or add percentage or add a
            unit'ed value.
  florian: TabAtkins doesn't like unitless values
  fantasai: Word spacing the percent means that character's own width.
  fremy: I understand what we're doing. In previous issue with CR we
         render because it's a control character. We render the black
  florian: For letter spacing I feel comfortable defer.
  astearns: Obj to defer this to text L4?

  RESOLVED: Defer this to text L4.

white space collapsing through bidi formatting chars
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-172
  github: https://github.com/w3c/csswg-drafts/issues/2233

  fantasai: We asked for i18n feedback. Wanted to check with WG as
            well. You have some text and at the end of the line you
            have whitepsace and mixed in there are bidi control
            characters. Does the whitespace collapse?
  florian: If instead of bidi control characters you have markup with
           the equivalent bidi commands we collapse through.
  myles: Reason to not collapse is if there's a character user can
         see. This is not that. It should collapse.
  florian: Spec says that but I don't believe anyone does that.
  florian: CSS2 and CSS Text 3 says it must collapse.

  fantasai: Keep spec as is and file bugs?
  myles: This is a thing we should do.
  koji: We make bidi controls follow collapsing.
  <eae> (to clarify, in our new layout engine we do collapse through
        bidi control characters. the current layout engine does not)

  astearns: Text 3 is where in process?
  fantasai: LC
  astearns: It'll have to be at risk if we still don't have impl.
  fantasai: I'm happy for at risk.
  fantasai: Mark it as at risk and if no one impl we say we want to do
            it this way.
  astearns: Close no change?
  florian: Mark at risk?

  RESOLVED: Keep but mark at risk

  fremy: Edge does this
  fantasai: koji says Chrome will.

  RESOLVED: Just keep, don't mark at risk.

hanging-punctuation: last and colons and dashes
  issue: https://drafts.csswg.org/css-text-3/issues-lc-2013#issue-170
  github: https://github.com/w3c/csswg-drafts/issues/2392

  fantasai: Brad Kemper asked if we can hang the colon. I thought and
            if we wanted to hang colons with the 'end' values that's a
            problem but we can do it for the 'last' value and probably
            would work. Do we want colons and maybe dashes to be
  myles: We had a long discussion on this.
  fantasai: This is the 'last' line, that was 'end' value. Last line
            has different behavior and so we want them to be hangable
  myles: Don't want new issues for every new character, there should
         be named sets.
  fantasai: Dashes are easy as a set in unicode.
  myles: I mean, I'm writing an English novel and I want the things in
         English novels to hang.
  astearns: You would have missed Brad's use case.
  fantasai: I think we could do customizable sets some day, not now.
  myles: I don't think these sets should be described in CSS
         properties. The spec should have a handful of common sets.

  fantasai: The default set. Does it include colon? We have a reason
            to include. Any reason not to?
  myles: The sets of characters are designed for cjk.
  fantasai: First and last are all languages. End is CJK. I don't
            expect them to use last because they'll use end. Should
            that set include colons and dashes?
  myles: What's I'm describing is the set has a list of characters.
         You want to add to the list. I think instead of one list we
         add to we should have general sets.
  fantasai: We can do that. But the property defining those sets need
            to have values.
  myles: The set I see here is designed for one typographic use case.

  astearns: Are you asking when we add this new set it's distinct in
            the spec? When we add this it'll be in a set.
  myles: It can be added both sets.
  astearns: You're asking for things to be added in sets based on use
  myles: Yes. I think we should consider this at higher level. For
         this use case hang these. And this use case hang these.
  astearns: For fantasai we need a default.
  myles: Colon doesn't fit in the current set.
  fantasai: You're looking at the set for end. The last value hangs
            a bunch of large punctuation categories. Do we add more
            which is colons and dashes.
  koji: I share myles' concerns. The property was defined first for
        CJK so there's a lot of CJK. If we want to support Latin
        hanging punctuation we should think about a proper set of
        hanging punctuation for Latin.
  fantasai: We didn't want to do optical margins in L3, but first
            and last is in L3.

  fantasai: I would ask the question, there's clear use cases for
            hanging colons and dashes. Is there a reason why we
  koji: We don't know what the design should be when this property
        includes other scripts. Doing that right now may conflict.
  astearns: Not sure I agree. I think you have to give evidence that
            adding colons and hyphens to the sets would break CJK
  koji: As fantasai said last isn't used in CJK.  First is for CJK,
        last is for Latin.
  fantasai: We're asking to change the set of characters in last to
            include more characters.
  koji: I think we will have more characters. I wish us to start
        thinking about hanging punctuation in a serious way.

  florian: Remove last until we know what we'll do with it?
  myles: There is an impl, at least one.  Proposal is don't touch for
         now and have a more elaborate extension in next spec level
  astearns: Defer this to text level 4 is proposal.

  fantasai: I feel that every time we talk hanging punctuation people
            gets confused. I'm trying to distinguish hanging
            punctuation at end of every time vs that you do at
            beginning of first and end of last line. It's a different
            set of characters.
  fantasai: You want to pull out the quotation mark from the outside
            of the start of the paragraph, but you wouldn't want to do
            it anywhere else. It's a different set of characters and a
            different feature.
  florian: And within that set these characters make sense.
  astearns: In the permutations I'm familiar with, optical margin
            alignment is the thing in text 4 and hanging punctuation
            is what's in L3. But I don't know if my concept of hanging
            punctuation in Roman can extend to CJK.
  florian: For you would colon and dash be included?
  astearns: Yeah.
  fantasai: We're solving 2 use cases in L3.
  astearns: We don't have to have a complete feature in a module. That
            we're close to CR makes me hesitant to add more things.

  florian: This new character solves the second feature better. Should
           it be incomplete in L3?
  astearns: Yes because we have an impl and we can refine in a future
  fantasai: But it's a change in behavior, not an addition.
  koji: I think colon and dash isn't a significant difference to add
        in L4.
  florian: We'd have to revise L3.
  koji: Future level can change past features.
  florian: It means you can't conform to both.
  myles: When you impl hanging punctuation there will be tests to say
         don't hang anything not in this list?
  florian: Yes. You should test these character and only these
           characters hang.
  astearns: That the spec says UA may include other characters as
            appropriate makes me think this is extensible.
  astearns: I prefer to defer.
  fantasai: It's fine, but we'll discuss in Sydney.
  astearns: I'd like to go into more details on the set in L4.
  astearns: Objections to defer to L4?

  RESOLVED: Defer this to L4.

  <br type="15 min">
Received on Thursday, 17 May 2018 07:33:22 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 17 May 2018 07:33:23 UTC