- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Tue, 19 Feb 2013 22:12:14 -0800
- 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 UTC