January 2005 Archives

The Apple UK Anti-CSS Conspiracy

So, I got me one o'them Mac things that people go on about so much.

I like it.

It's not long before I'm tinkering away, installing this and that - Firefox, Thunderbird, a couple of code editors... hold on a minute... Where's the bloody hash?

No, my friends, I do not expect Apple, as liberal and "down with the kids" as they appear to be, to bundle herbal narcotics with their machines, I mean the "#" character. Commonly known as the "pound sign" in the USA, here in the UK we've already got one of those - "£". And "£" is what sits on top of the "3" key on every UK keyboard. I understand that on US keyboards, "#" appears on the "3" key, but here, on any non-Apple keyboard, it gets its very own key. So where do Apple put "#" on their UK keyboards?

Scan keyboard once... can't see it. Scan it again... still can't see it. Carefully work my eyes over each key. It's not there! What am I supposed to do? Write CSS without ID selectors?! This is insane! Where's my hash?! Don't Apple want me to make lovely CSS with their sexy computers? You might as well just omit the "<" character, or even a letter or two. Space bar? Who needs it?!

Now this obviously won't come as news to any Mac savvy chappy, but I had to rely on a friendly detective to reveal that the secret lay in "alt"+"3". Oh, joy of joys, I can write CSS after all.

I'm Ali Baba, "#" is the treasure behind the door and "alt"+"3" is "Open, Sesame!"

Or something.

Monday 31 January, 2005 ( 5:06 PM GMT) | Comments (47) / Permanent Link

More Training

If you can't wait until June to hear me speak for 45 minutes about XHTML and CSS (stop clamouring girls! There's plenty to go around), why not come along to London in March for two lots of seven hours worth of expert insight?

The past few weeks saw me give the first Vivabit public training courses and, well, they were a success. It appears I'm good at this kind of thing. So. Ding ding! Round two.

Tuesday, March 22nd - "XHTML & CSS: A Web Standards Approach" based on the book of the same name (and given by the trainer with the same name as the author of that book. Coincidence?)

Tuesday, March 29th - "Web Accessibility" (must think of a funkier name) - the whats, whys and hows of making your web pages accessible to users with disabilities.

There's a maximum of six people per course. Bookings are like gold dust I tell ya.

Friday 28 January, 2005 ( 4:43 PM GMT) | Comments (suspended) / Permanent Link

Right! It's Time to Buy a Mac

I'm going to take my first foray into the wanktastic world of Apple.

It wasn't a surprise to anyone (even me, and I don't usually give a shit about Macs) when Mr. Jobs recently revealed the Mac Mini - Apple's attempt to turn PC users to the shiny side. OK Mr. Jobs. Let's see what this microscopic little box can do.

In my experience, people who own Macs love Macs. In an almost worrying way. I've never been that excited about a box of switches and seeing as I sit behind one for 25 hours a day, I'd kind of like to be (I think). So in marrying one rather than fooling around with one, I'm hoping to see what all of the fuss is about.

To relate this to the topic of web design and development (which, after all, is what this here blog is supposed to be all about) I should point out that the main reason for getting one of these matchboxes is to adequately test sites on what is an increasingly popular platform (and I think will become even more so now - this is a good business move by Apple). Business has been going well and I think 300 quid is justifiable for a testing machine.

If anyone can offer any advice... Cheaper, slower version or more expensive, faster version? Standard 256Mb memory or upgrade? (Note that's it's going to take a lot of convincing to make me opt for anything other than the most basic setup. I trust Apple aren't going to piss people off by supplying an inadequate amount of memory for OS X) Where's the best place to get it from (in the UK)? Apple Store? And where / what the hell do I get for it (namely word processor, code editor and "cheap" Photoshop etc. etc.)?

Friday 14 January, 2005 (12:32 PM GMT) | Comments (29) / Permanent Link

@media 2005

@media 2005: Web Standards & Accessibility. London, 9th - 10th June Q: What do you get if you cross web standards, accessibility, Jeffrey Zeldman, Joe Clark, Doug Bowman, Andy Budd, Robin Christopherson, Andy Clarke, Jeremy Keith, Ian Lloyd, myself, Britain's capital city and the days of the 9th and 10th of June?

A: @media 2005

Tuesday 11 January, 2005 ( 2:11 PM GMT) | Comments (8) / Permanent Link

T&C's Quandry

What's the best way to mark up an "I agree to the terms and conditions" checkbox?

Here's the obvious way:

	<input type="checkbox" name="agree" id="agree" /><label for="agree">I have read and agree to the <a href="/termsandconditions.html">terms and conditions</a>.</label>

The problem with this, though, is that if the user clicks on the "terms and conditions" link, because it's within a label for the checkbox, the checkbox will be checked. Because of this, it could be argued that the user doesn't agree to the T&C's because they only intended to read them, not to agree with them.

But then the text within that label is the best label for the checkbox. And the obvious place to put a link to the T&C's is within that text.

What to do?

Sunday 9 January, 2005 ( 4:38 PM GMT) | Comments (11) / Permanent Link

Payment Services - Rigid Junk

I'm working on a project that needs to take credit-card payments online. For a short-term, relatively small project such as this, opting for a payment "bureau" service such as those offered by WorldPay or PayPal seems to me to be the obvious choice (I'm coming from a UK-based standpoint - maybe it's different elsewhere). There's no need for your own internet merchant account - they do it all for you - the customer is taken to a secure web page hosted by the payment service provider, they take the customer's money and then they pay it to you, after taking a cut, of course. So, relatively easy to set up and hassle free to administer.

But the big problem I have is when it comes to the payment pages you have to use - the supplied HTML is rigid junk.

"Rigid" because the level of customisation over these pages extends to adding your own image (Oooo!) and even, if you're lucky, selecting your own background colour (Oh monsieur, with these options you are really spoiling us!). Some do actually allow you to apply some form of includes, but the untouchable stuff is still very rigid and, well, junk...

"Junk" because not only are these pages invariably full of font tags and tables used for layout, accessibility considerations are nowhere to be found. Labels? Alt text? Wassat? This isn't really acceptable in any situation, let alone one for a company trying to promote said standards and accessibility initiatives.

What I don't understand is why they can't give more control to the developer - it's not like these are aimed at non-technical consumers - the rest of the seller's website had to be developed in the first place. Why isn't there a simple option whereby you can make your own HTML page and just slot in the necessary form fields with the right names thereby allowing greater control over consistent design, table-free layout, lean HTML and, perhaps more importantly, accessibility considerations? I don't see where the problem would lie for the payment service provider. They can still securely host the payment page, they can even enforce some kind of brand placement or required wording for all I care - all I want is control over the structure of the underlying code.

There are various options that give you more control over things when you get your own internet merchant account (which is easier said than done), with a number of services offering payment "gateways". Unfortunately, these still involve the necessity of using their rigid junk HTML. The ultimate option, and the traditional e-commerce route, does give you complete control over your code, but it involves installing server-side software and collecting and processing the credit card details yourself, which just aint feasible for small-scale projects.

Applying credit-card acceptance to websites from scratch is new to me and, frankly, the options and processes are overwhelming and frequently baffling. One unfortunate conclusion that I seem to have reached however is that small-scale e-commerce and web standards just don't mix.

Tuesday 4 January, 2005 (11:40 AM GMT) | Comments (8) / Permanent Link