[css-snappoints] 10/24 Snap points draft update

Hi all,

As noted on the conf. call a couple weeks ago, it's been a while since the last update to the snap points spec.  I've pushed a new revision which resolves most of the issues.  I've also added this as a topic for TPAC so we can discuss in person if needed - it's always easier to discuss this feature with a whiteboard handy.  I believe I've captured or resolved all the feedback I've received -- if it looks like I've missed something or if you disagree with the resolution please let me know.

Link for convenience:
http://dev.w3.org/csswg/css-snappoints/

Changes and additions:
-Section 3 - Replaced usage of the term "leading edge" with "start edge", matching the CSS Alignment spec.
-Section 4 - Specified behavior when content is added, moved, deleted, resized.  Mandatory snap points MUST reconcile, proximity snap points MAY reconcile.
-Section 5 - Removed list syntax due to lack of scenario justification and since feedback was that people didn't like it.  One collateral benefit of this is that it also resolves the ambiguity incurred if an author tries to specify diagonal snap points using lists.
-Section 5 - Removed "element" value for scroll-snap-points property by popular request.  Its original intent was to guarantee mutual exclusivity between list/interval vs. element snap points.  While we still don't have scenario justification for combining interval and element snap points, we also don't have strong justification for prohibiting it.  Best practice will be to avoid mixing the two.
-Section 7 - Specified that the snap-coordinate is relative to the element's border box, rather than the box specified with the box-sizing property.  Added a new issue for Rob's request for the ability to specify which box to use.
-Section 7 - Specified that the snap-coordinate is transformed along with the element, such that the snap point is aligned with the element as-drawn.
-Throughout - Converted all <length>{2} values to <position> values.
-Throughout - Specified that the visual viewport adheres to the snap points (as opposed to the layout viewport).  This resolved the question about zoomed behavior.

There were also a number of issues that were requesting additional functionality and features.  I've removed those based on feedback from the conf. call that we'd prefer to get the basics nailed down first.  I'm definitely open to adding these back in as they're invented though.
-Snap areas
-Per-axis snap-type
-Direct linking to a snap point (e.g. with a hash or similar)
-Supplementary APIs (snap-to-next, snap-to-previous, jump-to-N)
-Ability to retrieve a list of computed snap points for a given scroll container

Thanks,
-Matt

Received on Friday, 24 October 2014 21:39:20 UTC