I'm using
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8"/>
<script>document.title=" ";</script>
</head>
</html>
It works in IE and Firefox, but Chrome doesn't work.
Well, in W3C standard. It seems that blank title is not allowed?!
User agents should use the document's title when referring to the document in their user interface. When the contents of a title element are used in this way, the directionality of that title element should be used to set the directionality of the document's title in the user interface.
According to HTML5 CR, the title element is required, unless “the document is an iframe srcdoc document or if title information is available from a higher-level protocol” (this is specified in the description of the head element).
It is possible to set the title in JavaScript by an assignment to document.title, in practice and according to HTML5 CR. Of course, this is ineffective for many important uses of the title, since this only takes place in a browser.
HTML5 CR also specifies that the title element must not be empty or contain just a space. More exactly, the content must be text that is not inter-element whitespace.
There is no corresponding requirement for the value of document.title. However, HTML5 specifies that on assignment, leading and trailing whitespace is stripped off. If you test the value of document.title after the assignment document.title = " ", you will see that the value is the empty string, not a space.
Browsers differ in what they do with the document title (set with a <title> element or via assignment to document.title). They may display it in various ways in their user interface. If the title is set to the empty string or is not set at all, browsers typicallty use the file name of the document, possibly somehow modified, in place of a title. This is what happens e.g. in Chrome, Firefox, and IE (on Windows) when they show document title as the name of a tab. (I don’t know what the question means by saying that setting title blank “works” in IE and Chrome.)
In most cases, an empty title for a document makes no sense, any more than it would make sense to publish a book without a name. But if you have a use case where you want to make the title (as shown by browsers in some contexts), you can deploy various tricks.
For example, NO-BREAK SPACE U+00A0 is by definition not a whitespace character in HTML, so you could use <title> </title> in HTML or document.title='\u00A0' in JavaScript. The title will then look like blank, but it’s technically not empty, so it will be used browsers.
Since NO-BREAK still occupies space (it’s really shown with a glyph, just a completely blank glyph), you might use LEFT-TO-RIGHT MARK U+200E instead; it is an invisible (zero-width) control character. In HTML, you could use <title></title>. Alternatively, you could use document.title='\u200E' in JavaScript.
chrome 76, macos 13 may 2019:
<title></title>
works, and here is a full example for an empty jekyll page with no tab title:
---
layout: null
---
<link href="http://localhostdotdev.com/favicon.ico" rel="icon" type="image/x-icon" />
<title></title>
<style>body { background-color: rgb(40, 44, 47) }</style>
(also has an empty favicon and a dark background that matches chrome's dark mode)
Related
The HTML5 specification for tag omission (http://www.w3.org/TR/html51/syntax.html#syntax-tag-omission) starts with the following two statements (emphasis mine):
An html element's start tag may be omitted if the first thing inside
the html element is not a comment.
An html element's end tag may be omitted if the html element is not
immediately followed by a comment.
Those to statements read similarly, but not the same and I am wondering if someon can offer clarification on what they mean.
The following case seems unambiguous - you can't remove the start or close tags:
<html><!-- start --> ... </html><!-- end -->
But what about when whitespace is introduced into the mix. Can the start tag for html be eliminated in the following case?
<html>
<!-- comment after whitespace -->
...
Can the end tag be eliminated in a similar scenario?
...
</html>
<!-- comment after whitespace -->
Some of the other rules make specific mention of whitespace characters which leads me to believe that they should be taken into account. Most of the rules say "...immediately followed by..." which is different than the first bullet point listed.
The important factor here is that the phrases first thing inside and immediately following are talking about nodes i.e. the DOM, not tags or other markup, so the distinction it is making is about whether the node is a child (first thing inside) or a following sibling (immediately following).
As far as spaces go:
An html element's start tag may be omitted if the first thing inside
the html element is not a comment.
The first thing inside an html element cannot be a space character because at that point in the parser algorithm, space character tokens are discarded and not added to the DOM.
An html element's end tag may be omitted if the html element is not
immediately followed by a comment.
Space characters, regardless of whether they appear just before or just after the </html> tag, end up inside the html element (in fact, also inside the body element), so the comment will be immediately following the html element regardless of whether there are spaces in between in the markup.
In html, space between tags doesn't matter. <html> <head> and <html><head> are the same thing to the browser. In content (e.g. between words inside a span/p tag) it's rendered up by the browser, but when you want to use space between elements (as a design resource) you should use  .
So, as I see, immediately followed by doesn't mean "the next character" but "the first thing after the place that end tag was supposed to be, no matter how many spaces between them.
Then, removing html tags in both cases would invalidate the html, because no matter how many spaces are betweeen the place </html> was supposed to be and the comment.
edit: I think they were trying to express the same thing by using another words and avoid being repetitive, but ended up being confuse;
The rules about tag omission are somewhat misleading in that for the most part they're not actually saying when tags can be omitted, but rather how they should be interpreted when they are omitted. Take, for example, the following document:
<!DOCTYPE html><!-- A comment --><title>A title</title>
This is a valid HTML5: you can run it through the W3C validator yourself. But the tag omission rules clearly state that
[a]n html element's start tag may be omitted if the first thing inside the html element is not a comment.
How do we reconcile this? The answer is that these are disambiguation rules. Because an html element's start tag may not be omitted if the first thing inside it is a comment, we are free to assume when parsing that the comment is not the first thing inside the html element. Similarly, the tag omission rules state that
[a] body element's start tag may be omitted if the element is empty, or if the first thing inside the body element is not a space character or a comment [...]
So we are free to assume that the comment is also not the first thing inside the body element. So in fact this document can be unambiguously parsed as equivalent to
<!DOCTYPE html><!-- A comment --><html><head><title>A title</title></head><body></body></html>
The parser algorithm for HTML5 specifies that if we are in the before html insertion mode, which is the state the parser transitions to after seeing <!DOCTYPE html>, and we see
A character token that is one of U+0009 CHARACTER TABULATION, "LF" (U+000A), "FF" (U+000C), "CR" (U+000D), or U+0020 SPACE
then we are to "Ignore the token." If on the other hand we see a comment token, then we are to
Insert a comment as the last child of the Document object.
It's not until we see some other kind of tag that we emit an html element. So we should expect this behavior not to be affected by whitespace, and indeed both Firefox 54 and Chrome 60 interpret the document
<!DOCTYPE html>
<!-- A comment -->
<title>A title</title>
identically to
<!DOCTYPE html><!-- A comment --><title>A title</title>
That is, both of them are treated like
<!DOCTYPE html><!-- A comment --><html><head><title>A title</title></head><body></body></html>
Apparently, if you have a </p> end tag with no matching start tag within the body element, most if not all browsers will generate an empty paragraph in its place:
<!DOCTYPE html>
<title></title>
<body>
</p>
</body>
Even if any text exists around the end tag, none of it is made part of this p element — it will always be empty and the text nodes will always exist on their own:
<!DOCTYPE html>
<title></title>
<body>
some text</p>more text
</body>
If the above contents of body are wrapped in <p> and </p> tags... I'll leave you to guess what happens:
<!DOCTYPE html>
<title></title>
<body>
<p>some text</p>more text</p>
</body>
Interestingly, if the </p> tag is not preceded by a <body> or </body> tag, all browsers except IE9 and older will not generate an empty paragraph (IE ≤ 9 on the other hand will always create one, while IE10 and later behave the same as all other browsers):
<!DOCTYPE html>
<title></title>
</p>
<!DOCTYPE html>
<title></title>
</p><body>
<!DOCTYPE html>
<title></title>
</p></body>
I can't find any references stipulating that an end tag with no corresponding start tag should generate an empty element, but that shouldn't come across as surprising considering that it's not even valid HTML in the first place. Indeed, I've only found browsers to do this with the p element (and to some extent the br element as well!), but not any explanation as to why.
It is rather consistent across browsers using both traditional HTML parsers and HTML5 parsers, though, applying both in quirks mode and in standards mode. So, it's probably fair to deduce that this is for backward compatibility with early specifications or legacy behavior.
In fact, I did find this comment on an answer to a somewhat related question, which basically confirms it:
The reason why <p> tags are valid unclosed is that originally <p> was defined as a "new paragraph" marker, rather than p being a container element. Equivalent to <br> being a "new line" marker. You can see so defined in this document from 1992:http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html and this one from 1993: http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt Because there were web pages pre-dating the change and browser parsers have always been as backward compatible as possible with existing web content, it's always stayed possible to use <p> that way.
But it doesn't quite explain why parsers treat an explicit </p> end tag (with the slash) as simply... a tag, and generate an empty element in the DOM. Is this part of some parser error handling convention from way back when the syntax wasn't as strictly defined as it was more recently or something? If so, is it documented anywhere at all?
That it is required is documented in HTML5. See http://w3c.github.io/html/syntax.html#the-in-body-insertion-mode and search down for An end tag whose tag name is "p" and it says:
If the stack of open elements does not have an element in button scope
with the same tag name as that of the token, then this is a parse
error; act as if a start tag with the tag name "p" had been seen, then
reprocess the current token.
Which translated into English means create a p element if the </p> tag can't be matched with an existing <p> tag.
Why it is so, is harder to ascertain. Usually, this is because some browser in the past caused this to happen as a bug, and web pages came to rely on the behaviour, so other browsers had to implement it too.
The HTML4 DTD states that the end tag is optional for the paragraph element, but the start tag is required.
The SGML declaration for HTML4 states that omittag is 'yes', which means that the start tag can be implied.
The end tag follows SGML rules:
an end tag closes, back to the matching start tag, all unclosed intervening start tags with omitted end tags
Anonymous block boxes are generated for inline elements such as text nodes, so they need not be wrapped by the paragraph element.
There's a thread in the Mozilla bug database which explains this behaviour:
Mozilla parses "half-tags" gullibly, leading to XSS security problems
Here's a relevant comment by Boris Zbarsky:
Actually, as I understand it, proper parsing of SGML/HTML requires that we
behave this way. That is, the '<' of the next tag is a valid way to close out
the markup of a previous tag...
And summarized by Ian Hickson:
The basic principle at work here, it appears, is that the markup is fixed up by delaying any closing tags until after all other open elements have been closed, and no attempt is made to make the DOM follow the HTML DTD.
References
SGML Productions
HTML 2.0 Specification
Arguments against SGML
Tag Soup: How UAs handle
Tag Soup: How Mac IE 5 and Safari handle
Web SGML and HTML 4.0 Explained
Testing SGML SHORTTAG support across browsers
Mozilla Bug 226495
Shorttag and Omittag
Jotting on parsers for SGML-family document languages: SGML, HTML, XML
A brief, opinionated history of XML - bobdc.blog
Context: Currently, Wt (Web Toolkit) will render a WAnchor object as a <span> tag rather than an <a> tag if the link that the anchor should point to, is empty.
However, there are some problems with this approach, notably that it adds unnecessary complexity to CSS styling (when using Twitter Bootstrap, for example).
I've been involved in a discussion with one of the Wt developers proposing a patch to change this behavior: http://redmine.emweb.be/issues/1348
He noted that the current behavior was implemented as a result of certain browsers having problems rendering <a> tags without an href attribute (possibly older mobile browsers?).
According to the official HTML specifications, there is no problem with this:
http://dev.w3.org/html5/spec/single-page.html#the-a-element If the a element has no href attribute, then the element represents a placeholder for where a link might otherwise have been placed, if it had been relevant.
http://www.w3.org/TR/html401/struct/links.html#edef-A Authors may also create an A element that specifies no anchors, i.e., that doesn't specify href, name, or id. Values for these attributes may be set at a later time through scripts.
And as far as I am aware...
<a>Link</a> // OK
<a href>Link</a> or Link // Undefined? (but common behavior is to navigate to the current URL)
Link // OK
I also checked the following document with the W3C HTML5 validator:
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>Untitled Document</title>
</head>
<body>
<a>Example of an anchor with no href attribute.</a>
<a href>Example of an anchor with a null href attribute.</a>
Example of an anchor with an empty string href attribute.
Example of an anchor that links to Google.
</body>
</html>
I received one warning:
Line 9, Column 8: Attribute href without an explicit value seen. The
attribute may be dropped by IE7. <a href>Example of an anchor with a
null href attribute.</a>
So my question is: are there any known situations where the total lack of an href attribute on an <a> tag causes problems in certain browsers? IE? Mobile Safari?
An a element without an href attribute has always been valid in HTML, and there is no reason to expect any browser to have an issue with this. Such an element is effectively similar to span, i.e. lacks any semantics. Traditionally <a name="...">...</a> has been used to set up a destination anchor, usually without an href attribute, and such elements work across browsers, though it is more modern and recommendable to use the id attribute (on any element).
Using href="" is formally correct, with an empty URL, which is interpreted as same-document reference.
Using href without any value is invalid according to current HTML specs. By HTML5 drafts, it can be used in HTML serialization and it is equivalent to href="". There is no guarantee that browsers behave that way.
Instead of
<!--
,
I used
<!-
...and it is working.
How?
It's not actually working - it's just interpreting it as an actual tag, and then throwing that tag out as invalid.
<!- foo bar -->
is treated as a tag, <!-foo bar--> which obviously isn't a standard HTML tag, and thus is ignored.
Try this, and you'll see it's not truly working as a comment:
<!- >foo bar-->
Modern browser parsers (i.e. those that use the HTML5 parsing algorithm) work like this. If they are expecting text or a new tag next, and they see <! then they check the next few characters to see if they are -- or DOCTYPE or, if they are processing embedded SVG or MathML, [CDATA[. (See http://dev.w3.org/html5/spec/tokenization.html#markup-declaration-open-state)
If, as in the case of <!- foo, none of these match then the parser enters the bogus comment state where all the characters following, up to the next >, are read and and converted into a comment to be put into the DOM.
Hence the behaviour you see with <!- working like a comment start. Note that such behaviour is "repair" behaviour for broken markup and it's wise not to rely on it.
You can see how such markup forms a DOM here: Live DOM Viewer
Also note that this is different to what #Amber says. It is not treated as a tag in any meaningful sense, and it is certainly not ignored.
Are there any browser issues with always collapsing empty tags in html.
So for example an empty head tag can be written like this
<head></head>
but is can also be written like this
<head/>
Will the second case cause issues in any scenerio?
Thanks
Self-closing <script> tags can mess up some browsers really badly. I remember my whole page disappearing into thin air in IE after I self-closed a script tag - everything after it was read as a script.
Assuming that you are serving your XHTML as XML, no. <head></head> is entirely equivalent to <head />. In fact, an XML parser won't even bother to tell you which one you have.
(There is, however, an issue in that the <head> tag must contain a <title>.)
You shouldn't use minimized form for head in XHTML.
http://www.w3.org/TR/xhtml1/#guidelines
About empty elements:
http://www.w3.org/TR/xhtml1/#C_3
Given an empty instance of an element
whose content model is not EMPTY (for
example, an empty title or paragraph)
do not use the minimized form (e.g.
use <p> </p> and not <p />).
In other words, paragraph should always be closed in XHTML, in HTML you could go with only opening tag. But if the element is supposed to have content it should be properly opened and closed.
For example line break has EMPTY content model and can be written as <br /> (same goes for <hr />) but not <div />.
Also see this SO question.
Empty Elements (XHTML)
Shorthand markup in HTML
Self-closing tags don't exist in HTML. The / is always ignored, that is, <foo/> and <foo> are equivalent. For elements such as br, that's fine, because you want <br>. However, <script src="..." /> means the same as <script src="...">, which is a problem (as noted in other answers). <head/> is less of a problem, because the </head> end tag is optional anyway.
In XML, on the other hand, self-closing tags do what you want. However, you probably aren't using XML, even if you've got an XHTML doctype. Unless you send your documents with a text/xml, application/xml or application/xhtml+xml MIME type (or any other XML MIME type), particularly if you send them as text/html, they will not be treated as XML.
Not that I am aware of. One caveat that has bitten me in the past is self closing my script tag: <script type="text/javascript" src="somefile.js" />
This results in some interesting fail.
In general an empty element can be written as a self closing tag, or opening and closing tags.
However, the HTML4 DTD specifies that the document HEAD must contain a TITLE element.
"Every HTML document must have a TITLE element in the HEAD section."
http://www.w3.org/TR/1999/REC-html401-19991224/struct/global.html#h-7.4.1
I believe some older browsers had problems with the lack of whitespacing - in particular
<head/> would be interpreted as a "head/" tag, whereas <head /> will be interpreted as a "head" tag with a blank attribute "/" which is ignored.
This only affects a few browsers, AFAIK. Either is valid XHTML, but older HTML-only browsers might have trouble.
This is in fact documented in the XHTML guidelines as C.2
Even considering only browser issues (i.e. disregarding validity) and narrowing the question down to the head tag alone, the answer is still yes.
Compare
<head/>
<object>Does this display?</object>
against
<head></head>
<object>Does this display?</object>
each served as text/html to any version of IE.
Does this display? will be shown only in the latter example.