What do you think this will output?
var div = document.createElement('div');
div.innerHTML = '<span>Hello world!</span>';
var span = div.firstChild;
div.innerHTML = '<span>Uh oh!</span>';
console.log(span.innerHTML);
console.log("Worker startup"); | |
this.oninstall = function(event) { | |
console.log('Worker install'); | |
event.waitUntil( | |
caches.create('static').then(function(cache) { | |
return cache.add( | |
//Templates |
# Add a key binding to your User Key Bindings and you're all good to go | |
# { "keys": ["super+shift+h"], "command": "convert_hex_to_rgb" } | |
# | |
import sublime, sublime_plugin | |
class ConvertHexToRgb(sublime_plugin.TextCommand): | |
def run(self, edit): | |
for region in self.view.sel(): | |
if not region.empty(): |
What do you think this will output?
var div = document.createElement('div');
div.innerHTML = '<span>Hello world!</span>';
var span = div.firstChild;
div.innerHTML = '<span>Uh oh!</span>';
console.log(span.innerHTML);
Caveats: I suck at accessibility, so I am probably wrong on a lot of things.
Chrome 32 on Android removes the 300ms delay on touch events for responsive sites. This disables double-tap zoom, leaving pinch to zoom the only way to zoom content. This is an accessibility concern, as for some users double tap zoom may have been the only way they were able to zoom web pages.
One of the biggest missed opportunities thus far with HTTP/2 ("H/2") is that we are not yet able to sunset WebSockets in favor of H/2. Web Sockets and H/2 both support multiplexing messages bi-directionally and can send both textual and binary data.
Server Sent Events ("SSE"), by contrast, are not bi-directional (they're a "server-push-only" channel) and binary data cannot be sent easily. They are, however, very simple to implement. Adding to the menagerie of options, RTCPeerConnection
can also be used to signal data to applications in a low-latency (but potentially lossy) way.
Because H/2 [does not support the handshake (upgrade) that WebSockets use to negotiate a connection](https://daniel.haxx.se/blog/2016/06/15/no-websockets-
Most APIs which accept binary data need to ensure that the data is not modified while they read from it. (Without loss of generality, let's only analyze ArrayBuffer
instances for now.) Modifications can come about due to the API processing the data asynchronously, or due to the API processing the data on some other thread which runs in parallel to the main thread. (E.g., an OS API which reads from the provided ArrayBuffer
and writes it to a file.)
On the web platform, APIs generally solve this by immediately making a copy of the incoming data. The code is essentially:
function someAPI(arrayBuffer) {
arrayBuffer = arrayBuffer.slice(); // make a copy
/* | |
* This work is free. You can redistribute it and/or modify it under the | |
* terms of the Do What The Fuck You Want To Public License, Version 2, | |
* as published by Sam Hocevar. See the COPYING file for more details. | |
*/ | |
/* | |
* Easing Functions - inspired from http://gizma.com/easing/ | |
* only considering the t value for the range [0, 1] => [0, 1] | |
*/ | |
EasingFunctions = { |