Following a previous post about HTTP 1.1 caching mechanisms, I have been asked whether common browsers were actually compliant or not, so I wrote a little test to verify if at least basic features were supported.
The results for your browser will appear in the frame below.
Update: This is a new version with cache headers completely handled by PHP instead of using apache mod_expires. I had to do this because I could’nt deactivate chunk transfer encoding of pages generated by php on my host, and this prevents HTTP 1.1 caching headers to be inserted by apache … the test seems to work now, but it is still in beta
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.
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.
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.
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 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
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
XHTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
Please note that according to the W3C XHTML guidelines, the XML declaration (<?xml version="1.0" encoding="UTF-8"?>) 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).
As you may already know, IE doesn’t support SVG unless you install a plugin like the ASV, that is unfortunately not supported anymore by Adobe.
As a web developer willing to use inline SVG, your best bet is thus to provide fallback mechanisms to display IE visitors at least a degraded version of what you’re trying to express/demonstrate, and teach them what they’re missing by sticking with evil IE.
Luckily, IE will simply ignore any markup it does’nt know, so you usually don’t need to bother masking or removing the SVG markup when serving pages to your IE visitors.
This is however not true if you insert plain text if your SVG … Let’s take an example.
When you insert the following SVG in your page:
<svg xmlns="http://www.w3.org/2000/svg"
version="1.1" wiewBox="0 0 200 100">
<text x="0" y="0"
font-family="Verdana"
font-size="55" fill="blue" >
Hello, out there
</text>
</svg>
IE will ignore all SVG markup and formatting, and actually display the plain text with the current style:
Hello, out there
Now, what happens when you insert HTML markup inside your SVG using the foreignObject tag ?
<svg xmlns="http://www.w3.org/2000/svg"
version="1.1" wiewBox="0 0 200 100">
<foreignObject width="200" height="100">
<span style="color:blue;">
Hello, out there
</span>
</foreignObject>
</svg>
Well, IE ignores all SVG and displays only the HTML markup embedded in the foreignObject tag:
In a nutshell, the actual SVG and the IE fallback are embedded in an SVG switch:
SVG aware browsers will recognize the conditional directive, and render the first alternative they understand (the actual SVG), ignoring the other (the IE fallback)
IE will silently ignore all SVG markup (including the conditional directive), and go straight to the fallback written in HTML.
In the example, below, SVG-aware browsers will display a red circle, and IE a simple text.
<svg xmlns="http://www.w3.org/2000/svg"
version="1.1" wiewBox="0 0 200 100">
<switch>
<circle cx="150px" cy="100px" r="50px"
fill="#ff0000" stroke="#000000"
stroke-width="5px"/>
<foreignObject width="200" height="100">
<span style="color:red;">
This is not a red circle
</span>
</foreignObject>
</switch>
</svg>