Re: CSS3 Text - Edit suggestions

Paul Nelson (ATC) wrote:
> I have read through the updated text. Following are comments for some
> more edits.
> 
> 1. For sake of consistency we should put all Unicode values inside of
> parenths, e.g. MIDDLE DOT (U+00B7). [especially seen in 7.3]

Fixed.

> 2. Section 4. Line Breaking (minor editing...grammar)
> 
> "For most scripts, in the absence of hyphenation a line break only
> occurs at word boundaries. Many writing systems use spaces or
> punctuation to explicitly separate words. Normally line break
> opportunities can be identified..."

...that seems to imply that standard line breaking in CJK text is
abnormal... I'd rather not make this change.

> "and often also Korean" - modern orthographic convention with Korean
> uses spaces between words. Inclusion here seems to be odd. I don't think
> it is often.

It's included here because line breaking for printed Korean often occurs
between syllables, as in Japanese, rather than only at spaces, as in English.
In CSS (as in UAX 14), this behavior is the default.

I switched "often" to "sometimes". If you like, though, I can remove it
from the list entirely; it's not worded to be exhaustive.

> 3. I would like to have the following sentence removed from the draft.
> It is an opinion that I would hope is no longer valid with current work
> of the Unicode group. "The CSS Working Group cautions implementers to
> consider the information in UAX14 with reservation..."

I recognize that Unicode has been constantly improving its specifications.
However, I would like to keep a note of caution about relying solely on
the pairs table in UAX 14. Anyway, I've commented it out for now: we can
discuss this at the F2F.

> 4. Section 4.2 - Replace "very much up-in-the-air" with "under
> discussion". Sounds more professional.

Changed.

> 5. Section 4.1 - Grammar fix: "When shaping scripts, such as Arabic, are
> allowed to break within words due to 'break-all' or 'break-strict', the
> characters must still be shaped as if the word is not broken."
> 
> 6. Section 4.2 - Grammar fix: "If hyphenation is applied to a shaped
> script, such as Arabic, characters must still be shaped as if the word
> is not broken/hyphenated."

Actually, "were" is the correct form of the verb here: the case is
counterfactual, so the verb should be conjugated as the subjunctive.

> 7. Section 6.2 - Remove "Where do scripts like Tamil fit in?". Tamil and
> other similar scripts go under the "clustered" classification.

As I said before, I've never seen Tamil justify as "clustered" -- only as
inter-word. If you have examples of Tamil justifying as "clustered", then
I'll remove the question; otherwise I'd rather leave it as an open issue
for now.

> 8. Previous mail indicated "flex points" might be replace by "expansion
> opportunities". 

Yep. I was planning to make that change as soon as I got home this afternoon...
It's checked in now.

> 9. Section 7. Spacing. I find this section confusing. Can you provide an
> example to illustrate the usage?

I'm /guessing/ you mean the <spacing-limit> definition.

The first paragraph says that

1. letter-spacing: 2pt 1pt 3pt;
    means optimum=2pt, min=1pt, max=3pt

2. letter-spacing: 2pt 3pt;
    means optimum=2pt, min=2pt, max=2pt

3. letter-spacing: 2pt;
    means optimum=2pt, min=2pt, max=2pt

(#3 is mandated by CSS1 and CSS2. Other than that, I'm not partial
  to the syntax.)

The second paragraph says that

1. Given computed values of optimum=2px and min=3px,
    min is reset to 2px.
2. Given computed values of optimum=2px and max=1px,
    max is reset to 2px.

Now that I think about it, it might make more sense to give precedence
to the minimum and maximum constraints, just like with min/max-width.

> 10. Section 7.2 "UAs must not apply letter-spacing to connected scripts.
> Or should they?" should be removed. If an author wants to apply a
> property to something shouldn't the UA honor the author's desire if they
> can?

Ok, removed.

> 11. Section 8.1 - After having some user scenarios provided by some
> on-line text processing applications, we might need to reconsider the
> ability to have multiple underlines applied, for example. In the case of
> a misspelled underlined word we want the underline to remain, with a
> different color wavy line for the queue for the misspelling. Might need
> some discussion on this at the F2F meeting. We want to be pragmatic, but
> not block a common use scenario.

I replied to this issue earlier. AFAIK, no previous CSS spec or CSS3 Text
draft allowed for multiple underlines to be specified on the same element.
However, even in CSS2, if you have nested elements each applying an
underline, they all get drawn under the descendant text. For example,

.spelling-error { text-decoration: underline; color: red }

    <span style="text-decoration: underline; color: blue">
      <span class="spelling-error">
         mispelt
      </span>
      correct
    </span>

Here the mispelt word will have two underlines: one red, one blue. (If
they're both the same style and font size, the red underline will paint
over the blue underline. Spellcheckers often use a different style,
though, so both underlines will be evident.) I think this should address
your use case.

~fantasai

Received on Tuesday, 20 February 2007 11:04:40 UTC