- From: Håkon Wium Lie <howcome@opera.com>
- Date: Wed, 1 Oct 2014 18:48:48 +0200
- To: Alan Stearns <stearns@adobe.com>
- Cc: "www-style\@w3.org" <www-style@w3.org>
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