People like to pretend HTML is semantic markup. (Semantic? No such thing exist. But I'll leave that inflamatory statement for another day).
Case in point: <em> vs. <i>, and <strong> vs. <b>. People who believe in semantic markup think em and strong are better, because they are "semantic" (are my scare quotes semantic?). But to me they are the exact opposite of semantic. What is "emphasis" supposed to mean? How is it different than "strong"? Beats me.
Semantic markup is supposed to be meaningful markup. The reality of web pages is that they are a visual, published medium. People think about these mediums visually, not in terms of a taxonomy of expression. When I want italics, I want italics. There's no underlying desire. I don't want "emphasis". I can reflect, and decide that I was intending to express emphasis, but that desire is retroactively determined, it is not my true desire at the moment when I was in the midst of composition. My true desire at that time really was "I want this text to be slanty with little curls".
This reminds me of (or maybe it's inspired by) a book I've been reading (slowly, for years), Consciousness Explained. One of its core ideas is that consciousness is what we tell ourselves we were experiencing, it's not what actually goes on in our heads. What that means is another (long) topic, but functionally I assert that semantics are a conscious process on a level that is not otherwise required for composition. By requiring that kind of thought, we are weighing down the author whose effort should really be directed towards writing, not towards typography.
(I'm writing this in ReST, which kicks HTML's butt!)
I personally prefer the term "structural markup" when discussing HTML.
I like ReST too, although I'm torn as to whether stripping stuff like
This is a title
---------------
Is better than
This is a heading or
this is a title
ReST is definitely easier on the author when facing a textarea box or some other functionless editing environment.# Mike
Structural markup and semantic markup are separate things, IMHO. Structural markup means that you don't abuse tables and instead use divisions to organise a page (as an example). Semantic markup means you use accurate element types to describe your data. They are similar concepts, but not identical.
"Case in point:" the I element type vs the EM element type. One means emphasis and the other means italics. It's arguable that the I element type should not have remained in HTML, but the argument for keeping it there was that there is a strong case for where italics is a convention that should not be broken; for example names of different species in biology texts.
If I wanted to index a website for search purposes, then ranking the keywords within EM elements higher than normal text would be sensible. The same is not necessarily true of I elements. There are a number of search engines that behave differently based upon whether they encounter I or EM. I consider this to be a feature rather than a bug - after all, I means a completely different thing to EM. The only reason they are confused by authors is because the presentation in common browsers is the same.
The difference between STRONG and EM is a matter of degree - there have been arguments that STRONG is redundant and that it should be replaced with nested EM elements. EM == emphasis. STRONG == strong emphasis.
"People think about these mediums visually,"
I don't. You'll have to prove that assertion rather than simply say it and hope people believe you. If anything, I experience what I write aurally rather than visually - I'm sure I'm not the only person who writes with a tone of voice in mind rather than how it will look on the page.
Probably Jim you are in a minority then. Here's a test, your words follow. Did anything stand out? Did you hear that? What?
----------------------
I don't. You'll have to prove that assertion rather than simply say it and hope people believe you. If anything, I experience what I write aurally rather than visually - I'm sure I'm not the only person who writes with a tone of voice in mind rather than how it will look on the page.
I don't. You'll have to prove that assertion rather than simply say it and hope people believe you. If anything, I experience what I write aurally rather than visually - I'm sure I'm not the only person who writes with a tone of voice in mind rather than how it will look on the page.
I don't. You'll have to prove that assertion rather than simply say it and hope people believe you. If anything, I experience what I write aurally rather than visually - I'm sure I'm not the only person who writes with a tone of voice in mind rather than how it will look on the page.# Mike
I think when I said "People think about these mediums visually" I was saying it the wrong way. People think of these in terms of example, and symmetrically with reading. I know what things are appropriate as italics because of an intuition I've developed with reading. Ditto punctuation and smiley faces. I don't understand the rules behind these. I could understand them, I could probably make something up if you asked, but I don't write based on rational rules. I think this is generally true of writers. I might even venture a guess that people who aren't comfortable writing often don't have that intuition, and attempting to simulate intuition with rules is difficult and distracting.
My intuition says slanty-letters. If I read HTML source all the time, I might develop an intuition that mapped well to the em tag. Admittedly I don't see i either, but at least the mnemonic is better. And ReST is better yet, because I do read *italic* stuff often. (But is that italic or bold? It can be both, really)
I also hate instant messangers that put in smiley faces. They are horrible. The smiley has become a valid (and very important) form of punctuation. Punctuation should have symmetry. I should see it on my keyboard, see it when I'm typing it, read it when it's sent to me. But then I seriously doubt anyone here would actually support the graphical smiley faces, so this is an empty rant ;)# Ian Bicking
A curiosity :)
When we shifted our project to using reST, I extended it in some ways, like being able to use triple-stars to emphasize + strong content. Because --- people thinking visually --- would need to do that some times.
For some reason, much later, I found myself reading the docutils list, where a reST advocate strongly emphasized that this made no sense. "**" was "strong emphasis", so what (structurally, semantically, ?) sense did "strong emphasis" + "emphasis" make? And he was right: it doesn't really make any sense ... except it was definitely necessary.
(And, um, I'd have to confess that the idea of generating smileys always seemed cool until the unbalanced paren problem became obviouis. Me, I can't stand the look of smileys in proportional fonts ;-)# Roger Espinosa
Are these debates just backwash from the introduction of HTML as a rough-and-ready, who-cares-about-strict-semantics markup language, and the subsequent stumbling attempts to separate structure and presentation with XHTML and CSS?
To me, even though I've never used a screen reader, knowing they exist and that it's important as a web designer to acknowledge their existence has been crucial in recognising, for example, the difference between EM and I. The question "What is 'emphasis' supposed to mean?" seems odd in this light. It means emphasis ;-) I is just an overhang from HTML's mix of presentation and structure. The visual, printed convention for, say, book titles, is italics. But you wouldn't normally want such a title *emphasised* if the text was spoken aloud. (Theoretically, in this case you should extend XHTML with a BOOK element, or use a CLASS on a SPAN and apply the italics with CSS. I usually stick with I for backwards-compatibility.)
Some words you want to emphasise. Visually, that usually translates as italics; aurally, it means intonation and volume. The web *is* primarily a visual medium, at the moment. But it seems wilfully ignorant to disregard the efforts to separate structure and presentation over the last 6 years or so.
In terms of writing web content, as both a writer and web designer I've got used to writing with markup, and it's always my sub-vocal expressions that guide the markup I use.
Gyrus: if you provide a semantic markup language, they won't come. People won't just spontaneously write properly-categorized semantic markup because in theory are are useful distinctions to be made.
Though I suppose, given a semantic document source you could map it more accurately to HTML that made the distinction between i and em. Though I somehow doubt that this will be common enough to make i/em distinctions valuable for a screen reader. It's not that people who don't distinguish are insensitive to the blind -- writing relies on empathy, and there's simply a disconnect there.# Ian Bicking
Mike,
You miss my point. I was talking about writing, not reading. Of *course* bold and italics emphasise things when you are reading something in a visual medium. That the whole point of them.
Ian seemed to be saying that when he writes something, his motivation for putting something in italics is that he wants it in italics, not to emphasise something. That's something the Robot Wisdom guy keeps saying, and it's not something I agree with.
As I said before, I have a tone of voice in mind when I write - that doesn't mean that when I use EM elements my primary consideration is how the page will sound when read aloud.
It occurs to me that when Ian says "The reality of web pages is that they are a visual, published medium." he is mostly (95+%) correct, and that the source of the division between semantic HTML and "classic" HTML hinges on this well-established precedent -- the majority of web pages are indeed designed for visual consumption. The "semantic" web, in W3C terms, refers to documents whose markup expresses meaning rather than presentation. Unfortunately, web-based browsers center around visual presentation, as does the primary XML-based markup language for web documents, XHTML.
The key fact to consider is that 95+% of all web browsing is done using an agent that doesn't interpret meaning as such. Mozilla has the ability to apply separate presentation instructions (CSS files) to bare XML documents, but does any other user agent have this ability? Not that I am aware, or at least not completely (feel free to edumacate me... ;).
I agree that XHTML is fundamentally broken in its current incarnation. The W3C would like us to believe that XHTML is semantic, an assertion with which I do not agree. I feel that XHTML is, still, a presentation language and I can prove it by pointing any standard browser at an XHTML document that does not contain any style information at all and still get typographic differentiation of portions of the text based on the XHTML-valid tag structure of the document.
The unsolved problem, however, is the remaining 5-% of agents out there, screen readers et al., that do indeed interpret (X)HTML documents in ways that do not coincide with the visual presentation afforded by XHTML. To accommodate them, I write my HTML keeping in mind the W3C-intended differences between EM and I, and similar. I suspect I find it as natural as any other type of writing (coding), because I do write with a tone of voice in mind, as per Jim, rather than considering the visual presentation. Also, I have pretty thoroughly internalized the difference between EM and I, and similar cohorts, so that I actually *think* in terms of emphasis rather than italics. But then, I'm a very non-visual thinker in many ways. I think also that I got into the habit a long time ago of creating content first, without any consideration for presentation, and only after I'm finished with the content do I worry about how it looks. I know for a fact that most people don't write this way, but it was trained into me when I was working telephone support for MS Word. The more advanced features of Word (master documents, in particular) cannot be used effectively while writing. They can only be implemented properly by applying them after finishing content creation.
Ian later says "if you provide a semantic markup language, they won't come. People won't just spontaneously write properly-categorized semantic markup...", with which I also agree. For the most part, people don't do something that provides no real payoff. But I think the payoff is pretty much right around the corner. Mozilla already supports styled XML. The other marginal browsers (sorry, I use a marginal browser myself -- Safari), if they don't support styled arbitrary (though valid) XML now, will do so shortly. I can't begin to guess when or if IE will support styled XML. Kimbro Staken's Syncato weblog software shows us how much added value XML brings to the table. Gentoo uses XML for its documentation, then transforms it to produce the web version. Once people start being able to use a single source document for both the content and the presentation, without mixing the presentation with the content and without making the presentation technology hard to use, semantic documents will come. Look at it this way: wouldn't it be easier to write content just once in an XML vocabulary that is well-suited to express the semantics of the content? Use an easy schema language (e.g. Relax NG) to describe the semantics, then just post the document wherever you want, and allow the user agent to do their job of presenting it to the user. Since the XML has semantic and structural meaning, processing tools can be quickly created to extract information and reuse it elsewhere, thus ennabling the law of unintended consequences.
I feel that this is a compelling vision. I'd love to live in this future. I want it now. Bueller? Bueller? Bueller? :)
A few further comments:
- I think when XHTML is pushed as "semantic", the term's used in a relative sense. That is, well-formed, properly structured XHTML is more semantically useful than HTML 3.2 tag soup cluttered with spacer GIFs, table layouts, etc. I don't think anyone ever claimed that it was as semantically rich as, say, MathML. It's a general-purpose document markup language that encourages separation of presentation from structure. Full XML support in major browsers will widen our options, I guess.
- To be fair, even HTML 3.2 can be "properly structured" in the sense used above - though the technology itself doesn't encourage it, as XHTML/CSS does.
- I'm not sure that browsers having built-in presentation defaults (paragraph spacing, heading sizes, etc.) implies that XHTML "centers around visual presentation". XHTML very generally describes hypertext documents. The same one can be read out, or rendered visually on radically different devices (presumably each with their own defaults). The document doesn't change, as, apart from rogue bits like the I and BR elements, the markup has little to do with presentation of any sort.
Gyrus:
Agreed, XHTML as semantic is a relative term. However, I disagree that XHTML encourages separation of presentation from structure. I will instead claim that the W3C is pushing that separation using XHTML (among various other technologies), and XHTML makes it possible. However, making something possible is *not* the same thing as encouraging it. Speaking of the technology alone, rather than the W3C's position papers, the technology does not really make it any easier to write semantic XHTML+CSS than to write tag soup. Pre-CSS HTML does not make it possible at all. XHTML+CSS does, at least, make it possible. Availability of browsers that do not have presentation defaults for XHTML tags, but instead rely on CSS for *all* presentation, now THAT is encouragement. ;) Imagine a web browser that accepts XHTML, and effectively strips out all tags before presentation -- you are left with, visually, a plain text document. No presentation at all. If you attach a CSS stylesheet to the document, then and only then the browser presents it according to the CSS. At that point, you have XHTML markup that is structural. You have markup that provides semantic meaning, and nothing else. Now you are forced to examine the structure of the document, to see whether or not that structure is accurate and provides value. The presentation is a side issue -- how, given a particular class of user agent, shall I best present this document? is a question that is not relevant to the issue of how much value is imparted by a given type of markup. I believe that XHTML provides little added value as markup. Considered as an XML vocabulary, for purposes of structure, metadata and semantic meaning, XHTML provides little value. Hypertext links are useful. Meta tags are good, but other XML vocabularies better represent the same information. Likewise with the actual document structure -- I'd rather use a special-purpose XML vocabulary that better expresses the semantics of my individual document, if I'm going to the effort of adding semantic markup. Wouldn't you?
On the other hand, considered as the predominantly available means of presenting documents on the web, XHTML rawks. It's widely available, it looks good, there isn't a steep learning curve, and tools are widespread. Note the use of the word "presenting".
And that's my main point. XML either adds value to some degree, or it doesn't. If it adds value, I want to know in what context is that value added? In the case of XHTML, the context, 95+% of the time, is viewing the added presentation abilities, plus the value of working links. I don't get any value at all from the W3C's intent to saddle XHTML with some hand-waving semantic meaning. Alternative user agents do, and so I keep them in mind when I write HTML, and choose markup that works reasonably well for as many cases as I find reasonable for the personal effort.
And, when I can reasonably assume that the intended audience for my web-available documents use browsers that support CSS-styled arbitrary XML, or don't care about the presentation value in the first place (spiders and such), I will very happily switch over to XML, and take part in the semantic web.
I don't think XHTML was ever intended to be an entirely semantic language. If there were no XHTML - just HTML and then XML - the transition to semantic mark-up would never occur. Developers would not chose to create XML documents because they would be excluding the large portion of their audience whose clients do not support XML.
XHTML bridges the gap between HTML and XML. It allows developers to produce documents that are as semantic and 'future proof' as possible without excluding their audience. When the time comes and most clients do support XML, the step up to XML will be less arduous than from HTML.
"By requiring that kind of thought, we are weighing down the author whose effort should really be directed towards writing, not towards typography"
Exactly. I once had a univesity prof who wrote his own textbook. He was free to sprinkle italics and bold and underlines wherever he pleased as he wrote. Unfortunately he knew nothing of typography. The result was a text that was a mess and near impossible to read.
Now what if this professor made an effort to simply indicate which words were titles and which phrases required emphasis, etc. ("semantic markup")? Enter one skilled typographer to create a stylesheet prior to printing. The result is a beautiful volume that conveys precisely what the author intended, but free from his primitive, ad-hoc typography.
1 vote for semantic mark-up. I've done it both ways and semantic wins every time.
# Ryan