Blink won’t implement pointer events
code.google.com
code.google.com
Pointer events would be nice, but using a polyfill isn't so bad. Even if they implemented pointer events, we would still have to implement a polyfill for backwards and cross platform compatibility.
For those of who complain of standards, look at the CSS Regions standard. It's dead and the only browser that has a strong implementation of it is Safari. Other examples of non implemented or partially implemented standards by the browsers: SVG animations, Server sent events, CSP, CSS filters, CSS Images Values and Replaced Content (i.e. cross-fade() images), Intrinsic Sizing, Media Capture and Streams, CSS Masking and Clipping, Web Speech API, CSS Clip paths, User Timing API, the list is endless.
Not to mention that IE and Firefox seem to be very slow at implementing any CSS styling related properties like CSS filters, masking, shapes, 3D CSS transforms (Firefox struggled for a bit and now IE is 'struggling' to implement them fully)
I feel that websockets is like the xml of this decade - "everyone is using it" so everyone wants to use it.
I'm all for making performance a priority, but the IE team found a way to implement pointer events without sacrificing performance. Surely they aren't uniquely capable of this engineering feat.
In the long run, shackling the web to the iPhone 1's touch input scheme seems awfully short sighted. I don't know if IE's pointer event model is the best alternative, but touchstart/down/up/stop definitely isn't.
Lately, I've actually found myself lamenting that I needed to further optimize a couple sites so they'd run smoothly on Chrome and/or Safari, when they were already buttery smooth in IE. That's something I never thought I'd find myself thinking.
(BTW, I see that someone downvoted you, but that wasn't me. Your point about AJAX caching is a good one.)
I wouldn't be surprised if things get better, at least for Chrome, in the near future.
Ugh, that's such a defeatist attitude. And it seems unfounded. Most developers use some form of abstraction on top of native events, such as jQuery or React.
I wish we could move towards a model where browser vendors would expose low level APIs and let libraries implement simple interfaces on top of them. At the moment we end up having to write browser-specific hacks that "guess" the state of the world based on weird heuristics and browser sniffing: https://github.com/facebook/react/blob/master/src/browser/ev...
You might find this academic paper from James Mickens interesting, which explores this exact idea in detail:
http://sigops.org/sosp/sosp11/current/2011-Cascais/printable...
The problem for Google is that an extensible web is a threat t their business model based around search. This is why they are so adamant about force pushing web components and polyfills. It's the least offensive (and least compute intensive) approach to their web crawler.
It's much easier and cheaper for them (as a business) to get everyone to adopt a half-baked and half-thought out standard that allows their crawler to extract content from a page without having to execute javascript to understand what is there.
With the right APIs, a JavaScript rich web can still be an accessible web for the physically impaired. OS X is proof that this possible. However, this approach makes it far far more expensive for web crawlers at scale since it's not as simple as just parsing a document. Forcing everything into a cheaply parseable document is just Google externalizing their costs on the rest of society.
Every decision made for blink needs two be viewed with two lenses: (1) what does this change mean for the Chrome web browser?; and (2) what does this change mean for the Google web crawler? At the end of the day, those two are closely related.
More pertinent to this issue, one of the Googler posts in the relevant public-pointer-events discussion cites that site:
http://lists.w3.org/Archives/Public/public-pointer-events/20...
There is a huge difference between the polyfill that is Polymer and the W3C Web Components specification.
The former is a polyfill that developers can only rely on if they explicitly include it as a dependency in their project. The latter is a feature that is (or at least should be) baked into the current version of every modern web browser out there.
The former conveys an architectural design decision that you must consciously make and that there may be other legitimate alternatives (known and unknown) that you may want to consider instead of the one you're familiar with. The latter conveys that there is one true way of accomplishing task/need X and to stray from using that standardized feature is only for either heretics or the brave.
The former creates a scenario that promotes a proliferation of alternatives. The latter squanders the intellectual capacity of the community with respect to a specific problem that is "officially solved".
To declare a "problem officially solved" with an inadequate solution is professional malpractice, IMHO.
The issue I'm talking about here was the fiasco earlier this year where the Chrome team announced the intent to ship web component features without the use of a developer flag despite the fact that the feature that was not defined in a w3c spec draft much less a mature spec[0]. When you have the market share that Chrome has, shipping without requiring a developer flag is tantamount to saying "Standards schmandards! We're gonna do whatever we want like we're building Internet Explorer in the late 90s!"
[0] http://lists.w3.org/Archives/Public/www-style/2014Feb/0103.h...
I know that the Safari devs are unencumbered and disagree with the Google approach, but I don't know what position they do support as an alternative. I just know that their position does not coincide with Google's position.
TBH, there isn't a whole lot of diversity among those working in this space. There are a lot of developers working on graphics, rendering and layout. There are a lot of developers working on web standards. The intersection of those two groups if plotted as a Venn diagram, is pretty small. After all we really only have a few user agents out there: webkit (safari), blink (chrome), gecko (firefox), servo (?) and trident (internet explorer).
The web would benefit immensely from having many more of the devs in the former group involved. I personally would love to hear ideas and get contributions from developers that work on projects/technologies like qt and wpf.
I'm not totally convinced by the Blink argument – the fact that "touch events are here to stay" is irrelevant, given the unifying nature of pointer events; "fast by default" is a noble goal, but must be a trade-off with functionality; and the whole event-handling-scrolling mess doesn't seem like enough of a deal breaker to preclude tweaks to the spec to fix it.
That said, I'm sure they've had extensive discussions about it and made this decision for a good reason - I hope they now push ahead hard with an alternative solution to these problems.
I've already worked with a couple of companies that have been bitten by assuming a device has either touch or mouse, but not both. They had code to the effect of `if ( touchstart in document ) { attach touch events } else { attach mouse events }` but then they ran into Chrome on a Windows 8 system with a touch screen. Whoops. Now their site only works if you touch the screen.
If you think this is "only a problem on those crazy Windows 8 notebooks" then you're not thinking ahead to systems that will use a Kinect, eye tracking, or some other advanced technique to implement pointers. Devs are really going to hate it when those interesting input methods are sliced and diced into mouse or touch (or God forbid BOTH) in order to shove it into Apple's 2007 vision of a web page input world.
Creating UI widgets that work well everywhere is a non-trivial task that is frequently underestimated.
What this really highlights is the need for high quality UI toolkits which abstracts these details. If a developer is complaining about supporting mouse and touch, then they're most likely missing out on many more details and should be using some pre-built components instead.
Many Chromebooks also have touchscreens.
Note that even Microsoft acknowledges the "touch events are here to stay" argument: IE mobile now supports touch events: http://blogs.msdn.com/b/ie/archive/2014/07/31/the-mobile-web...
For example, we've built better layout APIs (grid, flexbox, etc). Table layout still exists and is probably "here to stay". But we've nearly eradicated it from the modern web and moved the web into the future of responsive design. We can do this with input too.
If you have a touch-enabled Windows device, open up t.msn.com and try swiping through the carousel. It's powered by -ms-scroll-snap-points and feels really good - even on mobile devices. It beats hand-rolled JavaScript scrolling implementations hands down.
As a developer, being able to add `pointer-events: none` to CSS is amazing when compared to adding and removing touch event listeners in iOS to avoid blocking the so the scroll thread.
We are in a weird era where HTML5/web apis kind of succeeded ,making plugins almost obsolete, yet i'm still not sure 5/10 years from now,vendors will still be on that same line.The temptation of implementing proprietary APIs is still huge.
Touch events for instance are a still proprietary API.
It's a W3C recommendation http://www.w3.org/TR/touch-events/
It has 2 implementations (Firefox has implemented in a special branch and is working to port it to their main codebase) and a near complete test suite. Thus it's expected to reach the final Recommendation state soon.
So I don't think the standardization status will change Google's opinion here.
(I edit the PE spec and work on IE)
A small example: let's say that you want to redirect the error output to the standard output.
Since everything is a file descriptor on UNIX, you can just call dup2(2) and this won't have any repercussion on other parts of the program. You can also redirect any error to a file just by using this on a file descriptor you got from open (2).
But in Javascript, everything is different, you have to redeclare console.error and hope that this won't break anything if some library is doing exactly the same thing as you somewhere. This is also the same problem with XMLHttpRequest and various javascript APIs. (including the File and Blob API to read files on the browser).
You chose an unfortunate example. From the dup2 documentation:
The object referenced by the descriptor does not distinguish between fildes and fildes2 in any way.
Thus if fildes2 and fildes are duplicate references to an open file, read(2), write(2) and lseek(2)
calls all move a single pointer into the file, and append mode, non-blocking I/O and asynchronous I/O
options are shared between the references. If a separate pointer into the file is desired, a different
object reference to the file must be obtained by issuing an additional open(2) call. The close-on-exec
flag on the new file descriptor is unset.There's also this: https://github.com/whatwg/streams
The approach where all the vendors are ignoring each other as much as possible while pursuing their own improvements has created a giant mess. What is strangling the situation is there is no consistent vision of what they're actually trying to achieve, so the resulting platform is incoherent, and thus absolutely joyless to work with.
Browser vendors generally seem to be working pretty closely to build a consistent platform. While they've all got their own priorities, as ever, there's lots of collaboration in many areas. We've got cross-platform graphics, WebGL is almost useable, CSS support is good… and so on.
Compared to a few years ago, when we had to build sites that scaled from IE6 all the way to the iPhone, the web is much more uniform and pleasant to work with.
Is there really need to engage in hyperbole? The situation is bad enough without having to resort to exaggerations for effect.
The IE6 lack of support for transparent pngs and a host of other incompatibilities also fragmented the web and in effect the situation is much better now because most sites just work in IE 11 even though developers only tested in Chrome and or Firefox. This is true unless you're using features that haven't made it through the standardization process yet like webrtc. That sites "just work" in the latest version of IE without testing wasn't the case 5 years ago, or even 3 years ago.
From the source:
>Pointer events would likely never supplant touch events on the web (especially without support from Safari). Since touch events are here to stay, supporting another largely redundant input model has a high long-term complexity cost on the web platform.
Sounds to me like the Blink time is trying to use their say to reduce fragmentation and they've taken the side of practicality. Rough consensus and running code indeed.
The other points seem equally sensible to me (at least at first glance) - and a long way from "ignoring each other as much as possible while pursuing their own improvements"
If you read the history of that bug someone rightly points out a key thing is MS have to support the pen on surface, and that was as important to MS there as multitouch was to Apple with iOS. Mobile performance is clearly that to the Chrome team, and this mismatch of priorities is what is at the root of the problem.
Don't kid yourself. Sometimes it's the IE team that refuses to play along. Example: WebRTC.
Overall I feel that the cooperation between vendors on standards is quite good. but you can't expect all these mega corps to agree on everything all the time.
http://www.cnet.com/news/reconciliation-draws-closer-for-sky...
For IE implementation status, follow along here: http://status.modern.ie/webrtcobjectrtcapi
and check out our ORTC prototype: http://html5labs.interoperabilitybridges.com/prototypes/obje...
Every vendor fights their own turf battles. Not-invented-here seems to also be a big issue in standards committees.
I feel relieved now, compared with the old IE6 days.
Anyway, caniuse.com is a pretty good tool when I'm in doubt about using a new API/feature.
Just look at IE, it went from being a last place browser to being a second class browser (first class being Firefox and Chrome). IE 10 pioneered CSS grids, the basis for a mature CSS flexbox spec (thank you MS!!!!), CSS regions (although it is only iFrames =/), setImmediate, pointer events. The competition and collaborations between the browsers (and Adobe) today has set an era for stability and phenomenal progress.
Just thinking about the next IE version gets me tingling: partial ES6, Media capture, HTTP2, Web Audio API, etc. I could have never imagined that the IE team would become so sharp! Now if they can implement some CSS stuff as well (masking, shapes, composting, blending and filters PRETTY PLEASE) and make the browser more deferential to the content (shrink title bars and remove the border around the window por favor), then I will fall in love as I have with Safari.