- From: Dael Jackson <daelcss@gmail.com>
- Date: Fri, 15 May 2020 18:48:18 -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 3
----------
- RESOLVED: Add "wrap-as" and values, details TBD later (Issue
#4949: Switch line-breaking handling of atomic inlines)
CSS Text Decor
--------------
- RESOLVED: Accept PR #4737, close issue #4276 (Clarifying
skip-ink:auto behavior in relation to CJK text)
- There was no disagreement with the spec text for
text-decoration-skip-spaces so bugs will be filed on
non-conforming implementations in order to trigger further
conversation with the implementors to see if the deviation was
intentional or simply bugs (Issue #4653: Variants of
text-decoration-skip-spaces:end behavior, and initial value).
===== FULL MINUTES BELOW ======
Agenda: https://wiki.csswg.org/planning/virtual-spring-2020#day-three-time-slot-3a
Scribe: fremy
CSS Text 3
==========
Switch line-breaking handling of atomic inlines
-----------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4949
fantasai: We had defined atomic inlines to work like ideographic
characters
fantasai: but that is unfortunately not web compatible
fantasai: even if this would be a nicer behavior
fantasai: But since forever, atomic inlines have allowed breaking
opportunities
fantasai: so we accepted our fate
fantasai: But there are use cases for the correct behavior though
fantasai: so there was a question of how to switch to that behavior
fantasai: One proposal was line-break != auto => atomic treated as ID
fantasai: Another option: wrap-before/after to control wrapping
before a particular inline, so you could have values to
prevent/avoid
fantasai: One of them could be this smart behavior
fantasai: So, do we want to introduce a switch of behavior toggle
fantasai: and if so, which option?
fantasai: An issue with 'line-break' is that its other effects
won't be very visible in most languages
fantasai: and koji was afraid some people might set it, then have
subtle unexpected effects for CJK languages
fantasai: The other option is more targeted
fantasai: but it has the downside you have to target each element
independently
florian: One other issue is that the line breaking properties
currently don't exist anywhere
florian: so adding new behavior to them is wishful thinking
myles: In all the ebooks that use images-as-text I have seen, they
use a class on these images
<faceless2> +1 to myles
myles: So the rule to target them all is very easy
koji: In the github issue, we said it's fine with the property, but
we want a different feature
koji: The proposal was to pretend that atomic inline was a
line-breaking class
koji: and as we discussed in other issues, we have to resolve the
ambiguity between elements boundaries
koji: and maybe that should be discussed in that context
koji: I like that idea that was proposed on github
koji: I talked to ICU people to see if that would be possible
koji: but that didn't get an approval
koji: so they suggested to pick a specific character instead
fantasai: I'm fine with selecting one specific character we consider
to be representative of ID
fantasai: It would be confusing for authors to have to pick a char
fantasai: The mapping can be implementation detail
koji: I agree
faceless2: I agree with koji, that proposal is quite flexible
florian: If this means we are going to prioritize implementing these
properties, I agree
florian: but this is a very useful case for us
florian: and just pushing it to a new level doesn't do much for us
<faceless2> We've implemented already I believe.
<faceless2> pending testing, of course...
myles: Priority of the feature > stage of the spec
myles: We should design the feature well, not worry to much about
which spec level we put things in
<fantasai> +1
florian: Yes, but what we are wanting to do is tie this to a new
property nobody implemented
florian: and we don't know if that property itself will survive or
still function in the same way
myles: I think it's true, but if this happens, we can revisit later
astearns: I agree with myles here
astearns: Also, it's very separate to how line-break works today
astearns: This extra switch doesn't sound like very good design to me
florian: ok, I rescind earlier me's comment
astearns: Sounds like we are in agreement to resolve to add one more
value to wrap-before/after, which would specify which
character we want to emulate
astearns: Is that correct?
faceless2: Does that make sense as a single property?
koji: Yes, maybe we want only want property, a "wrap" shorthand
fantasai: But he also mentioned that it was rather non-specific as a
name, and could be confusing
fantasai: Also, this wouldn't encompass "wrap-inside"
fantasai: but maybe "wrap-as: ideographic"?
koji: I like that naming
koji: Maybe we can have different ideas
koji: but one nice thing is if you apply on an inline box, we can
have each side apply to the first/last character of the inline
fantasai: Yes
florian: I don't like wrap-as: avoid
florian: Maybe wrap-outside: ideographic/avoid ?
fantasai: I like that
<myles> koji have you thought about how to implement an element
which has both wrap-before and wrap-after and they have
different values?
<myles> koji like if wrap-before is ideographic but wrap-after is
something else
fantasai: I am worried about changing the class of the chars though
fantasai: because it also affects the breaking between first and
second
fantasai: so I would say "for the purpose of breaking before" the
first character
fantasai: <span>abc</span> + wrap-outside: avoid should not affect
breaking between a and b
koji: Not sure I see what is wrong
fantasai: Because that is affecting the inside of the element
fantasai: while we are trying to change the behavior outside
koji: Yeah I understood correctly
koji: I have use case for that I think
koji: Elements never break, unless it's inline block
myles: But this issue is about atomics?
<fantasai> https://www.w3.org/TR/css-text-4/#wrap-before
fantasai: Yeah but wrap-before applies to inlines too
fantasai: so we need to define an effect for them as well
koji: Hence what I proposed
fantasai: Then I would prefer another property
fantasai: I really don't find the proposal to change the breaking
inside for changing the behavior outside
astearns: And that would allows combinations too?
fantasai: Yes, but there is no combination of values that makes sense
fantasai: (flex is special, and the others don't care about
character class)
fantasai: but if that's not possible to implement
fantasai: then we need another property
myles: Yes, it's worth talking about implementability
myles: When we compute the line breaking opportunities, we have a
big string, and opportunities
myles: The model we propose with before/after is not compatible with
how line breaker work today
myles: so I am in favor of a single property that works on both sides
astearns: If it doesn't really make sense to have separate switches
for both sides
astearns: then a new property that affects both is better
astearns: Correct?
<faceless2> <p>a <span style="margin-left: 5em;
white-space:pre>�a;</span> b</p>
faceless2: We had one use case where this didn't apply to an atomic
inline
faceless2: (...)_
fantasai: Yeah, I don't think we were proposing to remove the
properties all together
fantasai: Just that for the specific use case of atomic inlines, we
should have a separate one
<faceless2> My example above was a case where suppressing
line-breaking before a non-atomic inline was useful - in
that example we would want to prevent the break before
the <span>, due to the force break inside it.
astearns: Ok, so what I am hearing is support for "wrap-as" with
values for atomic inline
myles: And editors need to figure out interactions with the rest
fantasai: I don't think it is too difficult
koji: What about the values? a string would be nice?
fantasai: I am ok with the spec behavior described as that
fantasai: but I would rather specify keywords
fantasai: That would be map to some specific characters
myles: Was the proposal for the string to be a single char?
myles: Or "ideographic"
koji: No, the char between quotes
myles: Then I think I agree with florian and fantasai
fantasai: And I don't think people will even see this behavior as
using ideographic
florian: "normal"?
<faceless2> -1000 to normal
astearns: Doesn't mean much to me though
fantasai: I think it's decent name; "normal" is ID just because
fantasai: It happens ID is the best char to map to to have the
desired behavior
astearns: Proposed resolution is to add "wrap-as" and values,
details TBD later
RESOLVED: Add "wrap-as" and values, details TBD later
florian: level 3?
fantasai: no ^_^
<break>
<myles> fantasai so the grammar would be `normal | ideographic`?
<myles> fantasai and the initial value would be `normal`?
<fantasai> I was thinking 'wrap-as: break-all | normal'
<fantasai> with break-all as the initial value
<fantasai> or something like that I guess it's not clear it only
applies to objects
<fantasai> :/
<myles> i disagree with these names
<myles> we can discuss it in github i guess
<fantasai> myles, basically I think we should be clear with the
initial value that it breaks everything
<fantasai> and that the other value is treating it as text-like
<myles> fantasai: how about `break-all | ideographic`
<fantasai> I don't like using ideographic because it sounds like the
wrong thing to use for most people who will want it
<fantasai> It sounds like only CJK will want to use that value, but
in fact it's useful in many more contexts...
<fantasai> we didn't choose to emulate ID because of CJK, we chose
to emulate ID because it happened to have the correct
line-breaking behavior
<myles> i expect most people will want to use the break-all value
<fantasai> myles, I don't think so
<fantasai> break-all is the default, but it doesn't give sensible
behavior in running text
<fantasai> it breaks against nbsp
<fantasai> it breaks against )
<fantasai> it results in very awkward breaks if you actually use it
in running text
<myles> right, most images are images. most images don't look like
inline text
<myles> they should break on both sides by default
<jfkthame> advantage of `ideographic` is the clear mapping to the
unicode line-break algorithm
<fantasai> jfkthame, yes, but that's helpful to implementers not to
users :)
<jfkthame> we could use `ID` if you don't want it to sound so
clearly CJK-ish
<myles> i think it's helpful to users. it tells them "what kind of
text this image should behave as"
<fantasai> myles, most images aren't used as inline-level content in
effect
<fantasai> myles, most people don't know about line-breaking rules
for languages other than their own
<fantasai> myles, ideographic is extremely cryptic
<jfkthame> in the event we add more values (e.g. like
closing-punctuation, opening-punct, etc) we'll care about
that mapping being clear
<myles> we may want to add "alphabetic" one day, and having it be
`break-all | normal | alphabetic` doesn't make any sense
<fantasai> myles, to the extent that images are mixed just with
other images, they will continue to break
<myles> right, and that's not a bug
<jfkthame> i fear that if we try to do something other than follow
the unicode classes we may paint ourselves into an
awkward corner
<fantasai> myles, to the extent that they're mixed with punctuation,
they should follow kinsoku rules
<fantasai> myles, treating as ID does both of these things
<myles> only if they're supposed to be texty
<fantasai> myles, breaking "([image])" inside the parens is never ok
<myles> disagree
<myles> if the image is a picture of a tree
<myles> then i want it to break on both sides
<fantasai> why????
<TabAtkins> don't break the forest for the trees
<fantasai> that makes no sense
<myles> cause it doesn't look like text
<fantasai> you put it in parens
<fantasai> don't care what it looks like, I can't imagine anyone
wanting that to break
<myles> that is how all browsers behave on all content today. hard
to argue it isn't a sensible default
<fantasai> if you didn't put it in parens, whatever.
<TabAtkins> Yeah, having a ( at the end of a line, then the tree
and ) at the start of the next line, seems like it would
be broke-looking
CSS Text Decor
==============
Scribe: TabAtkins
Clarifying skip-ink:auto behavior in relation to CJK text
---------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4276
<fantasai> https://github.com/w3c/csswg-drafts/pull/4737/files
fantasai: There's a PR from jfkthame about this issue. Looks correct
to me, wanted to check with the WG
astearns: I see myles had a question that was answered in the issue
myles: It looks like an issue to me, not a PR
AmeliaBR: The last part of the edit is an in-spec issue asking for
other non-CJK scripts which want this behavior.
AmeliaBR: Is that something to discuss now, or leave until later?
fantasai: Later. That's a question for impls and i18n
<xfq> +1 to the PR
astearns: So proposed resolution is to accept the PR and close this
issue. Objections?
RESOLVED: Accept PR #4737, close issue #4276
Variants of text-decoration-skip-spaces:end behavior, and initial value
-----------------------------------------------------------------------
github: https://github.com/w3c/csswg-drafts/issues/4653
florian: text-decoration-skip-spaces has a start and end value,
meant to make the browser not underline spaces at the start
and end of the line
florian: Spec is specific about what exactly you're supposed to skip
florian: In the first approximation it's "all the whitespace"
florian: Implemented in Safari and Firefox, which do different from
the spec and each other
florian: In Firefox, it's not only doing (Safari's behavior), it's
only skipping them if they're overflowing, not if they fit
in the line
[Safari skips all preserved U+0020 (but not , or U+3000, or
U+2007) on the end side if white-space is pre-wrap, but not pre
or break-spaces]
[Firefox skips overflowing preserved U+0020 (but not , or
U+3000, or U+2007) on the end side if white-space is pre-wrap,
but not pre or break-spaces]
florian: Possibly they're bugs and need to be fixed, but
double-checking that the spec is indeed what we want, given
the variants.
florian: Also the initial value is different across browsers.
florian: Spec says default is "start end"; Level 3 didn't have this
as a property but specified it in prose.
florian: Chrome behaves as if initial value is "none", Safari/
Firefox behave as their special variants of "end"
florian: So possibly spec is fine and impls are buggy, but if it's
intentionally deviating, we should consider that
myles: Webkit's behavior was implemented before this property
existed, I don't think it should influence this.
astearns: Action here might just be to file bugs
astearns: And have those discussion with implementors
astearns: If need be, we can come back to spec changes after
fantasai: Yeah, reason to file was just to check that, given the
variances, we really wanted the spec behavior.
astearns: Any input from Firefox?
jkew: I don't currently have an opinion.
florian: Okay, so I'll file bugs, assume the spec is good, and we
can circle back if there are complaints.
Received on Friday, 15 May 2020 22:49:04 UTC