W3C home > Mailing lists > Public > www-style@w3.org > April 2016

Re: [css-snappoints] [css-scroll-snap] Summary of latest updates 1/13

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 6 Apr 2016 14:15:32 -0700
Message-ID: <CAAWBYDAWjsVnbvoSMO2dswdX=xk-AXGSTS88hvvk8jx0bNbaVg@mail.gmail.com>
To: "Myles C. Maxfield" <mmaxfield@apple.com>
Cc: Dean Jackson <dino@apple.com>, fantasai <fantasai.lists@inkedblade.net>, Matt Rakow <marakow@microsoft.com>, "www-style@w3.org" <www-style@w3.org>, fantasai <fantasai@inkedblade.net>
On Fri, Jan 15, 2016 at 5:12 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Fri, Jan 15, 2016 at 5:08 PM, Myles C. Maxfield <mmaxfield@apple.com> wrote:
>>> On Jan 15, 2016, at 4:34 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Fri, Jan 15, 2016 at 4:07 PM, Dean Jackson <dino@apple.com> wrote:
>>>>> On 16 Jan 2016, at 10:52 AM, fantasai <fantasai.lists@inkedblade.net> wrote:
>>>>>> Ok.  Did you and Apple discuss any additional clarifications that
>>>>>> should be added to address their original concerns?
>>>>>
>>>>> Not specifically, no. But we did just check in a bunch of clarifications
>>>>> in response to Sebastian Zartner's email:
>>>>> https://lists.w3.org/Archives/Public/www-style/2016Jan/0099.html
>>>>
>>>> We asked for 2d snap points to be deferred from this version. Is there
>>>> anyone actively arguing for it? I thought we agreed in Japan that the
>>>> use case either could be done another way or wasn't necessary (sorry,
>>>> foggy memory as usual).
>>>
>>> No, it definitely can't be done in another way, and for the use-cases
>>> presented, it is necessary.
>>
>> This is correct, Dean's memory was foggy. Our objection was that implementing it is too difficult to understand all the behaviors that would be caused by the property.
>
> Is this objection against the current version of 2d snapping, or an
> older one?  Earlier versions of the proposal (pre-Sapporo) made the
> "1d or 2d" decision on a per-element basis, which resulted in some
> incoherence in the model that was understandably icky.  The current
> version puts the decision on the container, so the only difference is
> that the container has to choose both axis positions from a single
> element, rather than potentially grabbing each from a different
> element.  There shouldn't be anything hard-to-understand about it now.

This question was never answered.  What, precisely, do people think is
difficult to understand about 2d snapping in the current model?

Again, the only difference between 1d and 2d is that when the
container is set to 2d, each child must define a snap point in both
axises, and the container must choose both of its axis positions from
a single element, not from different elements like it's allowed to do
in 1d.

~TJ
Received on Wednesday, 6 April 2016 21:16:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:02 UTC