I think the title (and domain name) are a bit misleading: that's not HTML6, because it doesn't appear to be endorsed by anything related to the web standards (Mozilla, W3C, etc). That's MyHTML, sure, but not really HTML6.
Funnily enough, at a first glance it looked like a real proposal, then I looked again and it appeared as a joke (I mean ... <html:html> and <form:form> are a bit satirical), and then I looked the repo and there's enough issues to think that it is actually real.
> I think the title (and domain name) are a bit misleading: that's not HTML6, because it doesn't appear to be endorsed by anything related to the web standards (Mozilla, W3C, etc). That's MyHTML, sure, but not really HTML6.
HTML5 was exactly that; just a bunch of implementors (WhatWG) until the W3C eventually endorsed it.
I for one was neither mislead by this post nor did I take it as a joke.
I agree with lmm's comment, and clarify a tacit assumption that you're implying: that these ideas are somehow less valid because they aren't associated with a standards body.
It's true you never outright claim that, but you accuse the author first of being misleading, and then of making a joke. In fact this is (clearly) a real, heartfelt attempt to articulate the path one person wants HTML to move in, and I object strongly to any rhetoric that seeks to invalidate this persons views.
The domain is even more misleading: this isn't the 'HTML6 spec', it's one person with little support or peer review (completely unlike whatwg). It's worth flagging the article.
I hate to shit on people's work[1] on HN because everyone else does it but I earnestly think this will get filed in the same bin as XHTML, aka "no web developer actually cares about this so no one will write it and it will die an awkward, forgotten death."
HTML5 did some very important things. Mainly it wrestled back the web from plugins.
Hey, remember Flash?
Isn't that great! That in 2014 I can say "Remember Flash?" Flash had such an insane grip on the web and now it's nearly gone! Not nearly, you might argue, but there are extremely few serious pages left that depend on flash. We've come a huge way since 2009.
It's crazy to think back, honestly. I'm amazed at how the grip of flash has receded. I would not have guessed in 2008 that this was where we'd be. I am a happy web developer.
This just doesn't solve the same scope of problems. It might be useful to some people, just like XHTML, but it's not worth building a new buzzword paradigm over.
[1] Everyone who writes a post like this deserves to be commended. Putting your own opinions out there is hard, so kudos to the author.
I don't think it's shitting on work to criticize this proposal. It has too many flaws to just be nice, smile and go on - it is the direction I don't want HTML to take, and the direction that already failed.
It's missing the lesson of XHTML. Namespaces and XML-correctness failed, what is wanted is easy to write HTML that is readable and rescueable by the browser if it is invalid. Namespaces are a clusterfuck when you just want to get a html-element with a parser, and they make writing code so much more complicated.
Also, the whole idea of elements that have no meaning for the browser misses the niceness of HTML5. Yes, we have now some elements that have only semantic meaning like the header element, but there is at least the option for browser to help with them. It is a standard set to build readable code, not fully customizable XML with no anchor in the browser. Really appreciated are the elements that use the browser, like audio and video, as you mentioned. That is missing here.
Maybe things like the media element are a good idea. Or maybe not, since it does not hurt to be explicit what you are specifying here, a video or an audio file - talking about semantic.
>extremely few serious pages left that depend on flash. //
I'll bet of the pages served the [vast] majority depend on flash for display of content and/or advertising.
On the other hand many _sites_ no longer rely on flash in that they offer an alternative HTML5 implementation. But, of the pages served I'd imagine that version is far less commonly presented to the site visitor. I'm thinking YouTube as an example.
http://httparchive.org/trends.php?s=Top1000&minlabel=Nov+15+... shows that in the Top 1000 (however they're judging that) the instances of flash use are down on average from 52 to 34% over the last 4 years. However the average flash amount of flash transferred and the average number of flash items on a page don't show any downward trend.
HTML5 may have enabled some of that, but I think the thing that actually "wrestled the web back from plugins" is the iPhone, or more generally, the smartphone. Popular devices that people wanted to target, without support for plugins (sure, Android had Flash for a while, as a second-class citizen, but it never had support for arbitrary plug-ins).
Some good ideas here but some terrible ones as well. First, <html:whatever> is terrible. We don't need namespaces in HTML (or in XML for that matter, but that's a different story). <media type="image"> would be sufficient. Even better, something like this:
I do like the idea of not having generic <div>'s everywhere. You can already do this with, for example, Angular. Basically, aside from the pre-defined elements (div, span, input, etc.) I want to just use whatever element I choose myself. I should then be able to style it how I want, and by default it can be, let's say, a borderless, 0 margin, 0 padding, transparent, block element. That way I can use add <wrapper> and style it how I want. Saves keystrokes. This gets me into trouble if later browsers decide to actually support <wrapper> with different semantics than I intended, but I am sure we could work around this somehow without resorting to <html:wrapper> namespacing.
Lastly, I really would love to be able to define element behavior. I want to say that <calendar> is a link, until you click on it, then it opens a calendar, and fires such and such events, etc. Basically, instead of adding a script tag to the base template that defines how $('.calendar') should work, I want to define it globally, a la Angular's directives, then have this happen for the entire site. If the browser allowed me to have finer grained control over user input (exact keystrokes, position of cursor, etc.), I could then re-create <input type="text">! You might say "well, we already have that, the browser does it", but the beauty of doing it yourself is that you can define more complex rules for it than just "type in text". You could, for example, easily define the format of it without having to resort to ugly hacks (think a mm/dd/yyyy type input, or an insurance subscriber ID with a very specific format).
HTML will never be semantic. The whole idea should be scrapped. HTML is inextricably bound to CSS in 2014, and has become more and more about presentation and less and less about data.
Which is fine. We have JSON and XML for data. I would rather see some cohesive standards for JSON data formats, because that is the future. HTML is just the glue between CSS and Ajax requests.
To your point, I would also love to see more improvement in the area of using HTML/CSS/JS as a proper user interface toolkit. For example, Flexbox and CSS Grid Layout are steps in the right direction.
The web browser is a powerful sandboxed VM installed on virtually all Internet connected devices. And yet we a terrible toolkit for building applications on top of this VM (and I know it's because existing tools were built for hyperlinked documents and not proper stateful applications).
Also an interesting interesting topic are the different classes of these Internet applications. On one hand you have applications like Gmail, which are intended to reach a broad audience and should work on most "platforms" (substitute "web browser" for "platform" in this case). But you also have the traditional enterprise LOB application, where you may focus on one or two platforms and make that a "requirement".
I agree that HTML needn't be strictly semantic in the way that the OP suggests. But for the foreseeable future, it does need to encode basic structural data for CSS-less presentation. That includes links, headings, inter-page and intra-page navigation, and the like. Who needs that data? Screen readers, text-only browsers, and scrapers, to name a few.
Someday, it may be possible to do away with the concept of a web "page" or "document." Desktop and mobile apps aren't (generally) built in that paradigm. But if we move away from the document concept, we'll have a new set of problems. How do we represent things like blog posts, which really are more like documents than applications? How do we enable a variety of clients with varying capabilities to consume textual content? How do we maintain the useful concept of a URI, if at all? These may not be unsolvable problems, but they are challenging for sure.
I simply can't imagine anyone wanting to adopt this.
It seems like a lot of effort was put into the concept, and there are some great suggestions, but the added bloat goes against adopting the proposed solution.
"HTML6 is conceptually HTML with XML like namespaces."
Well, there goes backwards compatibility. This sounds like a poor attempt to modularize markup. Web components + shadow DOM have already solved this problem. React solves this problem.
"there is a void that HTML5 has yet to fill and that void is truly semantic markup."
The spec I see here doesn't even satisfy this requirement! It simply adds namespaces to existing elements and changes the syntax for some form elements. For instance:
<html:media src="images/logo.jpg" type="image">
vs.
<img src="images/logo.jpg">
Which is more semantic? Neither. They're identical in every way. Why is it better for the browser to figure out the type rather than using <video> or <audio>? The author makes it seem like this is an advantage, but frankly I can't see it. With HTML5, I get all sorts of methods for controlling media types based on the DOM node. I don't need volume controls on an image. Is it really that hard to decide which tag to use? Your computer can do three things:
* Display something that might move and makes no sound (image)
* Display something that moves and makes sound (video)
* Play sound (audio)
If--as the developer--you have no idea which of these three things your asset is going to do, you've got bigger problems than being burdened by figuring out which tag to use.
IMO, this spec fails to solve a problem that doesn't exist.
This is all already possible with current HTML, except for the namespace stuff (Which is too verbose, and was ditched after the failed XHTML effort, since it never really caught on anyway).
You can already create your own custom HTML tags with the `document.registerElement()` API. And then use all the semantic elements you want. You can even add custom rendering and logic to then via the shadow DOM.
You have to differentiate between the WHATWG and the W3C, which have different goals/purposes and different HTML specs.
As the link you referenced states, the WHATWG's non-versioned living standard attempts to stay "a little ahead of the implementations" with the goal of (hopefully) guiding implementors toward common goals.
The W3C periodically looks at already-implemented features and creates versioned snapshots (like HTML5, HTML5.1, etc.) with the goal of providing developers with a stable, known set of features for development.
Call it XHTML 2.0 or something like that. Calling your experiment HTML6 is a terrible idea.
Terrible because not only it disrupts completely on how HTML matured, but also because there won't be any more HTML versions from now on; HTML is now a living versionless standard.
Sorry, my intention is not to just bash your idea. I personally disliked it because it resembles xml, something that I learned to hate. But that's me.
On the issue tracker (https://github.com/OscarGodson/HTML6/issues/17#issuecomment-...), it's stated that this "HTML6" is meant for developing applications, not marking up documents. Which strikes me as odd, because he is pushing for semantics but is not targetting the one usage of HTML where it would make sense: Documents.
In apps, I care little about semantics. div-soup all the way, why not? Using non-standard attributes? Sure! As long as the browser behaves as an application platform and only my app has to understand the markup, then doing all this is fine [to me].
But for documents, it's a different thing. I want those to be as accessible as possible. This is the place to use semantic markup. I want to use <date> and similar things because I want search engines to understand my document. But "HTML6" is not meant for this?
So... I can see where the author wanted to go with this, but it just doesn't make sense to me.
But it breaks compatibility with what has been HTML since first version, by forcing to prefix existing HTML tags.
Rather, it should propose to enhance the new semantic tags by adding a prefix, for instance <e:calendar>...</e> (or </e:calendar> for readability) while preserving existing tags.
To achieve what the poster wants, wouldn't it be better to
<html>
<body>
<h1> Keep the stuff we already have </h1>
<#calender>
<.calender-header>And just make id and class syntax better?</.calender-header>
<.month>
<.day>1</.day>
</.month>
</.calender>
</body>
</html>
I don't see them removing the way html works, but I could see adding in a way to do classes easier.
Is there anything preventing you from using non-native elements right now? I mean the <html:html> weirdness aside... can't modern browsers just recognize current <weird><tags> and process them as such? Why not just have HTML keywords be hands off for your app and then do your own thing with the element syntax? That's what Angularians are doing.
Some of them already do. I use <p10> as a style tag on some websites and firefox/chrome deal with it fine. The advantage is that old versions of IE don't, so it's a simple browser detection for the user support team. ie. "Is the text in the top-right black or bright green?" "Ok, you need to update your browser..."
This is an old site. Copyright of the site is 2012. The github repo's first commit[1] predates the first commit of Web Components' draft of Custom Elements[2] by a few months.
So, I wouldn't say ignorant but that the Web is catching up to this "spec's" vision.
just feels backwards to me. the <html:* > stuff seems like it should all be under the default html namespace and assumed. where as the other stuff may be better suited to be namespaced.
just seems like a waste adding "html:" to all of the root/core elements.
[+] [-] arcatek|11 years ago|reply
Funnily enough, at a first glance it looked like a real proposal, then I looked again and it appeared as a joke (I mean ... <html:html> and <form:form> are a bit satirical), and then I looked the repo and there's enough issues to think that it is actually real.
[+] [-] lmm|11 years ago|reply
HTML5 was exactly that; just a bunch of implementors (WhatWG) until the W3C eventually endorsed it.
[+] [-] javajosh|11 years ago|reply
I agree with lmm's comment, and clarify a tacit assumption that you're implying: that these ideas are somehow less valid because they aren't associated with a standards body.
It's true you never outright claim that, but you accuse the author first of being misleading, and then of making a joke. In fact this is (clearly) a real, heartfelt attempt to articulate the path one person wants HTML to move in, and I object strongly to any rhetoric that seeks to invalidate this persons views.
[+] [-] nailer|11 years ago|reply
[+] [-] simonsarris|11 years ago|reply
HTML5 did some very important things. Mainly it wrestled back the web from plugins.
Hey, remember Flash?
Isn't that great! That in 2014 I can say "Remember Flash?" Flash had such an insane grip on the web and now it's nearly gone! Not nearly, you might argue, but there are extremely few serious pages left that depend on flash. We've come a huge way since 2009.
It's crazy to think back, honestly. I'm amazed at how the grip of flash has receded. I would not have guessed in 2008 that this was where we'd be. I am a happy web developer.
This just doesn't solve the same scope of problems. It might be useful to some people, just like XHTML, but it's not worth building a new buzzword paradigm over.
[1] Everyone who writes a post like this deserves to be commended. Putting your own opinions out there is hard, so kudos to the author.
[+] [-] onli|11 years ago|reply
It's missing the lesson of XHTML. Namespaces and XML-correctness failed, what is wanted is easy to write HTML that is readable and rescueable by the browser if it is invalid. Namespaces are a clusterfuck when you just want to get a html-element with a parser, and they make writing code so much more complicated.
Also, the whole idea of elements that have no meaning for the browser misses the niceness of HTML5. Yes, we have now some elements that have only semantic meaning like the header element, but there is at least the option for browser to help with them. It is a standard set to build readable code, not fully customizable XML with no anchor in the browser. Really appreciated are the elements that use the browser, like audio and video, as you mentioned. That is missing here.
Maybe things like the media element are a good idea. Or maybe not, since it does not hurt to be explicit what you are specifying here, a video or an audio file - talking about semantic.
[+] [-] pbhjpbhj|11 years ago|reply
I'll bet of the pages served the [vast] majority depend on flash for display of content and/or advertising.
On the other hand many _sites_ no longer rely on flash in that they offer an alternative HTML5 implementation. But, of the pages served I'd imagine that version is far less commonly presented to the site visitor. I'm thinking YouTube as an example.
http://httparchive.org/trends.php?s=Top1000&minlabel=Nov+15+... shows that in the Top 1000 (however they're judging that) the instances of flash use are down on average from 52 to 34% over the last 4 years. However the average flash amount of flash transferred and the average number of flash items on a page don't show any downward trend.
http://trends.builtwith.com/framework/Shockwave-Flash-Embed shows a different story - look at the whole internet version and they show a precipitous drop around April 2014, what caused that?
[+] [-] cwyers|11 years ago|reply
[+] [-] IgorPartola|11 years ago|reply
Lastly, I really would love to be able to define element behavior. I want to say that <calendar> is a link, until you click on it, then it opens a calendar, and fires such and such events, etc. Basically, instead of adding a script tag to the base template that defines how $('.calendar') should work, I want to define it globally, a la Angular's directives, then have this happen for the entire site. If the browser allowed me to have finer grained control over user input (exact keystrokes, position of cursor, etc.), I could then re-create <input type="text">! You might say "well, we already have that, the browser does it", but the beauty of doing it yourself is that you can define more complex rules for it than just "type in text". You could, for example, easily define the format of it without having to resort to ugly hacks (think a mm/dd/yyyy type input, or an insurance subscriber ID with a very specific format).
[+] [-] cletusw|11 years ago|reply
https://www.polymer-project.org/platform/custom-elements.htm...
[+] [-] YoAdrian|11 years ago|reply
http://www.html5rocks.com/en/tutorials/responsive/picture-el...
[+] [-] nicolagreco|11 years ago|reply
[+] [-] ssmoot|11 years ago|reply
[+] [-] xienze|11 years ago|reply
Bzzt, wrong. How would you propose we allow other document types to be embedded in HTML (like SVG)? Just hope the tag names never collide?
[+] [-] debacle|11 years ago|reply
Which is fine. We have JSON and XML for data. I would rather see some cohesive standards for JSON data formats, because that is the future. HTML is just the glue between CSS and Ajax requests.
[+] [-] daigoba66|11 years ago|reply
The web browser is a powerful sandboxed VM installed on virtually all Internet connected devices. And yet we a terrible toolkit for building applications on top of this VM (and I know it's because existing tools were built for hyperlinked documents and not proper stateful applications).
Also an interesting interesting topic are the different classes of these Internet applications. On one hand you have applications like Gmail, which are intended to reach a broad audience and should work on most "platforms" (substitute "web browser" for "platform" in this case). But you also have the traditional enterprise LOB application, where you may focus on one or two platforms and make that a "requirement".
[+] [-] jarrettc|11 years ago|reply
Someday, it may be possible to do away with the concept of a web "page" or "document." Desktop and mobile apps aren't (generally) built in that paradigm. But if we move away from the document concept, we'll have a new set of problems. How do we represent things like blog posts, which really are more like documents than applications? How do we enable a variety of clients with varying capabilities to consume textual content? How do we maintain the useful concept of a URI, if at all? These may not be unsolvable problems, but they are challenging for sure.
[+] [-] scottcanoni|11 years ago|reply
[+] [-] Finster|11 years ago|reply
Aaaaaannnnnndddddd I'm done. Thanks, but no thanks.
[+] [-] dkopi|11 years ago|reply
I simply can't imagine anyone wanting to adopt this. It seems like a lot of effort was put into the concept, and there are some great suggestions, but the added bloat goes against adopting the proposed solution.
[+] [-] sp332|11 years ago|reply
[+] [-] danielsamuels|11 years ago|reply
[+] [-] bastawhiz|11 years ago|reply
* Display something that might move and makes no sound (image)
* Display something that moves and makes sound (video)
* Play sound (audio)
If--as the developer--you have no idea which of these three things your asset is going to do, you've got bigger problems than being burdened by figuring out which tag to use.
IMO, this spec fails to solve a problem that doesn't exist.
[+] [-] TheCoreh|11 years ago|reply
You can already create your own custom HTML tags with the `document.registerElement()` API. And then use all the semantic elements you want. You can even add custom rendering and logic to then via the shadow DOM.
There's a lot of existing elements you can already use: http://customelements.io
Browser support is not 100% there yet, but http://polymer-project.org provides a polyfill that works on IE9+.
[+] [-] untog|11 years ago|reply
Where is my ejector seat?
[+] [-] dutchbrit|11 years ago|reply
What's wrong with just using <head>, <html> and <a> instead of <html:head>, <html:a> etc...?
Bad proposal IMO.
[+] [-] cabirum|11 years ago|reply
[1] https://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standar...
[+] [-] cletusw|11 years ago|reply
As the link you referenced states, the WHATWG's non-versioned living standard attempts to stay "a little ahead of the implementations" with the goal of (hopefully) guiding implementors toward common goals.
The W3C periodically looks at already-implemented features and creates versioned snapshots (like HTML5, HTML5.1, etc.) with the goal of providing developers with a stable, known set of features for development.
Different purposes, different specs, both useful.
[+] [-] jfmercer|11 years ago|reply
[+] [-] talles|11 years ago|reply
Terrible because not only it disrupts completely on how HTML matured, but also because there won't be any more HTML versions from now on; HTML is now a living versionless standard.
Sorry, my intention is not to just bash your idea. I personally disliked it because it resembles xml, something that I learned to hate. But that's me.
But please, don't call it HTML6.
[+] [-] xrstf|11 years ago|reply
In apps, I care little about semantics. div-soup all the way, why not? Using non-standard attributes? Sure! As long as the browser behaves as an application platform and only my app has to understand the markup, then doing all this is fine [to me].
But for documents, it's a different thing. I want those to be as accessible as possible. This is the place to use semantic markup. I want to use <date> and similar things because I want search engines to understand my document. But "HTML6" is not meant for this?
So... I can see where the author wanted to go with this, but it just doesn't make sense to me.
[+] [-] hbbio|11 years ago|reply
But it breaks compatibility with what has been HTML since first version, by forcing to prefix existing HTML tags.
Rather, it should propose to enhance the new semantic tags by adding a prefix, for instance <e:calendar>...</e> (or </e:calendar> for readability) while preserving existing tags.
[+] [-] danschumann|11 years ago|reply
[+] [-] randall|11 years ago|reply
[+] [-] adwf|11 years ago|reply
[+] [-] jpatte|11 years ago|reply
[+] [-] restlessdesign|11 years ago|reply
[+] [-] BrandonSmith|11 years ago|reply
So, I wouldn't say ignorant but that the Web is catching up to this "spec's" vision.
[1] https://github.com/OscarGodson/HTML6/commit/7d58a98b30fe473d... [2] https://github.com/w3c/webcomponents/commit/c60060999073e181...
[+] [-] jayrox|11 years ago|reply
just seems like a waste adding "html:" to all of the root/core elements.
[+] [-] madoublet|11 years ago|reply