Re: [css3-gcpm] Comments

Also sprach Michael Day:

 > > http://www.w3.org/TR/2007/WD-css3-gcpm-20070504
 > 
 > Comments:

Thanks for your review, this is very helpful.

 >   - string-set introduces some new keywords: self, before, after, 
 > first-letter. Currently, Prince accepts anything that the content 
 > property would accept as an argument to string-set. This includes things 
 > that the spec doesn't allow, such as target-counter() and leader().

Makes sense.

 >   - In some ways, it seems better to introduce a first-letter() function 
 > than to add first-letter keywords to everything else. CSS doesn't 
 > usually do things this way, though.

Whether to use "first-letter()" or "first-letter" is independent of
where the value is accepted. There was a preference for dropping the
parenthesis in the WG.

 >   - Prince does not support last-except on the string() function.

Right. It's a solution to the problem that has been haunting us -- how
to avoid the header on the first page. I know it can be achived in
Prince by using another trick, but doesn't the spec propose a better solution?

 >   - Can the element() function be combined with other values in the 
 > content property? For example, content: "Hello" element(foo) "world"?

No, not in my mind. Should it? It's more powerful, but potentially
more more messy, no?

 >   - Prince does not support the dotted, solid and space keywords for 
 > leader. Does treating solid as underscore really produce good results?

So, we should only support the string values? That's fine as long as
the font has the characters, I presume.

I believe that using underscore characters generally produces a solid
line, but there may be fonts which don't. 

 >   - The section on the footnote area refers to the "default style 
 > sheet", however this sounds meaningless, as CSS has no such thing, only 
 > document languages can have default style sheets. You could just say 
 > that float defaults to "bottom page" for @footnote, just like text-align 
 > has different default values for @top-left and @top-right.

Agreed, this may be better solution.

 >   - @footnote { float: bottom left column } looks quite scary to 
 > implement, even though it does make sense for authors. We'll see.
 > 
 >   - In 6.3 border-length, it refers to the name as border-width.	

Fixed, thanks.

 >   - 6.6 counting footnotes refers to putting counter-increment inside a 
 > @footnote rule. It's not clear whether this is a @page { @footnote {}} 
 > rule or a different one at the top level. Also, Prince increments the 
 > footnote counter for footnotes automatically.

So, again, you're saying that we should not rely on the default style
sheet. This seems fair enough. If we move over to an automatic counter
increments, would you allow a style sheet to override it? E.g., should
this work:

  @footnote {
    counter-increment: footnote 2;
  }

BTW, @footnote should always be inside @page {} -- this has now been clarified.

 >   - The second example in 6.6 refers to reset-counter instead of 
 > counter-reset.

oops-thanks 

(Or, should that be thanks-oops? :)

 >   - "If there is a footnote call on a page, the footnote area may not be 
 > empty, unless its 'max-height' is too small." I think that it is easy to 
 > break this rule, eg. by making a very very tall line of text that has a 
 > footnote call on it and takes up the whole page, leaving no space for 
 > the footnote at the bottom. We ran into this when we added footnotes to 
 > Prince, and we just move the footnote to the next page in this case.

This makes sense. I suggest we drop the fourth rule.

 >   - "Should there be a mechanism to create new areas like 
 > footnote/sidenote, or are two "magic" area enough?" One could imagine 
 > adding one extra keyword: @area footnote { ... }; however, it can be 
 > tricky to balance genericity with support for all the footnote details.

Exactly. I think I'll leave it as is unless someone asks for more.

 >   - On that note, there does seem to be heaps of overlap between 
 > footnotes, running elements, target-move() and named flows.
 > 
 >   - For the hyphens property, the manual keyword manages to carefully 
 > avoid mentioning the soft hyphen character at all. Is this intentional?

No, it should probably be there. I'm always a bit afraid of insulting
whole continents by overlooking some of their favorite characters. I
suggest this text:

  manual

    Words are only broken at line breaks where there are characters
    inside the word that suggest line break opportunities. Characters
    can be explicit (e.g., U+2010 hyphen) or conditional (e.g., U+00AD
    soft hyphen).

      Example: In HTML, ­ represents the soft hyphen character which
      suggests a line break opportunity.

        ex&ashy;ample.

We may also want to reference:

  http://unicode.org/reports/tr14/#SoftHyphen

 >   - There needs to be a mention of how @counter-style rules interact 
 > with @import rules.

Right. I suggest this text:

   Named counter styles can be imported through @import statements.

    Example: @import url(http://www.example.com/armenian-counters.css);


 >   - The symbol() value is sometimes called symbols(); which is correct? 
 > Prince supports symbols() and repeat().

I suggest "symbol" as it:

  - is (slightly) shorter
  - extracts one single symbol from the list

Remind me, what does repeat() do?

 >   - 13 Page floats: s/lease/least/.

Thx.

 >   - Regarding unless-room, presumably it means the element must fit in 
 > its entirety on the current page, eg. not be split?

Yes. Clarified.

 >   - bookmark-label should take any value that content can take.

Agreed.

BTW, this means that 'content' becomes 'self'. This was changed to
avoid confusion between the 'content' property and the 'content'
value. Are you Ok with this?

 >   - Do continuation markers need to apply to column breaks as well?

I can't recall having seen them. If they were to be added, they would
need their own pseudo-elements:

  p::before-colum-break { 
     list-style-position: outside;
     content: url(to-arrow.png);
  }
  p::after-column-break { 
     list-style-position: outside;
     content: url(from-arrow.png);
  }

This seems excessive to me.

 >   - "To avoid these limitations, the beginning of a change mark is 
 > associated with one document and the end of a change mark is associated 
 > with another document." s/document/element/?

Yes. Nice catch.

 >   - The default style sheet at the end should really be split: the h1, 
 > h2 rules are HTML/XHTML specific, while the other rules give special 
 > default values for properties in certain pseudo-elements.

Right. Unless we bake the last part into the spec itself.

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

Received on Monday, 7 May 2007 15:22:39 UTC