James Wilding's Weblog » html

Hello HTML5

James — Fri, 05 Mar 2010 13:05:20 +0000

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, , 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.

How to write better CSS

James — Fri, 14 Aug 2009 08:00:10 +0000

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.

CSS what-now?

We all know about Cascading Style Sheets. The W3C calls CSS:

a simple mechanism for adding style (e.g. fonts, colors, spacing) to Web documents.

A nice, clear definition which puts the focus on the important distinction between styles and documents.

Now, you already know not to put styling in your HTML (unless it’s within style attributes): font, link, vlink and other tags which directly styled documents have gone the way of tables-for-layout — keeping these anachronisms out of your markup will help you no end. But more than that, well-structured HTML will help you to write cleaner, more concise CSS.

Let your markup lead the way

A lot of people, when marking up a blog, will do something like this:

[html]

My Cool Blog

Lorum Ipsum

posted by John, 10/8/09

…

[/html]

All well and good (and nicely semantic), but a lot of those classes aren’t actually necessary for CSS: it’s easy to stuff your markup full of classes and IDs, but in many cases the structure of the document itself will allow you to apply style rules just as easily.

Look Ma! No classes!

Try this on for size:

[html]

My Cool Blog

Lorum Ipsum

posted by John, 10/8/09

…

[/html]

Now maybe your CSS brain is screaming ‘NO!’, but this will work just as well when it comes to CSS:

[css]
h1 {
font: 20px helvetica;
}

body > div {
border-top: 1px solid #000;
}

/* article titles */
body > div > h2 {
color: red;
}

/* article meta-data */
body > div > p {
color: #ccc;
}

body > div > div {
/* CSS for article bodies here */
}
[/css]

Maybe not the most attractive blog in the world, but those selectors work! See how we’re using descendant selectors to reflect the structure of our HTML? No need for classes or IDs, and the well-structured markup will give future developers a clue as to the relative importance of information inside the HTML document, too.

In conclusion…

Thinking carefully about the structure of information in your HTML will help your write clear, concise, well-structured markup and CSS. Try it!

Bowline: Desktop Apps with Ruby

James — Fri, 07 Aug 2009 18:13:21 +0000

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!

Bowline works in combination with Titanium, which lets you:

Use Web technologies to create rich applications for Windows, Mac and Linux from a single code base.

I think Bowline looks awesome. Desktop apps using Ruby, WebKit, HTML 5 — all the best stuff if you’re a web development geek like me.

It’s difficult to summarise how Bowline works (although it’s a little like Rails), so I recommend that you read the author’s blog post introducing the framework. Let’s hope Bowline grows into a stable, mature framework that does for desktop apps what Rails has done for the web.

Unsung heros of HTML

James — Tue, 16 Jun 2009 09:49:56 +0000

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 ;-)

`...`

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


$ ruby random_password.rb # => mSeq15H3j8
...
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 (BBC)…

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


Use in a document’s  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:












read this




Lastly, did you know that the 
 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 :-)



Pragmatism & Bad Markup
James — Fri, 05 Jun 2009 17:25:54 +0000
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.