RE: [css3-text] New WD of CSS Text Level 3

> Regarding value "all", this could be useful for speech hints,
> especially for common words used as proper names with abnormal
> pronunciation.  I understand that it is a minor use-case and
> that this value is intended for debugging, but I thought I'd
> throw that out there.
Providing speech hints and hyphenation feel like two orthogonal
scenarios. It feels strange to try to solve both scenarios with
a single property--even if it may be possible.

I think of the "all" value as strictly a debug value. I think
we should avoid adding debug values to the spec. I think a
better solution would be for UAs to provide better authoring
tools/APIs rather than for us to add new debug values to
properties.

*********

> Section 6.3 (hyphenate-limit-zone):

> This implies to me an area with a limited amount of hyphenation.
> What about "hyphenate-break-zone", "hyphenate-break-area",
> "hyphenate-break-margin" or "hyphenate-margin" (or padding...)?

hyphenate-limit-zone seems to mesh quite well with the other limit
properties. As with the other properties, it eliminates potential
hyphenation break opportunities--in particular, any hyphenation
points that exist in words inside the zone. I'd shy away from 
"margin" or "padding" because this zone doesn't have any impact on
the box model.

> One idea is that positive values can be relative to the line
> box and negative values to the block.  Otherwise, if one must
> be chosen, the block seems like an easier calculation?
What is the use case for negative values? If we make negative
values illegal I can't think of a scenario that's broken.

My feeling here is that the content box is more appropriate.
Authors will want to use hyphenation to achieve a consistent
visual effect across their text (e.g. across lines), so it makes
most sense to base the % value off of something that is shared
across lines.

*********

One hyphenation property that I think we should consider adding
is "hyphenate-limit-word". Similar to hyphenate-limit-before/after
this property would allow authors to specify the minimum length
a word must meet to be considered for hyphenation.

This functionality is supported by both InDesign and CorelDraw,
among others.

Authors can't achieve this level of control through
hyphenate-limit-before/after without also forbidding some
otherwise-desireable break opportunities in longer words.

Christian Stockwell

----------------------------------------------------------------------

From: www-style-request@w3.org [mailto:www-style-request@w3.org] On Behalf Of Xaxio Brandish
Sent: Friday, February 25, 2011 6:59 PM
To: Bert Bos
Cc: W3C style mailing list
Subject: Re: [css3-text] New WD of CSS Text Level 3

Good evening,

I was reading the editor's draft and had a few thoughts:

Section 5.2 (word-break):
Under value "break-all":

Might this want to reference UAX#29 or link to it from the term "grapheme clusters" since it is not defined this early in the draft?

The text
Hyphenation is not applied.

is used here.  It is not used for the other values.  Before the list of value definitions, would it make sense to say "Hyphenation is applied unless otherwise specified." ?

********************************************

Section 6 (hyphenation):

Because of the section subject, replacing occurrences of the word "broken" with "hyphenated" may be more clear.

********************************************

Section 6.1 (hyphenation control):
Under value "none":

The text says
Words are not broken at line breaks, even if characters inside the word suggest line break points.

Would it be more usable if this section mentions that section 5.2 (word-break) takes precedence, in case somebody jumps here directly from the navigation for quick-reference?

Regarding value "all", this could be useful for speech hints, especially for common words used as proper names with abnormal pronunciation.  I understand that it is a minor use-case and that this value is intended for debugging, but I thought I'd throw that out there.

********************************************

Section 6.2 (hyphenate-character):

This section contains a question:
Is the use of hyphenate characters at the beginning of lines common enough for this to be part of the specification?

The only use-case I can think of for this is a term that contains a hyphen which can have several words as the secondary portion of the term, whereupon the secondary portions modify the overall definition of the term and are then defined in a list format with a preceding hyphen for compound clarification.  However, all other cases and even this one could/should use list items instead, right?  What was the original intent of adding the second parameter to this value?  More specifically, in other languages, is the hyphenation continuation character different than the hyphenation break character?

********************************************

Section 6.3 (hyphenate-limit-zone):

This implies to me an area with a limited amount of hyphenation.  What about "hyphenate-break-zone", "hyphenate-break-area", "hyphenate-break-margin" or "hyphenate-margin" (or padding...)?

A question is asked:
Should percentages be relative to the line box or the block?

One idea is that positive values can be relative to the line box and negative values to the block.  Otherwise, if one must be chosen, the block seems like an easier calculation?

********************************************

Section 8.1 (text alignment):

How should section 6.3 calculate in relation to text-align: justify?  If 'justify' can change line boxes, it seems that no-hyphenation zones should be calculated afterward if applied to lines instead of blocks.

********************************************

Section 8.1.1 (Details on Character-based Alignment in a Table Column):

Should this section specify whether alignment characters generated as the result of list item prefixes are included in alignment calculations?

********************************************

Section 10.1 (first line indentation):

This section contains a sentence fragment:
Unless otherwise specified via the ‘each-line’ and/or ‘hanging’ keywords, only lines that are the first formatted line of an element.

Is this fragment intended as an "applies to" description, or is it supposed to be "...of the line box, unless otherwise...."?

--Xaxio

On Thu, Feb 17, 2011 at 9:40 AM, Bert Bos <bert@w3.org> wrote:
The CSS WG published an update of the CSS Text module:

   http://www.w3.org/TR/2011/WD-css3-text-20110215/


This module covers line breaking, justification and alignment, white
space handling, text decoration and text transformation.

The section "Changes" briefly lists the features that have changed since
the draft of last October:

   http://www.w3.org/TR/2011/WD-css3-text-20110215/#recent-changes


As usual, we ask that all comments on the draft be sent to this mailing
list, <www-style@w3.org>, with a subject line that starts with

   [css3-text]



Bert
--
 Bert Bos                                ( W 3 C ) http://www.w3.org/

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

Received on Saturday, 26 February 2011 06:23:29 UTC