Thursday, January 8th, 2009
Category: Ajax
, HTML
John Allsopp has a thoughtful piece that races some old concerns about the new tag set in HTML 5, and how we will ever be able to jump on that train when the cabooze still has IE.old train cars.
It is great to have new semantics for <section> and all, but what will browsers do with these new tags?
John walks through a simple example with the new tags, shows some issues, and then wonders if we could use the existing extension points (attributes):
Let’s invent a new attribute. I’ll call it “structure,” but the particular name isn’t important. We can use it like this:
<div structure="header">
Let’s see how our browsers fare with this.
Of course, all our browsers will style this element with CSS.
But how about this?
div[structure] {font-weight: bold}
In fact, almost all browsers, including IE7, style the div with an attribute of structure, even if there is no such thing as the structure attribute! Sadly, our luck runs out there, as IE6 does not. But we can use the attribute in HTML and have all existing browsers recognize it. We can even use CSS to style our HTML using the attribute in all modern browsers. And, if we want a workaround for older browsers, we can add a class value to the element for styling. Compare this with the HTML 5 solution, which adds new elements that cannot be styled in Internet Explorer 6 or 7 and you’ll see that this is definitely a more backward-compatible solution.
John then goes on to discuss the potential use of the role attribute, and more.
It feels like there are two issues here:
- Are new tags the right way to provide new semantic value
- Are there work arounds to back/forward compatibility.
Without compatibility, it will be impossible to get this off the ground for many people. What if we mix both worlds, and a shim is put in place to convert the new tags to divs and the like at runtime for browsers that don't support it. Is that enough?
You can get IE to support new tags as shown in this example by using document.createElement().
Category: Design, HTML
There are a slew of HTML/CSS design sharing template sites out there. What if there was a manifest that defined what they had, and tools could work with that so you could import repositories.
That is the vision that Daniel Glazman had when just created the HTML+CSS Templates Manifest 1.0 CC licensed spec.
You would end up with a file that looks like the example:
HTML:
-
-
<templates xmlns="http://disruptive-innovations.com/zoo/templatesManifest/1.0">
-
<template shortname="aFarewellToColor">
-
<title xml:lang="en">A Farewell to Color
</title>
-
<description xml:lang="en">
-
<p>Remember the early days when the Internet was all black and white,
-
this is a throwback to those days. In all seriousness, I made this
-
template because it was based on an earlier design that many found
-
useful. Plus I've always had a thing for creating designs on the web
-
with zero color, I guess it is an 'off the beaten path type deal'.</p>
-
<p>I should also mention that this template has some updates (err...
-
advantages) over the previous designs... this one uses h1 and h2
-
tags in the header for better SEO results, and has new image
-
rollovers for the navigation.</p>
-
</description>
-
-
<author>Bryant Smith</author>
-
<version>1.0</version>
-
-
<!-- the following URL does not exist (yet) -->
-
<license>http://bryantsmith.com/template/license.txt</license>
-
<website>http://bryantsmith.com/template/</website>
-
<support>http://bryantsmith.com/component/option,com_alfcontact/Itemid,55/</support>
-
<demo>http://bryantsmith.com/template/afarewelltocolor</demo>
-
-
<thumbnail>http://bryantsmith.com/template/previews/afarewelltocolor.jpg</thumbnail>
-
-
<package>http://bryantsmith.com/template/afarewelltocolor.zip</package>
-
<path>index.html</path>
-
<size>228275</size>
-
-
<tags>gray,menus</tags>
-
<format>xhtml</format>
-
<width>750px</width>
-
<columns>1</columns>
-
<sidebars>0</sidebars>
-
<direction>ltr</direction>
-
</template>
-
</templates>
-
And, if you are into design, the OmniGraffle wireframe stencils have been updated!
Friday, December 19th, 2008
Category: HTML
Mark Pilgrim has a new episode of This Week in HTML 5 that covers the onbeforeunload event. To get there, a lot happened, which Hixie explained:
Someone asked for onbeforeunload, so I started fixing it. Then I found that there was some rot in the drywall. So I took down the drywall. Then I found a rat infestation. So I killed all the rats. Then I found that the reason for the rot was a slow leak in the plumbing. So I tried fixing the plumbing, but it turned out the whole building used lead pipes. So I had to redo all the plumbing. But then I found that the town's water system wasn't quite compatible with modern plumbing techniques, and I had to dig up the entire town. And that's basically it.
After going into the detail of the actual unraveling, Mark gets to the skinny:
The most interesting part of this new definition is the script group, a new concept which now governs all scripts. When a Document is created, it gets a fresh script group, which contains all the scripts that are defined (or are later created somehow) in the document. When the user navigates away from the document, the entire script group is frozen, and browsers should not execute those scripts anymore. This sounds like an obvious statement if you think of documents as individual browser windows (or tabs), but consider the case of a document with multiple frames, or one with an embedded iframe. Suppose that the user clicks some link within the iframe that only navigates to a new URL within the iframe (i.e. the parent document stays the same). The parent document may have some reference to functions defined in the old iframe. Should it still be able to call these functions? IE says no; other browsers say yes. HTML 5 now says no, because when the iframe navigates to a new URL, the old iframes script group is frozen -- even if there are active references to those scripts (say, from the parent document), browsers shouldn't allow the page to execute them.
The main benefit of this new concept of script groups is that it removes a number of complications faced by the non-IE browsers. For example, it prevents the problem of scripts suddenly discovering that their global object is no longer the object that they think of as the Window object. Script groups are also frozen when calling document.open(). Freezing script groups also defines the point at which timers and other callbacks are reset, which is something that previous versions of HTML had never defined.
In related news, Jacob Gube has a guest post on RWW covering 5 Exciting Things to Look Forward to in HTML 5.
Friday, December 5th, 2008
Category: HTML
Ben Turner posted on Web Workers being available in the upcoming beta2 using the latest spec:
First, we’ve moved away from the old Gears-esque API that we had in Alpha 2 (see previous post) in favor of the emerging Web Workers standard. We’ve been hard at work with folks from Google, Apple, and others to get this new spec nailed down.
Most of the missing features I identified in Part 1 have been added with the exception of auto-JSON. There will be a very few small changes between Beta 2 and Firefox 3.1 final (most of which have already landed) and I’ll post about those again once we’re close to shipping.
So what’s available in Beta 2? We currently implement this subset of the Web Workers spec. Very briefly, creating a new worker is as simple as adding the following line to your web page’s script:
var worker = new Worker("workerScript.js");
Your workerScript.js file can do almost anything, really, including using XMLHttpRequest, importing additonal scripts, spawning new workers, setting timeouts/intervals, and passing complex messages via JSON. Further information can be found in Using DOM Workers.
And, in case anyone is interested in a more real-world example, I ported Chris Double’s JavaScript 8080 emulator to use Workers. The nice thing about using workers here is that all the actual emulation is happening on a background thread (or, on my machine, a second CPU). Keystrokes are sent as messages to the emulator thread and then emulator sends screen updates back (all using JSON). It also uses the importScripts function to load Chris’s hosted files rather than having to copy them around. Note that I didn’t bother with very serious error checking so unless you’re using Firefox 3 Beta 2 or newer then it most likely won’t work at all. Check it out here.
It is interesting to crack open the spec an see how it has been updated. It fills really well integrated with other parts of HTML 5. You can share workers cleanly, open a local database directly, show notifications, and import Scripts. Looks really nice.
Thursday, December 4th, 2008
Category: HTML
Henri Sivonen has posted an exprimental Gecko build that parses HTML 5:
The level of quality is “It runs and some pages render!” This build is not at all suitable for normal browsing use. Please don’t use it with your usual Firefox profile. There are numerous known issues starting with bogus memory management (leaking everything in the parser!), lack of fragment parsing support, lack of quirks mode, HTML elements being represented as DOM nodes that behave like XHTML elements and the integration with CSS layout being inefficient. The baseline Gecko source isn’t synced with the trunk, so the other parts of Gecko don’t have all the latest patches. The parser doesn’t reflect the most recent spec changes. meta element-based encoding declarations and BOM sniffing don’t work.
If a page doesn’t render, try reloading or navigating back and forth.
For background, please refer to a recent
newsgroup posting of mine. (Summary: The parser core is mechanically translated from the Validator.nu HTML Parser.)
Sam Ruby talked a little about the implementation:
He starts from a single source, in Java. The Java code can be compiled to Java byte codes, JavaScript source, or C++ presumably making use of Mozilla libraries for things such as memory management. If he can do that, it seems to me to be a rather small leap from there to producing C++ using, say, either Ruby or Python libraries for memory management, as well as a thin binding to the language. C# would also be a reasonable target.
If this could be done, and made available under a liberal license, it could go a long way towards making available consistent and performant implementations of the HTML5 parser algorithm everywhere.
Tuesday, December 2nd, 2008
Category: HTML, Standards
Mark Pilgrim has a new This Week in HTML 5 that features a bit new proposal for integrating HTTP authentication with HTML forms.
A common use for forms is user authentication. To indicate that
an HTTP URL requires authentication through such a form
before use, the HTTP 401 response code with a WWW-Authenticate challenge "HTML" may be used.
For this authentication scheme, the framework defined in RFC2617
is used as follows. [RFC2617]
challenge = "HTML" [ form ]
form = "form" "=" form-name
form-name = quoted-string
The form parameter, if
present, indicates that the first form element in the
entity body whose name is the
specified string, in tree order, if any, is the login
form. If the parameter is omitted, then the first form
element in the entity body, in tree order, if any, is
the login form.
There is no credentials production for this
scheme because the login information is to be sent as a normal form
submission and not using the Authorization
HTTP header.
Mark then goes on to say:
This idea has been kicked around for more than a decade. Microsoft wrote User Agent Authentication Forms in 1999. Mark Nottingham asked the WHATWG to investigate the idea in 2004. Better late than never, Ian Hickson summarizes the feedback to date. No doubt this new proposal will generate further discussion. No browsers currently support this proposal.
The idea makes total sense to me. The old HTTP BASIC style of authentication is a dying bread due to the annoying popup style and implementation. It needs a shake up, don't you think?
Friday, November 28th, 2008
Category: HTML, JavaScript
Greg Reimer is doing really interesting work with reglib and he now has a neutral post on events and how he favours the pattern of mouse enter / leave to mouse over / out.
He shows an example using the pyramid illustrations (as above) and then ends with:
The title of this post is a bit misleading. The mouseenter/leave events are never used. It's all still accomplished via mouseover/out, but there's enough information available in the handling element, event.target and event.relatedTarget elements--and their positions relative to each other--to know whether to execute the handler. Since the actual mouseenter/leave events don't bubble, and in any case are IE-only, reglib wants nothing to do with them. This code is checked in to the trunk, and with a little more testing will be released as reglib version 1.0.5.
One thing also, I'd be curious to know if anybody knows of a reason this would be *undesirable* behavior.
What do you think?
Category: HTML
That is what HTML 5 defines, and Dustin Diaz agrees as he lays down the skinny:
Doctypes have long been in standardista discussions circles. Why to use them. Which one to use. Which one is best. These are all <sarcasm>really fun details</sarcasm> to get into, but the most important aspect of any doctype is simply having one, since without one, you’re stuck in the lovely world of “quirks mode”. If you’re interested in understanding the anatomy of a doctype, then by all means, dive in.
There is really, absolutely no reason you need the rest of the doctype in your declaration unless you’re validating code. Furthermore, it does not mean that your page is even invalid. In the end, it puts your webpages into standards mode, which is what really matters. (Plus it’s easy to memorize ;)
Try it out. It will fix your box model in IE6 and clobber all those other funny gotchas when you’re in quirks mode. Cheers.
Do you concur?
Thursday, November 20th, 2008
Category: Firefox, HTML
Via Myk Melez comes word that Firefox 3 supports HTML 5 web protocol handlers, which I had not realized before. These are really nifty:
JAVASCRIPT:
-
window.navigator.registerProtocolHandler("mailto",
-
"https://www.example.com/?uri=%s",
-
"Example Mail");
This code creates a protocol handler for www.example.com that makes mailto links direct the user to the www.example.com web application, inserting the link into the URL given replacing the %s value. The final argument is the title of the protocol handler to present to the user.
There are obviously security limitations around this:
Note: Web sites may only register protocol handlers for themselves. For security reasons, it's not possible for an extension or web site to register protocol handlers targeting other sites...The URL template supplied when registering must be of the same domain as the webpage attempting to perform the registration or the registration will fail. For example, http://example.com/homepage.html can register a protocol handler for http://example.com/handle_mailto/%s, but not for http://example.org/handle_mailto/%s.
The user will be prompted on whether they want to allow this protocol handler:
Now, when the user clicks on a link that has a registered protocol handler, they will be prompted on how to work with it:
This feature is documented in the HTML 5 spec. You can find documentation on Firefox's implementation here and here.
Category: HTML
Mark Pilgrim is back telling us what is new in the world of HTML 5 and focuses on changes with the video tag and API:
The big news this week is a major revamping of how browsers should process multimedia in the <audio> and <video> elements.
r2404 makes a number of important changes. First, the canPlayType() method has moved from the navigator object to HTMLMediaElement (i.e. a specific <audio> or <video> element), and it now returns a string rather than an integer. [canPlayType() discussion]
The canPlayType(type) method must return the string "no" if type is a type that the user agent knows it cannot render; it must return "probably" if the user agent is confident that the type represents a media resource that it can render if used in with this audio or video element; and it must return "maybe" otherwise. Implementors are encouraged to return "maybe" unless the type can be confidently established as being supported or not. Generally, a user agent should never return "probably" if the type doesn't have a codecs parameter.
Wait, what codecs parameter? That's the second major change: the <source type> attribute (which previously could only contain a MIME type like "video/mp4", which is insufficient to determine playability) can now contain a MIME type and a codecs parameter. As specified in RFC 4281, the codecs parameter specifies the specific codecs used by the individual streams within the audio/video container. The section on the type attribute contains several examples of using the codecs parameter.
Video and the Open Web is a huge issue. The idea of having video be a native object that other components can integrate with (e.g. rotate in canvas) is great. We need codecs implemented. We need penetration. We need more.
Wednesday, November 19th, 2008
Category: Editorial, Flash, HTML
As it is Adobe MAX this week, there is a lot of talk about the Flash platform. How does this relate to the Open Web? Well, it turns out that Dion and I have been discussing how Flash can join and become a part of the Open Web.
Dion kicks things off with his blog post "The Flash Platform: How Adobe could join the Open Web to take on...". He first talks about how developers see Flash today versus other options:
Adobe (via Macromedia) has traditionally been a Web designer company, but developers haven’t jumped in to the same degree (note: not to say they haven’t been wildly successful!). I think that the perception is something like this:
Dion discusses how Adobe has an opportunity to position themselves relative to Silverlight much more strongly in the Open Web camp:
With Silverlight making a huge charge I worry about a world where you have “Best viewed in Silverlight and IE” (which in fact is “only viewed in…”) and people often ask: “But isn’t Flash just as bad?”
Adobe has an opportunity here. They can move to the right and Flash could become strongly in the Open Web camp. Then we would all be stronger as we come up against Silverlight :)
The next logical question related to this is open sourcing Flash:
The conversation tends to end up with opensourcing Flash, which I think will happen at some point through necessity, and the sooner the better (for everyones sake). Flex has a loyal base and has some open source help, but hasn’t gotten the love that it could get because it sits on top of something that isn’t open source itself. It is hard to get excited about an open source tech that sits on top of the same vendors proprietary platform!
I agree with Dion that open sourcing Flash and having it join the Open Web camp is a very compelling idea. Open source would just be the first step, though, so following up on Dion's post I put together an editorial titled "How Flash Can Integrate With The Open Web":
As Dion points out open sourcing Flash is one big part of making this happen, but another huge aspect would be to have Flash and Flex integrate better into the web stack and be less of a 'black box' on the screen...The important point is to integrate Flash and Flex more deeply into how the Open Web works:
- Cross-Platform Standards
- No Vendor Lock-in
- Anyone Can Innovate
- Powerful, Universal Clients
- Open Source Implementations
- Mashable, Searchable, and Integrated
I give a list of suggested ways to do this; the important thing is to have Flash integrate more deeply -- these are just some suggestions to kick things off. Here are some of them; click on them to read more in-depth how this might work:
I wrap up with a conclusion:
At the end of the day Adobe is a tools company, a really damn good tools company actually. Doing the above should allow Adobe to continue creating powerful tools that help authors and content creators while expanding the size of the market they can target.
The above list was just a suggestion to kick things off. The real focus is on having Flash integrate into the web stack better itself (and evolving both Flash and the web stack themselves into the future).
How do you see this happening?
Tuesday, November 18th, 2008
Category: HTML
One of the cool new features in HTML 5 is Cross Document Messaging. What makes this feature really nice is that all the next-generation browsers support it: Internet Explorer 8, Firefox 3, Opera 9, and Safari nightly. Facebook is already using this feature, for example, in order to support web-based instant messaging.
Austin Chau put together a nice simple demo and blog post showing how easy it is to use this new feature:
The demo demonstrates how easy it is for two iframes of different origins to talk to each other. In real time, each iframe is passing its own mouse coordinates from the onmousemove event to each other...The basic semantic is to use postMessage() to send data to a window object and the receiving window should register for the "onmessage" event to receive data.
In the demo Austin creates two iframes that communicate using postMessage in order to broadcast the mouse's coordinates:
JAVASCRIPT:
-
window.document.onmousemove = function(e) {
-
var x = (window.Event) ? e.pageX : window.event.clientX;
-
var y = (window.Event) ? e.pageY : window.event.clientY;
-
-
// this send data to the second iframe of the current page
-
window.parent.frames[1].postMessage('x = ' + x + ' y = ' + y, '*');
-
};
-
-
var onmessage = function(e) {
-
var data = e.data;
-
var origin = e.origin;
-
document.getElementById('display').innerHTML = data;
-
};
-
-
if (typeof window.addEventListener != 'undefined') {
-
window.addEventListener('message', onmessage, false);
-
} else if (typeof window.attachEvent != 'undefined') {
-
window.attachEvent('onmessage', onmessage);
-
}
Austin found that he has to use addEventListener instead of doing inline event handlers for things to work correctly:
One thing to beware of is that for some reason it would not receive data properly if you use the traditional event listener setup, you have to use addEventListener()
See the source code and the full blog post.
Are you planning to use postMessage in your own projects? If so, how?
[Disclosure: I work with Austin at Google on the Open Web Advocacy team]
Tuesday, November 11th, 2008
Category: HTML, Standards
In Mark's latest installment of This Week in HTML 5 he delves into what ISN'T in the spec:
It has been suggested (1, 2, 3, &c.) that HTML 5 is trying to bite off more than it can metaphorically chew. It is true that it is a large specification, and it might benefit from being split into several pieces. But it is not true that it includes everything but the kitchen sink.
For example, HTML 5 will not
