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