W3C home > Mailing lists > Public > www-style@w3.org > June 2014

[CSSWG] Minutes Seoul F2F 2014-05-21 Part III: CSS3 Text

From: Dael Jackson <daelcss@gmail.com>
Date: Fri, 13 Jun 2014 10:19:40 -0400
Message-ID: <CADhPm3sUGzdAt=LB0j8Rx3gz7svcaYfKiiadsdeJ0NXNowMwxg@mail.gmail.com>
To: www-style@w3.org
CSS 3 Text

  - RESOLVED: text-align is shorthand for text-align-last and
  - RESOLVED: Defer text-align-first and text-align: start-end
       to level 4
  - The wasn't any solution of a new name for grapheme clusters
       (currently called characters). The editors will come up
       with something until someone comes up with something better.
  - RESOLVED: Require which lines are justified even if the
       justification method is not defined
  - Arabic letters connecting between elements with display: inline
       will continue on the mailing list
  - Issue 72 about control characters will be tested a bit more, but
       likely will result in no change.
  - RESOLVED: No further splits to CSS3 Text
      Though this is a process that's been done before with other
      specs (including this one), it was felt that the most
      interesting to implement pieces of CSS3 Text were all in the
      unstable list. Given that and the fact that there is no clear
      logical division of properties either, it shouldn't be split.


Agenda: http://wiki.csswg.org/planning/seoul-2014#agenda
Scribe: dael

CSS 3 Text

  glazou: Let's start even if Bert isn't here.
  glazou: First is CSS 3 Text
  glazou: And we have 5 sub items. First is text-align shorthanding.

Relationship of text-align and text-align-last

  fantasai: We discussed this at Paris F2F
  fantasai: We currently have a text-align property and we have a
            text-align-last property.
  fantasai: They're currently independent and we think that we can
            make text-align-last a longhand for text-align.

  clilley: With making it take an optional 2nd value?
  fantasai: That's one possibility.
  fantasai: In most cases, people want text-align-last as either
            auto or justify; the latter means justify the last
            line because it's not by default.
  dauwhe: We call this forced justification in my work.

  fantasai: In Japanese people will set text-align: justify,
            text-justify: distribute and text-align-last: justify.
  fantasai: We eliminated that last step by special-casing 'auto'
            to make it easier.

  fantasai: We were going to tie text-align-last to have it apply
            only if justification is happening.
  clilley: So you mean that you can set text-align-last to justify
           and only the last line will justify?
  fantasai: Yeah.

  fantasai: The proposal on the table was to have text-align as
            a shorthand of text-align-last and text-align-all,
            which would take the other values.
  fantasai: We also have cases where people would want the
            ::first-line aligned for poetry or something.
  fantasai: Currently we have an issue noted in the spec where we
            need a name for that and we'll drop it if we can't find
            a name.

  TabAtkins: Can you apply text-align to the ::first-line?
  fantasai: I don't know. I think you could.
  TabAtkins: They don't cascade together.
  fantasai: The cascading is a bit of a problem.
  fantasai: I think it is.

  fantasai: Do we want to switch text-align to a shorthand and
            potentially add text-align-first?

  dbaron: I think you had explained a case where the first and last
          lines should work differently in cascade terms?
  fantasai: When you set first different from all you want to make
            sure that you're resetting all the alignment in the next
  fantasai: The question was, do we want text-align as a shorthand?
  fantasai: Should/would that obliterate a previous text-align-align?
  dbaron: I think it is where -last applies to anything before
          a break.

  dauwhe: That's something that's tripped me on text-align-last,
          that it applies after a forced line break.
  dbaron: I remember there's something not symmetric and you
          convinced me they should cascade separately.
  <SteveZ> As I recall, "text-align-last" applies to paragraphs that
           have only one line

  glazou: Can we use text-align on the first and last line pseudo?
  fantasai: It won't cascade correctly. If later in the cascade you
            want things to center, your 'text-align' declaration
            won't work because the pseudo is more specific.
  fantasai: That's a problem that shows up in various situations
            since the cascade on an element doesn't reset things
            that are set on a pseudo.
  TabAtkins: I wouldn't call that killer, but it's a down side.
  TabAtkins: Bold-ing the first line differently happens quite a bit.
             We use ::first-line for a lot of things that fall into
             a similar bucket and we're okay with making those not
  dbaron: I think text-align-last wouldn't work with a ::last-line

  dauwhe: I wish it was the last line. It would solve a lot of my
  dbaron: You want the opposite too.
  fantasai: You want a property for both things? No one has brought
            that up before.
  dauwhe: I can work up examples, but we run into problems where
          we're trying to force a line break. In inDesign there's a
          lot of ways to do a line break and you can't do that in
          CSS because it'll force justify the last line even if it
          only has two characters
  fantasai: Okay.
  * liam notes that cascading is generally less important for people
         generating print from their own content (!) or for epub

  fantasai: I think I need to work on reloading the previous
            discussions into my brain. Unless there's something else
            to point out, I'll do that as we discuss other things.

  * liam compares http://www.w3.org/TR/2012/WD-xslfo20-20120117/#text-align-last
  liam: We added a bunch of stuff for XSL-FO for this. We have a
        bunch more values there and I'd have to look at how they
  <liam> [xsl-fo text-align-last has relative | start | center |
         end | justify | inside | outside | left | right | inherit ]
  <liam> http://www.w3.org/TR/2012/WD-xslfo20-20120117/#text-align-last
  glazou: Okay.

  <fantasai> http://lists.w3.org/Archives/Public/www-style/2013Aug/0391.html
  fantasai: Most recent proposal was text-align and a shorthand for
            -all and -last where they take the same values except
            -last takes auto.
  fantasai: The text-align shorthand takes one or two keywords,
            second one setting text-align-last. Alternately a
            justify-all keyword. So you can set to justify: justify
            but it reads better.
  fantasai: So in most cases, the authors only need one keyword.
  fantasai: I guess we should go to the next issue while I find old
            minutes where we discussed this.
  dbaron: I could be mis-remembering.
  fantasai: It was something about when you set text-align-last and
            you set the rest of it, if you want the rest of it
  fantasai: If you only have one line it'll be text-align-first
            takes priority, followed by -last, followed by -therest

  SteveZ: I don't understand how -first takes priority because it
          would be wrong for Western.
  fantasai: If it's not justify.
  SteveZ: Is that why text-align-last took priority?
  fantasai: I think -first takes auto or start because there's no
            use case for another value.
  SteveZ: What's auto mean?
  fantasai: Do same as text-align-all.
  SteveZ: There's 4 components? -all, -first, -last and...?
  fantasai: And the shorthand text-align.
  SteveZ: I still think -first doesn't work because -all will want
          to be, in Western you want all but the last line justified.
  fantasai: You leave first as auto.
  SteveZ: But if it's priory it's justify.
  dbaron: Auto says nothing special for the first, keep going.
  SteveZ: But you have to decide if the first is justified.
  fantasai: I see what you're saying. Start takes priority but
            auto doesn't.
  TabAtkins: It's same as start-self.
  astearns: But in Western you want to take the text-align-last
            value if there's only one line.

  fantasai: dauwhe's problem that he brought about having a
            different behavior from last line vs after a forced
            break. It means we'd need another property.
  fantasai: And if we add that is text-align-last actually the last
            line, or after breaks.
  koji: Is there a use case?
  dauwhe: The use-case is tied into details of hyphenations and
          justification of text, but we get requests to alter it
          a lot.
  dauwhe: If that happens outside the parameters, you do a soft
          return and than that line is justified. That's desirable
          for us.
  dauwhe: We don't want to force that just to the last line usually.
  dbaron: So we need a mechanism for that. For saying a break should
          be treated as a non-forced.
  <liam> +1
  dauwhe: Yeah.
  fantasai: That makes more sense.
  dauwhe: I know it's an oddball use case.
  <SteveZ> I agree that a soft break should not be treated as a
           hard break

  astearns: I think it comes up where people try and use a break and
            are confused that it's a paragraph break when they want
            a soft break.
  koji: So is the break feeling alright?
  dauwhe: It feels like a different break character.
  glenn: Is there a unicode that has that semantic?
  fantasai: There's a bidi soft break that we don't want to get into here.
  dbaron: I'm of the opinion that if we can't remember why to
          separate, we should combine.

  <dbaron> I found
  fantasai: Minutes from last F2F, we were ambivalent, then we heard
            from digipub and they said it would be better to go
            short-hand long-hand
  <dbaron> fantasai is quoting from Minutes 2013-11-12 Tues IV

  plinss: Unicode does have a line separated vs paragraph separator.
  fantasai: I think that's the bidi(?) one.
  fantasai: It's similar to soft break.
  dbaron: If we agree we want that use case to be from a soft-break,
          we don't need to do that now.
  fantasai: So let's agree it'll be solved by a soft-break mechanism.

  koji: There's two issues in text-align I understand.
  fantasai: I can defer text-align-first to the next level. We don't
            have a good way to express it in the shorthand.
  fantasai: I think we need text-align-all and -last with text-align
            as the shorthand.
  fantasai: I think that's what we want to do. We should make that
            change and then go back to soft-break.
  dbaron: So text-align is a shorthand and takes one or two values?
  fantasai: Or the shorthand justify-all.
  SteveZ: So how do I get western layout to align all but the
          last line?
  fantasai: text-align: justify

  fantasai: Any other comments?

  RESOLVED: text-align is shorthand for text-align-last and

  SteveZ: My understanding of French poetry is the first line is
          left-aligned and the rest is right-aligned
  fantasai: We're defering that to 4
  SteveZ: What I'm curious is if I say text-align: right and then
          say text-align: na and text-align: start that will work.
  [this question seems to be mis-minuted]
  fantasai: Yes.

  dbaron: But that's what's deferred to level 4?
  [discussing case of text-align: right; text-align-first: left; ]
  fantasai: Part of the reason is that's fine in general if the
            browser supports text-align-first, but if it doesn't,
            your text is all right aligned and that's not the
            fallback you want.
  fantasai: We want a way to express first-line alignment in the
            shorthand so that the declaration that makes the other
            lines go right gets thrown out by older browsers.
  fantasai: That gives us a migration forward. No one has come up
            with a good way to express this in the shorthand. We've
            asked for keywords and no one has come up with one.
  fantasai: Unless there's a keyword, we're going to drop it.
  dbaron: It could be a / to separate the first and the all/last.
  fantasai: Maybe... but would still not be super-clear.
  dbaron: I'm fine dropping it.

  RESOLVED: Defer text-align-first and text-align: start-end
            to level 4

  <fantasai> We are in need of an understandable keyword for
             start-end behavior

Forced Soft Breaks and Alignment/Justification

  fantasai: And we have to go back to the soft break.
  fantasai: Current spec says that text-align-last takes affect
            after every force break. If we want to say except line
            separators we can.
  fantasai: Line separator is intended to be a soft break because it
            doesn't break the bidi paragraph.

  dauwhe: I found a unicode where line separator correspond to
          HTML <br>
  clilley: But understanding of break is often wrong.
  fantasai: We did a compatibility check and found that <br> is a
            actually paragraph separator. The Unicode spec example
            is wrong.

  dauwhe: Can we apply a property to break itself?
  plinss: Didn't we define break as replaced content?
  fantasai: My one concern is you have a bidi embedded quote...
            if you're doing a hard break it's a semantic break.
  fantasai: If you have a multi-line quote in poetry and you might
            have an embedding and you don't want to break the
            embedding on the line breaks.
  dauwhe: I'll send out what I've been testing for this
          unicode character.
  fantasai: I'm not sure a line-separator is a good option for this
            use case.
  fantasai: I'm not sure it's not either.

  koji: Since most of these cases are for a single line, can we
        consider changing this to be last-line? The point I'm not
        sure is if we need the options.
  koji: I'm not sure if it wants to consider <br> as a line.
  dauwhe: So you might be okay with text-align-last not applying
          before first line breaks?
  koji: From major use cases, I'm fine.
  fantasai: In Japan if you're justifying the very last line,
            if you happen to have more text you also want to justify
            all those.
  fantasai: You'll find use cases where you want to justify all but
            the last line, but not only the lines that are after a
            forced break which isn't the last line.
  fantasai: So having it apply to all is right, though you might
            want something to restrict and not apply to the
            last line.
  dauwhe: I feel I need to mull this over.
  fantasai: We can leave that there. We need another WD cycle anyway.

Grapheme Cluster Terminology

  plinss: Grapheme cluster terminology.
  fantasai: So we've aliased the term character to grapheme cluster
            so we can just say character.
  clilley: And this has a lot of problems where people think that
           character means different things.
  clilley: Logically you can say right is left, but it's still
  fantasai: Character has a lot of meanings and we picked
            one definition. We're not using a word that has
            a *different* meaning than the one we're using,
            we've just narrowed it to one of its definitions.
  fantasai: This gets word. i18n said people will be confused and
            you should use the right term.

  fantasai: Anyway, having heard from James Clark about Thai letter
            spacing vs line breaking, we have to conclude there's
            actually two things we're talking about.
  fantasai: One is the grapheme cluster in regards to spacing and
            one is wrt line breaking.
  clilley: And which is unicode?
  fantasai: Neither.
  fantasai: Unicode is trying to solve both problems, but targeting
            mainly line breaking.
  fantasai: But in order to do correct line breaking, you'll sometimes
            have to extend the meaning of grapheme cluster.
  fantasai: Unicode allows for tailoring for this case. They are
            aiming at the line breaking unit and they define what
            they have mostly there.
  fantasai: But then we have spacing where in some cases it's larger
            than the default grapheme cluster but in Thai it's smaller.
  fantasai: And some of those cases have to decompose characters to
            space the cluster correctly.

  fantasai: So now we don't want character or grapheme cluster.
  fantasai: So. Does anyone have suggestions?
  TabAtkins: At this point we're in the foo/bar territory
  dauwhe: Does first-letter make this more complicated?
  fantasai: No, I think it mostly uses line breaking definition.
  koji: We could go with line-break point as grapheme cluster and
        define spacing as something.
  clilley: You could define a new term so they have to look it up.
  clilley: Letter Spacing Break Opportunity is LSBO

  fantasai: So. Unless there are further suggestions we can move on.
  SteveZ: One comment. It seems to me the grouping is more important
          than the breaking aspect.
  SteveZ: So I didn't like letter spacing break opportunity and
          preferred talking of the nature of groups.
  fantasai: Break opportunity is a break between these "things" and
            we need a name for the "things"
  fantasai: You could define the behavior in terms of breakpoints,
            but if you're reading this definition to understand what
            the property is for, I wanted to have one understandable
            sentence of what this property does.
  SteveZ: How about unitary characters?

  koji: You mentioned using HTML's definition?
  fantasai: It's completely different. It's not a grapheme cluster.
  TabAtkins: It's codepoint or scaler value. One or the other.
  zcorpan: It's both in HTML. It's scaler if it can be, else wise
           it's codepoint.
  TabAtkins: Scaler value is a subset of codepoint that excluded the
             lone surrogate.
  TabAtkins: It's not relevant since I'm not talking about codepoints.
  zcorpan: HTML is complicated because it wants scalers and codepoints

  <fantasai> visually-perceived character and semantically-perceived
  <fantasai> (Unicode calls Grapheme clusters "user-perceived
 * liam not sure that's appropriate for e.g. Hindi

  dbaron: So how about creating the term "CSS character"?
  hober: CSS character would be confusing with the ch.
  fantasai: I think it's a problem with parsing.
  TabAtkins: I changed Syntax from character to codepoint.

  clilley: The reason there was a link to the word character, is
           that he thought that he would use an existing definition.
  fantasai: He picked a different definition and didn't realize that.
  fantasai: Anyways. I'm gonna put up a chart on the whiteboard and
            over the next break you can add suggestions.
  koji: No opposition to CSS characters?
  fantasai: There isn't a dominant one, really. We need two terms.

  <zcorpan> http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#unicode-code-point
            was what I was thinking about. Not called
            "character" though.
  <zcorpan> actually it is "character"

text-justify: auto

  <liam> [text-justify - at one point I'd proposed (and the wg
         accepted) a property to let the user ask for a named
         justification/line-breaking] algorithm

  fantasai: What's next?

  plinss: Defining text-justify: auto
  <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013

  fantasai: The issue was...(link above)
  fantasai: I believe this is text-justify: auto being more
            international one.

  koji: Issue 57 where there was feedback that we accepted
  <fantasai> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-57
  fantasai: The i18n group wanted us to be more explicit about the UA
            doing the right thing in all cases
  fantasai: Current state of implementations is that if you don't spec
            a language tag on your text it uses western justification.
  fantasai: This is a problem for CJK texts because there's no spaces.
  fantasai: Furthermore, we dropped text-justify: inter-ideographic
            in favor of auto.
  fantasai: But there's pages out there that use inter-ideographic
            assuming it's going to work for CJK.

  fantasai: We said where UA if possible should use the appropriate
            spacing for the text, but we added a better example.
  fantasai: [reads example 10 text]
  fantasai: That will cause CJK pages that set text-align: justify
            to start justifying, which I hope wouldn't break anything
  fantasai: We go further saying, if you know the content language
            you can be more sophisticated.

  clilley: I like that it includes English as a more specific thing.
           Can you remind me of the letter definition?
  fantasai: So it's a grapheme cluster where the base character is
            from the L or N general categories in Unicode.
  fantasai: It's not spaces, not punctuation, not whatever the M
            category was.
  fantasai: I want to go over this with implementors to see if it's
            okay or if they want more explicit text, or if they
            won't justify CJK without a language tag...
  clilley: This appears to only be for unrecognized languages. So
           this allows them to do this for any language. So this
           issue is only about special languages where you don't
           have something for it.
  fantasai: We want UA to justify with CJK spacing by default.
  clilley: And that's testable and I like that.
  fantasai: So I wanted to hear from implementors what they think.

  SteveZ: What happens for languages like Arabic which don't put
  fantasai: Arabic expands spaces. For Thai if there's a space
            expand that space and if there isn't one to expand
            you would expand between clusters.
  fantasai: This requires a 2-level justification algorithm.
  clilley: So that algorithm is wrong for Thai?
  fantasai: Thai spaces between grapheme clusters.
  fantasai: (clarifies) Word separators in CSS3 Text are actual
            characters, not implied word boundaries.
  SteveZ: So it's letter spacing.

  dbaron: This is when there's no language tag. So it would be
          useful to have more clear requirements here.
  dbaron: I think the current text assumes the implementor knows
          more about world languages than the spec author and that's
          not usually the case.
  dbaron: It won't be wide knowledge.

  dwim: I did text-justify in Blink and I can do English and Korean,
        but I don't know Arabic and what they prefer. More specific
        cases are needed.
  fantasai: If you implement primarily expanding word separators
            along with secondary expanding between SEA/CJK clusters,
            you get there. But if we have an implementor that has
            better knowledge I want them to be able to do better.

  clilley: So could choose what needs to be changed. This is the
           minimal version. So a test with a nonsense language is
           what's needed.
  dbaron: So it's also useful to say when there's a language
  fantasai: It's here.
  dbaron: That's not much.
  dbaron: I think the spec is unclear enough that it'll be ignored.
          So if you want it not ignored you should specify more.
  clilley: You remove the part that says example 10 and you make it
           non-normative. People with good knowledge of second
           languages, you let them do that with your second sentence.
  fantasai: We want the UA to use a universal compromise, but it can
            be more specific.
  clilley: So make it normative by saying this is the minimal
           required. Say from onwards this is the baseline.
  koji: But then what's minimal? Can you swap secondary and primary?
  zcorpan: You can also say if you have better, give me feedback?
  glenn: I like it as is.

  <fantasai> dbaron, maybe adding "and should, at minimum,
             adequately handle both Western and non-Western scripts
             by default" ?

  zcorpan: Is there a problem with spacing between all characters?
  fantasai: Yes. If you have a mix of CJK and Latin on the line, you
            want to space between the CJK characters and not the
            Latin; you could space between the Latin as a tertiary
  liam: There's a problem in German. Letter spacing is used for
  liam: A year ago I had an action item, I had sent a proposal to
        let the author to name which algorithm they want for line
        breaking and that was for CSS 4 text.
  liam: I hadn't realized I had that action, I'll rewrite the
        proposal for advanced line-breaking and some of this could
        be referred to such a property.
  <liam> [ proposal from last March -
http://lists.w3.org/Archives/Public/www-style/2013Mar/0183.html ]

  clilley: It could be useful.
  liam: Maybe you weren't on the call, but the goal was, when you do
        a better line-breaking a lot of the research has been for
        print and it goes wrong for screen.
  liam: If you use the line-breaking algorithm and you edit the
        text, you insert your pointer and type, but the dynamic
        justification can makeyour pointer move up and down by
        a few lines.
  liam: That's not acceptable.
  liam: I was going to let you say that you plan to edit this and do
        that shortly before you start the editing. That would tell
        the user agent you accept the text as is and don't refine
        line-breaking. For print you can optimize with just a
        few lines.
  liam: Than you get something that's slightly better. Being able to
        say what's an end is useful for several languages.

  fantasai: Any further comments on this?
  koji: This is a compromise that's suboptimal for CJK so IE
        will have some justification issues for quality.
  koji: You have something optimal for CJK and now we're removed it.
        If language isn't specified it's suboptimal for CJK.
  fantasai: CJK is secondary anyway because if you have a line with
            a space you just the space. JLREQ says that already.
  fantasai: I think it compresses instead of expands, though.
  koji: Compressing is okay. Expanding... Anyway.
  koji: Since we're talking line breaking changes anyway.

  <dauwhe> high-end typesetters often have rules that you can only
           reduce letter- and word-spacing to justify text, never
           increase space.

  fantasai: dbaron did you see the IRC text?
  dbaron: It's so far from what an implementors would write. This
          spec is saying do a pile of research.
  clilley: If you want.
  fantasai: I had more specifics and people said they don't want
            more specifics.
  clilley: I was pushing for more specific.
  fantasai: I can't please both directions.
  SteveZ: The main comment I wanted to make is whatever you write
          should be testable and some things I heard didn't sound
  fantasai: Auto is to "do the right thing" and we don't say what
            that is.
  SteveZ: Which makes it hard to test and get interoperability.
  fantasai: Then I'll need 6 years research to spec the right thing
            plus a research budget.
  fantasai: I can't give you the algorithm.
  dbaron: So how should implementors do it?
  Rossen: So why is it in the spec?
  fantasai: Because we need to say a baseline of how to justify.
  fantasai: I don't have the answers and I've been doing this for 10
            years. If you want a correct algorithm appropriate for
            everyone to implement, I don't have it.
  fantasai: I don't have any actionable requests here.
  fantasai: I can answer specific questions, but if you want a step
            by step algorithm, I can't do that.

  SteveZ: I thought I heard two things useful.
  SteveZ: First was clilley's point that we need a nonsense language
          to test and second was that we need an algorithm that
          processes that nonsense language which I thought was to
          prioritize existing spaces or use letter spacing.
  SteveZ: That's testable.
  SteveZ: Outside the nonsense language you can't test because
          people may have heuristics that let them do a better job.
  fantasai: There's simple cases where we can say you should get
            this result.
  fantasai: But we can't say here's the algorithm you must use.
  fantasai: So we can say here's a paragraph of Latin words with
            spaces and we can test if it's been handled correctly.
            And than do 5 CJK characters in a 6em box and then Thai
            and then etc. We can't test script mixing because people
            will want to have different priorities.
  fantasai: So we can test, but we can't spec more than a few
            outputs on a test case.
  fantasai: I can say you should have these outputs, but nothing
            more specific.

  <dbaron> https://www.rfc-editor.org/rfc/rfc6919.txt has
           "SHOULD CONSIDER" which seems to match this case
  dbaron: This sounds hard to justify spending time on because we'll
          write some code, someone will tell us it's wrong, we have
          to re-write and on and on and we may as well stick with
          the Western behavior
  clilley: That seems worse. Unless you're language is well known
           you get English justification.
  TabAtkins: If you're not well known you have to be a special case.
  clilley: Well the prose is something where here's a good way for
           spacing in general and if there's special cases you can
           do that better.
  * liam wonders if it'd be better to have a set of justification-in-
         language-X documents?

  fantasai: What are you asking me to do dbaron ?
  dbaron: I'm curious what other implementors think they'll do. I'd
          rather have an algorithm in the spec that's better than
          what we have and we can move toward and have something
          where if people say they think we can do better in their
          language, tell them they should get it in the spec.
  clilley: Yeah. So people will come with different opinions and
           this can get consensus of how things can be.
  plinss: This is sounding like counter-styles.

  zcorpan: An algorithm in the spec that we know is wrong and can
           get feedback and improve is more likely to get
  zcorpan: You can put in a bit note saying it's probably wrong.
  clilley: It's probably sub-optimal.
  SteveZ: The Japanese layout requirements taskforce is the best
          group out there to capture what you need and even they
          recognize that it's all house styles. Don't assume there's
          a right way.

  dauwhe: We devote our lives to carefully justifying text. But we
          do a lot of hand tweaking for results and it's so
          immensely complicated and we're frustrated we have so
          little control over it.
  dbaron: I think browsers have different interoperability than
          formatters. We care more about interop.
  dbaron: I don't consider it worth investing in something like this
          if it's complicated and won't lead to browser interop. I'm
          curious what others think.
  Rossen: I think your last sentence summarizes well. We won't put
          in much effort without an interop result.
  hober: If we spec something that's simpler to being worse in
         common cases, sure we could converge, but we don't want to
         if it's worse.
  fantasai: I don't think we're proposing you do worse. We're
            proposing we do better in non-English
  fantasai: I don't think interoperability of justification is the
            goal. We want the text to justify and look good, but
            exactly what it looks like we shouldn't obsess over.
            That'll vary and that's okay.

  dauwhe: I have no expectations that every word will maintain
          across browsers.
  fantasai: That's true just from different font libraries.
  dauwhe: If a font version changes it breaks justification. The
          smallest length can make large changes.
  plinss: There is an expectation that if I only change the browser,
          I should get the same thing
  dauwhe: That doesn't happen today.
  plinss: People want that.
  dauwhe: And this isn't text-align: justify, but other values
          of text-align.

  dbaron: If we start doing something that we think is better,
          someone will think it's worse and be furious and it's
          easier to point to a spec with some research than to say
          we thought this was better because we talked to the guy
          over here.
  fantasai: We want interop on if a line of text has been justified
            or not. Where space is inserted/removed is less important.
  fantasai: Right now if you have CJK and you ask to justify, it is
  fantasai: That's how deep the spec should get.
  dbaron: Then the spec should require that.
  dbaron: If that's what you want to solve it should be must level.
  fantasai: As far as an algorithm, I can do a non-normative
            appendix, but I don't want people that have a better
            idea or different performance be locked into a browser-
            required algorithm.
  Rossen: That's fair.
  dauwhe: Plus that might take another 5 years for the algorithm.

  plinss: Thinking back to counter styles, you mentioned that
          justification style is a house style so maybe at some
          point we want to name the prop to control all the
          properties of justification and do it as an @ rule so
          people who want to be really specific can.
  plinss: We can have our list of default parameters for these
          languages that are good starting points
  dauwhe: That might be a good way of describing it.
  fantasai: That's so not going to happen in the next 6 years.
  plinss: I'm saying somewhere down the road.
  fantasai: The algorithm will have different kinds of outputs.

  koji: Are we resolving this as adding a non-normative appendix?
  fantasai: We're saying require what should be justified.
  koji: So like the minimum.

  <jdaggett> frankly, one *could* spec text-justify: auto in
             infinite detail but as fantasai says, this would take a
             *lot* of research and probably wouldn't be completely
             relevant in the end
  <jdaggett> "ideal" justification is not something easily defined,
             there's typically "better for this use"
  <jdaggett> to say that "this has already been done for print" is
             nonsense, a lot of print typography is manual tweeking
             up the wazoo
  <dauwhe> jdaggett: most of the time spent in producing a book is
           manual adjustment of word, line, and page breaks.
  <dbaron> jdaggett, but if fantasai is saying that the point of the
           text in the spec is to ensure that CJK text should be
           justified inter-ideograph when justify is specified, then
           the spec should at least require that
  <jdaggett> dbaron: sure, if specific requirements are being stated
             those should be detailed, agreed
  <jdaggett> plus any print justification algorithm is inherently
             offline and can do infinite automatic adjustments
             without worrying too much about rendering speed. this
             isn't true for browsers
  <liam> [people do worry about formatting speed. Luckily there are
         very good very fast algorithms, but there are NP-complete
         corner cases for all of them]
  <jdaggett> liam: but with browsers those algorithms need to
             execute in real-time on $25 devices
  <jdaggett> it ain't the same!
  <liam> jdaggett, yes, understood.

  fantasai: These are justification opportunities and if they exist
            you must do them. Would that work for you?
  dbaron: I guess so. There's a bunch of things you said about where
          you know how to prioritize that should be in the spec.
  dauwhe: And hopefully the simple statements can be tested.

  RESOLVED: Require which lines are justified even if justification
            method is not defined

Cursive Joining Across Inline Boundaries

  plinss: Next is Arabic letters connecting between elements.
  fantasai: So this was people taking a UL and formatting as inline
            elements and because there wasn't a space, all the
            Arabic words were jammed together.
  fantasai: So if you format with no spaces the Arabic elements run
            up together. We were discussing how to create boundaries
            at the element boundary.
  fantasai: We could create a property devoted to it.
  fnatasai: We could piggyback off of bidi isolation,
  fantasai: Or if you have non-0 padding or margin, you consider
            that shaping isolated.
  fantasai: This is about shaping behavior for scripts like Arabic.

  glenn: What about Arabic causes the spaces to collapse?
  TabAtkins: It's not. It's the lack of space causes it to have text
             on text.
  TabAtkins: Can you do a zero-width non-joiner? Is that sufficient?
  fantasai: Yep. I think we can do that.
  fantasai: Let me pull up the thread.
  fantasai: I think that would work if author is aware. If we want
            this in a UA stylesheet or to take affect automatically
            it wouldn't work, but I'm not sure we need that.
  fantasai: I can reply to the thread and ask if that's felt to be
  <plh> http://lists.w3.org/Archives/Public/www-style/2014Feb/0302

Control Characters

  fantasai: Okay. Next?
  koji: Control characters
  <koji> http://dev.w3.org/csswg/css-text-3/issues-lc-2013#issue-72

  fantasai: We got a question from James Clark about why are we
            ignoring form feed, vertical tab, and new-line
  TabAtkins: They normalize out.
  fantasai: You can stick them in the DOM.
  TabAtkins: Oh...nevermind.
  fantasai: Then Roc said Mozilla has a control character visibility
            property, do we want that?
  plinss: Some word processors let you make spaces visible.
  fantasai: Then there was a reply saying that there was a section...
  zcorpan: But you can put it into the script afterwards.
  fantasai: But then it won't work in legacy.
  fantasai: So there's a legacy problem with pages that use control
  dbaron: But pages that are in UTF-8 can spec these control points.

  fantasai: Do we need to care in CSS?
  clilley: No.
  fantasai: So we say Zach Winburg's comment is out of scope?
  fantasai: From the original comments, just say there's no
            reason to. They're formatting.
  glenn: Sometimes you want to see control codes. If you're doing
         Arabic you want to see left or right marks and joiners, but
         not in the default.
  TabAtkins: Mozilla has a display for invisible characters.
  zcorpan: That was to catch errors.
  TabAtkins: Sometimes you want to display them on purpose.
  glenn: Unicode has a block that has visual depiction symbols and
         some fonts support those for control groups.

  fantasai: Wasn't there a property in GCPM? (text-replace)
  glenn: You don't want to change the character content.
  clilley: Text transform doesn't.
  <clilley> text-transform: control-visible
  TabAtkins: That's a decent idea.
  fantasai: And you can pick what you want.
  TabAtkins: We can add a keyword to replace Mozilla's proprietary
  zcorpan: And would that be compatible with showing spaces or tabs?
  TabAtkins: This is what it would do.
  zcorpan: I thought it was just control characters, not spaces.

  fantasai: So any suggestions on responding to this comment other
            than no change?
  fantasai: Apparently we conflict with unicode, but I don't think
            we are, since we are a higher-level protocol.
  koji: I think the proposal also wants to treat things with
        whitespace. Is that reasonable to add?
  koji: He's saying because HTML and Unicode do it's own thing
        we should.
  koji: Form-feed character.
  fantasai: I don't have an opinion. We should do what browsers do
            which I'm guessing is not to display.
  koji: Implementors?
  Rossen: I'm not sure.
  fantasai: We can write a test.
  fantasai: It's invisible.
  fantasai: So I think that's what we're doing. And the spec says
            don't render.
  koji: We don't have form feed as whitespace.
  fantasai: No, it's a control character.

  fantasai: Any other comments?
  fantasai: I think that's all the text stuff.

  [break = 15 min]

Splitting CSS3 Text

  koji: The basic issue is some properties are ready but some
        properties need more work.
  koji: I'm proposing the split the fast moving ones so they can go
        to CR while the other ones can stay in a different spec.
  astearns: I'm all for splitting to different levels. You had
            proposed at some point different modules?
  fantasai: My concern is the things we're churning on are the
            things that are the highest priority, where as the
            things that are stable, the 2.1 stuff, is fine. So
            text-justify, line-break and word-break are the things
            the i18n care about the most and the split would make
            them go slower.
  fantasai: I think in this case I'd be against pushing that stuff
            to the next level.
  fantasai: That might mean it'll be another 3 to 6 months to CR,
            but I don't think it'll be more than that.
  fantasai: We need to do the edits we discussed today, do a new WD
            and do a few cycles of LC to get comments.
  fantasai: And that's kinda what we're stuck on right now.

  koji: The size of the spec is quite large so half the properties
        we get almost 0 feedback so asking review of all the
        features every time doesn't makes sense.
  fantasai: We can say what has changed since last LC and please
            focus on those things. I think if we split we'll have to
            do LC/CR for one and work from FPWD for the other and
            that takes longer.

  plh: What about marking things as at risk?
  fantasai: The things that are holding us back are things we don't
            want to drop.

  glazou: You said FPWD was hard?
  fantasai: It would take the focus away from the things that need
            work to the things that are stable and going well.
            There's also a certain amount of editorial work to keep
            the two drafts in sync.
  fantasai: That won't make things go faster except what's high
  glazou: This is one level. We don't need everything that's in the
          other level. It's not versions.
  glazou: You don't need to copy 3 into 4. 4 is an extension.
  TabAtkins: You really do. You don't want delta specs.
  <SteveZ> The AB (some time ago) advised that we do not produce
           delta specs
  <SteveZ> Delta specs are not reader friendly
  fantasai: There's [???] that interact.
  glazou: That's the purpose of levels!

  dauwhe: Is there a natural split? I want to have one-stop-shopping
          for text.
  fantasai: I think this proposal will just get text-indent and a
            few others to CR faster.
  koji: What happened to text-decoration is that the spec went to CR
        and implementation starts. This will help us focus on the
        things left in the spec. I can see a lot of benefits.
  fantasai: If the high priority things were in the stable state
            I'd agree.
  koji: But that helps me to move low priority items to other specs.
  hober: So you're saying that you should move the higher readiness
         items to CR?
  glazou: A few years ago we said if there are things that are slow
          and blocking advancement we should remove them to another
  dbaron: But the ideal is we do that for things that are high
  fantasai: When we split text-decoration it's because it was long
            and there was a logical break. It turned out one part
            was faster, but I was expecting the same speed.
  fantasai: There is a clear priority here. I want to concentrate on
            the high priority things.

  koji: If half the CSS items are things we don't want, why keep them?
  fantasai: Mostly it was in 2.1, plus a few minor extensions, plus
            hanging punctuation. I don't think hanging punctuation
            is worth it.
  koji: There are 7 properties that are likely to move faster
  glazou: Bureaucratic isn't bad, it's extra editorial work that's
          a problem.
  fantasai: What are the 7 properties?
  <koji> https://lists.w3.org/Archives/Member/w3c-css-wg/2014AprJun/0121.html
[Member Only]
  <koji> Higher (zero-to-few feedback to the last LC):

  plh: Are there implementations of several of those higher properties?
  fantasai: Yes. Of all. The first 2 are in CSS 2.1, the next 2 have
            implementations, hanging-puntuation is AH and text-
            indent is in CSS 2.1
  fantasai: The lower 4 are high priority for i18n and ebook
            communities. If it'll take us 6 months or less it'll
            cause more confusion to split instead of benefit. We
            won't know why we published two levels in 6 months.
  glazou: We did that for selectors.
  fantasai: No, they were many years apart.
  glazou: We split levels 3 and 4 and we released CR when we did 4.
  fantasai: But 4 isn't going to CR in multiple years.
  fantasai: These properties should go in 6 months. I think it
            should be 6 months.
  fantasai: Selectors 3 went to PR. Here we have a WD that we're
            taking to CR and creating a new one to also take to CR.
  fantasai: We also have implementations of everything that we're
            planning to defer.
  fantasai: They all have implementations.

  Rossen: So how confident are you in the 6 months?
  fantasai: It depends on how much time I put into it, but koji is
            also available so as long as we're actively responding,
            we should be able to.
  fantasai: We're not getting "re-design this" type of feedback.
  koji: I think that's optimistic. Last time i18n asked for a
        3 month extension to LC. To make CR in 6 months we have to
        do the WD in one or two months. That's tough.
  Rossen: So we're talking about longer.
  koji: That's why I want to reduce the focus.
  fantasai: I wasn't really working on this for the last 6 months,
            koji was the only one working on it.
  koji: I expect a lot of work.

  dauwhe: Can w3c help focus i18n on this?
  fantasai: I think that LC was during the holidays.
  glazou: That's not a valid excuse. They're always late. We've even
          discussed this during a F2F.
  fantasai: They're overloaded, I think.
  clilley: Part of their job is to check every spec everyone produces

  koji: I can't imagine how one person could make all the test cases
        for this spec.
  koji: I don't have an implementation team.
  plh: If we don't know we can get to rec in 6 months, why aren't
       we splitting?
  koji: We said CR. To get to PR I need help from implementors.

  hober: CR is an official call for implementations. What's stopping
         us from unofficially asking we'd like people to implement?
  fantasai: They're implementing already.
  hober: So then why haven't I heard of a call for implementors?
  dbaron: And if there was a CR we'd feel more confident.
  clilley: CR gives a message of stability. There's no patent
           difference. You can do CR in 0 time. If you have full
           pass on your test suite you don't have to go to CR if
           you've met the exit criteria.
  clilley: You just need a test suite that passes.
  koji: What happened to text decoration is that once it got to CR
        it was picked up. I think CR gives a good message.

  fantasai: dbaron, what on this list would you pick out for impl
            only once it hit CR?
  dbaron: I think we would implement the stuff in the lower list.
  fantasai: I don't see a benefit of taking the higher level stuff
            to CR.
  fantasai: text-indent, maybe, but no one is super excited about
            that. Maybe hanging punctuation for CJK, but that's one
  fantasai: The things people are really waiting on are the things
            in the lower list. Those are the ones that a transition
            to CR would make a difference and the split will slow
            them getting to CR at least somewhat. It will add time.
  fantasai: Making sure the spec is still all coherent and there's
            appropriae intro text to each section...
  fantasai: It's easy to cut out a section. It's harder to pull
            interleaved things out and make both levels each fit
            together. That takes time and it's not worth spending
            without a benefit and I don't think we would get a benefit.
  clilley: Splitting won't help in any way. I think fantasai gave a
           good demonstration of that.
  glazou: Is there consensus?

  RESOLVED: No change to CSS3 Text
Received on Friday, 13 June 2014 14:20:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:30 UTC