Re: Comments on CSS3: Text LC

Christoph Päper writes:
> 
> <http://www.w3.org/TR/2002/WD-css3-text-20021024>
> 
> 2. Introduction
> 
> The legend for cell glyphs looks odd, a <dl/> would be appropriate IMO.
> 
> [Skipping stuff I don't know anything about.]
> 
> 4.4. Minimum and maximum font size
> 
> | 'auto' means that the user agent determine the minimum readable
> | font-size for the media. For example, a value is 9px is recommended
> | for Latin scripts.
> 
> s/is 9px/of 9px/
> I'm not sure that "9px" is correct here. You surely need at least 9 dots
> height to form all Latin letters, but is this really "9px" with "px" in the
> CSS sense?

It is only an example, not normative, but even so, I think 9px is
probably correct. If you have a 200dpi display, 9 dots would look like
a 3pt letter. The screen would be good enough that you could take a
magnifying glass and read the text, but that is probably not what you
want. You probably want at least 18 dots, i.e., 9px.

> 
> | the fonts of the last line of an element are not allowed to become
> | larger than the larger of 'font-size' and 'max-font-size'.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^
> 
> Are min- and max-font-size only of use in conjunction with
> text-align-last:size;? Instinctively I'd guess, it was possible to define
> e.g.
> 
>   body {font-size: 18px}
>   ul {font-size: inherit}
>   li {font-size: 67%; min-font-size: 9px}
> 
> to get readable fonts in nested lists.

Yes, that makes sense. It would need a modification of the font
selection algorithm and the property would then probably be better
placed in the Fonts module. Worth considering, I think.

> 
> 6.3. Word breaking
> 
> | Name: word-break-CJK
> 
> Wasn't there a (unwritten) rule to have all CSS properties lowercase?

You can, of course, still write 'word-break-cjk' in your style sheet.
In general, we do indeed write properties and values in lowercase, but
sometimes we make exceptions for readability. "CJK" is the common
abbreviation. Writing "cjk" doesn't look too bad to me, but I guess
it's a matter of taste.

> 
> Had there been considerations to add a possibility to CSS to allow authors
> to specify a (custom) cross-browser hyphenation dictionary?

That has been suggested, but so far it seems to be too hard. There is
no standard format for such dictionaries; there aren't even MIME types
for the formats that do exist.

We could, of course, define a new format, maybe even one that is
embeddable in CSS:

    @hyphenation nl {
        woor*den*boek i*dee*tje ca*f{é,ee,}tje
    }
    @hyphenation en {
        dic*tio*nary dic*tio*nar*ies
    }

but it would mean a lot of work without much certainty that anybody
would implement it. The working group doesn't have the resources.

> 
> 7.2. White-space control
> 
> | Name: linefeed-treatment
> 
> I think the property values are self-explaining, but too long. Can you
> rename treat-as-space -> space, treat-as-zero-width-space -> zero-width,
> ignore-if-after-linefeed > no-double?

I agree that the names are long, but they are like this in XSL.

> 
> | Name: white-space-treatment
> 
> The same as above. ignore-if-before-linefeed -> before,
> ignore-if-after-linefeed -> after, ignore-if-surrounding-linefeed ->
> surrounding.

Ditto.

> 
> 7.3. Text overflow
> 
> | The hint is typically an ellipsis character "..."
> 
> But you're using three characters here. I presume you mean the Unicode
> character that's behind &hellip; (too lazy to check its number) or an
> appropriate alternative. Same for the initial value of
> text-overflow-ellipsis.

The ellipsis character usually looks better than three full stops, but
not all browsers know the character. But I agree that, no matter how
we write it in the spec, we should make it explicit what the initial
value of 'text-overflow-ellipsis' is: the single ellipsis character or
three dots. I'd vote for the single character.

> The following example isn't marked up like the others (no maroon background
> etc.). Also use blockquote instead of div.citation.

Good point.

> I wonder if not a pseudo-element ::ellipsis would be more convenient.

Not more convenient, I think, but potentially more powerful. On the
other hand, do we really want the complexity of colored ellipsis in
different fonts with fancy backgrounds and borders? Note that you can
use an image instead of text, so if you really want to go wild, you
can: just do it in SVG.

> 
> 9. Text decoration
> 
> I've written some comments about that chapter of the previous draft a few
> days ago, most of those still apply.
> 
> 9.5. Other text decoration simple properties
> 
> | Name: text-underline-position
> 
> Everywhere else a value for automatic selection is called "auto", here it's
> "auto-pos", any particular reason for that decision?

That is because 'auto' is already a value on 'text-underline-color'
and the shorthand 'text-underline' would become hard to interpret if
'auto' could mean either auto color or auto position.

Though I think it is not in fact ambiguous, just harder. Hmm, maybe
I'm changing my mind: 'auto' might well be better than 'auto-pos'.

> 
> | Name: text-blink
> 
> | Conforming CSS2 user agents are not required to support this value.
> 
> What about conforming CSS3 UAs?

I think that sentence was meant to read "CSS3," not "CSS2". probably a
cut and paste from CSS2 that wasn't corrected afterwards. Not all
browsers want to (can) do dynamic changes.

> 
> 11.1. Capitalization
> 
> Just had the strange idea of a "kEwL" "h4x0R" or "hacker" value for the
> text-transform property, randomizing the case of the characters.

Hackers might say that it is not just a style, but a life style :-)

There are many things you could do with text: rot13, pig latin,
removing vowels, swedish chef... but you can do that in the source. I
think that when you want those, it is probably not just a style
change.

> 
> 12. Properties index
> 
> | In addition to the specified values, all properties take the [table]
> 
> The what? The "inherit" value?

Yes, probably. And also 'initial'.

> 
> Final Thoughts:
> 
> It seems as if you've done quite a job in CSS i18n, the backlash is, that
> there's *a lot* of confusing, uninteresting information for us Latin script
> writers. UA stylesheets aren't anymore useful without support for :lang(), I
> guess.

The intention is that designers should not have to worry about scripts
they don't know, nor should they have to protect their styles from
applying to other languages.

The initial values normally make sense, and when the default would be
different for different scripts, the properties have been split
(word-break-CJK vs word-break-inside).

'Linefeed-treatment' could be a problem. The 'auto' value will
automatically do the right thing, but if you explicitly set it to
'treat-as-space', any Thai text in that element will look wrong.
(There should be no spaces in Thai.)

On the other hand, 'linefeed-treatment' is probably only for
exceptional cases, anyway. If you use the 'white-space' shorthand, you
cannot even set 'linefeed-treatment' to anything but 'auto' or
'preserve'.

> There're some inconsequencies in refering to HTML/XHTML and their elements.
> You see "<br> XHTML element" (with <code>&lt;br&gt;</code>) as well as "IMG
> HTML element" (without <code/>), please keep one representation.
> 
> Christoph

PS. I see that the draft still has 'pre-lines' as a value on
'white-space' (meaning: collapse white-space and wrap as normal, but
still honour explicit line breaks). The current preference in the
working group is to rename it to 'pre-line' (without "s"). But if
anybody knows a better name...



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos/                              W3C/INRIA
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France

Received on Friday, 25 October 2002 15:07:57 UTC