Re: [css-line-grid][css-books] one property or more?

On 10/3/14, 1:01 AM, "Håkon Wium Lie" <howcome@opera.com> wrote:

>Also sprach Alan Stearns:
>
> > >Opt-out:
> > >
> > >   body { baseline-snap: new }
> > >   h1, h2, img, figure { baseline-snap: clear }
> > 
> > One problem with an opt-out strategy is how to get a nested element to
> > participate in a grid once a parent has opted out. Your examples have
> > usually set the figure element to opt-out. With the styling above, how
> > would I get the lines in a <figcaption> to align to the body grid?
>
>You'd say:
>
>  body { baseline-snap: root }
>  h1, h2, img, figure { baseline-snap: clear }
>  figcaption { baseline-snap: root }
>
>This is why 'root' is there -- to provide a grid which is accessible
>by all elements.

But you introduce a problem when you trade off defining a grid on body for
assigning the root grid to body. When an element defines a grid, its own
line-height relates to its top edge such that it’s perfectly clear where
the first line box will snap to the grid. Changing to the root grid
introduces some uncertainty - whatever’s between root and the element
changes where the top edge is on the root grid, so you don’t know (and
usually can’t control) where the first line will snap.

>
>I think 'root' and 'page' are simple elegant and solutions which gives
>most of the benefits of named grids without having to introduce a
>complex naming scheme.

I figure if we have to go to all the bother of specifying and implementing
how one or two special named grids work, we might as well allow
user-defined names. An identifier is not particularly complex.

>
>However, one can quite easily extend the one-property solution with
>two new keywords to avoid using 'root'/'page'.
>
>E.g., an opt-in example would be:
>
>  body { baseline-snap: define }  /* define basline grid, but don't
>engange it yet */
>  p { baseline-snap: engage }     /* engage baseline grid from youngest
>defining ancestor */
>
>An opt-out example would be:
>
>  body { baseline-snap: new }     /* define and engage */
>  img, figure { baseline-snap: clear }
>
>And your challenge above would be:
>
>  body { baseline-snap: new }                     /* define and engage */
>  h1, h2, img, figure { baseline-snap: clear }    /* clear grid set on
><body> */
>  figcaption { baseline-snap: engage }            /* re-engange grid set
>on <body> */

This is much better. It actually solves the challenge as presented. I
could work with this syntax, as it’s basically just folding the line-snap
property in to the values of your single property. I still think the two
separate operations of defining a grid and engaging the grid are more
clearly expressed in two properties, though.

The line-snap property currently has one additional value - contain. So if
we were to use a single property there might need to be something like
engage-baseline and engage-contain (or perhaps just baseline and
contain?). We’ve discussed allowing more non-dominant baseline alignments
in the future, which would be new values and keywords on the line-snap
property. For the folded-in version we’d need to add more values and
keywords there.

I am planning on allowing an ident on the line-snap property for named
grids in the future, so if I wanted to have an element’s line boxes use
contain for a named root grid I’d specify ‘line-grid: contain root’. In
the single-property syntax, I assume new and root engage baseline line
snapping. For this use case perhaps we would allow ‘baseline-snap: root
contain’?

I think this version of the single property could work, but I don’t think
it’s optimal. Describing how each of the single property’s values define,
engage, re-engage, etc. seems to me to be much more complicated than
having one property for defining a grid and a second property for line
snapping. Two separate properties make it easier to extend in the future
(both for defining a named grid and for snapping to different baselines).
The small benefit of using one declaration instead of two is a false
economy.

And I just had another thought. In my draft line-grid does not inherit,
but line-snap does. This maps well to what the properties are used for -
defining a grid is a singular operation, but it makes sense for snapping
to continue through all of the element’s children. The single property
can’t inherit, as you wouldn’t want a ‘new’ value to create a new grid on
each child. The engagement part of the single property is then carried
through to the element’s children just by definition, not inheritance. So
child elements have a 'baseline-grid:normal’ value and their content snaps
or not depending on the nearest ancestor with a baseline-grid value that
isn’t ‘normal’? That also seems suboptimal to me - better to have two
properties so that the inherited value of line-snap can indicate what
snapping strategy is used for the element’s line boxes.

Thanks,

Alan

Received on Friday, 3 October 2014 13:57:00 UTC