[css-line-grid][css-books] (base)line grids

Alan Stearns wrote:

 > The CSS WG has published an updated Working Draft of the CSS Line Grid
 > Module Level 1:
 > 
 >     http://www.w3.org/TR/css-line-grid-1/
 > 
 > This module contains features for aligning content to a baseline grid.
 > 
 > This draft has reduced the feature set for the first level, and added
 > extensive examples of snapping lines to the baseline grid.

It's good to see that the draft has been simplified. The complex model
first suggested was one of the reasons for writing up this proposal:

   https://books.spec.whatwg.org/#baseline-grids

It seems that the two drafts have, roughly, the same level of ambition. 

In this message:

   http://lists.w3.org/Archives/Public/www-style/2014Feb/0767.html

I argued for solving common use cases with only one property. Is
this possible in CSS-line-grid? I don't know. The draft doesn't have
any code examples. I think it should have some motivational code
examples for common use cases on all properties.

I suggest this as the first used case: align all content on a baseline
grid, except images and figures. in CSS Books I would write:

   body { baseline-grid: new }
   img, figure { baseline-grid: none }

In CSS Line-grid, I think you would write:

   body { 
     line-grid: create; 
     line-snap: baseline;
   }
   img, figure { line-snap: none }

Is this correct?

If so, I think the draft can be further simplified -- you can reduce
the number of properties needed from two to one if you combine the
task of defining and engaging a line grid. These are almost always
done as one operation, and I don't see a strong use case for being
able to define a baseline grid without engaging it?

----

There are, however, two predefined baseline grids in CSS Books: 'root'
and 'page'. 'root' is there so that all elements can refer to one
common baseline grid, no matter what other ancestor elements have
done. In this example, article and aside content would use the same
baseline grid:

  body { line-grid: create }
  article { line-grid: root }  /* ignore what <body> did, engage the 'root' baseline grid instead */
  aside { line-grid: root }    /* ignore what <body> did, engage the 'root' baseline grid instead */

It seems like a good, if not super-important, use case -- it gives you
some of the flexibility of named baseline grids without introducing
arbitrary name spaces. How would you express this in CSS-line-grid?

----

'page' is there so that baselines can be defined wrt. the page box.
Different pages may have different page margins, but you still want
baselines on different pages to align to avoid see-through when
printed. E.g.:

   @page introduction { margin: 10% }
   @page chapter { margin: 6% }
   body { line-grid: page }

This seems quite important for printed documents and I suggest it is
added to CSS-line-grid (it's mentioned in a note in the most recent WD).

----

One common use case is how to align boxes that do not snap. In CSS Books I can write:

   img, figure { 
     baseline-block-snap: before;      /* move up  */
     baseline-block-snap: after;       /* move down  */
     baseline-block-snap: center;      /* center */
     baseline-block-snap: auto;        /* before, after, center, depending on place on page */
   }

In CSS Line Grid, I guess you would write:

   img, figure {
      box-snap: block-start;           /* move up? */
      box-snap: block-end;             /* move down? */
      box-snap: center;                /* center */
      box-snap: xxxxxxxx               /* not possible? */
    }

I don't understand why the keywords are called 'block-start' and
'block-end' -- shouldn't they have "before" and "after" in them
instead of "start" and "end"? I always mix these up myself -- 'before'
and 'start' sounds much too much like synonyms in my head -- but I
believe "before" refers to the top edge (assuming latin), and "start"
refers to the left edge? If so, I don't understand how you would align
the left edge of the block with a baseline grid?

Also, not having an 'auto' value feels like a loss (I see it mentioned
in a note). But, using CSS Figures one can achieve the same effect as
'auto' does, you would write:

  img { float: snap }

  https://figures.spec.whatwg.org/#floating-to-nearest-edge:-snap

So, it may be that this is better thought of as floating than as
'not-snapping' to a baseline grid.

----

Finally, on syntax: CSS Books uses the same property/value names as
the AntennaHouse implementation:

  http://antennahouse.com/xslfo/extension.htm#axf.baseline-grid

I think it makes sense to build on the names used in this implementation.

------

However, there are things I don't understand in the AntennaHouse
implementation.

In my head, the processing model for baseline grids is: lay out all
elements as tight as possible, while honoring baseline grids. Then,
come back and, within the space that has been created, wiggle the
boxes that have 'baseline-grid: none' so that 'baseline-block-snap' is
honored.

In the AntennaHouse implementation, it seems that a value on
'baseline-block-snap' can actually influence how much space is
created. (In ways I don't quite understand.)

Is this the case in CSS-line-grid? That is, can a value on 'box-snap'
influence the size of the wiggling room?

Cheers,

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

Received on Wednesday, 1 October 2014 16:49:20 UTC