W3C home > Mailing lists > Public > www-style@w3.org > October 2008

[css3-gcpm] More feedback

From: Håkon Wium Lie <howcome@opera.com>
Date: Tue, 14 Oct 2008 23:24:29 +0200
Message-ID: <18677.3597.834131.283286@opera.com>
To: "Refstrup, Jacob Grundtvig" <jacob.refstrup@hp.com>
Cc: "www-style@w3.org" <www-style@w3.org>

Also sprach Refstrup, Jacob Grundtvig:

 > 6. Footnotes
 > s/traditions footnotes/traditions of footnotes/

Yes.

 > 6.4 Footnote calls
 > 
 > What should happen if a font is used with limited superscripted
 > entries (or at least less than the number of footnotes)?

I suggest this text:

  Using super-sized glyphs is optional; UAs may also scale and
  position other glyphs for use in footnote calls.

 > 6.7 target-pull()
 > 
 > Clarification needed: Does target-pull() only refer to textual
 > content (like named strings) or does it refer to an element and its
 > descendents (like running headers/footers)?

It refers to the element itself, not just it's textual content. I've
tried to clarified it with this wording:

  In order to move an element from one place in the presentation to
  another, the ''target-pull()'' value is introduced.

 > 6.9 Footnote magic
 > 
 > s/are automatically labeled with the value of ./are automatically
 > labeled with the value of the footnote counter./

Yes.

 > 7. Named flows
 > 
 > Example XXXVIII (tablenote):-
 > 
 > It is implicit that the ::note-marker and the and the content of float: to(...) gets moved together to the named flow. So:-
 > 
 > s/On the 'float' property, 'to()' is introduced to indicate that
 > the element should be pushed from its natural position and into a
 > named flow./On the 'float' property, 'to()' is introduced to
 > indicate that the element (and it's ::note-marker) should be pushed
 > from its natural position and into a named flow./

This is correct. However, I'm reluctant to make the change as it would
require even more changes. The element is indeed moved, along with all
its pseudo-elements and descender elements and their pseudo-elements
etc. This is also the case for other values on the float property
(e.g., 'float: right'). This is stated in CSS 2.1 section 12.1:

  The formatting objects (e.g., boxes) generated by an element include
  generated content.

  http://www.w3.org/TR/2007/CR-CSS21-20070719/generate.html#before-after-content

So, I don't think it has to be restated here.

 > Clarification: Does the floated element gets "promoted" to a display: block type?

You mean, is a floated element considered a block-level element. No,
not according to the definition of block-level:

  http://www.w3.org/TR/2007/CR-CSS21-20070719/visuren.html#block-level

 > Question: What prevents the use of ::marker rather than ::note-marker?

Nothing, that would be simpler. If we make the change, we should
probably change ::note-call to ::call as well. Too short? Too general?
Will it be mixed up with phone calls on mobile devices? :-)

 > Also, if an element that is floated to a named flow does that
 > include ::before, ::after content as well?

Yes, as per CSS 2.1.

 > 9. Hyphenation
 > 
 > The resources -- what format/specification do they adhere to?

Unspecified. Just like the format of images are unspecified. TeX's
format is used by Amaya and Prince.

 > 11. Image resolution
 > 
 > Computed value: I think it should be a single value; at least the
 > actual value used should be accessible through the CSSOM.

Right. In order to find a single value, the image may have to be
loaded. Finding the computed value cannot require the rendering of the
document -- can it require the loading of images?

I'd like to discuss this at the upcoming F2F meeting.

 > Should there also be a 'border-image-resolution' for completeness?

I've added this as an issue.

 > 12. Page marks and bleed
 > 
 > page-bleed
 > 
 > s/<length/<length>/

Fixed.

 > 14. CMYK colors
 > 
 > I understand that:
 > 
 > color: red
 > color: cmyk(...)
 > 
 > is backwards compatible; but I'm wondering if we can think of a more compact syntax:-
 > 
 > color: cmyk(...) || red
 > 
 > (inspired by the '||' operator).
 > 
 > Obviously this is not backwards compatible and would need to be
 > proceeded with a color: red -- but if in the future we add another
 > optionally supported colorspace then we specify it more compactly:
 > 
 > color: ycc(...) || cmyk(...) || red
 > 
 > Comments?

It would be more in line with CSS tradition to use a comma as a
separator. The comma traditionally denotes alternatives and this is
the same as what you are saying with ||, right?

The change would have to go into the CSS3 color module, though.

 > 15. Page floats
 > 
 > Other keyworks -- should include to(...) for named flows.

Yes.

I've also added this text to clarify what is meant with "page floats":

  Images and figures are sometimes displayed at the top or bottom of
  pages and columns. Also, an element may be moved to the next page or
  not displayed at all if there is not enough room on its native page.
  This is called "page floats" in this specification.

 > 'next' value -- s/next page/next page (or column -- depending on the reference keyword)/

This gives me a headache. These combinations worked nicely:

  next page
  next column

Now, however, the 'column' keyword is gone. It has no replacement;
'multi-column' means something different.

Do think floating to the next column is important? If the answer is
no, we can restrict the use of 'next' to combinations with 'page'. One
good reason for choosing this option is that 'advanced multi-column'
layout can express that a element should be floated to the last
column, or next-to-last column etc.

If the answer yes, we need to express this somehow. We can 

 a) reintroduce the 'column' keyword, or 

 b) say that 'next' refers to the column unless 'page' is explicitly
    mentioned.

None of these appeal to me. So, for now, I've restricted 'next' to use
with 'page'. What do you think?

 > 16. Advanced multi-column layout
 > 
 > The text "Fractions on the 'gr' unit refer to the last distance
 > added." confuses me. If I have 1.5gr and it's 1 column width + 1/2
 > a column gap -- it's not intuitive what the "last distance added"
 > is. Not sure how to better word it.

How about:

  The 'gr' unit has two purposes. When used on the 'float-offset'
  property it identifies a position by counting columns and gaps from
  the position established by the 'float' property. Fractions on the
  'gr' unit refer to fractions of the last counted gap or column.

  When used on the 'width' property, the 'gr' unit identifies a length
  by counting gaps and columns, starting at the point where the
  element naturally finds itself and continuing in the direction of
  box expansion. Fractions on the 'gr' unit refer to the last gap or
  column counted.

 > Example LXXXI / float-offset:
 > 
 > Question: With a float-offset of 2gr I expected that (per 16.1)
 > "the middle of the float should be aligned with the specified grid
 > line (or portion thereof)." -- i.e. the middle of the float should
 > be aligned with 2gr -- 2gr is the left edge of the 2nd column. It
 > would seem if this example was to work (as spec'ed) we'd need
 > float-offset: 2.5gr (middle of 2nd column). Example LXXXV is
 > assuming this.

You're right. That was a nice catch.

 > Another (artificial) example I'd like to know how to do is how to
 > float an element just in the column gap?

It's an interesting use case.

 > float-offset: 1.5gr -- should do the trick for positioning

Right.

 > width: 1gr -- not clear which grid this is referring too?

We would have to change the definition of 'gr' to make this work. But
that should be possible.

 > I am thinking that perhaps it would be better for these advanced
 > grid float cases if the CSS properties were more explicit:
 > 
 > float: left 2.5gr // align center with middle of 2nd column (counting from left)
 > 
 > float: left [2gr,3gr] // center float between grid line 2 and 3 (counting from left)
 >                       // (i.e. center in 2nd column); if width: auto then width is
 >                       // distance between grid line 2 and 3.
 > 
 > float: left 2.5gr top 50% // horz centered in 2nd column, vert centered
 > 
 > The [<length>,<length>] specifies an offset to determine the left &
 > right side of the float; it also affects calculated 'width' if it
 > is specified as 'auto' to be the distance between the two lengths.
 > 
 > This does solve my (artificial) problem from above:-
 > 
 > float: left [1gr,2gr] // float in 1st column gap; float width is
 > same as column gap (assuming width: auto)

Hmm. I'm hesitant to complicate the 'float' property further.

If we change the defintion of 'gr' to be one of "start counting in the
area (either gap or column) where you find yourself in, and contiue
counting in the direction where content expands to", it should be
possible to address your use case:

Use case 1: make an element float into the first column gap of a
multi-column element, and make it fill the whole width of the gap:

  .gap-figure {
     float: left;
     float-offset: 1gr;
     width: 1gr;
  }

 > Since this email is getting rather long and I'd like to share my
 > comments sooner rather than later I'll send the rest of my comments
 > for css3-cgpm at a later date.

Please do, your comments are very helpful. 

A new version of the editor's draft is available from

  http://dev.w3.org/csswg/css3-gcpm/Overview.html

-h&kon
              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Tuesday, 14 October 2008 21:25:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 27 April 2009 13:55:15 GMT