HTML5 has changed the Web.
Some parts are good, but mostly it is based on a lack of proper design, and a lack of understanding of how to design notation.
I don't believe that HTML5 can lead the Web to its full potential.
We learn in school what numbers are, and how to add, subtract, multiply and divide.
However, when we get to square roots, we are only told:
The square root of a number n is the number r such that r × r = n.
This is a declarative definition. It tells you what something is, it tells you how to recognise it, but it doesn't tell you how to calculate it.
Most people know what a square root is, few people leave school knowing how to calculate one.
So take a look at the procedural definition of square root:
function f a:
{
x ← a
x' ← (a + 1) ÷ 2
epsilon ← 1.19209290e-07
while abs(x − x') > epsilon × x:
{
x ← x'
x' ← ((a ÷ x') + x') ÷ 2
}
return x'
}
What does it do? Under what conditions?
How does it do it? What is the theory behind it?
Is it correct? Can I prove it?
Under what conditions may I replace it, or a part of it with something else?
| Declarative | Procedural |
| root(n)= r such that r × r = n. | function f a:
{
x ← a
x' ← (a + 1) ÷ 2
epsilon ← 1.19209290e-07
while abs(x − x') > epsilon × x:
{
x ← x'
x' ← ((a ÷ x') + x') ÷ 2
}
return x'
}
|
number: optional sign, digit+ optional sign: "-"? digit: "0"; "1"; "2"; "3"; "4"; "5"; "6"; "7"; "8"; "9". A number has its normal everyday meaning.
This is:
2.4.4 Numbers
2.4.4.1 Signed integers
A string is a valid integer if it consists of one or more ASCII digits, optionally prefixed with a "-" (U+002D) character.
A valid integer without a "-" (U+002D) prefix represents the number that is represented in base ten by that string of digits. A valid integer with a "-" (U+002D) prefix represents the number represented in base ten by the string of digits that follows the U+002D HYPHEN-MINUS, subtracted from zero.
The rules for parsing integers are as given in the following algorithm. When invoked, the steps must be followed in the order given, aborting at the first step that returns a value. This algorithm will return either an integer or an error.
Otherwise, if the character indicated by position (the first character) is a "+" (U+002B) character:
2.4.4.2 Non-negative integers
A string is a valid non-negative integer if it consists of one or more ASCII digits.
A valid non-negative integer represents the number that is represented in base ten by that string of digits.
The rules for parsing non-negative integers are as given in the following algorithm. When invoked, the steps must be followed in the order given, aborting at the first step that returns a value. This algorithm will return either zero, a positive integer, or an error.
So the HTML5 definition of signed numbers is 16 times longer and has internal inconsistencies.
It will not surprise you to learn as a result that the HTML5 spec is very large.
You can tell by reading the HTML5 spec that it was written by programmers.
"When your only tool is a hammer, all your problems look like nails"
And yet, they're programmers and they forgot about how you use libraries in programs? The HTML5 spec is one huge monolithic program.
Declarative methods are not only for specification.
HTML used to be all about being declarative.
The poster-child of HTML declarative markup is the <a> element:
<a href="talk.html" title="..." target="..." class="..." >My Talk</a>
This compactly encapsulates a lot of behaviour including
Doing this in programming would be a lot of work.
CSS is another example of a successful declarative approach.
When W3C started the CSS activity, Netscape, at the time the leading browser, declined to join, saying that they had a better solution, JSSS, based on Javascript.
Instead of
h1 { font-size: 20pt; }
you could use script to say
document.tags.H1.fontSize = "20pt";
"JSSS lacked the various CSS selector features, supporting only simple tag name, class and id selectors. On the other hand, since it is written using a complete programming language, stylesheets can include highly complex dynamic calculations and conditional processing." (Wikipedia)
Which brings us to Javascript.
"Javascript: the Good Parts" contains several texts such as this:
"If the operand [of typeof] is an array or null, then the result is 'object', which is wrong"
and
"The mechanism that Javascript provides to [make a new object] is messy and complex, but it can be significantly simplified"
and
"The best thing about Javascript is its implementation of functions. It got almost everything right. But, as you should expect with Javascript, it didn't get everything right"
So apparently even some of the good parts are bad.
Javascript debugging is hard.
Postel's Law (also known as The Robustness Principle) states
"Be conservative in what you do, be liberal in what you accept from others"
Not everyone thinks this is necessarily a good rule. I don't, and I'm not the only one.
I personally think this principal has had a bad effect on the web, because if thanks to being liberal, browsers accept all sorts of junk, then authors don't know it is wrong, and then they can't easily be conservative in what they produce.
It produces "suck it and see" coding. Once it looks OK in the browser, you stop, thus increasing the amount of junk on the web.
This is bad, because the message you are sending is not the message being received, but you don't know it. It can eat hours of your time trying to find out why your CSS doesn't work, only to discover it's because the browser thinks the HTML is different to what you think it is.
The Robustness Principle was proposed in order to improve interoperability between programs, which has been expressed by one wag as:
"you’ll have to interoperate with the implementations of others with lower standards. Do you really want to deal with those fools? Better to silently fix up their mistakes and move on."
However, for the reasons mentioned earlier, the Robustness Principle should never be applied to programming languages!
Unfortunately it has been to Javascript. Did you know that
Javascript is very hard to debug, since it silently accepts certain classes of errors, that then don't show up until much later.
Studies have shown that 90% of the cost of software come from debugging. Reducing the need for debugging is really important.
Published recently:
"Hello, I’m Mr. Null. My Name Makes Me Invisible to Computers"
by Christopher Null
One of the problems with using programming as the basis of functionality is that standardisation flies out of the window.
Example: CSS presentation mode (which I am using here). This allows you to specify how any document can be formatted when doing a presentation.
Alas, HTML5 has taken the approach that you can do this better in Javascript. No one supports Presentation Mode any more. And there are now lots of Javascript packages to do presentation.
ALL DIFFERENT!
You can no longer switch in a different presentation package, and use that, because you have to CHANGE THE DOCUMENT.
The programmers are doing the document design, so all the documents become proprietary, and there is no interoperability, which is the whole point of standards.
This is why there are so few new elements in HTML5: they haven't done any design, and instead said "if you need anything, you can always do it in Javascript".
And they all have.
And they are all different.
So which framework do you use?
Raw bare-metal Javascript?
Angular? Dojo? Bootstrap? Or one of the other 26 listed on Wikipedia?
Are they compatible? No.
What happens when your chosen package dies, or is no longer supported, or doesn't get updated for the latest version of all browsers? YOU HAVE TO CHANGE ALL YOUR DOCUMENTS.
This is why we need standards, not proprietary formats like frameworks.
document.getElementById('test-table');
dojo.byId('test-table');
$('test-table')
delete Ext.elCache['test-table']; Ext.get('test-table');
$jq('#test-table');
YAHOO.util.Dom.get('test-table');
document.id('test-table');
"Many developers who have grown up only using frameworks have a total lack of understanding about the fundamentals of HTML, such as valid and semantic markup ... This is of great concern as semantic markup is one of the core principles of an accessible web."
Nicole Henninger:
"You know... I feel like I blinked and then all of the sudden what I thought was my job was suddenly not my job but now I'm being told that I need to do this other stuff that I don't even like and people wonder why I'm wielding a stiletto like a weapon and screaming, "I HATE JAVASCRIPT! YOU CAN'T MAKE ME! NO MEANS NO!" and considering a second career in comedy writing."
<div class="dropdown">
<button id="dropdownMenu1" data-toggle="dropdown" aria-haspopup="true" aria-expanded="true">
Dropdown
<span class="carat"?</span>
</button>
<ul class="dropdown-menu" aria-labelledby="dropdownMenu1">
<li><a href="#">Action</a></li>
<li><a href="#">Another</a></li>
<li><a href="#">Something</a></li>
<li><a href="#">Separated</a></li>
</ul>
</div>
And then there are the design techniques they used when they did do some design.
Cows are not designers.
Cowpaths are data.
If you pave cowpaths, you are setting in stone the behaviours caused by the design decisions in the past.
Cowpaths tell you where the cows want to go, not how they want to get there. If they have to take a path round a swamp to get to the meadow, then maybe it would be a better idea to drain the swamp, not pave the path they take round it.
Paving cowpaths is a bad design principle.
The HTML5 group spidered millions of pages, because they could, and then on the basis of that data decided what should be excluded from HTML5.
This is not "paving the cowpaths"! This is putting fences across cowpaths that are used by fewer cows than some other paths.
For instance: @rev.
<link rel="next" href="chap2.html"/> <link rev="prev" href="chap2.html"/>
@rel and @rev are complementary attributes, they are a pair, like +/-, up/down, left/right.
The HTML5 people decided that not enough people were using @rev, and so removed it.
1. This breaks backwards compatibility.
2. What are the people who did use it supposed to do?? Bad luck for them apparently.
For years, the wider community had agreed to use a colon (:) to separate a name from the identification of where it came from. A colon was a legal name character, and it was chosen to be backwards compatible, but in some environments could be interpreted in a certain way.
eg: xml:lang
But no, they had to develop a new separator, the hyphen.
eg:
<div role="searchbox" aria-labelledby="label" aria-placeholder="MM-DD-YYYY">03-14-1879</div>
"The amount of “not invented here” mentality that [pervades] the modern HTML5 spec is odious. Accessibility in HTML5 isn’t being decided by experts. Process, when challenged through W3C guidelines, is defended as being “not like the old ways”, in essence slapping the W3C in the face. Ian’s made it clear he won’t play by the rules. When well-meaning experts carefully announce their opposing positions and desire for some form of closing the gaps, Ian and the inner circle constantly express how they don’t understand." (2009) http://cssquirrel.com/blog/2009/08/03/behold-leviathan-confused/
Many groups had already solved problems that HTML5 could have used, but that HTML5 decided to reinvent (often with worse results, since they were for areas that they were not experts in).
2003: Cross working group task force created of interested parties.
2004: First working draft of RDFa
2008: RDFa Recommendation
So RDFa represented more than 5 years of work and agreement and consensus on how metadata should be represented in HTML and other technologies.
2009: HTML5 creates microdata out of the blue, copied from RDFa but different, and less capable, with no warning, and no discussion or consultation.
FUD ensues.
2013: Microdata abandoned.
How to use HTML to create scholarly articles, using RDFa
If XML did one thing right, it introduced a new notation for empty elements:
<br/>
This one simple change meant that you could parse a document without a DTD or Schema; you could parse any document without knowledge of the elements involved, which made the parser forward-compatible.
HTML5 dropped the requirement of using this notation (probably because of Irritated by Colon Disease), meaning that they can now never add a new empty element without breaking something.
Well, this has always been a problem, but it seems to be getting worse and worse. This is just a page selected at random. There are far worse examples. There is no 'document' anymore.
<div class="row"> <div class="span4 col pull-right bTB1S padTB30">
<div class="padT0 marB10">
<h4 class="franklin-bold size-one-twenty-pc marT0">‘Basically owned the technology in cryptography'</h4>
<div class="franklin-light size-fourteen lh17em">
</div>
</div>
<div class="video-image-wrapper">
<div class="video-container not-lead" class="playing">
<div class="video right-rail-video" style="height: auto; width: auto;" id="wp_69ebfb98-049e-11e5-93f4-f24d4af7f97d" data-show-endscreen="0" data-autoplay="0" data-video-uuid="69ebfb98-049e-11e5-93f4-f24d4af7f97d" data-companion-ad="0">
<div class="innerWrapper" style="width: 100%;"></div>
</div>
</div>
<div class="image-button-wrapper">
<div class="spinner">
<img class="image" data-right="true" data-original="http://www.obfust.com/sf/wp-content/themes/wapo-blogs/inc/imrs.php?src=http://s3.amazonaws.com/posttv-thumbnails-prod/thumbnails/55660d34e4b0ba0b9fd407d8/CROCKER1.jpg&authapi-mob-redir=0" src="http://www.obfust.com/sf/wp-content/themes/wapo-blogs/inc/imrs.php?src=http://s3.amazonaws.com/posttv-thumbnails-prod/thumbnails/55660d34e4b0ba0b9fd407d8/CROCKER1.jpg&w=1080&authapi-mob-redir=0" />
</div>
<div class="imm-video-overlay">
<img data-video-id="wp_69ebfb98-049e-11e5-93f4-f24d4af7f97d" class="wp-loading imm-loading-btn-small" src="http://www.obfust.com/posttv/resources/img/loading_wp_white_100.gif" style="display: none;" alt="loading" />
<div class="imm-video-play-btn imm-video-play-btn-small">
<i class="fa fa-play"></i>
<span class="franklin-bold">Play Video</span>
</div>
</div>
</div>
</div>
<div class="marT10">
<p class="marTB0 light-grey size-fourteen franklin-light">
Steve Crocker, worked on early networking technology for DARPA. </p>>
It was a DOM group.
The old DOM group got closed long ago; it shouldn't have been.
We had this. It has been taken away. It needs to be put back.
We had this. It has been taken away. It needs to be put back.
We will all be 80 one day. We will all need to continue using the web. Accessibility should be in the design from the ground-up. It is not something you can add on later.
The web is the way now that we distribute information. We will need the web pages we create now to be readable in 100 years time, just as we can still read 100-year-old books.
Requiring a webpage to depend on a particular 100-year-old implementation of Javascript is not exactly evidence of future-thinking.
At least declarative markup is easier to keep alive because (see the 5th slide) it is INDEPENDENT OF THE IMPLEMENTATION!
It is time for a new movement, to lead the Web to its full potential.
We should seize back the Declarative Web.
How?
As an example, XForms, a declarative format, is served these days as an XML Document with a prologue that causes it to be converted it to HTML+Javascript.
<?xml-stylesheet href="../xsltforms/xsltforms.xsl" type="text/xsl"?>
So we can still create meaningful declarative documents, and serve them to HTML browsers.
We need to add something that signals that a particular entry is only for implementing the contents, so that if/when it is implemented natively it can be ignored.
We should agree on how to allow namespaces to cooperate across bits of Javascript.
HTML5 can become the assembly language of the web, and we can go back to having a coherent, declarative, user-friendly web.