W3C home > Mailing lists > Public > www-style@w3.org > February 2014

Re: [css-line-grid] Are named grids required?

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>
Message-ID: <CF33B7EF.3C496%stearns@adobe.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:19 UTC