James Wilding's Weblog

Tag: html

March 5, 2010

Hello HTML5

HTML has just reached a major milestone with the publication of six working drafts of the markup language’s specification (via).

Despite being technical documents, these specs also make for interesting reading if you’re at all curious about the evolution of the web’s mother tongue. A great place to start is the history of HTML in the main HTML5 spec: there’s some detail here about how HTML5 came to be, as well as some brief information about the aborted XHTML2 effort. This section helps you understand why HTML5 exists at all.

Next, you’ll want to know what elements are available for HTML5 authors: for this, start with “The elements of HTML” (again, in the main spec). This section lists HTML5′s tags and explains how to use them; new tags such as section, nav, article, and aside are covered here.

As a web developer, you’re going to be writing HTML5, so also read “The HTML syntax” for more detail on how HTML5 documents should be structured. The section called “Writing HTML documents” is especially useful, and includes information on the doctype (previously important but now “a mostly useless, but required, header”).

If you’re put off by technical language, be reassured that the spec makes an effort to be readable by humans too: after the spec for doctype syntax, for example, we get this summary:

In other words, <!DOCTYPE HTML>, case-insensitively

Despite all the HTML5 websites out there, I think it’s really important for developers to go to the source and read the original spec: it’s surprisingly accessible, and even glancing at it will help you understand where HTML5 is coming from.

comments closed
August 14, 2009

How to write better CSS

Well-written CSS is easier to read, easier to maintain, and generally less of a headache. But the key to better CSS isn’t in brackets and line breaks: it’s actually all about the HTML.

(more…)

2 comments
August 7, 2009

Bowline: Desktop Apps with Ruby

Bowline is a Ruby GUI framework that allows you to build desktop applications using Ruby, HTML, CSS, and JQuery. Sounds interesting? I thought so too!

(more…)

comments closed
June 16, 2009

Unsung heros of HTML

I’ve just bought and read HTML & XHTML Pocket Reference. It’s a useful book that’s taught me a few new HTML tags (and I thought I knew them all!).

Whatever you think of semantic HTML, these are essential for any die-hard web geek ;-)

<samp>...</samp>

Sample output from programs and scripts. I’d use this rather than <code> (or within <code> tags) to indicate that the content was an example output of, say, a ruby script.

$ ruby random_password.rb # => <samp>mSeq15H3j8</samp>

<dfn>...</dfn>

Use to indicate the defining instance of the enclosed term (probably the first time you use a special name or acronym):

…The British Broadcasting Corporation (<dfn>BBC</dfn>)…

<button>...</button>

Replaces your boring old form submit button with something classier, using an image:

<button name="submit" id="submit">
<img src="images/submit_button.png" />
</button>

<base />

Use in a document’s <head> to define the base path for all relative URLs in the document. This could be useful if you’re writing a blog, want all your links to start with articles, and are lazy:

<html>
<head>
<base href=”/articles/” />
</head>
<body>
<!– links to /articles/how-to-make-millions –>
<a href=”how-to-make-millions”>read this</a>
</body>
</html>

Lastly, did you know that the <address> tag isn’t meant to be used for any just address? I didn’t. It’s actually intended for marking up the address of the author of an HTML document. I wonder how many people follow that convention :-)

2 comments
June 5, 2009

Pragmatism & Bad Markup

I’ve been reading a lot recently about semantic markup: when to use it, why to use it, whether to use it at all. For many people, semantics in HTML is a holy cow — no matter what, the argument goes, you should never shirk your responsibility to use markup that adds meaning to your content.

This is something I broadly agree with, but: sometimes it’s OK to use ‘bad’ markup. If you’re just creating something for your own private use, or are prototyping some HTML that you’re going to flesh out later, then the semantics of what you’re writing really don’t matter. As long as you can come back later and use ‘better’ markup when it matters, it’s OK.

Note the ‘can’ in my last sentence. You need to know that you’re going to be able to replace your tag soup with something beautiful at a later date, before it matters; otherwise you’re creating a code debt that you won’t be able to replay. It’s like the difference between borrowing a little money which you can afford to pay back later, and borrowing too much.

So when does ‘bad’ code start to matter? For me, the answer to this question comes in two parts. First, bad code starts to matter when the code becomes a problem for your users — when it starts causing accessibility issues, for instance. Second, when bad code starts to create problems for you — maintenance problems for instance, or problems understanding your past intentions — then the code matters. This is when you should stop, and rewrite.

HTML is an easy language to learn, and a difficult one to master. Like Ruby, it gives you more than one way of doing things; this is both a blessing and a curse. Because HTML allows you to markup code ‘wrongly’, we should always be careful to manage our code debts and learn to respect our own limits. A little borrowing against future effort it OK; an unmanageable debt of badly written, meaningless code is not.

1 comment