- From: Etan Wexler <ewexler@stickdog.com>
- Date: 30 Jan 2003 21:00 +0700
- To: www-style@w3.org
Following are substantive comments on the Working Draft,
"CSS3 module: text",
<http://www.w3.org/TR/2002/WD-css3-text-20021024>.
3.1. Text layout introduction
"(e.g., Roman scripts)" ... "(e.g., mixing Roman with Arabic)"
Change both occurrences of "Roman" to "Latin".
"For example, Roman scripts are typically written left to right"
Change "Roman" to "Latin".
3.2. Setting the inline and block progressions: the
'writing-mode' and direction' properties
"Sets the inline progression to left-to-right, and the block
progression to top-to-bottom as is common in most Roman-based
documents."
Change to "Sets the inline progression to left-to-right, and the
block progression to top-to-bottom, as is common in the Latin
script."
"Sets the inline progression to top-to-bottom, and the block
progression to right-to-left as is common in Asian scripts."
Devanagari, Arabic, Tamil, Thai, and Mongolian are all Asian
scripts; none of these normally proceed top-to-bottom and
right-to-left. Change to "Sets the inline progression to
top-to-bottom, and the block progression to right-to-left, as is
common in some East Asian scripts." Or change "Asian scripts"
to "the Han script".
"tb-lr"
.. "The direction property is set to 'ltr'."
This writing mode is like 'rl-tb' turned 90 degrees
counterclockwise. So why is 'direction' set to 'ltr'?
"bt-lr"
.. "The direction property is set to 'rtl'."
This writing mode is like 'lr-tb' turned 90 degrees
counterclockwise. So why is 'direction' set to 'rtl'?
".hinv {writing-mode: lr-tb; display: inline-block;}
<span class="hinv">1996</span>"
The class name "hinv" is tied to presentation and should be
replaced by, for example, "date".
"The 'writing-mode' and 'direction' properties, when specified
for table column elements, are not inherited by cells in the
column since columns don't exist in the document tree."
Columns may exist in the document tree; in fact, columns must
exist in the document tree if one is setting properties on them.
That is not the issue. The issue is that the column elements are
never the ancestors of their constituent cell elements.
"As such, 'writing-mode' resets the 'direction' value.
Similarly, modifying 'direction' after 'writing-mode' changes
effectively the 'writing-mode' value to the opposite inline
progression."
In other words, a declaration of either property sets both
properties. This should be formally recognized, so that in the
following example, the computed 'writing-mode' value is 'rl-tb'.
e { writing-mode: lr-tb; direction: rtl; }
3.3. Glyph orientation within a text run: the
'glyph-orientation-vertical' and 'glyph-orientation-horizontal'
properties
"The glyph orientation relative to the inline progression is
determined automatically based on the Unicode character code of
the rendered character."
From a certain perspective, this is true, but the statement
fails to speak to the heart of the matter. It is the width
property of the character that determines the orientation of the
character's glyph. Is there a concern about confusing readers by
using "width" and "property" with meanings that differ from
their CSS meanings?
Following the example of the split between 'word-break-CJK' and
'word-break-inside', we should have
'glyph-orientation-vertical-wide' and
'glyph-orientation-vertical-narrow'. We can retain
'glyph-orientation-vertical' as a shorthand, its 'auto' value
setting 'glyph-orientation-vertical-wide' to '0deg' and
'glyph-orientation-vertical-narrow' to '90deg'.
"The user agent may round the value of the angle to the values
of glyph rotation supported by the user agent."
Does this affect the computed value?
"Name: glyph-orientation-horizontal"
..
"Applies to: all inline-level elements"
Why does 'glyph-orientation-horizontal' apply only to
inline-level elements?
4.5. Additional compression: The 'text-justify-trim' property
"i.e. the blank space within the character area itself"
Change "character" to "glyph".
5. Indentation: the 'text-indent' property
How does 'text-indent' interact with "text-align: center"? Is
the content of the first line centered within the area remaining
after the indentation is considered?
7.1. Text wrapping: the 'wrap-option' property
The focus on line feed characters (U+000A) is very tied to XML.
In SGML, for instance, the commonly preserved line break
character is carriage return (U+000D). And, looking to the
future, line separator (U+2028) will come to be the line break
character of choice, even if XML sticks to line feed.
"a text wrap after the last character which can fit"
Change "character" to "glyph".
8.5. Text kerning: the 'kerning-mode' and
'kerning-pair-threshold' property
"Name: kerning-pair-threshold
Value: auto | <length>"
Should "<length>" be "<'font-size'>"?
"This property controls the font size threshold, above which
pair kerning would be active (if enabled)."
So if the font size equals the threshold, pair kerning is
inactive. Was this really the intent?
"<length>
<font-size> threshold."
Change the prose to "Pair kerning is activated when the computed
font size exceeds the specified <length>." Or is it the actual
font size that is compared?
9. Text decoration
Why do the property names start with "text-"? Is there some
danger that, say, "underline-style" would clash with a property
name from another module?
The "Applies to" fields in the property definitions should read
"all elements with and generated content with textual content",
yes?
9.1. Introduction
"Until CSS2, the only text decorations available were available
through the 'text-decoration' property exposing itself various
effects underline, overline, line-through, etc... and the
text-shadows property."
Change to "In CSS1 and in CSS2, the 'text-decoration' property
controls text decorations: underline, overline, line-through,
and blinking. CSS2 adds text shadows, which the 'text-shadow'
property controls."
"However the text-decoration property has some limitations
stemming from its syntax, which allows for multiple
'text-decoration' formatting effects to be specified at the same
time but it precludes finer control over each of those
formatting effects. More specifically, it offers no way to
control the color or line style of the underline, overline or
line-through."
Change to "However, the 'text-decoration' property has
limitations stemming from its syntax, precluding fine control
over each of those formatting effects. Specifically, it offers
no way to control the color or line style of the underline,
overline or line-through."
"The 'text-decoration' property itself is now a shorthand
property for all these new properties, but it only takes its own
set of values which affects all the other text decoration
properties."
Change to "The 'text-decoration' property itself is now a
shorthand property for all these new properties. However, the
'text-decoration' values are not composites built from the
values of constituent properties. Rather, 'text-decoration'
values come from a small set specific to the 'text-decoration'
shorthand property."
"If an element is empty or is a replaced element (e.g., the IMG
element in XHTML), user agents must ignore these properties.
Text content also excludes white space characters that are
collapsed during the white space processing."
There is no 'IMG' element type in XHTML: there is instead the
lower-case 'img'. Change the sentence to "If an element is empty
or is a replaced element (e.g., img elements in XHTML), user
agents must refrain from rendering text decorations on the
element. In deciding whether an element is empty, user agents
must ignore white-space characters that are collapsed during the
white-space processing."
"All these text decoration properties are not inherited, but
descendant boxes should be formatted with the same decoration
(e.g., they should all be underlined). The color of decorations
should remain the same even if descendant elements have
different 'color' values."
Why are these suggestions ("should") and not requirements
("must")?
"Finally, user agents may chose either to average thickness and
positions of the 'line' text-decorations based on the children
text size and baselines, or to ignore the text of children."
Change to "In determining the position of and thickness of text
decoration lines, user agents may consider the font sizes of and
dominant baselines of children. Of course, user agents may
ignore children in these determinations."
"Typically the underline superscript text segments are averaged,
while the subscript segments are not."
Change to "User agents typically consider superscript segments
but ignore subscript segments."
9.2. Text decoration style: the 'text-underline-style',
'text-line-through-style' and 'text-overline-style' properties
"thick
single line using a greater line width."
This style is inadvisable. When we add properties to control
text decoration line width, this style will be redundant. Let's
approach width control in a thorough and proper way.
I propose the properties defined as follows.
Names: text-underline-width,
text-line-through-width,
text-overline-width
Value: auto | normal | <number>
| <length>| <percentage>
| thin | medium | thick
Initial: auto
Applies to: all elements with and generated
content with textual content
Inherited: no
Percentages: computed 'font-size'
Media: visual
Computed value: <length>
Possible values:
auto
The user agent may use any algorithm to determine the text
decoration width. Implementors are encouraged to consider
the font sizes and baselines of all affected text. The text
decoration style should affect the resulting value (the
style 'double', for instance, would typically produce a
width greater than the style 'solid' produces)..
normal
The text decoration width is the normal text decoration width
for the nominal font. If no font characteristic exist for
the width of the text decoration in question, the user agent
should proceed as though 'auto' were specified.
<number>
The text decoration width is the product of the <number> and
the computed 'font-size'. If inherited, the inherited value
is the <number> rather than the computed <length>.
<length>
The text decoration width is the <length>.
<percentage>
The text decoration width is the product of the <percentage>
and the computed 'font-size'.
thin
This value is equivalent to a <number> value kept by the user
agent. The <number> must be constant throughout a given view
of a document and should yield a thin line.
medium
This value is equivalent to a <number> value kept by the user
agent. The <number> must be constant throughout a given view
of a document, must be greater than or equal to the 'thin'
<number> and should yield a medium line.
thick
This value is equivalent to a <number> value kept by the user
agent. The <number> must be constant throughout a given view
of a document, must be greater than or equal to the 'medium'
<number> and should yield a thick line.
9.3. Text decoration color: the 'text-underline-color',
'text-line-through-color' and 'text-overline-color' properties
"Computed value: specified value (except for initial and
inherit)"
Why would 'auto' not compute to a <color>?
"The color of the underline is determined by the 'color'
property."
Change "underline" to "text decoration".
9.4. Text decoration mode: the 'text-underline-mode',
'text-line-through-mode' and 'text-overline-mode' properties
Is white-space the same for these properties as for other CSS
constructs? If so, somebody using, for example, U+3000
(ideographic space) is going to be sorely surprised.
The properties defined as follows, inspired by certain comments
on www-style [UNDERLINE-SKIP] [THAI-UNDERLINE] include and
exceed the functionality of the text decoration mode properties.
Names: text-underline-skip,
text-line-through-skip,
text-overline-skip
Value: none | [ white-space || [ strokes <length>? ] ]
Initial: none
Applies to: all elements with and generated
content with textual content
Inherited: no
Percentages: N/A
Media: visual
Computed value: specified value (except for initial and inherit)
Possible values:
none
The text decoration is continuous.
white-space
The text decoration skips white-space.
strokes
The text decoration skips glyph strokes that cross it. If no
<length> follows, the user agent may use any algorithm to
determine the clearance to maintain around the strokes.
<length>
The <length>, which must be non-negative, indicates the
clearance to maintain around glyph strokes. User agents may
impose a minimum and a maximum on actual values.
9.5. Other text decoration simple properties:
'text-underline-position' and 'text-blink'
I propose the properties defined as follows.
Names: text-underline-position,
text-line-through-position,
text-overline-position
Value: auto | normal |
<baseline>? [ <number> | <length>
| <percentage> ]
| <baseline>
Initial: auto
Applies to: all elements with and generated
content with textual content
Inherited: no
Percentages: computed 'font-size'
Media: visual
Computed value: <length>
The computed position specifies an offset from the
text-after-edge. Positive values are toward the text-before-edge
while negative values are away from the text-before-edge. A text
decoration is positioned so that its middle aligns with the
respective position.
Possible values:
auto
The user agent may use any algorithm to determine the text
decoration position. Implementors are encouraged to consider
the font sizes and baselines of all affected text, as well
as the text decoration width. The text decoration style may
affect the resulting value.
normal
The text decoration position is the normal text decoration
position for the nominal font. If no font characteristic
exists for the position of the text decoration in question,
the user agent should proceed as though 'auto' were
specified.
<baseline>
The baseline identifier specifies a baseline position. If a
term follows the baseline identifier, the baseline position
is the position from which the following term specifies an
offset. If no term follows, the computed baseline position
is the text decoration position.
<length>
If a <baseline> was specified, the text decoration position
is the sum of the <baseline> position for the nominal font
and the <length>. If no <baseline> was specified, the text
decoration position is the <length>.
<percentage>
If a <baseline> was specified, the text decoration position
is the sum of the <baseline> position for the nominal font
and the product of the <percentage> and the computed
'font-size'. If no <baseline> was specified, the text
decoration position is the product of the <percentage> and
the computed 'font-size'.
<number>
If a <baseline> was specified, the text decoration position
is the sum of the <baseline> position for the nominal font
and the product of the <number> and the computed
'font-size'. If no <baseline> was specified, the text
decoration position is the product of the <number> and the
computed 'font-size'. If inherited, the inherited value is
the specified value.
"Name: text-blink"
..
"Inherited: no"
Why is this property not inherited? The 'text-blink' property
is substantially different from the other text decoration
properties. That the other properties are not inherited is a
poor reason.
"blink
blink"
Change the description to "Produces blinking text, which
alternates between visible and invisible states at rates
determined by the user agent."
"Conforming CSS2 user agents are not required to support this
value."
That's great, but what about CSS3 user agents?
9.6. Text decoration shorthand properties: 'text-underline',
'text-line-through', 'text-overline-mode' and 'text-decoration'
"The 'text-underline' property is the shorthand for
'text-underline-style', 'text-underline-color',
'text-underline-mode' and 'text-underline-position'."
Add "Any constituent properties not explicitly assigned values
in a 'text-underline' declaration take their respective initial
values."
"The 'line-through' property is the shorthand for
'text-line-through-style', 'text-line-through-color' and
'text-line-through-mode'."
Presuming the status quo, change "'line-through'" to
"'text-line-through'". Add "Any constituent properties not
explicitly assigned values in a 'text-line-through' declaration
take their respective initial values."
"This 'text-overline' property is the shorthand for
'text-overline-style', 'text-overline-color' and
'text-overline-mode'."
Add "Any constituent properties not explicitly assigned values
in a 'text-underline' declaration take their respective initial
values."
"The 'text-decoration' shorthand sets the properties" ... "to
their default values"
Change "default" to "initial".
"All the sub-properties maintain their defaults."
Change "sub-properties" to "constituent properties". Change
"defaults" to "initial values".
9.7. Text shadows: the 'text-shadow' property
I thought, following comments that Chris Lilly made
[TEXT-SHADOW] [BOX-SHADOW], that 'text-shadow' would be
deprecated or eliminated in favor of the far more flexible
'filter' property (with its excellent SVG pedigree). I favor its
elimination. Has the Working Group considered Chris's comments?
"Value: none | [<color> || <length> <length> <length>? ,]*
[<color> || <length> <length> <length>?]"
This grammar is faulty in its placement of the comma. Observe
that it permits the following declaration.
text-shadow: red blue;
Observe that the grammar forbids the following declaration.
text-shadow: 0.1em 0.1em red, -1em -1em blue;
Change the grammar as follows.
"Value: none | [<shadow> ,]* <shadow>"
Define <shadow> as follows.
"[<color> || <length> <length> <length>?]"
Incidentally, the 'box-shadow' property definition can use
<shadow>.
"Inherited: no"
Why is 'text-shadow' not inherited?
"Each shadow effect must specify a shadow offset"
If this is true then the value grammar is faultier still. Change
the definition of <shadow> as follows.
"[<color> <length> <length> <length>? | <length> <length>
<length>? <color>?]"
"A shadow offset is specified with two <length> values that
indicate the distance from the text. The first length value
specifies the horizontal distance to the right of the text. A
negative horizontal length value places the shadow to the left
of the text. The second length value specifies the vertical
distance below the text. A negative vertical length value places
the shadow above the text."
Change "values" to "terms" and the four occurrences of "value"
to "term". Change the last four occurrences of "length" to
"<length>".
"The exact algorithm for computing the blur effect is not
specified."
Add "If no blur radius is specified, the treatment is as if a
blur radius of zero were specified and the shadow has the same
size and shape as the glyphs that cast it."
"Such user agents should consider declarations that specify the
optional third parameter to be parser errors"
Change "optional third parameter" to "blur radius".
"A color value may optionally be specified before or after the
length values of the shadow effect. The color value will be used
as the basis for the shadow effect."
Change both occurrences of "value" to "term" and "values" to
"terms".
10.1. What is document grid?
"The grid behavior can be set on the line progression, on the
block progression or both."
Line progression is the same as block progression, as lines are
but a special type of block box. Change the sentence to "The
grid behavior can be set on the inline-progression-dimension, on
the block-progression-dimension or both."
"'line-height' of the block element set to the desired grid
block progression dimension value"
Eliminate "dimension".
"'text-height' which defines the inline box block progression
dimension. Depending on the content size, one or a multiple of
'line-height' will be necessary to accommodate a given inline
box content."
Change "inline box block progression dimension" to "block
progression value for inline boxes". Eliminate the last
occurrence of "content".
"The grid on the line progression is obtained by altering the
character advance width (or line progression) of inline
elements."
Change the first occurrence of "line progression" to
"inline-progression-dimension". Change "character" to "glyph".
Change the second occurrence of "line progression" to "inline
progression value".
"Adding extra space between each characters by using the
'letter-spacing' property."
Change "each characters" to "grapheme clusters".
"Giving a fixed advance width to ideograph characters only.
Other characters are spaced normally."
Change "ideograph characters" to "ideographic grapheme
clusters". Change "Other characters" to "other grapheme
clusters".
"Giving a fixed advance width to all characters, excepted
connected glyphs (like Arabic)."
Change "characters" to "grapheme clusters".
10.2. Line grid mode: the 'line-grid-mode' property
"ideograph"
"This mode applies in the following ways to the various
categories of character:"
"each wide-cell glyph (as well as narrow-cell kana) that can fit
within a single grid space is
rendered in the horizontal center of the grid space. The width
of the grid space is determined by the 'line-grid-progression'
setting."
"consecutive narrow-cell and connected glyphs are treated as a
single strip, which is then placed in the center of the smallest
number of grid spaces necessary for it to fit in. If a line
break occurs within such a strip, the strip is treated as two
separate strips whose individual placement follows the same
rules as those for a single strip."
"non-breakable objects (e.g. images) and wide-cell glyphs that
for some reason are wider than a single grid space, are each
centered within the smallest number of grid cells necessary for
it to fit in."
Change to the following.
"ideograph"
"Content is divided into units that we will call strips. Each
strip is horizontally centered within the smallest number of
grid spaces that can contain the strip."
"Each grapheme cluster with a wide base character is a strip.
Each grapheme cluster with a narrow kana character as its base
character is a strip. Each non-breakable object (e.g. an image)
is a strip."
"For other grapheme clusters the case is more complicated. Line
break characters form the boundaries of provisional strips. The
user agent attempts to fit each provisional strip in the grid
spaces remaining on the current line. If the current provisional
strip fits on the current line, the user agent proceeds to the
next line and the next provisional strip. If the current strip
(s1) does not fit in the grid spaces remaining on the current
line, the user agent finds the last line break opportunity in
s1, transfers all content after the line break opportunity to a
new strip (s2), and tries again to fit the current strip. The
user agent repeatedly transfers content in this manner from s1
to s2 until s1 either fits on the current line or has no more
line break opportunities. If the current line is not blank and
s1 does not fit in the grid spaces remaining on the current line
and s1 has no line break opportunities, the user agent combines
s1 and s2 into a single strip as they were originally, proceeds
to the next line and tries as before to fit the strip. If the
current line is blank or s1 fits in the grid spaces remaining on
the current line, the user agent proceeds to the next line and
uses s2 as the current strip."
"If a line break opportunity cannot be found in a text run going
over the line boundary, then that text run will be pushed down
to the next line and the last part of the previous line will be
left blank."
Eliminate this passage if adopting the change above.
"all"
"This type of grid can be used to achieve mono-spaced layout.
The layout rules are simple: all non-connected glyphs are
treated as equal, that is every glyph is centered within a
single grid space by default. Runs of connected glyphs are
treated as strips the same way as in 'ideograph' grid.
Justification or any other character-width changing behaviors
are disabled for the block element."
Change to the following.
"all"
"This type of grid can be used to achieve mono-spaced layout. As
with 'ideograph', content is divided into strips and each strip
is horizontally centered within the smallest number of grid
spaces that can contain the strip. The rules for determining
strips differ."
"Each grapheme cluster with a non-joining base character is a
strip. Each non-breakable object (e.g. an image) is a strip.
Each run of grapheme clusters with joining base characters that
join to each other is a strip."
10.3. Line grid progression: the 'line-grid-progression'
property
"Value: text-height | line-height | <length>"
"Initial: normal"
That initial value is not defined.
"This property affects the line progression of characters
subject to the fixed advance width as determined by the
'line-grid-mode' property."
Change to "This property determines the inline progression
dimension of grid spaces." Or, if not adopting that suggestion,
change "characters subject" to "characters which are subject".
This latter suggestion eliminates the possibility of the
misreading of the sentence as equivalent to "This property,
subject to the fixed advance width as determined by the
'line-grid-mode' property, affects the line progression of
characters."
"The computed value of the block element text-height is used."
What is 'text-height'?
"div.section1 { line-grid-progression: .5in }"
"would make each glyph in a horizontally laid out part of a
document rendered within 0.5 inch of horizontal space"
Change the prose to "The rule set above would make grid spaces
0.5 inches long in a div element in the section1 class. If the
element has horizontal flow, it would look like the following
(without the grid lines, which are shown for clarity)."
"Enlarged character grid applied to mixed text in horizontal
layout"
Eliminate "character".
"If the section's layout flow is vertical, then 0.5in becomes
the vertical distance between consecutive characters in a
column"
Change to "If the element has vertical flow, then 0.5 inches is
the vertical measure of each grid space".
"Enlarged character grid applied to mixed text in
vertical-ideographic layout"
Eliminate "character".
11.1. Capitalization: the 'text-transform' property
"The case mapping rules for the character repertoire specified
by the Unicode Standard 3.0 can be found on the Unicode
Consortium web site: http://www.unicode.org."
Proper references are needed and should be to the particular
data files,
<http://www.unicode.org/Public/UNIDATA/UnicodeData.txt> and
<http://www.unicode.org/Public/UNIDATA/SpecialCasing.txt>.
11.2. Hanging punctuation: the 'hanging-punctuation' property
"This property determines whether a punctuation mark, if one is
present, may be placed outside the content area in the padding
or margin area, at the start or at the end of a full line of
text."
Eliminate "in the padding or margin area,". After all, the
padding and margin in question may be of zero width.
"It is the responsibility of the style writer to create
meaningful padding and margin areas to allow effective rendering
of the punctuation."
If the hanging punctuation would be placed outside the margin
area, is the punctuation still rendered?
"A leading punctuation, if present, may overhang at the start of
the content area. It is placed in the padding or margin area."
"An ending punctuation, if present, may overhang at the end of
the content area. It is placed in the padding or margin area."
Reiterating the question above, what happens if the padding and
margin are zero?
"No hanging punctuation allowed (the punctuation and the
character preceding it shown in blue for clarity)"
Change to "No hanging punctuation allowed (the punctuation mark
and the glyph preceding it shown in blue and the right content
edge shown with dashed line for clarity)".
"Hanging punctuation appearing in the end of line padding area
(the punctuation and the character preceding it shown in blue
for clarity)"
Change to "Punctuation hanging at the end of line (the
punctuation and the glyph preceding it shown and the right
content edge shown with dashed line in blue for clarity)".
"Note: User agents should follow the convention of the scripts
for trimming either only the first lines or all lines. For
example, in Roman text, only a punctuation appearing at the
starting point of the first line may be placed outside the
content area."
I believe that this passage is too restrictive. In Latin text,
it is acceptable that punctuation overhang at the end of the
last line. Perhaps a change to the following will be
sufficiently correct.
"Note: User agents should follow script-specific and
language-specific conventions about which lines allow which
hanging punctuation. For example, in Latin text, a leading
punctuation mark may overhang only on the first line and a
trailing punctuation mark may overhang only on the last line."
11.3. Combining text: the 'text-combine' property'
'This property controls the creation of composite characters
(a.k.a. "kumimoji") or lines (a.k.a. "warichu").'
Change "characters" to "grapheme clusters".
"No composite characters are created."
Change to "Glyphs arrange normally."
"Combines glyphs to fit within the space of a single wide-cell
glyph, by reducing them in size and stacking them next to and/or
on top of each other. This effect is commonly used in Asian
typography."
Writing "East Asian" instead of "Asian" would be more accurate.
"No more than 5 glyphs can be combined at a time."
Change to "No more than five grapheme clusters can combine into
a unit."
"If the text to be combined results in a single glyph, no
special combination effect occurs."
Change to "If the text to be combined has only a single grapheme
cluster, no special combination effect occurs."
"The following texts shows the arrangement for 2, 3, 4 and 5
characters"
Change to "The following texts shows the arrangement for two,
three, four and five grapheme clusters."
"The following mark-up:"
"span.kumimoji { text-combine: letters }"
That is not markup but a styling rule.
"could make the following 4 characters appear as one (shown in
blue for clarity):"
The example calls for an overhaul. I suggest the following.
"Assume the following document."
"<doc>The word kumimoji, <span
class="kumimoji">くみもじ</span>, is
Japanese.</doc>"
"Assume the following rule set."
"span.kumimoji { text-combine: none; }"
"The document would look like the following:"
[image with English text and hiragana]
[caption] "Mixed text layed out normally"
"Now assume the following rule set."
"span.kumimoji { text-combine: letters; }"
"The document would look like the following:"
[image with English text and with kumimoji of hiragana]
[caption] "Mixed text with kumimoji applied to four characters"
"The combined lines appear inline with the surrounding text."
This is false when the warichu element is a block-level element,
a situation that the 'Applies to' field allows. Correct the part
which is incorrect.
"The combination may be broken across several lines, each line
box representing its own logical subset of the combination."
This is unclear. Please restate.
"The following mark-up:"
"span.warichu { text-combine: lines }"
That is not markup but a styling rule.
"would make the enclosed text look like the following (shown in
blue for clarity):"
[image]
I suggest an example like the one suggested above.
12. Properties index
"text-shadow" ... [Inherited] "no (see prose)"
There is no prose in the property description that discusses
inheritance.
14. Profiles
"'text-align'" [Values] "left | right | center | justify"
[Initial] "start"
Change "start" to "depends on user agent and writing direction".
(CSS1 writes "UA specific".)
"'text-align'" [Values] "left | right | center | justify |
<string> | inherit" [Initial] "start"
Change "start" to "depends on user agent and writing direction",
as CSS2 writes.
"'text-decoration', in addition to its CSS2 behavior, becomes a
shorthand property for the following properties:
'text-line-through', 'text-overline', 'text-underline'"
The enumerated properties are themselves shorthand properties,
so 'text-decoration' actually sets 'text-line-through-color',
'text-line-through-mode', 'text-line-through-style',
'text-overline-color', 'text-overline-mode',
'text-overline-style', 'text-underline-color',
'text-underline-mode', 'text-underline-style', and
'text-underline-position'.
15. Glossary
"Hangul"
"Subset of the Korean writing system."
That is a spare description. The following is a start on
something at least a bit more informative. "Subset of the Korean
writing system in which a few letters combine to form syllables.
Visually, each written syllable occupies the same amount of
space."
"Kashida"
"Arabic elongation character."
Change the description to "Any of a number of elongation glyphs
that sit on the alphabetic baseline; used in Arabic and Syriac.
Also a character (U+0640, "Arabic tatweel") used to indicate the
glyph."
"Subset of the Japanese writing system consisting of phonetic
characters used to represent Roman words."
Change "Roman" to "Western".
"Kumimoji"
"Composite character consisting of up to 5 characters that are
reduced in size and combined to fit within the space of a single
character."
Change the description to "Composition of two to five grapheme
clusters that are reduced in size an arranged to fit within the
space of a single wide-cell glyph."
"Logograph, Logogram"
"Character in the Chinese (or East Asian in general) writing
system that represents an entire word."
Change the description to "Character or glyph that represents an
entire word. Common in the Han script used in China, Japan, and
Korea."
Appendix A: Vertical Layout Effect on CSS Properties
"Underline appears on the left side of a vertical column and
overline appears on the right"
This is false on two counts: {writing mode: tb-lr} and
{text-underline-position: before-edge}.
Normative references
Why is [ISO15924] not listed as a normative reference? It
determines the valid values for 'text-script'.
Why is [UAX-11] not listed as a normative reference? It
determines the behavior of "glyph-orientation-vertical: auto".
Why is [XML1.0] not listed as a normative reference? It
determines which characters count as whitespace.
Other references
"[HTML40]"
..
"[HTML401]"
Seeing these references together, I have to wonder why HTML 4.01
alone is not enough. The sole reference to HTML 4.0 is in
section 11.1
(<http:/www.w3.org/TR/2002/WD-css3-text-20021024/text.html>):
"See HTML [HTML40] for ways to find the language of an HTML
element."
[UNDERLINE-SKIP]
Christoph P=E4per.
"Questions on CSS3 Module: Text - line".
21 October 2002.
<mid:003201c27944$73490ee0$3ef4ae8b@heim4.tuclausthal.de> /
<http://lists.w3.org/Archives/Public/www-style/2002Oct/0074.html>.
[THAI-UNDERLINE]
Arthit Suriyawongkul.
"will CSS3 support styles of underline-skipping (for char with tail) ?"
8 November 2002.
<mid:3DCB6112.DC453267@Sun.COM> /
<http://lists.w3.org/Archives/Public/www-style/2002Nov/0018.html>.
[TEXT-SHADOW]
Chris Lilley
"Re: box-shadow)ext-shadow', 'box-shadow', and 'font-effect' (was Re: Proposal: box-shadow)"
5 October 2001.
<mid:3BBCECCF.47AADF47@w3.org> /
<http://lists.w3.org/Archives/Public/www-style/2001Oct/0038.html>.
[BOX-SHADOW]
Chris Lilley.
"Re: Proposal: box-shadow"
2 October 2001.
<mid:3BBA0E49.858D4174@w3.org> /
<http://lists.w3.org/Archives/Public/www-style/2001Oct/0019.html>.
Received on Friday, 31 January 2003 00:04:58 UTC