- From: Alan Stearns <stearns@adobe.com>
- Date: Wed, 26 Feb 2014 23:35:43 +0000
- To: Håkon Wium Lie <howcome@opera.com>, Tab Atkins Jr. <jackalmage@gmail.com>
- CC: fantasai <fantasai.lists@inkedblade.net>, www-style list <www-style@w3.org>
On 2/26/14, 2:17 PM, "Håkon Wium Lie" <howcome@opera.com> wrote: > >So it seems there's agreement that we do not need named grids. That's >an important simplification, one that motivated me to write up this >proposal: > > http://books.spec.whatwg.org/#baseline-grids > >... >Also, I think the "root" and "page" values are useful. "root" is a >grid defined by the font/position of the root element, while "page" is >a grid defined by the page area + the font of the root element. To >avoid show-through in printed matter, it is important to have a >baseline grid that doesn't change when page margins are change. For >example, the page area on the first page of a chapter may be different >from those on other pages, but we still want baselines to match. The root and page values look to me like named grids - just privileged names instead of user-defined ones. If those are needed, I think it would be better to allow them to be established in the same way that we allow user named grids. For the root grid, my assumption is that in most cases we do not need to have an explicit name. As long as no element defines a new line-grid, that’s what the snap properties would use. Do you have a use case for something like this? +root ++parent that defines a grid +++child that snaps to parent’s grid +++child that snaps to root grid That’s the basic case for named grids, and I just don’t see it being a common case. For a page grid, we could say that using line-grid in an @page rule sets the root grid for the page, and as long as no element on that page defines a new line-grid, snapping to that grid would avoid show-through. Thanks, Alan
Received on Wednesday, 26 February 2014 23:36:15 UTC