The big news this week is the disclosure of a vulnerability that researchers have dubbed “clickjacking.” To understand it, start with Giorgio Maone’s post, Clickjacking and NoScript. Giorgio is the author of the popular NoScript extension for Firefox. In its default configuration, NoScript protects against this vulnerability on most sites in most situations; you can configure it to defeat the attack entirely, but only at the cost of usability and functionality.
Using Javascript hacks to detect that window.top != window to inhibit rendering, or override window.top.location. These mechanisms work only if Javascript is enabled, however, and are not guaranteed to be reliable or future-safe. If the check is carried on every UI click, performance penalties apply, too. Not to mention, the extra complexity is just counterintuitive and weird.
Requiring non-trivial reauthentication (captcha, password reentry) on all UI actions with any potential for abuse. Although this is acceptable for certain critical operations, doing so every time a person adds Bob as a friend on a social networking site, or deletes a single mail in a webmail system, is very impractical.
Worried yet? Now let’s turn to the question of what browser vendors can do to mitigate the vulnerability. Michal offers several proposals. It is important to realize that none of these proposals have been implemented yet, so don’t go rushing off to your text editor and expecting them to do something useful.
Ian Hickson gave a great presentation at Google where he just sat down, opened up Emacs, and started to build demos on the fly that use HTML 5 features. His goal was to use browsers available today (albeit nightlies and such for some of them) to show progress.... so no future tense!
There are a substantial number of iPhone apps that tie into the builtin native components such as the camera.
Brad Lassey has been hacking on Fennec (the Mozilla mobile browser) as well as Firefox itself to integrate with camera phones and Webcams alike:
I wrapped a video tag, image and a few buttons in xbl and bound it to <input type=”camera” />. When a user hits a website using this tag, he or she currently will see a live video preview and a “take photo” button. When the user clicks the button, the photo is grabbed from the camera and shown to the user in the image element. The image element and video element are in a deck element so only one is shown at a time. After the photo is taken, there is a button that reads “Take another photo,” in case the user doesn’t like the one they just took. Once the user is satisfied, this element works like any other form element and the file can be uploaded to a web service.
After talking to a few people this should actually be bound to <input type=”file” accept=”image/png”/>. Also, it needs some UI design both for what it looks like in content and for a configuration dialog. Finally, we’ll need to think about security and make sure no one can snap a photo of you when you’re not looking your best.
I kinda like having an input type="camera" myself, to be more explicit. It would be cool if you can get access to the image as data (e.g. the value is data:......). I love it.
The form attribute on various elements, which associates an element with its parent form, and the elements attribute of the form element, which associates the form with its elements. (Form-associated elements no longer need to be children of the <form> element itself within the DOM, so explicit association is required. Form-associated elements that are DOM children of the <form> element are implicitly associated, so your existing markup will continue to work the way you think it does.) [r2157]
There have been some clever tricks to create new custom tags in Internet Explorer, such as the createElement trick. However, I never realized that Internet Explorer itself provides a facility to define new tags in the markup and have them styled, since Internet Explorer 5!
Some details from the MSDN documentation on this feature, titled "Using Custom Tags In Internet Explorer". The trick lies in making sure you namespace things. For example, in the MSDN docs for this feature the example of creating a new JUSTIFY tag is given:
<HTML XMLNS:MY>
<MY:JUSTIFY>
This paragraph demonstrates sample
usage of the custom MY:JUSTIFY tag in a document.
By wrapping the paragraph in start and end
MY:JUSTIFY tags, the contained
text is justified within the specified width. Try
resizing the window to verify that the
content is justified within a 500-pixel width.
And don't forget to right-click anywhere on the
window and "View Source".
</MY:JUSTIFY>
The docs then go on to discuss applying an Internet Explorer 'behavior' to this custom element to give it expanded abilities:
Custom tags become much more interesting when applied with a DHTML behavior. Introduction to DHTML Behaviors (or behaviors) are applied to elements on a page, the same way styles are, using cascading style sheets (CSS) attributes. More specifically, the proposed CSS behavior attribute allows a Web author to specify the location of the behavior and apply that behavior to an element on a page.
Using DHTML in Internet Explorer 4.0.0, it is possible to create simple animated effects, such as flying text, by manipulating the position of elements on a page over time. Beginning with Internet Explorer 5, this functionality can be encapsulated in a behavior, applied to a custom <InetSDK:FLY> tag, and wrapped around blocks of text on a page. This can be applied to cause text to fly from various directions.
I'm going to do more testing on this functionality today to see how deep it goes, but if true it makes it easier to create browser shims for Internet Explorer for things like SVG, MathML, etc., including HTML 5 (if we namespace the HTML 5 elements, required to get this to work).
The reason I'm looking for an alternative to the createElement trick is I've found that it doesn't work with nested custom tags, which limits its usefulness. For example, I've found the following to not enter the DOM correctly:
The other major news this week is the addition of the hashchange event, which occurs when the user clicks an in-page link that goes somewhere else on the same page, or when a script programmatically sets the location.hash property. This is primarily useful for AJAX applications that wish to maintain a history of user actions while remaining on the same page. As a concrete example, executing a search of your messages in GMail takes you to a list of search results, but does not change the URL, just the hash; clicking the Back button takes you back to the previous view within GMail (such as your inbox), again without changing the URL (just the hash). GMail employs some nasty hacks to make this work in all browsers; the hashchange event is designed to make those hacks slightly less nasty. Microsoft Internet Explorer 8 pioneered the hashchange event, and its definition in HTML 5 is designed to match Internet Explorer's behavior.
The purpose of defining an event loop is to unify the definition of things that happen asychronously. (I want to avoid saying "events" since that term is already overloaded.) For example, if an image defines an onload callback function, exactly when does it get called? Questions like this are now answered in terms of queueing tasks in the event loop.
Thanks again to Mark for doing the work so we don't have too. After seeing three episodes, it is interesting to see the velocity of changes in the spec. Kudos to the group for that.
Henri Sivonon has taken Hixie’s Live DOM Viewer, and is now running the Validator.nu HTML Parser within it, using GWT 1.5 RC2, which fixed a bug to do with JavaScript in hosted mode.
The navigator attribute of the Window interface must return an instance of the Navigator interface, which represents the identity and state of the user agent (the client), and allows Web pages to register themselves as potential protocol and content handlers.
Currently, HTML 5 defines four properties and two methods:
appName
appVersion
platform
userAgent
registerProtocolHandler
registerContentHandler
This is only a subset of navigator properties and methods that browsers already support. See Navigator Object on Google Doctype for complete browser compatibility information.
I am really jazzed about the first entry in a new series on HTML 5. Mark Pilgrim (of Python, Greasemonkey, Open Web, writer extraordinaire, and creator of Google Doctype) has started the series This Week in HTML 5 which aims to keep us up to speed on the spec, and progress across the board (what are browsers implementing etc).
In the first episode he discusses the progress with workers, interesting clarification around providing text instead of images, and more.
Anyway, over to Mark:
The biggest news is the birth of the Web Workers draft specification. Quoting the spec, "This specification defines an API that allows Web application authors to spawn background workers running scripts in parallel to their main page. This allows for thread-like operation with message-passing as the coordination mechanism." This is the standardization of the API that Google Gears pioneered last year. See also: initial Workers thread, announcement of new spec, response to Workers feedback.
Additionally, the spec now tries to define what authors should do if they know they have an image but don't know what it is. Quoting again from the spec:
If the src attribute is set and the alt attribute is set to a string whose first character is a U+007B LEFT CURLY BRACKET character ({) and whose last character is a U+007D RIGHT CURLY BRACKET character (}), the image is a key part of the content, and there is no textual equivalent of the image available. The string consisting of all the characters between the first and the last character of the value of the alt attribute gives the kind of image (e.g. photo, diagram, user-uploaded image). If that value is the empty string (i.e. the attribute is just "{}"), then even the kind of image being shown is not known.
If the image is available, the element represents the image specified by the src attribute.
If the image is not available or if the user agent is not configured to display the image, then the user agent should display some sort of indicator that the image is not being rendered, and, if possible, provide to the user the information regarding the kind of image that is (as derived from the alt attribute).
Great to see this series kick into gear, and having Mark keep us in the loop on the very important HTML 5 effort.
Michael Mahemof is working a lot with TiddlyWiki and posted on how the project injects HTML into an iframe, and then get them out later. This enables you to use the browser parser to do its thing:
In IE8 mode, we provide support for script to update the travel log components (for e.g. back/forward buttons, address bar) to reflect client-side updates to documents. This allows a better user experience where users can navigate back and forth without messing the AJAX application state.
What is interesting here is that even though Sharath said: "adopted in IE8 from HTML5" we have Richard Monson-Haefel (Curl evangelist) saying Ajax is dead RIA walking. This strong conclusion comes from the fact that IE implemented an HTML 5 feature???
The Open Web always has baggage from the fact that there are many parties involved, but the benefits have always made it win out. The browser is the virtual machine of the Web. While Richard thinks that fragmentation can kill Ajax, I see a brighter picture. We have HTML 5 to look at, and browser are innovating in interesting ways. That is a good thing. It pushes us forward.
It is interesting that the articles pushed are on Silverlight using this for its own goals, but Sorry Richard, this doesn't mean people will be learning Curl :)
