11–20 of 65 posts
One thing which makes me sad is the lack of structure of the Javascript API. Everything is now built using Javascript and the JS VM is not following any UNIX principles in its implementation. I would really like to have a UNIX-like JS API. 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'…
People used to complain about mobile device fragmentation, but the web is now looking more fragmented than at any point since IE3 vs Netscape, and whoever else decided to chuck together an excuse for a browser and release it. 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 con…
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.
People used to complain about mobile device fragmentation, but the web is now looking more fragmented than at any point since IE3 vs Netscape, and whoever else decided to chuck together an excuse for a browser and release it. 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 con…
I think you've reached a slightly perverse conclusion. 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'v…
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.
This is interesting, because I'm pretty sure Microsoft is going to go full steam ahead with pointer events. Indeed, they're the only major vendor of a device that supports both mouse and touch (finger AND stylus) events – it's going to be super important to handle those events well. I'm not totally convinced by the Blink argument – the fact that "touch events are here to stay" is irrelevant, given the unifying nature…
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.
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...
One thing which makes me sad is the lack of structure of the Javascript API. Everything is now built using Javascript and the JS VM is not following any UNIX principles in its implementation. I would really like to have a UNIX-like JS API. 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'…
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.One thing which makes me sad is the lack of structure of the Javascript API. Everything is now built using Javascript and the JS VM is not following any UNIX principles in its implementation. I would really like to have a UNIX-like JS API. 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'…
There's also this: https://github.com/whatwg/streams
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.
Earlier quoted context omitted.
I think you've reached a slightly perverse conclusion. 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'v…
The Blink team have simply become the new IE style refuseniks, using mobile performance as the standard excuse. Mozilla, Apple and Microsoft have all been creating new "standard" APIs which no one else implements, yet in order to get best performance on their systems you have to use. 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 im…
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.
One thing which makes me sad is the lack of structure of the Javascript API. Everything is now built using Javascript and the JS VM is not following any UNIX principles in its implementation. I would really like to have a UNIX-like JS API. 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'…
>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 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…