Set of issues run into by children using iPad apps. Should be generally appropriate though:
“Designing apps for children is extremely hard. Not only is quality, age-appropriate content hard to create, but designing the flow and interaction of these apps is made more difficult because designers must refrain from implementing advanced gestures, which would only confuse and frustrate kids (and, by extension, their parents). Yet all apps can and should adhere to certain basics. Hopefully, the four guidelines discussed here can become fixtures of all children’s apps.”
Seems generally bad to embed sensitive info in the URI (the http+aes URI scheme’s decryption key) similar to the now deprecated password field.
Use case is covered here: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JanMar/0811.html. Also discussion including someone mentioning the issue above.
Fascinating, but really most of the time it is in your code. Really you should look there first. Usually not the compiler’s fault, or the OS’s fault, or a loose wire in the CPU…
Follow the link for other great Al themed artwork.
(via http://twitter.com/alyankovic/statuses/177517595874951171)
Fictional plot summaries of TNG S8 episodes. Like:
The goal of this experiment was to combine the flipping tables emoticons with the Threw It On The Ground video using shiny new HTML5-ish features and the end result is the table flipper flipping the Threw It On the Ground video.
The table flipper emoticon is CSS before content that changes on hover. Additionally on hover a CSS transform is applied to flip the video upside down several times and move it to the right and there's a CSS transition to animate the flipping. The only issue I ran into is that (at least on Windows) Flash doesn't like to have CSS transform rotations applied to it. So to get the most out of the flip experiment you must opt-in to HTML5 video on YouTube. And of course you must use a browser that supports the various things I just mentioned, like the latest Chrome (or not yet released IE10).
I've been working on the Glitch Helperator. It is a collection of tools and things I've put together for Glitch. It has a few features that I haven't seen elsewhere including:
I say all of this to set up the fact that Beatrix has little idea of how traditional TV works and seeing her first real exposure to it was enlightening to say the least.
One of the more limiting issues of writing client side script in the browser is the same origin limitations of XMLHttpRequest. The latest version of all browsers support a subset of CORS to allow servers to opt-in particular resources for cross-domain access. Since IE8 there's XDomainRequest and in all other browsers (including IE10) there's XHR L2's cross-origin request features. But the vast majority of resources out on the web do not opt-in using CORS headers and so client side only web apps like a podcast player or a feed reader aren't doable.
One hack-y way around this I've found is to use YQL as a CORS proxy. YQL applies the CORS header to all its responses and among its features it allows a caller to request an arbitrary XML, HTML, or JSON resource. So my network helper script first attempts to access a URI directly using XDomainRequest if that exists and XMLHttpRequest otherwise. If that fails it then tries to use XDR or XHR to access the URI via YQL. I wrap my URIs in the following manner, where type is either "html", "xml", or "json":
yqlRequest = function(uri, method, type, onComplete, onError) {
var yqlUri = "http://query.yahooapis.com/v1/public/yql?q=" +
encodeURIComponent("SELECT * FROM " + type + ' where url="' + encodeURIComponent(uri) + '"');
if (type == "html") {
yqlUri += encodeURIComponent(" and xpath='/*'");
}
else if (type == "json") {
yqlUri += "&callback=&format=json";
}
...
Anecdote on software usability. FTA: “… and suddenly realized that it was a perfectly ordinary whiteboard felt-tip pen. The headwaiter just draw an ”X” over their booking, directly on the computer screen!”
(via “What’s the waiter doing with the computer screen?” (javlaskitsystem.se))
Elaborating on a previous brief post on the topic of Web Worker initialization race conditions, there's two important points to avoid a race condition when setting up a Worker:
For example the following has no race becaues the spec guarentees that messages posted to a worker during its first synchronous block of execution will be queued and handled after that block. So the worker gets a chance to setup its onmessage handler. No race:
'parent.js':
var worker = new Worker();
worker.postMessage("initialize");
'worker.js':
onmessage = function(e) {
// ...
}The following has a race because there's no guarentee that the parent's onmessage handler is setup before the worker executes postMessage. Race (violates 1):
'parent.js':
var worker = new Worker();
worker.onmessage = function(e) {
// ...
};
'worker.js':
postMessage("initialize");
The following has a race because the worker has no onmessage handler set in its first synchronous execution block and so the parent's postMessage may be sent before the worker sets its onmessage handler. Race (violates 2):
'parent.js':
var worker = new Worker();
worker.postMessage("initialize");
'worker.js':
setTimeout(
function() {
onmessage = function(e) {
// ...
}
},
0);
Automated authors writing books and automated middle men trying to sell over priced books at a profit. The author of the blog post claims to be human, but I’m not so sure.
Implied HTML elements, CSS before/after content, and the link HTTP header combines to make a document that displays something despite having a 0 byte HTML file. Demo only in Opera/FireFox due to link HTTP header support.
As a professional URI aficionado I deal with various levels of ignorance on URI percent-encoding (aka URI encoding, or URL escaping).
Getting into the more subtle levels of URI percent-encoding ignorance, folks try to apply their knowledge of percent-encoding to URIs as a whole producing the concepts escaped URIs and unescaped URIs. However there are no such things - URIs themselves aren't percent-encoded or decoded but rather contain characters that are percent-encoded or decoded. Applying percent-encoding or decoding to a URI as a whole produces a new and non-equivalent URI.
Instead of lingering on the incorrect concepts we'll just cover the correct ones: there's raw unencoded data, non-normal form URIs and normal form URIs. For example:
In the above (A) is not an 'encoded URI' but rather a non-normal form URI. The characters of 'the' and 'path' are percent-encoded but as unreserved characters specific in the RFC should not be encoded. In the normal form of the URI (B) the characters are decoded. But (B) is not a 'decoded URI' -- it still has an encoded '?' in it because that's a reserved character which by the RFC holds different meaning when appearing decoded versus encoded. Specifically in this case, it appears encoded which means it is data -- a literal '?' that appears as part of the path segment. This is as opposed to the decoded '?' that appears in the URI which is not part of the path but rather the delimiter to the query.
Usually when developers talk about decoding the URI what they really want is the raw data from the URI. The raw decoded data is (C) above. The only thing to note beyond what's covered already is that to obtain the decoded data one must parse the URI before percent decoding all percent-encoded octets.
Of course the exception here is when a URI is the raw data. In this case you must percent-encode the URI to have it appear in another URI. More on percent-encoding while constructing URIs later.
Some rights reserved