That is the rather depressing thing about this. The sorry state of HTML5 is an indictment of the much more sorry state of every other cross-platform GUI toolkit. When you start to break down all of the issues of development, training, deployment, and execution, HTML5 is the better tool. It's by no means a great tool, but what else do we have available?
Saying we should write HTML using the following syntax?:
(div class="red"
(p
(Hello, World!)
)
)
I'm not sure what problem this solves. It eliminates the tiny bit of work that is typing the extra characters in a closing tag, and in doing so you lose all of the other information as to what exactly you're trying to close. The end of most HTML douments would be ))))))) (plus a mess of indenting).
I can see this causing many more problems than it would solve; I'm okay with typing three extra characters to avoid lack of confusion.
The current syntax may not be ideal, but I don't think removing the object type from a closing tab is a good way to make it better.
What is "knowing what you're doing?" I'm honestly curious, because I handwrote most of the HTML on my website and I don't know how to have it cleaner than something like this:
"A p element's end tag may be omitted if the p element is immediately followed by an address, article, aside, blockquote, details, div, dl, fieldset, figcaption, figure, footer, form, h1, h2, h3, h4, h5, h6, header, hgroup, hr, main, menu, nav, ol, p, pre, section, table, or ul, element, or if there is no more content in the parent element and the parent element is an HTML element that is not an a, audio, del, ins, map, noscript, or video element."
practically always except when it obviously makes no sense. If you mean <p>Hello</p><span>World</span>, you obviously can't omit </p>, since the inline <span> would become part of <p>. But why would you write that anyway?
When you omit </p> where you shouldn't, the validator will usually tell you. You do validate your HTML, right?
The fact that the end tags are named means that people are also tempted to write markup like:
<strong> one <em> two </strong> three </em>
This is technically invalid, but some browsers will "helpfully" parse it and apply strength to "one", strength and emphasis to "two" and emphasis to "three". This would be avoided if the closing tag weren't named.
Invalid markup means you are relying on the browser to read your intent or your mind. They are very good at doing that but no self-respecting web developer would ever do such an insane thing as your example.
EDIT: Interesting about the downvotes. It shows a total lack of understanding the fundamentals of how browsers work but, alas, downvote away.
You're being downvoted because of your argument from intimidation ("no self-respecting web developer...") and your wording ("such an insane thing"), not due to a lack of understanding browsers.
No, tell the truth - just don't be a fucking asshole about it. Everything about the way you're talking makes you sound like an aggressive jerk. Even your username screams "I'm an asshole who thinks he knows it all and always has a snarky reply ready". It's OK. We've all been there. Exercise is a good way to get the negativity out.
You are confused. HTML is used to describe the structure of the document, not its visuals. CSS has nothing to do with the HTML content so your complaint about the property/value thing is misplaced and inlining CSS, as you show, is frowned upon.
Then you show the tag/tag thing as if that is a HTML pattern but what you show as your example is just gobbldey-gook nonsense and you claim it's typical.
Certain elements are, or can be made to be, "inline" which gets them treated the same as characters on a line. Thus those elements, such as an image, will have white space between them as a word does in a paragraph. If you butt those element's tags right next to each other, with no white space between them, then there will be no white space on the displayed page.
You absolutely have to split jade documents and use includes/blocks though, any decent sized page, even if it's static becomes unmanageable very quickly.
Complaints such as his, and most of the comments so far below, show a total lack of knowledge of the science and underpinnings behind the whole thing and the only supported proof throughout is silly, invalid examples of markup no one would ever use.
More laughable are the attempts at making HTML look like a programming language, which it is not, and I'd bet that comes as news to many.
http://en.m.wikipedia.org/wiki/Rich_Text_Format from 1987 ish worked this way. Or as another commenter mentioned SGML in it's more compact forms from the same time period and so therefore early HTMLs. Having a closing symbol at all is a pain and I have painful memories from trying to manually find a missing closing bracket in a book length Rtf document. HAML uses significant indention to accomplish the nesting which I find much much easier to read nowadays.
I thought I remember reading this was debated extensively when XML was being ratified. The consensus was that it was better for reading the markup even though it made it harder to write vs SGML's empty end tag.
In any non trivial HTML doc many of the close tags will be far from the start tag, such as <body></body> and looking at a bunch of </> tags and having to go match them up with the correct start tags is more difficult. I run into this all the time with parentheses in your typical programming languages.
The IDE I usually use does auto close tags but also does folding both help with verbose close tags or matching parens so it doesn't matter much what the language does anymore. I generally do think html/xml is more readable because it so verbose including end tags.
The reason this is a problem is not because documents are long, but because HTML does not have a concept of encapsulation. You can't make a subroutine--or rather, subtree--of HTML.
i was actually thinking about this recently. one appeal of json over xml is xml is so wasteful with all those tags. then i thought, why in the world are we still doing web pages in html and not some other json or other syntax? =|
64 comments
[ 2.6 ms ] story [ 118 ms ] thread(div class="red"
)I'm not sure what problem this solves. It eliminates the tiny bit of work that is typing the extra characters in a closing tag, and in doing so you lose all of the other information as to what exactly you're trying to close. The end of most HTML douments would be ))))))) (plus a mess of indenting).
I can see this causing many more problems than it would solve; I'm okay with typing three extra characters to avoid lack of confusion.
The current syntax may not be ideal, but I don't think removing the object type from a closing tab is a good way to make it better.
In practice, where the code is coming from 3 or 4 different levels of templating? Bets are off.
But then, Twig has its own weird issues sometimes with adding whitespace so I've given up caring how templated html works altogether in that case.
http://jade-lang.com
e.g. <p>, <li>, <tr>, <td>.
> But that's just messed up.
Nah, it's pretty straightforward once you wrap your head around it: https://html.spec.whatwg.org/multipage/syntax.html#optional-...
> </>
This reminds me of @annevk's XML5 concept: https://annevankesteren.nl/2007/10/xml5
Quite straightforward indeed.
practically always except when it obviously makes no sense. If you mean <p>Hello</p><span>World</span>, you obviously can't omit </p>, since the inline <span> would become part of <p>. But why would you write that anyway?
When you omit </p> where you shouldn't, the validator will usually tell you. You do validate your HTML, right?
EDIT: Interesting about the downvotes. It shows a total lack of understanding the fundamentals of how browsers work but, alas, downvote away.
Then you show the tag/tag thing as if that is a HTML pattern but what you show as your example is just gobbldey-gook nonsense and you claim it's typical.
I just don't know what to say to you.
Certain elements are, or can be made to be, "inline" which gets them treated the same as characters on a line. Thus those elements, such as an image, will have white space between them as a word does in a paragraph. If you butt those element's tags right next to each other, with no white space between them, then there will be no white space on the displayed page.
[0] jade-lang.com
More laughable are the attempts at making HTML look like a programming language, which it is not, and I'd bet that comes as news to many.
In any non trivial HTML doc many of the close tags will be far from the start tag, such as <body></body> and looking at a bunch of </> tags and having to go match them up with the correct start tags is more difficult. I run into this all the time with parentheses in your typical programming languages.
The IDE I usually use does auto close tags but also does folding both help with verbose close tags or matching parens so it doesn't matter much what the language does anymore. I generally do think html/xml is more readable because it so verbose including end tags.
1. HAML
2. IDE