[css3-gcpm] Miscellaneous comments on WD-css3-gcpm-20070504

“may also used” should presumably be “may also be used”.  Also, I don't
understand the next sentence, i.e. I don't know what it means by “is
only concerned with” -- or “may [be] used with” for that matter: does
“may be used with” mean that conformant UA's should support the
functionality with other media, or just that hyphenation etc. is often
used in other media but this specification doesn't provide for doing so
from within CSS ?


§6.2, Example XXII: Not sure what “oldest” means.

The text says “In this example, ... due to the ‘right’ keyword”, but the
example has only a ‘left’ keyword.

Don't know what “is considered to come before” means.  Change to “is given
precedence over” if that is the intended meaning.

“by the footnote elements elements” should probably be “by the footnote elements”.

Consider re-ordering the list of “properties [that] apply to the footnote
area”: swap ‘border’ and ‘padding’, so that content, padding, border, margin
form a logical sequence.  Less compellingly, consider moving border-length to
after border, and (less importantly again) background properties to after (say)
margin.


§6.3 border-length:

The first paragraph of text mentions ‘border-width’, which doesn't occur
anywhere else in the spec.  Should probably be ‘border-length’.

The Percentages field refers to the length of horizontal border, whereas the
main text says that it controls “borders in the inline direction of the
footnote area”.  If this is deliberate, then please confirm so by adding ‘(even
if the inline direction of the footnote area is vertical)’ to the Percentages
field text.  (Otherwise, correct it of course, e.g. adding ‘(or vertical
border if the inline direction of the footnote area is vertical)’.)

Similarly, that paragraph of text mentions “horizontal borders”, which might
also be a mistake.

How is “the inline direction of the text” determined in the case of bidi or
when there are multiple paragraphs where some are ltr and others rtl, or when
the direction property conflicts with the order of the script used in the text?


§6.8 ‘Laying out footnotes’, first item: consider changing “page” to “page or
column”.

Second item, regarding the red text, some reasons in support of document
order are: (i) assists location of the footnote in the common case that
the footnote markers are counters, at least in absence of a counter-reset
call.  Even in the case of a counter-reset call (e.g. the previous page
didn't have room for its last footnote), I think the footnotes belong in
footnote-counter-ignoring-resets order, which [it is claimed in the red
text, I haven't checked] is the same as document order.  Also, humans
(let alone computer programs) aren't always sure what "visual order"
actually means in the case that one call is slightly below but to the
left of another call (in an all-ltr page), or when mixing different
inline-progression directions, or when using columns.


§9.1 ‘Hyphenate properties’, hyphens property, none: What does “word” mean in
this context ?  E.g. is ‘break-point’ one word or two?  What about ‘/’ or
zero-width space?  What sort of “characters inside the word” are we talking
about other than ­ ?


hyphenate-resource property: Value says ‘none | <uri>’, but the text talks
about a comma-separated list.  Is ‘none’ a valid item in the list?  I'd guess
that this value should be written as ‘none | [<uri> , ]* <uri>’.


hyphenate-lines property: does a “hyphenated line” include the case of explicit
hyphens in the text, such as if ‘super-scripted’ gets broken as
‘super-//scripted’ ?  What about other lines ending with a character of the
unicode dash category?  What about the case when, due to bidi, the (logical)
end of the line lies at neither (visual) end of the line?  This is a matter of
whether we're trying to avoid "pig's bristles" (the appearance of many dashes
at an end of a line) or whether we're trying to avoid too many successive bad
breaks.


hyphenate-character property: Would be good to give (a reference to) more
guidance to user-agent developers as to how to choose an appropriate value.
U+058A's name is ‘Armenian hyphen’, but even if it's used just like a European
hyphen, that still leaves open the question of exactly when to use it (e.g. if
only one of the surrounding characters is in the Armenian script, or if some
non-alphabetic characters are involved, and whether one is required to skip
over combining marks).

Is there a more compelling use-case for the example, such as explicitly
specifying the hyphen character in cases of doubt, like an English document
containing an Armenian place name ?


§10.1 ‘super-decimal’: “replaces the used of” is wrong.


§11 ‘Character substitution’: I don't think this belongs in CSS.  The example
given is wrong for the case that the ASCII apostrophe character is being used
as an opening single quote or as a prime/foot/minute sign or as an ASCII
apostrophe character for description of a computer language or as one half of a
double-quote or double-prime (inch/second) sign.  Example XLI will sometimes
give wrong results because the Soviet Union had the same boundaries as current
Russia, and in any case the change will be wrong in the case of sentences
specifically talking about naming or that describe a historical context; and
blind textual substitution isn't enough to adapt more generally to the changed
political realities.  In absence of more compelling examples, this sort of
substitution belongs in editors, not in renderers.  There are lots of other
yet-unimplemented CSS properties that are more valuable to implement than this
one.

(If you must keep this facility, then note that it's under-specified for the
case when “from” strings overlap each other, or when the “from” string is
empty, or when a substitution creates an occurrence of the “from”
string.  Each of these should be noted, even if only to say explicitly
that its behaviour is unspecified.)


§13 ‘Page floats’: The text and examples are inconsistent as to whether ‘next’
counts as a vertical keyword or not: rule 4 says that at least one horizontal
or vertical keyword must appear, but the examples say that ‘next page’ is
valid, suggesting that ‘next’ counts as vertical; yet we're told that “only one
vertical keyword (‘top’, ‘bottom’) can appear in a value”, and yet ‘top next
page’ is a valid value.

I suggest changing “at lease one horizontal or vertical keyword must appear” to
add “or the keyword ‘next’”.


The rule that keywords can appear in any order implies that the misleading/
confusing string ‘page bottom next left’ is a valid value.  Restricting the
order both makes parsing easier and forbids that confusing value and simplifies
the list of validity rules all at the same time:

  [ top | bottom ]? [ left | right | inside | outside ]? next? page

with the only rule remaining to be stated in text being that

  ‘page’ by itself is not a valid value (i.e. at least one of top, bottom,
  left, right, inside, outside or next must also be specified).

(Adopting this change would also involve changing the examples, btw.)

(Note that ‘float: top left page’ and ‘float: left top page’ both receive the
same error handling by conformant CSS2.1 UAs, btw, namely to ignore that
declaration.)

Consider merging with §15 given the interaction with unless-room.


§14 ‘Advanced multi-column layout’: Consider changing “separated CSS3” to
“separate CSS3”.


§15 ‘Conditional content’:

“Two new value” should be “... values”.  Also, I don't think I'd describe
‘unless-room’ as a value but rather as a keyword for use within the value of
the float property.

It isn't clear whether ‘hide’ can be used in conjunction with ‘page’ in the
same declaration (‘left page hide unless-room’); more generally, neither the
hide description nor the unless-room description specify what other keywords
are allowed in the same declaration.


§18 ‘CMYK colors’: The appearance of cmyk(0.5, 0.1, 0.0, 0.2) will differ from
one printer to another.  Printers often have a different number of inks than 4.
Some of the SVG 1.2 working drafts have tried to overcome these issues (search
for icc-color, device-color, deviceColor).  Consider removing §18, perhaps
adding a reference to css3-color and/or SVGPrint.


‘Other references’: Consider linking to the most current version in each case.


pjrm.

Received on Thursday, 2 August 2007 10:55:50 UTC