Re: CSS3 Text - Edit suggestions

Paul Nelson (ATC) wrote:
> The rational of moving hypenation from a script-specific context to an open
> application where it may (or may not apply) is that we do not know all of the
> places where hyphenation might apply. Rather than having us be experts in all
> scripts, having generic wording that allows UAs to implement hyphenation and
> word breaking to the best of their ability (and hopefully improve over time),
> a generic statement will help the specification be more robust.

Is the wording in my last email sufficient?

> I believe that a lot of effort has been put into helping UAX 14 be
> implementable. I would have a higher level of confidence in making the line
> breaking dependent on UA implementation than calling out that breaking
> generally occurs "at" punctuation. I don't know how "at punctuation" should
> be implemented and therefore see ambiguity introduced. I believe we should
> avoid introducing this ambiguity and encourage the use of standards whose
> purpose it is to provide the right kind of data.

The two paragraphs we're talking about are meant to provide background
information, not to set any normative requirements. I've been very careful
to avoid any normative-sounding wording. If it really makes you nervous,
I can explicitly mark those paragraphs non-normative.

Notice also that the new wording doesn't use "at punctuation". Please
reply about the text I've just given you, not what you replied to last
week!! You didn't answer any of my questions. :( :(

>> In these systems a line can break anywhere <em>except</em> between certain
>> character combinations.
> Is the plan to list all of the combinations? Or, is there a normative
> document that can be referenced?

There is no plan to list all of the combinations. We will normatively
reference the normative parts of UAX14, and informatively reference
the rest, along with other standards such as JIS X 4051. Line breaking
rules are ultimately up to the UA. There is a lot of room for tailoring
there and requiring, e.g. the pairs-based algorithm in UAX14 would
prevent any higher quality implementations.

> The issue with Tibetan justification is that groups like FLOSS have read the
> working draft document are then trying to figure out how to implement it.
> That is unfortunate because it is not a useful expediture of the volunteer's
> time. If one considers wood blocks and wants to emulate them then it may be
> beneficial. However, if you leave the information in the spec there will be
> many people who think that is the norm. Lets discuss this at the F2F meeting.

I think we should publish this draft before the F2F meeting so we can get
feedback on i18n issues from people like Asmus, C J Fynn, and the w3c i18n
community, and feedback on other issues like text-decoration and hyphenation
from the www-style community. That feedback should be part of our discussion
at the F2F: therefore we need to publish the draft before then. If you
agree that such feedback would be valuable for our discussions, then we must
agree that we can't wait until the F2F meeting to decide whether we publish
with Tibetan justification defined and marked as deprecated, or we publish
without it and leave people with an archived copy of my scratchpad with an
incorrect understanding of how it works and an incorrect understanding of
its usefulness (or lack thereof) in modern typesetting.

If you want a more obvious note about the deprecated status of Tibetan
justification, tell me what to write and I'll put it in.

> I second the idea that we talk about hyphenation at the F2F meeting at end of
> March.

Ok.

~fantasai

Received on Monday, 19 February 2007 20:19:35 UTC