
HTML6 Concept - Theyeard
http://html6spec.com/
======
arcatek
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.

~~~
lmm
> 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.

~~~
Havvy
Except WHATWG is made of many of the same members as the W3C.

~~~
lucideer
WHATWG is made of a very small subset of the members of W3C. The vast majority
of W3C members are not part of WHATWG.

~~~
nailer
WhatWG are still a lot more diverse than this singular person. 'HTML 6 spec
dot com' is misleading.

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

~~~
onli
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.

------
IgorPartola
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:

    
    
        <media type="image">
            <src href="/foo.png">
            <src href="/foo-2x.png" type="high-definition">
        </media>
    

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

~~~
cletusw
You just gave the _exact_ definition of web components!

[https://www.polymer-project.org/platform/custom-
elements.htm...](https://www.polymer-project.org/platform/custom-
elements.html)

~~~
warfangle
Came here to drop a link to web components ;) imho, empowering devs to define
elements & their behavior is better than defining a standard set of elements &
their behavior.

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

~~~
daigoba66
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".

------
scottcanoni
I am holding out for HTML9.
[http://html9responsiveboilerstrapjs.com/](http://html9responsiveboilerstrapjs.com/)

------
Finster
> HTML6 is conceptually HTML with XML like namespaces.

Aaaaaannnnnndddddd I'm done. Thanks, but no thanks.

------
dkopi
<html:html> <html:head> <html:title></html:title> <html:meta>

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
Like XML, you can just define a default namespace at the beginning, and then
you don't have to repeat it in every tag.

~~~
nailer
The spec itself should define a default namespace, and the examples should use
that namespace.

~~~
nailer
Filed it:
[https://github.com/OscarGodson/HTML6/issues/39](https://github.com/OscarGodson/HTML6/issues/39)

------
bastawhiz

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

    
    
        <html:select type="calendar" name="the_calendar" range="10/10/10-10/10/11">
    

How is that better than

    
    
        <input type="date" min="2010-10-10" max="2011-10-10">
    

in any way shape or form? Hint: it isn't.

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

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

There's a lot of existing elements you can already use:
[http://customelements.io](http://customelements.io)

Browser support is not 100% there yet, but [http://polymer-
project.org](http://polymer-project.org) provides a polyfill that works on
IE9+.

------
untog
_HTML6 is conceptually HTML with XML like namespaces._

Where is my ejector seat?

------
dutchbrit
Having <html:a href="/cats">Cats</a> as a link just looks weird.

What's wrong with just using <head>, <html> and <a> instead of <html:head>,
<html:a> etc...?

Bad proposal IMO.

------
cabirum
Isn't html5 supposed to be a living standard [1], meaning continuous updates
and no html:next spec?

[1]
[https://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standar...](https://wiki.whatwg.org/wiki/FAQ#What_does_.22Living_Standard.22_mean.3F)

~~~
cletusw
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.

Different purposes, different specs, both useful.

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

But please, don't call it _HTML6_.

------
xrstf
On the issue tracker
([https://github.com/OscarGodson/HTML6/issues/17#issuecomment-...](https://github.com/OscarGodson/HTML6/issues/17#issuecomment-21903036)),
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.

------
hbbio
It's an interesting proposal.

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

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

~~~
adwf
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..."

------
jpatte
There's even a typo in the first example:

    
    
      <html:a href="/cats">Cats</a>
      <html:a href="/dogs">Dogs</a>
      <html:a href="/rain">Rain</a>
    

I guess forgetting the namespace in the closing tag will happen A LOT to
everyone.

------
restlessdesign
This makes zero mention of shadow DOM or web components, which strikes me as
somewhat ignorant on the author’s part.

~~~
BrandonSmith
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.

[1]
[https://github.com/OscarGodson/HTML6/commit/7d58a98b30fe473d...](https://github.com/OscarGodson/HTML6/commit/7d58a98b30fe473d5cc8a7ce335632e8ea228e7b)
[2]
[https://github.com/w3c/webcomponents/commit/c60060999073e181...](https://github.com/w3c/webcomponents/commit/c60060999073e181091d316b82fd56c8c9dc6ab7)

~~~
restlessdesign
I stand corrected—thanks!

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

~~~
ape4
If that happened browsers would have to make "html:" optional. So authors
could get away without using it.

~~~
jayrox
and at that point a complete waste of being in the spec to start with.

~~~
xienze
Err, no. XML allows you to set the root namespace for an element so it and
child elements have an assumed namespace.

The point of using namespaces is to allow embedding different document/element
types in the same document.

------
rikacomet
A concept always invites picky comments, but one can be subtle about it. I
agree on few tags, like <logo> , <calender> , <nav> .

but I feel there is still more that is needed. Specially with regards to
<select> and <input> tags. Have you come across how tricky it can be to style
both? Both of these require more simple styling and controls. Also, I would
very much welcome some sort of basic encryption for data submitted by <input>
tags, given that many don't need SSL certificate level of security, but being
totally naked is not okay as well.

------
iraldir
The one good idea here is merely the media tag, which could be useful for CMS
for instance. But that's it. Namespaces are already too much in XML, don't
bring them into HTML, please.

------
amvp
I'm almost disappointed to see a post like this with no comments - because
while it's often quite negative - HN comments often provide me with context
and a counterpoint that's really quite useful.

My first reaction is that I quite like it. It's more semantic than dozens of
nested divs and spans, and perhaps that's not as useful for machine generated
code - for those of us coding html by hand.

~~~
dalke
Is it really more semantic? Consider the first example, starting
"<calendar><month name="January"><day>1</day>...".

It looks reasonable from the start, but then you get into real-world issues:
why do you need to specify the days? What do you do if you want a 10 year
calender? How do you treat February? What are the odds of everyone getting the
calender correct, especially when doing it by hand? How do you specify the
first day of the week? Some countries start the week on a Sunday and others on
a Monday. Can the month name be localized, so that French readers see it as
Janvier while the back-end still knows it's January?

People tried really hard to get semantic namespaces working with XML/XHTML,
but it didn't really seem to pan out.

------
elchief
Is this a joke? Literally the dumbest thing I've seen in years. No one, ever,
is going to namespace every html element.

------
kingkool68
You can already use whatever HTML element you want for CSS and JS hooks. I too
have dreamed of a way to use whatever element you want way back in 2009
[http://www.russellheimlich.com/blog/death-to-the-
div/](http://www.russellheimlich.com/blog/death-to-the-div/)

------
outsidetheparty
I feel like being backwards-incompatible with html5 (while using the same
doctype!) is a tiny bit of a deal-killer.

------
agumonkey
<html:media type...> seems like the wrong path to simplification, namely
redundancy.

    
    
      - The file extension carry the type information (but may be missing)
      - The Content-Type MIME too
      - The actual data stream also (think $ file some-media)
      - And html6 adds an attribute

------
wtetzner
It seems like there's some conflicting messages in this. At first, the author
suggests that getting rid of an attribute and using the tag name is better.
But then they immediately suggest the opposite for <img>, <embed>, <video>,
<audio> etc.

------
vxNsr
So I'm not the least bit familiar with XML, (so ignore me if this doesn't make
sense) but why do we need the <html:*> part of the element?

This seems like a great idea but if it requires all that redundancy (
<html:html> ) I have trouble seeing this used in practice.

------
lvillani
In an hypothetical future, with XHTML now effectively gone and HTML5 becoming
an ever increasing jumbled mess, if I were to _really_ have the chance to
reinvent HTML, I would reimplement it in terms of S-expressions. Easier to
parse and better on the eyes.

------
aaronlumsden
I'm not a fan of this idea at all and I think the title and website are very
misleading.

------
michaelt
I've heard a bit about 'semantic markup' for the web but I don't really
understand it.

I'd love it if someone could tell me, as an example, how semantic markup would
support displaying a syntax-highlighted a block of code in a web page?

------
0x006A
looks a bit like xhtml. whats the point? html is not xml. why would it work
this time?

------
gonzalocasas
Not sure if this is a really bad joke or... Nah, it's gotta be a joke. Right?

------
mahdavi
<html:html> Seriously?

~~~
xienze
It's a namespace that contains HTML elements. Pretty obvious choice for the
name. Presumably there would be "svg:" for SVG.

It seems the author's fatal mistake was not assigning the "html:" URI to the
root namespace since everyone here is so caught up on "HUR DUR HTML:HTML
THAT'S SO DUMB LOL XML SUCKS".

------
jfmercer
The author seems to confuse HTML for XML. Basically, what he wants is XML.

------
RyanMcGreal
I'm confused by the <calendar> example near the top: you can already define
your own elements in HTML5 (and backport it to older browsers via
html5shiv.js).

------
mdumic
I lost you somewhere around XML...

------
bungle
Namespaces in XML was the biggest mistake in XML.

~~~
xienze
Care to elaborate? Pretty much every programming language has the concept of
"packages", "prefixes", or "namespaces" to logically group components,
functions, etc. together. It's only natural to have the same thing in a
document format that can contain heterogeneous document types...

~~~
bungle
Maybe I bring you James Clark (technical lead for XML, among others):
[http://blog.jclark.com/2010/01/xml-
namespaces.html](http://blog.jclark.com/2010/01/xml-namespaces.html)

Namespaces in XML is a foot shooting feature. Sure it has its uses, but still
a misfeature.

------
swalsh
There's only one thing I want in my future web client, and that's to not have
to use javascript. Dart, or compilation in general is not quite the savior i'm
hoping for...

I want to be able to write C#, or Ruby, or python, and reference it on a page,
and for it to run. Gosh that would be great. I wouldn't even mind if its a
very limited version of the language.

Edit: confused why i'm downvoted... hmmm

~~~
talles
Think what kind of nightmare would that be now that web browsers are on
phones, tablets and microwave ovens.

This _salvation_ throws away decades of work of thousands of people that made
our web browsers and our standards. Not to mention throwing away these decades
spenting _getting it right_.

But if you really want to go there, go ahead, there's Java applets, Flash,
Silverlight, Google's NaCl and probably more.

Or, probably better, get out of the browser land and write a freaking _app_.

