I wrote a YUI 3 primer for SitePoint, check it out and let me know what you think! ★
Posts Tagged ‘Articles’
YUI 3: Lighter, Faster, Easier to Use
Friday, June 19th, 2009My Interview of John Resig (Creator of jQuery) for SitePoint
Friday, December 5th, 2008My interview of John Resig for SitePoint just went online. Go check it out, leave a comment and spread the word. :-)★
HTML or XHTML: A purist’s dilemma
Tuesday, November 22nd, 2005Whenever possible, I like to do things the right way. Proper implementation of anything—though it may take more effort initially—returns dividends in the form of higher performance, reliability, scalability, re-usability, and so on and so forth. This principle applies to life in general and isn’t limited to web development (read: Tacoma Narrows Bridge). It is however at the core of this article and the focus of the issue I am wrestling with.
For some time now, I was under the impression that XHTML was simply “better HTML,” due to its inherent well formedness—what with it being written in XML and all. But it seems I was mistaken (and I’m willing to admit it). Recently I’ve been reading articles by Anne van Kesteren, and it’s gotten me wondering if I didn’t just jump on the XHTML bandwagon without even asking myself that one all-important question: “Do I really need this?” Had I taken the time to explore the issue a little, I would have found out that in order to deliver XHTML to a client properly, I should be doing it via the application/xhtml+xml MIME type. Currently my documents are delivered as text/html, so all I have to do is change the MIME type right? Not really. While Firefox supports it, IE doesn’t. A document delivered to IE using the application/xhtml+xml MIME type causes the browser to display a download window as it doesn’t support it as a known document format. I could rig my web server to deliver the document in text/html for IE, but then I’d have to ask myself: “Is the effort worth it?” In other words, what advantage would XHTML bring me for the effort I’d have to expend in properly implementing it? Not to mention the fact that it would still be delivered in the incorrect MIME type in IE. The answer unfortunately is: none. Though there really aren’t any major semantic differences between HTML and XHTML, I’d really only need to use the latter if I had to extend HTML with MathML or some other custom markup languages. For more on this, read Anne’s post entitled: “MIME types matter; DOCTYPEs don’t“
Now, some of you may be thinking “big deal, it still validates as XHTML even if the MIME type says it’s HTML and not XHTML.” Well, that would be a bad assumption to make since according to the W3C HTML WG Chair Steve Pemberton, …documents served as text/html should be treated as HTML and not as XHTML.
This means that even though I work very hard at writing properly formed XHTML, in reality what I’ve been doing is exactly what I’ve been trying hard to avoid: I’ve been writing tag soup! That’s right, since in essence I’ve been delivering HTML documents using mal-formed HTML.
My dilemma is the following: Do I switch to HTML 4.01 and get used to uppercase tags that don’t self-close? Do I stay with XHTML 1.0 Strict and keep delivering it with the incorrect MIME type? Do I rig Apache to deliver my XHTML with the application/xhtml+xml MIME type and abandon visitors with older browsers (like IE 6). Or do I find a happy medium that delivers application/xhtml+xml to conforming browsers and text/html to everyone else?
What do you think?
Related Reading
- XHTML advocates considered erroneous by Anne van Kesteren
- MIME types matter; DOCTYPEs don’t by Anne van Kesteren
- Why MIME types are not like handing someone a cup of coffee saying it’s hot chocolate by Anne van Kesteren
- Well-Formed by Anne van Kesteren
- Markover: limpid.nl by Anne van Kesteren
- XHTML is invalid HTML by Anne van Kesteren
- Re: Sniffing XHTML sent as text/html by Steven Pemberton
- xhtml v. html: a tiresome debate by Molly E. Holzschlag ★
The Case for Semantics
Thursday, October 20th, 2005Communication, a wonderful tool that enables us to accomplish so much in our daily lives. Yet it’s up there with breathing and electricity as something we take completely for granted. Take speech for example. We communicate via speech by giving meaning to the sounds that we are able to make with our mouths. Each distinct sound is assigned a letter, the sum total of which constitutes our alphabet. We then take these letters and combine them to create words. Those words then are further combined to create sentences which in turn combine to make paragraphs and so on and so forth.
We use words to convey meaning. If the words that we used didn’t sufficiently convey the thoughts that we wanted to express, there would be little reason for us to use them. We’d simply be making noise.
The reason we are able to do this is because somewhere along the way, a group of us agreed to assign a particular letter to a particular sound. Then we grouped those letters and agreed on meanings for them and called them words. Different groups agreed on different letters and different words, which are of course the different languages we have today. (Some of us believe in the Tower of Babel story but that falls outside the scope of this post). But, regardless of choice of language, what’s key is our collective agreement which allows us to communicate complex thoughts and emotions. Without which we’d be reduced to grunting, flailing, disorganized and highly frustrated people.
Semantics is a subfield of linguistics that is traditionally defined as the study of meaning of (parts of) words, phrases, sentences, and texts.
As you are no doubt aware—after all you are reading this online—communication has progressed quite a way beyond simple analog speech. Today we are able to not only speak with others around the planet in real-time, we are also able to transmit volumes of text, images, sounds and video via technologies such as the internet. Just as it was essential to assign meaning to spoken words, so it is the case now with the languages we use on the internet. One of the oldest and most fundamental of which is the HyperText Markup Language, used in the creation of web pages.
When one creates a web page, they do so to share information. But that information can quickly become confusing if not expressed correctly. I’ll use an example from our daily speech to illustrate. Say I want you to get me a can of soda from the refrigerator in the garage. Would you know what I meant if I asked: “can you get me a thing from the thing in the thing?” You would more than likely not know what I meant. That’s because I wasn’t using the correct words to convey the proper meaning of my request. In the context of HTML this principle holds just as true. Headings, lists, paragraphs, tables and other such markup transforms plain, relatively meaningless text into meaningful content.
Often times however, it’s the misuse of this very same markup which is responsible for the mangling of meaning on the internet. For example, because browsers render heading texts of increasing dept in smaller and smaller font sizes, some have taken to using headings representing two or three levels of depth in order to render their text in a particular font size when their text isn’t even a heading! Still others use the convenient grid pattern of tables to lay out their content thus expressing that their page contains tabular data when there isn’t any. Such abuses are rife throughout the internet and should be avoided at all costs if we want people to understand what we are communicating. Otherwise, though the content we see online may seem—at least visually—legible, it is in fact an unintelligible, garbled mess that is of no lasting use.
It may sound harsh of me to say that badly marked up content is of no lasting use but it’s the truth. When a page is visually legible yet improperly marked up, it’s very difficult to maintain and software is unable to understand it. If it’s not understandable by a computer, it can’t be properly indexed by search engines, correctly understood by screen readers, reused as a data source for other applications and put to use in future applications not yet conceived. It may as well be an image because it has about as much semantic meaning.★