- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Fri, 30 Nov 2012 13:35:41 -0800
- To: Dean Jackson <dino@apple.com>
- Cc: Simon Fraser <smfr@me.com>, Rik Cabanier <cabanier@gmail.com>, www-style list <www-style@w3.org>
On Fri, Nov 30, 2012 at 4:13 AM, Dean Jackson <dino@apple.com> wrote: > On 30/11/2012, at 12:08 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote: >>> In addition, allowing authors to hijack a common user-interface feature >>> like the scrollbar, and turn it into a knob that makes non-scrolling animations >>> happen seems like something we don't want to encourage. Scrollbars are >>> for users, not authors. >> >> Scroll events, and their ability to cancel the actual scrolling and >> hijack the deltas for the author's own purpose, already exist, and are >> already commonly employed to do a lot of the effects I provided in the >> Prior Art section. This is not something new, nor is it something >> that is going away, and I'm confident that its use will actually >> continue to rise over time. > > We get a huge amount of complaints from users over scrolling > performance, on sites that don't do any of this advanced stuff. > Simon mentioned how easy it is to fall onto a slow path. > > Maybe you've only seen complaints from developers? This is an irrelevant point. If authors implement the functionality in this proposal themselves with JS, they'll trigger *at least* as much de-optimization, but their performance will be noticeably worse. >> We can't put this genie back in the bottle, nor do we *want* to - > > I want to :) Given the prevalence of this kind of pattern on native apps, and the increasing prevalence in the web despite the pain and crappiness (see my Prior Art section, which is only a sampling of all the stuff out there that could benefit from this), I don't think it's realistic to pretend we can do so. Avoiding the work to make touch-based interfaces work well in browsers will just mean that webapps will continue to perform worse than native apps in this important UI aspect. >> there's lots of genuinely good and useful things to be done in this >> space, as demonstrated by all the prior art, both on the web and in >> native apps. >> >> This proposal just captures the common authoring patterns and make >> them (a) easier for authors, and (b) less sucky for users. > > I think it's slightly troublesome that this is adding interactivity to > CSS, but doing it through a back door. You're basically saying that > CSS will control the state of the document based on what the user is > doing. With the exception of :hover, that's a significant change to > the design goal of CSS. And if we're adding responses to interaction, > why is this particular limited feature the most essential? I would think > the most obvious starting point for such an adjustment to CSS would be > having a selector match based on the state of non-related elements > (i.e. click on something and another part of the page changes state). But > anyway, I'm saying that this proposal is making a big change in the > CSS model. I appreciate that there are *multiple* places where we need to add more interactivity into CSS. (More properly, we need to add more declarative interactivity via *some* mechanism, and CSS is the easiest way to attach declarative data to elements at hand.) > Also, I'm skeptical that your proposal is really any easier for > authors beyond the most simple cases. Highly interactive things > are often better done in script. The prior art you show are fairly > cool demos, but very linear. You are correct that my listed examples are relatively simple. I believe that they're representative, though - most such touch interactions are fairly simple and linear. The examples are drawn from actual usage, after all; they're not just made-up trivial showcases of the syntax. You would *actually* be able to use my code for the Twitter pull-to-refresh, for example. Note, though, that "linear" might not be accurate. You can certainly utilize transforms (even 3d transforms) in the proposal to achieve very fancy effects. For example, the ubiquitous 3d transform demo of the ring of numbered panels is easy (just a light modification of the carousel demo code I already have), and would make a cool way to present a slideshow! > For example, your proposal mentions the pull-to-refresh. If you look > at the iOS implementation of the system PTR, you'll see this is something > that couldn't be done without script (a graphic that changes shape as the > rubber band is pulled). I have no idea what this is, and google isn't helping - can you point to images or a video of it working? Regardless, I'm comfortable with very advanced cases not being able to use this, as long it solves a large majority of actual case. That said, shape-warping isn't actually out of the picture. This proposal slots nicely into the Web Animations proposal, which means you should be able to link up the scrubbing controls to SVG animations, such as <path> animation. > But mostly, I really don't think this is important to the Web and > the CSS community right now. We're having to conduct polls of the CSS WG > members to decide which small subset of the huge amount of work that > needs to be done will actually get any attention. Is this more important > than everything we won't get to? > > I'd like this group to focus on > > (a) things that can't be done but are necessary/highly-desired (responsive > gradients is a good example), or > (b) fixing the existing things that people are using > > Compare your proposal to the position:sticky one. This is something related > to scrolling that was addressing a clear need and helped both users and > developers. > > I think the phrase I'm looking for is "bang for buck". It is currently *impossible*, not just hard, or doable if you have enough engineering resources, but *impossible* to create an app that responds to touch the same way that a native app does. You can't work around the delay imposed by having the touch get translated into a gesture and stroll its way into the JS event queue, and it's not uncommon for this delay to be 100ms. Worse, once you *do* start your late response to the gesture, you're at the mercy of the UI thread, which janks when you look at it funny, so your motion will often be jerky if any other JS happens to be running at the same time, particularly if you're on mobile. If you feel that the problems I'm trying to solve aren't worthwhile, that's cool. We can debate about that. But this isn't a frivolous feature; it's addressing a place where there is something missing in the current platform that authors are unable to plug themselves. ~TJ
Received on Friday, 30 November 2012 21:36:29 UTC