Gary Edwards's Library tagged html5 →  View Popular

For HTML documents, user agents must use the parsing rules described in this section to generate the DOM trees. Together, these rules define what is referred to as the HTML parser.
While the HTML syntax described in this specification bears a close resemblance to SGML and XML, it is a separate language with its own parsing rules.
Some earlier versions of HTML (in particular from HTML2 to HTML4) were based on SGML and used SGML parsing rules. However, few (if any) web browsers ever implemented true SGML parsing for HTML documents; the only user agents to strictly handle HTML as an SGML application have historically been validators. The resulting confusion — with validators claiming documents to have one representation while widely deployed Web browsers interoperably implemented a different representation — has wasted decades of productivity. This version of HTML thus returns to a non-SGML basis.
Authors interested in using SGML tools in their authoring pipeline are encouraged to use XML tools and the XML serialization of HTML.This specification defines the parsing rules for HTML documents, whether they are syntactically correct or not. Certain points in the parsing algorithm are said to be parse errors. The error handling for parse errors is well-defined: user agents must either act as described below when encountering such problems, or must abort processing at the first error that they encounter for which they do not wish to apply the rules described below.
Conformance checkers must report at least one parse error condition to the user if one or more parse error conditions exist in the document and must not report parse error conditions if none exist in the document. Conformance checkers may report more than one parse error condition if more than one parse error condition exists in the document. Conformance checkers are not required to recover from parse errors.
Parse errors are only errors with the syntax of HTML. In addition to checking for parse errors, conformance checkers will also verify that the document o

www.whatwg.org/...parsing.html - Preview

html5 parsing-html DOM

The stripped down "HTML Author" version of the 900 page HTML5 specification.   The bulk of the spec targets "implementers" such as browsers and editors.  It's very exacting and should provide for an unprecedented universal interoperability.

Introduction:  This specification provides the details necessary for producers of HTML content to create conformant documents, and for others to wcheck the conformance of existing documents. It is designed:

to describe the syntax and structure of the HTML language
to describe the semantics of HTML elements and their attributes (that is, to describe what the elements and attributes represent)
to be clear and unambiguous
to be as concise and readable as possible
Certain purposes are intentionally out of scope for this specification; in particular, it:

does not provide any conformance criteria for HTML consumers; in particular, it does not attempt to define how Web browsers and other user agents process documents
does not define any APIs related to processing of HTML content by HTML consumers.
does not attempt to be a tutorial or “how to” authoring guide

dev.w3.org/spec.html - Preview

html5 html+

You need an HTML5 ready browser to visit this demonstration.  Amazing stuff though.  The latest Chrome beta 3.0.196.2 works well.  Ajaxian has a review of this at:  http://ajaxian.com/archives/audio-canvas

Lots of Webkit tweets in the demo!

9elements.com/...canvas - Preview

html5 chrome webkit

HTML 5 Reset Stylesheet
We’ve had a number of people asking about templates, boilerplates and styling for HTML 5 so to give you all a helping hand and continue on from those basic building blocks that Remy talked about last week I’ve created a HTML 5 reset stylesheet for you to take away and use, edit, amend and update in your projects.

Based on Eric Meyers CSS reset, I’ve made a few adjustments from Erics work that we’ll get to later but first here’s the file in full and we’ll then break it down step by step.

html5doctor.com/html-5-reset-stylesheet - Preview

html5 richard-clark eric-meyers css3

Web technologies are increasingly being used on the desktop to bring richer user interfaces to conventional applications. In this tutorial we will show you how to use the WebKit HTML renderer alongside native GTK+ widgets to make a desktop WYSIWYG editor with Python.

arstechnica.com/...tor-with-webkit-and-html-5.ars - Preview

webkit html5

Modernizr is a new library that detects various HTML5 and CSS3 features and lets you know so you can use them: Enables the writing of conditional CSS and conditional JavaScript! The JS tools just keep coming.

ajaxian.com/...rnizr-html5-and-css3-detection - Preview

JavaScript HTML5 CSS3 HTML+ Modernizr JS-Libs

Michael Hickens has been writing about Google Wave and how it will forever change the Web. In a recent article he took on the incredible WebKit - HTML+ phenomenon, tying in the surge of WebKit marketshare at the edge of the Web with dramatic changes taking place across greater Web.
<br>

From Michaels article: .... "I recently described how Google's Wave, a collaboration tool based on the new HTML 5 standard, demonstrated the potential for Web applications to unglue Microsoft's hold on customers. My post quoted Gary Edwards, the former president of the Open Document Foundation, a first-hand witness to the failed attempt by Massachusetts to dump Microsoft and as experienced a hand at Microsoft-tilting as anyone I know......"
<br>
The year 1998 marked the end of the browser wars, the end of Netscape, and the beginning of Microsoft's anti-trust woes. It also marked the beginning of XML, and the end of HTML, with the W3C leaving HTML, CSS and SVG to rot. What a year.

<br>
Today we find the landscape considerably changed. Instead of a browser war between Netscape and Microsoft, ending with the triumph of an IE monopoly, today we have a browser race. And IE isn't a contender, having been pretty much abandoned by Microsoft once they had Netscape in the dirt.

<b>
The introduction of XML 1.0 in 1998 ushered in a new era of customized XML schema's for all kinds of data exchanges. The Web came alive with data flows from disparate databases and transaction systems that were never designed to talk to each other. The noise across the Web, private and public, was deafening.

<br>
There was however a few notable attempts to encode document based content in XML, with OpenOffice ODF and MSOffice OOXML taking center stage. Unlike the excitement and extraordinary Web capabilities that surrounded XML data schema work, XML documents veered away from the Web. By design, ODF and OOXML are incompatible with the language of the Web. But given the legacy of client/server dominance powerful "end-user-facing" desktop office

industry.bnet.com/...-fight-starts-with-smartphones - Preview

openweb michael-hickens webkit ge HTML5 HTML+ CSS3 JavaScript google-wave iphone android

Good article from Glynn Moody explaining the OpenDocument Foundation's decision to drop OpenOffice ODF for HTML+. That date of this article is November 13th, 2007. The Foundations announcement comes after ISO members vote down OpenXML as an ISO standard. Microsoft however does not give up. They come back to ISO by responding in detail to every objection, pushing for a February 2008 BRM. Following the BRM, and contingent on Microsoft's promise to fix OpenXML, join the OASIS OpenOffice ODF work, and, support ODF 1.1 in MSOffice using a plug-in, ISO votes again. In March of 2008, ISO approves OpenXML.

In May of 2009, Microsoft releases an MSOffice plug-in fully compliant with ODF 1.1 (ISO 26300). Although conforming to and in full compliance with ODF 1.1, the world is shocked to learn that the interop between MSOffice ODF and OpenOffice ODF is worthless. Which is exactly what the Foundation had been arguing for years. ODF "compatibility, interop and compliance" had to be fixed prior to Microsoft's expected implementation!!!!! Otherwise, ODF would be shredded.

Told you so!

lwn.net/258232 - Preview

cdf foundation glyn moody odf ooxml opendocument sharepoint html+ html5 css3 interoperability

Whoops. This is the better article! ZDNet got the dregs. CNET got the real thing: Google Native Client, HTML5, GWT, Wave, Web Worker Threads, webkit/chromium, Chrome, O3D

"Google wants its Native Client technology to be a little more native.
Google Native Client, still highly experimental, lets browsers run program modules natively on an x86 processor for higher performance than with Web programming technologies such as JavaScript or Flash that involve more software layers to process and execute the code. But to use it, there's a significant barrier: people must install a browser plug-in.

news.cnet.com/8301-17939_109-10251563-2.html - Preview

Google-Native-Client HTML5 GWT Wave Web-Worker-Threads webkit_chromium Chrome O3D

Good article from Stephen Shankland describing how the Wave-HTML5-O3D-Web Worker pieces fit. He left out GWT. But this after all, one very big picture. Google has thrown down a game changer. Wave represents one of those rare inflection points where everything immediately changes. There is no way to ignore the elephant that just sat on your face. \n\nGoogle has been demonstrating its sandboxing technology for making web applications perform at similar levels to those associated with native desktop applications.\n\nGoogle Native Client, still highly experimental, lets browsers run program modules natively on an x86 processor for higher performance than with web-programming technologies, such as JavaScript or Flash, that involve more software layers to process and execute the code. But to use it, there is a significant barrier: people must install a browser plug-in.

news.zdnet.co.uk/...0,1000000097,39657632,00.htm - Preview

wave html5 html+ gwt O3D web-workers google

What a loaded statement. This was at the beginning of Google I/O. Incredibly, the rest of the show proved their point. Google backed up all the grand assertions with running code and developer affirmations. Incredible. Here's a taste:

<i>...Google, Mozilla, and Palm gave us all a big whack upside the head this morning. As Shakespeare said, "The hot blood leaps over the cold decree." The technology is here even if the standards committees haven't caught up. Developers are taking notice of these new features, and aren't waiting for formal approval. That's as it should be. As Dave Clark described the philosophy of the IETF with regard to internet standardization, "We reject: kings, presidents, and voting. We believe in: rough consensus and running code."
<br>
Support by four major browsers adds up to "rough consensus" in my book. We're seeing running code at Google I/O, and I'd imagine the 4000 developers in attendance will soon be producing a lot more. So I think we're off to the races. As Vic said to me in an interview yesterday morning, "The web has not seen this level of transformation, this level of acceleration, in the past ten years."</i>

radar.oreilly.com/...google-bets-big-on-html-5.html - Preview

webkit web-3.0 webkit-chromium google html5 css4

Some interesting questions about Google Wave; proposed by Om Malik and Jordan Golson, but with some hesitant reservations. As the title of this nervous commentary suggests. The narrowness and shallow context of this article is to be expected from hapless back-benchers incapable of grasping the big picture. But GigaOM? What a surprise. Maybe i should be revising my Silicon Valley information feeds?

Google is into it with Microsoft, and for the sake of the future of the OpenWeb, Google better win. How does anyone able to fog a mirror miss this? Incredible.

"..... Has Google, with its latest project, Google Wave, actually come up with the Next Big Thing in online communication, or is it yet another Googler vanity exercise? Wave is a combination of email, instant messaging and a real-time wiki — plus open architecture and APIs. Or as creators Lars and Jens Rasmussen and Stephanie Hannon put it, “what email would be if it were invented today.”

Om also points out another comment from Lars: <i>“Email is the most successful protocol on the planet…we can do better.” </i>

I think Google Wave is in the center of a number of revolutionary Google initiatives advanced at the recent Google I/O. HTML 5, the Canvas Tag, O3D, and the assault on the x86 Microsoft desktop stronghold are all part of Google's greatest challenge; keeping the Open Web free and competitive with the emerging MS Web.

Michael Hickens has an interesting article;<i><b> <a href="http://industry.bnet.com/technology/10001911/google-wave-crashes-over-microsoft/">Google Wave Crashes Over Microsoft"</a></b></i>. Michael spoke with me prior to publishing, and i gave him my cosmic viewpoint of how things fit together (or not). You can find a loose summary of our discussion here: <i><b><a href="http://docs.google.com/View?id=dghfk5w9_7hptc6vfn">Google Wave: Crashing the Microsoft Desktop Monopoly</a></b></i>. Clearly i am still writing :)

gigaom.com/...heights-of-arrogance-with-wave - Preview

google-wave html5 html+ OpenWeb

<i>"........ Google Native Client, still highly experimental, lets browsers run program modules natively on an x86 processor for higher performance than with Web programming technologies such as JavaScript or Flash that involve more software layers to process and execute the code. But to use it, there's a significant barrier: people must install a browser plug-in.

However, Google wants to make the technology more broadly accessible in browsers through new technology coming to HTML, the standard used to build Web pages, and at the Google I/O developer conference Thursday demonstrated its work to make that happen...."</i>

Looks to me that Google is attacking the problem of integrating a Chrome browser with x86 desktop metal. Maybe it's the only way to get webkit/Chromium Web Apps on a par with native x86-Windows desktop apps?

There is that infamous quote describing the Google v Microsoft challengeto consider: "Google has to replace the MSOffice productivity environment on the desktop "Client" before Microsoft replaces Google apps and services on the "Server". (Same holds true for IBM Lotus Notes - WebSphere on the Server and OpenOffice/Symphony on the desktop client).

The quote actually comes from some high level Microsoft document experts, said to have been uttered while under the glaze of legendary Czech Pilsners during a recent ISO meet up in Prague. Looks like there is far more to this quote than meets the eye. I wonder though. Google is looking good. So good that perhaps they are confident enough to take things public - as the events at Google I/O seem to indicate?

~ge~

news.cnet.com/8301-17939_109-10251563-2.html - Preview

html5 html+ webkit webkit_chromium x86-Chrome

Google "Rich Snippets" is a new presentation of HTML snippets that applies Google's algorithms to highlight structured data embedded in web pages.

Rich Snippets give end-users convenient summary information about their search results at a glance. Google is currently supporting a very limited subset of data about <b>reviews and people</b>. When searching for a product or service, users can easily see reviews and ratings, and when searching for a person, they'll get help distinguishing between people with the same name. It's a simple change to the display of search results, yet our experiments have shown that users find the new data valuable.

For this to work though, both Web-masters and Web-workers have to annotate thier pages with structured data in a standard format. Google snippets supports microformats and RDFa. Existing Web data can be wrapped with some additional tags to accomplish this.

Notice that Google avoids mention of RDF and the W3C's vision of a "Semantic Web" where Web objects are fully described in machine readable semantics. Over at the WHATWG group, where work on HTML5 continues, Google's Ian Hickson has been fighting RDFa and the Semantic Web in what looks to be an effort to protect the infamous Google algorithms.

RDFa provides a means for Web-workers, knowledge-workers, line-of-business managers and document generating end-users to enrich their HTML+ with machine semantics. The idea being that the document experts creating Web content can best describe to search engine and content management machines the objects-of-information used. The google algorithms provide a proprietary semantics of this same content.

The best solution to the tsunami of conten the Web has wrought would be to combine end-user semantic expertise with Google algorithms. Let's hope Google stays the RDFa course and comes around to recognize the full potential of organizing the world's information with the input of content providers.

One thing the world desperately needs are powerful desktop editors capable of

googlewebmastercentral.blogspot.com/...introducing-rich-snippets.html - Preview

rdfa rich-snippets google html5 odf ooxml w3c

In 2004 Ian Hickson attended the W3C workgroup on XHTML and CDF. He notes the fact that, as Steven Pemberton pointed out, six year ago (1998), the W3C decided that HTML was dead, and the way forward was a host of new languages (what is now XHTML2, XForms, MathML, SVG) that would lead the world's population to a clean new world.

Then he has this to say: <i>".... The truth is that the real Web, the Web that authors write for, is the Windows IE6 Web. The only way to change that is to reduce the IE6 market share, and new technologies don't do this. Marketing does. Once users are primarily using a browser that is being regularly updated, then we can start introducing radically new technologies. Until then, such technologies simply aren't going to become popular.

There were a lot of rather confused statements during the meeting. For example, it is clear that a lot of people think that the browser is dead and that the way forward is transparent "runtimes" that execute remote applications securely. But then these same people demand to know why Mozilla, Opera and Safari don't support XForms and SVG, saying that their lack of support is crippling their standards' adoption.

Surely if the browser paradigm is dead, it doesn't matter what we implement?

What I think most of the people at the meeting actually want is a standard that combines XHTML, XForms, SVG, and SMIL (and CSS, DOM, and ECMAScript, although they rarely if ever actually mention those by name), and then adds enough APIs to make the host into a platform in its own right. ..."</i>

ln.hixie.ch/?start=1086387609&count=1 - Preview

html+ html-css html5 w3c hixie

Chris Walker provides some interactive demonstrations of the powerful webkit-transforms that are placed in CSS. So, what can we do with all this magic? Well, the culmination of the Chris Walker demo is a Mac OSX style Dock menu, using no Javascript...<br><br>

<i>".....Yes, that’s right a bulging docked menu, with no javascript.
Just so you remember, there no javascript in the demo. Check out the Javascript free <a href="http://thechriswalker.net/osx-dock">OSX Dock Menu Demo</a>.<br><br>

This demo actually proves an important point Tom Yager made earlier about Ajax; Will JavaScript inconsistencies break the Web? <br><br>
<b><a href="http://weblog.infoworld.com/yager/archives/2009/03/taking_ajax_lit.html">Taking AJAX literally makes lousy Web apps</a></b>: <i>"As little as possible should be the rule for JavaScript, which must play a supporting role to CSS and HTML"</i>.

Tom concludes that it's best to follow the WebKit model, putting everything possible into first CSS4, then HTML5, and then JavaScript. I would argue that the proliferation of JavaScript libraries is a good hedge against the non interoperable future Yager warns of. But hey, why stop the guy when he's on a roll. CSS4! I guess the webkit-transforms have been officially christened. Thanks Tom.
<br><br>
~ge~

thechriswalker.net/...ions-the-osx-dock-example.html - Preview

webkit webkit-transforms webkit-animations CSS4 JavaScript HTML5

To sum up: character encoding is complicated, and it has not been made any easier by several decades of poorly written software used by copy-and-paste–educated authors. You should always specify a character encoding on every HTML document, or bad things will happen. You can do it the hard way (HTTP Content-Type header), the easy way (<meta http-equiv> declaration), or the new way (<meta charset> attribute), but please do it. The web thanks you. Good post, lots of links to other "MUST READ" commentaries and explanations of character encoding. Including Joel Spolsky and Tim Bray.

blog.whatwg.org/d-to-html-5-character-encoding - Preview

character-encoding html5 whatwg

Given the increasing number of platforms supporting Javascript + HTTP + HTML5, it's not inconceivable that "write-once, run anywhere" might come closer to fruition with this combo than Java ever achieved.

Here's how this architecture plays out in my mind. Javascript is the core programming language. Using a HTTP transport and JSON data format, components in different processes can perform RPCs to one another. HTML5 features like local storage and the application cache allow for an offline story (the latest build of Safari on iPhone supports this). And of course, HTML + CSS allows for a common UI platform.

adamac.blogspot.com/...evolution-revolution.html - Preview

WebKit html-css-svg html5 javascript iPhone

Great links to HTML5 resources

adactio.com/1540 - Preview

html5

This is a brief introduction to the new structural elements in the HTML 5 Working Draft, and how to use semantic class names in HTML 4.01 or XHTML 1.0 markup that correspond to the names of those structural elements. By doing so, you’ll get a head start in understanding how to use the new elements and also go some way towards using plain old semantic HTML if you’re not already.

jontangerine.com/...tml5-with-semantic-class-names - Preview

html5 semantic-class-names