Ever since HTML5 has started to gain wider use, many developers have wondered what syntax style should be most prevalent. When coding HTML in XML format, it was easy–because the validator forced you to code in a consistent manner.
Well, since code validation in HTML5 is a bird of another feather, a consistent coding style is going to be extremely unlikely across the web. While an exact coding style across all sites is not really necessary, I think some level of consistency is in order. People’s concerns in this area are valid.
So here are my own personal point-by-point recommendations for clean and consistent markup, and some reasons behind the decisions.
(Calligraphy photo credit: Kriss Szkurlatowski)
Use All Lowercase
We’re used to it, it’s easy to read, and it looks cleaner. I think uppercase markup looks amateurish, and that’s besides the fact that it’s more difficult to type it in uppercase naturally. I think most developers (especially those who are used to XHTML) will agree with this wholeheartedly.
And obviously, when I say “all” lowercase, I don’t mean attribute values, which could be mixed depending on the value. Also, I think it’s fine for the word “doctype” to be in uppercase inside the doctype declaration. So, except in the case of the doctype, don’t use uppercase or mixed-case for your tag names and attributes.
Bad:
<DIV id="main">
<p>content</p>
</DIV>
Good:
<div id="main">
<p>content</p>
</div>
Always Use Quotes on Attribute Values
This one will be more difficult for some to accept in all cases. One of the guiding principles during the creation of HTML has been to eliminate as much unneeded code as possible. If you can eliminate a few extra characters in your page, then this is obviously a good thing. However, in the case of quotation marks around attribute values, I think there is good reason to always include them.
First of all, as in the case of uppercase vs. lowercase, it just looks nicer and less amateurish. But more importantly, there are cases where you have to use quotes. Here are two examples:
<link rel="stylesheet" href="screen.css?v=1.0">
<body class="no-js ie7">
In both cases shown above, you have to use quotation marks around the values. In the first example, it may not be immediately evident, but because of the inclusion of the query string value with the equals sign, you’re required to use quotes around the value of the href attribute. If you don’t, the HTML5 validator will tell you your code has an error. The equals sign makes it look like there’s another attribute listed, so it gets parsed wrong and doesn’t know what to do. With quotation marks, this problem is avoided.
In the second example above, because we’re using multiple classes on one element, separated by spaces, this requires quotes. If the quotes aren’t present, then only the first class will be recognized by a markup parser, and any subsequent classes will look like value-less attributes.
Thus, because of the need for quotes in certain circumstances, I think it’s reasonable to use quotes on all attribute values. This ensures future maintainability of the code (i.e. you can easily add classes or a query string) and keeps the code consistent.
This is bad:
<div id=main>
<p>content</p>
</div>
This is good:
<div id="main">
<p>content</p>
</div>
Don’t Close “Standalone” Tags
Here’s another one that not everyone will agree with, and some might even say it’s not in keeping with the call for consistency.
In my opinion, the purpose of a closing tag is to tell the developer or the HTML parser where the enclosed content ends. Maybe that’s an over-generalization of the actual purpose of the closing tag, and maybe there’s more to it, but I think that’s a pretty safe assumption. I’d be happy to correct this if I’m wrong.
So, if an element cannot have any enclosed content, (which means it’s technically a void element), then there should not be a closing tag or closing slash. Some examples of void elements include <meta>, <img>, <input>, and <source>.
In my opinion, it’s redundant to close an element that isn’t really “open”. So, I suggest we leave off the closing slashes on these “standalone” tags.
Keep in mind that some elements are required to have a closing tag, even though they may not have content. One example is the <script> element. It may or may not have content, but it always requires a closing tag–so it’s not a “void” element. I can’t think of any other tag that falls into this category, but it’s something to keep in mind.
This is okay:
<meta charset="utf-8" />
This is even better:
<meta charset="utf-8">
Close All Elements That Have Content
When validating HTML5 pages, you’ll notice that you could include stray paragraphs without closing them. Thus, the following is a perfectly “valid” HTML5 document:
<!DOCTYPE html>
<html>
<head>
<title>My Page</title>
</head>
<body>
<p>
<p>
<p>
<p>
</body>
</html>
But obviously, “valid” pages don’t necessarily equate to good markup. So I think it’s good practice, and I’m sure many agree, to close all elements that actually contain, or are intended to contain, content. This excludes all void elements, but includes paragraph tags. I’m sure this suggestion is already being followed by most, if not all HTML5 developers.
To be honest, I’m not completely sure why stray paragraphs are allowed in HTML5. This doesn’t seem to be the case for other elements. My guess is that this is related to the desire that HTML5 supports existing content and the fact that many older web documents used paragraphs as breaks, kind of like how we might use <hr> elements today.
This is bad (even though it’s valid HTML5):
Johnny went to the store.
<p>
He wanted to get some gum.
<p>
He had no money, so the clerk threw him out.
This is good:
<p>Johnny went to the store.</p>
<p>He wanted to get some gum.</p>
<p>He had no money, so the clerk threw him out.</p>
Don’t Quote Boolean (or “Standalone”) Attributes
Some might view this as a contradiction of one of the previous suggestions to quote all attributes, but I don’t think it is. To me, selected="selected" is just plain dumb. Or as Jeremy Keith puts it in HTML5 for Web Designers: “This is brought to you by the Department of Redundancy Department.”
Keith doesn’t necessarily disagree; he’s just pointing out that it’s, well, redundant. I think that’s enough reason to never quote these types of attributes (which are technically referred to as Boolean attributes) and always use the single-word syntax. I would also suggest keeping these at the end of the tag’s set of attributes. This makes things cleaner, less cluttered, and easy to maintain.
In dealing with readability of the code, you might even consider writing these value-less attributes using uppercase, but I don’t know if that’s necessary. It’s just an option, I suppose.
This is bad:
<input type="text" required="required">
This is good:
<input type="text" required>
This is a possibility:
<input type="text" REQUIRED>
What’s Your Preferred Style?
Most other HTML syntax issues are universal to all versions of HTML (indenting, proper nesting, etc). With regards to making the transition from XHTML to HTML5, are there any other things you can think of that need a consistent style?
Also I do realize that much of what I’ve said here is merely my own style decisions. But I do think I’ve given good reasons for making these decisions, and other developers could follow these suggestions without any harm to their markup.
Yup, that’s pretty much how I do it. On self closing tags I do use
<meta attribute="value" />however and I also close all elements that can be closed, like in you example I would have closed the 5 empty paragraphs. I think that that really improves readability.One thing you don’t write about, but I’m sure you do, is correct indenting. Too many times is still see work from my predecessors that isn’t correctly indented.
i m quiet a lazy one i ll ignore all the time consuming things like end tags ,attribute values ,quotations .html5 is made for me. There is also another article which you can go through for knowing syntax and rules it’s a really good one for beginners:
http://techtutorz.blogspot.in/2014/04/understanding-html5-tags-attributes.html
i’m not totally sure about this point “Don’t Close “Standalone Tags”, since the X from the XHTML comes from XML, and XML rules says that every tag should be closed, XHTML should respect that rule too. IMHO, every tag, no matter if it’s a standalone, should be closed, it also helps editor (such as notepad ++, which i use for html & xml) highlight and find tags closures.
But is just my opinion, i’ll keep closing standalone tags hehe.
Nice article btw.
Regards from Argentina
Keep in mind that I’m not talking about XHTML here, but HTML5, which is not subject to the strict formatting of XHTML.
Sure, but it takes very little effort to write your HTML5 so that it’s still readable by an XML parser, and you never know when you might want to do so… or when somebody else might want to do so for that matter.
Not that it’s such a big deal to parse HTML anyway, but still :)
I’ve read 2 different books on HTML5, and I’ve started reading a 3rd one, and not one of them recommends that you use strict XML syntax just in case you need your HTML5 to be parsed as XML.
HTML5 was designed in such a way so as to remove the strict parsing rules of XML. Those syntax rules were counter-productive, so there is no reason to stick to them.
Don’t get me wrong; I do see your point, but I don’t think it’s as likely to be needed as you seem to suggest. Taking a “just in case” attitude will be almost as counter-productive as going back to XHTML.
Using this line of reasoning, we could reason that we ought not take a “just in case” position with regards to accessibility. “Just in case” the user doesn’t have Javascript enabled. “Just in case” the agent doesn’t support certain methods. “Just in case” the user is on a small screen. etcetera. Taking your anti-“Just in case” position seriously can lead to some pretty poor practices and marginalizing of users.
Also, HTML5 specification allows for the application/xhtml+xml and application/xml MIME types. Because of this, I think it’s much more appropriate to at least close all tags.
Craig, you’re comparing HTML5 as XHTML to accessibility. That’s a very inappropriate comparison.
With regards to accessibility: Acessibility is a goal, not a means to an end. In the case of HTML5, XHTML-syntax is just one means to the end; and it’s not a necessary means. So it’s perfectly fine to use a simpler, stripped-down syntax.
And yes, HTML5 does allow pages to be served as xml, but if someone chooses that method, then that is ultimately their goal; not their means. That is, they’re doing it for a reason.
But in general, you don’t have to serve HTML5 pages in XHTML syntax. If that was a requirement, or even best practice, then you’d hear a lot more standards proponents talking about it. Unless I see more evidence to support your view that’s it’s necessary, I’m afraid I can’t accept what you’re saying.
Why are people still talking about XHTML..?
If you want to take a ‘just in case’ position for XML parsing then surely its better to code in XHTML from the outset.
If helps your text editor highlighting then I’m sure its fine to use for that, but that’s something specific to you, the web author, rather than a more general approach to coding discussed here.
I have to say I agree 100% with these syntax styles. It just makes sense to do it that way. The code will be easier to read and maintain.
A more cosmetic type of choice (admittedly probably über-irrelevant) that always fables the consistency-freak in me:
What’s your newlines/carriage return approach? I.e. the number of carriage returns after each tag: one, or two carriage returns after each tag — or a random mix of one or two depending on what ‘feels right’?
Second though: when would (and wouldn’t) you keep nested tags on the same line?
I guess this comes down to personal choice, but for me at least, this tend to affect the readability as well. If someone can suggest a logical rationale and a working set of rules, I’d be curious to hear it.
What you’ve brought up is actually a related but quite different topic. My post is specifically about HTML5, whereas your applies to any kind of web markup.
But to be honest, I have been thinking about certain style issues with regards to HTML in general, related to the stuff you discuss, so I might post something on that later on.
I, personally use one carriage return between tags, except for when I start a new logical section, where I use two.
I keep nested tags on the same line when it is inline content and break the line between block content.
I agree on all fronts except I’ve been using checked=”checked” (although yes, it is redundant and I wish they had a better way of doing this, I feel AWKWARD just having the word checked in there! It feels so dirty!)
But I fully agree on <br> is better than <br />, I agree about lowercase, I agree about closing all tags with parsed content, and I agree about putting attributes in quotes.
Great article :) (although I am obviously biased, since I agree with you :P )
@Rose, yes I agree it does feel dirty! But I think I personally will start doing it. Other than that, I will be using XHTML strict markup simply because I’m used to it (nested and tabbed of course)
I agree with all but the closing tag. It was invented for the purpose of readability, and it is how many former XHTML coders do things. Either way is not good or bad, yet I think it does increase readability, particularly to newcomers.
I’m doubtfull about the boolean attributes too. It does look kind of redundant in the XHTML way, yet that is how many coders learned it and how many IDEs will generate it, if applicable.
In general, I think we should stick to good, well known conventions, even though we are no longer strictly enforced (we never were really).
I prefer to quote boolean attribute because of some bugs and inconsistencies between browsers and jQuery.
With Firefox 3.6 a code like
$(":input").filter("[required]")would select an input tag with
required="required"but notrequirednorrequired=""That’s actually a very good point. I might add a note to the article. Thanks.
I also prefer to quote boolean attribute values but it was from more of a style perspective than processing perspective. Thanks for providing the JQuery example — it makes a strong case for using quoted boolean attribute values.
I too agree with having values inside the quotes for boolean attribute.
I always quote booleans for the reasons above. I get your point about redundancy, but really that stems from the fact that they’re only pseudo-boolean. True boolean values come in twos: 0/1, False/True, etc. HTML’s implementation provides no false value, only a true value. If the following code was valid it would not be redundant.
<input type="checkbox" checked="false">still like the rule for xhtml
Never use a value and the intent is always clear.
Boolean attributes should never have a value, precisely because it leads to confusion for anyone not 100% familiar with the rules e.g. <input type=”checkbox” checked=””> is checked which is confusing, or <input type=”checkbox” checked=”0″> is checked which is also confusing.
As a software-developer/systemarchitect, I can only recommend that you keep the closing /> on meta etc. because the parsing of the pages becomes much more easy.
I like to think of HTML-tags like brackets. You need one to open and one to close something.
In your example, if SOMEONE decides to put a </meta> later on your page – lets say in a comment field in a blog, then the whole page would be included in head and nothing shown.
I like the new HTML5, and yes XHTML was strict. But also away to try to clean up the mess from bad HTML formatting.
The less fuss there is about how the code/formatting is structured, the less errors we see in cross-browser development cycle.
Regarding indention. Seriously, any automated system for big sites will try to zip/squeeze the last few remains of “tabs” and “spaces” out, so no, do what do want in HTML markup, but accept that spaces are removed as needed when going live in big systems.
Its only geeks who looks at the prettyness behind the site, not the customers, they just want a website that provides valid information.
Dont take me wrong, I do use indetion myself, when doing a new template, but once we go into CMS we cut and paste and then its all about the results. You dont get an extra paycheck bonus for pretty html, sorry to tell you. But do feel free to do it in your coffee break.
I do not believe that is correct. I did a quick test, and throwing a stray closing meta tag later in the page does not affect the layout of the page. Not to mention that any decent commenting system would escape those kinds of characters anyhow. Interestingly, the fact that I had to correct your comment to include the reference to the closing meta tag somewhat illustrates my point. :)
The point of using the simpler syntax is to mimic what browsers have been doing all along—which basically means that you don’t need a closing slash on void elements like meta tags.
I like to put spaces between = and “. When reading through a lot of code, I find that the added spaces help me to read faster. ie: img src = “/images/juicebox.jpg” rather than img src=”/images/juicebox.jpg”.
I think these are very common syntax styles, 2-3 points only related to HTML5…
My advise is use XHTML5. Suffix your webpage with .xhtml.
There is nothing wrong with following the XML rules.
Benefits are:
it’s XML, you can load parts from other ones webpages, transform it into what ever you want, load that transformed part into your page. Without an XML structure you can’t use XSLT.(you can’t transform).
I use XSLT to generate my websites. When standards changes, when my customer demands an other output format, i am not in panic. The only thing that i have tot do is reconsider the transformation.
For the same money we transform content to E-pub, XSL:FO (pdf), XHTML5, XHTML1.1, WML or what ever.
Second benefit: Browsers interpretation is predictable. When your structure is broken, a browser interprets it and tries to solve it. Using javascript you can dive into deep troubles when that interpretation differs from your point of view. XHTML pages get’s a warning and does not show when the structure is broken. Saves a lot of time when you are searching for a needle in the haystack.
But what do you do about the fact that Internet Explorer up to version 8 cannot serve real XHTML pages?
Keep in mind that, although we have used XHTML-based markup for web pages for years, in reality those pages were not really “XHTML”, but rather they were HTML pages, using XML-based syntax rules. They were never true XHTML pages.
What you’re suggesting will only be possible for a real world project that has virtually no visitors viewing the pages with IE6-8, which is pretty much impossible.
See this page for a support chart: http://caniuse.com/#agents=desktop&cats=Other
– “They were never true XHTML pages.”
If you were serving them with appropriate headers (application/xml+xhtml), yes they were true XHTML, at least on compliant browsers. The problem is most people don’t have a clue what that means.
– “But what do you do about the fact that Internet Explorer up to version 8 cannot serve real XHTML pages?”
Nothing. They will work just as good, while still having the machine parsing advantage. And there is nothing wrong with serving XHTML markup as text/html for every browser now, since it’s 100% valid. There is no downside to it.
No, as far as I understand it, if you serve a page as “application/xhtml+xml” to IE6-8, it will try to download the file, rather than render it as a web page..
That’s my point:
http://www.w3.org/TR/REC-xml/#dt-empty
Well I do agree with most of your propositions.
For the boolean attributes (seletecte=”selected”), I remember that in HTML4, this didn’t exist. It was introduced by XHTML, to match with XML constraints, so returning to the previous markup isn’t a mistake.
XML has make a lot of noise at one point and HTML, that was also trendy by the WWW moved in its direction and became XHTML. Was it an error? I don’t think so as it helped to formalize and standardize the markup but HTML is not XML and HTML5 is not XHTML so I think most of the comments disagreeing with your propositions are off topic.
If you code in HTML5, any XML parser has nothing to do on it ! Use an HTML5 parser that could translate the code into XML but don’t ask HTML5 to be XML compliant as it’s not hits purpose!
And for the funny part of it, be careful XML-evangelists, JSON is coming and will eat you ;-)
Besides Don’t Close “Standalone” Tags, wich i’m not sure that is html5 correct, need to search a little deeper, but i like all the other syntax style, that i use since… long long time :)
I don’t know that I’d would label any of these things as “bad” per se. One of the nicer features of HTML 5 is the flexibility of the syntax in that it allows you the freedom to code however you’re comfortable.
That being said, I do, personally, agree with the tighter standardization you’re talking about, and when looking at someone else’s code it’s always nice to see familiar methodologies, but I think the most important thing in consistency.
We’re pretty much simpatico, Louis.
>>> So, except in the case of the doctype, don’t use uppercase or mixed-case for your tag names and attributes.
I agree with you, and this is what I doo, but is this really a principle or just a personal preference? We’re used to lower-case tag names and uppercase ‘
DOCTYPE‘ at this point — but is there any other reason other than our habit, and our historical association of uppercase tags with amateurs (even though HTML5 says it’s fine? Are we just celebrating/enforcing what we’re most comfortable with as somehow superior?On self closing tags how do you guys approach the img tag? I get the whole why close what you do not really open. Maybe its my experience of XML but I do prefer the
/>syntaxMy thoughts exactly. I understand the other side though, is that you would only “close” something that had the ability to contain content. Perhaps I am thinking about this too philosophically, but I feel a void element is the content in and of itself, like an
would be and thus would require a self close.But, with that said and it is my preference also, it is an XML practice and I can adjust my technique appropriately. I suppose it could be construed as closing the door to the room with no walls in the first place? :)
Well I screwed the pooch on that post. That’s what I get for listening to Pandora while posting!
BTW, I was referring to an IMG being the content in and of itself.
All lowercase – agree
Always Use Quotes on Attribute Values – agree
Don’t Close “Standalone” Tags – agree
Close All Elements That Have Content – agree
Don’t Quote Boolean (or “Standalone”) Attributes – agree
Yep – with you 100% ;)
Thanks for the link to this Russ (and the links for light reading every week – awesome for slacka*ses like me)
I’m at 80% … not closing the standalone tag just feels wrong somehow, like a little voice keeps asking “but what comes next … you left it open … something will get in there” … etc.
Each to their own obviously! (and nice to know there are others with similar views as part of the discussion) – great article.
It took me a while, but after a couple of years of intense HTML5 use I’ve reached the exact same conclusions as you!
At first I did close standalone tags, for example, but after a few months I realized that it really was totally useless. It was just XHTML in the back of our minds, refusing to die.
Good thoughts. The one thing I would have to disagree with is not closing standalone tags. Yes, it makes for valid HTML5, but I think standalone tags should be closed for the sake of readability. When most developers see
<p>They are going to asume that there is a closing
</p>somewhere in the code. On the other hand, if you use
<p />then it’s safe to assume that the tag isn’t going to be closed somewhere else on the page. In my opinion, just because HTML5 is more forgiving, it still doesn’t mean that we should abandon the helpful parts of oldschool XHTML.
Not closing tags seems dangerous and not explicit enough. You’re relying on all browsers to use the same logic to understand when to close a tag. Also look at this example:
<ul>
<li>foo
<ul>
<li>bar
Does that give you a nested list or two lists?
Sean,
Keep in mind that we’re not living in the days of the browser wars. The browser makers no longer do what they want in modern implementations. The spec now not only defines how correct code should be handled, but it also defines how errors should be handled. See this section of the HTML design principles page, and in particular the part called “Handle Errors”.
Oh and if you are using <p /> in your code that makes me a sad panda.
I also agree that you should close standalone tags, and this is the best reason why. A lot of us learned HTML by looking at other HTML, and consistency here is helpful to the reader. If you don’t see a /> on the end, then you know to expect a closing tag further on.
On uppercase v. lowercase DOCTYPE and self closing tags….
Remember most of our readers are not using HTML5 browsers and we are taking advantage of the fact that non IE browsers style unknown elements and we have to trick the IE”s to believing they know about the new elements. At the end of the day, most of our people are in browsers that are happy XHTML browsers and are randomly behaved with loose HTML.
So until most people have real HTML5 browsers, I’d keep the <!DOCTYPE html$gt; all upper case, and I’d still close my meta, img and br tags (though we shouldn’t be using br tags anyway)
nice post, I agree with most of your style.
btw, the answer to “I can’t think of any other tag that falls into this category” is in the post’s title –
<style>. The reason is after you open a style/script tag the browsers expects CSS/JS code and then a closing tag.Another thing I’ve learned just today – Not closing your self-closing tags means they’re not compatible with XPATH, which makes sense as it’s XML based. I’m not talking about validation here, I’m talking about debugging and a few semantic-web or opengraph-like services which could benefit from parsing XPATH. I think I’ll keep those slashes on meta & link tags.
Well, maybe I didn’t phrase that question properly. The
<script>tag requires a closing tag, even though it will often occur with nothing in between the tags. The<style>tag is not like that, because it will never be put on a page unless it has content.I suppose a
<video>element with no fallback and no “source” tags might qualify. Or even<textarea>. Both those elements require a closing tag, even though they don’t always have content in between the opening and closing tags.I really couldn’t disagree more. XML formatting is no longer “required,” but that doesn’t mean we should stop using it. There are huge advantages to proper XML formatting. Google and the validators won’t care if your content is not strictly formatted, but a smaller shop’s PHP script that’s syndicating content across the web will probably overlook your content because of poor HTML choices.
There is so much benefit for so little effort in XML formatting rules…I simply don’t see the value in using any other method.
In the example you’re discussing, it would be best if the content was actually produced in XML. The shop’s PHP script should be accessing the XML feed directly, if that is its intent. The page itself (built in HTML5 and PHP) could also build its page based on the contents of the XML feed.
So, although I see your point, I don’t think it’s a necessity. In fact, part of the reason for the creation of some of the new semantic elements in HTML5 is to improve portability and the ability to syndicate content.
I agree — XML format is preferable for machine-readable content, but the reality is that content is consumed in many different ways. Content should be published in both XML and in XHTML — why create a readable format and a non-readable format when you can have two completely transparent formats simultaneously?
I guess my question is this: what is the BENEFIT of shorthand formatting? Is it simply to save time spent typing the slash and ensuring that your document has properly closed tags? If that’s the case, I’m not convinced. XHTML offers tangible benefits for minimum effort.
It’s both sad and funny that posts like these are still needed in 2011. Apart from some good pointers, it’s also a post that indicates that finding best practices that work for everyone, even on the most basic level, is virtually impossible in our little front-end world.
To be a bit more concrete, I don’t agree with the self-closing tags part (I’d close them, definitely now that html is a living spec and nothing tells you any of these tags won’t accept content in the future) and the boolean part (just for consistency).
I understand there’s no right or wrong here (probably why you should rename your “this is bad” examples), it just goes to show that we still have a long way to go to grow as a profession :)
Thanks for your thoughts, Niels.
I have to admit, I find some of those commenting on the need to self-close tags, and/or stick to strict XML-style rules seem to be doing so because of fear of what may or may not change in the future.
To those people I say: Remember HTML design principle 2.1: Support Existing Content. Unless the entire interwebs is revamped and all previous content is destroyed, I don’t think the concerns people are raising are valid. You said “nothing tells you any of these tags won’t accept content in the future”, but that’s not really true; HTML’s design principles tell me that.
Of course, there really are no guarantees in anything. But if we have to start from scratch with web content, then I guess we’ll deal with that when it comes.
Hmm, not sure I understand what you mean by “html’s design principles tell me that”. Extending a tag to accept content doesn’t seem to break any existing stuff. Imagine a rework of the image tag like this:
<[img alt="">
<res value="hi-res" src="..." />
<res value="lo-res" src="..." />
</img]
Like this you could list multiple sources for different resolutions (for whatever reason). Such an extension is not unthinkable and wouldn’t break _any_ declaration currently used on the web. But one could add content in between the tags and so all of a sudden the closing tag becomes relevant. Why not make sure you’re not ever going to run into this kind of situation? Is it really that much trouble to include the / on all self-closing elements?
Niels, you said:
That’s not really true (at least not from what I can see). According to your initial argument (and the argument of a few others in this thread), any image elements that don’t have the closing slash would essentially be ‘broken’, because the new rendering engines would be looking in vain for a closing tag, and causing the rest of the page to get all wonky.
You argue here that it should be possible to add a closing tag to the
imgelement, but in your example you used square brackets in an unconventional way. I’m not sure why you did that. If such a new element used a completely different syntax (as you propose here), then obviously that would have no effect on existing tags. So I guess I have no problem with that.But I also don’t see any reason why any existing img elements would have to have a closing slash, as you seem to imply…? When the parser sees “<img” it will not look for a closing slash/tag; but when it sees “<[img” it will.
So, again, there’s no reason to include a closing slash on any img elements. Not to mention the billions of img elements that already exist on the web that cannot possibly be closed by anyone. Those have to be supported. If the img element is changed, those existing tags will be broken. HTML’s design principles ensure that this will not happen.
“So, again, there’s no reason to include a closing slash on any img elements. Not to mention the billions of img elements that already exist on the web that cannot possibly be closed by anyone.”
I agree here. I think XML formatting has a sense of security that HTML5 strips down and yeah, thats a bit unnerving.
I also disagree with not closing the “standalone” tags, but for a different reason.
Its mostly about readability and convenience for me, when you have some values in such tag, self-closing it is a clear visual indicator that the tag content is complete, there is nothing missing you forgot to type in. It actually holds true for any kind of tag – if it is left “open”, even when doing so is “legal”, you don’t know if its content is all there. That might not be problem while first creating the code, but when you come back to it after months or even years, you start wondering…
As far as I’m concerned, I prefer use the XHTML syntax for HTML5 : so I’m able to re-use the website code without changing all the code.
Anyway, on my personal website, I was used to serve it as application/xhtml+xml, and I don’t see a reason to stop this, even it is now using HTML5 features, as video, nav, etc.
I am not so sure about the “Don’t quote boolean attributes”. An attribute should always equal something, otherwise it shouldn’t be an attribute. But I admit that checked=”checked” is weird since the attribute equals itself. Does checked=”true” work? Required=”true” work? Anyways… html5, with its all new cool features, doesn’t purge every single weirdness in the html markup.
There’s no rule that says that an attribute needs to have a value. In fact, if anything, the opposite would be true. Take the word “attribute” in a generic sense, and such attributes can stand alone without values.
And to answer your question: No, in order to use the new
requiredattribute, you have to either dorequired="required"or justrequiredon its own. If you give it a random value, it won’t validate. I’m not sure if it will work or not, but it definitely gives a validation error.I still like the same rules that was applied to xhtml …
Like close the img and meta tags with the ending /
The only new thing I am going to do is to ignore “Standalone” attributes
It makes more sense.
I vote for closing standalone tags, too. Makes life easier for the parser and improves readability.
Here’s my stance on self-closing tags:
It’s not a matter of efficiency, neatness, or validation. It’s one of simplicity. Saying, “All tags must be closed,” whether to a beginner or professional, is preferable to saying, “All tags must be closed, except this one. Oh, yeah. This one too. And this one.” Particularly with the addition of all these newfangled tags in HTML5, it’s important to optimize our code for readability. Don’t assume everyone looking at your code knows every tag you use without consulting a reference. Self-closing your tags means people reading your code know, without a doubt, the tag wasn’t accidentally left open. It’s not so much about writing code as reading it.
Self-closing tags are a necessity in xhtml due to XML-like syntax. But there’s absolutely NO need for them in html. In fact, it’s not correct if you follow HTML syntax rules. Yes, your code will still be valid if you use it, but it’s NOT correct. And I don’t see how self-closing tags improve readability of the code.
“Keep in mind that I’m not talking about XHTML here, but HTML5, which is not subject to the strict formatting of XHTML.”
There is no HTML5 -there’s only HTML and OTHER Markup Languages
The coments here are a rough definition of the sentence: a bunch of confused amateurs and charlatans.
HTML is not XML
just dig it!
“Use All Lowercase”
Not in HTML, Of course NOT!
“I think most developers (especially those who are used to XHTML) will agree with this wholeheartedly.”
Let them use their bloody xhtml than -stay away from HTML. Its that simple…
“Don’t Quote Boolean (or “Standalone”) Attributes”
There are no boolean or standalone attributes they are properties.
DISABLED is a property. Meaning:
-if present -than there it is!
-If not, than it doesn’t have it!
Clear?
For example should and can recieve an attribute for scripting purposes ..: MyButton.disabled=0 //meaning false that is: enabled, or MyButton.disabled=1; //meaning true, that is: disabled
But a charlatan with attidtude and full of opinions may try stating…:
MyButton.disabled="0"and fail. Or,
MyButton.disabled="false"// or "enabled"and fail again, and again and again, because he has opinions but no fundamental knowledge about what he is dealing with, nor what he is talking about – at all.
Only a professional will know by heart how and what to do – whenever he needs to.
same thing
equal to
this is for fooling xhtml fools
cause it has the same meaning as the correct HTML syntax
Confusing is it? -Of course it is!
That is, if you are just another xhtml charlatan member of the barbarian horde with opinions on HTML, based on its bastard xhtml language, thatn you are doomed too.
Well, as a matter of fact -all of those who first started coding between year 1999-2001 are doomed and full of propagandistic **** and opinions about things they know nothing at all, instead of being filled with fundamentals and basic knowledge on the subject.
It’s 2011 and this is a topic? Jeezus.
XML has make a lot of noise at one point and HTML, that was also trendy by the WWW moved in its direction and became XHTML. Was it an error? I don’t think so as it helped to formalize and standardize the markup but HTML is not XML and HTML5 is not XHTML so I think most of the comments disagreeing with your propositions are off topic.
its error not to close standalone tags. It breaks base rule of xml based standards
Then it’s a good thing this article is about HTML5, not XML! :)
You might also argue that this is HTML5 and not ePub3 (which is an ebook format accepted by many ereaders). The ePub3 specification is HTML5 and HTML5 is an upgrade of XHTML and HTML.
XHTML is actually HTML but more strict. It’s not amateurish to think and care about other markup languages. Especially if it will help us in the long run. This topic may be very old, but it needs refinement.
The idea of closing standalone tags is very well accepted in web development. It is clean, and makes it easy for transitioning to other formats.
Why not html5 semantic tag used & described, i thought it to be described in this tutorials. But a nice effort.
Can somebody suggest of using semantic tags of html5 in a proper way.