More about IT >

HTML 5 Sucks

Since I first wrote this critique, the languages of the web have evolved steadily. Some of the horrors I whinged about have been fixed, others dug deeper in. My own views have changed a little too, mainly with more bright ideas to make it author-friendly. But HTML 5 still sucks.

Heresy

It's true. There are a few nice things about HTML 5 but for the most part it has really gone the wrong way. Wow, the invective I get when I criticise it. It feels like I am a heretic, like we have a religion on our hands. "It's best practice," the solemn words are intoned as yet another O'Reilly classic whisks past my head.

Well, let's not forget the W3C's current thoughts at http://www.whatwg.org/specs/web-apps/current-work/.

"Best practice" – really? Best for whom?

Recall that HTML was originally supposed to be the human-readable lingua franca of the web, the language that anybody can throw together and get something up there. Yet as it evolved HTML saw itself more and more as a programming language, to be generated by machines for other machines to parse. Human needs were supposedly catered for – plain HTML is still human-readable for example. But the truth is, in functional terms its ethos has become subservient to the mantra.

Ah yes, the mantra. The author provides the content, HTML the structure or "semantics", CSS the style. Then there is JavaScript for the smart, programmatic interactivity. Make no mistake, the parallel use of these several languages is baked into the HTML 5 specification.

HTML 1 tried to do something practical for the author by creating an inherent intimacy between semantics and style, reflecting the way we design and read documents. By the time we reached HTML 4 the emphasis had wholly changed, seeking to do something practical for the system developer by divorcing style from semantics. It had turned the whole thing back to front. But the problem was, as every page author and designer knows, styling and semantics are indeed indissolubly linked: if you try to separate them you are bound to run into trouble.

The original understanding of semantics as being meaningful to the human reader has morphed into one as being meaningful to the code processor. We have moved away from the original user-centric language and, since HTML 4, have instead pretended to a rigid bottom-up distinction between semantics, content and style. Pretend to? That's right – it has never worked and never will. Web pages and the people who write them are top-down things. By that I mean that we start with the broad container and work down to the details. Bottom-up is fine in a rule book for a programming language sich as javascript, but not for a language designed to communicate stuff to us mere mortals, we simply do not work that way.

HTML 5 has been forced to recognise this to some extent, making practical concessions to the reader such as recognising the value of compatibility with old web pages and rowing back on strict XML conformance. But, for new pages, it has pursued its machine-oriented mantra with the same old blinkered fanaticism.

Style is, supposedly, banished as ruthlessly as ever to CSS, with HTML reserved for semantics. In practice this neither has happened nor can happen. Yet to challenge the mantra is to invite lectures, anger, prejudice and hypocrisy of a truly religious depth and fervour. I actually get more angry rants over this than I do over my views on religion (only the ethereally mathematical polyhedra bring me more emotional vitriol than the objective facts of information technology). In truth, this religious fervour is probably the thing about HTML 5 that sucks the most, because it prevents everything else from being tackled. Let this vain heretic show you a few examples anyway.

Tabular layout

HTML Tables layout is reserved for organised data, and using it for page layout is a Cardinal Sin. Nesting tables is even worse, a heresy of Satanic proportion. But what if I want a table-like page layout? By this I mean "table-like" in the sense of block-based. This kind of block-based layout is very common in organisational "house styles" such as those used by the UK Government – my meat-and-drink for over twenty years – where it often has to work in printed A4 page format, too. You might think, "well, stick to PDF", but don't forget that HTML 5 is the W3C Master Plan to replace such unfortunately practical inconveniences, it's not just a way to get journalistic content online. And even Government Departments have moved online and regard the web page as the primary information medium, with PDF reaching the parts, such as properly formatted printed documents, that the web can not.

To be fair, back in the day some really crap GUI web tools, such as early versions of DreamWeaver and FrontPage, minced up web pages into relentlessly nested tables with a myriad tiny cells until the poor web browser overloaded its horrible-tangle stack and crashed. They even diced up images so that each fragment, now an image in its own right, fitted into its own little cell. Such table-based automata were pure digital hideousness and "Don't use Tables for page layout" very properly got dinned into every rookie design-tool codie for a generation. But, as we shall see, the users of those tools are not the creators of the tools and the baby got thrown out with the bathwater.

Meanwhile, what are we supposed to do instead? Why, use CSS of course. It has lots of convoluted toys to create page layouts that dance to the tune of the user agent. But not, alas, to the tune of the content author. Content dances around at the software agent's pleasure and the poor reader sees only an unpredictable reshuffling of the author's original vision. Even assistive technologies get thoroughly stuffed in their desperation to second-guess what all those arcane CSS properties are intended to convey in terms of sequential presentation. More on that in the section on normal flow.

Meanwhile, what about the inverse problem, if we have tabular data but our code generation tool was written by a good little droid and conforms to the layout mantra? Why, how kind, the CSS table model provides substitutes for all the missing table components. Oh, not quite all; the rowspan and colspan substitutes need knowledge of the size of the overlapped cells, which is not always available.

Yes indeed, you can now use a styling language to mimic the semantics of a data table. Having been told solemnly not to use semantic markup to implement styling, we have instead been given a semantic implementation baked into the styling markup language. This direct reversal, dear souls, is self-defeating to the point of being utterly mental. Instead of unacceptable old Web Devils like me styling page layouts using semantic tables, it is somehow acceptable for HTML 5 Angels to code semantic tables using a styling language. Whatever happened to the rigorous separation of semantics, content and style? Oh dear.

And of course, we couldn't let CSS Tables go without borking the implementation, could we? The HTML global cellspacing and cellpadding, along with the local rowspan and colspan, are now an utter nightmare to implement. The poor page creator must struggle with the most complex hierarchies of presentation modes and sizing algorithms for the oversized table cells as they dance to the tune of that relentlessly literal-minded user agent.

While on the subject of tables, Wikitext (the markup language for Wikipedia) has a brilliant feature in sortable tables. Just click the icon in the column heading and the row display order is sorted on that column. It is incredibly useful when viewing big lists with lots of information fields for each entry. Many of you will have long used it in spreadsheets almost unconsciously. When you stop and think, all it does is restyle the existing information, it can hardly be described as programmatic. Yet the Wikitext implementation requires javascript, as nether HTML nor CSS has the necessary capability. Such a simple viewing tool really should not rely on a coding language to deliver it. All it needs is for something like:

<table sort="on">

or

<table style="sort:on;">

Frames

Many publishing pros, especially those producing magazines, handbooks and other documents with strictly-defined house styles, will tell you how important frames are for effective page layout.

Early versions of HTML offered you a frame element to position a subsidiary web page in the main one. A frameset defined a layout incorporating multiple frames, which allowed a site to build a page from standard blocks without recoding each block in every page. You could even click through subsidiary pages in a given frame without disturbing the others. The problem was, the web browser could bookmark only the main frameset page, it didn't record which sub-pages populated the frames. So if you clicked through a few pages in one or two frames, the browser had no record of the page state you actually wanted to bookmark. And those framesets were getting so plumb popular, they were everywhere – the web was becoming un-navigable!

So did folks improve the Favourites (aka Bookmarks) function to include every page in the frameset? No, instead they decided to hate frames on principle, to just burn the whole thing and save having to think straight. Framesets were banned. That, my friends, was the moment when the W3C wholly lost touch with the professional page designer. And wow! It was a long time ago now, Deprecated in HTML 3 if I remember rightly, removed wholly from HTML4.

Somehow the iframe survived, as a kind of apology for a media container. It has even been regaining some of its popularity. Using it, you can create a window in your page, into which you can pour another page. But iframes are not well behaved – the window is difficult to adapt to circumstance. Each sits wherever normal flow drops it and to align multiple iframes the HTML 5 designer must resort to floating and/or layering containing divs all over the place, managing how they all jump around and how the iframes they contain might overlap each other. You can't even size an iframe to its content, so if you have different sized iframes you will have to size all their containers individually. And if the content grows, then you must use javascript to guess at a new size for the container. It all makes an utter cabbage of the way professional designers need to go about their business. The embed element is a bit like an iframe for media players to drop stuff into. You can even drom a web page in (with MIME type text/html) but it still has pretty mucn the same layout problems.

What we need is actually really simple: tables for tabular data, frames for page layout and urls for the 21st century. Let me repeat that. No, really, it's so simple I don't need to. That's all. W3C, just shut up about Seven Hells for the Unworthy and go do it, all right?

Normal flow

The CSS specification has a concept of "normal flow", in which content is presented in the order it appears in the sequential flow of the source page. At first sight this appears to be inevitable and trivial – surely any web page is displayed in the sequence in which it is written?

Unfortunately, CSS has the ability to break normal flow. For example a right-aligned floating box has to be inserted in the page ''before'' the content displayed to the left of it. Thus, the earlier block of content is displayed ''after'' the subsequently coded block and to make it intelligible the source content has to be swapped round, breaking the normal flow.

I once got into an argument over whether we should use HTML tables or CSS to lay out a certain page. I was loftily informed that tables, and especially nested tables, break accessibility tools such as screen readers for the blind. I coded two examples, one using nested HTML Tables and the other CSS. The CSS version, in order to display properly, was forced to break normal flow. Then I asked a blind colleague to see what he could make of them. His screen reader coped flawlessly and utterly transparently with the nested tables. It would always tell him if it encountered any data tables or got a bit worried about them. This time it knew not to bother. When I told him the HTML was not only tables but nested he was astonished – his reader had given not the slightes clue that there were any at all. The CSS page fared less well. The scrambling of normal flow was read back to him verbatim, rendering the content unintelligible. Would our corporate web developers kindly update their guidelines in the light of an evidence-based formal request? Not likely, the religious fervour of the mantra was thrown, loftily as ever, back in both our faces, I have to say really quite rudely. Galileo was wrong, Jupiter's moons do not go round it. Stop wasting our important time and go do something else, if you really know so little about theology.

Is normal flow a semantic or a stylistic concept? Well, if we break normal flow and present the second part of a page before the first part so the reader encounters it first, as the blind assistive text reader did, I think you will agree that it has broken the semantics. But now consider a centrally-focused layout with boxouts all around. Different people respond to different visual cues. Some will home in on the prettiest graphic, others on the boldest text, others the top-right corner (or whatever their national linguistic convention). A good layout caters for all of these. A typical scanning paradigm (hardly a "pattern") for such a page is to start in the middle and then move progressively outwards in whatever direction meets your interest, possibly in a wildly zigzag path. At each node, when the reader is ready to move on, the eye scans the surrounding area in whatever mode is most appropriate to the reader's anticipation: more detail, a peer node, back to the core? This can be very effective in, say, a stakeholder analysis for a large and complex project. We may happily code the boxouts in any order because we must break normal flow in order to position each to best stylistic effect. This time, breaking normal flow does not break the semantics.

This helps to illustrate how the relative positioning of objects is sometimes a matter of semantics and sometimes a matter of style. Page layout cannot be cleanly dumped in either camp, and separating the two into distinct languages makes more cabbage for the poor page designer.

Consider a page comprising a diagram whose physical layout is determined by presentational elements such as frames and SVG graphics. This layout defines the semantics of the overall structure, with detailed semantics added using html markup. There may be an obvious normal flow, a master path through the diagram, but there is no sane way in which this can be hooked into the code design for all that positioning-cum-semantics salad. What normal flow needs is a human-centric markup, a way of tagging elements sequentially so that a reader app will process them in the correct order. One way to achieve this would be to create a flow attribute which may be added to the containing elements which string together to create the normal flow, for example:

<div flow="17">My content</div>

Any rendering agent now knows the logical order in which to present the content and can check out the other styling attributes for the niceties.

div or diva?

We have seen there is a distinction between the stylistic and semantic aspects of positioning content in the page. The HTML <div> element is a curiously ambivalent construct. Being part of the semantic language specification we should expect it to contain a set of semantically related items, and sometimes it does. But it has no inherent semantic of its own, in fact it was deliberately introduced to function in a wholly contradictory way, to stylistically present the contained items as a visual grouping. In this it is merely an empty placeholder for the accompanying CSS and is typically used as such. But often the purpose of that accompanying CSS is to distinguish the div content from the surrounding content, as a way to implement the semantic function of a content separator and container. In other words, the div is a dog's breakfast of an element. It is both a styling convenience and a semantic one because it is not possible to cleanly separate the two. It is essentially this ambivalence which has created the ability to break normal flow.

One of the nastier things about relying on divs is that it is often necessary to nest a fragment inside a div, before it can be styled the way you want. For example the <img> element does not accept all the CSS positioning parameters, so it has to be wrapped in a div before it can be properly positioned. Arranging several images together then requires a complex nest of divs. It would be so much better if the image containers themselves could accept the necessary positioning code.

And the div has an even darker side. It has begun taking over the role of nested tables as the horror of automated page building. Everywhere on the web today you will find vast, complex nests of <div> elements vying with each other to misplace the closing </div> tags. Classes abound, with CSS calling up such cascades of burgeoning stylesheets and JavaScript doing the same, that the chances of a class name conflicting across two sheets rise exponentially, while the chances of finding and fixing the problem without some superficial kludge fall similarly.

In all this mess, normal flow is thrown to the winds. The poor assistive reader is left in deeper mire than ever nested tables could achieve. The almost universal tendency these days to automated code salad is another reason why we need a separate approach to markup if we wish to designate a strictly semantic construct such as normal flow.

The div has proved its worth and cannot now be shunted aside because it breaks the mantra. Far better to shunt the mantra aside and accept that HTML must embody stylistic as well as semantic functions. Oh, and those guidelines to developers, you can stop yelling "don't use nested tables" at them and start yelling "don't use nested divs". Yesterday is already too late to start. I can't hear you, louder! "DON'T USE NESTED DIVS!". That's it, well done. Now, go live up to it.

The tale of em and strong

Way back when, HTML text could be italicised using <i> and bolded (or emboldened) using <b>. But this was deemed stylistic and the mantra banned it to CSS. So HTML grew <em> and <strong>, the supposed semantics underlying the styles, which could then be re-styled using CSS.

But what is the semantic of strengthening a phrase? How does it differ from emphasising the phrase? To find out, we inevitably refer to the context in which it occurs. It may for example be that one is shouted while the other whispered, that one is a global declaration while the other is a variable value, that one is a section title while the other is an image caption (use either to choice for your table titles), or that one is used merely to distinguish it from the other in a hierarchical document outline. There is in fact no semantic set in stone other than any inherent in the visual style itself. To the surprise of nobody in the real world, the rule of <em> and <strong> never really caught on. We need <i> and <b>, they can never go away.

The dominance of the <i> and <b> styles has actually been acknowledged in HTML 5. They are no longer deprecated, as they once were. Meanwhile <em> and <strong> remain useful to the data codie who has no knowledge of the intended rendering. The two systems now live uncomfortably alongside each other, the worm you cannot kill in the organic apple. HTML 5 may be intended as a coder's paradise but the truth is, time and again the hard facts of life force it to break its own mantras. And even when it tries not to, there are plenty of real people out here with the strongest of practical motivations to do that for it.

Active and passive: Cascading Simple Smarts

Then there's the active stuff, the smarts, that we do with JavaScript. HTML and CSS are the passive languages, right? If you want anything actually doing, then JavaScript is your friend, right? Oh dear again.

Well, on the one hand we have hyperlinks and forms, both of which can perform useful interactions and neither of which needs JavaScript or even CSS. "Oh, but I mean programmatic interactions of course", cries the thrower of the books, "Hyperlinks are just dumb navigation".

OK, so on the other hand we have the drop-down menu, another dumb navigation widget. Now it is a funny thing but almost every element of the classic windowing user interface – buttons, checkboxes and the rest – can be created in HTML alone, with the lone exception of drop-down menus. You can use a mouse to click on a widget or a hyperlink, sure, but you can't use it to open a drop-down navigation menu, whether through hovering or clicking, without some crafty CSS3 or JavaScript. Like it's a magic smart thing that needs special treatment, just to be able to hover a mouse and display a list – in the right place – that is already written into the page, yeah? Yet an HTML form submission has to pull together a long response string from the user-set widget states, that's way more programmatic than just displaying or hiding a list that is already there.

No, when it comes to HTML vs. JavaScript, the mantra has been borked both ways.

Then, there are the CSS3 tricks such as conditionals and custom variables. I am sorry, mantra-chanters, but these are unarguably programmatic as opposed to passively stylistic. And you added these to CSS long after specifically creating it to stay clear of the programmatic stuff! Sheesh! I won't even begin on the incestuous nature of the HTML "class" attribute and the way that JavaScript and CSS fight for ownership.

The simple truth is, even a passive web page needs some basic interactive navigation features in its markup language and HTML 5 falls short. On the other hand, security demands that both it and CSS rigorously avoid programmatic smarts. The distinction between dumb interaction and smart interaction really needs to be sharpened. Yes, there are three key levels in any web page – structure, content, style and smarts – no, there are four key levels....

One might even try to add a fifth. Some basic smarts are safe and simple enough to be active by default, even if the user wants javascript disabled. These include user interactions such as form-filling, playing media files and simple option processing via the more sophisticated CSS tricks. There are probably a few more. It makes sense to keep these out of the styling language and also out of the main smarts processing. One option would be a kind of intermediate scripting language, between CSS and javascript. But five levels, do we really want all that?

A more user-centric alternative, focused on the HTML changes I am suggesting here, would be to move all the basic CSS style features back into HTML where they originally came from, allowing CSS itself to be repurposed as the intermediate user interactivity language. CSS might now be recast as "Cascading Simple Smarts". I certainly think that's prefereble to YAWSL – Yet Another Web Scripting Layer.

One way to draw the line between HTML and CSS could then be to draw the same line as for printing off a web page. In this process, all the interactions get dropped and only the visible display gets rendered. Keeping HTML for the visible display and CSS for the interactive options would be a very clean way to implement the print API. Certain display interactions such as table sorting and form-filling would need to be implemented in HTML, although the form submit function would be restricted to CSS.

Content re-use

Another of the magical things about Mediawiki, the software behind Wikipedia, is the ability to create arbitrary fragments of information and then to re-use them by embedding them in other web pages. They call it transclusion and so will I. It is such a magical feature that many an editor cannot imagine building such a usable and accessible resource without it.

As soon as I begin to code up a web site, the lack of proper transclusion in HTML 5 becomes painfully obvious.

The old frames were a crude attempt at transclusion of a sort. I use iframes for the site navigation on this blocki, primarily because javascript is not essential, even if its lack does make things clunky.

A similar alternative is available through the <embed> element, which creates a media container. Setting the Mime type as text/html will display a subsidiary web page in the container. But it suffers similar problems to the iframe, lacking any innate ability to resize to fit.

The W3C specification is a bit dense, but it seems to assume that any included HTML content must be a complete web page in its own right. With the XML influence fed in through XHTML, we gained the idea of data islands. This is content which may or may not be HTML but is nevertheless embedded in the web page. But it too must be wrapped around with semantic definitions which make it in effect a complete page.

Wikitext markup is different. You can write a fragment of anything and transclude it into your page very easily. A navbox perhaps, a notice or a fragment of a table, say its header with a row of column headings. And you can add content to your transcluded item, say the message in the notice or the title of the table. The basic code format goes something like this:

   {{transcluded file name|insert1=text to be inserted}}

Which in HTML might be defined for the sake of argument as:

   <transclude complete="off" src="transcluded file name">
      <insert id="1">text to be inserted</insert>
   </transclude>

where the "complete" attribute defines whether the source is to be included unmodified, containerised by closing off any HTML elements left open, or perhaps even topped-and-tailed to form a complete embedded document (In Mediawiki this completion mode is set globally on the server, which can be inflexible).

Actually, my Firefox browser happily renders such document fragments in an iframe, but I don't know whether this is universal among modern browsers, or how complete a fragment must be - for example must any element opening tags in the fragment be closed off in it too, or can that be left to a different fragment? Certainly, it is progress in the right direction.

The Wikitext approach also differs technically from HTML in that the transclusion is done server-side while the embedded HTML, be it in an iframe or embed element, merely links to the extra content so that it must be downloaded separately and the inclusion is then done by the client web browser. This has the effect of making any HTML implementation more limited than Wikitext because by its nature one cannot break the hierarchical nesting of opening and closing element tags once the page has been served, whereas crafty wikitext coding can play all kinds of games to insert, delete or modify tags.

MediaWiki has a further, powerful refinement in that you can treat the transcluded code fragment as a template and pass parameters to it from the main page. For example you can design an infobox template or a warning box and populate it with a list of values or a custom message, saving the need to code the whole display box for each instance of use.

Content re-use isn't a functional thing, it's an authoring and display thing. In fact HTML does make a nod to it with images. You can re-use an image in different pages, merely by linking to it. Imagine having to embed the image file content in every web page it appears in, well, that's where we are now with text re-use! It ought to be right up there in the page authoring language. But it isn't. Gah!

I am being a little unfair to HTML here. The server-side smarts of Wikitext have more in common with a web development language such as PHP or ASP than with the HTML those languages churn out. Nevertheless, without some such functional content re-use, HTML is badly crippled. HTML 5 can only get round it by resorting to JavaScript and programmatic interaction with the Document Object Model (DOM), but there is no reason why the simple get-it-and-diplay-it functionality, even the more basic templating features, could not be written into HTML.

MathML and SVG

HTML is not alone. It can be expressed as a dialect of XML, the original umbrella language invented specifically to enforce a separation of structure, content and style. Other examples which deal with user presentation include MathML and SVG.

The mathematics markup language MathML has the problem of meaning vs. presentation (aka semantics vs. style) in spades. On the one hand the graphic symbols used for a particular mathematical idea vary between national conventions, while on the other hand a given symbol may be used to mean different things in different conventions. For example the decimal point is variously positioned at different heights or replaced by a comma, while the period represents a decimal point in some conventions and a multiplier in others. The separation of semantics and style into different languages proved totally unworkable and so both are explicitly included in one and the same language specification, MathML. The W3C and the viewing agent DOM have just had to learn to live with reality. Sadly, having a solution munged together at the end of a long and agonising journey to a dead end and back, MathML is about as human-readable as C++.

Scalable vector graphics SVG is even more obviously unable to separate "meaning" from style. Its whole job is to present visual objects in styles which convey information, and in a freestyle manner in which the meaning is evident from other visual cues of which the processing engine can have no knowledge. Yet as an XML dialect the mantra of separation survives. Things like positioning, shape and size are deemed semantic but colour and thickness are style. Sure, such an arbitrary division can be enforced and given to a machine to render, but it is not the way people work. And as soon as you bend your SVG image to the way people work you find the mantra to be a horrendous mess. For example sometimes it is the colour which carries the meaning. You need to change the colour of your discs? Well, update the CSS stylesheet. You need to change the size of your discs? Oh, that needs the SVG objects themselves hacking. Yet you are explaining how traffic lights work – the size of the light is just a stylistic convenience to fit the page, while the colour carries the semantic meaning of the light. The language has it back to front on this occasion. No, a meaningful separation of semantics and style is simply not possible in SVG. It is, if anything, even less human-readable than MathML.

Of course, both these languages are baked into the HTML 5 specification: any compliant user agent must be able to render all three. In effect they deliver exactly the inseparable blend of semantics and style that I have been banging on about. And that is a Very Good Thing. But really, what's with the ludicrously broken and unenforcible mantra supposedly underlying all three, huh? The job could, and should, have been done so much more cleanly.

HTML 6

So there you have it. Time and time again the distinctions between structure, content, style and smarts are flouted as if it didn't matter a damn, even where it isn't irretrievably broken, while at the same time it is ritually pronounced as the reason Why Things Must Be Done The Way They Are. What can be done to fix this broken standard that is HTML 5?

Why can't we go back to something more human-centric and start again? This has happened in a minimal kind of way, because although all the old styling attributes have been pulled from HTML creation standards over the years, web browsers still have to cope with ancient legacy code. If I write <table cellpadding=4> today, the browser still has to deal with it properly. The world can still use all the old attributes and break the mantra without breaking the page. And, because they are often more convenient than CSS, we all do already and we will keep right on. Like <i> and <b>, all the rest is not only here to stay, but here for a good reason.

I believe that we should not be trying to pull styling elements and attributes from HTML but actually enhancing the original model with more of them and widening the values they can accept. For example being able to set the cellpadding in em or pt units would be extremely useful. They could also adopt the same cascading approach as CSS, with say the default cellspacing for all tables set in an "html stylesheet" and overridden where a local value is set.

Another fundamental change would be introduced by the idea of layout as a core feature of HTML pages, being neither semantics nor style but a way to deliver both. The status of divs can now be openly understood and the good things about both tables and frames cleaned up.

Transclusion would reinforce the need for a bookmark and other browser navigation aids to record not just url of the page visited but its internal state at the time, a topic I have not dwelt on here because it is not the fault of HTML.

So here's a summary of the changes I propose:

  1. Introduce a user-centric vs. process-centric model to replace the structure-content-style-smarts mantra model. If you must retain the present paradigm for processing purposes, you will need to ensure that there is a defined mapping between it and the user-centric paradigm.
  2. Recognise HTML "layout" elements (such as the div and iframe) as contributing a tacit but flexible semantic and expand the layout capabilities:
    • Re-introduce frames and framesets, as additional layout elements.
    • Extend the url specification to include destination urls of frames, framesets and iframes.
    • Introduce auto-sizing of an iframe to its content.
    • Recast/reinvent the table styling in CSS3 as frame styling. Tell data rendering programmers that they might as well code for HTML attributes as for CSS attributes – being too lazy to is not a user-centric approach.
  3. Flow attribute to be introduced to enable the rendering flow to be specified.
  4. Duplicate more CSS-only features as HTML attributes, for example:
    • Table border styling.
    • Set cellpadding and cellspacing in em or pt units.
    • Drop-down menu lists, for example as an ml element.
  5. Table row sorting on columns to be implemented as an HTML and/or CSS attribute.
  6. Transclude element to be introduced, or if preferred the embed element to be extended, to allow seamless inclusion of text/markup fragments into a page. The ability to pass strings as variables would be extremely useful too, so that the target page can be used as a passive template.
  7. "HTML stylesheets" to be introduced, which set default values for HTML attributes in an HTML-like language, thus duplicating/replacing much of CSS functionality in a syntax familiar to the HTML author.
  8. Active properties to be reshuffled between standards:
    • HTML form elements to be deprecated and their functionality added to CSS, as their interactivity goes beyond mere display or navigation.
    • CSS to be recast as a "Cascading Simple Smarts" user interactivity language.
    • CSS basic styling elements to be deprecated and their function restored to HTML.

But would all this still be HTML 5? "Of course!" cries the acolyte across the room, "HTML has become a living standard and we need never muck about with version numbers again." Oh, get real, put down your Book of Common Prayer for just one moment. This would no longer be your kind of HTML, it would be my kind of HTML. And that makes it HTML 6 whatever your liturgy claims. In fact, it makes it heresy.

Here, have that O'Reilly book back. >WHACK!< Oops, sorry about that. Still, I do think you need it more than I do.

Updated 28 Apr 2018