W3C home > Mailing lists > Public > www-style@w3.org > May 2020

[CSSWG] Minutes Virtual F2F 2020-05-06 Part III: CSS Text, CSS Text Decor [css-text] [css-text-decor]

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 15 May 2020 18:48:18 -0400
Message-ID: <CADhPm3u_WEEFO0K9E2AbTAfcyZNOhh4NoFEoWkrh7VecqzHz6g@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 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).


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
  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
  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
  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
  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
  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>&#0a;</span> b</p>
  faceless2: We had one use case where this didn't apply to an atomic
  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 ^_^


  <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
  <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 &nbsp;, 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 &nbsp;, 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

This archive was generated by hypermail 2.4.0 : Monday, 23 January 2023 02:15:14 UTC