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

[CSSWG] Minutes Tucson F2F 2013-02-06 Wed PM II: CSS3 Text

From: fantasai <fantasai.lists@inkedblade.net>
Date: Tue, 19 Feb 2013 22:12:14 -0800
Message-ID: <5124693E.7030605@inkedblade.net>
To: "www-style@w3.org" <www-style@w3.org>
CSS3 Text
---------

   - Discussed interaction of word-break and line-break.
   - Wordsmithed line-break definitions
   - RESOLVED: Strike the two sentences "Support for this property is optional.
               It is recommended for UAs that wish to support CJK typography
               and strongly recommended for UAs in the Japanese market."
   - RESOLVED: (1) do language-specific justification and
               (2) and there are 4 values: none, auto, distribute and interword
               (3) auto includes inter-ideographic behavior
   - Plan to drop min/max values from letter-spacing, only have one value for tracking.
   - Need some plan to resolve conflict between
       a) Having ability to turn off letterspacing from justification
          (Needed for German)
       b) Having ability to combine tracking and letterspacing
          (Useful in CJK, possibly needed by legacy Japanese docs using
           'text-justify: ideographic; letter-spacing: 0'.)
   - Plan to defer 'text-align: <string>' to L4.

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


CSS3 Text
=========
Scribe: dbaron

   <jdaggett> http://www.w3.org/Style/CSS/Tracker/products/10
   jdaggett: This is list of issues on css3-text.  Koji and Elika want to
             push text to LC.
   jdaggett: I think this spec needs to be restructured; I think we need
             to drop a lot of things, because for one reason or another,
             they're underspecified, experiments, or not clear.
   jdaggett: I think some of these issues are more than going in and
             tweaking the wording; I think we should defer some of them
             all together.

word-break vs. line-break
-------------------------

   <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/291
   jdaggett: I think we can start with a few of these that are relatively
             simple.
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Dec/0052.html
   <jdaggett> http://dev.w3.org/csswg/css3-text/#line-break
   jdaggett: so the text module has 'line-break' property followed by
             'word-break' property
   jdaggett: These are to some extent governing similar things.
   jdaggett: These are somewhat based on IE properties, though IE has sort
             of deprecated... is it 'line-break'?  Documentation says
             word-break equivalent to line-break?
   fantasai: That seems very unlikely; not the same thing.
   jdaggett: Both about where you want to have a soft wrap opportunity.
   jdaggett: 'line-break' is trying to give you general categories;
             'word-break' is giving you escape hatches.
   fantasai: the other way around
   jdaggett: 'line-break' is giving general categories
   jdaggett: line-break has loose, normal, strict -- general categories
   fantasai: word-break is supposed to apply to entire text.  General policy,
             controls breaking between letters.
   fantasai: line-break is supposed to control line breaking around punctuation.
             One exception for small kana.
   jdaggett: There's an interaction between these properties; overlapping,
             I'd say.
   fantasai: They overlap in that they both control breaking around small
             kana, but that's the only overlap.

   jdaggett: So let me ask one question:  why can't these be unified?
   fantasai: I tried; people want to vary them independently.
   jdaggett: One property with keywords for one or both?
   jdaggett: word-break is unfortunate as a property name; really about
             line-breaking
   glenn: implementations can be orthogonal to a certain degree, maybe
          completely
   <SimonSapin> word-break sounds like hyphenation
   fantasai: property names are historical; not much I can do, and I didn't
             have anything substantially better
   jdaggett: both apply to a similar category of things; would be better
             as one property
   jdaggett: unfortunately glenn is now implementing this for WebKit, so
             we're not just talking about the IE implementation
   jdaggett: only IE that has implemented these properties in the past
   koji: don't know about Firefox
   fantasai: working on, but don't have one
   jdaggett: so effectively properties only supported by one browser
   glenn: I know word-break partially supported by WebKit, and there's a
          patch for line-break.
   jdaggett: But you're working on that.
   Koji: glenn working on line-break; word-break is in Safari 3.0

   glenn: I know that when I implemented line-break, including a large
          suite of tests, I did not have to take word-break into account.
   glenn: so it seemed orthogonal from a semantic perspective
   jdaggett: because 'word-break' only applies between letter breaking
             opportunities?
   glenn: word-break said that you can consider all possible soft breaks
          within a space-separated segment or not
   glenn: then once you consider soft opportunities then at that point
          the line-break property semantics came into play by defining
          what were soft-break opportunities and what were not
   glenn: ... in certain contexts, contexts being certain languages
   glenn: the semantics of the two properties were layered on each other
          so orthogonal to implement
   jdaggett: not sure how that's possible given that break-all and keep-all...
             text "except where forbidden by the line-break property" and
             "including those explicitly allowed by line-break"
   glenn: if it said keep-all, then you wouldn't consider any word-breaking
          in CJK
   glenn: so none of the soft breaks would apply
   glenn: if it said break-all, then all would apply
   glenn: if normal, then it allowed line breaking within words
   glenn: I was dealing with normal and break-all

   fantasai: if you do break-all and line-break: strict, then you're allowed
             to break between any two letters, except can't break before
             small kana
   fantasai: I thought this seemed weird, but was told people do that.
   glenn: I was just reading the definition of -ms-word-break: for break-all,
          behaves as normal for CJK text, but allows line-break to break
          normally for non-CJK text.
   glenn: so it excluded applicability for CJK text
   fantasai: because they break normally
   steve: CJK has kinsoku rules...
   smfr: are these 2 properties consulted at different times in the
         linebreaking algorithm, or do they all contribute to the possible
         breaks after which you decide where to break?
   jdaggett: I'm not sure I believe glenn's assertion
   jdaggett: where you said first deal with word-break and then deal with
             line-break
   jdaggett: seems like with keep-all specified, you still have to consider
             what line-break is
   stevez: common use in CJK seems to be to allow western words to be
           arbitrarily split rather than kept together
   stevez: no idea what this would mean in Arabic
   * fantasai notes it's defined for Arabic in css3-text
   glenn: IE documentation also says keep-all is suitable for non-CJK text
          including small amounts of CJK, break-all suitable for CJK text
          including small amounts of non-CJK text
   jdaggett: so the question is: will this break / be different from the
             IE implementation?

   glenn: The IE documentation claims that the unprefixed property is deprecated
   fantasai: ... in favor of the prefixed one
   fantasai: probably because there was a previous revision of css3-text
             where I tried to combine them into one thing

   glenn: I have to admit, in testing of my patch, I did not create a
          combinatorial test of line-break and word-break; I just assumed
          word-break was normal and tested the line-break feature
   jdaggett: has it landed?
   glenn: landed, but pulled out for performance regression, not functionality
   jdaggett: would we in the near future have something to test with?
   glenn: I'll be resubmitting in the next few weeks
   jdaggett: important to figure out if there are differences in the
             implementation and if those differences are important
   glenn: that's reasonable

   stevez: I'm more concerned that this is aimed at western text in a CJK
           setting
   fantasai: depends on the value
   stevez: It's still western in CJK, not south asian, not SE asian, not
           middle-eastern, and it is ill-defined for those cases, all of
           which have nuances
   fantasai: It's defined, it's just not useful
   stevez: it defines letters; for S asian, which work in terms of syllables
           rather than letters, it's ill-defined
   jdaggett: what they're saying is it's not useful
   jdaggett: is there something here that would be useful for those contexts?
   jdaggett: if this is unneeded, then it doesn't matter so much, but if
             there's something here that's needed, then that needs to go
             in the spec
   stevez: It just seems to me that letters are the wrong thing to define
           this in terms of.
   fantasai: Letters are defined to be grapheme clusters in L* or N* categories
   stevez: but syllables are not grapheme clusters
   jdaggett: I think the question is much more about if this applies in
             contexts other than CJK.
   Koji: is the question about whether to merge these 2 into a single property?
   jdaggett: In response to what Steve is saying, that these seem to be
             western/CJK only...

   stevez: Once sentence in here that's impossible to satisfy: when scripts
           that are shaped are broken, required to be shaped as not broken...
           but there are required ligatures that you can't break
   glenn: [missed].
   glenn: example 4 shows 3 words with break opportunities between each
          connecting character (and non-connecting)
   stevez: I understand connecting/non-connecting, but ligatures are worse
           than that.
   glenn: I think ligatures are second order to connectedness
   [discussion of lam-alef]
   [scribe can't keep up]
   glenn: what this doesn't do is discern the distinction between breaking
          between glyphs vs. characters
   glenn: so if result of char->glyph mapping produced ligatures and then
          connecting glyphs, that's a little different than saying break
          at the characters that correspond to the output glyphs.
   glenn: that's not really defined here
   stevez: where are letters defined?
   * fantasai trying to remember what was the goal of this discussion, and fails
   jdaggett: "A letter for the purpose of this specification is a character
              belonging to ..."
   fantasai: characters are similarly redefined to be grapheme clusters
   jdaggett reads definition
   stevez: syllables are not grapheme clusters
   fantasai: if you want to deal with breaking between syllables, we could
             add new values, but that's not a requirement anyone has given me

line-break
----------

   jdaggett: One issue I have is about line-break:  the text uses SHOULD language;
             I think that makes the entire behavior of this property a SHOULD
             behavior.  I think UAs should be required...
   fantasai: would changing recommended to required help?
   glenn: in many CSS specs [missed]
   jdaggett: I think what fantasai said would be sufficient.
   jdaggett: What I don't like is that it's using vague terms -- in the
             hands of an implementor, you'll get implementations that do
             different things.
   fantasai: what's vague?
   jdaggett: what's loose, normal, and strict, for non-CJK languages?
   glenn: it's clearly defined
   fantasai: It says "If the content language is C, J, or K..."
   fantasai: It says allow X, disallow Y, and if the content language is
             C J or K then also Z
   jdaggett: For a different language, are there different rules that are
             stricter or not stricter?
   [discussion about which part of the spec they're reading]
   Koji: first bullet applies to all languages, second applies to C J and K
   jdaggett: c'mon, it's about Kana
   fantasai: Can you quote the part of the text you have a problem with?
   jdaggett: As defined, this says nothing about what is done for other
             languages
   fantasai: you do nothing
   [multiple discussions]

   <glenn> http://trac.webkit.org/wiki/LineBreakingCSS3Mapping
   glenn: Link to table derived from this spec, with precise definition
          covering all languages.
   glenn: if you look at the header of that table, you see ICU open/close
          parentheses, loose open/close parentheses
   glenn: That's the column for if it's not CJK, what does loose mean?
   glenn: - means "as otherwise defined by the default line breaking behavior"
   glenn: So there are some fallbacks to the default linebreaking behavior
          defined earlier in the spec
   glenn: so for any language you can determine which applies
   stevez: you created this table how?
   glenn: by interpreting the spec that fantasai wrote
   glenn: and factoring in the use of ICU and UAX14
   glenn: what I'm trying to say is that there's a definitive, unambigious
          answer about what normal, loose, and strict, mean for all languages,
          from my reading of the spec

   jdaggett: (1) says RECOMMENDED
   fantasai: fixed now
   jdaggett: (2) not saying anything about other languages
   jdaggett: in the gestalt of the property, we've got 7 categories for
             line breaking... if I apply this to all languages is it really
             the case that loose and strict in this context should really
             never have a different meaning?
   fantasai: it's possible we might want to do that in the future
   fantasai: for this level there are no behavior differences for non-CJK text
   glenn: this does provide specific results for CJK
   fantasai: we've gotten no feedback for needs from other languages
   stevez: the table given does affect other languages
   stevez: loose sets before/after breaking on ellipsis, and doesn't for
           strict and normal
   stevez: ellipsis seems to me to be non-language-specific
   stevez: Is it only the ellipses that are in a CJK sequence, or all of them?
   fantasai: We don't say that it's for certain languages... it's for these
             characters, period.
   glenn: This table on ellipsis character refers to a specific codepoint,
          tied in to default behavior of ICU
   glenn: B/A mean break as permitted before or after

   glenn: I agree with jdaggett that recommended [...]
   fantasai: That's done already.
   <fantasai> RELOAD THE PAGE
   glenn: if the user-agent implements this property then I think it's done
   [...]
   Koji: RELOAD THE PAGE

   glenn: the fact that it doesn't define it for other languages I don't
          view as an issue; I agree with Elika
   glenn: If somebody comes forward and says that for Thai, we want X, then
          fine...

   jdaggett: for breaks after prefixes, currency symbols, why not define
             it in terms of currency symbols rather than specific codepoints?
   fantasai: Could you file that as an issue?
   <fantasai> ISSUE: Why aren't all currency symbols included in line-break rules?
   <trackbot> Created ISSUE-301

   jdaggett: The original issue was about the confluence of the two properties.
   jdaggett: I think there was text added that clarified keep-all.
   fantasai: So I think we can move on.

   glenn: In order to address his comment about behavior for other languages,
          I think we should add a note...
   fantasai: There's one note on that already, should we have two?

   jdaggett: There's a line saying "support for this property is optional...";
             I think this should be removed.
   <fantasai> "Support for this property is optional. It is recommended for
               UAs that wish to support CJK typography and strongly recommended
               for UAs in the Japanese market. "
   glenn: I agree.
   glenn: Support for the property is optional in that we don't have conformance
          criteria
   fantasai: we do
   glenn: not in 2.1
   jdaggett: we shouldn't be talking about UAs specialized in a given market
   SteveZ: The person who disagrees is not in the room.
   (Håkon)
   SteveZ: Are you saying you don't want optional properties in...?
   jdaggett: the notion that it's optional is a redundant statement
   stevez: I don't think it's redundant at all.
   jdaggett: all browsers render japanese text
   fantasai: not all CSS implementations are browsers
   stevez: not all browsers are conformant
   <SimonSapin> http://weasyprint.org/docs/tutorial/#weasyprint-navigator
   stevez: this sentence is here so you can be conformant if you aren't
           supporting certain things
   jdaggett: there are a lot of properties in css that only apply in a
             certain context.  We shouldn't be saying that if you're not
             involved in that context, it's optional.
   stevez: but it's not optional
   jdaggett: I don't think this is necessary, and we should remove it.
   stevez: Then we have to change the [forgot]

   steve: conformance to a module requires implementing all of the properties
          in the module correctly unless otherwise stated
   glenn: there's a section on partial implementations
   dbaron: The section on partial implementations what this WG insists that
           you do if you implement it partially. Implementing it partially
           doesn't mean you're conformant.
   dbaron: It means we recognize that implementations add features piece by
           piece, and states we want them to do it this way

   jdaggett: This is an unnecessary sentence; there are other properties
             in this spec equally CJK-dependent.
   jdaggett: We sholudn't be going through our specs and marking things
             optional...
   SteveZ: I personally don't care; I'd just rather not cycle back and end
           up in the same discussion.
   jdaggett: But I think Håkon was objecting to this property as a whole.
   SteveZ: I don't think he wanted to be required to do CJK support and
           vertical text support; I think his reason was largely concerned
           with implementing CJK.

   glenn: If you're asking for that particular sentence to be removed, is
          it safe to assume you also want to change the paragraph just
          before the bullets... "The precise set of rules in effect ...
          does recommend that" should also be removed, and the previous
          sentence for text wrapping should just end with a colon?
   glenn: you've asked to remove vague language like should and recommend
   jdaggett: without require, the entire property definition is left open
   glenn: do you want to remove that text?
   jdaggett: no
   glenn: that's inconsistent
   jdaggett: I'll raise issues on the mailing list and we can fight about
             this later.
   fantasai: Now we're deciding whether it's ok to have properties that
             are optional for conformance with the module.

   jdaggett: ... This whole module is about international text.
   stevez: Another way to meet what Håkon wants:  note that says for
           implementations that do not deal with CJK text this property
           has no effect
   fantasai: not true; don't want to parse something you don't do something with
   fantasai: if the implementation doesn't support, it shouldn't parse
             or trigger @supports
   stevez: in this case, support was to do nothing
   fantasai: support should never mean do nothing
   glenn: there are some specific semantics here in non-CJK text.
          It prescribes specific meaning to strict/normal/loose for certain
          non-CJK text.
   jdaggett: You're just saying that if the language is not CJK it applies.
             However, the characters are ones that are only used in Japanese.
   jdaggett: except for ellipsis, maybe
   glenn: also hyphens
   glenn: U+2010, U+2013
   jdaggett: but that's under language-specific
   glenn: so only ones are ellipses, U+2025, U+2026
   jdaggett: if you're going to object, then we'll move it to the list and
             resolve it there
   jdaggett: it's a waste of time to talk about this; it's a non-important
             discussion
   jdaggett: I think we should remove the two sentences and go from there
   Koji: straw poll, and Håkon can object?
   jdaggett: can just ask if there are objections?
   Bert: Is there nothing that can be done about the ellipses... whole
         property for just two characters?
   jdaggett: We're talking about the sentence
   glenn: Yes, it would be nice if those 2 characters could be put in the
          CJK portion

   jdaggett: There aren't implementations that just wholly ignore languages.
   fantasai: There used to be implementations that didn't support bidi at all.
   jdaggett: They're partial implementations... let's get on with our life.
   jdaggett: Especially for a spec that's all about international text
   stevez: I agree in general that there shouldn't be optional properties;
           fairly meaningless in an interoperable world.
   stevez: If you're saying this particular one is bad, I don't think there's
           that much of a case.
   jdaggett: I propose we resolve on striking these sentences.
   <koji> jdaggett proposed to remove "Support for this property is optional.
          It is recommended for UAs that wish to support CJK typography and
          strongly recommended for UAs in the Japanese market"
   RESOLVED: Strike the two sentences "Support for this property is optional.
             It is recommended for UAs that wish to support CJK typography
             and strongly recommended for UAs in the Japanese market."

   glenn: can I ask a follow-on?
   jdaggett: ok
   glenn: prior to the bullets, just above that:  "CSS distinguishes between
          three levels of strictness in the rules for text wrapping. The
          precise set of rules in effect for each level is up to the UA and
          should follow language conventions. However, this specification
          does recommend that: "
   glenn: I propose removing all but the first sentence of that paragraph
          and ending with a colon
   glenn: The use of "recommend" makes everything in the bullets optional
   fantasai: Is there a need to discuss this?
   glenn: I don't like recommend; I like to see requires
   fantasai: RELOAD
   glenn: ok, I'm fine with that

   Bert: I had a question, just to verify...
   Bert: looking at the definition, letter refers to character; says
         characters have to have a Unicode category.  But character is
         redefined as a cluster.
   fantasai: There's a definition; it's slightly complicated.

text-justify
------------

   <jdaggett> http://www.w3.org/Style/CSS/Tracker/issues/295
   jdaggett: If there aren't other issues on line-break, I'd like to talk
             about text-justify
   jdaggett: So the text-justify property: one of the more important issues
             I've logged about the spec.
   jdaggett: I don't think we should move to last call with text-justify
             as specified
   jdaggett: see http://www.w3.org/Style/CSS/Tracker/issues/295
   <jdaggett> http://lists.w3.org/Archives/Public/www-style/2012Dec/0057.html
   fantasai: what we've figured out so far that distribute value is needed;
             commonly opted into for CJK typography
   fantasai: an inter-ideographic is needed, since default does not allow
             justification of CJK, so people use it to opt in to CJK
             justification
   jdaggett: justification and line breaking are to some degree language
             dependent
   jdaggett: so why can't that be something that user agents simply do
             based on the language?
   jdaggett: http://dev.w3.org/csswg/css3-text/#text-justify
   jdaggett: shows values: none / inter-word / ... / kashida values in spec
   jdaggett: these are the categories
   jdaggett: I posted reactions that other people have had to this.
   jdaggett: I don't think this is the right way to specify modifications
             to the justification algorithm
   jdaggett: I think we should have a property more about the specific
             behavior of those things, and then abstract out across
             languages...
             e.g., in Thai, if you want to talk about different types of
             justification.  Focus on what it's trying to do.
   jdaggett: These came out of IE; if you look at the definition of these,
             it's vague, and not clear what they're doing.
   Koji: we made it clearer
   jdaggett:  we've given a definition, but I'm not sure what the use case is

   jdaggett: e.g., for inter-cluster
   jdaggett: we discuss this at [???].  Led to action item for use cases,
             led to what's now in the spec.  Look from author perspective.
             Why would author use this?  If it's for Thai, why would an
             author choose this?
   fantasai: default behavior is for spaces, this distributes between Thai
             clusters
   jdaggett: how is that different from distribute?
   fantasai: that expands Latin characers also
   fantasai: Definitely distinct from default behavior, you only turn it
             on in certain situations.
   fantasai: distribute says to justify between Latin characters just as
             if they're CJK characters
   Koji: look at figure
   jdaggett: not clear whether space after [go] is a fullwidth space or ...
   fantasai: Can't show all differences between all the values without
             mixing all the scripts, and nobody does that in real text.
   fantasai: if you want us to go scan pictures of stuff, we can find
             pictures to scan

   jdaggett: these are defined in terms of breaking Unicode character
             space into sections, in a way that doesn't seem natural
             to a lot of people
   jdaggett: people like John Hudson who posted a detailed response that
             you didn't answer... "why are you breaking scripts like this?"
   jdaggett: you're defining categories, set of scripts are defined way below...
             doesn't make sense to a lot of people, which John Hudson was
             saying
   http://lists.w3.org/Archives/Public/www-style/2012Dec/0057.html
   jdaggett: The point I'm trying to make is what he says in the second
             quote, starting with "Again, I come back to my previous point";
             now I'm paraphrasing what he said.
   glenn: what is your issue on Thai?
   jdaggett: not Thai... we're breaking this down in a way that's not at
             all clear to implementors, and using a system of categorizing
             Unicode scripts not based on standard or commonly used way of
             breaking it down

   glenn: I think we can do better examples, like for Thai.  It's often
          the case that you distribute between clusters.
   glenn: Unfortunately this example doesn't show any combining vowel signs
   glenn: or combining tone marks
   glenn: if the example had a consonant with a combining vowel sign and
          combining tone mark, it would be clear in the example how
          inter-cluster differs from distribute
   glenn: That's frequently used in Thai signage, newspapers
   jdaggett: you're saying the Thai characters are distributed differently
             from the latin characters?
   glenn: yes

   stevez: comes back to the definition of character. The definition of
           character now in the spec muddles that up.
   jdaggett: Trying to look at it from a high level and classify high level
             categories of differences is a safe way to do this.  It's going
             to be error-prone.  It's not specified in a way that it's going
             to be interoperable.
   glenn: grapheme clusters is defined by Unicode.
   fantasai: categorization of scripts is not, it's in terms of how they justify
   jdaggett: ... priorities ..., difference between one value and the other
             is the priorities
   jdaggett: I'm still unclear about the use case.
   glenn: Inside of publishing companies there are probably style rules for
          how to deal with multi-scripts distribution.
   glenn: I think you're probably not going to find it outside of that context.
   glenn: so anything that's definitive in some context is better than the
          current state of affairs which is pretty random
   glenn: if we don't have script prioritization specified properly, we could
          improve
   jdaggett: I think we should specify in terms of restrictions, "prioritize
             X less", "prioritize Y last"... we could cover all use cases that
             way, and leaves you not having to define broad script categories.
-glenn

   Koji: I still don't understand what you mean by use cases
   Koji: use case for inter-ideograph is japan, china, etc.
   jdaggett: That's my entire problem with this property.  If it's for CJK,
              why can't you just go based on the language.
   Koji: that's not what browsers do already for justification
   jdaggett: but it could easily be defined that way
   jdaggett: and defining it that way gives UAs more leeway to figure out
             what the right things, and we don't have to put a lot of effort
             into detailing script categories
   jdaggett: you're talking about pushing this to last call; it's not clear
             if it's the right direction
   Koji: It's implemented for WebKit and IE; everyone's using it
   jdaggett: part of the problem is that here, we don't know if implementations
             match
   <fantasai> 
http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Ap%20{%20width%3A%202.9em%3B%20border%3A%20solid%3B%20}%0A%3C%2Fstyle%3E%0A%3Cp%20lang%3Dzh%3E%0A%E8%BF%99%E6%98%AF%E4%B8%80%E4%BA%9B%E4%B8%AD%E5%9B%BD%E5%AD%90%E3%80%82
   <fantasai> Testcase above shows that implementations don't use lang
              values to turn on proper justification....

   jdaggett: MS people haven't documented their impl
   stevez: I'm not sure what you're complaining about
   jdaggett: This spec is defining script categories that are not defined
             elsewhere; we're coming up with our own set of categories.
   stevez: There's no external definition of script categories that we can
           point to
   stevez: is that part of your point?
   jdaggett: I'd put it as that we're making groupings that are unique to
             this spec
   stevez: there are groupings that are in common use today
   stevez: there are different justification rules in common use today for
           groups of scripts
   * fantasai wonders if we can avoid a lot of this by removing inter-cluster
   jdaggett: another way to think of them is not breaking them down by
             script but saying "these scripts share this behavior", and
             defining property values based on these behaviors, not saying
             property values say "value means X for this set of scripts
             and Y for this set"
   * fantasai is confused what the difference is between the two things
              above stated
   stevez: other problem with this outline, I think you're saying.... too
           many combinations of script X in Y to come up with a reasonable
           set of finite properties to adequately control every combination
   stevez: It might be better to be able to, with a script pseudo-element,
           to label how a fragment of text is to behave in justification
   stevez: that doesn't get me into the combination thing; the combinations
           come about by simultaneously trying to apply the set of pieces
   fantasai: I think that's overkill for 99.99% of the population.
   stevez: I think the default rules would work for 99% of the population.
   stevez: e.g., For Latin, the rules are word-spacing, then letter-spacing;
           for Japanese, normally no spacing at all so need a value to say
           space the letters; for Thai and most of S Asian I would use
           cluster spacing
   jdaggett: is there a tradition of justification
   fantasai: for Thai and many Indic, yes
   [details]
   jdaggett: if I look at Thai as an example

   dbaron: Koji was saying that browsers don't implement lang-dependent
           justification rules today
   dbaron: Just because they don't do it today, doesn't mean the solution
           is that authors should specify it, if lang-dependent rules
           would be sufficient.
   dbaron: If we can do things with same amount of code, but no new properties,
           then that's better.
   Koji: I think what we came down... WG wanted not to do language-dependent ...
         not introduce justification-language: japan
   jdaggett: nobody wants justification: japan.  But browsers already have
             some line-breaking behavior based on language; it makes equal
             sense to do the same for justification.
   jdaggett: ... and what I don't quite get... if a Japanese author says
             text-justify on a piece of text... are there multiple styles
             they'd actually use?
   various: yes
   jdaggett: then we need values... but do these values make sense to the
             author?  Do the values describe the different styles?
   Koji: if you want a space between characters, use inter-ideograph...
         people understand that

   fantasai: 2 typical styles in japanese: compress around extra spaces
             around punct; otherwise expand certain things, but don't
            expand between Latin
   fantasai: ... or just equally space everywhere (text-justify: distribute) --
             less common, but definitely used.
   jdaggett: I can see the use case for text-justify: distribute.
   jdaggett: seems like what you want are ways to say "allow this" or
             "enable that"
   jdaggett: then it's very clear that for this set of codepoints I'm allowed
             to expand the box, but at a lower priority
   jdaggett: that way you're creating property values that make sense to
             what the author wants to do
   jdaggett: not some "this is what's best for japan"
   Koji: then if ... tools work correctly, that changes layout
   Koji: you're saying to make justification language-dependent
   jdaggett: yes
   stevez: he's saying to put in language-specific rules for justification,
           and only have controls where they're needed to override
           language-specific rules
   jdaggett: yes

   dbaron: If you're doing lang-specific rules for justification
   dbaron: Could use rules specific to the language of the block
   dbaron: Within the block, mark sections as other languages
   dbaron: but not affect the justification choice for the block
   stevez: so you can distinguish between japanese-in-english and
           english-in-japanese, which is an important distinction
           since the rules are different

   jdaggett: the meta-point here is that this property seems like we're
             only doing it because IE defined it
   jdaggett: ... and that I see this as not the right way to do this
   stevez: slightly differently: we're doing it the way we're doing it
           because IE defined it.  Can we step back and say what is really
           needed to do the controls that we need?
   stevez: we recognize the need for a property (normal vs. distribute,
           maybe other cases)
   stevez: but I think John's complaint, do what IE/Word did... is that
           really the most reasonable way of doing this?
   Koji: I understand your point, but that's not what we want this way
   Koji: my belief is that layout language and content language are different
   Koji: I do not want layout dependent on language we use

   Koji: maybe different pseudo-element can work
   fantasai: no way to get correct justification by having somebody write
             the algorithm in CSS syntax... would just be a nightmare,
             e.g., with different punct characters behaving differently
   fantasai: doing high-quality justification for a language can't be done
             reasonably making the user define the algorithm in CSS syntax
   fantasai: it should be a one-line request for a type of justification

   stevez: I sort of agree with what you're saying ... jlreq talks about
           justification and categories therein.  But it largely punts on
           foreign language included in japanese
   stevez: it says what happens at the boundary, but not necessarily what's
           inside the foreign piece
   stevez: I think david's point that you need both a paragraph language
           and a specific language inside that may change things is another
           important piece to this
   stevez: ... which doesn't really get picked up in what we're talking about

   fantasai;as far as the switches needed: in Japanese need regular vs distribute
   fantasai: ... in Latin, whether letter-spacing can expand
   fantasai: ... and in Arabic, ideally, spaces vs. cursive elongation (Kashida)
   fantasai: ... which is common in newspapers
   fantasai: Those are the sets of switches that we definitely need to
             distinguish between

   jdaggett: example: cursive latin in Japanese text
   jdaggett: could be any number of styles applied there... can't be called
             Kashida (it's Latin)
Scribe: Bert
   jdaggett: In that context, you need to say how each one of those blocks
             will expand
   jdaggett: It may be that you only want to expand on word spaces
   jdaggett: In that context, you need to say how each type of block is
             going to expand.
   jdaggett: Maybe in the case of Latin, you want to stretch the characters.
   jdaggett: not widely supported, but neither is kashida.
   jdaggett: Picking those pieces is not necessarily a single setting.
   jdaggett: This single property sets all of these.
   jdaggett: Currently you have kashida and inter-ideogrpahic.
   jdaggett: Cannot allow them together.
   fantasai: Maybe in some future level we allow value combinations.
   fantasai: The example you gave is soooo obscure... we'll never get there.
   fantasai: Why ever discuss this even in the 15 years?
   jdaggett: It captures the problem that this prop is trying to define.
   jdaggett: Opaque to the user.
   fantasai: We can make it a shorthand in the future,
   jdaggett: Because we are defining it this way...

   jdaggett: My alternative is to not define it at this level.
   jdaggett: Only 'auto' and 'sdtsitribute' and rest in level 4
   fantasai: What about 'none'?
   jdaggett: What's it for?
   fantasai: accessibilty. Can turn off justification in user stylesheet.
   SteveZ: What's the harm with none?
   jdaggett: text-align: left is the same
   SteveZ: Not the same when you mix arabic and latin.
   fantasai: Overriding text-align also turns off centering, end-alignment.
   SteveZ: justification shouldn't have been in text-align.

   fantasai: auto & distribute would get you japanese distinguishing
             between two set of rules, that's fine.
   fantasai: But why not 'inter-word'? Could use it to turn off letterspacing.
   SteveZ: You can set letter-spacing to 0
   [discussion about what letter-spacing with a value does to justification]
   fantasai: Don't know if anybody cares if you get justification if you set
             letter-spacing to a positive value.
   SteveZ: letter-spacing: max?
   jdaggett: Can add some value.
   fantasai: text-justify [missed]
   SteveZ: jdaggett complains about it being a hodgepodge
   jdaggett: If we can resolve to make text-justify then we can resolve to
             deal with letterspacing.

   koji: webkit and ie do this property already.
   jdaggett: How can you NOT say that japanese behaves [...]
   koji: there are many docs without a lang attribute
   koji: Those documents will break
   jdaggett: this property that was never defines is somehow already defined
             by practice...
   fantasai: We have that situation all the time.
   fantasai: Not a circular referecne
   jdaggett: I'm not sure this is something that breaks if you treat in
             lang-specific manner.
   fantasai: If there is no lang attribute that may ok.
   fantasai: But there are docs out there there that have no lang attr
             and specify inter-ideograph.
   fantasai: They should continue to justify.
   fantasai: Two ways.
   fantasai: other is to have the initial value do that
   fantasai: MY pref would be for auto to just work for japanese, even if
             lang is not specified.
   jdaggett: sniffing.
   fantasai: We don't sniff, those code points just justify.
   fantasai: You'd have to test if that is web-compatible, though.

   jdaggett: We don't even know how ie and webkit work.
   jdaggett: They haven't given any input.
   jdaggett: not on how it desirable.
   jdaggett: was an action on sylvain.
   jdaggett: still not done.
   jdaggett: for a LC, this property should not be like this.
   jdaggett: Explore this, is one option.
   koji: how can we make consensus?
   koji: both sides have said everything.

   <fantasai> text-justify: none | auto | distribute | inter-word
   fantasai: I propose to define text-justify with 4 values:
             none auto distribute and inter-word.
   fantasai: interword turns off letterspacing.
   fantasai: distribute as defined currently.
   fantasai: auto would need test cases to ensure that CJK is correctly
             justified with auto.
   jdaggett: that sounds good. Not sure about inter-word.
   plinss: sounds like a way forward.
   SteveZ: inter-word not good for thai.
   fantasai: no, but use auto for Thai.
   fantasai: If it turns out to be an issue for Thai we can change it.
   fantasai: Thai community hasn't been demanding features yet.
   fantasai: However japanese has had very strong comments.
   plinss: can we resolve on that?
   koji: auto includes inter-ideograph
   fantasai: as long as the language-specific rules do not forbid it, yes.
   plinss: so, as long as there is no reason not to.
   fantasai: if you tag something as french and it has CJK, you may want
             to not space it.
   fantasai: but if untagged, use ja behavior
   RESOLVED: (1) do language-specific justification and
             (2) and there are 4 values: none, auto, distribute and interword
             (3) auto includes inter-ideographic behavior
   <fantasai> Discussion on inter-word continues after the break
   <fantasai> because it interacts with letter-spacing issue
   [dbaron and tantek leave for airport]

-dbaron
-tantek
Scribe: fantasai

letter-spacing
--------------

   fantasai: The letter-spacing property is defined so that if you apply
             any spacing value other than the initial value, it suppresses
             justification except at spaces.
   fantasai: This means that you can't combine tracking with any sort of
             East Asian justification
   fantasai: The proposal is to have letter-spacing: <length>; apply
             tracking, but leave justification alone
   fantasai: in other words it sets the optimal spacing between letters,
             not a fixed spacing
   szilles: If I have 2 different trackings on a single line
   szilles: What happens under justification?
   fantasai: I have no idea
   jdaggett: Maybe discuss that on www-style
   <jdaggett> discuss on www-style the new proposal

   fantasai: Anyway, you were suggesting to remove extra letter-spacing
             values
   jdaggett: The justification algorithm isn't specified, so that means
             the values of letter-spacing as defined in the spec, are not
             inter-operable
   jdaggett: These provide very fine-grained control
   jdaggett: This winds up being something they tweak to handle e.g. bad
             justification in webkit
   jdaggett: Some other implementation has better justification
   jdaggett: But has to deal with these values of letter-spacing, which
             are tuned to webkit's implementation, and make no sense in
             this new implementation
   ...
   szilles: If we don't say something about justification spacing, when
            it happens, and how much, then implementations will give
            different results.
   jdaggett: If you don't have sufficiently high quality justification
             algorithm, then this control becomes a crutch
   jdaggett: And then existing content will constrain future implementations.
   jdaggett: Thing that concerns me here, usually letter-spacing is used
             by ppl in design applications where they are setting the value
             empirically; they're testing against an implementation
   jdaggett: Usually from design to presentation, all same implementation
   jdaggett: That's not the case with the Web
   jdaggett: If you get to point where you need to set this property, then
             you're already dependent on particular implementation
   jdaggett: You're setting it so you get what you see in WebKit
   szilles: I don't think that's the common use.
   szilles: Can be used that way
   szilles: But common use is to control the amount of letter-spacing that's
            allowed to happen
   jdaggett: Common way this is abused is to make up for deficiencies in
             hyphenation algorithm
   jdaggett: Same way InDesign gives controls you shouldn't be using to
             do this
   szilles: InDesign case it's ok, because wysiwyg in results

   jdaggett: If you're proposing a simplified property, willing to defer
             this to that discussion.
   fantasai: I want to close off css3-text and send to CR, so if we're
             redesigning the approach, want to push to L4
   jdaggett: But you were saying that we needed to revise letter-spacing
             from 2.1 ...
   fantasai: The issue was that 2.1 gives the ability turn off letter-spacing
             for justification by setting to other than normal, e.g. setting
             to 0
   fantasai: And that's important for some languages like German, the ability
             to turn that off.
   fantasai: I was thinking that we could let letter-spacing: <length> allow
             justification, and use text-justify: inter-word; to turn that off

   szilles: Suggest letter-spacing-control property that would limit the
            amount of justification in letter-spacing
   szilles: John said he's concerned about variety of different implementations
            using this capability differently
   szilles: So I suggested that we could define a triggering of the use of
            letter-spacing-based justification based on a measurement of
            white space
   szilles: Most recent idea is that if I increase word spacing by more than
            X%, then I will trigger the use of up to the max of letter-spacing
            to reduce the word space
   szilles: Only reason I put latter in is to make it more clear as to when
            it's going to happen
   szilles: How much of it is used is still left up to the algorithm. Might
            want to do river elimination or something.
   szilles: The problem I have is that the use of inter-word is binary, not
            enough control in it.
   fantasai: Ok, that makes sense.
   szilles: If we did that, then I'm ok to have current thing have only one
            value
   jdaggett: Should we resolve on changing the current definition of
             letter-spacing to one value?
   Bert: Depends on what else we do.
   szilles: Think we should go back to letter-spacing define tracking only.
   szilles: Controlling justification piece should be separate
   szilles: So I can live with doing that.
   jdaggett: Think we have ideas here. Not sure we have something enough
             to resolve on.
   jdaggett: Resolve on a single value?

   szilles: Right now we have inter-word in there, want to drop that
   fantasai: Think we might still need it in Korean, have to investigate.
             But purpose there can be not about whether letter-spacing
             can be used, but about whether justification tries to use
             spaces only.
   szilles: Ok, that makes sense to me then.

   jdaggett: How about we resolve on a single value for letter-spacing,
             with action on fantasai to come up with wording that handles
             considerations above.
   fantasai: So if letter-spacing takes a single value, current definition
             forbids tracking with justification
   fantasai: So when letter-spacing is used, forbids any justification
             other than at spaces, e.g. no justification between
             characters/clusters in Japanese or Thai
   fantasai: I'm ok to having only one value, just have a concern with this
             situation.

   koji: What about word-spacing?
   Bert: Have some trouble understanding what word-spacing means with three
         values
   [jdaggett and fantasai try to explain this]
   <jdaggett> what is the maximum value for word-spacing?
Scribe: SimonSapin
   Bert: I was more surprised to see 3 values on word-spacing than on
         letter-spacing
   <jdaggett> is it the maximum *additional* spacing (i.e. width of the space
              + additional word spacing)?
   <jdaggett> or the maximum of (width of the space + additional space)?
   [fantasai draws an example]
   fantasai: the maximum refers to the max of increase to word-spacing from
             justification
   <jdaggett> let W = width of the space
   <jdaggett>     L = width of letter spacing
   <jdaggett>     A = variable additional spacing
   <jdaggett> max value of word-spacing = max(A)
   <jdaggett> ]
   SimonSapin: the used word-spacing is one length that is between the
               computed min/max
   fantasai: yes, they all refer to the same thing
   fantasai: yes, that formula is correct
   fantasai: CSS1 defines word-spacing as the additional space, and I can’t
             change that
   fantasai: with calc you can define calc(some value - 100%) to set the
             exact size of the space.
   plinss: letter-spacing happens on both sides of the space character
   plinss: so you get double letter-spacing between words

   fantasai: […] file an issue on German
   fantasai: you must not change letter-spacing for justification
   fantasai: we have to resolve the conflict between allowing Japanese
             letter-spacing for justification by default and not allowing
             it for German

   Bert: justify the last line (or only line) by increasing the font size?
   jdaggett: copyfitting. That’s hard

character-based alignment
-------------------------

   Bert: text-align with a string value … looked at "tabbing" as done in
         word processors
   jdaggett: not much control on how it’s lined up
   plinss: very controversial
   Bert: the idea is not to have to use a table
   jdaggett: table with this makes implementers cry
   SimonSapin: yes
   fantasai: syntax may not be ideal, but the functionality gets annoying
             in any case with tables
   jdaggett: you want this working in table, wondering if it’s the right way
   fantasai: could defer to level 4
   <jdaggett> agreed

etc.
----

   fantasai: other issues?
   jdaggett: none logged. Will review
   jdaggett: text-justify resolution means we can toss out at the appendix […]?
   fantasai: yes
   fantasai: Though redefining distribute to apply to Arabic could be interesting
   fantasai: or could keep definition of the cursive category
   plinss: adjourned

Meeting closed.
Received on Wednesday, 20 February 2013 06:12:43 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:21:06 GMT