Kaizou » XHTML

HTML 5 offline web applications

David Corvoysier — Sat, 04 Apr 2009 17:21:21 +0000

HTML 5 provides a new caching feature to support offline web applications.

Basically, you can specify in a specific file called the “cache manifest” the caching policy to apply to a particular web page.

To activate the HTML 5 caching feature for a specific document, you only need to specify the URI of the cache manifest file in the manifest attribute of the element.

...

The file that references the cache manifest file is called the master entry.

Please note that to be properly parsed by the browser, the manifest file must have a text/cache-manifest MIME type (which means that you will need either to add a custom file type extension binding to your web server or to specify manually the mime-type, for instance using PHP header directive).

A cache manifest file typically looks like this:

CACHE MANIFEST
index.html
style.css
images/logo.png

NETWORK:
search.php

This file specifies several files to cache (the cache explicit entries), and then specifies that search.php should never be cached (it is said to belong to the online white list), so that any attempt to access that file will bypass the cache.

Whenever the user browses to the page corresponding to a document to which a cache manifest is associated, the browser must check on the server if the latter has been modified:

If it hasn’t, then the cached content is used,
If a new version of the cache manifest exists, then the cached content is considered as staled and reloaded from the server.

The cache manifest for a document may also contain fallback entries that can be used if the browser can’t retrieve the original content. Below is an example where a static image is used when the retrieval of a dynamically generated image fails:

CACHE MANIFEST
FALLBACK:
images/mirror-effect.php server-busy.jpg

HTML 5 also defines an application cache API to manually trigger cache updates:

update(): updates the cache for the current document in the background,
swapCache(): reflow the HTML document using updated cached content,
onupdateready(): event triggered when the cache content has been updated,
onobsolete(): event triggered when the cache content has been marked as obsolete,
…

HTML 5

David Corvoysier — Fri, 03 Apr 2009 17:08:37 +0000

One of the most revolutionary concept introduced by HTML 5 is the native support of audio and video playback in web pages.

Two new HTML elements have been defined for that purpose: and , based on the generic media element type.

Media elements use a common set of attributes:

src: defines the source of the media to render,
autoplay: boolean to activate|prevent immediate playback,
loop: boolean to activate|prevent automatic looping on content,
controls: boolean to display|hide browser playback user interface.

and elements can contain elements to be displayed to the user in older browsers that do not support these new elements.

Below is an example of how to use the element:


    Listen

Alternatively to the src attribute, the content to be rendered can be specified using one or more elements, each of them describing a specific media resource.

Each can be identified by its src and type attributes, optionally complemented by a codecs attribute:

The element has an optional poster attribute that can be used to define an image to be displayed before the video is played:

These new media elements also support a set of handy javascript method, properties and events, to allow the fine-grained control of the rendered UI.

play()
pause()
currentTime: current playback time,
duration: overall duration of the media,
playbackRate: playback speed (can be negative !),
onplay(): content has just start playing,
onpause(): content playback has just been paused,
onerror(): an error occurred,
…

New HTML 5 block-level elements

David Corvoysier — Mon, 09 Mar 2009 11:59:51 +0000

The HTML 5 specification introduces new block elements that can be used to structure documents:

: represents a document or application section (a content column for instance),
: represents an independent piece of content inside a document/section (a blog entry for instance),
: represents a piece of content not directly related to the displayed content (typically a sidebar),
: represents a document header,
: represents a document footer,
: represents a block of navigation links (typically a blog navigation bar),
: can be used to render a chat session, using complementary
(talker) and
(quote) tags,
: can be used to provide textual information about an embedded content,
: represents a document/section contact block,

Introducing: HTML 5

David Corvoysier — Fri, 06 Mar 2009 15:05:32 +0000

The HTML version you are using everyday is HTML 4.0.1, defined back in 1999 by the W3C.

Its XML counterpart is XHTML 1.1, successor of XHTML 1.0 defined in 2000 and revised in 2002 by the W3C.

The newest XHTML 2.0 was at first meant to replace both, but the fact that it was not compatible with XHTML 1.1 raised quite a controversy.

This, added to the fact that some major internet companies and non-profit organizations wanted to expand the typical browser experience to include other internet usages like messaging and media playback led to the creation of the Web Hypertext Application Technology Working Group (WHATWG), that released in 2005 the first version of the HTML 5 specification.

The W3C started in 2007 a new HTML working group that took the WHATWG HTML 5 specification as a basis, leading to the publication of the first HTML 5 draft in 2008.

The W3C HTML 5 working group is led by Ian Hickson from Google, Inc (WHATWG HTML 5 specification editor, CSS 2.1 co-editor, Acid2 and Acid3 developer) and David Hyatt from Apple, Inc (Safari/Webkit project leader, Firefox co-founder).

The HTML 5 specification defines both HTML and XHTML document types.

The W3C maintains a list of differences between HTML 5 and HTML 4.

I will try to explain these differences in separate posts:

and associated new block-level elements,
& elements,
offline web applications,
… TBC …

Differences between strict & transitional (X)HTML

David Corvoysier — Fri, 06 Mar 2009 14:03:16 +0000

HTML and XHTML exist today in two flavors: strict and transitional. By default, a lot of editing tools or CMS use the transitional model.

This is a shame because it may lead people to use a deprecated HTML syntax for presenting content instead of using CSS. This will lead to future incompatibilities and extensive use of the “Quirks mode”.

I will summarize below the main differences between the strict and transitional models. Then, the reader may be able to figure out whether he can safely switch to (X)HTML strict or not.

Elements only allowed in transitional (X)HTML

The list below has been compiled using this full XHTML doctypes element comparison

applet,
basefont,
center,
dir,
font,
frame,
frameset,
iframe,
isindex,
menu,
noframes,
s,
strike,
u,

Today, only the iframe element is still used widespread, despite the fact that it can be replaced by object.

Attributes only allowed in transitional (X)HTML

The list below has been compiled using this full XHTML doctypes element attributes comparison

align in anything but tables-related elements,
alink,
background,
bgcolor,
border,
color,
compact,
dir,
face,
frameborder,
height,
hspace,
ismap,
height,
lang,
link,
noshade,
nowrap,
object,
size,
start,
target on anchors a,
text,
type,
version,
vlink,
vspace,
width.

As you can see, most of these attributes can easily be replaced by CSS rules. The only one that is still used widespread is a.target. In my humble opinion, this is not a problem, because you should not decide to open a link in a new window on behalf of the user. Anyway, if you really want to do that, you can still use javascript.

Document structure constraints in strict (X)HTML

The body, blockquote and form must only contain block-lebel elements like div or span.

Choosing the proper DOCTYPE

David Corvoysier — Fri, 06 Mar 2009 12:47:37 +0000

I have been recently asked to tell the differences between HTML 4.0, XHTML 1.0 and HTML 5.0, and I had to dig in the specifications to provide an answer. Doing this, I realized that I did not really pay attention to the DOCTYPE declarations in my web pages so far, possibly leading to unexpected behaviours in some browsers (see the very detailed article on Wikipedia about Quirks mode.

To be short, HTML documents must start with a DOCTYPE declaration that is used by the browser to choose the appropriate rendering. It allows in particular to distinguish between real HTML documents and XHTML documents served as text/html to non-XHTML browsers (though required by the XHTML specification, the DOCTYPE declaration is actually redundant with the namepace declaration if the document is served as application/xhtml+xml).

The current HTML specification is HTML 4.01 (1999). It defines three document types:

HTML 4.01 strict, that relies entirely on CSS for presentation
HTML 4.01 transitional, that still allows deprecated presentational markup
HTML 4.01 frameset, that must only be used to declare framesets

In a first attempt to replace HTML 4.01, the W3C has defined XHTML 1.0 (2000-2002), that redefines HTML 4.01 using a strict XML syntax. Unsurprisingly, XHTML 1.0 also defines three document types:

XHTML 1.0 strict, that is exactly HTML 4.01 strict with closing tags,
XHTML 1.0 transitional, that is exactly HTML 4.01 transitional with closing tags,
XHTML 1.0 frameset, that must only be used to declare framesets.

In a later standardization effort, the W3C produced XHTML 1.1 (WIP), that doesn’t add much, but defines only a strict DOCTYPE.

To summarize, when developing a new page, the first thing you need to decide is if you go for HTML or XHTML. My recommendation is to always choose HTML unless you really need XHTML (for instance because you want to add inline SVG).

Then, in both cases, unless you really need to use the deprecated HTML syntax, then use the strict DOCTYPE.

HTML

XHTML

Please note that according to the W3C XHTML guidelines, the XML declaration () should be omitted, as it triggers quirks mode in older versions of Internet Explorer. This is only a problem if you need to specify a different character encoding than UTF-8 (the default).

SVG inline in XHTML

David Corvoysier — Sun, 01 Feb 2009 18:40:12 +0000

SVG is now supported by all web browsers except IE. Opera has the best SVG support, but Safari and Firefox are not far behind. I think it is now time to take advantage of the powerful SVG features.

What does SVG add to the web developer toolkit ?

Well, as its names indicates, SVG first provides a simple syntax to draw shapes that scale: it is thus particularly handy to draw screen layouts and buttons. I see some people starting to get interested …

But wait: SVG also includes a wide range of gradient, opacity and geometric transformations that can be applied not only to native SVG shapes, but also to images. This give you access to many fancy effects very hard to achieve with HTML alone, like for instance image reflection or fading.

Want more ? Check this out: SVG markup can be modified dynamically using javascript, allowing you to actually animate it. Who said cover-flow at the back of the class ?

Animation through javascript sucks on low-end devices ? Well, SVG also includes native animation capabilities (unfortunately only supported today by Opera).

Fair enough, but the whole web is built on top of HTML, and switching to full SVG is definitely an option.

Well, the cherry on the cake is that you don’t have to: SVG can be inserted inline into XHTML. How powerful that is ?

You will find detailed information on why and how it works on the SVG wiki. A method to have inline SVG supported by IE using the Adobe SVG viewer is also provided.

Here is an overview of what you need to do.

First, you need to use XHTML, because plain old HTML doesn’t support being extended by another markup language, and your SVG markup will be ignored by the browsers.
Second, you need to make sure that the SVG-aware browsers know this is XHTML, by delivering your content to them as application/xhtml+xml. You probably nevertheless still want to deliver your content to IE as text/html, so what you need is conditional mime-types based on the Accept header of the user agent.
- it can be done at the HTTP server level. See example below for apache (example taken from the SVG wiki):
```
AddType text/html .xhtml
RewriteEngine on
RewriteBase /
RewriteCond %{HTTP_ACCEPT} application/xhtml\+xml
RewriteCond %{HTTP_ACCEPT} !application/xhtml\+xml\s*;\s*q=0
RewriteCond %{REQUEST_URI} \.xhtml$
RewriteCond %{THE_REQUEST} HTTP/1\.1
RewriteRule .* - [T=application/xhtml+xml]
```
- If you don’t have access to your web server configuration, you can still:
  - modify headers on the fly. See an example for PHP below:
```
if(preg_match("|application/xhtml\+xml|i",$_SERVER["HTTP_ACCEPT"]){
  header("Content-Type: application/xhtml+xml");
}
```
  - or insert meta tags in the HTML head to specify the proper mime-type. See another example for PHP:
```
if(preg_match("|application/xhtml\+xml|i",$_SERVER["HTTP_ACCEPT"]){
  echo "" ;
}
```
  - If you use WordPress, the simpliest way is to use the Content-Negotiation plugin
Third, put your SVG under an SVG tag


    
    HTML Text with SVG background

Fourth, style your SVG with CSS

The result should look like this:

HTML Text with SVG background

Please note in particular how the CSS styling allows the SVG to be perfectly integrated in the page:

the absolute positioning of the svg root element allows the next-coming HTML span to appear on top of the SVG background
the :hover behaviour allows a dynamic update of the SVG rect element fill attribute when the element is moused over

You will find more examples below: