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

Also sprach Peter Moulder:

 > "may also used" should presumably be "may also be used".  

Yes

 > 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 ?

The text intended to say that only the 'print' media type was
affected, conformance-wise. I've reformulated this in the "conformace"
section.

 > §6.2, Example XXII: Not sure what "oldest" means.

In the tree structure of elements, the root element is the oldest. A
parent element is older than its children, and sibling elements also
have a relative age. 

 > The text says "In this example, ... due to the 'right' keyword", but the
 > example has only a 'left' keyword.

Good catch. Fixed.

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

The example that follows the text illustrates what it means; when you
have both footnotes and bottom-floating content, the footnotes will
appear below the floating element. I've changed the text to:

   The position of the footnote area is give priority over floating content. 

Is that better?

 > "by the footnote elements elements" should probably be "by the footnote elements".

Indeed

 > 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.  

Done

 > Less compellingly, consider moving border-length to
 > after border, and (less importantly again) background properties to after (say)
 > margin.

Done

 > §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'.

Right

 > 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?

Yes, it's troublesome. Perhaps it's better to use explicit names. For example:

  border-length: 30%;
  border-align: left

This seems quite useful, also when making the commonly used small
horizontal bars:

      Hello, world!!
           ---
      There you are.

Which could be achived with:

  border-length: 30%;
  border-align: center;

The vertical issue and the the possible combinatorial explosion of
properties requires some thinking, though. Possibly, it can be avoided
by saying that 'border-length' applies to all sides and to use
'start', 'center', 'end' which are meaningful both in vertical and
horizontal contexts.

 > §6.8 'Laying out footnotes', first item: consider changing "page" to "page or
 > column".

I disagree. I think it's acceptable to put all notes in the first
column even when footnote calls appear in the second 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.

Document order it is; I've removed the issue.

 > §9.1 'Hyphenate properties', hyphens property, none: What does "word" mean in
 > this context ?  E.g. is 'break-point' one word or two? 

CSS has a long-standing tradition of using 'word', but not defining
it. It's simply too hard to define for all scripts and languages.

 > What about '/' or zero-width space?  

Unclear. UAs treat them differently today.

Prince has a property to influence this:

  http://www.princexml.com/doc/6.0/properties/prince-linebreak-magic/

 > What sort of "characters inside the word" are we talking
 > about other than ­ ?

There are a few other candidates:

  The hyphen character ‐
  The hyphenation point ‧

 > 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>'.

Yes

 > 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.

I believe effect we're after is visual, rather than logical. That is,
we're trying to avoid the pig's bristles. However, I think the spec
should remain silent on this.

 > 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 ?

I not an expert on this. Anyone?

 > §10.1 'super-decimal': "replaces the used of" is wrong.

Indeed

 > §11 'Character substitution': I don't think this belongs in CSS.

It's borderline. But, very convenient when you need it. Just like
'text-transform' is. Here's a document that uses it:

  http://www.princexml.com/samples/

(the first document in the list)

 > 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.

Yes. However, if you have good markup, you can exclude these case.

 > 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.

Yes. I should probably use a less charged example. 

 > In absence of more compelling examples, this sort of
 > substitution belongs in editors, not in renderers.

The problem is that the person who formats a document doesn't always
have control of the editor.

 > 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.)

Noted

 > §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'".

Good suggestion.

 > 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.)

I think it's a good proposal.

 > (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.

There are many interactions. I'll leave it where it is for now.

 > §14 'Advanced multi-column layout': Consider changing "separated CSS3" to
 > "separate CSS3".

Right

 > §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.

Yes

 > 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.

I've noted it as an issue. 

 > §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.

I've added a note that we need a color space profile for cmyk and
links to the specs you mention. They do not include the 'cmyk()'
syntax, though, which I think is valuable.

 > 'Other references': Consider linking to the most current version in each case.

Yes

Thanks for a good review!

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome

Received on Tuesday, 7 August 2007 09:26:32 UTC