Posts tagged html
Wanting to understand the web
May 13th
Numerous people who are better at keeping on top of things than I am have already talked about how good Ben Ward’s “Understand the Web” is, but I’m not going to let that stop me joining the chorus. With so much being thrown around about which proprietary vendor is more open, and what extra tool could be considered part of the HTML5 crowd, it’s good to see someone working to get to the core of what the web really is and working from there.
Want to know if your ‘HTML application’ is part of the web? Link me into it. Not just link me to it; link me into it. Not just to the black-box frontpage. Link me to a piece of content. Show me that it can be crawled, show me that we can draw strands of silk between the resources presented in your app. That is the web: The beautiful interconnection of navigable content. If your website locks content away in a container, outside the reach of hyperlinks, you’re not building any kind of ‘web’ app. You’re doing something else.
…
Cross-platform user interface sucks. It’s a nightmare of inconsistency and wrong, momentarily obsoleted assumptions. But cross-platform content? Well that is content. It’s articles and poems and pictures and movies and music, everywhere! How brilliant is that!
Book Review: Refactoring HTML
May 23rd
Despite years of progress by web standards advocates, and a significant improvement in the quality of the HTML on the web, many of us still end up grappling with outmoded, broken HTML on a regular basis. When confronted with a large site filled with broken pages it can be hard to know where to start. Elliotte Rusty Harold’s Refactoring HTML offers a step by step recipe book for migrating such sites to clean, semantic code.
Harold’s is a well known name in the XML world, and that background shows through in how he approaches the book. While a general audience will probably find useful content, the reader needs to be prepared for a series of command-line and Java-based examples. Tools like tidy are featured prominently, as is the use of regular expressions to seek out broken code to fix and, in the music-to-my-ears category, automated testing.
If you’re equipped to do so, following these steps will lead to much cleaner, more manageable sites, but I found myself wondering how many of those comfortable with command line tools and regular expressions are in the market for a book like this.
In general I suspect the key audience for this will be IT departments inside large organisations tasked with refreshing or extending an intranet. For those developers, who maybe don’t spend much of their time working with HTML and like the idea of using scripting tools similar to those in their regular workflow, this book’s worth a look. If you’re already familiar with current trends in web development, then there are probably other ways of picking up on the scattering of techniques that might be new to you.
Disclaimer: I was sent a copy of this book for review by the publisher. You can find it at amazon US, amazon UK and all sorts of other places.
Project Launch: New Greenbelt website
Apr 13th
One of the numerous projects I’ve been juggling over the past few months has been a redesign of the Greenbelt Festival website. That redesign went live late last night.
Working from Wilf‘s designs I initially built new HTML and CSS templates and began to establish some rules for how we’d handle the new image management requirements for a site that is now very photo-heavy. When it came time to apply the new designs to the CMS, however, it became apparent that there was a much bigger job ahead.
That CMS (a bundle of custom PHP that I had inherited) has grown over time and within some quite onerous server configuration constraints to a point where it was due a significant overhaul. Sticking with PHP was a fixed requirement as we’re relying on various APIs and a server architecture that wouldn’t be happy with me shifting to, say, rails, but already having the problem domain mapped out and the opportunity to radically simplify a few things meant I got to enjoy the feeling of stripping out a lot of code without impairing functionality.
One note that Derek Sivers made in his controversial blog entry last year about switching from Rails to PHP was that working with Rails had made him a better PHP developer. I’ve found a similar effect. I have no intention of leaving the world of Rails (I still prefer it by orders of magnitude), but tackling projects like this in PHP are a reminder that working for a while with really good tools is likely to encourage you to seek out best practice in whatever environment you end up in.
Ruby developers who occasionally work on PHP projects as I do may be interested to note that we are using capistrano for deployment, and I intend to use rspec for some testing. I’ll try to write that up once it’s in place.
With a refreshed CMS, new templates, and some standardisation of our many javascript files on top of a jquery foundation, Paul, Greenbelt’s was able to manage the photos and copy to turn that new look into a vibrant and content-rich new site. You can see a few notes he wrote about the redesign on the site.
There’s still a fair way to go. I’ve got a lot of tests to write in order to make it easier for us to make further changes, and various aspects of the site are more than ready for a more fundamental rethink that will let the festival open up its archives better, but all concerned are very pleased to present the fruit of our labours.
Book Review: Drupal 5 Themes
Feb 5th
Aimed at those with a knowledge of HTML and CSS but with no prior experience of programming, Drupal 5 Themes sets out to show you how you can quickly and easily get a drupal site up and running with a highly customised look and feel.
Drupal is highly themeable, with most aspects of the user interface being accessible purely in the theme layer without needing to dip into module development or the CMS’ core. The book takes the user through the various theme hooks and introduces the simple PHP code needed to override them, add new ‘regions’ (in which blocks can be displayed), customise existing themes and create your own (almost) from scratch. The primary focus is on the default theme engine, PHPTemplate, but others are referenced and a little time is spent on the options for building your own theme using raw PHP (without the extra layer of a theme engine).
For the most part the content is straightforward, and the reader should quickly get a feel for the naming conventions that drive the PHPTemplate approach. While not much programming knowledge is needed, it would be helpful for the reader to have a basic grasp of PHP and introductory programming constructs such as loops and conditionals. I was also surprised to find recommendations to name functions phptemplate_* within theme-specific template.php files, where they could instead be prefixed with the theme’s name rather than ‘phptemplate’. PHP’s not fond of functions that share names within the same context, and it is best to give those functions the most specific name available to you in order to avoid errors.
Given the fact that only HTML and CSS are listed as pre-requisites I was a little surprised that the PHP code wasn’t introduced in a more focussed section. Given its simplicity it’s to be hoped that anyone intending to spend much time building drupal sites would be able to figure it out, but while time is spent picking apart example code little time is spent actually giving a conceptual introduction or, for that matter, on explaining how to install drupal in the first place. Surprisingly, space was given to explaining how cascades work in CSS, which you would think is a fundamental part of a knowledge of CSS and unnecessary in this context.
This is the second book in a row that Packt has sent me for review where it has seemed that reference material is scattered too freely amongst the tutorial-style chapters. Significant chunks of space are given over to listing off functions, the locations of stylesheets, and so on, which is useful information but breaks up the flow of the book unhelpfully. It’s surprising that that content wasn’t moved to an appendix or, as with their jQuery books, a separate volume. Sitting in the middle of the book it feels like unnecessary filler (just one or two examples would do, along with a reference to an appendix, other volume, or online source) and the space could helpfully be given to more detailed tutorial material. That coupled with poor print quality and light paper stock (both also an issue with that previous book) gives the book a lightweight feel and reinforce its weaknesses.
This book should get an HTML/CSS developer who’s not afraid to dip their toes into some PHP up to speed with customising a drupal site, and its worth considering if you’ve been mostly building static sites or customising wordpress and need a content management system with a wider range of features. Unfortunately it’s still fairly weak structurally, and you may well find yourself needing to combine it with quite a bit of online documentation to properly cover the topics under discussion.
Disclaimer: I was sent a copy of this book for review by the publisher. You can find it at packt publishing, amazon US, amazon UK and all sorts of other places.
The fury that Microsoft have unleashed
Jan 24th
Such has been the flood of information since Aaron Gustafson broke the news of Microsoft’s radical new plans for Internet Explorer that I’ve mostly sat back and tried to absorb it all, waiting before contributing anything.
For those who haven’t been following the developments, Microsoft have said that future versions of Internet Explorer will support a new HTTP header and/or meta-tag which will indicate to the browser which version of IE the page is designed for. Unless the page specifies otherwise, all future versions of Internet Explorer will render it just like IE7 would. If you want IE8 to actually use the new features it brings with it, such as (we hope) improved standards support, you will need to explicitly ask it to do so.
There’s been a lot of response and people have fairly quickly become quite polarised. David Emery has a good list but a few I particularly noted were:
Eric Meyer and Jeffrey Zeldman explaining their support, Jeremy Keith suggesting that at the very least this is the wrong way round (the default should be the latest and greatest rendering engine), Drew McLellan (Web Standards Group Lead) pointing out that while members of the WaSP Microsoft Task Force had been involved in the initiative, this is not (currently) a WaSP-endorsed idea, comments from Ian Hickson,
and Sam Ruby and his commenting crowd considering the technical implications.
Reading all the debate it can be hard to separate feelings about this specific idea from a basic resentment against Microsoft that is harboured by most web developers I know. The failure of Internet Explorer to keep up with web standards has cost many of us, in aggregate, months of work, and our clients lots of money. The time we’ve spent supporting broken browsers could have been time spent improving the user experience or developing exciting new uses for the web. It feels very much as if the only way Microsoft can see to fix the mess they’ve created with their lacklustre browsers (and some very poor authoring tools) is to throw us a new type of confusion.
Regardless of it being Microsoft, though, even after reading all the debate I can’t help but feel that this is a very bad idea. Even if we get to the day that Internet Explorer 11 dominates and IE10 is the only other version used by a significant number of users, this would mean there would still be sites out there that are coded not to older standards than we may be used to, but to one of three or four older rendering engine and their unique set of bugs. That’s too much information for anyone to handle.
And then, of course, there’s the question of other web browsers. Sure, we can add a note that a site is designed for “safari 3, firefox 2.0, IE7 and Opera 9″, but that’s not a complete list even now. And we’re already seeing an explosion in the number of mobile devices, app-specific browsers, screen scrapers and other means of accessing the web. I find it hard to see this as anything other than a short-sighted form of browser lock-in.
So what should we do? Clearly the standards process is moving slowly and it’s taking browser developers several generations of their software to fully support the standards we do have. There’s already a lot of discussion of what should happen to the standards process to change that, but in the meantime I quite like the line of thought in David’s blog entry mentioned above suggesting we should have a way to test for support of various CSS properties. I’m not sure about the precise implementation details, but object detection got us a long way when we wanted to escape browser sniffing before, and maybe that’s still a fruitful line of enquiry?