Patrick Griffiths (or PTG) is a London-based freelance webmaker. He is most widely known for his site HTML Dog, an HTML and CSS resource for beginners and experts alike. Patrick has written some highly acclaimed articles including Suckerfish Dropdowns, Sons of Suckerfish and Elastic Design. He also shares his knowledge with the world via his blog - aptly titled "Dog Blog".
- 1. First of all, HTML Dog is an amazingly informative site. How did it come about and what are its aims?
Patrick: The original intention was to create a small project that I could use to show to potential employers what I knew and what I could do.
But then I got carried away and it became much bigger. Now my host is knocking on my door telling me I'm three times over my bandwidth limit.
I came to a few conclusions:
Firstly that most HTML/CSS tutorials out there are poorly written, inadequate and out of date, not to mention completely ignorant of web standards.
Secondly that most resources related to web standards are aimed at the intermediate to advanced web designer. That's probably because it's experienced web makers who really understand the benefits of web standards. But then I don't see why it can't be taught from the outset without making a big deal about it - it's just the way it's done and it's the best way it's done. The thing is, the way of the web standard isn't more difficult than the mad hack fonts 'n' tables method of old, so I don't see the point in learning that antiquated, unreliable model and then learning how to improve on it at a later date.
Web standards needn't be the exclusive domain of advanced developers.
Having said that, HTML Dog isn't just for beginners. The guides are split into beginner, intermediate and advanced levels to hopefully accommodate users of all skill levels. Its overall aim is to be a general resource to (web standard) (X)HTML and CSS. So far I'm pretty happy with it and I'm happy that it's doing well.
- 2. How long did it take to develop?
Patrick: Initially, before launch, probably a couple of months, maybe three, to write the guides, design and develop the thing and do a bit of testing.
It's been continually growing since then with new articles, references and a web log so far. The list of things I want to do with the site grows larger all of the time - it's not 'finished' by any means.
- 3. In February you redesigned the entire site from scratch. Was it hard to implement standards as part of the process. Have you had much user feedback?
Patrick: I'm not sure about hard as such, but I'm quite strict with myself and didn't want to bend any of the 'rules' so some things presented challenges, but then I enjoy challenges.
When I developed the site in the first place I plastered contact forms all over the place because I wanted lots of feedback and I do get a lot of very welcomed comments (although I feel bad about not having the time to respond to them all). All in all people seem to like the redesign.
- 4. Recently, you ditched your AAA compliant rating. Why was that?
Patrick: Because it doesn't adhere to AAA. In my opinion.
I've developed a real problem with accessibility compliance claims recently. There are a lot of problems involved with using WCAG 1.0 for anything more than guidelines. As rules, many of the points are simply too vague or if you were to follow them to the letter (as you should if you claim to follow any standard) then things can even become impossible. I'm not comfortable with bending the guidelines to suit me or adhering to all of the points, many of which are out of date or detrimental to usability or even accessibility. So I've ditched the claim completely.
WCAG 1.0 are great as a guide but not as a strict standard to adhere to and claim compliance with. WCAG 2.0 is only a working draft at the moment, but it looks much more solid and I intend to look into that more deeply in the near future.
- 5. In your opinion, when is it appropriate to use images for text?
Patrick: Rarely. They used to be much more overused than they are nowadays, when web designers didn't have the first clue about CSS and thought that the only way they could achieve a certain result was through images. There's still a lot of that pixel-perfect mentality and sometimes designers will still reach for Photoshop too easily, but as awareness of CSS has increased I am seeing fewer examples of images for every heading level or a big graphical paragraph because a designer wanted it to fit it into a 300px-square table cell.
Compared to functional text, graphical text is not scalable (well, I suppose it could be but it wouldn't look very good) and is obviously much heavier.
Essentially, I believe you can only justify images for text when the text needs to be highly stylised or in branding, when you obviously need a very specific design.
- 6. You have labelled the
<hr>a 'bad tag'. Do you think it has purposes from a semantic point of view - as a divider of content?
Patrick: Semantically, hr is presentational rather than meaningful - both 'horizontal' and 'rule' are purely spatial. So if we want HTML to be meaningful, structured content devoid of presentation (as it's supposed to be), then if this tag were to have a semantic purpose, it should be called something like
From a functional point of view, hr *could* be seen to have a purpose and maybe I'm being a tad pedantic in labelling it a 'bad tag'. But if it does have a place then it's not as a 'horizontal rule'. It's the only tag that is arguably useful but is poorly named and messes with the ethos of separating structure and presentation.
- 7. Tell us about Elastic Design - what is it and how does it work?
Patrick: It's a layout that will expand and contract depending on the user's custom text size settings by using ems and percentages rather than pixels as units.
The idea is that you maintain the proportional dimensions of your design (which could also aid accessibility) and you solve problems such as over-spilling text.
- 8. If a user views an Elastic layout with extremely large font size the layout may extend wider than their viewport. Do you see this as an issue?
Patrick: Yeah. It's the only problem, and one that you need to take into account when employing elastic designs. As a rule of thumb, I would say that if the page works at 800x600 (or 1024x768 depending on what your argument is) in Internet Explorer's largest text size setting then you're going to be largely okay. Of course, one solution is rather than having a fixed width design (fixed in ems), you can have one or more liquid portions.
- 9. Elastic layouts can be too wide for some users, fixed width layouts can be too narrow for others, and liquid layouts can cause extremely long line length in wide viewports. Is there a method that will keep everyone happy?
- 10. You said recently "Building web pages with web standards has one massive advantage - it heightens usability." Could you elaborate on that?
Patrick: Well, it's mainly in the fact that slashing page file sizes, as using web standards tends to have a habit of doing, will mean things load faster.
External CSS also tends to lead to much greater consistency in style and I suppose you could also say that it's more usable for the web designer too because all they have to do to change styles globally is change one file rather than every HTML page.
- Thanks for the interview, Patrick!
- Patrick: No problem. Do I get the job?