Html:YourMakingMoreWorkForUs about html6

[OscarGodson]

If you want to have access to whatever tags you want you have to namespace it. There's no way to distinguish from, say, <img> and <html:img>. How would we know which to display an image and which is your own custom tag? If you didn't want to have to type html: then you could just use HTML5 style and have predefined tags like img.

Also, you shouldn't be writing much HTML ;) Your server should be writing out the HTML and you should be writing tiny HTML snippets.

P.S. I fixed up your post. On GitHub you can do code snippets with three backtickets like:

some code

[zakkates]

Nice. Thanks for fixing up my code. I get it now. Also, I really appreciate your prompt response!

So, 1) You mentioned I could just use HTML5 semantics if I prefer it that way, so 1a) Could I use HTML5 and HTML6 in the same page? and 1b) my assumption would be that HTML6 would become the new standard and HTML5 will become phased out.

2. I have a few solutions. 2a) You could make tags like "img" or "head" or "title" as non-usable tags. OR 2b) what if for custom tags you used:

<div:hereIsMyIdea>
stuff
</div:hereIsMyIdea>

or

<html:hereIsMyIdea>
stuff
</html:hereIsMyIdea>

3rd question: Can you still class or ID things?

<hereIsMyIdea class="a-class" id="an-id">

This makes sense so that you could have a standard format for all but on special pages, maybe one small aspect of the css changes.

thoughts?

thanks!

[OscarGodson]

1a) No, because you wouldn't be able to tell what's HTML5 and what's HTML6. Just like you can't use HTML inside of true XHTML. (doing <br> would cause an XML error).

1b) HTML5 and less would be it's own style, yeah. Like XHTML was phased out, HTML5 would be seen as the "old" way of writing HTML. But like now, you could still write XHTML or even most of HTML3.2 and all of 4.

2a) That'd defeat the purpose of HTML6 where you could use any vanilla HTML you wanted, like XML.

2b) Wouldn't that be equally as much typing, if not more? Now you have to namespace all your custom HTML which would be the majority if your HTML rather than the few header elements and media elements in the body.

3. Yeah, I didn't make that fully clear, but yes you could use those as well as any other tag. The CSS spec, which is different, would look for tags with class or IDs and JS would too with querySelector, getElementsByTagName, etc.

[zakkates]

Thanks!

[zaz]

@OscarGodson, I agree with @zakkates here, and I'm sorry to say that I think your proposal is completely flawed.

You talk about HTML6 being "truly semantic", but semantics is about meaning. Meaning is nothing without understanding, yet you want to move all the tags that are understood by the browser to an html namespace, putting the focus on tags that are not understood.

Essentially, you want to replace tags with classes. Your <calendar> example shows how elegant this is for a human to read, but there is simply no benefit to the browser at all. It's no different from <div class="calendar">. Where "calendar" is just an arbitrary, meaningless string of letters to the browser.

If you wanted to make HTML shorter, doing it the other way around and putting the custom tags under a namespace (e.g. <t:calendar>) would be the way to go (for the sake of backwards compatibility if nothing else). But considering that most pages are served compressed nowdays, I don't think the savings will be notable, and can't see this ever happening.

Very interesting read though, and nice butterfly! :P

[zakkates]

Thanks @jb

My thought is that this should make programming easier for us, not more tedious work. Right? Having to add "html:" to all of my normal tags does not save me time, it's adding work to my development.

zk

[OscarGodson]

@zakkates If adding html: to your HTML is a significant portion of your development time there's something wrong with your app. The amount of HTML you write for an app should be nothing compared to the CSS, JS, and backend code. You can redesign an entire site without ever even touching the HTML. You can omit end tags, quotes, and other pieces now. Do you omit those to save time?

@jb "If you wanted to make HTML shorter" that is absolutely not the point of the spec. If typing is a big problem for you, you should use an editor with autocomplete.

This is also not for the browser. The browser already doesn't care about semantics. In what cases does the browser care about the semantics of a site? It just sees tags. Some are special and it does something with it (makes them clickable, changes the CSS, etc), but it could care less if your HTML is semantic or not. If it did, over half the web would be broken.

This is for the human which as you say is elegant to read, write, and work with in your code and templates and for spiders/bots.

Example: If you're writing a bot and you wanted to look for calendars because you were making a search engine that when you search for some term and it relates to a date you want to look at a bunch of sites and try to find dates. Right now to do this you look for all kinds of crazy stuff like uls and ols containing dates in the lis, for an array of classes jq-calendar, calendar, calendar-wrapper, calendar_wrapper, calendar-container, and so on.

Bots are already trying to find meaning in classes and IDs. Google's has done inline search result nav based on looking up nav, navigation, nav-wrapper, etc. for years. If it's a class, id, tag name or some other bit of text doesn't matter to the bot. If this were implemented there'd be less to look for. Would you ever write <calendar_wrapper>? Probably not. I could say confidently most people would mark a calendar up as <calendar>. But classes people use very differently.

I also want to point out that this is meant for apps. Apps are generally not crawled since they contain user data. Google doesn't crawl your Facebook, email, or calendar. If you were just making a plain site or blog and SEO was crucial to you could just use old HTML if you wanted.

[zakkates]

Hey Oscar! I just checked out "Simple", it rocks!!!!!

I just requested an invite.

Where'd you learn how to develop apps?

[zaz]

Semantics are very important because not all browsers work in the conventional way. Take screen-readers for example, which make use of emphasis <em>, thematic breaks <br> <hr>, and the new <nav> tag, along with many others. HTML is not about displaying stuff on a screen; it's about conveying meaning.

"If this were implemented there'd be less to look for."
That just isn't true. The HTML5 <nav> tag fixes the problem you mentioned, but your proposal reintroduces it. With HTML5, crawlers just have to search for <nav> tags. With HTML6, crawlers have to search for: <nav>, <navigation>, <top-nav>, <bottom-nav>, etc. — and that's only for English websites!

You want the next version of HTML to be nicer for humans to read than browsers, be designed specifically for apps, be meaningless to computers, and completely break all backwards compatibility with the 20-year-old HTML specification?

Do you honestly foresee this becoming an official specification?

[OscarGodson]

@zakkates is the email you used in your GitHub profile the email you requested? i can send you an invite right now if so. If not let me know your email and i'll send you one. I learned on my own when I was ~15ish :)

[zakkates]

yup, same email I used for github.

when you were 15ish... geez, did I miss my calling? haha. I'm 24 now, and I know html and php pretty well. I do primarily front end and minor back-end wordpress development for websites.

[OscarGodson]

@jb

Take screen-readers for example, which make use of emphasis <em>

From people who actually use screen readers, they've told me these tags don't even matter and that most readers ignore them because they're use wrongly and purely for presentation so often.

thematic breaks <br>

Most readers from my understanding ignore this because, again, they're used incorrectly so often for spacing. I couldn't find any links that said this was a default in any screen reader.

Even as you said, "semantics is about meaning". The problem with the tags you give an example for are already garbage by screen readers because they're not used the way they're supposed to. In HTML6 if you used those elements it'd act the same way as it does now.

For your navigation example, screen readers usually look for navigation outside of that element since it's used so infrequently and new. Remember that JAWS (the most widely used screen reading software) for example is like $900 and users of it obviously can't upgrade frequently. Most users are probably on versions that don't even know HTML5 tags. They find links in lists or just a group of links and they also usually have menus of just all the links on the page. In fact, some newer screen readers will guess if you have a group of links with like # or no href that these are JS links and will trigger a click to figure out where they go.

In the perfect world these tags would make sense, but the majority of the web uses them incorrectly and browsers, including screen readers, have needed to get good at finding these things without semantic markup or these people would be SOL when browsing the web.

You want the next version of HTML to be nicer for humans to read than browsers, be designed specifically for apps, be meaningless to computers, and completely break all backwards compatibility with the 20-year-old HTML specification?

As stated above, browsers of all kinds already deal with markup that makes no sense. Basically this adds html: at the beginning of old HTML tags and makes it "official" to use random tags. You can use random tags now and the browser would act the exact same way.

As for breaking backwards compatibility, how would it break backwards compatibility? I'm honestly confused on that. I'm not saying "hey, browsers, delete all your understanding of HTML<=5". I'm saying "If this is HTML6, parse it this way".

Do you honestly foresee this becoming an official specification?

Of course not. Only thing that makes it into these standards is things done by Apple, Google, Mozilla, Microsoft or W3C member himself. It's very rare for anyone outside of those companies to get anything into consideration even.

[zakkates]

BUT @OscarGodson I assume you're trying to get hired by Google or Apple? lol

[OscarGodson]

Ha, no, I'm pretty happy where I'm at now :) I was employed with MSFT briefly after the Yammer acquisition and I'm not a fan of huge companies like that haha.

[philandy]

I agree about those companies. I worked for an IT department before Dell took over.

As far as specs that rocked it but were by the small guy, all we have to look to is MS-DOS and Linux.

About the only thing I would consider changing if this project were mine would be a possible rename to NML (n for namespace) since HTML is so arbitrary (and now even capitalist) on its tags.

[zaz]

HTML5 is still very new to the web, and conformance will improve with time. I thought one of the goals behind HTML6 was to make the web more semantic, but it seems to me like you're actually giving up on semantics?

Your proposal breaks backwards compatibility because HTML6 renderers will not display older versions of HTML at all. Every other version of HTML has kept backwards-compatibility so well that the first webpage still displays fine with HTML5 renderers. Your proposal means that browsers will need two (albeit only slightly different) rendering engines.

If this isn't ever going to become a standard, then what are we trying to achieve here?

[OscarGodson]

it seems to me like you're actually giving up on semantics?

So we're on the same page for the definition:

the meaning of a word

I'm not giving up on it at all. My goal is to take the meaning of tags and let the community as a whole decide on the standards and allow of freedom in the choice. Unspoken standards will form as they always do.

We are all using <ul><li><a> as a way to markup navigation over <menu><a>, but it's not an official standard that you need to use a ul or ol tho. But, also, screen readers find the list of links and assume it's a nav list. Again, this is using a generic ul as a way to mark up a navigation which was never defined in any spec as the way you are supposed to markup a nav.

Your proposal breaks backwards compatibility because HTML6 renderers will not display older versions of HTML at all.

There isn't even a DOCTYPE associated with that page. HTML6 would require one so that it knew to run as HTML6. Just like XHTML.

Your proposal means that browsers will need two (albeit only slightly different) rendering engines

Yes, just like they have for XHTML as well as the real XHTML version. XHTML used a slightly different version of HTML and true XHTML used an XML engine. Not sure why that's much of a problem?

If this isn't ever going to become a standard, then what are we trying to achieve here?

From the site:

Section 6 - Conclusion

This is simply an idea. ...

[zaz]

I would say semantics in this context is the meaning of things to a computer, and unspoken standards have no meaning for computers.

If HTML6 is incompatible with HTML by design then I agree with @philandy; you should rename it NHTML (Namespaced HyperText Markup Language) or something.

To be honest, I think you're wasting your time though.

Sorry, I think we'll just have to agree to disagree.

[OscarGodson]

@jb

To be honest, I think you're wasting your time though

I just write for myself. I enjoy writing and thinking up ideas. I'm not wasting my time by playing with ideas for myself :) this isn't official, not submitted, and as I say in the conclusion it's just an idea I had.

[OscarGodson]

unspoken standards have no meaning for computers.

Is incorrect tho. Written standards have no more meaning than unspoken ones unless they're told to look for certain things. Like my ul example. Thats standard, but a crawler, screen reader, and text browsers "know" those are probably navs.

[OscarGodson]

Last thing, I haven't promoted this at all except when I did it the first time. I don't link to it or anything. I'm not entirely even sure how you guys found this :)

[zakkates]

Keep on writing @OscarGodson! You'll never invent something revolutionary if you don't take risks! I support you

[zakkates]

@OscarGodson - who wouldn't be googling for "HTML6"? lol, duh!

[zaz]

@OscarGodson: Sorry, no harsh feelings. But yeah, it is top of Google for "HTML6" :P How many hits does it get?

[OscarGodson]

@jb ha, yeah, im amazed its even at the top. Doesn't even have html6.com as the domain. Its like 300 uniques a day without any linkage or anything by me haha. And people, surprisingly, return to the site more than I'd expect. 1/4 are return visitors (I dont even view the site more than once a month)

[philandy]

@OscarGodson you've been on more lately (thanks to us probably). I personally agree with this logic, but I feel the need to be part of it, like I feel CSS can be assimilated here partially because of the namespaces.

Whether this is HTML6, ++ or Namespaced (HT?) ML, I think I want my websites in it.

[m93a]

Hi there! I have not read all the comments in this thread but I agree with @philandy - NML is a great name! We can rename the language itself to NML but still call it HTML6 to keep popularity :D - and with @OscarGodson - Custom tags rock!
@jb, to make computers understand our code, we can add a meta tag that describes what custom tags do, eg:

<html:head>
  <html:semantic tag="b,em,i" means="emphasis" />
  <html:semantic tag="title, h1, h2, h3, heading, hgroup" means="header" />
</html:head>

[zaz]

[zakkates]

lol

[m93a]

@jb OK, I was just trying :D

[m93a]

@jb And what about role attribute? They use it in Ubuntu Touch and it's quite practical. For example they mark all a that should be rendered as buttons as data-role=button (that data- prefix is here because the attribute is not a part of HTML5) and style just all elements with the same rule.
So the tag names would say how the elements should treat and role would say what do they mean.
Here's a basic list of roles:

• anch (which is default role of html:anch in my pull request)
• link (which is default role for the actual html:a tag and html:link tag from my pull request)
• nav (the page's main navigation element)
• content (the main content of the page, if no specified, it's html:body)
• side (sidebar, that's what aside tag means)
• article
• header
• list
• dialog (a modal dialog or a prompt)
• em (a highlighted text, that's what b, i, em and apart tags mean)
• button (form:button's default)
• toggle (checkbox and radio from form namespace use this as default)
• opts (selecting from multiple options)

---

EDIT: Sorry, my fault. Correcting "role tag" to "role attribute".

But with HTML6 we're probably breaking what HTML5 was trying to achieve.

[zaz]

@m93a "tag names would say how the elements should treat and role would say what do they mean"

What do you mean? Are you saying that tags should define how an element looks and roles should define their meaning? Surely it should be the other way around? And are you proposing we scrap all of those tags you listed in favour of <div>s with role= attributes?

[OscarGodson]

Yeah, not entirely sure I understand what you mean @m93a by "tags say how the elements should treat", but, the physical appearance of anything non-native should all be done by CSS. In HTML6 there wouldn't be a list of elements you could use so most of your list above wouldn't exist (like article, side, header, etc). However, things like bootstrap and stuff would standardize the way certain elements look. Say, <calendar>. People wont want to style it themselves on each site so they'll use some component library. Let the community figure out standards and common styling and take that away from committees.

[m93a]

HTML5 vs HTML6
IMHO this is the best way to make you understand.
Examples:
<div class=wrap> => <wrap>
<a class=button> => <html:link role=button>
<nav class=sidebar> => <box role=side>
<strong>hi</strong> => <b role=em>hi</b>
<span class=js-button>Click</span> => <click role=button>Click</click>

Tags would be mainly for the styling purposes (instead of the most common uses of class) and browser implemented functionality.

Sample page:

<!doctype html>
<html:html>
 <html:head>
  <html:meta charset=utf-8 />
  <html:title>MyPage</html:title>
  <html:style>
   box {
    display: block;
   }
   [role=side] {
    width: 300px;
    float: left;
   }
   h {
    display: block;
    font: 2 rem;
   }
   list {
    display: block;
    list-style-type: disc;
   }
   list > * {
    display: list-item;
   }
  </html:style>
 </html:head>
 <html:body>
  <box role=content>
   <article role=article>
    <h>MyPage</h>
    Lorem ipsum dolor sit amet et cetera...
   </article>
  </box>
  <box role=side>
   <list>
    <html:link>uno</html:link>
    <html:link>dos</html:link>
    <html:lind>tres</html:link>
   </list>
  </box>
 </html:body>
</html:html>

[ganju001]

If you want to make it more semantic please see W3C semantc web specifications (ex. http://en.wikipedia.org/wiki/Resource_Description_Framework), Try to integrate HTML with it.

IMO web needs to go XHTML to have transformations/querying(XSLT, XQuery) and other benefits that XML has.
Other way is to build web in layers: design semantic page, then build the representational page based on the semantic one. But its more convention than a specificaton + more work to maintain it.

P.S. As for "more wrtting" when using namespaces check http://www.w3schools.com/xml/xml_namespaces.asp

[tchalvak]

Y'all do know that unknown tags are rendered in a standard way in browsers, right? (with the very notable exceptions of the horrible and support-should-be-dropped ie8 and ie7)
http://diveintohtml5.info/semantics.html#unknown-elements

So if you take html5, and you want to create a totally new element, you can, simple as that.
Want a <3d> element? <3d>You have it</3d>
Just do it. It will be styled display:inline by default, but that's easy enough to fix.

And it has complete backwards and forwards compatibility as long as you're willing to provide a css or javascript shim/polyfill for the functionality.

-That- will be the true html6. Finding new purposes that people need simplified into tags, and standardizing them, with new functionality, until we see wide adoption for them. And it's really an untapped potential in html5, too, as the new semantic elements like <article>, <header>, often fail to push the bounds of what's possible. Html6 could easily be that, a compilation of new additions and standards that people need, but never knew they needed, that have full backwards compatibility down to ie9.

Some interesting reading:
http://css-tricks.com/forums/topic/html6-and-css4-my-proposals/
http://www.html5rocks.com/en/tutorials/webcomponents/customelements/
https://www.w3.org/Bugs/Public/buglist.cgi?product=HTML.next

[m93a]

@tchalvak The HTML5Rocks article is really cool! Thanks!
EDIT: document.registerElement doesn't seem to be present in Firefox30.
Web standards are evolving extremely fast - now I realize how hard it is to stay informed.

[aaronlumsden]

My initial thoughts - I'm not a fan and think it just brings unnecessary mark-up into the equation.

[estevaoam]

Whats the benefit of namespacing html tags that way? It just complicates things.

You lost me when you wrote this:

HTML6 is conceptually HTML with XML like namespaces. If you don't know XML, or don't know what XML namespaces are they're basically a way to allow you to use the same tag without it conflicting with a different tag. You've probably actually seen one before in the XHTML DOCTYPE: xmlns:xhtml="http://www.w3.org/1999/xhtml"

XML is a pain in the ass, seriously.
It's difficult to read, unpractical and (most) developers hate dealing with it.

Thanks for the effort of writing this spec, but personally, no thanks.

We need a new syntax, apart from HTML or something else, we're trying to do this for a long time, HAML it's the most successful attempt to do this but it doesn't please me either.

At least, it's worth discussing it, I see this as part of the McDonalds theory.

[zaz]

@estevaoam: You should try SLIM — it compiles faster and has a nicer syntax than HAML. It does away with all those annoying % signs, amongst other things.

[Gigcom73]

PullPeepMo's small files text rich HTML6

[Gigcom73]

html6