I feel like this might have already been answered on SO, but I couldn't find a similar question.
I've been told by some more experienced programmers that the following is incorrect syntax :
<input type=...> Name </input>
and that the following is correct syntax :
<input type=..../>
I've never known about this, I've always used the first snippet and have never encountered any problems that I know of. Could someone explain why the first is incorrect, and why it still works? Is it rescued by the browser, or is it just a style issue? Any explanation concerning the syntax above is acceptable, as I don't want to risk looking like a noob the next time I'm asked to write html code.
Could someone explain why the first is incorrect
An input element is not allowed to have child nodes, everything about the input is described by its attributes. To associate a label with an input, use a <label> element.
and why it still works?
Browsers are designed to cope with bad input. They ignore end tags for elements that are not open.
Input tags are basically known as void elements i.e they aren't designed to contain text or other elements, and as such do not need a closing tag.
Realistically, the validity would depend on which doctype you declare.
In this context, /> is valid with HTML 5 and XHTML doctypes and invalid with HTML 4.01 doctypes.
Browsers are quite forgiving, but your friend is right and the syntax is wrong. Input elements should not have content. There are plenty of resources about this, one of them is w3schools which says:
Note: The <input> element is empty, it contains attributes only.
Tip: Use the <label> element to define labels for elements.
You can also find a validator online which will validate your page and report any issues to you: W3 validator. It's well worth the effort to validate a page before publishing it. Even though browsers are forgiving and will try to display a page as good as possible, errors like yours make a page invalid and increase the risk that a page is rendered incorrectly or -theoretically- not at all.
In this particular case, a browser might choose to display the text before or after the input, inside the input (not likely), or not at all. By making an HTML document valid, you decrease the risk of a bad surprise.
The HTML specification about the input element says this:
Content model:
- Empty.
and:
Tag omission in text/html:
- No end tag
That means that the element doesn't have any content and doesn't have any ending tag.
In HTML you write the tag like this:
<input type= ... >
In XHTML the tag follows XML standard, so a tag without content is self closed:
<input type= ... />
In HTML5 either way of writing it is valid.
The reason that the code still works is that browsers try to make the best of invalid code. The extra </input> tag doesn't stop anything from working, the browsers will just ignore it. Either the browser doesn't understand what it is supposed to be, or the browser vendor anticipated that specific error and the browser knows to ignore it.
Related
I am using angular-ui-select within a website where the styled select fields are configured with an own tag named ui-select. This works great, but doing a W3C validation leads to this error:
Element ui-select not allowed as child of element div in this context. (Suppressing further errors from this subtree.)
Here's an example code:
<!doctype html>
<html lang="en">
<head><title>x</title></head>
<body>
<div>
<ui-select></ui-select>
</div>
</body></html>
I understand that <ui-select> is not expected to be there but how can I handle this better?
Can I wrap it into a different tag or is there a different approach for ui-select instead of using HTML markup?
W3C HTML5 validator maintainer here. The short answer with regard to the validator behavior right now is, the validator's going to emit errors for any custom elements you use in documents, and currently there's no way you as a user can work around it doing that—and it's going to continue that way for some time longer until we get around to figuring out a solution.
We're having some ongoing discussions about how to solve this. Changing the validator to just ignore any element name with a hyphen is not viable as a complete solution, because the consequence of that is we could then not practically check any child elements it might have—we'd just have to ignore the entire subtree, because to do otherwise would lead to other errors. So that's way short of being an ideal solution.
Anyway, I'd love to find a good way to solve this, so if others have ideas I'd like to hear them. Two good places to send ideas/proposals on this are the public-webapps#w3.org mailing list https://lists.w3.org/Archives/Public/public-webapps/ and the whatwg#whatwg.org mailing list https://whatwg.org/mailing-list#specs
One idea I've thought of myself is, we could just have the validator treat all custom elements in the same way it currently treats the <div> element (as far as where it's allowed in a document and what child elements it's allowed to contain). That's also short of ideal, but at least it would give a way to check for errors in descendant elements in the custom element's subtree.
Update 2017-02-06: the W3C HTML Checker now supports custom elements
So, I added support for custom elements to the W3C HTML Checker (validator) on 2016-12-16 and a few days later refined it to do more detailed checking for prohibited names.
The trick I ended up figuring out to implement it in the checker architecture—which is at its core a RelaxNG grammar/schema-based validator—was to add a pre-processing filter that take any elements that have a hyphen in their element name, and puts them in a separate XML namespace.
Then I updated the RelaxNG schema to allow any elements from that XML namespace anywhere. (Which is ironic because I pretty much hate XML namespaces and all the problems they cause.)
So we’re now looking at doing something similar for custom-attribute names—probably just by defining those as being any attribute names that contain a hyphen (like custom-element names).
But the HTML checker can’t be changed to allow custom-attribute names until the HTML spec is updated to allow them. For that, see the proposal being discussed in the HTML-spec issue tracker.
That's indeed a long-known issue with AngularJS.
A few things you can do:
Instead of using the element <ui-select>, you can use <div ui-select>, but that will still fail on the argument.
An argument prefixed with x- or data- will pass but I am not sure ui-select supports that.
HTML W3C validation is useful, but I think mostly important for HTML emails so they don't get screened as spam. It's also good for search engines, but really not that critical.
If you look at 'why validate', the reasons are mostly for cleanliness, ease of debugging, and overall good practice.
Angular (un?)fortunately expands the realm of possibilities for HTML5, in a way that, naturally, deviates from the latest specifications for HTML.
We are having the same problem using Knockout custom components.
http://knockoutjs.com/documentation/component-overview.html
I added a suggestion how to enhance the validator with a minor enhancement for users wanting to use custom elements even if the specification is not yet final (http://w3c.github.io/webcomponents/spec/custom/#custom-tag-example):
https://github.com/validator/validator/issues/94
I posed a similar question some time ago and got a pretty good answer, now I would like to slightly modify that question in light of something I noticed while working with Google Maps.
The question is, I've always used <div style="clear:both"></div> to clear a float. There are other times when I've needed to create an empty element to be populated with JS, for example. Now, since HTML is a subset of XML, why can't I use <div style="clear:both" /> instead of typing the ugly closing tag.
I was given a great answer that I admittedly don't fully understand in my previous question, but while working with Google Maps I noticed that Google had the same idea that I did. In their very first code sample, they use <div id="map-canvas"/> without the ending tag.
So my new question is, even if this is not quite proper HTML, would there ever realistically be case where this would not work?
Please and thanks.
Now, since HTML is a subset of XML
HTML is not a subset of XML.
HTML 4 and earlier were SGML applications, but browsers never implemented the SGML specification properly.
XHTML 1.x is an XML application, but browsers will only use XML parsing rules if you serve XHTML with an XML content-type (like application/xhtml+xml).
HTML 5 has its own parsing rules that better reflect what browsers actually do. It allows a / character at the end of elements where the end tag must be omitted for the sake of people who are addicted to XML or have poor syntax highlighting software, but only those elements.
I noticed that Google had the same idea that I did. In their very first code sample, they use <div id="map-canvas"/> without the ending tag.
That is an error and is not allowed in HTML. It only "works" in browsers because the end of the document comes before the start of any element or text that is allowed as a child node of a div element.
The question is, I've always used <div style="clear:both"></div> to clear a float.
That's a nasty approach to the problem in the first place. It requires an extra element, and can add space where the element is rendered. Better, in almost every case, to set overflow: hidden on the containing element to cause it to wrap the floats.
HTML is not a subset of XML. HTML has a different structure. Some elements are singular (like image) and don't need a closing tag or ending / at all. The ones who do, need to be closed by a proper closing tag.
Some people use XHTML, though, which is basically HTML using XML syntax. It depends on the doctype you use.
Google's example is wrong in this case. It uses a Html 5 doctype. If you run their snippet through the W3 validator, it tells you:
Line 26, Column 26: Self-closing syntax (/>) used on a non-void HTML
element. Ignoring the slash and treating as a start tag.
<div id="map-canvas"/>
And that's what will probably happen in most browsers as well. They read it as if the div is just opened there. At a certain point it will be automatically closed. The / is ignored.
About the clearing of floats: the way you are doing it is old, and ugly because you need extra markup, for what is basically a CSS issue. Fortunately, there are better ways, a couple of which are described in detail here: What methods of ‘clearfix’ can I use?
I found that add attribute to close tag can treat as comment and is very convenient:
<div id="container">
very many mess that you may mess up tags....
</div container end>
And tested it on every browser and it seems no quirk.
I want to know does it has any side effect that I didn't notice?
It makes your html not valid anymore. It may have unexpected side effects, like forcing IE into "quirks" mode. Also, it seems abusive. Please just use HTML comments, <!-- Hello, World! -->.
In “genuine” XHTML, i.e. XHTML served with an XML content type, an attribute in an end tag is treated as a well-formedness error: the page is not displayed at all, and an error message is displayed instead.
Otherwise, there are no documented effects. The parsing rules in the current HTML5 CR imply that attributes in an end tag are parsed, but no processing (no meaning) is assigned to them. They are not specified as causing a parse error. This may, however, be an oversight; but declaring them as parse errors would just mean that browsers “may abort the parser” (and browsers do not actually do such things).
Thus, in HTML syntax (as opposite to XHTML syntax), attributes in end tags can be expected to be ignored. On the other hand, there is nothing particularly convenient about them. If you use </div container end>, it may have undesired side effects on you or other humans that read the HTML source. You may get lured into thinking that this must be an end tag for <div id="container">. It may, or it may not; this simply depends on whether it actually matches in the syntax – something that a good editor should show you.
This sounds a bit like a trivia question, but it would help me figure out my options solving an actual problem. Is there an HTML tag that can be used anywhere in the DOM? (something to be used as a placeholder) An HTML5 tag would be ok. No XHTML unfortunately.
I've thought about it for a bit, the only tag I can come up with is <script/>. Otherwise, I guess that <span/> would work almost(?) anywhere in <body/> and <meta/> would work in <head/>. Any other idea? I haven't thoroughly checked HTML5, so perhaps I'm missing a newer addition.
Also, please don't overthink this and try to reverse-engineer my question. Using a tag as placeholder is one of many different options that I'm examining, that's all. Thanks!
<!-- this one -->
Comments cannot be retrieved using DOM's getElementsByTagName(). However, it is possible to select them in XPath using the node test comment(), e.g. //comment() would select all the comments in the document.
You mentioned that you'd not looked in detail at HTML5, and you've already accepted the comment answer, but I thought I'd mention that most of the elements that come under metadata content would be valid. You can only use base and title within the head element, but all the rest are also valid in the body:
command
link (with itemprop attribute for body)
meta (with itemprop attribute for body)
noscript
script
style (with scoped attribute for body)
Of course, the semantics of those elements may not be suitable for you, if comments work stick with them.
Come to think of it, comments can be used anywhere, although I'm not sure they qualify as a proper tag.
I have a lot of empty span tags and so on in my code, due to CSS image replacement techniques.
They trigger a HTML validation warning.
Should I care?
I agree with #Gumbo, but having lots of warnings that make no difference can hide the ones that you do need to pay attention to. If you can put something in the span that gets rid of the warning but doesn't break your UI, you should at least think about doing it.
I've made validation part of my workflow because it helps me catch mistakes early. And while I don't consider empty elements to be a problem, it negates some of the value of using a validator if I have to mentally parse a list of warnings each time and decide whether a warning is important or not. So I try to keep my pages both error- and warning-free so that a quick glance at the HTML Validator icon in the Firefox status bar only changes when there is a real problem. To that end I keep empty elements "unempty" by inserting an empty comment.
<span><!-- --></span>
(At least that works with the Tidy validator.)
Now, that being said, I don't think this is at all necessary for many situations. It is perfectly reasonably to think that adding eight extra characters to your code just to avoid a validator warning is ridiculous. But it works for me.
You should consider the behavior of the page for things like screen readers. It is common to actually put a few words describing the image in the tag that are then hidden by the image replacement.
See the CSS Zen Garden where you can see examples like H1 spans with text being replaced in CSS by images.
This will improve the not only the accessibility of your site, but also the search-ability.
An "empty" tag has a very specific definition in HTML:
<span/>
versus
<span></span>
The former is not permitted by the HTML 4.0 Strict DTD, so should be flagged by a validator. The only tags that can use the former syntax are those specifically identified as "EMPTY" in the DTD (eg, <br>).
The second form is valid HTML, and does not get flagged by the W3C validator.
So I have to assume that either (1) your validator is broken, or (2) you are using the tag incorrectly.
A warning is not an error. It’s just a reminder that you should improve something.
I suppose if bandwidth was an issue, those empty tags could be revisited to see if you could get them from appearing alogether.
Eric Meyer also says that empy tags are bad, semantically.
Warning don't mean it's wrong, but say it could, or sometimes should, be better.
In the same way
if("value"==variable)
is better than
if(variable=="value")