Wednesday Aug 29, 2007

Front-End Quiz Part 7, Doctypes


Which HTML doctype is best?

  1. HTML 3 or lower, or just don't use a doctype.

    \*Shudder\* With an ancient or missing doctype, your web page will be rendered in quirks mode, making proper CSS design more buggy and difficult.

  2. HTML 4.01

    My personal choice. As of 2007, HTML is still a perfectly current, valid standard, and is extremely well-supported and well-understood on the web.

  3. XHTML 1.0 or 1.1

    There are actually some problems with XHTML. As of 2007, try to serve true XHTML, and your website will probably fail for lack of visitors, simply because Internet Explorer (IE) currently doesn't support it. Many sites these days claim to be built in XHTML, but most fail the validator, and almost all are served as text/html to support IE, causing them to be understood by all browsers as nothing more than syntactically weird-looking HTML. In other words, it is HTML in all but name. As a best case scenario, let's assume that on September 2008 IE 8 will ship with true XHTML support. That means XHTML won't be a feasible option for websites until the last users of Internet Explorer 7 (released 2006) finally upgrade. In other words, extremely optimistically, it will be, say, 2010 or later before true XHTML is a viable option. Until then, why fake it? All of that said, there are some good reasons to use today's faux brand of XHTML. Most commonly, content might need to be treated as XML on the server-side, even if it's served as text/html to the client. This is where I think XHTML shines today.


Wednesday Aug 22, 2007

Front-End Quiz Part 6, Separating Content, Behavior, Presentation


Where/how is content best separated from behavior and presentation?

  1. On the client-side, using semantic HTML plus external JS and CSS files.

    This is where I set up camp. Server-side methods exist for separating content, presentation and behavior, but they have different ideas of what "presentation" and "behavior" mean. In terms of separating out the visual presentation and client behavior layer, CSS and unobtrusive JavaScript should be the first line of defense.

  2. On the server-side, using features of your rendering framework/MVC architecture.

    If, by "presention" you simply mean HTML code, and by "content" you mean information stored in the application, and by "behavior" you mean controller logic, then yes. On the other hand, if you're coding font tags, layout tables, spacer images, onclick="" and onload="" attributes directly into your JSPs or page renderers, then I think that's a serious red flag. With CSS handling the visual details and unobtrusive JavaScript handling client interactivity, your web renderer is free to focus on saying "now a heading," "now a list," "now a submit element," etc.


Wednesday Aug 08, 2007

Front-End Quiz Part 4, CLASS and ID attributes


What are the purposes of the class and id attributes?

  1. Presentational hints for CSS, for example <span class="green"> and <div id="leftcolumn">.

    Not a very good approach, IMO. This is the classic mistake of mixing content and presentation. For example, if you want to switch to "orange" instead of "green," then your CSS will have to change from span.green{color:green} to span.green{color:orange}, which is, well... weird.

  2. General-purpose semantic hints, for example <p class="warning"> and <div id="nav">.

    I overwhelmingly prefer this approach. This allows the utmost flexibility in evolving the presentation and behavior layers independently of the content, plus it has a self-documenting effect on the HTML source code.

  3. To replace outmoded HTML tags, for example <div class="heading"> instead of <h1>.

    Run away! Run away! I hesitate to say that any one development approach is evil, but this comes close. HTML elements such as <h1> have a structural meaning used by search indexers and user agents of all kinds. Breaking away from all but ultra-generic generic <div> and <span> tags breaks searchability and accessibility, as well as the ability to meaningfully syndicate your content via RSS or Atom. It prevents use of your content in ways that you don't anticipate, and in contexts that you might not have considered.


Wednesday Jul 18, 2007

Test your Knowledge about Front-End Web Architecture

Here are some questions about front-end web architecture to test your knowledge of the craft. Sometimes the answers are fuzzy, so I'll throw out a few possible answers in quiz form, and then give my opinion about what I think the correct answers are and what my reasoning is. Feel free to disagree!


What is the underlying philosophy of CSS?

  1. To distill out the presentation layer so the markup can focus on content.

    As I see it, this is the underlying philosophy of CSS. With CSS managing the details of the presentation, HTML can shed the presentational encrustation it developed during the browser wars, making it more concise and powerful. There's a term for this: Plain Old Semantic HTML, or POSH for short. POSH is easy to produce, maintain, style and script against.

  2. Because HTML turned out to be a horrible presentation language.

    Yes, but I'd clarify this one thing: HTML wasn't supposed to be a visual formatting language in the first place. In fact, the world's first web browser, which Tim Berners-Lee wrote in 1991, actually used stylesheets for the specific purpose of handling presentation. Subsequently, HTML got hacked into the role of handling the presentation during the tumultuous early evolution of the web.

  3. To give visual designers better control over a website's look and feel.

    I would somewhat disagree with this for a couple of reasons. A) CSS was meant to control presentation in more than just visual media. For example it can control Aural and Braille presentations. The visual (screen) medium just happens to be the most widely-adopted way of using CSS. B) CSS doesn't necessarily give better control, so much as a better means of control. For better control, we'll have to wait for future versions of CSS to be finalized by the W3C and implemented by browsers.

  4. So visual designers wouldn't have to muck around with HTML.

    I would disagree with this. In my experience, if a visual designer is writing CSS, they must understand HTML on a very deep level, and will almost certainly have to muck with the HTML. If, on the other hand, a visual designer is just designing in Photoshop and handing off bitmap comps to front-enders, then CSS is irrelevant to the visual designer anyway.


Thursday Jan 18, 2007

HTML class attributes aren't just for CSS

HTML's class attribute was meant to be used in several ways, not just as a CSS tie-in. According to the HTML spec, class attributes are a general-purpose semantic hint. Here's an example of such a usage:

<div class="calendar">

There are at least three ways classes are useful outside the CSS context:

  1. They make HTML structurally self-documenting. HTML is fairly generic. Classes allow you to specify the meaning of various parts of your document, making it easier for yourself and others to unravel its meaning in the future.

  2. They serve as triggers for unobtrusive JavaScript. Now that hard-coded event attributes are dying off, class attributes allow JavaScript to dynamically select and operate on various parts of the document.

  3. Classes are a key part of microformats, which allow online tools to extract meaning from HTML code. Being plain old snippets of HTML, microformats are readable by humans using browsers. But because they're built in a standardized way, they can also be understood by software.

Tuesday Jan 02, 2007

How this Blog Design was Created

I decided to go the total web-standards-nerd route in creating this blog design. Semantic HTML, source-order, accessibility, and unobtrusive JavaScript were all factors from the outset.

The first thing I did was to customize the "Basic" theme. This gave me a starting point. I removed all presentational information, starting with the CSS code. Then I went through the HTML and removed presentational hints. For example, layout tables, <center> tags, &nbsp; characters, etc. Even things like class="left-bar" had to go. "Left" is too presentational, and I relaced it with "sidebar," since it might be argued that "sidebar" is a semantic hint. (Yes, that's how much of a nerd I am.) Fortunately there wasn't much presentation baked into the HTML to start with, because most Roller themes are pretty good about separating content and style.

Next to go was JavaScript. I had just removed the presentational layer, and now it was time to remove the behavioral layer. These layers would be added back in later via external files, once the HTML-only blog was proved working.

Wherever possible, I made the HTML as semantic as possible; selecting and organizing tags elements by meaning and structure. Source-order sensibilities were used, placing more important things higher in the source code. Headings/sections were arranged such that if you removed all but the headings (<h1> - <h6>) you'd get an outline of the page. <p> was used to contain all logical fragments of text. <div> was used to delimit sections. <ul> was used to build lists. It turns out, semantic HTML is really pretty brainless and straightforward, once you yank out presentational noise.

Once the blog was purified, it was boring-looking, but usable. No columns, just black Times New Roman text that strung all the way across the browser screen on a white background, with blue hyperlinks. It was nekkid! Time for some clothes. An empty CSS file was <link>ed to the blog, which I began populating, resulting in the current design.

As you may know, it's easy to do CSS design in Firefox, Opera and Safari, all of which understand and render CSS beautifully. But then you inevitably have to do battle with IE. Most designers approach the IE problem by peppering their CSS file with hacks. Hacks are oddly structured CSS commands that, due to IE bugs, either can't be understood by IE or can only be understood by IE. Instead of doing this, I used conditional comments to load corrective stylesheets into just IE. Conditional comments are an IE-only feature that look like regular HTML <!-- --> comments to real HTML parsers, but have special meaning to IE. This way, I was able to quarantine IE-specific bigfixes to a couple small, IE-specific files.

About

My name is Greg Reimer and I'm a web technologist for the Sun.COM web design team.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today