- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 21 Oct 2015 11:00:19 -0700
- To: François REMY <francois.remy.dev@outlook.com>
- Cc: "Robert O'Callahan" <robert@ocallahan.org>, www-style <www-style@w3.org>
On Wed, Dec 4, 2013 at 7:58 AM, François REMY
<francois.remy.dev@outlook.com> wrote:
> That being said, I was asking myself the question why we needed a new grid-definition language here. I'm in favor of simply reusing the "grid-template" syntax in a "scroll-snap-template" property : this would enable visual editors to be reused, and reuse existing mental models.
>
> I'm pretty sure that, in a lot of useful cases, we already have to handle the snapped scroll on a grid, and we could therefore even have
>
> (1) "scroll-snap: mandatory from-grid(*:*)" which means "use as mandatory snapping-lines all rows and all columns of the computed value of the grid template"
>
> or
>
> (2) variants like "scroll-snap: mandatory none from-grid('start', 'separator', 'end' : *)" which means "use as mandatory horizontal snapping-lines the vertical lines from the grid named 'start', 'separator' or 'end', do not define any vertical snap-mechanism".
>
> A solution like this one would maybe reduce the need for the "descendant-based snapping lines" mechanism you described a bit further in the mail, since you could achieve the same result at the parent level using a grid, which may be simpler to implement than creating deep scroll-snapping dependencies (that may be worth at some point, but we may refrain from including this in L1 in order to make some progress implementation-wise asap).
If you have a grid, you can just snap to elements in the grid. If you
have any grid lines that aren't used to position elements, you almost
certainly don't want to snap to them anyway.
~TJ
Received on Wednesday, 21 October 2015 18:01:13 UTC