John Allsopp is a founder of Westciv, an Australian web software development and training company, which provides some of the best CSS resources and tutorials on the web. Westciv's software and training are used in dozens of countries around the World.
The head developer of a leading cross platform CSS editor, Style Master, John has written on web development issues for numerous web and print publications and was one of the earliest members of the Web Standards Project. He is a tireless Web Standards activist. He shares his thoughts on the web and life at his personal website, Dog or Higher.
John: Well, I think I'll just stick to the Samurai question :-)
When the Web Standards Project kicked off, Style Master had been released, the House of Style was kicking around, and I used to post a fair bit to the CSS Newsgroup.
For some strange reason Jeffrey Zeldman, who was one of the WaSP founders, emailed me asking whether I'd like to be involved. It was flattering, and hard to say no.
Originally, there were seven CSS "experts". So, after the Kurosawa film, Seven Samurai, we became the CSS Samurai. See, everything has its reason, obscure as it might be.
Rather than carp on about how bad these implementations were, we (the "Samurai") did something kind of unusual. We put together a top 10 list of what was missing, or poorly implemented in Netscape, IE and Opera. It wasn't a protest, or point scoring exercise. It was strong but constructive criticism.
The Samurai put together test cases and did extensive browser testing, comparing browser performance with the - at that time still far from well understood - specification.
I honestly think it had a positive impact on CSS support in subsequent browsers.
Since then, while WaSP has been a strong advocate for standards, I don't think it has played that kind of role. It's probably a little more "adversarial" in a way, which reflects the times as much as anything. Back then we were all in it together, there was no real place for agendas. Things have changed a bit since then.
John: People keep me enthusiastic.
Over the years there have been waves of interest and momentum with CSS. When the Web Standards Project started, that was one wave, and certainly another in the last year or two.
Designers, like Doug Bowman and Dave Shea (to name only a couple) who do fantastic things with CSS, people like you and Peter Firminger who get off your butts and get behind the standards with the WSG, and Web Essentials.
And the promise of a standards based web. That keeps me enthusiastic, without a doubt.
John: No. certainly not then. I really thought that a lot of the point of the article was really obvious, and that everyone more or less "got it" and in about 3 months time everyone would say "well derrrr".
Now I see things a little differently. I think the web is a much more radically different medium than I did even then. It is a vast ocean, and we do cling to its shores.
One example of this is web design and development. That's something I know a little about. The point of the Dao article was that the web is a new and different medium, and the old ways of designing, rooted in paper and printing simply don't hold for the web.
At that time people were always talking about "control". That is the designer having control. How to fix font sizes, page sizes, window sizes and so on.
The web is about control, but not the designer's, it is the user's control that is central to the design and philosophy of the web.
This is an extraordinary change in mindset for developers and designers. And one that still has not really taken root.
So, no, I had no idea that people would still find it relevant when I wrote it. But I understand a little more now why.
John: I have many many favourite Simpsons moments. Like when Jessica and Nick... erm, hang on.
OK. Years ago, on the corner of my street there was an Internet Cafe. Well, more like a room full of little cubicles with computers connected to the net. Bondi being backpacker central, and these brave adventurers being the independent souls they were, it was constantly full of people emailing their friends and family back home (where ever that was) about their exciting adventures. Every single day.
Either Maxine (the smarter, better looking part of westciv) or I were reminded of an episode of the other Simpsons, where Fat Tony (the Mafia Capo of Springfield) had a room full of rats he was milking to supply the school cafeteria. Mayor Quimby was outraged, accusing Fat Tony that he had promised to supply "Dog or Higher" quality. The scene of these rats in cubicles brought to mind the backpackers at their computers, and so every time I walk past an internet cafe I think of that scene.
I guess the name also reflects on the way I work, sitting in a room off my bedroom, somewhat like a cubicle, somewhat like one of those rats at times.
So when I came to naming my blog, Sara, who by the time people read this will be my wife, thought for some reason instantly of "dog or higher" and lacking any imagination myself, it stuck.
Plus she always has better ideas than me anyway. My blessing and my curse in life is to be surrounded by women smarter than me.
John: The original "House of Style" we put together over several months in '97 and '98 while we were developing Style Master, learning abut CSS, in theory, and in practice.
It started with a Guide, now fascinatingly called the "Complete CSS Guide", then called "Everything you ever wanted to know about style" (after the amusing Woody Allen film, "Everything you ever wanted to know about sex [but were too afraid to ask]"). There really wasn't a comprehensive complete guide to CSS other than the specification (this was before Eric Meyer's original O'Reilly book). We wrote the FM to FR as Andrei Herasimchuk would say. It's something we hope to do for other web standards in the not too distant future, because Andrei is right, there aren't many FMs to FR.
We also developed our own browser compatibility charts, after we had the idea of incorporating this info into Style Master. As an aside, it was the first time I had ever seen such a thing, but I am sure others had done it earlier. However, imagine a world where someone patented that idea, so no other software could warn you of compatibility problems? See how stupid our patent system can be? So, we decided to also put this info online.
Then we decided that we also needed a good tutorial to go with Style Master, but that it should not be specific to our app, so we ended up with a reasonable good tutorial (Maxine recently rewrote it, and it is now fantastic.)
We developed a "cookbook" of CSS "recipes", little tricks you could use to spice up your site.
So, all of a sudden, we had a few hundred pages of CSS related info, and behold, it became a site in its own right.
Over the years I have, and more recently Maxine has also written quite a few articles, published all over the place, as well as many we simply published ourselves. Many of them are there too.
So, I guess the answer is about 7 years or so. It's been an incremental process, adding things, modifying them, getting rid of the things that aren't relevant any more (but if you want to know about WebTV compatibility for CSS, you can still find it there.)
John: Trying to trick me I see Mr Weakley.
What I think you are asking me is "how come line-height: 1.5 is valid CSS, but that is not true for any other CSS property?" Actually, that's not entirely true, z-index can also take a numerical value.
[As an aside to the casual viewer, this stems from a session at Web Essentials where Dave Shea, during one of his fantastic presentations, pointed out that line-height doesn't need a unit, but said he didn't know why. I made some off hand comment about how it is a multiplier, and unique in CSS like that, so now I'll have to go into some more detail I guess. Should have kept my big mouth shut.]
I am an old coot at the best of times, but when it comes to CSS I am positively prehistoric. My really intimate understanding of CSS stems from the time of CSS1 and CSS2. I may well be the only person foolish enough to have ever implemented any software support for the table selectors of the early drafts of CSS2 (don't ask), or the @font-face statement (we supported both in their entirety in Style Master 2, the last time I ever implement anything in a draft specification).
Back in CSS1, the specification said of line-height
"When a numerical value is specified, the line height is given by the font size of the current element multiplied with the numerical value. This differs from a percentage value in the way it inherits: when a numerical value is specified, child elements will inherit the factor itself, not the resultant value (as is the case with percentage and other units"
So there was a significant difference between values of 120% and 1.2 when it came to line-height.
Specifying a line-height of 120% meant that the computed line-height was inherited by child elements. So, if the parent line-height were 10px, and the line-height value were 120% then each child element would inherit a line height of 12px, and their children would also inherit 12px line heights.
But if you used the numerical value (1.2) then the children would inherit a multiplier value (that is 1.2) and then, their children would inherit this multiplier value. So if an ancestor had a font-size of 1.5em, then it would have an actual line-height of 1.5em x 1.2 that is 1.8em
Now, the current specification (2.1) says
The used value of the property is this number multiplied by the element's font size. The computed value is the same as the specified value.
The computed value of the property is this percentage multiplied by the element's computed font size."
Now who knows whether this really means the same thing or not.
I have too little time to really bother deciphering it. Or maybe old age is catching up with me.
Someone may care to help me out.
John: OK, there are a couple of reasonably interesting things about font-size units and inheritance. We'll start with relative units, particularly em and ex (I still think it is confusing to refer to pixels as relative units. They may be, but in quite a different sense to em and ex.)
For almost every property, when relative units are used, for instance, line-height: 1.2em, then the value is relative to the "computed font size of the current element".
But for font-size itself, it is relative to the computed font-size of the parent element. Which of course makes sense if you think about it. Afterall, you can't set the font-size of an element relative to its size.
Now, percentages are a little different again.
Depending on the property, the percentage may be relative to quite few different things. For instance, with the width property "the percentage is calculated with respect to the width of the generated box's containing block. " For line-height it is the element's computed font-size.
For font-size itself, a percentage is essentially identical to relative values. The computed font-size value of an element is is relative to the "computed font size of the current element".
Hope that is of some value to someone somewhere.
John: You know, I could easily argue either case with reasonable coherence. In a sense they are neither, I guess to some extent they are a necessary evil.
The term "hack" has two different meanings in software, often intertwined.
In a positive sense, a hack is an ingeniously non-intuitive solution to a complex problem.
In the negative sense it means an unstable, short term solution that will become someone else's problem sooner or later. The Y2K problem is a good example of both these meanings in the one solution. Yes, it saved valuable memory. Then it bit us hard years later.
As someone with an engineering background, particularly in software, I tend to avoid hacks. Having written commercial software for over a dozen variations of at least three distinct operating systems, I've learnt the hard way, that things change, and the assumptions you make when using a hack will almost invariably be wrong given enough time. So I tend to avoid them like the plague.
This to some extent limits what we can do commercially with CSS based designs. But not as much as you might think.
John: A solution in search of a problem, though many designers would disagree with me.
Firstly, I think they are based on a fundamental misconception of the idea of separating content from its presentation. I have a little rule of thumb. If it conveys information, it is content. Or even simpler, if you read it, it is content.
Now, we talk about the separation of content and its presentation, how this is a good thing (which I agree with), and how decorative images in HTML are bad because it puts presentation in the content of a document.
But how about image replacement techniques? If you accept my premise that an image with text in it is content ('cause you read it) then you are putting content in your CSS, which surely is at least as bad as putting presentation in your HTML.
But on less philosophical grounds it is bad in a number of practical ways.
1. IR techniques are not accessible. Full stop.
In fact the hoo haa about how they are accessible because they work in some versions of Jaws underscores how little we really grok accessibility. So what if it works perfectly in every screen reader. What about people with other visual disabilities, who simply want to zoom up their text size a bit, or a lot? Tough.
Repeat after me, IR techniques are not accessible.
2. IR techniques are ugly
Now, the real point of IR techniques, as far as I can tell, is to have nicer looking pages.
The font rendering in photoshop. GIMP (or whatever other tool) on which ever platform that the text is rendered on will be different from font renderings on many of the platforms your pages will be viewed on. This gives a dissonance between headings, and the other IR'ed text, and the main text of a page. I think that this dissonance (for example aliased text on many platforms, with anti aliased headings) is simply ugly.
Similarly, an important aspect of page design in proportionality. Yet due to the different default screen resolutions, and to user control by font zooming, while with CSS and text you can maintain font proportionality using say ems, IR based designs won't scale. Your IR based "text" will remain the same size as your actual text increases or decreases in size.
Again, simply ugly.
3. IR techniques make reusing, updating, restyling content much more difficult.
Want new content? Got a spelling mistake? Then you need to create a new image, using precisely the same tools and settings as for the other text rendered as images, then change the HTML (to add an ID if it is new content), and the CSS. That's more work than changing font tags or even inserting IMG elements.
OK, so what's good about IR techniques?
You get to use more fonts, and they look smoother (unless you have a Mac, when font smoothing already works well).
"But my client wants them" you cry. "I must please my client to feed my children."
Your job, amongst other things, is to point out to your client, in the nicest possible way, when they are being moronic. You can put it more nicely than that of course.
John: These days, I, through westciv, do three or four different things when it comes to the web.
So let me cover off each of these in turn.
Style Master is currently in beta testing for version 4. We are improving our existing features, but the key to us is to make CSS more accessible to designers. After all, it is more than anything a designers tool. So probably early next year keep an eye out for Style Master 4 that has quite a few features, indeed a whole way of working with CSS you simply haven't seen before.
We are currently working with a number of really respected people in their fields to expand the range of courses and guides we currently offer.
Andrei Herasimchuk, of Design by Fire fame wrote a great article about the shortcomings of web standards call "I'd RTFM if there were an FM to FR". We aim to be the FMs you FR.
We have held a few workshops over the years. In fact, your viewers may be interested to know that we [Russ and I] met through one of those workshops. It seems a lifetime ago, but it is less than 12 months.
Right now, we are working on doing a series of workshops in Australia, and possibly the US, early next year.
Last, but not at all least, Web Essentials you will agree, was a far greater success than we might have dared hope. I have the sneaking feeling that WE will take up more of our time. But I don't think i can say much more right now :-)
Copyright © Web Standards Group 2012