- From: fantasai <fantasai.lists@inkedblade.net>
- Date: Thu, 30 Jun 2005 05:43:18 -0400
- To: Christoph Päper <christoph.paeper@tu-clausthal.de>, www-style@w3.org
Christoph Päper wrote: > > I like most property and value names much better than the old ones. > > 3.2. The White Space Processing Rules > > * 2. If 'white-space-collapse' is not 'preserve-breaks', line break > characters are transformed for rendering into one of the > following characters: a space character, a zero width space > character (U+200B), or no character (i.e. not rendered), > according to the line break transformation rules. > > The last three words link (without looking like a link) to 3.2.2 > > 3.2.2. Line Break Transformation Rules > > When line breaks are collapsible, they are either transformed into > a space (U+0020) or removed depending on the script context before > and after the line break. > > No mention of U+200B here, except for: > > * If the character immediately before or immediately after the line > break is the zero width space character (U+200B), then the line > break is removed. Fixed by removing "into one of the following...not rendered),". The link actually has an underline... I'll probably spend some time on the style sheet before the next WD publication; I'm just using the old one for now. > 4.2. Hyphenation: the 'hyphenate' property > > Although it could be postponed to a later version of CSS, please > consider the inclusion of a 'url()' value to a hyphenation dictionary > that the UA should use /in addition/ to the built-in one. If the > ressource is not found or not supported---it is out of the scope of CSS, > but not necessarily the W3C, to define such a file format---, the > browser must procede as if the value was 'auto'. I don't see how this would be useful or interoperable. In particular, there's no way we could exit CR with such an ill-defined "feature". "word-break-inside: normal | hyphenate" was changed to "hyphenate: none | auto" to allow expanding this property's value in the future, but I don't think there is anything practical we can do at /this/ point. Having a hyphenation dictionary at all is still on the wish list, and if a particular application wants to provide support for custom dictionaries (say, for printing applications like Prince), they can use the vendor-extension mechanism, which would be just as interoperable as a standardized use of url() to point to a non-standardized dictionary format. That said, if implementations are working on hyphenation support and CSS3 Text's simple on-off switch is insufficent to represent the settings they need, we can expand the property in other ways. (E.g. set hyphenation limits.) Given the fluid quality of CSS-based layouts, however, I think hyphenation limits are best set automatically based on the actual content width. (You want less restrictive limits when you're working with shorter measures, and in fluid layouts you don't know how wide the measure will be ahead of time.) > 5.1. Text Wrap Settings: the 'text-wrap' property > > When restricted text-wrapping is enabled, (...) > > Is 'restricted' a former name of 'suppress' or is it any value other > than 'unrestricted'? It is not defined. Changed to "When 'text-wrap' is set to 'normal' or 'suppress'" Have I addressed your comments adequately? ~fantasai
Received on Friday, 1 July 2005 09:44:39 UTC