- From: Alan Stearns <stearns@adobe.com>
- Date: Fri, 3 Oct 2014 13:56:29 +0000
- To: Håkon Wium Lie <howcome@opera.com>
- CC: Christoph Päper <christoph.paeper@crissov.de>, "www-style@w3.org" <www-style@w3.org>
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