[CSSWG] Minutes Telecon 2018-12-19 [fxtf] [css-grid] [css-text]

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

Move SVG text-decoration features to a CSS draft

  - RESOLVED: text-decoration-fill and -stroke goes into Fill and
              Stroke spec. Shapes properties go into Shapes L2. Both
              with notes they're at risk and looking for implementer
              interest. (SVG Issue #591)

CSS Grid

  - RESOLVED: Close this issue (Issue #3445: Non-existent line names
              in abspos grid items) and accept the clarification note.

CSS Text

  - RESOLVED: Add a clarifying note to L3 and discuss a potential new
              value in L4 (Issue #3434: Prevent line breaking after
              explicit hyphens)
  - There is disagreement to if the segment break transformation rules
      should be defined using East Asian Width or if there's a
      different approach available.
      - The argument to use East Asian Width is that currently line
          breaks are unusable and this moves toward addressing that
          even though it requires special casing some characters, like
          emoji. Additionally more characters can be added at a later
          date if a better system is found.
      - The argument against is that since it is currently unused time
          should be taken to find the right solution and avoid risk
          that we'll end up with a compatibility problem later.
      - fantasai stated that there were two principles she's like to
          solution to adhere to:
          1: We have defined rules all UAs must follow.
          2: We're using unicode property of some kind and not having
              CSS spec create a custom list
      - Discussion will continue on the issue and then on a telecon or


Agenda: https://lists.w3.org/Archives/Public/www-style/2018Dec/0028.html

  Rossen Atanassov
  Tab Atkins
  David Baron
  Amelia Bellamy-Royds
  Tantek Çelik
  Dave Cramer
  Elika Etemad
  Javier Fernandez
  Tony Graham
  Dael Jackson
  Brad Kemper
  Peter Linss
  Myles Maxfield
  Michael Miller
  Anton Prowse
  Melanie Richards
  Florian Rivoal
  Jen Simmons
  Alan Stearns

  Chris Harrelson
  Chris Lilley
  Nigel Megitt
  Manuel Rego Casasnovas
  Lea Verou
  Greg Whitworth

Scribe: dael

Next F2F

  Rossen: Let's get going
  Rossen: As usual first agenda item is call for any extra items
  Rossen: Or any changes you would like to see to the current agenda
  florian: One on scheduling, I think. fantasai you wanted to mention
           a side meeting on inline?
  fantasai: There was a lot of inline topics, wondering if want to
            spend extra time around F2F on those issues. Not sure what
            would be on the agenda. If anyone is interested we can try
            and schedule.
  Rossen: Can we try and do this on the private list to see what works
  fantasai: mmhmm
  Rossen: I think this is a great idea.
  Rossen: Anything else?

Move SVG text-decoration features to a CSS draft
  github: https://github.com/w3c/svgwg/issues/591

  Rossen: Is krit on?
  astearns: I don't think he is, but said it was fine without him.

  Rossen: Request is to move text decoration features into CSS WD
  Rossen: Sounds like we took all resolutions last week about moving
  Rossen: We have resolution for text-decoration-fill and -stroke.
          What's asked now?
  astearns: Resolutions are from SVG WG
  Rossen: You're correct. I was remembering the resolution frenzy a
          week or 2 ago

  Rossen: So SVG group is more then happy if we can take text decor
          related properties back into CSS
  Rossen: Since there are already resolutions on this in the issue we
          can do one to accept them all
  Rossen: Comments or objections?

  <tantek> are they implemented outside of SVG?

  florian: Would this be text decoration L4?
  Rossen: That would be my expectation unless there's a reason to put
          anywhere else
  AmeliaBR: Fill and stroke module is other logical place. We're
            recommending to move to CSS because fill and stroke is
            taking basic fill and stroke properties which these line
            up with. They're equivalent of text decoration color but
            if you're using fill and stroke you need to continue that
  AmeliaBR: They're in SVG2 right now, but not stable enough for
            implementation to stay there as we go to CR. Fill and
            stroke module is also called CSS Paints
  AmeliaBR: It's in FXTF repo
  <AmeliaBR> https://drafts.fxtf.org/paint/

  florian: Is there a resolution to move these to CSS Repo?
  AmeliaBR: All FXTF specs are full responsibility of CSS
  florian: Yes, but did we resolve to move them?
  Rossen: Yes, I'm pretty sure we have resolutions

  tantek: Are these implemented yet? Or are they things implementors
          said they want to implement?
  AmeliaBR: No implementations yet which is why we can't keep in SVG2
  tantek: Makes sense for moving them out.
  tantek: Do we have any positive noises or statements about intent to
          experiment or implement from any implementors?
  AmeliaBR: In SVG we've had positive statements of the type where if
            anyone else implemented we'll implement too. Nothing
            beyond that
  Rossen: Shape properties were discussed at length. Only implementor
          at time interested was inkscape. Browser implementors
          weren't interested at the time
  Rossen: I remember a couple years ago consensus was we will move and
          use CSS shapes L2 and go from there. See how much
          implementor interest that takes
  Rossen: text-decoration-fill/-stroke I don't recall. I trust
  Rossen: If the leading question is if they should go to WICG instead
          that's a good point
  fantasai: I think these properties are quite straight forwardly
            analogous to what is in fill and stroke already. Question
            on if they should exist is more interesting. We can add
            and say at risk and point out we're not sure this is high
            priority to have fill and stroke separate. I don't think
            WICG makes any sense because it's analogous to what we have
  TabAtkins: Agree. At bare min we're adopting the definitions as
             exist. We can put in an appendix and note they may not
             make it.
  tantek: I'm okay incubating these in WG because we've shown good
          practice in the past. If we don't have implementors with
          interest I'd ask we note in the spec we're looking for
          implementor interest so we're transparent. Other then that
          fine with where group puts this
  fantasai: We can put this in an appendix with that note
  <myles> I'd like to implement these someday eventually
  <tantek> concern with appendix is that indicates informative intent,
           whereas I think I am hearing normative intent
  <fantasai> tantek, appendices are normative unless otherwise noted

  AmeliaBR: There's a placeholder section already in fill and stroke
            and it even says they should be at risk, just doesn't have
            actual definitions. Can slot in neatly there right now
  <astearns> https://drafts.fxtf.org/fill-stroke/#text-decor

  Rossen: Sounds like we're taking text-decoration-fill/-stroke into
          Fill and Stroke spec and shapes into Shapes L2 with a note
          calling for impl interest
  Rossen: Reasonable?
  <tantek> +1
  Rossen: Objections to adopting text decoration fill and stroke into
          text decoration with a note calling for impl interest. Same
          for shaping into Shape L2?
  AmeliaBR: Fill and stroke spec is what we talked about.
  Rossen: Sorry, text-decoration-fill and -stroke goes into fill and
          stroke. Shapes properties go into Shapes L2

  RESOLVED: text-decoration-fill and -stroke goes into Fill and Stroke
            spec. Shapes properties go into Shapes L2. Both with notes
            they're at risk and looking for implementor interest.

CSS Grid

Non-existent line names in abspos grid items
  github: https://github.com/w3c/csswg-drafts/issues/3445

  fantasai: Wanted to confirm everything with WG since it's CR.
  Rossen: Can you summarize?
  fantasai: Issue was about the reference for line name. Currently
            define implicit lines have all the names. Abspos referring
            to line name not in explicit grid. Had been a case where
            someone referenced a non existent line in inflow grid and
            caused a line to be created and now abspos is looking for
            a different line name. We defined it's looking for
            implicit line. Added a note to clarify, everyone seems in
  florian: Close no change or close with clarification note?
  fantasai: Close with clarification note
  <lajava> I've been discussing this with rego and we agree that the
           note clarifies the issue
  Rossen: Objections to close this issue and accept the clarification

  RESOLVED: Close this issue and accept the clarification note

CSS Text

Prevent line breaking after explicit hyphens
  github: https://github.com/w3c/csswg-drafts/issues/3434

  <fantasai> https://drafts.csswg.org/css-text-3/#hyphenation
  florian: Not entirely clear to me at least and at least one other
           implementor if hyphens:none is meant for only suppressing
           invisible but leave existing hyphens alone or if it's meant
           to turn off wrapping opportunity at regular hyphens
  florian: koji and, I think, fantasai understood to not doing
           anything to normal hyphens. But I read that it's no
           breaking at hyphens. Either way we should clarify. If we
           clarify to say it's not suppressed maybe explore a control
           in the next level
  florian: Current spec is not clear so we should clarify
  florian: Spec says suppresses hyphenation opportunities. Doesn't
           define a hyphenation opportunity.
  florian: That's where ambiguous comes from
  dbaron: You'd think hyphenation opportunity is different then
          breaking opportunity.
  florian: Different from wrapping opportunity. Wrapping opportunity
           that's right after a hyphen is different. I can see it's
           reasonable for the spec to mean it

  AmeliaBR: As an author, I've come across places where I want to
            suppress break at hyphens. But you can do that by turning
            off wrapping
  florian: You can do it with extra mark up.
  astearns: Need extra to signal intent. It's not breaking at any
            breaking opportunity in that string. If you have a regular
            hyphen and words on either side with breaking opportunity
            you don't want those to break either
  <myles> ++astearns
  florian: You mean you would allow in other places as well? The
           automatic hyphenation. But in this no auto, no wrapping.
  astearns: You want markup on the special words where you don't want
            entire term to break
  florian: Not opposed to saying hyphens:none does not disable
           wrapping at regular hyphens. I think we could use a little
  florian: It does seem that's what spec intends, but was not obvious.
  AmeliaBR: I like clarifying hyphenation opportunity is opportunity
            to insert a hyphen. Breaking opportunity is second to that.
  florian: And we can re-open an issue on L4 to explore if we want an
           automatic way of doing this.

  dauwhe: We have general rule where we don't want to hyphenate
          hyphenated phrases and I'd love some css control for that
          that doesn't involve preprocessing thousands of words. But
          that's L4
  dauwhe: We don't want to hyphenate words with intrinsic hyphens
  florian: That's dealt with. This is a different case.
  dauwhe: I'm phrasing in a different way. But yes we don't want line
          breaks anywhere in those phases as astearns said
  fantasai: Seems really weird that you'd take hyphenated phrase like
            one in issue, forbid breaking in a long term is unusually
            strict. I can see not breaking at a point that's not the
            hyphen, but breaking at hyphen I don't imagine you'd want
            to suppress.
  <bradk> “E-Mail” should not wrap
  fantasai: Case here is someone that doesn't want hyphenation and is
            getting breaks at hyphens. And they thought they turned
            off hyphens and think hyphens and breaking is analogous
  AmeliaBR: I think there is a Unicode character for hyphen without
  fantasai: I think it makes sense suppress hyphens at breaks through
            hyphens property. Given current state of implementations
            hyphens:none does not suppress those breaks. Might mean we
            add a value in L4 that means no really don't break at
            hyphens or hyphenation points.

  myles: What's the example?
  florian: bradk's IRC example. You'd never want e-mail to break
  <AmeliaBR> @bradk, I think that would also be covered by
  myles: This is about things like long-term and t-shirt
  <dauwhe> https://www.princexml.com/doc-refs/#prop-prince-hyphenate-before
  fantasai: t-shirt could be a case where you don't break if it's less
            then 2 char on other side. You can control that for
            hyphenation in L4.
  fantasai: long-term breaking there is less likely to be because each
            half is too short
  florian: Seems like stylistic choice in this case

  florian: Can we resolve for L3 to clarify as AmeliaBR and I spoke of
           and leave it open for L4 and hash it out there? Seem

  myles: One more thought, in section it says it affects searching and
         copying. I think affecting copying is a feature not a bug.
  florian: Possibly. Searching is more annoying
  myles: Have to look at searching. Searching is more complex
  fantasai: NFK normalization
  florian: There was spec by i18n to help browsers figure out what to
           do when searching
  myles: Like curly quotation marks match straight quotation marks
  myles: We use ICU usearch facilities
  florian: I think we're a little off topic. L3 hyphens:none doesn't
           do what we talked about, open issue in L4?
  fantasai: I think we wouldn't change meaning of none in L4.
  florian: We might add a value.
  fantasai: Fine with me.
  <bradk> 👍
  Rossen: Any objections to add a clarifying note to L3 and discuss a
          potential new value in L4?

  RESOLVED: Add a clarifying note to L3 and discuss a potential new
            value in L4

Segment Break Transformation Rules for East Asian Width property of A
  github: https://github.com/w3c/csswg-drafts/issues/337#issuecomment-446842105

  Rossen: Brought back from week before if I recall
  Rossen: Additional comments from koji. Wanted to have koji comment.
  Rossen: Do we have koji or enough from his feedback that we can
  myles: I think I understand koji's feedback
  Rossen: So we can make progress and see if can resolve

  florian: Context is suppressing segment breaks in source code. If
           you have word space word space the segment break is
           converted to a space, but in languages without spaces we're
           having a part of the spec deal with suppressing.
           Non-controversial part has been shipped. Characters on both
           sides of break are unambiguously CJK
  florian: What do we do when one side is ambiguous like ". Initial
           proposal was when segment break is language tag as CJ and
           one side is ambiguous and the other unambiguous we suppress.
  florian: emoji, though, was inconsistent. Some wide, some narrow,
           some ambiguous. We proposed in spec to treat all emoji as
           ambiguous so if you had unambiguous Asian on the other side
           you suppress the break
  florian: koji pushed back and myles agrees with pushback

  myles: I think we can all agree on goal. If you have Chinese text
         line break in the middle shouldn't turn into a space.
  myles: When I was reading spec the whole section on how to determine
         if suppress space proposal looks at East Asian Width and then
         emoji and then elsewhere and it seemed this wouldn't work in
         a lot of cases we haven't thought of. The more we try and fix
         this section the more complex it gets and the more we'll miss
  myles: I think that's similar to koji where if you add a case for
         emoji you'll have to add a case to reduce set of emoji
         because unicode says more is emoji then people think. Instead
         of spec behavior only one browser impl we should let browsers
         experiment and try and come up with a better way, perhaps
         involving unicode consortium.
  florian: Agree with part, but not all. Languages are complicated so
           if we want to cover all cases rules will be complicated. If
           we are not careful here and we add too many things we later
           want to remove that would be problematic.
  florian: Being cautious about what to add, I would agree.
  florian: On the other hand, letting UA experiment- that's not
           reliable for authors so they can't do anything. If both
           sides are clearly Asian there's no worry and we should do
           it. Ambiguous on one side and break is Asian and other side
           is Asian we're safe.
  florian: Emoji we went through everything and found that we thought
           adding all of it was safe. I'd be okay with you double
  florian: I suspect there will be more areas of inconsistency. We
           will at some point say this is rare enough and we're not
           handling it. I think we should solve enough that East Asian
           languages can have line breaks.
  florian: I would say let's be careful with what we add. I think we
           have been with emoji. There is a slope here, but we can
           decide how far down we go
  <fantasai> proposal wrt emoji is in
  <fantasai> you can see the entire list of affected characters

  myles: Rather then going half way down the slope and saying no more,
         we should investigate another approach
  florian: Do you have a suggestion on another type of approach? I
           feel this will be about subsets of unicode things. How to
           do it may have strategies.
  myles: I don't have a specific proposal and that's why I think more
         room to experiment. I don't think we're at a point where we
         can say some should and some should not react this way. I
         think we're at an early phase.
  fantasai: I don't think that's the case. Spec has used East Asian
            Width property and no one has said we shouldn't use that.
            The details of how we're using it we're finding in some
            cases it needs to be tailored to do it in the same way.
            Smiley face is neutral and grinning is wide, but author
            won't expect that.
  fantasai: I don't think it makes sense for us to have an environment
            where they can't know that their space will get eaten by
            changing smiley. Rule florian has is there are subsets of
            emoji where we don't know why they're wide.
  florian: They're mostly classified due to what legacy encoding they
           came from
  myles: I agree East Asian Width doesn't work well. Possible solution
         is don't use East Asian Width and I'd like to pursue that
  fantasai: Alternative is script + script extensions property. Other
            then that it's creating a custom list which we won't do.
  florian: That's because maintenance.
  florian: East Asian Width spec says it should be tailored
  koji: I agree with myles. East Asian Width is designed to be compat
        with encoding. Not designed for this purpose. We'll see lots
        of inconsistencies. Options are live with inconsistencies. If
        we don't want that, don't use East Asian Width

  florian: My feeling is in terms of web compat if we add more cases
           to suppress it's safe. Removing is bad. If we find a more
           efficient approach later that characterizes more characters
           we can move to that. We should be careful to not suppress
           spaces that really should be there. Even if way we reach
           character set is more complicated then you wish, that's not
           a long term problem. If we find a better way in the future
           we can do that as long as we didn't include so many
  florian: I think marking some of it at risk we can do that. But it's
           not going to do wrong behavior in a way that we can't walk
  florian: So I propose mark as at risk, but leave it, and welcome
  koji: If we find myles' point logic on East Asian Width wasn't great
        it's not backwards compat
  florian: Suggesting there are currently characters classified as
           wide that shouldn't suppress spaces? Because if there isn't
           any we're safe
  myles: One happy medium is to say there are some sets of triggers
         that will or won't cause suppression. Other then that it's up
         to browser. Kinda like line breaking with some restrictions
  fantasai: Where you break the line isn't a big deal. It doesn't look
            really wrong with slight differences. But if there is a
            space in one impl and not another that's a real problem
            for the typesetting. If there isn't interop the user can't
            check their text, looks fine, load in another browser and
            there's lots of space. We need interop and this isn't a
            good place for everyone decides.
  <dbaron> I think there are real web compatibility problems as a
           result of line breaking differences.
  myles: We've go through to today
  florian: No author uses line breaks in East Asian. We're trying to
           make it better
  myles: Why not solve now because they're not using it
  florian: Any solution will be a superset of what's specced today so
           I don't see why can't spec today. I'm willing to put part
           that you think is overkill at-risk
  myles: As spec right now there is an algorithm where every string
         produces yes or no suppress.
  florian: What I mean is if we say yes suppress to more things it
           won't cause web compat. If we say yes to fewer things it
           will. That's why I'm talking about supersets. If we add
           more things authors will be able to add more line breaks.
           So we can expand. Reducing is bad. So if there's a
           different solution later with a same size or larger set
           that's okay.
  myles: I'd like to expand that set without going through WG
  florian: I don't see how that works. Regardless of how we spec if
           browsers aren't interop it's not usable
  myles: Already not
  florian: Trying to make it usable
  myles: So wait
  florian: Wait until what? You say don't standardize and I say do.

  Rossen: We're getting too argumentative and I'm not sure we're ready
          to resolve. Discussion is valuable and brings us closer to
          something where we can resolve. Doesn't feel we're there yet.
  Rossen: Perhaps we can continue to work on this as part of the text
          inline focus group that will be proceeding F2F unless you
          feel strongly we can resolve
  florian: I don't feel we can. Taking it offline for now and next
           time we meet we keep talking sounds...not as good as
           resolving, but we can't resolve
  Rossen: But this conversation was great and gives room for people to

  fantasai: I want to say I insist on 2 things. 1: we have defined
            rules all UAs must follow. 2: We're using unicode property
            of some kind and not having CSS spec create a custom list
  <tantek> +1 to fantasai's two rules
  Rossen: We can recommend to people what they can do, we can't
          require it
  fantasai: Then you'll be non-compat with spec

  myles: I'd like to hear what unicode consortium has to say
  fantasai: Their feedback is East Asian Width is not something
            they're putting effort into maintaining
  florian: That conversation goes off topic, it's hard to share it all.
  fantasai: And we're explaining what we're doing and they ask if
            we're using UAX-14 properties and that's not helpful
  Rossen: Your point is valid. This won't bring us closer to
  Rossen: Let's table this and work more to get to something better
          for interop and for the web.

2018 In Review

  Rossen: We've got a minute left. I'd like to wrap up 2018 by
          thanking everyone for all the hard work. I wanted to share a
          quick state. In terms of how productive we were; If a WG is
          measured by amount of spec published then 2018 has been
  <myles> yaaaaaay!!!
  <tantek> Woohoo! 🎉
  Rossen: We have published 4 RECs, congrats to everyone that put the
          hard work into getting those. 13 CRs including one Houdini.
  Rossen: We have published 27 WDs, some of them a few times
  Rossen: We have published 44 documents which is unbelievable.
          Congratulations. 2017 we had 16, 2016 11, 2015 we had 8.
          We're trending quite well. Not sure we'll be able to keep
          that curve next year, we'd need over 100.
  Rossen: Bottom line, thank you for all of the hard work. I know
          editors have been pushing hard, people have been writing
          test cases, debating issues, all of this results in an
          awesome 2018. I'm looking forward to 2019 being even better.

  Rossen: Thank you again for a great 2018. Happy holidays to you and
          your family and we will be back on January 9th as our first
          2019 call
  Rossen: Happy holidays, talk to you in 2019

Received on Thursday, 20 December 2018 01:10:12 UTC