Open fantasai opened 4 years ago
@frivoal opened PR https://github.com/w3c/csswg-drafts/pull/4755 for the first option, fwiw.
My preference is 3rd atm.
Also fine with 4th, defer until we hear actual voices wanting it. We already heard some requests to customize line breaking behavior. By deferring, we will have opportunity to design features that can suffice more requests.
I have a slight preference for 2 because these existing properties are already designed to control line breaking around atomic inlines, so they are a natural place to put this functionality.
@litherum Note, the wrap properties control line breaking around any inline, not just atomic inlines.
I don't have good confidence whether wrap-before is the right way to go or not. Defining/disallowing break opportunities at element boundaries is a complex problem.
I prefer to customize line breaking classes of a character (or a meta character that represents atomic inlines in this case) then use UAX#14 rules as is. If that's not good enough, we can consider customizing UAX#14 rules. But I'm hesitating to define behavior at element boundaries.
@jfkthame I think what I described above is the same as what you described in some other issues about line breaking behavior at element boundaries, but I'm not certain if I understood your opinion there. WDYT about this issue?
I started writing a long comment here that I thought was going to be in support of PR #4755, but by the end I found myself thinking that maybe the wrap-*
properties are the right solution. So I guess I'm leaning towards proposal 2.
Could we define additional values for wrap-*
that don't directly force or prohibit a break, but instead override the line-breaking class of the inline? So wrap-before: ideographic
would mean the element behaves as class ID
for the purpose of determining whether a break is allowed before it, etc.
So the initial values wrap-before: auto; wrap-after: auto;
would give the web-compatible legacy "always breakable" behavior for an inline image; wrap-before: ideographic; wrap-after: ideographic;
would give the behavior CSS Text tried to specify as default (without needing any specific line-break
value); and other values could be defined to correspond to other line-breaking classes if there's any demand for them.
(It'd be nice to have a shorthand that sets both wrap-before
and wrap-after
to a single value: img { wrap: ideographic; }
to opt in to the ID
-like behavior. But maybe wrap
is too short and non-specific, given how many assorted line-breaking/wrapping controls we have.)
I'm good with that too if wrap-*
becomes to what @jfkthame suggested. One minor thing though, can it be wrap-before: 'A'
to make it "wrap like the the character 'A'", instead of mapping to the line breaking class? This is easier for ICU line breaker to handle.
Maybe wrap-as
for the shorthand?
I think picking a character to emulate can be an implementation detail; as long as the UA picks a character from the correct category, there's no difference in behavior.
wrap-as
sounds workable to me.
The CSS Working Group just discussed Switch line-breaking handling of atomic inlines
.
RESOLVED: add "wrap-as" and values, details TBD later
The CSS Working Group just discussed Break
.
I'd like to propose the syntax wrap-as: normal | ideographic
where normal
is the initial value.
I'd like to propose the syntax
wrap-as: normal | ideographic
wherenormal
is the initial value.
I like it. How about adding a few more? Not wanting to break before or after might be useful for some types of images.
Also great to define whether the table cell width calculation quirk should be applied or not for values other than normal
.
I don't like it, because ideographic
does not convey the useful things to authors who don't use CJK. We chose to match ID class because it has the right behavior, not because we wanted to match CJK. This kind of naming is helpful to people who implement a line-breaker, not to authors using the property.
Alternate syntax: wrap-as: break-all | letter | word
where 'letter' behaves like AL and 'word' behaves like ID.
'break-all' is the initial value for legacy reasons, and breaks against everything including nbsp. (I would not call the initial value's behavior "normal" except insofar as it's legacy behavior, it does very weird things when mixed with text. Breaking within "IMGnbspIMG" or "(IMG)" is very very weird.)
I'm fine with either break-all
or normal
, but letter
and word
don't work well for scripts that do not use spaces to delimit words. Alphabetic
and ideographic
looks more correct to me. @r12a, do you have suggestions?
As above, I would like to add open
, close
, and exclamation
. Many chat apps use images for Emoji, and exclamation mark images are common. There are ~40 classes in UAX#14, probably all of them are too much, but these 3 are useful.
I don't like it, because ideographic does not convey the useful things to authors who don't use CJK.
We can add emoji
alias if people outside CJK don't seem to understand what ideographic
would behave.
@kojiishi Do you think we need the subtle differences between the CL, CP, and EX classes? Theoretically, I suppose we could come up with use cases for most UAX14 classes (as you could have picture-based representation of mostly anything), but in practice, it seems to me that one type of closing (probably based on CL) is good enough, and it is much simpler for authors to only need to deal with one.
CSS Text tried to define that atomic inlines behave like ID characters with respect to line breaking (e.g., breaks between an atomic inline and a closing parenthesis or comma is forbidden). We had to alter that to allow breaks between atomic inlines and nbsp due to compat. More recently, https://github.com/w3c/csswg-drafts/issues/4576 found that there were sites depending on the "always breakable" behavior of atomic inlines with punctuation as well. This means by default, atomic inlines need to always allow breaks before and after the atomic inline, regardless of what character is there.
The problem is that this is an unnatural line breaking pattern for things like emoticons, gaiji, or other images that are intended to behave like text. We need some way to switch atomic inlines into this mode.
Two proposals were raised on the thread in https://github.com/w3c/csswg-drafts/issues/4576:
line-break
for this purpose: values other thanauto
(the initial value) treat atomic inlines like ID.wrap-before
andwrap-after
properties in CSS Text Level 4 to make this distinction.A third option would be to introduce yet another line-breaking property dedicated to this problem. Fourth option is not to solve. (Personally I do not prefer these solutions as we have way too many line-breaking controls already, and I do think this is a problem worth solving.)
What do we want to do here?