I really like to use "short closing" for tags using ordinary <tag/> format but unfortunately using such method in Browser (i.e. chrome) cause quite unexpected behavior.
When in document I have:
<div/><div/>
it's interpreted as
<div>
<div></div>
<div>
no matter what DOCTYPE i use (XHTML) or HTML5 I just get this in a wrong way.
I'm also using this "notation" for custom tags in namespace <widget:aSampleWidgetA/> <widget:aSampleWidgetB/> which also introduce this problem.
I don't want to use a full closing notation as its making a lot of visual mess in code.
Is there some way to force Browser to parse those tags as proper XML?
Apologies, I can't find great documentation on this but I suspect it is because a div is not a valid self closing tag. Looking at the XHTML DTD, empty tags are specifically marked as EMPTY, div is not, so Chrome instead behaves as if it is html5 where the closing tags are can be left off and takes a best guess as to where to close them.
Alternatively, if you don't like the look of html, perhaps you might prefer something like haml or jade templates.
There is a way to make browsers (except of IE8 and below) parse the markup as XML. You need to serve it with the proper XHTML content type application/xhtml+xml.
Doctype is irrelevant for parsing, it affects only rendering mode (Standards or Quirks). When served as text/html, all pages will be parsed by HTML rules (HTML5 rules for modern browsers), which effectively mean that end slash in the 'self-closing' syntax is just ignored, and the ability of the element to be 'self-closed' is actually hard-coded in the parser. Divs and custom tags don't have this ability.
Related
I see many posts realated to this but never see some good explanation why people do this and what is best practice in professional way?
We all normaly use HTML5 rules and that's perfect but is there any reason to we use in modern design with XHTML rules "for any case"?
I see many WordPress, Jommla, Drupal and some less known templates in this modern days that use combination of HTML5 and XHTML like properly nested HTML tags, non minimizations, closed empty elements like <br />, <hr />, <img />, <input />, etc.
Why do this mix? Is that because support for old browsers or just old-school development mixed with new technology or just leak of knowladge of HTML5 rules?
XHTML had really strict rules, and the browsers wouldn't show things correctly if they weren't coded using the correct syntax.
HTML5 is not that strict. Even if you write a page with doctype set to HTML5, XHTML code will still work.
In some cases it still is a good idea to use XHTML. Eg. e-books. Even though the epub format now supports HTML5, older screenreaders still don't do that. Because of this alot of e-books are stil written using XHTML
The context is understanding the difference between what version of HTML (HTML5) and which parser are being used in combination.
The HTML parser is loose and will accept literally almost anything.
The XML parser is strict and will not tolerate poor code.
Also:
XHTML (application/xhtml+xml) is a subset of XML.
HTML is a subset of SGML.
So you can use HTML5 with the XML parser, my web platform does this (see my profile).
Why serve HTML5 as XML? I had already been using XHTML 1.1 years ago and witnessed a thread on a different PHP programming forum. Some guy could not figure out why Safari would not style an element like all of the other browsers. After three days he figured out he was missing a quote on an attribute; if he had been parsing the page as application/xhtml+xml the page would have broke (Gecko/Firefox/Waterfox the whole page breaks, other browsers will render up to the error) and being aware of the issue fixed it and recovered in seconds.
Those websites are not XHTML, they are simply using an XHTML doctype. The page must be served as application/xhtml+xml (see the network requests panel in any browser developer tools) to be considered XHTML (e.g. XHTML5) otherwise it's actually HTML code with invalid bits of code that are ignored by the browser.
Your comment about the trailing slash is either correct or incorrect subjective to the context of what you intended due to the vagueness of your comment. If you implied that people generally switched from XHTML 1 to HTML5 then yes however if you intended that XHTML now allows omitting the trailing forward slash than no. XML / XHTML require the trailing slash without exception.
The correct syntax for HTML's elements base, link, meta, hr, br, wbr, source, img, embed, param, track, area, col, and input (called void elements in HTML 5) is not to use an XML-style empty-element tag.
Fromt WHATWG/W3c's HTML current specification at W3C:
Void elements only have a start tag; end tags must not be specified for void elements
This isn't a case of XML/XHTML being stricter than HTML or something; it's just due to HTML's SGML legacy: in HTML 4's SGML grammar (DTD) from 1999 these elements were declared to have content EMPTY. If anything, using XML-style empty element syntax is less formal, since merely tolerated and ignored by HTML 5 parsers; but a sequence of a start-element tag, followed by an end-element tag for a void element is not.
See also How to find empty elements in html5 for a more elaborate discussion of empty elements.
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.
I found some code that uses this:
<ul>
<li>
<false>blah blah blah</false>
</li>
</ul>
What is this? Is it an HTML5 creation? SO & Google searching <false> (with or without HTML) didn't show anything.
This is the site. Check the markup for A. communicate through speaking, listening, reading, writing, viewing and representing* under Objective A.
It is not defined in any HTML specification or public draft, and it is most probably not recognized as meaning anything in any browser. In short, it is a “custom tag”; cf. e.g. to Using custom HTML Tags.
In this case, the choice of the tag name looks very odd, and there does not seem to be any references to false element in the CSS or JavaScript code on the page. In general, however, custom tags could be used for styling and client-side scripting, since modern browsers normally parse elements marked up with custom tags and generate DOM nodes for them.
My guess is that the use of these tags is accidental, not intentional. The tags cause no problems as such, at least not until <false> markup is added to HTML... They apparently did not bother using a validator (the W3C validator reports 195 Errors, 26 warnings).
<false> is not a valid HTML tag. However, some browser actually don't care and just parse unknown elements as inline elements, which is why you needed a reset CSS for IE≤7 (?) if you wanted to use new block level elements (e.g. <article>).
This is considered bad style. Either prepare your own doctype or use CSS classes. There is no semantic tag to indicate false values.
since IE won't render XHTML as XHTML, but treat it as HTML instead, when can this actually cause problems for IE?
i know of one case, where
<div style="clear:both" />
in browsers that support XHTML, the div is closed. But IE will treat the div as still open, so the layout can have unexpected result later.
Internet Explorer will have trouble distinguishing XHTML documents from XML documents if the MIME-type is not specified as text/html. However, because it fully supports HTML 4.01 the majority of problems arise from inconsistent and non-standards implementations of positioning, layout, and CSS properties. To avoid any problems it is best to write valid XHTML and specify a DOCTYPE.
A list of all known Internet Explorer Bugs
Self-closing syntax won't work (it will appear to work only on elements that are always empty in HTML). XML serializers might generate <textarea/>, <script/> and similar, which break pages in various ways (triggering complicated error recovery, sometimes involving re-parsing of remainder of the page).
Explicitly closed HTML "empty" elements might behave oddly (</br> inserts break in IE).
<![CDATA[ outside HTML's hardcoded CDATA elements will be recognized as a tag. It won't affect escaping and might make some content disappear.
In HTML's CDATA elements (namely <script>) entities won't be recognized. XHTML requires <script> if (1 < 2) … which is going to be syntax error in IE.
Background of <body> will be applied differently in IE.
There will be no cross-browser syntax for namespace-aware selectors in CSS.
You'll get all implied HTML elements (e.g. <tbody> in all tables) and implictly closed elements (it's usually not a problem when document is valid, but other browsers won't warn you as long as markup is well-formed).
Elements and attributes with prefixes won't be namespaced and will get different tagName in IE (which is also illegal in XML). They won't get appropriate default styling and behaviour either (<xhtml:a> can't be a link).
You won't be able to use namespace-aware methods like createElementNS (they don't exist in IE), .tagName will be uppercase in IE, but not in all cases.
Elements and attributes with prefixes won't be namespaced and will get different local name in IE (which is also illegal in XML).
These are only problems concerning switching from working XML document to HTML. There are as many surprises when you're going from HTML (i.e. what everyone expects and takes as normal behavior) to real XML, e.g. document.write doesn't work rendering most of Google's scripts useless.
These all apply to any browser treating XHTML as text/html rather than specifically IE, but you should read Appendix C of the XHTML 1.0 spec here: http://www.w3.org/TR/xhtml1/#guidelines