Kaizou

Generating custom javascript events

David Corvoysier — Mon, 29 Mar 2010 18:03:18 +0000

HTML 5 introduces many new exciting features, and it is very tempting for the web developer to start buiding pages taking advantage of this new syntax as soon as an early implementation shows up.
For those aiming at the masses, it may however be necessary to fill the HTML 5 implementation gaps of some browsers with custom javascript implementations.
Fair enough, says the web developer: thanks to Javascript extensibility mechanisms, it is easy to add new properties and methods to existing objects and even to create new javascript objects, but what about all these new javascript events ?
Well my friends, since DOM level 2 specification it is possible to create, initialize and dispatch custom javascript events.
Basically you can create a javascript event by calling the DOM document createEvent method:

var evt = document.createEvent("Event");
...
var mevt = document.createEvent("MouseEvent");

The createEvent argument defines the Event interface:

UIEvent : for DOMFocusIn, DOMFocusOut & DOMActivate events
MouseEvent: for click, mousedown/up/over/move/out
MutationEvent: for all DOMXX modification events
HTMLEvent: for load, unload, abort, error, select, change, submit, reset, focus, blur, resize, scroll events
Event: Any other event

Note: You cannot generate a key event
Once you’ve instantiated an event of a specific type, you can specify its attributes using the corresponding initEvent method:

var evt = document.createEvent("Event");
evt.initEvent("myEvent",true,true);
...
var mevt = document.createEvent("MouseEvent");
mevt.initMouseEvent("click",true,true,...);

The first three parameters are common to all initEvents functions: the first argument specifies the event type, the second indicates if the event can bubble and the third if its default action can be prevented.
Once the event has been created and initialized, it can be dispatched to the document or to a specific node:

var evt = document.createEvent("Event");
evt.initEvent("myEvent",true,true);
document.dispatchEvent(evt);
...
or
...
var target = document.getElementById("myTarget");
target.dispatchEvent(evt);

Of course, you also need to specify an event handler if you actually want to catch this new event:

document.addEventListener("myEvent",myEventHandler,false);
...
or
...
var target = document.getElementById("myTarget");
target.addEventListener("myEvent",myEventHandler,false);

CSS 3 Web Fonts

David Corvoysier — Sun, 21 Jun 2009 15:23:14 +0000

Among other cool things, CSS 3.0 finally introduces an old feature that had only been implemented so far using proprietary extensions, and therefore did not receive the attention it deserved: Web Fonts !

As specified in the CSS Fonts Module Level 3 specifications, web developers can insert @font-face CSS rules into their stylesheets to specify explicitly the location of the font resource corresponding to a font face specified in that stylesheet, thus allowing a consistent rendering of their site.

For instance, I use the “Soviet” font family for the title of this blog, but this font is not so common, so I inserted the following code in the site main stylesheet:

@font-face {
  font-family: "Soviet";
  src: url("./fonts/Soviet2.ttf") format("truetype");
}

And in the CSS rule corresponding to the site title:

#header h1#logo-text a {
	position: absolute;
	margin: 0; padding: 0;
	font: 56px 'Soviet', 'Trebuchet MS', Sans-serif;
	letter-spacing: -3px;
	text-decoration: none;
	color: #000;
	top: 58px; left: 300px;
}

This causes compatible web browsers to download the Soviet Font from my site and correctly display the site title.

Of course, not many web browsers today support Web Fonts (according to my tests, only WebKit nightlies have the correct display), but things will change shortly, as Firefox 3.5 should support them.

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,
…

Browser HTTP 1.1 caching compliancy test

David Corvoysier — Sun, 22 Mar 2009 15:20:21 +0000

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

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).

Inline SVG Fallback

David Corvoysier — Mon, 02 Mar 2009 13:07:15 +0000

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:

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 ?

Well, IE ignores all SVG and displays only the HTML markup embedded in the foreignObject tag: