RE: Feedback on hyphenation properties

Commenting only on the name change:
We have, for many years now, had an agreement that properties shared with XSL would have the same core definition in both working groups, but a working group could add additional values. This was done at the insistence of the CSS Working Group early on. The implications of this is either change the property name so that it is no longer shared or add the new values to true and false. 

The main reason that this becomes important is that other WG (e.g. SVG) can reuse the properties and that ought to have the same meanings wherever used.

Steve Zilles

> -----Original Message-----
> From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf
> Of Håkon Wium Lie
> Sent: Monday, August 09, 2010 4:40 AM
> To: Simon Fraser
> Cc: www-style@w3.org list
> Subject: Re: Feedback on hyphenation properties
> 
> Also sprach Simon Fraser:
> 
>  > > As you can see, the property used to be called 'hyphenate' but was
>  > > changed to make it different from XSL. I think the new 'hyphens' work
>  > > well -- it's shorter an easier to type.
>  >
>  > I don't know much about XSL, but is there a reason to keep the CSS
> property
>  > names different from terms that XSL uses? Does this cause actual
> problems in real
>  > use, or is it just to avoid developer confusion?
> 
> Normally, we try to reuse names. In the case of 'hyphenate', however,
> XSL uses this definition:
> 
>   hyphenate: false | true
> 
>   http://www.w3.org/TR/xsl/#common-hyphenation-properties
> 
> In CSS, "true" and "false" are avoided to allow for extensibility. The
> proposed CSS definition is:
> 
>   hyphenate: none | manual | auto
> 
> Also, I'd like to propose another value:
> 
>   hyphens: all
> 
> which, mostly for testing purposes, add markers in all hyphenation
> opportunities. Prince implements this and it seems useful:
> 
>   http://www.princexml.com/bb/viewtopic.php?f=4&t=3758
> 
>  > > The reason for having a comma-separated list is to allow different
>  > > hyphenation resource formats to be supplied.
>  > >
>  > > The only such format I know is the format used by TeX and OpenOffice:
>  > >
>  > >   http://en.wikipedia.org/wiki/Hyphenation_algorithm
>  >
>  > I don't see any description of the format of the hyphenation dictionary
>  > there.
> 
> Sorry, wrong link:
> 
>   http://www.ctan.org/cgi-
> bin/search.py?metadataSearch=hyphenation&metadataSearchSubmit=Search
> 
>  > I think if the CSS spec references a dictionary type, we need
>  > to at least specify what the format is, and ideally link to a normative
>  > reference on said format.
> 
> In general, I agree that it's useful to point out which formats
> browser should support. We don't do that for the 'icon' property, though:
> 
>   http://www.w3.org/TR/css3-ui/#icon-property
> 
>  > Its also unlikely that we'll support this format in WebKit on Mac, since
>  > we rely on an underlying framework for hyphenation, and it has its
>  > own dictionaries supplied with the OS.
> 
> That's fine. The draft states:
> 
>   In any case, the UA can also use local resources not listed on this
>   property.
> 
> If you want, we can also change the text from:
> 
>   This property specifies a comma-separated list of external resources
>   that can help the UA determine hyphenation points.
> 
> to
> 
>   This property specifies a comma-separated list of external resources
>   that optionally may help the UA determine hyphenation points.
> 
> or something?
> 
> -h&kon
>               Håkon Wium Lie                          CTO °þe®ª
> howcome@opera.com                  http://people.opera.com/howcome

Received on Monday, 9 August 2010 15:10:16 UTC