W3C home > Mailing lists > Public > www-style@w3.org > October 2013

[CSSWG] Minutes Paris F2F 2013-09-13 Fri V: Text, Writing Modes, Animations

From: Dael Jackson <daelcss@gmail.com>
Date: Mon, 30 Sep 2013 20:01:39 -0400
Message-ID: <CADhPm3sH2L7zPTpP=TP1nOZ33WOQAq35XBqoWF1eo_vkhW3-Lw@mail.gmail.com>
To: www-style@w3.org
CSS Text

  - RESOLVED: letter-spacing: <length> doesn't restrict justification.
              text-justify:inter-word; disables inter-letter
  - RESOLVED: letter-spacing:normal; computes to 0.
  - RESOLVED: Spec the dependence of text-align-last on
              text-align:justify and mark issue for feedback on
              shorthanding vs. not.
  - RESOLVED: drop minimum/optimum/maximum values for word-spacing.
  - RESOLVED: Keep 'text-align: start end' in, add an issue about
              naming, and mark it at risk.
  - RESOLVED: Take css3-text to last call pending resolving issues from

Writing Modes

  - Koji found a difficulty from the decisions made regarding tcy and
          writing modes yesterday.
  - RESOLVED: Drop digits 1
  - RESOLVED: css3-writing-modes to Last Call when edits agreed in this
              meeting are completed.


  - dbaron brought the group up to speed on the changes he had made to
       the spec.
  - The order in which events will fire and boundary points were of
       particular concern, but it was decided that an e-mail
       conversation and testing were the best way to answer the
       outstanding questions.


CSS Text

  Topic: Letter-spacing
  fantasai: CSS2.1 says that if you have non-normal letter-spacing, you
            can't justify between grapheme clusters, only in space
  fantasai: This is problematic in cjk, because they don't use spaces.

  fantasai: We have several problems with the current spec.
  fantasai: One is nobody implements it.
  fantasai: If you set letter-spacing to 0 or something else, in latin
            text, yes, you don't get any space. In cjk, no.
  fantasai: So the text currently thinks "0" and "normal" are the same
  fantasai: In word-spacing, "normal" *is* equal to 0.
  fantasai: Those are the problems.

  fantasai: Is there a reason not to change the existing spec?
  Bert: Point 3 (word-spacing) is an unfortunate mistake, but unfixable.
  Bert: I don't think that word-spacing and letter-spacing necessarily
        need to inform each other.
  Bert: Line-height also has "normal", and we don't compare them.

  Bert: When you say "nobody implements it", you mean "..."?
  fantasai: Implementations don't restrict cjk justification.
  Bert: One change could be to change the meaning of the existing
  Bert: We could alternately add a value.
  fantasai: That makes it unreasonably complicated for authors in a cjk
            environment. They have to set justification, and also set
            letter-spacing to something appropriate.
  Bert: Not necessarily letter-spacing, just text-justify. They do that
  fantasai: No, "auto" (default value) just works. There's a less common
            justification mode for cjk which they can opt into, but it
            normally just works.

  szilles: Restrict letter-spacing for a subset of scripts, and have a
           cjk-spacing or ideograph-spacing for their separate controls?
  fantasai: Doesn't work. I believe there's already content with
            letter-spacing at a positive value that expect spacing on

  Bert: Why do people set it to 0?
  fantasai: Because they think it's the right value, the default value.
            It's unobservably different if you're not justifying.

  Bert: I think I liked steve's proposal.
  fantasai: Letter-spacing right now applies to cjk, and it must
            continue to do so.
  Bert: It's not that it doesn't apply. It's just that letter-spacing:0
        lets you justify between cjk.

  fantasai: Okay, so the proposal is that letter-spacing never restricts
            justification for cjk, but non-"normal" values restrict
            justification for latin and similar scripts.
  Bert: How to define "similar scripts"?
  fantasai: Dunno.
  liam: If you have a passage of english text with a short passage of
        chinese, and have justification turned on, those characters
        could be spread apart?
  fantasai: Yes.
  fantasai: Spaces get priority over inter-cjk, though.

  szilles: One way to distinguish language categories would be if they
            use a word space.
  fantasai: So thai would be with chinese, but korean would be with
  szilles: Yes. If you have spaces, no need to do anything else.

  koji: "Word space" in unicode is one of the non-script-specific
         characters, so that doesn't tell us anything.
  koji: We'd need to have a script-based property for this.
  szilles: My concern is that there may be languages that use a script
           with word space, and another language that uses the same
           script without spaces.

  fantasai: This seems overcomplicated. Already, "normal" and "0" just
             seem confusing for authors.
  Bert: The fact that there are two values implies that they're
  fantasai: A lot of people probably don't even realize there's a
            "normal" value, and the fact that it looks the same as "0"
            normally doesn't help.
  fantasai: I think having script-specific behavior tied to "normal" vs
            "0" is also confusing.

  Bert: The best solution is to have some other feature to turn on
        flexible letter-spacing.
  fantasai: Things should work by default, and you're proposing that
            justification doesn't work by default for cjk.
  Bert: The spec already doesn't work for cjk.
  Bert: So don't break latin, just add something for cjk.
  fantasai: We're not getting anywhere, so I'm giving up for now.
  szilles: Well, we at least came up with several possible solutions.

  dbaron: Can we get a report of which implementers actually have a
          normal vs 0 distinction right now?
  fantasai: That's the issue - none of them do.
  fantasai: If we make this change to the spec we're bringing it in line
            with implementers
  dbaron: I couldn't find a CJK testcase where an implementation does
          inter-letter spacing for CJK justification
  fantasai: You have to set [lang] correctly...


  dbaron: I can't get Chrome to do any inter-character justification
          even with [lang]
  fantasai: I think Chrome needs you to set text-justify to something
  fantasai: Even if we change text-justify, the spec says that "0" means
            you can't justify between letters. So we still need to
            change something.

  koji: I think what Steve is asking for is to have a way to disable
        letter justification.
  szilles: To have a way of tracking which languages use inter-letter

  koji: We want today's behavior to not change, correct?
  szilles: Close. I'm okay with...
  fantasai: I think what makes the most sense is to make normal compute
            to 0, as it does with word-spacing.
  fantasai: And if we want a way to turn off inter-letter spacing, put
            that in text-justify.

  dbaron: I think using "letter-spacing:0" to prevent inter-letter
          justification is not intuitive.
  Bert: I think it's perfect. We don't need an extra property.
  <astearns> +1 on dbaron's statement

  szilles: We're trying to come up with a solution that matches today,
           is reasonable to explain, and gives me the ability to do
           tracking and allow justification using letter spacing.
  dbaron: I think we have a set of justification controls that I believe
          can do this already.
  dbaron: And we have something that is not intuitive in the spec, that
          doesn't match implementations, and that we'd like to get rid
          of. I don't see what the problem is.
  szilles: Evidence seems to say it does match implementations...?
  szilles: Except for 0.
  dbaron: That's what we're talking about.
  dbaron: 0 vs normal.

  Bert: The problem is that once I set a letter-spacing value, it
        shouldn't do inter-letter justification.
  Bert: It's nice that if you set it to 0, it also means no spacing.
  fantasai: So proposal is that if you set letter-spacing to a <length>,
            any length, you can still justify. (Plus a control on
            text-justify that prevents justification.)
  dbaron: But the spec currently says that setting a <length> should
          disable justification. The implementers that do perform
          inter-character justification don't follow the spec, and *do*
          allow justification.
  szilles: So right now we have one property doing both tracking and
           justification control...

  fantasai: What I'd like to see is that letter-spacing has no effect on
  fantasai: If you want to disable justification, use text-justify.
  szilles: So letter-spacing becomes tracking only.
  szilles: And "normal" and "0" are the same.
  Bert: Then we have a redundant value.
  szilles: That's okay.
  Bert: I don't want to change it in the cases where it currently works.

  dbaron: We *have* found that some browsers do cjk inter-character
          justification, and they violate the spec (doing it anyway,
          regardless of letter-spacing). They don't do inter-character
          for latin, so your case still works.

  fantasai: So my proposal is that text-justify has "auto",
            "inter-word", and "distribute".
  szilles: None of those do what japanese does.
  szilles: jl-req has a big table that does different things based on
           the letters.
  fantasai: That's "auto".

  dbaron: Does it vary based on tracking?
  szilles: I don't think it talks about tracking.
  fantasai: "Auto" explicitly does that jl-req stuff.
  steveZ: Fine, then I'm happy.
  ChrisL: So is "auto" testable?
  fantasai: Still no. jl-req is an informative ref.
  <jdaggett> hmm, 'auto' as currently define *may* do JLREQ stuff
  <jdaggett> there's no normative requirement for such behavior
  * TabAtkins jdaggett, yes, that's what we're saying.

  szilles: This is something where we want implementers to compete for
           better quality.
  fantasai: And there's a simple auto algorithm that they can do
  ChrisL: So there's no way to explicitly say "use jl-req"?
  fantasai: No. Japanese people have been kind and obsessive enough to
            write down a very good algorithm, but *nobody else* does
  szilles: Japan has house styles that vary the jl-req table.
  <ChrisL> and no way to say 'I implement jlreq but want the fast one

  * dbaron wonders how this is related to the normal vs. 0 issue.

  szilles: InDesign lets you control those things.
  SteveZ: I'm fine with this.

  liam: I wanted to make sure this didn't exclude arabic kashida
  fantasai: We had a specific value, but killed it. "Auto" allows that,
            and the spec has an example.

  liam: Also, when doing copy-fitting, you often have multiple things
        you want to list which controls what things are allowed to vary.
        Maybe have multiple values here?
  fantasai: I want to address that in the future. This doesn't block it.

  [straw poll, the yay carries]
  ~10 in favor, Bert against

  Bert: I don't understand why you change an 18-year old spec.
  plinss: To match implementations, none of which match the spec.

  RESOLVED: letter-spacing: <length> doesn't restrict justification.
            text-justify:inter-word; disables inter-letter

  fantasai: word-spacing:normal computes to 0. For consistency, I say we
            do the same thing with letter-spacing.
  Bert: I don't think there's a strong consistency argument.
  TabAtkins: I think word-spacing and letter-spacing are reasonable to
             tie in consistency arguments.
  fantasai: Also, this means the computed value is just a length, which

  RESOLVED: letter-spacing:normal; computes to 0.

Writing Modes

  fantasai: A new complication with tcy was found by koji.
  fantasai: <tcy><span>text</spa></tcy>
  fantasai: Koji and I were discussing this, and right now when we
            evaluate how much text to turn into a tcy run, we go across
            the entire contents of the element.
  fantasai: Whether or not you turn it into tcy depends on whether
            there's an element boundary in it.
  fantasai: If there's a boundary, we give up.

  glenn: Remember that TCY is a japanese word, while
         text-combine-horizontal is a property name. Consistency?

  fantasai: Koji and I were thinking of changing this, so that we just
            split up the text into runs between boundaries, then
            evaluate tcy on that.
  fantasai: So if I set tch:all here, I'll take the whole text run and
            turn it into tcy.
  fantasai: <tcy>a<q>bc</q></tcy>
  fantasai: Here, "a" becomes a tcy (turning upright), and "by" becomes
            a tcy.
            Rendered like:

  szilles: This isn't extensible.
  fantasai: Right, not extensible to including markup in the future.
  fantasai: But it's simple (no lookahead), and makes the contents of
            the tcy only ever be plain text.
  fantasai: An implication of changing this is that if I have "digits"
            as the value...
  fantasai: <tcy>123<q>45</q></tcy>
  fantasai: The first one wouldn't tcy, the second would. You'd get:
            (with 1/2/3 being rotated)

  szilles: I don't see what this solves.
  koji: I think extensibility to markup should be a new value for the
        tch property in the future.
  szilles: There's more likelihood of accidental markup than purposeful
           markup, and this one is affected by that accidental markup.
  koji: Today it'll fail entirely with accidental markup.
  szilles: Right, and that's probably a good thing.
  szilles: You're assuming that the <q> has a meaning in those examples,
           meaningfully breaking it into 3 units.
  fantasai: Current spec gives up when you see the <q> boundary.
  szilles: Right. Probably a better default.
  rossen: The other option was to, if it's all inline, to take it as a
          single tcy run.
  rossen: So it'll still fail on blocks.
  rossen: Which I think is reasonable.
  rossen: I think "all" is pretty explicit and means "I want this whole
          thing to be combined".
  rossen: Presumably I know what I'm doing.

  fantasai: What happens if I have <tcy digits>12<span>34abc</span></tcy>?
  fantasai: 1234 is expected to form a tcy.
  fantasai: But that's combining/breaking in an element.
  TabAtkins: That's similar to bidi fragments, no? This is a problem we
              already solve.
  TabAtkins: (not saying it's a sane problem)

  koji: We have implementers for 2 years, and we found these issues just
        a few months ago. We already have lots of content using it.
  koji: So we need something compatible with existing content.

  rossen: Option C would still work in existing content. TCY together
          everything that's inline.
  koji: Can we come up with some spec text?
  rossen: Yeah.

  szilles: We already have a notion of "inline content" in the grammar,
           so the spec can just say that the contents must be inline
  koji: ???
  szilles: You're basically converting a float of max-content width, but
           doing some other things - turning off some variants, etc.,
           maybe do some kernings.
  szilles: You'll have to specify all that anyway to be consistent with
  szilles: And if it doesn't fit in an em, scale until it does.
  szilles: Clearly not ideal, but I'm not sure we have much of a choice.

  dbaron: I think we do have the choice to do simpler things that don't
          work in every edge case.
  szilles: What do you buy? You're using code you already have.
  dbaron: That's not always simple.

  fantasai: Rossen and I were discussing problems with fragmenting the
  fantasai: For example, if you have logical properties that you want to
            cascade and resolve, you can't do that if part of the
            element is horizontal and some is vertical.
  fantasai: Rossen suggested that you start forming tcy, and if there's
            an unclosed element at the end, you give up.
  fantasai: Here you end up with a single fragment that has 2 different
            writing modes and that's worse than bidi
  TabAtkins: [doesn't understand why this is different from what happens
             in bidi fragments, but whatever]

  [discussion of details]
  <Bert> (Does <tcy digits2><em>abc1</em><span>2de</></> makes "12"
  <TabAtkins> (given their current suggestion, no - that's two unclosed
  <TabAtkins> (given the earlier suggestion of just using fragments,
               yes, it would)

  [more board scribbling and mumbling, too small, fast, and confusing to

  fantasai: We did decide we had an issue about "digits" having to check
            outside its boundaries, to make sure that a run of digits
            within the element isn't contiguous with a larger run of
            digits starting outside.

  israelh: In "abc<tcy>def</tcy>", what would happen?
  israelh: I mean <tcy>a<span>bc</tcy>.
  rossen: It would work - the span would both open and close within the
  fantasai: We were hoping to keep this relatively simple, which is why
            we had a non-inherited property.
  fantasai: Now it's getting more and more complicated.
  dbaron: It feels like this is already the complicated appendage to the
          spec, which is now getting more complex.
  dbaron: We agreed to stick on this complicated appendage because it
          was considered essential for some use-cases...
  dbaron: But do we really need to address every tcy case in this level?

  szilles: Figuring out which subset to address is where we seem to go
  fantasai: We started with just plain text...
  dbaron: And then you said it wasn't enough.
  koji: I'm fine with plain text with inherited values.
  koji: But what I just said gives bad results for the a/bc case.
  israelh: Do you see things like i^12, or whatever?
  koji: I see people doing H_2O or CO_2 using horizontal writing mode in
        an inline-block
  koji: I do see that, or "CO_2", etc. but you can just use
        writing-modes and inline-blcok for that.

  szilles: If I put properties on an inline, do you turn it off?
  fantasai: You inherit the all, and it takes effect on the inner span,
            not the outer.
  szilles: That's not extensible.
  fantasai: Right. You can use inline-block to do *anything* in tcy, it
            just doesn't do automatic compression.
  TabAtkins: Until we do copyfitting, which'll address that.

  fantasai: The other solution going forward that koji said, is a new
            display value "character", which does try to do compression,
            dots, etc.
  fantasai: That would let us do everything you want to do with this
  fantasai: This lets us do all the use-cases so far. You can even do
            CO_2 if you use the unicode subscripts.
  fantasai: You can use inline-blocks for anything else, and in the
            future we can get even better.

  szilles: I don't like the fact that it's not extendable.
  koji: We intended to do that. But we're designing for as simple as
        possible right now, and don't exclude expansion in the future.
  fantasai: ...so new design is inherited property.
  fantasai: Consistency argument is that "digits" takes a run and looks
            for continuous characters of a given type.
  fantasai: But only on a text run.
  fantasai: Consistent.

  <TabAtkins> "digits" or "all".
  fantasai: "all" is just like digits, but with any character.
  szilles: It really isn't like that at all. For digits, you don't need
           explicit markup; this needs explicit markup.
  rossen: Right, you normally want to avoid markup. "all" just fills in
          the holes for things like CO_2.

  israelh: To the extent that we keep it consistent with what we have
           right now, it'll be easier to understand. If we go beyond
  israelh: ???
  israelh: When we go beyond what we can compress in a single line,
           we've already established that it fails. So it's okay to
           fail, from an authoring perspective.

  rossen: So I think we converged to 2 choices.
  rossen: 1 is to keep inheriting. Break when you see element
  rossen: This'll make most cases that koji says work, and the "digit"
          value work.
  rossen: Simpler to implement, maybe a little more confusing to
          understand. Potentially not extendable.

  rossen: 2 is to go for more elaborate combining whee we allow crossing
          element boundaries.
  rossen: But then we need more smarts to think about if there are
          unclosed elements, etc.
  rossen: Likely harder to implement. Potentially more understandable to
  rossen: But I'm sure with enough mucking around we can always create
          some element combinations that fail us.
  rossen: So it's simple reimplementation but maybe some rarer cases not
          working, or more complex implementation with some exotic cases
          working, but we don't even know if it's the right "working".

  [howcome just left; Tantek left a few minutes ago]

  fantasai: (1) text-only, inherits
  dbaron: Are there still multiple variants of (1) ?
  fantasai: I have one in my head that I think is good.
  fantasai: (2) only inline content (previously C)
  fantasai: And (1) is A+D

  6 for option 1
  (fantasai, Rossen, Koji, Florian, dbaron, Tab)

  2 for option 2 (Israel, SteveZ)

  Bert abstains, can't make up his mind
  <hober> and many, many abstentions

  fantasai: Koji and I will spec up A+D and we'll come back to the
RESOLVED: Drop digits 1

[Short Break]

Scribe: Fantasai

  plinss: What's the status with jdaggett?
  plinss: We'll return to text if jdaggett appears

  Shane: At F2F in Tokyo, I offered to get back to group with regards to
         implementation progress that we made on the new T&A cascade
         that we resolved on,
  dbaron: I just got it into the spec this week, though some bugs in
  Shane: We don't have any problem with it, there don't seem to be any
         major issues.
  Shane: Some questions, though.

  Shane: One part of implementation that was sub-optimal:
  Shane: The issue is we've said that when you specify a transition on a
          property that is inherited and the inherited value is changing
          due to transitioning, child transition should not start
  dbaron: I thought we resolved the opposite.

  dbaron: My understanding was that we resolved...
  dbaron: Resolution I have is in minutes at
  <dbaron> A, C, D, E from
          with modified part B
  dbaron: We resolved to accept A, C, D, and E from this with a modified
          part B.
  dbaron: That's the edits I tried to make this past weekend.
  dbaron: Part D, I guess, is where I said that, although it falls out
          of the way I specified part A, or something else.
  dbaron: Idea there was that if you have an inherited property that's
          inheriting through a tree and you have multiple places in that
  dbaron: That specify transitions
  dbaron: Then you will get all of the transitions.
  dbaron: It may produce undesirable results, but it's what you asked
  Shane: We're happy with that approach, a lot easier to implement that
         than suppress child transitions.

  dbaron: One conclusion from that discussion was to give up on
          suppressing transitions there.

  krit: If you have inherit from ?, thought it was already specified
        from the beginning that we resolved values before staring
        animations or transitions.
  krit: We resolved all the inheritance values before we start the
        transition, so you don't have 'inherit' keyword.
  dbaron: 'inherit' isn't a computed value, so that's not a problem.

  Shane: I have a list of 5 questions, but we don't have to go through
         those now.
  dbaron: Anything likely to benefit from discussion?
  Shane: When do we fire events? Are events asynchronous?
  dbaron: When transition events fire?
  dbaron: I don't know that we have a resolution on it, but I think it's
          important that the script that runs as a result of
          TransitionEnd event run before the Refresh that would have the
          "no transition running anymore" style data.
  dbaron: Don't do a screen refresh.
  dbaron: Can't avoid script getting access to styles.
  dbaron: But really want to avoid screen refresh between update to
          style data and sending TransitionEnd event

  Shane: Does a transition end on the screen refresh that first ...
  dbaron: Asking > or >=?
  dbaron: I don't think we've actually defined that.
  Shane: Couple that question with timing statement you just made, then
         if you were to say that TransitionEnd on the first frame in
         which the final property value has been displayed, and the
         transition effect must happen before the next round.
  dbaron: Final property value is tricky with step transition functions.
  dbaron: Could we say perhaps that, talk about that hypothetical
          transition you'd have if your timing function was step-end?
  dbaron: Makes a change only at end of transition

  dbaron: Think that in Gecko we will fire the TransitionEnd event
          essentially while we're doing the style updates
  dbaron: In order to do the refresh for that value.
  dbaron: If you have a step-end() timing function, and have
          TransitionEnd on it, and use TransitionEnd to set it to some
          other value, think you should never see the end value of that
          transition. I would hope.
  Shane: No, I think you should.
  Shane: Otherwise, taking the step-end, if you chain based on
         TransitionEnd, you'll never see any value until the last
         transition ends.
  dbaron: I was using "see" too loosely...
  dbaron: We would fire the TransitionEnd event at a point where the
          script will see the end value, but we haven't yet repainted
          the screen for that value.
  dbaron: So if you make another style change right then, it'll take
          effect before we do any repaints. Not 100% sure about that.
  krit: Might be desired in this cas

  Shane: If you want to time two animations... to be perfectly smooth,
         then you... I guess it also ties into whether we consider
         transitions end-exclusive or not.
  dbaron: Spec is not very clear on this stuff.
  dbaron: Not entirely sure on this stuff. Not sure we should make it
          clear for this version or not.
  dbaron: If we figure out something we can agree on
  dbaron: Worth writing some tests for this stuff and seeing what

  Shane: We would be quite happy to not tie these questions down now and
         wait until WebAnimations spec has been reviewed, and then in
         the next level of CSS Transitions and Animations, adopt
         whatever conventions Web Animations has provided.
  dbaron: I'm certainly ok with waiting.
  dbaron: Don't necessarily want to commit to waiting for web
  hober: Right.
  dbaron: Not all that concerned that this will be a critical issue for
  Shane: ...
  dbaron: It's probably worth seeing how interoperable things are.

  dbaron: I definitely had mental model of what boundary conditions are.
  dbaron: I don't know if that agrees with your model, and spec doesn't
          have a model.
  Shane: Web Animations model is ... that a sample only belongs to one
         animation or another ...
  dbaron: That is the model I used in implementing CSS Animations, I
  dbaron: For repeating animations.. though not entirely I think.
  dbaron: Think what I did for repeating animations, I considered all
          the repetition cycles, if right at boundary, would use start
          state of next repetition than end state of last animations.
  dbaron: But for last cycle, would still use value from animation.
  dbaron: Don't remember if there was a good reason for that.
  dbaron: Essentially what I did for animations, it included both end
  dbaron: Picked second iteration over the first one.

  Shane: Given that model, when do the events fire?
  dbaron: At the boundary point.
  Shane: After style has been calculated, but before screen refresh?
  dbaron: In Gecko only fire events as part of our refresh cycle.
  dbaron: It would fire after style calculation.
  dbaron: Would need to look more closely at code to see what changes
          would take effect in observer.
  Shane: Does that mean another style update could be triggered?
  krit: Looking at SVG animations, it is always end-exclusive.
  dbaron: Ok, I will make note to myself to see what happens if we make
          ours end-exclusive completely, and see what that breaks.

  Shane: A little concerned about that approach
  Shane: If an event fires such that ...
  Shane: Interrupted, then we can't really do chaining properly.
  dbaron: If an event fires when?
  Shane: ...
  Shane: Step-end
  Shane: No change, no change, no change, then jump
  Shane: Never mind.

  Shane: We currently coalesce iteration events if there are multiple
         events between frames.
  Shane: You okay with that behavior?

  Scribe: krit

  dbaron: As implementer I would not really care.
  dbaron: Maybe we can discuss over email?
  Shane: Sure
  Shane: One other thing:
  Shane: Provide a negative animation delay and pause
  Shane: So that we can hit particular points and test these.
  Shane: I think we can build a nice conformance suite
  Shane: And think Gecko passes our test suite.
  Shane: Is there anything missing that we should test?

CSS Text
Scribe: dbaron

  fantasai: text-align and text-align-last; last issue on
            text-combine-horizontal (if we have a better name)
  fantasai: The issue is interaction of text-align and text-align-last,
            and whether one should be a shorthand of the other
  Bert: and whether there should be a text-align-first

  fantasai: Or we could just have 2 properties (text-align-all and
            text-align-last) and all can take 2 values to say what the
            first line should do, but I don't have a strong opinion on

  fantasai: I think we've discussed this a couple of times, don't have a
            super good answer.
  fantasai: The main difference in behavior is if you set 'text-align:
             justify; text-align-last: justify' and then later in the
             cascade want a particular paragraph to be 'text-align:
             center', the last line will still end up being justified.
  fantasai: Then we could do what IE does, text-align-last only takes
             effect when you have text-align:justify
  fantasai: If you go from center back to justify, then the first
            text-align-last is still taking effect. Do you want that, or
            do you want these text-align declarations to clear out the
            first one?
  fantasai: That's the main interaction issue.

  fantasai: There's also -- jdaggett wanted to be able to specify
            text-align: justify-all and have that just work instead of
            having text-align-last
  fantasai: But for back compatible we still need text-align-last
  fantasai: so if we want to make this work we need it connected --
            a shorthand

  fantasai: Last consideration: somebody on the mailing list wanted to
            say last line alignment matches the rest, without caring
            what it is.
  fantasai: If you want justify-all to work it needs to be a shorthand;
            if you want the ability to explicitly defer last to match
            others, it needs to not be a shorthand.

  Bert: If we have just one property, just text-align, and no
  fantasai: We have a backwards compatibility issue because people are
            using text-align-last. In IE6, and old CR.
  Rossen: at least
  fantasai: We know MS is going to continue to implement
            text-align-last, but seems like we're not going to have the
            shorthand option.
  fantasai: ... if we want to be compatible with ???
  fantasai: Have 2 implementations, Microsoft and Mozilla.

  Bert: Seems like what IE is doing is the best, just honoring last when
        text-align is justify
  Rossen: That's what word also supports.
  ChrisL: Put it in the "Applies To" line.
  fantasai: I thought word used something else.
  Alan, Rossen: Word gives you the option, only applies to the last line
                if justified.
  <ChrisL> applies to the last line of elements where text-align has the
           value justify.

  fantasai: Considerations are: cascading behavior - both solutions
            handle 'text-align: center' overriding -- but if elsewhere
            set text-align:justify does it resurrect the old
  fantasai: Can't have justify-all value vs. can't have value for
             matching the rest.
  fantasai: And an expectation of shorthand behavior from property

  fantasai: Comments?
  Tab: No opinion.

  fantasai: If we add first line justification, then it would probably
            be a keyword on text-align.
  <astearns> I'm for option B - text-align-last only applies if
             text-align is justify
  fantasai: If text-align-last is not shorthanded we probably wouldn't
            do a text-align-first property because it would have
            horrible cascading (and if we had a shorthand they should
            both be in the shorthand).
  fantasai: Bert and jdaggett prefer not having text-align-last and just
            using text-align for everything.
  fantasai: That would have been better.

  peterl: Can we deprecate text-align-last?
  Bert: Maybe I'm inconsistent, but in this case...
  Bert: but I don't think we should do that; it's been in a CR. One of
        those mistakes we make once in a while.
  peterl: I'm not saying take out of spec; leave it in spec and mark as

  Bert: Do you have a use case for text-align-last with anything else
        than text-align: justify?
  fantasai: I don't have a strong opinion right now, although before I
            was pretty convinced we should do the shorthanding.

  peterl: I'm not happy about the legacy issue, but that's life.
  Alan: Since we don't have a ??? use case for doing the right thing,
        but we don't have anything ???. Leave it as it is with MS's
        behavior until somebody gives us a reason to make a change?
  peterl: Will need to change if we want text-align-first, would make
          sense to have shorthand.
  Alan: Are we planning to do that now?
  peterl: No, but we should at some point

  [nobody seems to feel strongly]

  ?: I defer to jdaggett?

  Rossen: When we discussed this a couple months back, the query we did
          over roughly 2 million documents came back with ... something
          between 3-5% used text-align-last.
  peterl: Any tests for value of the property, or just presence?
  Rossen: I don't remember how I wrote the query... maybe checking for
          value other than inherit.
  peterl: So it included some cases where value had no real effect
  Rossen: I think so.
  Rossen: I wanted to see if <1%
  peterl: But it could also potentially drop if most were setting to
          initial value or something that has no effect.

  peterl: If there is no strong opinions, leave it as is?
  dbaron: How is it?
  fantasai: Spec says they're totally independent properties.
  peterl: What does Gecko do.
  fantasai: Completely independent.
  fantasai: AntennaHouse also implements

  fantasai: Spec the IE behavior, and if somebody prefers shorthand they
            can raise an LC comment and explain why.

  RESOLVED: Spec the dependence of text-align-last on text-align:justify
            and mark issue for feedback on shorthanding vs. not

  * oyvind re animations tests, there are some old ones in opera
           incoming/ that I didn't get around to inserting the spec
           reference links into yet.

  fantasai: I'm out of issues on css3-text.
  Bert: Can we add the poetry behavior keywords to text-align:
        first-left first-right?
  fantasai: A little concerned about doing that ... I'd do it as
  Bert: Too difficult for users.
  fantasai: Always correct.
  fantasai: The only use case is start-first.
  fantasai: I think it's obvious.

  Bert: Those are words only people in the WG understand.
  Bert: Maybe 'poetry', not 'start end'
  Koji: If people don't understand 'start end' then we need to discuss
  Florian: ... Beating them looks hard.
  Bert: I'm not sure if it's only based on the direction. If that's
        indeed the case than a single keyword would be enough.

  fantasai: Actually, there's 2 things I want to drop from the spec
  fantasai: (1) 'text-align: start end'
  fantasai: (2) word-spacing can take up to 3 values defining minimum
            optimum maximum; we don't have any implementations and would
            prefer to drop and figure out justification limits when
            we're in level 4.

  Bert: Do we want to have limits or do we want to allow other
        algorithms as well?
  Bert: I'm ok with dropping it, not sure we should add it back in
  fantasai: I think we should drop it until we have a clear idea what we
            want for that.
  Koji: Seems like the consensus is to drop.

  RESOLVED: drop minimum/optimum/maximum values for word-spacing.

  Bert: I'm not sure about dropping 'start end' value from text-align
  fantasai: Main reason I want to drop is not because I don't want to
            handle the poetry case, but because I want to figure out the
            clearest syntax.
  fantasai: This is just putting two keywords, not super-obvious what
            that means.
  fantasai: Maybe it makes sense to have some other keyword to express
            that instead.
  Bert: I'd like it to be a single keyword, not two keywords.
  Bert: 'poetry' would work for me.

  fantasai: I think that's too specific; I might use it for code.


  fantasai: Poetry in general is not aligned like that.
  peterl: Maybe research to see if there's a name for that?
  fantasai: I want to drop largely because don't have good syntax for it
            that's obvious.
  Bert: Two-sided, continuation?

  Alan: Any implementations?
  fantasai: No,
  Alan: I think we should drop it.

  Peterl: We're trying to go to last call soon.
  fantasai: Unless there are objections.

  peterl: That's not alone a reason to drop; because it's not
          implemented -- could mark at risk

  <Bert> (I think alan was talking about min and max on word-spacing,
          wasn't he?)
  <astearns_> Bert: I was talking about dropping the poetry thing.

  Alan: To play devil's advocate, ...
  peterl: Keep in, put issue about naming, mark at risk?
  fantasai: "This needs to be renamed at last call or it gets dropped"?

  Bert: At some point I want the feature that inserts an > on every line
        but the first.
  fantasai: I want to check with jdaggett, and check with him on
            text-align stuff.
  fantasai: So I will make edits and do the write-up and if people here
            are happy with it we can go to LC unless jdaggett wants more

  <Bert> (left square bracket is actually more likely than angle

  RESOLVED: Keep 'text-align: start end' in, add an issue about naming,
            and mark it at risk.

  peterl: Do we want to resolve for LC now, or wait for edits and
          jdaggett's feedback?
  fantasai: I would prefer resolution, even if it takes another cycle,
            so we can publish if things are ok.

  RESOLVED: Take css3-text to last call pending resolving issues from

  fantasai: Any open issues on writing modes?
  Koji: text-combine-horizontal naming only
  fantasai: Plan is for writing modes to go to last call once we have
            all the edits done.

  peterl: Any concerns with that?
  florian: Maybe not the last last call?
  hober: But we want the feedback, thus ok with doing it now.
  peterl: Are people comfortable going to LC without seeing edits?

  RESOLVED: css3-writing-modes to Last Call when edits agreed in this
            meeting are completed.

  fantasai: I'll post to www-style with the edits so people can look and
            give a week or so, and then publish.

Meeting closed.
Received on Tuesday, 1 October 2013 00:02:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 00:02:09 UTC