Learning the World » XHTML

Embedding YouTube Video with iPhone Fallback

Martin Kliehm — Wed, 25 Nov 2009 17:00:01 +0000

Just a quick note as a reminder to myself how to embed YouTube videos in a standards compliant, valid XHTML syntax. It works across all current browsers, doesn’t use , and has the elegant fallback displaying a still image that is linked to YouTube, thus enabling iPhone users without Flash to view the video.

vi/ VideoID/0.jpg" width="480" height="360" alt="[Video title]" />
YouTube Video

Please note that there are spaces in the code above to allow linebreaks. If you copy and paste you need to remove those.

Here is an example:

YouTube Video

Farewell, XML declaration

Martin Kliehm — Wed, 04 Jun 2008 16:00:04 +0000

For years I have been using an XML declaration prior to my DOCTYPE declaration:

TR/xhtml1/DTD/ xhtml1-strict.dtd">

It was obvious for me that such a declaration would be a good thing to have since XHTML is XML after all. Only later I learned that it triggers a bug in IE6 to render pages in quirks mode with a broken box model. But I was used to build workarounds for Internet Explorer bugs since IE 3.0 and never knew anything but the broken box model in IE, so I continued to use the declaration.

Until recently my colleague Thomas Junghans took the trouble to research, and found this phrase in the XHTML specification:

An XML declaration is not required in all XML documents; however XHTML document authors are strongly encouraged to use XML declarations in all their documents. Such a declaration is required when the character encoding of the document is other than the default UTF-8 or UTF-16 and no encoding was determined by a higher-level protocol.

The declaration is not required as long as you encode in UTF-8 or UTF-16, you are only strongly encouraged to use it. Gasp!

Richard Ishida lists some advantages of using the declaration when serving the pages with an XML MIME type or viewing them offline, however I’m convinced the disadvantages prevail.

So as long we are stuck with IE6 — and people say that could be as long as 2014 when support for Windows XP ends (reminder to self: throw a party on 8 April, 2014) — I will refrain from using the XML declaration. Amen.

The XHTML Access Module

Martin Kliehm — Fri, 11 Jan 2008 20:45:21 +0000

I would like to introduce the XHTML Access Module, a new working draft released by the XHTML 2 Working Group of the World Wide Web Consortium (W3C). As you know, the X in XHTML stands for “extensible.” Also you may have heard that XHTML 1.1 and 2 are modular specifications, so it’s easier and more flexible to extend the core modules by bolting some extra modules on whenever special features are required. I have described before how to extend XHTML with the Target Module or the Accessible Rich Internet Applications (ARIA) modules. So the XHTML Access Module is a new module intended to improve accessibility and extend XHTML Roles.

Otherwise the draft’s abstract and introduction are vague and leave room for interpretation what this is exactly about. What I have understood is:

This module defines a new element with the name access.
The element can be used to define an access key for any other element.
Another usage could be as a skip link as there is a targetid and targetrole attribute.

For me it remained unclear whether this element belongs in the head like link elements, or in the body like anchors or label elements. Anyway, among other Common attributes it can have a title plus a few new attributes: key, targetid, targetrole, and activate.

The key attribute is optional and defines an access key in a generic way. So far there was only the accesskey attribute for anchors and form elements, now any fancy Web 2.0 div element impersonating something else can receive focus by striking a key. Browser vendors are encouraged to emphasize the responsive character in a word, like underlining it. Also the working draft provides a description what user agents should do if there are conflicts with existing shortcut keys. So the team paid attention to the discussions about the reasonableness of the accesskey attribute.
The targetid and targetrole attributes assign targets by id or role. There can be more than one of each, comma separated. I imagine that’s like tabbing through elements, but with a shortcut key.
The last new access attribute is activate. I must admit I have no clear idea what “activate” could mean or what this attribute is good for. An element receives focus, so there should be a perceivable effect, some sort of feedback to the user. If an author does not want this, there are ways to suppress default renderings by CSS. If she doesn’t want the focus event to trigger something, there’s JavaScript to cancel it.

I thought of playing with the new element, but it’s too early for a test implementation. The working draft still lacks a XML Schema that could be used in namespaces. It would be possible to extend a DTD without much conflicts, alas the module doesn’t come in one box, but in two (again). So you would need to append both the qname module and the access module instead of simply adding the access module. I don’t understand the rationale for this separation, but I see it’s more painful for an author to implement it that way.

However, the access element provides a better and more generic functionality than existing alternatives, it fills the gap of missing access keys, and if I got it right it defines a standardized method for skip links, although this could be expressed clearer. Apart from the usual suspects there is Google’s accessibility specialist T. V. Raman on the team, and Richard Schwerdtfeger from the team that built more accessibility into Firefox, the Open Document Format, and IAccessible2 as an accessibility interface for screen readers. So my bet is we will see support for this element in our favorite browser as soon as this draft is more mature. Your turn, Microsoft.

XHTML 1.1 Second Edition with Target Attribute

Martin Kliehm — Thu, 22 Feb 2007 16:30:35 +0000

When I switched from HTML 4 to XHTML 1.1 a couple of years ago, I soon found the target attribute was missing. I have never been in love with the target attribute anyway, but some clients insisted that their links should open in a new window. So I did some research.

You won’t believe how much myth and misinformation is out there. Some say it’s deprecated. In fact it never was. It is part of XHTML 2 and XHTML Basic, and there is a target module in XHTML 1.1, the modularized version of XHTML. The attribute is not included in HTML 4.01 Strict and XHTML 1.0 Strict because it was then considered to be related to frames and iframes, but it’s not marked “deprecated.” It was simply not in the core set of modules for the XHTML 1.1 driver.

Some people argued it’s a behavior and thus belongs into unobtrusive JavaScript. But then clicking on a link to get to another page is also some functionality, and nobody would think of replacing anchors with loads of bloated script to simulate such a basic behavior.

So I ended up extending the extensible with a customized DTD:


PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/ DTD/xhtml11.dtd">
%xhtml11.dtd;
 


PUBLIC "-//W3C//ELEMENTS XHTML Target 1.0//EN"
"http://www.w3.org/TR/ xhtml-modularization/DTD/ xhtml-target-1.mod">
%xhtml-target.mod;



However, now I have to bid farewell to that bizarre old friend: the working draft of XHTML 1.1 Second Edition includes the target module in the core set, finally. I’m relieved because tinkering with DTDs is a pain, but it had style …

Note that in the current version target is not yet included in XHTML 1.1 Schema, but I have been assured it will definitely be in the final version.



Reforming HTML
Martin Kliehm — Mon, 30 Oct 2006 12:18:29 +0000
Many good people have expressed their concern about the state of the W3C, like Jeffrey Zeldmann, Molly Holzschlag, Eric Meyer, or Björn Höhrmann. Tim Berners-Lee responded a few months ago. Now he announced reforms in his TimBL blog.

The transition from HTML to XML has failed, so they will evolve HTML incrementally with more powerful XHTML features as incentives for switching. We have seen that recently with the XHTML 1.1 role attribute module. Another XHTML 2.0 feature I can foresee as a XHTML 1.1 module is the href attribute on all elements, not just anchors. Convince a browser vendor to implement this feature, and if developers want to play with the cool stuff, they have to switch to XHTML …

The development process of the drafts will be controlled by a new HTML group with different chair and staff contact. Also the work on XHTML 2 will proceed independently from HTML. HTML forms will be extended to become a subset of the powerful XForms. And the W3C finally bought some new server hardware for the W3C validator.

The new groups shall be more responsive, with powerful issue tracking systems, but at the same time Berners-Lee asks for respectfulness and social awareness. We are not talking about technical issues alone. There are people and their feelings involved as well, and we have to pay more respect to that.

Get involved! You can discuss on the W3C QA blog about the proposal, or participate in the QA interest group, the I18N or the WAI outreach working groups — even if your company is not a member of the W3C.

Other opinions on this topic:


Anne van Kesteren: Victory: new HTML WG
Joe Clark: How not to fix HTML
Roger Johansson: New W3C working group to improve HTML
Sean Fraser: W3C HTML Reinvention
Chris Wilson: You, me and the W3C (aka Reinventing HTML)




Best Practices in Web Development
Martin Kliehm — Mon, 10 Jul 2006 16:56:19 +0000
Roger Johansson and Sean Fraser recently reviewed websites which were submitted for the CSS Reboot Spring 2006, and they seemed to be quite shocked when 71.8% failed to validate. While this is sobering and to a degree surprising — one might expect better results from CSS aware developers on a relaunch — it confirmed my own results from reviewing a couple of high profile websites for clients.

In this article:


    Case study
    Best practices in HTML
    Best practices in CSS
    Best practices for search engines


Case study

Over the years we made several technical analyses for the clients’ own websites and some of their competitors, including major German broadcasting companies, TV program journals, and a couple of large online travel sites.

We were checking for overall performance like file sizes as well as best practices in (X)HTML, CSS, semantics, and some other aspects of friendliness to users and search engines. We mostly skipped accessibility because there were already severe errors in the other areas.

It’s not like these websites were made by some backstreet crack houses agencies. All have a well-known logo stuck to them, most of them get more than a million visits each month, some up to more than a hundred million. Still the reviews felt like a time-travel to 1998. In our elite circles we speak about a “new professionalism,” but HTML in the wild is still a very dark and ugly jungle.

Most common errors were missing alt-attributes and unencoded &-characters in URLs. Also quite common were XML endslashes in HTML documents, or hacks from the nineties: proprietary attributes like background in table data, height in a table row, marginwidth, marginheight, topmargin and leftmargin, or missing type attributes in style and script tags.

Getting into the depths of old-school programming we found proprietary tags like , , or , misconceptions like valign="center" instead of "middle", forgotten closing tags, or tag soup like the classic form between table rows (to prevent top margins), block level elements inside of inline elements, 
 tags around everything (including tables and headlines!), or script tags before or after  . Especially ad servers and site statistics were infamous for their crappy stone-age code.


Only a few were missing a doctype declaration (DTD) altogether, most ran HTML transitional 4.01 in quirks mode, only one claimed to be XHTML 1.1 (gasp). Seven out of ten had a charset encoding, but only the XHTML website did care to define the site’s language. Almost all had no clue about CSS positioning and used table layout.

Sometimes we encountered code where developers obviously hadn’t understood even the most basic principles of CSS 1. They used either font tags with style attributes, or other tags just like font tags with a lot of repeated inline style. Thus the advantages of CSS through central style sheets with classes and IDs were counteracted.

It didn’t come as a surprise that the few websites using CSS 2 for layout had significant smaller file sizes. Those with CSS 2 had between 15-21 KB of HTML, their competitors with table layout 55-95 KB. Still you got to pay attention to the file size of images and rich media (including banners) as they frequently blow up the total amount. Be aware of DHTML menus, as they have a tendency to get out of control sizewise (40k JavaScript in one case, 85k in another). Less than a total of 100k for the home page should be sufficient, even for sites with rich graphic interfaces.

I don’t want to bore you with further rants about burning bandwidth with 600k large home pages (multiply that by a million), hence we thought positive and made a checklist of best practices. Although the checkpoints appear to be quite obvious and common sense when you read them, you might be surprised that the best website managed to fulfil 22 out of 29 checkpoints, the worst only 8, with an average of 12.

By the way, the HTML and CSS part of the checklist is more or less the same we use for testing the qualifications of job applicants. We associated a severity grade (major, average, minor) with each checkpoint, and for each error in the small task we give them we subtract 3, 2, or 1 point(s) respectively from a maximum of 100. Half the amount is subtracted when a checkpoint is partially fulfilled. We adopted that system from the German accessibility test — it’s fair and a great way to compare test results.

Here’s the short version of our checklist. Feel free to make your own severity rating. Just be consistent in your own tests to get comparable results.

Best practices in HTML


    The document must validate as HTML or XHTML.
    The document must have a DTD.
    The document must have a character encoding, either through a HTTP header or a meta tag.
    
        The document should have the language defined in the following ways:
        
            
            
            
        
    
    All attribute values should be quoted. In XHTML, quotes are mandatory.
    Element and attribute names should use a consistent case to enhance readability, preferred is lowercase for XHTML compability.
    Code should be well  to help maintaining developers to get a fast grip of the basic structure and key concepts.
    Code should be consistently indented, tabs preferred over spaces.
    Images, image maps and scripted content must have an alt-attribute with an appropriate value.
    Images should always specify their width and height to allow browsers to continue rendering while waiting for the image data.
    Some special characters like ", <, >, and & (especially within attributes like href or src) must always be replaced by their character entities or numeric character references (NCR). Also characters not included in the character set, like € in ISO 8859-1, must be replaced. The W3C I18N activity group further recommends to replace other special characters like –, but not common characters like “ü” in German texts or “é” in French to maintain code readability.
    script and style tags must have a type attribute.
    
        JavaScript code should be included using external files for caching and better maintenance.
        Of course with Yahoo’s performance research about browser cache and HTTP requests you could discuss if external files load faster with several server requests through script src="foo.js" or just one request and internal HTML code, but either way you should use central, non-redundant files and include them in one way or another.
    


Best practices in CSS


    CSS must validate.
    Elements should be positioned with CSS 2, not tables.
    All ornamental lines, borders, background colors and -images, underlines and other decorational elements should be rendered with CSS 2.
    Text should be formatted with CSS 1, not with font tags.
    All style sheets should be included in reusable, centrally maintainable, and cacheable external CSS files, not as redundant code within the HTML files.
    External CSS files should be sent with the correct MIME type (text/css).
    CSS classes and IDs must be valid, i.e. beginning with a letter, not a number or an underscore. IDs must be unique. Their names should be generic, describe functionality rather than appearance.


Best practices for search engines


    Use a descriptive title with the name of the website and consistent separating characters in it.
    Use keywords, keyphrases, and a description reflecting the page’s content.
    The URL should be descriptive, human-readable, easy to remember, to bookmark, and easy to spell on a phone. Don’t bother the user with file extensions, thus you will be future compatible and independent from your current software.
    Use the Robots Exclusion Standard, i.e. robots.txt.
    The content should be as high up in the code as possible as it gets more relevance there.
    Use proper semantic code, like headlines, or list items for anything that resembles a list. Don’t use list items to get bullet points or headlines to set bold text.
    Use  tags to specify relations between pages, like rel="start", chapter, prev, or next, as search engines might value your start page more, or browsers could preload next pages.
    Use a favorite icon for bookmarking and to keep your error log clean.
    Use the PICS standard to signal search engines and filter programs that your website is safe for kids.