Created: 2013-04-22/30 2013-05-02 2013-05-16 2013-10-16 2013-10-23
Author: Dr. O. Hoffmann (German web-page)The draft for HTML5 provides several new elements with semantical meaning or functionality - are they ready for use? The variant of the format for the HTML5 tag soup parser is far more complex than what remains as the essentials, if documents are send to an XML parser and this version is simpler to understand and to use for authors, therefore the tests here are restricted to some new parts of this essential variant. This means especially the restriction to the XML variant does not reduce the feature set. With the less restrictive HTML5 tag soup variant one can only add more bugs and funny notations to the source code. Such a tag soup parser mainly needs to normalise this to something similar to the XML variant with the same functionality. I do not want to test these normalisation issues, therefore I start already with the XML variant, to skip all issues not really important for the feature set.
One speciality of the HTML5 are the "willful violations" of other specifications. Well, following this idea I ignore in these documents a few parts of HTML5 as well - mainly I indicate the used version with an URI in the attribute version. If one cannot indicate the version a document uses, it has no defined content and there is nothing to test or nothing to interpret as defined semantical meaning, especially because several issues in HTML5 are incompatible to other variants of (X)HTML. Additionally different HTML5 drafts can be incompatible as well, for example by removing elements or attributes in newer drafts, available in older or changing the meaning of such elements. Therefore it is pretty important to indicate the HTML5 draft version, the document was written with. For example due to those draft changes the experimental validator for HTML5 often fails, just because it ignores the version information.
And I do not care about some 'redefinitions' of old elements like small or cite, because the 'redefinitions' result in nonsense for common use cases.
Typically user agents with a visual presentation are the first to interpret new features and new elements with semantical meaning may result in more problems for the visual presentation that for the aural presentation, which may only require to speak out the names of the elements. For a visual presentation one should expect, that there is a more prominent visualisation for major structures like sections, headers and footers than for example for paragraphs - but this is wrong. Due to the suggestions of the HTML5 draft most of these new elements are only presented similar to an element span or div, this means no special presentation or only a line break to get a new block of content. This means already due to the suggestions of the HTML5 draft should always use additionally old elements with a more dominant presentation to structure the presentation of a document.
For the whole concept of separation of styling from content - CSS and (X)HTML - it is essential to have a well structured visual presentation with the default stylesheet of the a user agent, because if this user agent fails to present new features of CSS, the user in doubt can switch off the interpretation of CSS to get an accessible presentation of the content.
Other relevant issues for testing are related to new feature, which provide new functionality like a meter or progress element or restrictions of form inputs or there are new features to solve issues in another way than before, for example with the new elements audio, video or embed to take over some tasks from the sophisticated object element.
An interesting observation: The (experimental) validator for HTML5 (Conformance Checker) of the W3C fails to validate the XML variant if HTML5 and reports typically nonsense, even worse, it does not respect the character encoding given by the server, respectively the processing instruction - therefore there is no reliable check method for HTML5 documents! Additionally if HTML-tidy output is used on the validator page, everything related to HTML5 is removed, what can result in a meaningless document with broken navigation. Therefore: Do not believe in the 'HTML5 Conformance Checker' and not in HTML-tidy. If you use HTML5, you are on your own!
This document is used to test features with mainly semantical meaning.
Intentionally at the beginning of the document I mainly use new elements
to structure the documents - as expected already from the styling suggestion
from the HTML5 draft indicate, that this will not be sufficient.
For old user agents there is no visual indication of these elements at all,
for new user agents some elements are presented as blocks without a further indication
of structure, others with no special presentation. However a remarkable exception is
the presentation of the element figure. If already implemented, elements like
mark, meter, progress or an element with the attribute
contenteditable have some relevant visual presentation as well.
But for example Opera 12 seems to have some problems with new line breaks in
contenteditable segments.
Or for meter or progress there is only the graphical presentation,
no precise values are provided, if the author does not care about it - therefore
of limited use.
The elements detail or ruby are for example implemented in Google Chrome 26 (WebKit/537.31), not in Opera 12.16 or Firefox 20/24.
Reversed list numbering is interpreted for example in Google Chrome 26 (WebKit/537.31), Firefox 20 and Opera 12.15. The attribute type for ordered lists is typically interpreted as well in viewers, but usually the numbers have to be positive, if not the numerical type is chosen, else the presentation is typically switched to a numerical representation for zero and negative numbers.
Google Chrome 26 (WebKit/537.31) seems to have some interpretation of dialog with some styling,
but if not open there seems to be no way to get access to the content - not really helpful, and a questionable
feature for a dialogue anyway. And the open variant of the Google Chrome dialog covers the
following content - this is simply annoying and stupid - do never use this element!
I asked about the accessibility problem of this element in the official mailing list of the HTML5
draft at 2013-05-02, if there is an answer with an advice to use it in a meaningful way not resulting in accessibility problems, I will provide an update here. It looks like the problematic implementation is removed from WebKit in
a later version, for example not available in Chromium 29 (WebKit/537.36).
Several features are obviously not implemented at all like scoped stylesheets, or the new interpretation of the old element menu, time, spellchecker.
menu type currently seems to make no difference for presentation, no matter, what type is used, everything looks like the element ul.
Konqueror 4.8.4 seems to interpret nothing of these new elements with KHTML, a few things with WebKit 534.34, but not comparable with the WebKit variant used in Google Chrome 26.
The draft from 2013-08-06 introduces a new element main.
The test document mainly tests, if there is some meaningful presentation for this new block element.
In Opera 12.16 and Konqueror 4.8.4 (KHTML or AppleWebKit/534.34) this is presented like a span - no separation.
In Firefox 24 and Chromium 29 (WebKit/537.36) this is presented like a div - a block element without separation.
Initially there was the idea, that all user-agents for HTML5 should interpret at least one and the same format for the element video and correspondingly one for audio. But the browser vendors failed to agree on one format, one of the reasons was obviously the complex patent laws in the USA. Therefore still there is no reliable format for these elements, authors can safely use, not even patent free formats like OGG.
Nevertheless, the fallback mechanism, if the used format is not interpreted remains questionable. One can switch between other other audio and video formats, but not to other formats like SVG or HTML5 itself. One the other side, old formats seem to not interpreted either by those programs, who should, for example formats like WMV or AVI in microsoft internet explorer.
Late in the draft process there was introduced the element track, respectively a new format to provide subtitles and other text alternatives for video and audio for example Google Chrome 26 (WebKit/537.31) shows some text for video, not for audio, but provides no selection, if there is more than one track, Opera 12 or Firefox 20/24 ignore the element - but the text about the new format is not even an official draft. Opera 12.16 displays the track text for video.
With Konqueror 4.8.4 most multimedia formats are interpreted, both with KHTML and WebKit 534.34, unfortunately with embedding OGG there seem to be problems.
And the interpretation of video and audio format in the element object seems to be worse than years ago, before the user-agents interpreted video and audio - even if a format is interpreted in these new elements, this does not mean, that current user-agents do it as well in object.
To resume: Multimedia in (X)HTML remains a disaster. Therefore not really a big progress with HTML5. The best approach still seems to be just a link to the files with a simple element a with some descriptive text around.
The new draft from 2013-08-06 adds an attribute download for the element a.
With this authors can indicate, that referenced files are intended for download or external
programs, not for direct presentation. This seems to be a good alternative to embedded
approaches, because external programs typically have less problems with many of those formats.
The attribute is ignored for example in Opera 12.16, but Firefox 24 interprets it as well
as Chromium 29 (WebKit/537.36). Konqueror 4.8.4 (KHTML) provides it for download but ignores the suggested names.
About the new capability to exchange content in object, because now it has an attribute name,
therefore it can be target of references: Ok in Opera 12.16, Chromium 29 (WebKit/537.36), ignored in Firefox 24
and Konqueror 4.8.4 (KHTML, wrong size here for embedding as well and wrong viewBox for exchanged content),
ok for Konqueror 4.8.4 (AppleWebKit/534.34, but wrong size for object).
But Opera 12.16 and Chromium 29 (WebKit/537.36) ignore typemustmatch.
Concerning seamless iframes: This is completely ignored in Opera 12.16, Firefox 24, Konqueror 4.8.4 (KHTML and AppleWebKit/534.34), ok in Chromium 29 (WebKit/537.36) for the SVG document, but ignored for the XHTML document.
Do iframes work with srcdoc? Ignored in Opera 12.16, Firefox 24, Konqueror 4.8.4 (KHTML and AppleWebKit/534.34). Chromium 29 (WebKit/537.36) tries a presentation, but surpringly displays an unnecessary scrollbar...
For new form features the typical fallback mechanism is, that old viewers send simple text without validation of the input - anyway one has to check this at the server side. Only such a feature like the delocalisation of form elements, spread outside the form element is completely incompatible for older viewers, something like keygen as well.
output seems to have no difference to span in presentation, for example one can put the result of a computation done by the server inside the output, if the form itself is the action target of the form. But without further presentation indication this is of limited use.
Opera 12 seems to interpret most of the new features, Firefox 20 for example less, therefore one cannot expect to get have all new features in all viewers. Nevertheless, if interpreted, there are interesting features and implementations to explore for authors. If everything is tested with an older viewer, not interpreting any of these new features, an author can be almost sure, that everything will work as well with a partial interpretation.
For example, in general Opera 12 interprets list and datalist, but (a part of) the list becomes only visible, if the first characters of the input fit. Alternatively one can remove all characters to get the complete list presented - therefore tricky to see what is in the list.
Firefox 20 for example ignores attributes like min, max, step and allows arbitrary inputs for the type 'color' as well as for time and date related types, ignores datalist and list or keygen.
Google Chrome 26 (WebKit/537.31) seems to have problems with the input of date and time
in the international format, it mixes up the order of years, months and days, partially the
validation of the time input is broken - respectively it does not indicate, what is wrong and there is no suggestion,
what the viewer assumes, that should be noted.
Comparable to Opera for list and datalist (a part of) the list becomes only visible,
if the first characters of the input fit.
Konqueror 4.8.4 seems to interpret nothing of these new form methods with KHTML, and only a few things with WebKit 534.34, but not comparable with the WebKit variant used in Google Chrome 26.
If you as a user are concerned about privacy and you are already suspicious about cookies and some other features, corporations and data collectors used to identify your activities for their intentions - bad news, HTML5 allows to do it worse - there can be stored 5 Megabyte of data on your computer under the control of each author wanting to store something on your computer without asking you!
But for authors there is not only the advantage to use the computer of the user to store arbitrary data, the problem is, that this works only, if the interpretation of java-script is activated. Therefore it is simple for users to avoid this by switching off the interpretation of java-script, yet another reason to do this, not only security and stability issues, privacy as well. Authors must not rely on java-script to provide any content. And the user has the option not to allow the use of his computer as a data dump or restricts this to smaller sizes than 5 Megabyte. For example, meanwhile it is possible to abuse the cache of a viewer as well to store data to identify users, therefore it is recommended to switch off caches anyway, if privacy is relevant. Therefore I do not check this feature here at all.
A better way to care about this is to store data at the server and to require users to register and login, if they want to use stored data from you. This works for old viewers as well and it is obvious for the user to be identified after login, what is finished again after logout.
HTML5 allows, similar to the electronic book format ePub, to provide information about all
files of a project to put everything in the cache for working offline. Obviously to benefit from this
features, users have to set up the user agent in such a way, that it is allowed to cache/store content
from internet. Usually, if this is not explicitly switched off for example for privacy reasons, user
agents are already configured to store content in a cache. This project provides such so called manifest
information as well. To check it, simply disconnect from internet and try to get access to the
test files, the images and the multimedia files of this test. But note, that you obviously need to
connect again, if you want to send a form to a server, not just to a cached file.
Note, that you may have problems to see an updated version of these pages, if the user-agent stored
the pages. You have to insist, that it gets the content from the server again, for example by
adding a GET-parameter to the URI or by removing the history and to empty the browsing cache.
Note that authors can use this feature as well to count users individually - if a user agent does call for a specific file from such a cache, produced exclusively for this user agent, this can be counted. I a user comes back to the project, the user agent will still have this stored and will not be counted again, until the history or cache is cleaned.