Archive for the ‘WHATWG’ Category
Next week Wednesday, August 3, the W3C HTML5 Last Call review period ends. Consider taking another look and giving some feedback!
Here is a quick rundown of what happened last week:
- The proposed
download attribute made it into the HTML specification. Specify it on an
a element to force the referenced resource to be downloaded rather than navigated towards.
- The WebApps WG published a first draft of The From-Origin Header. It allows resources to declare they are unavailable within an embedding context. E.g. to prevent bandwidth leeching.
- The DOM Core draft now defines the
TreeWalker features: Traversal chapter in DOM Core. These features have existed for ages, but details were not defined thus far.
- In a quest to define
window.find() Ian suggests that maybe it ought to be dropped. If you need it, speak up!
- In the light of a small vulnerability with allowing the
base element in the
body element, we are taking another look at it. Because well, all your
base are belong to us.
Since the summer causes a slowdown of everything standards, the next WHATWG Weekly is in two weeks.
First thing's first. Hi my name is Liam Hockley, I am a recent addition to the admin team on the WHATWG forums and I have been working on improving the site over the past couple of weeks. (forums.whatwg.org)
The first thing I did, was update the forum software from the severely outdated phpBB2, to the fresh new phpBB3. This process went fairly smoothly. Next I created a new forum section to facilitate the discussion of forums/website ideas and feedback. On top of this, the other admins and myself have been working to make sure spam is not and will not be an issue moving forward.
The next step and what we are currently working on, is to try and get the forums more active. I would like to encourage you to use the forums and tell all of your friends. This could serve as a great base for compelling discussion and debate on the HTML spec.
In the future, I plan to try and implement integration of the twitter RSS feed and potentially an RSS feed of the WHATWG mailing list. There is also an effort in place on the part of phpBB, to modernize their markup to follow the latest HTML spec in upcoming releases. We will most certainly be taking advantage of that once it becomes possible.
Anyways, thank you for reading. If you get a chance, check out the forums and drop us a line.
-Liam "Xdega" Hockley
As support for WebM is ramping up, Web authors can start using it. However, since not everyone has a WebM-enabled browser, yet, using WebM on your site poses the problem of having to explain to the visitors of your site how they can view WebM. It is inefficient for everyone to have to do this from scratch on their sites. Also, chances are that per-site help text will be incomplete and out of date soon.
To address this problem, with hosting and domain name help from Anne van Kesteren, I have made webm.html5.org as a place to pool the effort. When you publish WebM content, instead of explaining which browsers support WebM, you can simply link to webm.html5.org and it will detect if the user’s browser supports WebM. If the browser doesn’t support WebM, the page will suggest upgrading the browser to a new version that supports WebM, installing a WebM decoder if the browser supports 3rd-party decoders and one is available, switching to another browser or using another operating system (as applicable and in that order).
The dull visual appearance of the page is a known problem. Visual design isn’t my strong point. I have also avoided using logos without permission. If you’d like to contribute nicer CSS or a nicer-looking (but still short and on-topic) test clip, please find hsivonen on the #whatwg IRC channel on Freenode. Also, if you can contribute accurate advice for platforms that aren’t already covered (e.g. FreeBSD, AIX or OS/2), please drop a line on IRC or in the comments here. (You can view source on webm.html5.org to see what is already covered.)
In 2009 we announced that the HTML5 specification at the WHATWG was progressing to Last Call. The plan at the time was to finish the specification this year and publish a snapshot of "HTML5" in 2012. However, shortly after that we realised that the demand for new features in HTML remained high, and so we would have to continue maintaining HTML and adding features to it before we could call "HTML5" complete, and as a result we moved to a new development model, where the technology is not versioned and instead we just have a living document that defines the technology as it evolves.
As there is still interest in publishing a snapshot of HTML5, the W3C is still working on that (in conjunction with the WHATWG).
Because the specification is now a living document, we are today announcing two changes:
- The HTML specification will henceforth just be known as "HTML", with the URL
http://whatwg.org/html. (We will also continue to maintain the Web Applications 1.0 specification that contains HTML and a number of related APIs like Web Storage, Web Workers, and Server-Sent Events.)
- The WHATWG HTML spec can now be considered a "living standard". It's more mature than any version of the HTML specification to date, so it made no sense for us to keep referring to it as merely a draft. We will no longer be following the "snapshot" model of spec development, with the occasional "call for comments", "call for implementations", and so forth.
In practice, the WHATWG has basically been operating like this for years, and indeed we were going to change the name last year but ended up deciding to wait a bit since people still used the term "HTML5" a lot. However, the term is now basically being used to mean anything Web-standards-related, so it's time to move on!
If you have any questions please don't hesitate to ask them in the comments or on IRC. We'll update the FAQ with the most commonly asked questions.
The WHATWG Wiki portal has a nice section describing HTML vs. XHTML differences, as well as specifics of a polyglot HTML document that also would be able to serve HTML5 document as valid XML document. I'd like to review what it takes to transform an HTML5 polyglot document into a valid XHTML5 document: it appears, finally the 'XHTML5' has become an official name.
The W3C first public working draft of "Polyglot Markup" recommendation describes polyglot HTML document as a document that conforms to both the HTML and XHTML syntax by using a common subset of both the HTML and XHTML and in a nutshell the HTML5 polyglot document is:
- HTML5 doctype/namespace
- XHTML well-formed syntax
Polyglot document could serve as either HTML or XHTML, depending on browser support and MIME type. A polyglot HTML5 code essentially becomes XHTML5 document if it is served with the XML MIME type
In a nutshell the XHTML5 document is:
- HTML doctype/namespace: The
definition is optional, but it would be useful in a polyglot document by preventing browser quirks mode.
- XHTML well-formed syntax
- XML MIME type:
This MIME declaration is not visible in the source code, but it would appear in the HTTP Content-Type header that could be configured on the server. Of course, the XML MIME type is not yet supported by the current version Internet Explorer though IE can render XHTML documents.
- Default XHTML namespace:
- Secondary namespace such as SVG, MathML, Xlink, etc. To me this is like a test, if you don’t have a need for these namespaces in your document, then the use of XHTML is overkill in the first place.
Finally, the basic XHTML5 document would look like this:
<meta charset="UTF-8" />
<rect stroke="black" fill="blue" x="45px" y="45px" width="200px" height="100px" stroke-width="2" />
The XML declaration
<?xml version=”1.0” encoding=”UTF-8”?> is not required if the default UTF-8 encoding is used: an XHTML5 validator would not mind if it is omitted. However it is strongly recommended to configure the encoding using server HTTP
Content-Type header, otherwise this character encoding could be included in the document as part of a meta tag
<meta charset="UTF-8" />. This encoding declaration would be needed for a polyglot document so that it will be treated as UTF-8 if served as either HTML or XHTML.
The Total Validator Tool - Firefox plugin/desktop app has now the user-selectable option for XHTML5-specific validation.
I would say that the main advantage of using XHTML5 would be the ability to extend HTML5 to XML-based technologies such as SVG and MathML. The disadvantage is the lack of Internet Explorer support, more verbose code, and error handling. Unless we need that extensibility, HTML5 is the way to go.