Explanation

HTML is a markup language used in web development, and is the subject of this comic. The comic employs multiple poor HTML practices while asking the rhetorical question of how best to annoy web developers, effectively answering the question that it poses.

First, in HTML, all tags should be matched with both an open and close tag of the same type <div>Like this</div>. Previous to HTML 4.01 all tags were uppercase (technically elements were uppercase and attributes were lowercase "to improve readability" [1]) to make it easier on the browser to parse what was markup and what was content on the page. As is the case with nearly every change to the HTML specification, many developers slowly got lazy and stopped making every tag uppercase forcing browser developers to check for both upper and lowercase as they parsed the markup. When the specification was bumped to XHTML 1.0 it stated that no one should use uppercase tags any more, everything should be lowercase.

Another basic idea of HTML is that all tags, or elements, must be properly nested. (Although they have slightly different meanings, the words "elements" and "tags" are generally used interchangeably.) That is, anything inside a div must be closed before the div is closed.

Correct

Incorrect

<div>
<ol>
<li>Correctly nested</li>
</ol>
</div>

<div>
<ol>
<li>Incorrectly nested</li>
</div>
</ol>

Further, web developers make a distinction between semantic and structural elements. Semantic elements contain a clue in their name as to what kind of an element they are - for example, an <article> tag contains an article, such as a blog post or news article, while an <ol> tag contains an ordered list. (It's wise to note that this is not an absolute rule; it's possible to put non-article content in an <article>, it's just not recommended.) Semantic tags do not, however, indicate how their contents are to be displayed; your browser might display an <article> in the default font, layout, and placement, while mine, a screen reader, might ignore everything on the page <article>s, and read <article>s in a soothing voice.

Structural tags, on the other hand, give no clues as to what they contain; they just indicate how a web page is to be laid out. <span> and <div> are structural tags; they can contain anything. Their definitions in HTML simply indicate that <div> is a block tag - it can affect both what the text looks like and where it is on the page; by default, it is displayed in a separate block from the rest of the text in the page, and has at least one line break before and after its display - and <span> is an inline tag - it affects what its text looks like, but not where it is on the page. Without additional attributes, it's impossible for a browser to tell what's supposed to be inside a <div> or a <span>, which means that my screen reader can't just pluck out the blog posts and read those.

Currently, the standard of usage is shifting toward using semantic tags over structural tags, since they provide more information to browsers and people reading the source code of web pages. HTML5, the most recent version of the standard web development markup language, is introducing many semantically meaningful tags that can be styled using CSS to follow the same behavior as a div or span, but that are easier to understand when reading the markup or parsing it with a non-standard browser.

The title text makes reference to &nbsp;, which is the HTML escape code for non-breaking space which is a type of space that will keep two words together, and will not allow word wrapping to separate them. If the words come at the end of a displayed line, how this is handled depends on the browser and on the element's styling; some browsers and styles will force the connected words onto a new line, while others will "overflow" the edge of the container to accommodate the linked words. This is useful, for example, for keeping units with a number so it is easy to spot 100 km instead of needing to hunt for 100km. Using a non-breaking space at the end of a line, without another word on its trailing end, is only useful in extremely rare and limited circumstances, and does not generally have a purpose.

The title text also uses an <A> tag, seemingly to indicate an answer. In fact, <A> is an anchor tag, which creates hyperlinks. It is not an answer tag. This tag is generally used with either the href= (which creates a link to another URL) or name= (which creates a named anchor on the page that can be linked to with href=#) attribute (but not generally both at once). In addition, the placement of <A> and <a> (the capitalization here is also irritating to a web developer who values consistency) indicates that ": Like " should be a link or named anchor, but "this." should not. Whether or not to include punctuation in an anchor is a matter of some debate among developers, but including excessive whitespace is generally frowned upon, and the anchor should include all of the relevant text.

Transcript

Discussion

I literally grimaced when I saw the comic, and then I read the title text and my stomach churned, and then I saw the non-breaking space and I wanted to crawl up in a ball and die. lcarsos_a (talk) 06:01, 7 December 2012 (UTC)

Most people curl up into a ball to die. Well not most people... 192.104.231.235 17:50, 8 May 2013 (UTC)skrame

I'm a web developer and I didn't find this annoying, although I did roll my eyes. Then I came here to see if there was anything I missed that SHOULD annoy me. No, to annoy a web developer you have to use table tags, blink tags(not supported on most browsers for good reason, annoys anybody when it works), and have a stray !-- inside a tag where it doesn't belong. Also, use any html inside your css file. And have it where it only works in IE. Ferretwilliams (talk) 06:11, 7 December 2012 (UTC)

That's okay, it's easy to implement blink with javascript and changing the display value from hidden to inline every half second. And lots of news sites these days re-implement the marquee tag with a bit of javascript too. What Randall really missed here was an opportunity for the center and font tags. lcarsos_a (talk) 06:18, 7 December 2012 (UTC)

It's been a long while since I coded html (I quit about the time style sheets appeared) but I think the annoying part of &nbsp; is the fact that it appears as the 6 characters instead of a space, not just that it's at the end and could push the text to another line. Doesn't this typically mean that someone copied some code but didn't look carefully at the results when they pasted it into an editor? --DanB (talk) 14:27, 7 December 2012 (UTC)

Either the title text has been parsed - in which case it's actually &lt;A&gt;: Like&lt;/a&gt; this&amp;nbsp; (and, yes, probably copy/pasted) - or it hasn't (which seems more likely to me), in which case the &nbsp; will show up as a non-breaking space when it is parsed. Noëlle (talk) 00:40, 8 December 2012 (UTC)

The title text is copy/pasted from xkcd, where he escapes the ampersand so that the non-breaking space escape will show up in the title text. He might just be toying with those of us who know about the non-breaking space, as most people (the kind of people that would mis-match div and span and change the case of their tags) don't even know what a non-breaking space would be used for. lcarsos_a (talk) 03:37, 8 December 2012 (UTC)

I know. :) I was answering Dan's question. Assuming the title text is going into a webpage, either the whole thing is already parsed, in which case the tags will also appear as they currently do, or it's not parsed yet and the &nbsp; will appear properly in the rendered page. :) Noëlle (talk) 01:53, 10 December 2012 (UTC)

I wonder if the "answer" in the title text is yet another joke? It goes <A>: Like</A> this — but A used in this way means Anchor, not Answer. Such a line would appear in the browser as "Like this" (with the word Like blue and underlined), making it a clickable "Like" link. -- 69.158.169.14 (talk) (please sign your comments with ~~~~)

I think there is another joke hidden there: It goes »<A>: Like </A>this« instead of »: <A>Like</A> this« which turns not only »Like« but also the surrounding whitespace and punctuation into a link/anchor. That points to WYSIWYG HTML editors, as it's easy there to select a little bit more than the intended word when creating a link/marking text as bold, etc. 178.201.95.76 01:03, 8 December 2012 (UTC)

Actually, the Like wouldn't be blue and underlined BECAUSE it lacks the href. At least in firefox. The <a name> and <a href> are so different that browser apparently don't do either when neither are present. -- Hkmaly (talk) 11:48, 8 December 2012 (UTC)

Similarly, it would be nice to address whether you can close a <div> with a </span>. Obviously you're not supposed to, but would it work? – PhilosopherLet us reason together. 20:57, 7 December 2012 (UTC)

Opening but not closing a div tag, depends on how a browser's quirks mode interprets that; I'd expect the browser to have everything fall into that div until it encounters a close tag of an element outside (that the div is nested inside). I'd also expect that encountering a close span without having first pushed an open span tag onto the DOM would simply not be recognized as markup and treated as improperly escaped page content. But, I don't write code for any of the major browsers so this is wild speculation. lcarsos_a (talk) 21:24, 7 December 2012 (UTC)

You can't close a DIV with a SPAN; they're syntactically different and browsers treat them as such. If you try the code above, the major browsers do exactly as Lcarsos suggests with the open DIV (continue until they find a matching /DIV or until /BODY) and completely ignore the /SPAN (Chrome goes so far as to expunge it from the DOM entirely). The DIV behavior exposes a subtler aspect to the comic, actually - because DIV isn't a semantic element, if a /DIV is missing, it can get very, very difficult to track down where the appropriate /DIV is supposed to go, especially when multiple coders are working on a single long (and, in the worst-case scenario, improperly-nested, multi-file) page. Noëlle (talk) 00:39, 8 December 2012 (UTC)

Note that "multi-file" is common when it's application output and not static page. Even if the files are supposed to be correctly nested, it may be hard to find which of them isn't, especially taking into account "if"s of template engine. The template engine may not really help you, similarly to some interprets or compilers of programming language which tells you they are missing some closing symbol near the end of file even when the place they are actually missing from is somewhere in the middle, because they paired them incorrectly. -- Hkmaly (talk) 11:48, 8 December 2012 (UTC)

There needs to be a little more explanation of what <div> and <span> tags are. I come here to have the jokes I don't get explained, and after a sentence like "Usage of <span> and <div> tags should be kept low, for they have no intrinsic semantic value," I need a site called "explainexplainxkcd.com." 24.224.110.93 01:17, 9 December 2012 (UTC)

I clarified in the explanation. Does that look better? Noëlle (talk) 01:53, 10 December 2012 (UTC)

Yes, thanks. I'm afraid I still don't have much idea what <div> and <span> are, but it looks like that's because it would to hard to absolutely fully explain. Thanks! 98.122.166.235 04:07, 10 December 2012 (UTC)

It would, but I'll give it a shot! First, let's establish that DIV and SPAN are HTML elements that surround text or other elements on the page. You generally don't see <div> by itself; you see <div>Some stuff</div>. The forward slash in the second tag tells the browser to close the DIV element. (That's the difference between a tag and an element; <div> and </div> are both tags, but we refer to <div>contents</div> as a page element.)

Now, to extend the metaphor into the real world, you can think of <div> as meaning "container" and <span> as meaning "effect". "Container" doesn't mean very much by itself; it's just "a thing into which you can put other things". Likewise, "effect" just means "a way in which you can change how other things look". ("Effect" isn't necessarily the best term here, but I can't think of a better one.) "Container" provides no clues as to what kind of container it is or what you might find inside; "effect" doesn't really tell you what kind of visual change you're getting.

Imagine, then, a Christmas tree. You can put the Christmas tree in a tree stand (<div class="tree-stand">Christmas tree</div>) or inside a big box (<div class="big-box">Christmas tree</div>), or both at once if you're feeling saucy (<div class="big-box"><div class="tree-stand">Christmas tree</div></div>). Note that the closing tag will backtrack through the code and close the first DIV it finds, so that you could put other things inside the big box too: <div class="big-box"><div class="tree-stand">Christmas tree</div>Christmas cookies</div>. Likewise, you can attach ornaments and tinsel to the tree. Since they're effects that you're adding to the tree, rather than containers into which you're putting the tree, you'd use SPAN: <span class="ornaments">Christmas tree</span> and/or <span class="tinsel">Christmas tree</span>.

You can even have a Christmas tree with ornaments on the left and tinsel on the right, in a tree stand, inside a big box, with some cookies in the box with it:

(I decided to frost half of the cookies while I was putting them in the box.)

There's an important distinction to make here, by the way: the ornaments and tinsel can't help you move or position the Christmas tree, and they don't tell you anything about where the tree is, which is why we're using SPAN for them. The big box and tree stand, on the other hand, can be used to move or position the tree, which is why we're using DIV.

Meanwhile, HTML5 wants us to use <bigtreebox> and <treestand> for the containers, and <ornaments>, <tinsel>, and <frosting> for the effects.

While I'm thinking about it - DIV and SPAN remain very important tags in web development, because even though they're structural and not semantic, the fact remains that there isn't going to be a pre-defined semantic tag for everything you want to do, and not every browser supports making up your own tags (even though they're supposed to). Until HTML5 is finalized (which is currently projected to happen in 2016, if I'm remembering correctly) and everybody starts supporting arbitrary tag definitions (which may be "never"), DIV and SPAN will remain useful as generic "container"/"effect" tags. Noëlle (talk) 12:14, 10 December 2012 (UTC)

As an intelligent human, it irks me when other humans are lazy, sloppy, or otherwise stupid. As a developer, I sometimes deal with all three. My annoyance factor is amplified by the fact that developers are (supposedly) educated and should be held to a higher standard. So the question is not "what can you get away with in most browsers", but "what is the established standard." As Mike Holmes would say, "Do it right the first time." - Ixalmida --208.95.30.82 18:10, 10 December 2012 (UTC)

My personal feelings aside, this isn't an appropriate forum to debate the worthiness of contemporary use of HTML5. Noëlle (talk) 22:12, 10 December 2012 (UTC)

It seems to me that this explanation is missing part of the joke in the title text. The Anchor tags are excluding the word "this", while it is VERY common to make a link ONLY the word "this", such as "It should look like <A>this</A>". I wouldn't be surprised if I saw something declare that the word "this" is the most hyperlinked word in the English language, LOL! I cannot believe that excluding the word was accidental. - NiceGuy1 198.41.235.209 09:02, 23 January 2016 (UTC) I finally signed up! This comment is mine. NiceGuy1 (talk) 06:03, 9 June 2017 (UTC)

I used to develop web pages. Now I'm a plain surfer. This comic has the wrong text. It should be "How do you annoy a web surfer?" I cannot count how many sites are ruined by sloppy coding Just Like Randall Illustrated. And people expect all browsers to cover up their slovenly laziness. 172.68.3.127 05:23, 21 August 2016 (UTC)

"Using a non-breaking space at the end of a line, without another word on its trailing end, is only useful in extremely rare and limited circumstances, and does not generally have a purpose." A dating site I use allows you to use linebreaks on your profile, but any updates get pushed to the "news feed" without linebreaks, resulting in sentences or lists running together. Excess spaces are removed, so a non-breaking space (while invisible on the profile) will render the text readable in the feed. 108.162.210.196 20:17, 8 November 2016 (UTC)

"Before HTML 4.01, all tags were uppercase (technically elements were uppercase and attributes were lowercase "to improve readability" [1]) to make it easier on the browser to parse what was markup and what was content on the page." This is simply wrong. HTML tags have never been case-sensitive (XHTML was). The linked page in no way bears out this assertion. My source is having worked on HTML before HTML 4. I will edit this in 24 hours unless someone objects. That will give me time to find better sources. AmbroseChapel (talk) 01:46, 4 September 2017 (UTC)

Sources for HTML not ever being case sensitive, either before or after version 4:

Those first three are linked from the official W3C spec. I really think someone made a huge mess of trying to understand HTML's relationship with XHTML? Anyway, as that stuff about case and HTML is simply wrong, I will now edit it out. AmbroseChapel (talk) 23:36, 4 September 2017 (UTC)

Tools

It seems you are using noscript, which is stopping our project wonderful ads from working. Explain xkcd uses ads to pay for bandwidth, and we manually approve all our advertisers, and our ads are restricted to unobtrusive images and slow animated GIFs. If you found this site helpful, please consider whitelisting us.