2016 Jan 19, 10:49 2014 May 22, 9:25
The
DOM location interface exposes the HTML document's URI parsed into its properties. However, it is
ancient and has problems that bug me but otherwise rarely show up in the real world. Complaining about mostly theoretical issues is why blogging exists, so here goes:
- The location object's search, hash, and protocol properties are all misnomers that lead to confusion about the correct terms:
- The 'search' property returns the URI's query property. The query property isn't limited to containing search terms.
- The 'hash' property returns the URI's fragment property. This one is just named after its delimiter. It should be called the fragment.
- The 'protocol' property returns the URI's scheme property. A URI's scheme isn't necessarily a protocol. The http URI scheme of course uses the HTTP protocol, but the https URI scheme is
the HTTP protocol over SSL/TLS - there is no HTTPS protocol. Similarly for something like mailto - there is no mailto wire protocol.
- The 'hash' and 'search' location properties both return null in the case that their corresponding URI property doesn't exist or if its the
empty string. A URI with no query property and a URI with an empty string query property that are otherwise the same, are not equal URIs and are allowed by HTTP to return different content.
Similarly for the fragment. Unless the specific URI scheme defines otherwise, an empty query or hash isn't the same as no query or
hash.
But like complaining about
the number of minutes in an hour none of this can ever change without huge compat issues on the web.
Accordingly I can only give my thanks to Anne van Kesteren and the awesome work on the
URL standard moving towards a more sane (but still working
practically within the constraints of compat) location object and URI parsing in the browser.
2012 Feb 24, 1:44
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:
- The parent starts the communication posting to the worker.
- The worker sets up its message handler in its first synchronous block of execution.
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);
technical programming worker web-worker html script 2011 May 23, 4:26Applying CORS to the media elements: "I've added a content attribute to <img>, <video>, and <audio> that makes the image or media resource be fetched with CORS And have the origin
of the page if CORS succeeded. The attribute is "cross-origin" and it has two allowed values, "use-credentials" and "anonymous". The latter is the default, so you can just say <img cross-origin
src="data.png">."
cors crossdomain web browser webbrowser html technical 2011 Feb 23, 2:17Proposal to standardize on the function to add search providers in user agents.
technical search-provider browser webbrowser web whatwg 2010 Jan 26, 2:00The sandbox attribute for the iframe element sounds like a big pit of issues. Includes a new mime type text/html-sandbox to put on content that shouldn't be rendered as html in browsers that don't
support the sandbox attribute.
html html5 sandbox security web browser iframe mime mimetype html-sandbox technical 2009 Sep 29, 10:54How Firefox and IE7&8 perform feed sniffing
rss feed atom mime mime-sniffing sniffing mimetype web browser html5 technical 2009 Sep 10, 6:42"Although HTML and XHTML appear to have similarities in their syntax, they are significantly different in many ways."
html html5 xml xhtml whatwg wiki technical 2009 Jun 8, 4:56"List of known implementations of HTML 5 in web browsers (list is incomplete, feel free to extend it)"
reference browser html ie8 firefox html5 opera whatwg wiki 2009 Apr 23, 1:35"This e-mail is an attempt to give a relatively concise yet reasonably complete overview of non-Unicode character sets and encodings for 'Chinese characters', excluding those which are not supported
by at least one of the four browsers IE, Safari, Firefox and Opera (henceforth 'all browsers'), and tentatively avoiding technical details which are out of scope for HTML5 unless they are important
to gain a general understanding of the relevant issues."
html html5 iso-2022 charset encoding character unicode cjk 2009 Apr 7, 12:14This makes plenty of sense, that a site should be able to check if a protocol handler exists for some URI scheme, but it'd be nice if this were some sort of declaritive fallback plan rather than
having to do it all with script. "The HTML5 standard function registerProtocolHandler() should probably remain void as in standard, but WhatWG could invent yet another boolean
protocolRegistered("area"), with the only argument (protocol name as string), to check whether a protocol is registered."
html5 registerProtocolHandler html script url uri scheme protocol 2009 Apr 7, 10:04Aggregation of feeds concerning HTML5 including Ian Hickson's, Planet Mozilla, Planet WebKit, the IE Blog, the WHATWG blog, etc etc.
w3c html5 html blog feed daily 2009 Apr 7, 9:02
I'm a big fan of the concept of registerProtocolHandler in HTML 5 and in FireFox 3, but not quite the implementation. From a high level, it allows web apps to register themselves as
handlers of an URL scheme so for (the canonical) example, GMail can register for the mailto URL scheme. I like the concept:
- Better integration of web apps with your system.
- Its easy for web apps to do.
- Links to URNs can now take the user to the sites the user prefers for the sort of thing identified by the URN. For example, if I have a physical address in HTML, instead of making that an http
link to Yahoo Maps, I can make the link a geo scheme URI and those who follow the link will get their preferred mapping site that
has registered for that scheme. Actually, looking at the geo scheme's RFC, maybe I'd rather use some other URN scheme to represent the physical location, but you get the point.
However, the way its currently spec'ed out I don't like the following:
- There's no way to know if you are the handler for a particular URL scheme which is an important question for web app URL protocol handler authors.
- There's no way to fallback to an http URL in the case that a particular URL scheme isn't registered. A suggested solution to testing the registration of a scheme is for browsers to provide an additional script method
to check if a scheme is registered. I don't like the idea of writing script that walks over all my page's links and rewrites them based on that method. I'd much rather see a declarative and
backwards compatible fallback mechanism, although I don't know what that would look like.
- There's no way to register for a namespace within the urn scheme URI, the info scheme URI, or the tag scheme URI. I want to register
info:lccn/... (Library of Congress Card Number identifiers) to LibraryThing or Amazon and I want to register urn:duri:... (dated URIs) to the Web Archive, among other things.
- Will this result in a proliferation of unregistered URL schemes with clashing namespaces? The ESW Wiki notes why this would be bad.
- And last, although this is nitpickier than the rest, I don't like the '%s' syntax used in the registration method. I'd much rather pass in an URL template, like the URL template used
in OpenSearch. If an URL template is used for matching rather than registering against a particular URL scheme, this could also allow for registering a namespace within a URN. For example
something along the lines of:
registerProtocolHandler("info:lccn/{lccnID}", "htttp://www.librarything.com/search_works.php?q={lccnID}", "LibraryThing LCCN")
url template registerprotocolhandler firefox technical url scheme protocol boring html5 uri urn 2009 Feb 3, 11:15"r2719 specifies that browsers should not allow scripts to set document.domain to anything on the Public Suffix List, such as "com" or "co.jp". Essential background reading on why this is dangerous:
Untraceable XSS Attacks. Most browsers already block this attack, e.g. Firefox since 3.0. [Background: Re: Setting document.domain]"
html5 tld publicsuffix dns security html internet web reference w3c 2008 Oct 1, 1:08A weekly summary of the going-ons in the WHATWG usually on the topic of squabbles in HTML5 esp. what to do about the alt attribute in the img tag. Interesting stuff on charsets.
development software whatwg html5 html specification feed rss user-agent w3c 2008 Aug 20, 9:48Apple will or will not license the canvas tag? 'Apple Computer, Inc. ("Apple") believes it has intellectual property rights ("IP Rights") relative to WHATWG's Web Applications 1.0 Working Draft,
dated March 24, 2005, Section 10.1, entitled "Graphics: The bitmap canvas". At this time, Apple reserves all rights in its IP Rights and makes no representations as to Apple's willingness or
unwillingness to license these IP Rights. However, in the event that the Web Applications 1.0 Working Draft, dated March 24, 2005, becomes part of a formalized draft standard at W3C or IETF, for
example, Apple is prepared to address the disclosure/licensing rules of such organizations.'
apple patent html ip html5 canvas whatwg browser browser-war