Re: Comments on CSS3: Text LC

Bert Bos <bert@w3.org>:
> Christoph Päper writes:
>
>> 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:
> but it would mean a lot of work without much certainty that anybody
> would implement it. The working group doesn't have the resources.

Perhaps it's worth a working group for its own as hyphenation dictionaries
can be of use in other (W3C) languages than CSS as well. You'd only need an
inclusion mechanism then. So far no browser I'm aware of supports
hyphenation (except with &shy;), so why wouldn't they implement a W3C
recommended format, if one at all?

>>| Name: linefeed-treatment
>
> I agree that the names are long, but they are like this in XSL.

Did I mention that I don't like XSL much? Especially without the trailing T.

>> 7.3. Text overflow
>
> The ellipsis character usually looks better than three full stops, but
> not all browsers know the character.

How many browsers supporting CSS3: Text don't support U+2026 nor the named
entity &hellip;?

> But I agree that, no matter how we write it in the spec,

Oh you meant that, okay then.

>> 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?

I'd guess, people will want to be able to style the ellipsis character as
much or less as a list bullet character. Personally I'm fine with using the
current text style or a URI.

>> 9. Text decoration
>>
>> I've written some comments about that chapter of the previous draft a few
>> days ago, most of those still apply.

That was <003201c27944$73490ee0$3ef4ae8b@heim4.tuclausthal.de>.

>>| Name: text-blink
>
> Not all browsers want to (can) do dynamic changes.

Wowereit. ;-)

>> 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.
>
> There are many things you could do with text: rot13, pig latin,
> removing vowels, swedish chef... but you can do that in the source.

Those go, as far as I know them, beyond the value I suggested, because
they're altering the letters or words and thus the meaning. Changing the
case doesn't do that, except for very few cases in some languages, but that
can happen with the current values, too.
Plus, "kewl" would show some amount of humour among the W3C.

I thought about an XML variant having a rot13 element, shouldn't it be
possible to say

  rot13       {text-transform: rot13}
  rot13:hover {text-transform: inherit}

in its default CSS? <rot13>secret</rot13> does mean "secret" and not
"frperg", but should be displayed as this.

>> 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.
>
> 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.

I fully agree, but it's getting harder to find the information you want in
the specs.

Christoph Päper

Received on Sunday, 27 October 2002 11:22:40 UTC