[CSSWG] Minutes Seoul F2F 2014-05-21 Part III: CSS3 Text from Dael Jackson on 2014-06-13 (www-style@w3.org from June 2014)

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

CSS 3 Text
----------

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

==== FULL MINUTES BELOW ======

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

CSS 3 Text
==========

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

Relationship of text-align and text-align-last
----------------------------------------------

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<dbaron> I found
http://lists.w3.org/Archives/Public/www-style/2013Aug/0391.html
fantasai: Minutes from last F2F, we were ambivalent, then we heard
from digipub and they said it would be better to go
short-hand long-hand
<dbaron> fantasai is quoting from Minutes 2013-11-12 Tues IV

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

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

fantasai: Any other comments?

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

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

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

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

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

Forced Soft Breaks and Alignment/Justification
----------------------------------------------

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

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

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

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

Grapheme Cluster Terminology
----------------------------

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

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

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

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

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

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

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

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

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

text-justify: auto
------------------

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

fantasai: What's next?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cursive Joining Across Inline Boundaries
----------------------------------------

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

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

Control Characters
------------------

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

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

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

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

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

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

[break = 15 min]

Splitting CSS3 Text
-------------------

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

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

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

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

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

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

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

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

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

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

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

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

RESOLVED: No change to CSS3 Text

Received on Friday, 13 June 2014 14:20:08 UTC