[CSSWG] Minutes and Resolutions Hamburg F2F 2012-05-11 Part IV: Text and Writing Modes

CSS3 Text

   - RESOLVED: Pending Jonathan Kew's okay, keep text-transform:capitalize
               in its current form, with only an informative reference to
   - RESOLVED: Disallow combinations of values in text-transform for this level.
   - RESOLVED: Changing currentColor to resolve at used-time is okay with
               the SVGWG; we're just waiting on Color to be errata'd.
   - RESOLVED: letter-spacing is kept as-is in the draft.  A note should be
               added about using padding to put extra spacing on either side
               of an element, for the use-cases in which that is important.
   - RESOLVED: Remove the 'avoid' value from text-wrap.
   - RESOLVED: Remove the longhands for white-space.
   - RESOLVED: Change overflow-wrap back to word-wrap. Allow CSS Property
               Aliasing (future spec) to define that it aliases to
               overflow-wrap.  Next time Text revs, change the property
               name officially and talk about aliasing.
   - RESOLVED: Drop the full-size-kana value from text-transform in level 3.
   - RESOLVED: Don't change "nowrap" keyword.

Writing Modes

   - RESOLVED: Nobody cares too strongly, so fantasai should decide whether
               to use "isolate bidi-override" or "isolate-override".
   - RESOLVED: no UA dependent values for text-orientation
   - RESOLVED: put our own table of behaviors for mixed-right and upright
               values in the writing-modes spec until UTR50 stabilizes

====== Full minutes below ======

CSS3 Text

   fantasai: A few issues to go over.
   fantasai: First is about justification and half-width characters.
   ISSUE-98: http://www.w3.org/Style/CSS/Tracker/issues/98
   fantasai: I'd like to close this as WONTFIX.
   fantasai: Problem is a grid-style font whose characters are either
             half-width or full-width, and you try to justify by putting
             equal space between every character, the chars will no
             longer line up.
   fantasai: Koji recommended ignoring it, because these fonts are going
             out of style, so it's not important enough to address right
   <fantasai> http://www.w3.org/Style/CSS/Tracker/issues/98
   ACTION vincent to run the "justification of mixed full/half-width chars"
          proposal past Nat. http://www.w3.org/Style/CSS/Tracker/issues/98
   <trackbot> Created ACTION-470

   ISSUE-240: http://www.w3.org/Style/CSS/Tracker/issues/240
   fantasai: Next issue - should text-transform:capitalize apply to letters
             after a hyphen or underscore?
   jdaggett: What's the existing behavior?
   fantasai: Dunno.  The issue was "should we use UAX29 to determine word
   fantasai: I think the current spec doesn't define. It points to UAX29 as
             being useful, but doesn't define explicitly.
   dbaron: I think authors have complained about the inconsistency. I don't
           know if their complaints were consistent in one direction or
   fantasai: There's definitely cases where UAS29 doesn't work well -
             compare "l'enfant" with "don't", two words versus one.
   fantasai: I don't think we have the correct rules yet, but I don't think
             we need to be spending much time on it either right now.
   fantasai: You simply can't rely on it to handle more than the simplest
             cases correctly.
   fantasai: So I propose closing it as WONTFIX, at least right now.
             It's potentially useful, but it's very big, and low-priority
             in my mind.
   florianr: I think that Opera does something suboptimal, and I'd appreciate
             a better ref, but I understand how hard it is, and how there's
             probably just not a good answer today.
   fantasai: A lot of the things that look obviously wrong in Kew's testcase
             that look obviously wrong are already handled in the normative
   fantasai: For example, a lot hinges on the text saying "capitalize the
             first *letter*". So you find the word boundaries, then scan
             for the first *letter*, not necessarily the first character.
   jdaggett: Have you checked with Jonathan Kew that this is satisfactory?
             I'd like to verify that he's fine.
   fantasai: Yeah, I can make sure. I think all of his examples were
             covered by that sentence.
   RESOLVED: Pending Jonathan Kew's okay, keep text-transform:capitalize
             in its current form, with only an informative reference to

   ISSUE-242: http://www.w3.org/Style/CSS/Tracker/issues/242
   fantasai: Next is combinations of values in text-transform.
   fantasai: Previous draft let you combine values that weren't mutually
             exclusive, like "capitalize full-width".
   fantasai: There were several suggestions on the mailing list to not
             allow these combinations.
   fantasai: So I propose we disallow that.  There's not strong use-cases,
             and we can fix it later.
   florianr: For context, I was one against the combining.  I didn't
             dislike combining, I thought the *draft's* way of doing it
             wasn't good enough, and was hostile to later improvement.
   florianr: I have a proposal for a better way, which is part of a
             proposal for the next level.
   RESOLVED: Disallow combinations of values in text-transform for this level.

   ISSUE-244: http://www.w3.org/Style/CSS/Tracker/issues/244
   fantasai: There was an issue about currentColor and inheritance - the
             current behavior doesn't work for properties that inherit.
   fantasai: I think we were waiting for SVGWG approval, which we got, so
             I guess we want errata on CSS3 Color?
   TabAtkins: Chris said he was okay with doing the errata, he's just been
              unable to do it yet.
   RESOLVED: Changing currentColor to resolve at used-time is okay with
             the SVGWG; we're just waiting on Color to be errata'd.

   fantasai: Next is an issue about where exactly you draw the letter-spacing.
   fantasai: So if you say "I want letter-spacing in this element", is there
             spacing on either side of the element?
   fantasai: Current spec says no - the spacing between elements is given
             by the common ancestor.
   fantasai: A thread on the list said it might not be the right behavior
             for emphasis in German and perhaps others.
   fantasai: However, you can always add spacing with padding, while it's
             hard to remove the letter-spacing.
   fantasai: So I propose we close as WONTFIX, and suggest to use padding
             for spacing around the word.
   TabAtkins: I think this is fine - letter-spacing only takes <length>,
              so it's trivial to apply the same <length> in padding right
              next to it.
   [a question from Liam that I didn't catch about the interaction of
   RESOLVED: letter-spacing is kept as-is in the draft.  A note should be
             added about using padding to put extra spacing on either side
             of an element, for the use-cases in which that is important.

   ISSUE-243: http://www.w3.org/Style/CSS/Tracker/issues/243
   fantasai: This is about the effect of graphical effects on text-decoration.
   fantasai: We'd deferred an issue on how visibility applies to text-decoration
             from CSS2.1
   fantasai: I thought about it, and think that if you make an element
             hidden, its decoration should disappear (even if the decoration
             came from the parent).
   fantasai: But what about text-shadow?
   fantasai: It's clear that if *I* create the underline, I should shadow it.
             But what if my parent is underlining me?
   fantasai: And you have other effects - opacity, filters, etc.
   dbaron: Those are both group effects, so they definitely affect the
   fantasai: Okay, so thoughts on this?
   dbaron: I remember thinking about these things when I was fixing up the
           Gecko text-decoration code during 2.1
   dbaron: I thought we had a reasonable answer to this. I'd need to go
           poking around about this to see what it was.
   fantasai: Okay. I don't need an answer immediately, if you need to do
              some research.
   dbaron: There was a related issue with shadows - what color the underline's
           shadow was.
   fantasai: Okay, so no conclusion yet. I just need feedback.
   szilles: Is shadow the only effect?
   dbaron: The only things that should worry about is shadows and visibility.
   dbaron: shadows are the same thing as text-decoration.
   fantasai: Kinda, but shadows inherit normally.
   dbaron: The decoration model is that its' *text* that draws decorations,
           not the element, which is why they're consistent.
   szilles: text-shadow is like what you can do with filters.  We should
            be consistent with shadows and filters.
   fantasai: From the mailing list, Brad has a strong preference for not
             shadowing decorations.
   TabAtkin: And I had a preference for shadowing the decoration.
             Steve's consistency argument favors shadowing it.
   dbaron: Then the question is whether you use the shadow's color or the
           decoration's color.  I think the answer is to use the shadow's
   szilles: And that's consistent with filters too.
   dbaron: Note that opinions can switch if you swap so that the shadow
           is on the parent and the underline is on the child.
   fantasai: no, that just inherits and works as expected.

   fantasai: next issue is text-wrap.
   fantasai: There used to be four values. We dropped one due to lack of
             use cases.
   fantasai: So now there are three values: normal, nowrap, avoid.
   fantasai: The problem here is that the text-wrap property inherits.
   fantasai: So if you have a bunch of nesting, and you set 'avoid' on
             the outer element, you'll get 'avoid' on the children too.
   fantasai: I think this is bad. My proposal is to remove the 'avoid'
             value, and maybe pick it up for something else later.
   fantasai: And then, once avoid is gone, there's nothing you can do
             with these properties that couldn't be done with vanilla
             white-space, so revert to white-space being a non-shorthand
   florianr: I think this is good idea.
   RESOLVED: Remove the 'avoid' value from text-wrap.
   RESOLVED: Remove the longhands from white-space.

   fantasai: Last issue is about ruby.
   fantasai: The layout model for ruby needs a ton of work, and it's
             nowhere near stable.
   fantasai: But there's one property that's simple and clear to apply
             even if you hardcode your ruby markup, and that's ruby-position.
   fantasai: In a similar way how we defined table properties even before
             we defined table layout properly, we can say that ruby-position
             can be applied to ruby, and controls whether it's above or
             below your text.
   fantasai: It doesn't define *any* details about alignment or sizing,
             just its positioning.
   jdaggett: What's the advantage of moving this?
   fantasai: The advantage is that this property's definition is *done* -
             it needs no more work.
   jdaggett: You seem to be looking for a spec to stick this into.
   fantasai: Yes, since epub already is using this, so we should pull it
             into a proper spec.
   szilles: Can we put this into Writing Modes? It seems to make more sense.
   jdaggett: I'm uncomfortable with this controlling ruby when ruby
             layout is undefined.
   dbaron: One of the dangers with Ruby is that we've gotten feedback
           from the Japanese publishers wanting particular behaviors,
           and we're getting close to interop behavior on the *opposite*
           of what they want.
   fantasai: I cant' write the whole ruby spec right now.
   TabAtkins: Don't be afraid of single-property specs.
   fantasai: I could write a Ruby-Position spec and take it to last call
             in two weeks.  ^_^
   szilles: Question, if we decide when we *do* write the proper Ruby
            spec, that this property isn't useful, what will we do?
   fantasai: I can't offer 100% guarantees, but I am quite sure that this
             property will be necessary no matter what.
   TabAtkins: Seconded, based on my own understanding.
   plinss: I agree with you, Steve, in general about trying to spec ahead
           of a good understanding of the model.
   * sylvaing we can always put it in GCPM *cough*
   plinss: But ePub is running ahead and possibly doing something that
           might diverge, so we should control it now.
   jdaggett: So epub has its whole ruby model?
   fantasai: No, this is the only property they use.  The rest of ruby is
             just through markup for them.
   jdaggett: Okay. I just don't like trying to spec ahead of the model.
   plinss: I agree with the sentiment, but is that a strong objection?
   jdaggett: No.
   Liam: The XSL definition for this uses different property names.
   Liam: [lists them]
   fantasai: bopomofo was changed to inter-character to be understandable
             to non-Taiwanese.
   fantasai: We use the line-relative values instead of logical values.
   <Liam> http://www.w3.org/TR/2012/WD-xslfo20-20120117/#ruby-position
   Liam: [describes 'auto' behavior]
   jdaggett: If we're going to change this property, I object to speccing
             it now.
   TabAtkins: I would prefer we don't claim 'auto' ahead of the proper
              layout model.

   fantasai: Okay, moving on. overflow-wrap versus word-wrap.
   florianr: MS invented word-wrap and did it unprefixed.  Everyone else
             implemented it.
   florianr: Not long ago we decided this was a bad idea, and tried to
             change it to overflow-wrap.
   florianr: I've changed my mind about whether it's good to do this.
             I don't think it's a good idea in this instance to change
             it to overflow-wrap.
   plinss: New people are learning CSS everyday and not all of them already
           know this. People in HP get confused regularly.
   hober: Nobody implements the new name? With the same values? Same
          behavior? What are we doing here again?
   TabAtkins: I agree.  It's a bad name, but it's *done*. If we want to
              *alias* it, that's fine, but we should say that's what
              we're doing and explain how to alias in the spec.
   florianr: Agreed. aliasing isn't defined yet, but I have a good model
             for aliasing defined in Opera.
   florianr: But the code review for my "alias word-wrap" patch was
             denied, with them saying I should tell the W3C to not do it.
   dbaron: I think it's potentially harmful to have permanent aliases.
           Gecko currently has none.
   TabAtkins: What are you doing about page-break-* and break-*?
   dbaron: Not implementing break-* yet.  Don't know how we'll deal with
   plinss: Not everyone using CSS already knows CSS.  Gotta think about
           the future as well.
   dbaron: When will authors actually prefer to use overflow-wrap against
   florianr: When you drop prefixes on overflow-wrap.
   plinss: So the arguments against seem to be the same as the arguments
           against any change.
   TabAtkins: Specifically, the arguments are that the benefit is
              sufficiently small that it's not balanced against the
              pain of aliases.
   dbaron: I'll say that I'm okay with this, but think that if we do more
           than 3 rename-for-better-reading per decade, we're doing
           something wrong.
   * sylvaing_airport the bartender and I are cheering for dbaron
   TabAtkins: I suggest we stick with word-wrap, let the Aliasing spec
              define the alias, and then let Text pick up the alias
              next time it's able to rev.
   RESOLVED: Change overflow-wrap back to word-wrap. Allow CSS Property
             Aliasing (future spec) to define that it aliases to
             overflow-wrap.  Next time Text revs, change the property
             name officially and talk about aliasing.
   <sylvaing> resolution exploded my head
   <tabatkins> sylvaing, it's just "do the rename at a point that won't
               slow down Text".
   <sylvaing> i know. but it also says 'we had a name, we changed the
              name, now we're changing it back so we can change it again
   <tabatkins> sylvaing Hah, true.

   jdaggett: We have another important topic.  We've talked about
             text-transform:full-size-kana for a few f2fs, and we keep
             going around and around.
   florianr: Are you okay with doing @text-transform in level 4 if we
             drop full-size-kana from level 3?
   jdaggett: yes.
   RESOLVED: Drop the full-size-kana value from text-transform in level 3.

   ISSUE-246: http://www.w3.org/Style/CSS/Tracker/issues/246
   fantasai: One more issue.  white-space:nowrap has the least consistent
             hyphenation in all of CSS.
   fantasai: Flexbox also has a nowrap value.  These *must* be consistent.
   fantasai: So Alex and I were going to just make them both "nowrap".
   fantasai: But Tab wants to make them both 'no-wrap'.
   dbaron: There's the problem of authors 3 years in the future trying to
           remember which is the one that also works in old browsers.
   TabAtkins: The good one will be the new one, and the shitty one will
              be the interoperable one.
   [seems to be consensus to not change it]
   RESOLVED: Don't change "nowrap".
   <Bert> ('nowrap' is certainly the keyword I can never remember: is it
           prewrap vs no-wrap or vice-versa?)
   TabAtkins: Maybe I can just change "nowrap" in flexbox to "single" like
              the old flexbox draft.
   TabAtkins: I'm renaming everything anyway. By the time I'm done this
              will be called the Ruby layout draft.

   ISSUE-220: http://www.w3.org/Style/CSS/Tracker/issues/220
   fantasai: Another issue.  What do you do with ideo spaces and fixed-width
             spaces at the end of a line? Do they disappear or stay? How do
             they line-break?
   TabAtkins: Those aren't collapsed as part of whitespace collapsing?
   fantasai: No. And the question is what to do at the end of the line.
   kojiishi: Feedback from Japan is that people liked FF/IE behavior.
   kojiishi: Some liked the details of FF or IE better, but everyone
             thought that they were both acceptable, and better than
             the other browsers.
   plinss: We're out of time now, unfortunately.
   kojiishi: There's a mailing-list post in this.  We can decide on this
   fantasai: Does either option make the Chinese happy?
   kojiishi: I think so.
   szilles: Feedback from Eric was that he didn't make that decision.
   szilles: This *might* imply that the behavior is language-specific.
   szilles: He was clear that UAX14 was right.
   [disagreement on whether UAX14 says that linebreaks are possible between
    spaces, and what it allows between characters]
   <fantasai> it allows breaks between fixed-width spaces, just not U+0020
   <fantasai> and ideographic space is indeed handled as ideographic character
   plinss: Resolutions?
   [no resolution - koji will propose something soon]

Writing Modes

   ISSUE-200: http://www.w3.org/Style/CSS/Tracker/issues/200
   fantasai: Currently only isolate and bidi-override are usable in combination.
             Someone suggested that they aren't useful except in concert,
             so we should combine them.
   glenn: Previous these values were isomorphic to the unicode control
   fantasai: They will be again - unicode agreed to add isolation characters.
             We're just ahead of them.
   fantasai: Previous we allowed "isolate" in combo with "plaintext",
             but it turns out we don't need the ability to turn isolate
             on/off with plaintext, it should just always be on.
   dbaron: Every time I look at this, I get confused.  That's not a good sign.
   [discussion about their behavior]
   fantasai: To be consistent, 2.1 should have had "normal | embed | embed-override".
   [stop talking about the behavior]
   TabAtkins: So it seems the current and proposed behavior are functionally
              equivalent.  The *only* thing is that you'll have
              "isolate-override" instead of "isolate bidi-override".
   dbaron: yes.
   fantasai: [explains the values with a chart, to illustrate the axises]

                        strong      |     neutral
             embed |    'embed'     |     'isolate'      |
   INSIDE   -------+----------------+--------------------+
          override |'bidi-override' | 'isolate+override' | <-- subject of issue
                   +--------------- +--------------------+
                                    |     'plaintext'    |

   szilles: When answering questions like this, I think we should ask what's
            most useful for the authors.
   fantasai: I think it's easiest to author with them combining.
   RESOLVED: Nobody cares too strongly, so fantasai should decide whether
             to use "isolate bidi-override" or "isolate-override" herself.

   kojiishi: Another issue - I think we should add an auto value to
   kojiishi: UTR50 is taking longer than expected - I think another
             6 months or more.
   kojiishi: Right now we're in trouble because the behavior isn't defined,
             but content is depending on some behavior.
   jdaggett: I don't see the value of having a new value without a definition.
   TabAtkins: We don't usually make 'auto' mean "whatever", it means
              "magic that CSS doesn't control, but which is well-defined".
   fantasai: I'm not sure adding auto would actually help us here.
   kojiishi: If we leave it as it is, the world will be UA-dependent anyway.
   TabAtkins: Do we expect impls to actually follow the explicit keyword
              if we add this auto?
   fantasai: I'm not sure the value is there.  If people are authoring to
             webkit's ipmlementation, they'll expect webkit's implementation.
   fantasai: Nothing we do with keywords is going to change that.
Scribe: Shane
   fantasai: If WebKit doesn't implement sideways values you can't do
             explicit orientation control
   koji: Japanese vendors of epub readers are using WebKit and writing
         patches to implement sideways. But having trouble upstreaming to
   jdaggett: so you're relying on the values working the way they are
             intended to. In webKit they don't.
   jdaggett: if I say upright, I don't always, based on code point and
             font and other stuff
   koji: upright works for asian users
   jdaggett produces a counterexample
   <hober> the bug that jdaggett is talking about:
   koji: I'm talking about major asian use cases
   koji: as long as you don't use mixed complex path, it just works
   TabAtkins: This is going to be completely polluted anyway, probably
              need to make a new property in a few years
   jdaggett: epub is standardizing on a property that is undefined
   discussion about whether this is about ebooks or the web
   TabAtkins: because UTR50 isn't out yet people are just implementing
              stuff they think is reasonable
   TabAtkins: so if you can't wait for utr50, define something and we'll
              fix it later
   TabAtkins: write down a reasonable way of doing thing
   kojiishi: problem is that defining behavior for arabic etc. is not easy
   fantasai: that's fine, just define the bits you need
   TabAtkins: just give arabic some value, doesn't matter what
   TabAtkins: can provide use-good-arabic-vertical-text later
   fantasai: or just swap it in if it's close enough
   fantasai: I'll take an action with koji to do that
   jdaggett: I don't get why we can't just wait for utr50
   TabAtkins: because of pollution
   jdaggett: how is that different to what happens elsewhere?
   TabAtkins: they're not even trying to be similar
   jdaggett: putting in stuff we remove later is busywork
   TabAtkins: if we leave it then we'll just need to tear the property
              down because it'll be too inoperable
   jdaggett: I've proposed in the past an @-rule to do this
   kojiishi: I've been saying to make this UA-dependent because that's
             been happening for 30 years.
   TabAtkins: jdaggett proposes an extension mechanism so stuff can be
              defined in the future
   Tabatkins I want to propose something simple so we have a chance at
             keeping the keywords
   florian: what's the chance of being able to keep them?
   TabAtkins: non-zero
   florianr: do you expect implementations do drop their heuristics and
             adopt your simplified ones?
   TabAtkins: yes, I would hope that happens
   florianr: and worst case is we waste a bit of time drafting the
             simplified heuristics
   fantasai: even then our tables will end up being input to the UAX50
   jdaggett: I think the UAs will keep doing what they are doing despite
             what the WG does. Our best hope is for clarity - i.e.
             "just wait until utr50 is ready"
   jdaggett: if we give them an interim thing then they'll complain when
             the real standard comes out
   fantasai: the no change situation is that everyone will assume the
             WebKit behavior is the standard
   jdaggett: there is no standard. Things keep changing from version to
             version of browser.
   kojiishi: we can't file bugs with out something in the spec
   hober: we can file bugs now - I filed one recently about unexpected
   stevez: that just makes the problem worse because people will think
           that WebKit is the standard
   TabAtkins: so the alternatives are: 0% chance of working, will have
              to burn down the prefixes, vs. people might get upset with
              multiple updates
   jdaggett: If koji and fantasai take the tables and put them in the spec,
             I don't object. I just don't think it will solve anything
   florianr: do you think it can hurt anything?
   jdaggett: if vendors end up looking at it as a solution, it isn't,
             because there's no consistency between different implementations
             or versions of the same implementations.
   jdaggett: but I do not think we should be adding values at all
   fantasai: I agree with that
   RESOLVED: no UA dependent values for text-orientation, and we'll put
             our own table of behaviors for mixed-right and upright values
             in the writing-modes spec

Received on Wednesday, 16 May 2012 02:54:00 UTC