HTML6
HTML6 copied to clipboard
OscarGodson
HTML-6 looks ugly. Uglier than HTML-5
I personally don't like (In fact I hate) the XML based syntax of HTML.
QML (https://www.youtube.com/watch?v=_6_F6Kpjd-Q, http://qt-project.org/doc/qt-5/qtqml-index.html) for example, a long time ago used to have a XML based syntax as well, however, nowadays QML looks more like jSON and honestly speaking is much more readable. Kivy, a python framework for Mobile Apps (http://kivy.org/#home, http://kivy.org/docs/gettingstarted/rules.html) has followed the same philosophy as QtQuick/QML (http://qt-project.org/doc/qt-5/qtquick-index.html) for the User Interface as well.
I don't know why HTML is still too old school.
I know it is going to be challenging to all of a sudden change the syntax but I reckon it completely worth it. At least for the client side web developers it is going to be heaps easier to read and write the User Interfaces.
// File name = main.html
import main.js
import main.css
from model import nav, slider as nav_model, slider_model
from delegate import nav, slider as nav_delegate, slider_delegate
Html
name: house_keeping
title: "True HTML6++ Sample"
meta.title: "Page Title"
meta.description: "This is an example of HTML6++ with namespaces"
Body
Header
id: page_header
width: 100%; height: 200
Image
id: logo
src: "images/logo.png"
alt: "This is a logo"
Navview
model: nav_model
delegate: nav_delegate
Content
Sliderview
model: slider_model
delegate: slider_delegate
speed: 27
effect: fadein_fadeout
Article
h1: "This is my main article head"
h2: "This is my sub head"
p: "This is a paragraph"
p: "This is a paragraph"
Article
h1: "A cool video!"
h2: "Pay attetion to the media elements"
p: "This is a paragraph"
video
src: "vids/funny-cat.mp4"
autostart: true
controls: standard
p: "Man, that was a stupid cat."
Label
id: footer
text: "This site is © to Oscar Godson 2009"
// File name = model/nav (Fetch it from a database and make it dynamic instead)
ListModel
Item
menu_name: "Cats"
menu_link: "/cats"
active: true
Item
menu_name: "Dogs"
menu_link: "/dogs"
active: false
Item
menu_name: "Rain"
menu_link: "/rain"
active: false
// File name = delegate/nav.html (Delegate describes how each item in the view looks like)
Anchor
text: menu_name
link: menu_link
if active:
class: active
// File name = model/slider (Fetch it from a database and make it dynamic instead)
ListModel
Item
source: "cats.png"
caption: "Funny cats are awesome"
Item
source: "dogs.png"
caption: "Wild dogs are aweful"
Item
source: "rain.png"
caption: "Where is my rain coat?"
// File name = delegate/slider.html (Delegate describes how each item in the view looks like)
Rectangle
class: slider
Image
src: source
alt: caption
Label
text: caption
The point of HTML6 being written in HTML is that it'd be backwards compatible. If you copy and paste HTML6 into a browser you wont see the HTML tags. Even tho <html:a>Foo</html:a> doesn't exist it wouldn't break anything. You would see Foo on the page. However, in your example, you would literally see A text: foo.
My made-up spec is already pushing the syntax compatibility, but yours would completely break it and therefore I don't think any browser vendor would implement it. At least in the next 5 or so years.
P.S. "ugly" is in the eye of the beholder ;) I find:
<html:a>Hi</html:a>
Much easier to read and way more nice to write then:
A
text: "Hi"
Same reason some people love Python syntax over Ruby, or CoffeeScript over JavaScript. If there's one thing I've learned in the programming world, nobody fully agrees on what looks "ugly" syntax wise. Not even in the same languages (thats why there's code style guides) :)
Please do not feed too much McDonalds and Junk foods to HTML because it is already too fat. :)
While designing a product, As a rule of Thumb the Consumers of the product have to be the first priority not the technology.
The only reason I renamed html:a to Anchor is because it looks much more semantic. As you know in programming it is a better practice to write a full word rather than a single character to represent a variable name. It applies to HTML as well.
In my example, you should not literally see A text: foo because we can use a scripting language to handle the Fat Free Markup until the browsers naively support.
How on Earth the second one is more readable than the first one?
<a href="home.html">Home</a>
<html:a href="home.html">Home</html:a>
The 'a' tag itself is not semantic enough. What is 'a'? Apps? Asynchronous? Airplane? This is why I renamed the 'a' tag to Anchor and 'href' attribute to link. Or the following one looks pretty good as well.
Link
source: "home.html"
name: "Home"
We just want HTML to be as Semantic and as Fat Free as technically possible. As a front-end UI designer we should not need to worry about a lot of unnecessary stuffs from the HTML syntax. I have seen a lot of people forgetting to put closing tags in heaps of places and sometimes even closing the tags in a wrong order for example, closing the Parent tag first then closing the child tag underneath. (Particularly in Responsive themes with overwhelmingly crazy amount of nested DIVs).
So as a solution, the closing tags should be removed as well because the indentations are already more than enough (Like in Python) because I suppose modern IDEs are more than smart enough to do code folding nowadays based on indentation alone.
Also I reckon it is much easier to read the attributes as a key: value pair one item in a line.
According to Layman (Ronaldo of Typography) each line should be of about 7 words. I believe It is a far better to write the HTML attributes vertically because our eyes are good on reading a few words in a line vertically rather than heaps of words horizontally.
For example consider the following examples,
<!-- about 15 words in a line -->
<html:input id="some_id" type="text" name="first_name" class="text_box" placeholder="First Name"></html:input>
vs
<input
id = "some_id"
type = "text"
name = "first_name"
class = "text_box"
placeholder = "First name"
>
or even better get rid of the closing tag and the funny looking '<' and '>' characters altogether.
// About 2 words in a line
Input
id: "some_id"
type: "text"
name: "first_name"
class: "text_box"
placeholder: "First Name"
Needs more vertical scrolling but is much more readable.
I have to admit that for a very little advantage (backward compatibility) you are moving in a wrong direction. Most of the people nowadays use HTML for writing Apps. HTML was originally designed for Documents not for User Interfaces. This is why we call Document Object Model not User Interface Object Model.
People have already started doing it. If you don't trust me have a look at this video https://www.youtube.com/watch?v=Ea8Maw4FTw8
this repo https://gitorious.org/qmlweb.
and have a look at ZebraUI (http://www.zebkit.com/) as well because ZebraUI uses Canvas to render the UI components rather than DOM elements.
It is not just HTML, I believe the entire Client side stuffs have to be re engineered. I have used more than 10 languages and from my experience I can tell that it is much easier to write poor Javascript codes compared to Python, Lua, Golang etc as Javascript is way too much dynamic, magically converts datatype and gives "can't find xyz property of undefined" error and doesn't have a good library system.
I would love to see the native implementation of Property and 2 way data binding in the HTML world as well without having to depend upon crazy Javascript hacks, tweaks, frameworks and work arounds.
While designing a product, As a rule of Thumb the Consumers of the product have to be the first priority not the technology.
That is literally why HTML6 is written to be backwards compatible. All your arguments are for developers. If you use a scripting language rendering times will be dramatically slower (esp on mobile which is the number one way people browse now), won't be searchable by Google at all, along with a host of other consumer issues.
If your arguments are not for tech, what advantages do users have with your setup? I can only see you list developer ones.
Developers are the first Consumers of the product not the end users. Seriously, Your approach makes Developers run away from HTML. End users don't care what language and what technology is used at all.
Using scripts will not slow things down. The bottle neck used to be the number of HTTP requests. We sort of get over it using HTML5 history API and Websockets. The next bottle neck is reading through the crazy amount of nested DOM elements (esp the responsive ones) make things heaps heaps slower. Javascript Engines and VMs (V8 engine, DartVM, V4VM etc) are very fast nowadays.
won't be searchable by Google at all
Not really. Search engines are the part of evolution as well. Its certainly not impossible because the contents are still text based. Leaders motivate others to be changed.
I reckon you are an old XML programmer and you are repeating the word html everywhere as a part of XML namespacing rules but seriously speaking the Developers (in other words the first Consumers of your product) love to see as clean and as semantic syntax as possible. Your syntax is way too FAT and Fugly than it needs to be.
Using scripts will not slow things down.
That's for sure not true. I welcome you to try to write your own HTML parsing engine thats as fast, or even sort of similar, to a browsers C parsing code. Not only do you have to parse an entire document in your own format, you then have to convert it to to HTML then, finally, you give it to the browser to render it like it would have done at the start. Go ahead and do a simple web page and run it through JSPerf.
And that's just initial static HTML. You would also need to basically rewrite JS' DOM code and write a transpiler for CSS. None of that would work the same. You would need to also write a transpiler to convert all older JS (like jQuery, etc) to work with your new format. So to recap:
- It has to parse all your YAML style HTML into regular HTML and then drop it into an HTML doc
- You need to rewrite all DOM JS code so it works with your new format (ex:
document.querySelector('Anchor')). - It needs to transpile other, non-YAML style DOM JS libs to your new JS DOM syntax from step 2
- Your JS, on top of all of this, has to now transpile CSS. If you do
Anchor {}it will need to converta {}, and so on.
That would be incredibly slow. I've done things just like this to transpile custom formats for other things. I've been a full time JS engineer for about 5 years and I can promise you those 4 steps above would be slow since it has to do all this on the fly anytime there's a repaint (which is constantly).
I reckon you are an old XML programmer
For sure no. For one, I'm 24 and two I haven't ever used actual XML professionally. I've almost exclusively used JSON. I've used things that look like this such as Haml, YAML and so on. As I said, I really dislike the syntax (and I know plenty of people who despise whitespace significant formats). Nothing against those languages and formats but I'm really not a fan of it.
Yes, for me, characters instead of whitespace is far easier for me to parse and it is for many others. Neither is right or wrong, but you should realize that not everyone thinks YAML syntax is much easier to read then others.
P.S. if you search twitter about significant whitespace you can find plenty of people who dislike it (and like it). Here's a dislike. I'm not sure why you find it hard to believe some might not like the same thing you do? https://twitter.com/nexxylove/status/527630410964946944
@helambuapps The language you propose has nothing to do with HTML. Choose a name for it, write a spec, program a parser, make browser vendors and search engine companies use it and then come back with results.
HTML is pretty Fat already and you want to make it more fat just because you personally love it. You are free to like or dislike anything. Old dogs have right not to learn new tricks as well.
As I said, I really dislike the syntax (and I know plenty of people who despise whitespace significant formats). Nothing against those languages and formats but I'm really not a fan of it.
Yes, for me, characters instead of whitespace is far easier for me to parse and it is for many others. Neither is right or wrong, but you should realize that not everyone thinks YAML syntax is much easier to read then others.
It is only for you and a handful of people like you who are already used to old school style. Not for complete beginners and also not for super genius as well.
If white spaces are less readable than XML then why doesn't Google wrap up all the search results in XML tags?
It is of course pretty difficult to implement YAML sort of syntax from scratch. It will probably not happen anytime soon but if it happens reading and writing client side UI codes will be beez-neez.
Digia has already started experimenting with QML and Chromium. https://blog.qt.digia.com/blog/2013/06/25/experimenting-with-chromium-and-qt/
To me you are just making bad things worse. From a readability prospective your implementation of HTML6 fails.
@helambuapps you should take a look on HAML, it's a YAML-like syntax that generates to HTML. I would also like to see an HTML6 that doesn't use this verbose XML syntax but for backwards compatibility reasons this won't happen in the near future.
@KLINGTdotNET
Thumbs up for HAML cuz it has no closing tags.
From my experience, I have seen a lot of people forgetting to close the HTML tags and sometimes even close them in wrong order (I mean closing the parent tag before closing the child and grand child tags), Particularly on the Responsive HTMLs from Bootstrap, Foundation etc etc.
When I get a chance, I would like to compile and build the experiment Qt/QML based Chromium browser as well.
@OscarGodson Yes indeed Javascript Interpreters and VMs can't match up with the speed of a compiled optimized C/C++, FORTRAN etc but remember the bottle neck is reading, updating and manipulating through the crazy amount of nested HTML DOMs not the scripting language. This is one of the reasons why they want to natively implement the Object.Observe thing in Javascript. Basically speaking, it is much slower to develop in C/C++ because it takes forever to compile, however, C has a plenty of other advantages.
I also don't like the dynamic nature of Scripting languages. Particularly Javascript because it is way too much dynamic and much more vulnerable to run time errors compared to Lua and Python.
This is why a lot of programmers nowadays want to use Golang.
Stop! This is not a forum! What exactly do you want to change about HTML6? (Except of completely rewriting it into YAML-form)
If the answer is nothing (or everything), leave.
nobody fully agrees on what looks "ugly" syntax wise
That's true, but I think most people agree all unnecessary tokens should be removed.
True that, but YAML has nothing to do with it. Maybe default namespace would be a fix.
EDIT: Possible solution? Link to a gist
"That's for sure not true. I welcome you to try to write your own HTML parsing engine thats as fast, or even sort of similar, to a browsers C parsing code. Not only do you have to parse an entire document in your own format, you then have to convert it to to HTML then, finally, you give it to the browser to render it like it would have done at the start. Go ahead and do a simple web page and run it through JSPerf."
ROFL!!! Who the hell wants to re-write a HTML parsing engine for what reason exactly? This makes absolutely ZERO sense.
