2016 Jan 27, 7:44 2016 Jan 7, 9:31 2015 Jun 14, 9:20 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.
2013 Aug 29, 7:17
I just got a FitBit One from my wife. Unfortunately I had issues running their app on my Windows 8.1 Preview machine. But I recognized the errors as IE compatibility issues, for instance an IE
dialog popup from the FitBit app telling me about an error in the app's JavaScript. Given
my previous post on WebOC versioning you may guess what I tried next. I
went into the registry and tried out different browser mode and document mode versions until I got the FitBit software running without error. Ultimately I found the following registry value to work
well ('FitBit connect.exe' set to DWORD decimal 8888).
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Main\FeatureControl\FEATURE_BROWSER_EMULATION]
"Fitbit Connect.exe"=dword:000022b8
For
those familiar with the Windows registry the above should be enough. For those not familiar, copy and paste the above into notepad, save as a file named "fitbit.reg", and then double click the reg
file and say 'Yes' to the prompt. Hopefully in the final release of Windows 8.1 this won't be an issue.
2011 Apr 14, 11:27If only all web compat issues were so easily fixed: "If someone knows about any websites I can personally take care of contacting them and trying to get them fixed."
w3c reference file api standard 2011 Apr 4, 10:00
Working on GeolocMock it took me a bit to realize why my HTML could use the W3C Geolocation API in IE9 but not in my WebBrowser control in
my .NET application. Eventually I realized that I was getting the wrong IE doc mode. Reading this old More IE8 Extensibility Improvements IE blog post from the IE blog I found the issue is that for app
compat the WebOC picks older doc modes but an app hosting the WebOC can set a regkey to get different doc modes. The IE9 mode isn't listed in that article but I took a guess based on the values
there and the decimal value 9999 gets my app IE9 mode. The following is the code I run in my application to set its regkey so that my app can get the IE9 doc mode and use the geolocation API.
static private void UseIE9DocMode()
{
RegistryKey key = null;
try
{
key = Registry.CurrentUser.OpenSubKey("Software\\Microsoft\\Internet Explorer\\Main\\FeatureControl\\FEATURE_BROWSER_EMULATION", true);
}
catch (Exception)
{
key = Registry.CurrentUser.CreateSubKey("Software\\Microsoft\\Internet Explorer\\Main\\FeatureControl\\FEATURE_BROWSER_EMULATION");
}
key.SetValue(System.Diagnostics.Process.GetCurrentProcess().MainModule.ModuleName, 9999, RegistryValueKind.DWord);
key.Close();
}
weboc fck ie document mode technical ie9 2010 Aug 13, 11:47Other characters sets for HTTP headers: "By default, message header field parameters in Hypertext Transfer Protocol (HTTP) messages cannot carry characters outside the ISO-8859-1 character set. RFC
2231 defines an encoding mechanism for use in Multipurpose Internet Mail Extensions (MIME) headers. This document specifies an encoding suitable for use in HTTP header fields that is compatible with
a profile of the encoding defined in RFC 2231."
rfc language localization charset http technical reference http-header 2010 Feb 25, 4:10Comcast is running an opt-in DNSSEC trial for all Comcast customers. Their FAQ covers the incompat. of DNSSEC with their Comcast Domain Helper (typo DNS redirects to Comcast ads... bleh!): "What
happens to Comcast Domain Helper, which offers DNS redirect services, when you fully implement DNSSEC? We believe that the web error redirection function of Comcast Domain Helper is technically
incompatible with DNSSEC. Comcast has always known this and plans to turn off such redirection when DNSSEC is fully implemented." Yay!
dns dnssec comcast faq internet ip security technical 2009 Nov 17, 6:52"What if there was a backwards compatible way to transfer all of the resources that are used on every single page in your site — CSS, JS, images, anything else — in a single HTTP request at the start
of the first visit to the page? This is what Resource Package support in browsers will let you do." Another resource packaging implementation but this suggests they'll actually implement this in
FireFox. One issue with all of these is you can't use the resources from the package in any context that didn't ask to use the package for fear of security issues which means you can't stick the
packaged resources in your HTTP cache. The package itself could go in the cache which would mean multiple packages per page or all your page's resources in one package. Of course the same security
issues are a concern for all of the packaging proposals if a site has any way to inject into the source the request for the package. It'd be a similar vector to the UTF7 XSS issues but much worse
attack.
security web browser http zip firefox resource technical via:kris.kowal 2009 Oct 7, 8:10Quirksmode does a chart comparing the differences in various versions of WebKit: "There’s iPhone WebKit, Android WebKit, S60 WebKit (at least two versions each), Bolt, Iris, Ozone, and Palm Pre, and
I don’t doubt that I’ve overlooked a few minor WebKits along the way. All 10 mobile WebKits I’ve identified so far are subtly or wildly different."
compatibility web development browser webkit apple google android iphone safari technical via:mattb 2009 Jun 22, 3:12HTML5's mime-sniffing is getting moved to an IETF doc: "Many web servers supply incorrect Content-Type headers with their HTTP responses. In order to be compatible with these servers, user agents
must consider the content of HTTP responses as well as the Content-Type header when determining the effective media type of the response. This document describes an algorithm for determining the
effective media type of HTTP responses that balances security and compatibility considerations."
mime mime-sniffing ietf http w3c html5 technical 2009 May 3, 4:42A comparison of the implementation status of various CSS features across mobile browsers.
via:connolly css html browser web mobile android google iphone compatibility 2009 Apr 23, 2:22Review of mime sniffing based XSS attacks with recommended protections for both web sites and browsers. Also, surprising to me since I rarely see it in this sort of a paper, thought and stats on the
compat. affects of their recommended changes for browsers. Very happy to see that in there!
web security ie browser xss sniff mime firefox chrome safari html html5 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 Mar 23, 11:06The HTML5 spec tells us how it is in the real world for URLs: "This specification defines various algorithms for dealing with Web addresses intended for use by HTML user agents. For historical
reaons, in order to be compatible with existing Web content HTML user agents need to implement a number of processes not defined by the URI and IRI specifications [RFC3986], [RFC3987]."
html html5 url uri reference w3c 2008 Aug 29, 10:31Differences between Microsoft's JScript and the ES3 standard with example output from all major browsers on each point.
microsoft development jscript javascript standard reference programming browser ie8 es3 compatibility 2008 May 30, 1:36Killbits: "This article describes how to stop an ActiveX control from running in Microsoft Internet Explorer and in Windows Internet Explorer. You can do this by modifying the data value of the
Compatibility Flags DWORD value for the Class identifier (CLS
security ie killbit msdn microsoft windows browser reference 2008 May 12, 4:05
Sarah and I have finished playing through the games "Paper Mario", "Paper Mario: The Thousand-Year Door", and "Super Paper Mario" last week (including the various Pits of 100 Trials). We played
them all on the Wii, because even though Super Paper Mario was the only one released explicitly for that platform, Wii maintains compatibility with Game Cube games such as Thousand-Year Door and
Paper Mario although originally released for the Nintendo 64 is now available as a pay for download game on the Wii's Virtual Console. So, yay for Nintendo!
I think my favorite of the three is Thousand-Year Door mostly because of the RPG attack system. In Thousand-Year Door and Paper Mario when you come into contact with an enemy you go into an RPG
style attack system where you take turns selecting actions. In Super Paper Mario you still have hit points and such, but you don't go into a turn based RPG style attack system, rather you do the
regular Mario jumping on bad guys thing (or hitting them with a mallet etc...). Thousand-Year Door and Paper Mario are very similar in terms of game play but Thousand-Year Door looks very pretty
and has made improvements to how your party-mates are handled in battle (they have HP and can fall as you would expect) and there's an audience that cheers you on during your battles.
Even if the gameplay sucked the humor throughout the series might be tempting enough. Mario's clothing and mustache are mocked throughout and standard RPG expectations are subverted. I hate to
describe any of these moments for fear of ruining anything but, for instance, an optional and very difficult enemy who may only be killed after hours of work only results in one experience point,
or a very intimidating enemy who you imagine you'll have to fight actually challenges you to a quiz.
Despite how I personally rank them, all the games are great and I'd recommend any of them.
mario videogame paper mario nontechnical