Modernizr is a new library that detects various HTML5 and CSS3 features and lets you know so you can use them:
Writing conditional CSS with Modernizr
Now, once your page loads, Modernizr will run and go through all of its tests. It will automatically add all the classes to the <body> element of the page, and these classes will be along the lines of body.feature or body.no-feature, with the former indicating that the current browser supports that specific feature and the latter indicating that the browser does not support the feature.
Additionally, it will create a new JavaScript object in the global scope, called Modernizr. This object will contain properties for each of the features that Modernizr detects for, and their value will be set to TRUE or FALSE depending on the browser's support for it.
What you can do from this point on is write pseudo-IF/ELSE statements in your CSS. Let's look at an example from the Modernizr.com site itself:
In the above example, we're doing an "IF" condition in CSS: IF the browser supports both CSS gradients, THEN apply this background property to the #main element (instead of the original background property).
Writing conditional JavaScript with Modernizr
When leveraging Modernizr in your JavaScript, it's as straight-forward as it can be to do IF-conditions based on what the browser currently supports:
We are seeing a growth in these kinds of tools and shims to get HTML5 features into developers hands. Another great site to help is the new HTML5 Doctor.
Why is it that the person who is the center of this process is allowed to be a man who rejects consensus, actively denies issues (based on his own admitted policy) and substitutes expert advice in important areas like accessibility with analyzing data from the Google Index and parsing numbers? Numbers that we cannot have a third party confirm because every request to do just this is ignored?
There is no doubt in my mind that Ian is brilliant. However no man, no matter how brilliant, should be allowed to be so influential on a spec when he is bringing all this baggage to the table with him.
The number of grievances folks have with any standards process are legion, but wouldn't life be more fun if they all came with comics?
(As I wrote this, Dion leaned over and said, "I used to work with Ian, I find it funny to think of anyone trying to control him.")
Annotate structured data that HTML has no semantics for, and which nobody has annotated before, and may never again, for private use or use in a small self-contained community.
He goes on to detail a number of scenarios such as this subset:
A group of users want to mark up their iguana collections so that they can write a script that collates all their collections and presents them in a uniform fashion.
A scholar and teacher wants other scholars (and potentially students) to be able to easily extract information about what he teaches to add it to their custom applications.
The list of specifications produced by W3C, for example, and various lists of translations, are produced by scraping source pages and outputting the result. This is brittle. It would be easier if the data was unambiguously obtainable from the source pages. This is a custom set of properties, specific to this community.
<p>Hedral is a male american domestic shorthair, with a fluffy black
fur with white paws and belly.</p>
<imgsrc="hedral.jpeg"alt=""title="Hedral, age 18 months"
class="photo"/>
</section>
and extract:
Cat name: "Hedral"
Description: "Hedral is a male american domestic shorthair, with afluffy black fur with white paws and belly."
Image: "http://example.org/hedral.jpeg"
Here is where the fun begins as Ian walks through the issues with the microformat-esque approach, namely the overloaded "class":
there is no way for a parser to know which classes are properties of cats and which are just for styling (e.g. 'photo' used in this example).
I have to admit that I think the baby could be thrown out with the bathwater here. I would hate to see class="cat" type="cat" for example!
<p>I love my cats. My oldest cat is <span property="com.damowmow.name">Silver</span>. <span property="com.damowmow.desc">Silver is <span property="com.damowmow.age">11</span> years old and refuses to eat
alone, always waiting for either Yellow or Blue to eat with
I don't miss the com.* world of Java. I hate the verboseness. It looks so ugly to compare "com.mycompany.foo.cat" to "cat". Is it just me?
Hixie then concludes:
To address this use case and its scenarios, I've added to HTML5 a simple
syntax (three new attributes) based on RDFa. It doesn't have the full
power of RDF, because that didn't seem to be necessary to address the use
cases. It doesn't really have anything in common with Microformats; I
didn't find the Microformats syntax to be very convenient. (This was also
the experience with eRDF.)
I expect the syntax will need adjustments over the coming weeks to address
issues that I overlooked. I look forward to such feedback.
I also found the following Tweets interesting (via @kevinmarks and @diveintomark) as I wrote this :)
@hixie @kidehen URLs are useful, as they resolve. all else is stamp collecting.
@kidehen In practice few people really understand the subtlties of URN vs URI vs IRI vs URL vs Web Address vs Hypertext Reference vs...
All this crap about HTML5 "gatekeepers" is hiLARious. For 6 years, they BEGGED the W3C to work on HTML+1. The W3C said no.
In the datagrid data model, data is structured as a set of rows representing a tree, each row being split into a number of columns. The columns are always present in the data model, although individual columns might be hidden in the presentation.
Each row can have child rows. Child rows may be hidden or shown, by closing or opening (respectively) the parent row.
Rows are referred to by the path along the tree that one would take to reach the row, using zero-based indices. Thus, the first row of a list is row "0", the second row is row "1"; the first child row of the first row is row "0,0", the second child row of the first row is row "0,1"; the fourth child of the seventh child of the third child of the tenth row is "9,2,6,3", etc.
The chains of numbers that give a row's path, or identifier, are represented by arrays of positions, represented in IDL by the RowID interface.
The root of the tree is represented by an empty array.
Each column has a string that is used to identify it in the API, a label that is shown to users interacting with the column, a type, and optionally an icon.
The possible types are as follows:
Keyword
Description
text
Simple text.
editable
Editable text.
checkable
Text with a check box.
list
A list of values that the user can switch between.
progress
A progress bar.
meter
A gauge.
custom
A canvas onto which arbitrary content can be drawn.
Each column can be flagged as sortable, in which case the user will be able to sort the view using that column.
Columns are not necessarily visible. A column can be created invisible by default. The user can select which columns are to be shown.
When no columns have been added to the datagrid, a column with no name, whose identifier is the empty string, whose type is text, and which is not sortable, is implied. This column is removed if any explicit columns are declared.
Each cell uses the type given for its column, so all cells in a column present the same type of information.
Elijah Grey has a very cool new script CiteDrag that "adds automatically citation (ie. blockquotes, text quotes, ect.) to any dragged content off of the website which is using the script. CiteDrag requires no additional setup other than include the script somewhere on your website."
I just dragged that above text from my blog post where announced the creation of CiteDrag and dropped it into my WordPress “Edit Page” interface, where automatically appeared quoted. Looking into the <blockquote> we can see that it even has the cite attribute defined. That is just one example of how CiteDrag works.
In a browser such as Firefox 3.5 beta (Shiretoku or a Firefox Nightly) go over to the test page and then start to drag the links, text, and image over to the text area.
Another day, another Paul Rouget HTML 5 demo :) This time he does something fun with Web Workers to allow you to see the difference that you can get when you use them.
If you run the demo demo and watch the animated PNG you will see how smooth the world is based on if the animation stops from time to time. Try it with workers on and off to see.
We have been using Workers in Bespin from the get go. Malte Ubl is doing very cool work to ironout the differences between different Web Worker implementations (Firefox, Safari, and Gears). For example, through his abstraction you get the standard importScripts in Gears too, and it includes a mutex abstraction to boot. This has been crucial for us as we add more JS intensive features to the code editor such as realtime syntax checking, rich syntax highlighting, JSLint error reports inline, and more.
We have found that you do have to be careful with Workers though. You don't want to fire too many off as you end up with a raging CPU if you aren't careful, so Malte and others are working on a slicing plan that will keep the CPU down but also keep the UI responsive. We will report back.
It goes into great depth to discuss the nuance of dates and it makes you really reflect on how complex this can be.
Who needs machine readable dates? As far as I can see there are two target audiences for this operation. The first is obviously social applications that have to work with dates, and where it can be useful to compare dates of two different events. An app must be able to see if two events fall on the same day and warn you if they do.
However, as a target audience social applications are immediately followed by historians (or historical, chronological applications). After all, historians are (dare I say it?) historically the most prolific users of dates, until they were upstaged by social applications.
This raises the question whether the <time> element should be tailored for historical use at all. When I started writing this entry I was convinced that it should.
In keeping with the definition of its purpose I the see the <time> element as a tool for an Internet-wide chronological search-and-compare system. Such a system will be a boon to historians, who would be allowed to quickly and easily look up events that happened around the same time as the event they’re writing about.
In history, just as in other academic disciplines, serendipitous discoveries are the meat of exciting new theories. A history-compliant use of the <time> element that allows automatic search and compare would broaden the horizons of historians.
However, now that I’ve reviewed some of the more common problems that have to be solved in order to decrease potential harm, I’m starting to doubt whether the <time> element can easily be made to fit history.
Right now, though, the specification is a vague compromise that doesn’t make the <time> element useful for historical research, but still allows it to be used historically.
I feel this ambiguity should be removed. I feel that the specification should clearly state whether the <time> element is meant for historical use or not. The current vague, implied “No” should be changed to a clear answer. I prefer Yes, but I can live with No.
Meanwhile DanC created an initial draft that will lead to splitting out the URL section as detailed in my last post. I did some testing on CSS URL handling and found out it uses exactly the same algorithm as HTML5 in user agents except that the URL character encoding is always set to UTF-8, just like it works for XMLHttpRequest. In light of this it would make sense to simply revise the IRI specification to make more sense, but there are not enough proponents for that apparently as it would affect e.g. Atom. I guess creating a separate IRI specification (which is what the HTML5 URL handling is) creates less theoretical issues… I wonder though whether anyone has actually tested Atom clients. Do they really refuse to handle spaces in URLs? Do they really do the right thing per the IRI specification and normalize URLs when the encoding of the feed is not a Unicode encoding? Do any clients that handle IRIs do that properly? I doubt it.
I am sorry, but I can't help but write contentEdible for some reason :) Mark Pilgrim has been pushing forward with his series on HTML 5, and recently has a couple of interesting dives:
The feature of the day is spell checking, by which I mean client-side in-browser checking of text in standard <textarea> and <input type=text> elements. Several browsers support this out-of-the-box, including Firefox 2 and 3, Safari 3, Opera 9, and Google Chrome. However, each browser has different defaults of which elements get spell-checked, and only a handful allow the web author to suggest whether browsers should offer checking on a particular element.
Welcome back to my semi-regular column, "The Road to HTML 5," where I'll try to explain some of the new elements, attributes, and other features in the upcoming HTML 5 specification.
The feature of the day is contentEditable, by which I mean client-side in-browser "rich text" editing. All major browsers support this now, including Firefox 3, Safari 3, Opera 9, Google Chrome, and Internet Explorer (since 5.5). Of course, the devil is in the details.
Ian Collins has created DBScriptCache, a JavaScript program that "automatically caches script files in the browser's HTML5 client-side database. Rather than including your scripts using script tags, you include them using this script. The first time a user views the page the scripts will be pulled into the db and stored. On subsequent visits the scripts will be loaded from the db cache and not from your server. The script will continue to come from the cache until you supply a new version number or change the name of the script."
Remember the days of frames and framesets? Not the iframe, but when you had sites with fixed headers and you cursed at not being able to bookmark correctly.
Personally I’m quite fond of the way HTML frames are handled in HTML5. In case you missed it, HTML5 now defines rendering of HTML in non-normative fashion. All gory rendering details of all HTML elements that affect rendering in contemporary Web browsers defined, including blink and marquee. Yay! For implementors this is really useful. I can recall several instances offhand where Opera QA was trying to figure out what the default styling was in other browsers for certain elements because pages did not look quite the same. (E.g. margin of form elements in quirks mode or various elements that need to have text-indent:initial applied to them for unknown reasons.)
Frames and framesets is designed as a simple grid algorithm that ignores CSS for that particular document. For an obsolete feature, it’s quite neat. I almost started writing evil test cases against it (e.g. inserting a body element before the frameset, removing the head element, etc.), but then decided that ensuring that extremely old and obsolete features work correctly is probably not the best use of my time. (Admittedly I’m still tempted.)
The big news this week is more major work on the non-normative section on rendering HTML documents, including a lot of reverse-engineered documentation of legacy (invalid) attributes that users expect browsers to support.
When can I use... is a nice site that Brad Neuberg mentioned which does something that we have been looking to do. It gives compatibility tables for features in HTML5, CSS3, SVG and others.
Mark Pilgrim release a couple of HTML 5 roundup posts in a row. In his first post he talks about:
Big news #1: r2692, a major revamp of the way application caches are defined. Application caches are the heart of the offline web model which can be used to allow script-heavy web applications like Gmail to work even after you disconnect from the internet.
Big news #2: r2684, which redefines the on* attributes in a way that doesn't suck quite as much. Also, it defines the widely used (but poorly understood) onerror attribute in a way that matches what browsers actually do with it.
Big news #3: r2685 and r2686 defines a whole slew of important events that are fired on the Window object, including onbeforeunload, onerror, and onload. Previously, some of these were defined on the <body> element, which didn't actually match current browser behavior.
In his latest post he discusses the news this week that is the beginning of the non-normative section on rendering HTML documents. For those of you not up on spec-writing lingo, "non-normative" means "you can ignore this and still claim to be in compliance with the specification." It's advice, not commands. On the other hand, it's generally useful advice, so ignoring it completely is probably not in your best interests.
If you do any web development, chances are you know checkboxes and radio buttons can have two states: checked and unchecked. But in the case of checkboxes, you may want to indicate to the user that they are half-way between those states, for example when you have a master checkbox above many other checkboxes of singular items. This is now possible on Trunk (Firefox 3.2) thanks to the implementation of the HTML5 "indeterminate" DOM property. All it takes is a bit of script:
