W3C home > Mailing lists > Public > www-style@w3.org > July 2019

[CSSWG] Minutes Toronto F2F 2019-06-05 Part I: CSS Text, Writing Modes [css-text-4] [css-writing-modes]

From: Dael Jackson <daelcss@gmail.com>
Date: Sat, 6 Jul 2019 18:50:53 -0400
Message-ID: <CADhPm3tj7doS846DzFnx26JGGPE9nOcyjzzvUpXv4MMcgVy30g@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
--------

  - Florian presented a proposal to add space expansion properties to
      CSS ( https://specs.rivoal.net/css-space-expansion/ ) to address
      use cases for languages that do not usually use spaces, but
      occasionally still want them.
      - This would function similar to a text-transform when
          interacting with justification and word spacing
      - There was a desire to have a separation in properties between
          when spaces should be expanded manually vs automatically
          since those were different use cases.

  - RESOLVED: Add zero-width-space-expansion to Text 4, plan to rename
  - RESOLVED: Add manual vs automatic space expansion property (name
              and values TBD) to Text 4
  - RESOLVED: Add a note to the spec about considering not hyphenating
              proper nouns, but no normative changes (Issue #3927:
              hyphens:auto should not hyphenate Capitalized words)

Writing Modes
-------------

  - RESOLVED: Propagate direction, and writing mode from the body to
              the root without affecting computed styles w/optional
              text-orientation (Issue #3066: Does vertical writing
              mode of an HTML body element cause an orthogonal flow?)

===== FULL MINUTES BELOW ======

Agenda: https://wiki.csswg.org/planning/toronto-2019

Present:
  Rachel Andrew, Fronteers
  Rossen Atanassov, Microsoft
  Tab Atkins, Google
  L. David Baron, Mozilla
  Amelia Bellamy-Royds, Invited Expert
  Oriol Brufau, Igalia
  Tantek Çelik, Mozilla
  Dave Cramer, Hachette Livre
  Elika Etemad, Invited Expert
  Rob Flack, Google
  Jihye Hong, LGE
  Koji Ishii, Google
  Brian Kardell, Igalia and Open JS Foundation
  Ian Kilpatrick, Google
  Una Kravets, Google
  Chris Lilley, W3C
  Stanton Marcum, Amazon
  Cameron McCormack, Mozilla
  Theresa O'Connor, Apple
  François Remy, Invited Expert
  Florian Rivoal, Invited Expert
  Jen Simmons, Mozilla
  Alan Stearns, Adobe
  Lea Verou, Invited Expert

Scribe: Una

CSS Text
========

Space Expansion
---------------
  proposal: https://specs.rivoal.net/css-space-expansion/

  florian: So there are a number of languages (human languages, e.g.
           Japanese) where there are no spaces between the words when
           you break them normally
  florian: and usually in Japanese for example, in children's books
           (or for language learners) they do use spaces between words
  florian: or they have space separated chunks of sentences
  florian: Sometimes they switch to a mode where they only break the
           line between words
  florian: The primary use for this is textbooks and storybooks for
           young children but also books for language learners
  florian: and its also something people with dyslexia appreciate
  florian: and so the ability to style a text to have word separation
           with spaces or not is a stylistic choice where the dominant
           style is to not do this, but sometimes you want it
  florian: There is an increasing push to do this, and the government
           is pushing for all textbooks to be available in electronic
           format
  florian: Next week there is an exhibition in Japan where several
           companies are going to announce ebook solutions where there
           is not a public standard for this
  florian: It turns out that very little is actually missing, so after
           discussing this with the Japanese publishers and fantasai,
           we came up with a solution
  florian: that allows for unicode and have a CSS prop that turns
           these into spaces so you do your markup with normal
           Japanese text except you include your text with space
           properties

  hober: But that doesn't include the case where you want to include
         line spaces
  florian: word-break would re-introduce this, the line-breaking is
           already handles but space-insertion is not
  florian: The spec I'm introducing lets you expand these spaces

  chris: So if you're copying and pasting (i.e. with plaintext) you're
         not going to see any visual difference
  florian: So I wasn't seeing that in the presentation-preserving
           sense, but when people author things
  florian: if you use the unicode character rather than the HTML tag,
           you could do a similar thing

  hober: If you round trip it, you don't get the word-break: keep-all
         behavior - how would the other environments know?
  fantasai: All of these presentations are valid presentations, it
            just depends on the user context as to what they want. It
            will wrap and look like normal text otherwise
  fantasai: When you copy text out of an HTML doc where it operates
            under loose rules of line-breaking into an environment
            where it breaks strictly, there's still no problem with
            the text
  fantasai: It's a similar concept to this

  florian: Just to finish this up: the property is designed to be
           inheritable
  florian: If you want to selectively turn on some word breaks and not
           others, you can put classes on your wbr's and turn it off
           here and there
  florian: and then in the spec I have a few examples

  AmeliaBR: How does this interact w/justification and word spacing?
  florian: It's kind of like a text transform
  AmeliaBR: So justification/wordspacing would be applied after?
  florian: Yes
  florian: I started with a Japanese usecase for this. We're using
           ZWSP / <wbr>, something that is valid if not common in Thai.

  fantasai: Other cases where this could be useful: Etheopic
            typesetting
  fantasai: This property could be able to switch between using spaces
            and using Ethiopic word spaces.
            Also Korean where you want to collapse spaces
  fantasai: We haven't gotten a demand for these use cases, but we
            should design the property with these possibilities in
            mind.
  chris: This sounds like you have an open ended list of substitution
         chars
  fantasai: General substitution is probably a separate property.
            (See Håkon's suggestion for text-replace.)
  florian: Based on the Etheopic/Korean use case, it's probably not a
           space-expansion property, but a space-substitution prop
  florian: so theres a bit of bikeshedding to figure out what we want
           this to expand to
  chris: Space substitution sounds like the content gets changed

  koji: I have two pieces of feedback:
  koji: 1 is for the usecase this is done by a font feature
  koji: 2 the other one is about the content is okay with keyed
        content, and combining this idea with keyboard, but a11y
        includes non-keyed content. Keyboard is not enough
  fantasai: If you want to 100% control breaks with the wbr element,
            you can set the entire element with whitespace:nowrap
  koji: I disagree [...]
  florian: That's a bug, whitespace applies to inlines, and something
           that should wrap inside of it and doesn't wrap should be
           fixed
  emilio: we definitely did have compat bugs and fixed them
  florian: There are definitely bugs left in that area, but the bugs
           are getting fewer
  koji: What about the other part? I think substitution can be better
        done by font features
  florian: This does not interact with other properties done by CSS
           text, these are regular spaces substituted in. All the text
           works
  myles: Strong argument this should be done by every font
  florian: Yes
  koji: zwsp has justification impact
  fantasai: No, it's not allowed to expand

  astearns: You mentioned that there are proprietary ebook solutions
            proposed for this, do you know what they are?
  florian: I don't know what they are, I just know they will be
           announced
  florian: I don't know how they work, I just know its a topic that is
           bubbling in the market
  astearns: We should probably get their input on how they want their
            ecosystems to express this thing
  florian: I haven't talked to the software vendors, but I've talked
           to the publishers -
  florian: they don't want to get vendor-locked
  florian: That's why Japanese publishers are pushing for this
  florian: they don't want to do something that turns away from the
           open platform of the web

  AmeliaBR: I have 2 questions:
  AmeliaBR: 1. Is it feasible to get acceptable results from this in
            an auto way (like a hyphenation dictionary)
  AmeliaBR: End users might want to change display but that only works
            if the text has these complex word breaking inserted
  florian: Yes and no - some kind of natural language processing could
           insert this. Probably in regular publishing that is meant
           to do this, there is some degree of automation and some
           manual
  florian: language analysis is not 100% reliable
  florian: If it's done automatically you'd get some mistakes, only
           some degree being right
  florian: In the textbook concept, since there are different degrees
           of strictness, for content that is intentionally prepped
           for this, they'd probably use a bunch of manual application
  AmeliaBR: So then my question is - is it reasonable to treat this
            like automatic hyphenation in the browser?
  fantasai: I think you'd have to do grammatical analysis, not just
            dictionary-matching
  fantasai: I don't think we'd want to build that into the browser

  AmeliaBR: My second q - you said it behaves like a text transform.
            Why does it need to be a separate property?
  florian: I'm leaning toward it not being a part of text transform
           for 2 reasons - text transform happens after whitespace
           collapsing, I think this should happen before
  florian: Another reason is from an author point of view this should
           be separate
  florian: the inner mechanism can use some of the same machinery
  florian: That's issue 3 in the spec
  fantasai: Cascading separately is really the reason it should be a
            separate property

  dauwhe: This reminds me of something completely different
  dauwhe: Sometimes when people have text of poetry, they separate the
          lines with slashes
  dauwhe: and go back and forth with great annoyance to line breaks
          and slashes
  fantasai: I'd like to deal with that using content generation on
            the <br> tag
  florian: In that case it's kind of similar
  fantasai: This one is doing a transformation on the result of the br
  florian: It's considered sort of equivalent to a whitespace

  myles: So I think this is a pretty interesting feature, and don't
         know much about it but I have q's..
  myles: There are text facilities for getting words and characters
         between some text, I wonder if the same facilities could be
         extended to iterate over clauses and rather than having
         content inject a bunch of zwsp and wbr,
  myles: for the same reason justification is done by the browser
  florian: I think this would fall short. Unlike hyphenation, it's not
           just dictionary based
  florian: It's harder to do - this kind of software exists in
           Japanese, but it's not all there and it sounds expensive
           and hard
  florian: You'll probably also want to add classes to your wbrs
  florian: to separate different words and the automated approach
           wouldn't be subtle enough to do this
  myles: That's still better than having people spray a bunch of chars
         inside their content
  fantasai: That might be good enough for general web browsing as an
            aid to the user, but not for publishing
  myles: I think hyphenation is great model for this
  myles: I think its worth investigating rather than defining this is
         the one true way
  fantasai: We need to do this quickly enough before the Japanese
            publishing industry is forced to switch to proprietary
            solutions
  florian: I don't think this model is incompatible with the automated
           mode in the future
  AmeliaBR: We can have an automatic model, and this is what do you do
            with those breaking opportunities
  AmeliaBR: A separate property could say whether you auto insert word
            break opportunities when there is a good browser solution

  myles: The next thing is, there are 2 mechanisms for describing
         where the spaces go -- why?
  florian: I would describe it as 1.5 instead of 2
  florian: When we've tried to characterize what wbr is, the fact that
           it effectively inserts zwsp is what makes this apply to wbrs
  florian: I want to be able to put classes on these wbrs
  florian: I think just doing it with wbrs and ignoring zero-width
           spaces would solve the problem-ish but it's not
           unimaginable to say an IME could insert zwsp between words
  <hober> see also https://unicode-org.atlassian.net/browse/ICU-6780
  myles: I was just about to say I like wbr because when you copy and
         paste they get stripped
  myles: ...
  florian: But those aren't garbage characters
  myles: Under which situation would someone want to change the value
         of the css here - why not bake it in, why is it configurable
  florian: Regular content people read is not spaced out but people
           with dyslexia will want that to be spaced out
  florian: You can add a browser extension to have this space out
           characters
  florian: if you're reusing the same content for various grades
           (school grades) you can space it based on grades
  fantasai: The Japanese industry can standardize levels of spacing
  AmeliaBR: It can become a part of the e-reader styling

  fantasai: A lot of ebook readers aren't going to do a lot of NLP,
            and the point is we want to provide visibility in the
            platform so people can build on top of it
  fantasai: I don't think its necessary for epub readers to analyze
            the text, it can be a css property they can turn on and
            off
  fantasai: suppose you have a website w/stories for children to read,
            they can use their own UI
  koji: I agree with Myles and we should try to make this a feature of
        the readers not the platform

  hober: Overall this sounds great, but one of the responses to the
         question of doing this automatically is that it might be hard
         to implement, and everyone uses ICU these days - there is a
         patch for myanmar line break
  hober: In principle this kind of thing could be done with ICU in
         shorter term
  hober: I'd like to tune-in to ICU case by case to make this happen
         automatically in the shorter-term
  AmeliaBR: We should think of the model as automatic when designing
            the props even if manual gets implemented first
  florian: Sounds reasonable. The model should at least be compat w/
           that

  fantasai: Automatic needs say which one type of segments to find,
            since there are different levels.
  stantonm: We've done analysis on word breaking, its not sufficient.
            ICU is not enough
  stantonm: You get about 80% of the way there
  fantasai: I think one of the things you have is with hyphenation,
            you get a word, and at what point do you decide at the
            0-width space that you don't want any breaks
  stantonm: I was also going to agree that the way to add spaces
            automatically without the markup - we do that w/kindle and
            don't see authors do a lot of extra work on their content
  stantonm: but allowing the flexibility to do this would be a nice
            touch

  florian: I see more optimism about the feasibility of manual
           insertion than what I heard in Japan
  florian: What I'd like to do at this point is take this as a
           standalone ED or more likely as a standalone section and go
           through them over the next couple of months
  florian: If some browsers find this interesting and implementation
           gets sponsored in others, we could make reasonable rapid
           progress in this
  florian: Does this look like something we should impl into text lvl
           4?
  AmeliaBR: Are you willing to accept this should be 2 properties - 1
            defining the transformation and 1 defining whether it
            should be manual or automatic?
  florian: I agree it should be manual and automatic whether that
           should be a flag
  fantasai: I think a separate property for automatic detection makes
            sense
  fantasai: It's quite a different usecase
  florian: Fair enough
  florian: We could put this into text level 4 and automatic text
           level insertion into level 4 as well
  fantasai: I think we need some kind of outline for the second prop
            but we can take a resolution to this one
  fantasai: I don't want to define a prop with undefined set of vals
            in the spec

  Rossen: We can do that -- for the 0-width space we can add this one
          now - any objections?
  Rossen: Resolved, and a separate resolution is to define the auto
          vs. manual one and once its ready lets bring it on the call
          and decide on it

  RESOLVED: Add zero-width-space-expansion to Text 4
  RESOLVED: Add manual vs automatic space expansion property (name
            and values TBD) to Text 4

  <AmeliaBR> [some name bikeshedding; agreement that we don't want to
             bake the character name zero-width-space into the
             property name]
  <fantasai> We should rename the property in a way that isn't tied
             into specific character names
  <fantasai> one possible future use case is switching between space /
             ethiopic word-space
  <fantasai> (which is a visible character)
  <fantasai> so take that into consideration

  Rossen: Let's move onto the next topic: issue 3927


hyphens:auto should not hyphenate Capitalized words
---------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3927

  florian: So the issue being raised is that in some languages, when
           words are capitalized you should hyphenate and in some they
           should not
  florian: We should bake this into the spec
  florian: I'd like to close this as won't fix or rejected because we
           already say this is dictionary based within the logic of
           the language-based resource
  fantasai: I would go a little farther and say that we should put
            a note and but not change normative requirements and talk
            about proper nouns
  fantasai: It can suggest i.e. in English you may want to suppress
            hyphenation words that are proper nouns and mixed case
  fantasai: I would like to leave the heuristics up to the user agent
            and not bake anything into the spec, however.

  dauwhe: In English should capitalized words be hyphenated? maybe... I
          wouldn't want anything baked into the spec that says what
          should happen
  AmeliaBR: The recommendation is more to add a suggested note to add
            in your hyphenation dictionaries you should consider this
  AmeliaBR: at least one browser has agreed
  AmeliaBR: Not sure this is a normative requirement
  Rossen: So proposed resolution for this is to add a note and no
          normative change

  RESOLVED: Add a note to the spec and close with no normative change

Writing Modes
=============

Does vertical writing mode of an HTML body element cause an
    orthogonal flow?
-----------------------------------------------------------
  github: https://github.com/w3c/csswg-drafts/issues/3066

  fantasai: This deals with the fact that we have writing mode
            propagation from writing mode to HTML that is not very
            consistently implemented
  fantasai: It seems to me that we should propagate it to the HTML
            element and consequently not have an orthogonal flow
            because it's on the the entire doc, not the root element
  Rossen: So this is only the case when writing mode is specified on
          the body only
  fantasai: Whether you specify one on the body or not, we're
            basically ignoring it
  Rossen: You end up with double scrollbars sometimes on the wrong
          sides
  fantasai: Edge doesn't do that
  fantasai: My proposal would be to do what Edge did
  fantasai: There's a few things that need to be fixed, but the
            proposed resolution is to go with what Edge did which is
            that the body writing mode is propagated to both the root
            element and the writing block
  AmeliaBR: So it would be treated the same as if you set it on the
            HTML
  Rossen: As an overwrite
  emilio: There is a viewport implementation, but the root element
          style is different
  Rossen: Wish we had a time machine to go back and have fixed this
          when it was originally done
  fantasai: There are margin-collapsing bugs
  fantasai: We resolved to propagate things before but there are some
            side effects

  koji: In chrome, we used to track the propagate and we resolved not
        to propagate and removed the code
  fantasai: Really? I remember it wasn't possible due to compat
  florian: IIRC direction does not propagate
  emilio: We should use a computed value propagation?
  dbaron: The way the spec describes this propagation, it is not
          affecting the computed styles
  koji: Only the principle writing mode is affected but no style
        propagation
  dbaron: If I read what the spec says literally - it is saying that
          if you set writing mode on body to vertical LR
  dbaron: You have an initial containing block that's vertical-lr
          containing a block for the html element that's horizontal
          containing a block for the body that's vertical-lr
  florian: Either don't do any propagation at all or have all of those
           things use the same writing mode
  koji: Propagation leads to conflicts
  dbaron: The hardest part of style is changing the computed styles,
          if you want to fix this propagation you want to make the
          propagated value also apply to the block for the elem
  dbaron: without messing with styles at all, making it apply to both
          the block and the styles for the html

  florian: We added propagation because it felt necessary and I don't
           think we can remove it
  fantasai: My recollection was compat requirements for ebooks, which
            is why we have it
  emilio: Batch propagates writing mode properties
  emilio: direction, writing mode, etc.
  fantasai: I think we're propagating the full set, doing part of it
            will get weirdly inconsistent
  fantasai: writing mode, direction, text orientation are the set of
            props that determine the direction mapping
  fantasai: I think text-orientation won't have any effect on the
            initial containing block anyway

  Rossen: So are we leaning towards that resolution that defined the
          propagation without affecting computed styles?
  Rossen: So the style subsystem doesn't have to be complex, but the
          experience makes sense and it avoids orthogonal flow changes
          when they're not needed
  emilio: It'll be weird if you have a pseudo-element in the root
          element but I guess thats not very common
  iank: I'm a big concerned about the performance implications
  Rossen: Let's evaluate the performance once you have a patch that
          actually does it
  Rossen: in terms of behavior the proposed resolution is to add from
          body to the root element, the propagation & logic

  heycam: Is this for any root element?
  Rossen: I remember we didn't do this for SVG
  AmeliaBR: Is there a reason not to do it for SVG?
  Rossen: We didn't have body element in SVG
  AmeliaBR: The propagation doesn't apply but the fact that the root
            element defines a principle writing mode for the document
            should apply to SVG
  Rossen & fantasai: sure

  iank: What happens to properties like border-block-end?
  fantasai: For propagating the user values, they're resolved before
            writing implementation
  iank: I'm concerned about low-end device performance
  Rossen: Let's talk about it when we have a little more info
  AmeliaBR: So is the resolution full propagation from the body to the
            root
  Rossen: Propagate direction, writing mode, and text orientation from
          the body to the root without affecting computed styles
  fantasai: The case of the document specifying vertical text
            orientation on the entire document and also being RTL is
            an unusual use case
  Rossen: The proposed resolution is the same minus text-orientation
  fantasai: We could say propagated text orientation is optional

  proposed resolution: propagate direction, and writing mode from the
      body to the root without affecting computed styles w/optional
      text-orientation

  RESOLVED: Propagate direction, and writing mode from the body to the
            root without affecting computed styles w/optional
            text-orientation

  fantasai: We'll need an implementation report and some bug fixes
  Rossen: Is it vastly different than what was done before?
  fantasai: It needs an update
  florian: We're a week worth of work away from making it a rec - bug
           fixing and updating the implementation report

  <break>
Received on Saturday, 6 July 2019 22:51:47 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 6 July 2019 22:51:47 UTC