Re: Your kung fu is excellent but what about...

I've yet to experience a real-world case where the factoring of concerns with stylesheets even remotely begins to match the way that I'd like to operate. As long as the standard does not address my needs, and there are no concrete plans to actually remove widely-used but deprecated features, I'll feel free to ignore the XHTML nazis.

Conversely when it comes to the old Perl code that you post, my objections to it are not that it is dated, but rather that it sets you up for a variety of problems. (eg You've got missing error checks and have made errors hard to debug, you've made multiple instances of the same field harder to display, you don't get the benefit of typo-checking from strict.pm...)

These benefits make sense to me. But the stylesheets lecture does not. Sure, it separates some presentation from content. But I can get a more flexible separation from using any templating tool - and if I'm going to develop a complex website I have to use the templating tool anyways. Furthermore stylesheets never seem to allow me to divide control in the way that I want to divide it.

Then there is the argument that things like XHTML are the future. Well argument that, You have to use this because it is the future! has always failed to impress me. If it is the future then I'll discover that in the future. But it won't become the future unless it delivers concrete enough benefits that people switch. Until I begin hearing about those benefits and get convinced by them, I'll ignore them.

Call me cynical. But over the years there has never been a shortage of platforms and standards promising to be the future. Most are trivia questions 5 years later. Some achieve modest success. And only a handful transform the world. Transforming the world takes long enough that it is pretty easy to notice and react long before it happens. (Unless you're embedded in a business model where your customers won't let you react, see The Innovator's Dilemma for more on that.)

Disclaimer. I've never has any enthusiasm for this whole "web" thing, and so can't bring myself to feel any passion about "doing it right".

Comment on Re: Your kung fu is excellent but what about...

Replies are listed 'Best First'.
Re^2: Your kung fu is excellent but what about... by wfsp (Abbot) on Dec 12, 2004 at 11:13 UTC
I sympathise with your cynicism and generally agree with your point about the 'next big thing'. I have to admit, though, that I have been seduced by the XHTML fanatics. One reason was the realisation of what w3c actually meant when they darkly refer to 'other devices' and 'alternative presentation'. For many years I was convinced that you only had to worry about screens that were 800 pixels or wider, there being so few screens smaller than that. Was that a mistake! Seeing the web site I help maintain on a 1500px laptop was a bit of a shock too! What's happened to all my lovely gifs? Replaced with xhtml/css2 that's what! Screens are simultaneously getting smaller and bigger very quickly. A bit of the future is already with us. It also dawned on this Neanderthal that another 'other device' was audio browsers and what they do, for instance, with tables. I've long been an advocate of "don't use tables for page layout" but now I'm convinced. For a static site in particular these issues are far easier to deal with using the latest standards. Also, if you're planning to move to dynamically produced pages (as I am) having a compliant site in the first place will make the transition much less painful. One thing that does underline your point is frames. I would cheerfully shoot the person who thought that was a good idea and break the legs of the person who left me with a framed site. Search engines don't like them, they interfere with the back button, links to and from your site can produce 'unexpected behaviour' and you're left with tricky dicky javascript on every page. I'm proposing and campaigning for the frames to be dropped but they've had them for 6 years or so and they are stubborn (you'd get on well with them!). I welcome the attempt to move toward more strict standards. I believe that whatever the future does hold will have less traumatic consequences if these standards are supported and adhered too. I also applaud you intransigence. These things often end up being some sort of fashion parade where the 'label' is all important. Keep up the good work!	[reply]
Re^3: Your kung fu is excellent but what about... by tilly (Archbishop) on Dec 13, 2004 at 16:01 UTC
This is fair enough, but I haven't used frames in many years. (You're right, frames suck.) As for moving to dynamically produced pages, well I have predominately dealt with dynamically produced pages from day 1. (I'm primarily a Perl programmer, I consider web work very secondary.) My comments are made in that context. As far as I'm concerned, the biggest way that dynamic differs from static is that you can automate repetitive stuff in a template. (In fact you pretty much have to.) This gives you design options that static does not. I grant that CSS is designed to display better on very small screens and audio displays. I've never been told that making that work is a business requirement. OTOH in trying to discourage tables for layout, the CSS folks made using tables far more of a PITA than it has any right to be. As far as I'm concerned, I should be able to stick a style on a row and have it apply to the cells in the table. Sorry, it doesn't work that way. Now we can go through the arguments for/against using tables all day long. Let me just say that every few assignments I wind up having to display a tabular report. (Could that be because I'm dealing with data??? And tabular tables are a natural representation of it? Just possibly...) And every time I find that the design of CSS gets in my way.	[reply]
Re^4: Your kung fu is excellent but what about... by Aristotle (Chancellor) on Dec 21, 2004 at 05:58 UTC
As far as I'm concerned, I should be able to stick a style on a row and have it apply to the cells in the table. Sorry, it doesn't work that way. `<style type="text/css">tr.highlight td { font-weight: bold; }</style> <table> <tr class="highlight"><td>This is bold.</td></tr> </table>` [download] Now we can go through the arguments for/against using tables all day long. Let me just say that every few assignments I wind up having to display a tabular report. If anyone is trying to get you not to use tables for displaying tabular data, they don't know what they're talking about. Tables are deprecated as a layout crutch, not when used for their actual purpose. They'd've gone the way of the `font` tag in recent specs if they were inherently evil — except they haven't. Makeshifts last the longest.	[reply] [d/l]
Re^5: Your kung fu is excellent but what about... by tilly (Archbishop) on Dec 21, 2004 at 07:20 UTC
Re^6: Your kung fu is excellent but what about... by Aristotle (Chancellor) on Dec 21, 2004 at 07:34 UTC
Some notes below your chosen depth have not been shown here
Re^4: Your kung fu is excellent but what about... by Anonymous Monk on Dec 13, 2004 at 16:16 UTC
You must have a different definition of "static" vs "dynamic" pages than I have. I've always used "dynamic" for pages that are generated on demand (CGI, mod_perl, whatever), while "static" pages are created in advance (and served for instance from a filesystem or database). I'm a bit puzzled about what you mean by "static pages". From you description, I gather you can use templates when creating a "static page". Which makes me wonder, what in your opinion is a static page?	[reply]
Re^5: Your kung fu is excellent but what about... by tilly (Archbishop) on Dec 13, 2004 at 16:30 UTC
Re^2: Your kung fu is excellent but what about... by hardburn (Abbot) on Dec 13, 2004 at 14:50 UTC
For me, using strict XHTML and stylesheets helps when writing programs to parse the output of a page. While parsing, it's easy to ignore one big `<style>` tag. It's harder to ignore a bunch of `<font>` tags littered throughout the document. Other XHTML additions, like forcing a well-formed tag layout, also help here. Further, adhering to the standards covers you. If I create XHTML-strict/CSS that passes the validator, and the standards quite explicitly say how the given code should render, then any other rendering is a browser bug, and not my fault. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply] [d/l] [select]
Re^3: Your kung fu is excellent but what about... by tilly (Archbishop) on Dec 13, 2004 at 16:25 UTC
You're right that screen scrapers benefit from XHTML. But when I've written the HTML in the first place, I've never seen it be in my interest to encourage screen scraping. Besides which, when I have to screen scrape, I'm generally paranoid enough not to believe that things are XHTML, and I think that anyone else screen scraping probably (should at least) make the same assumption. As for your comment about browser bugs, I'd frankly be astonished to encounter a workplace where you can get away with saying, "My webpage is fine but IE 6 happens to be broken. Complain to Microsoft." As long as IE is the bulk of the market, any website that is broken in IE is going to be considered broken, no matter what the official standards say. Generally speaking, I find that if I develop against Mozilla and then fix occasional breakages with IE, I'll wind up with something that works reasonably well on most major browsers. Running through a basic HTML validator looking for unclosed tags takes care of most of remaining browser differences. By contrast, as many complaints out there attest, producing a sophisticated web page using all of those juicy CSS standards typically results in a website that doesn't render right for most people (who, like it or not (I don't) use IE).	[reply]
Re^4: Your kung fu is excellent but what about... by hardburn (Abbot) on Dec 13, 2004 at 17:38 UTC
I personally want to encourage screen scraping. At the very least, it makes automated testing of web pages possible. Getting management to agree is a different matter . . . I find that if I develop against Mozilla and then fix occasional breakages with IE, I'll wind up with something that works reasonably well . . . I find this true, too. Mostly, my statement was concerned with even more niche browsers than Mozilla (Opera, Konq/Safari). I'm also blessed with a userbase that is around 70% Mozilla (or derivitive) (specifically, our userbase is mostly computer-illerate academics who were told to use Mozilla :). In such an environment, it's easy to tell non-standards-compliant browsers to go fix their bugs and leave me alone. "There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.	[reply]