If a monk were to post a question about the hot new app he was developing on Bank of America's web team which started, say:

#!/usr/bin/perl open(STDERR,'<&STDOUT'); require 'cgi-lib.pl'; print &PrintHeader; if ( ! &ReadParse(*input) ) { print "Enter your name: <INPUT NAME=name>" } else { print "Your name is ", $input{name} || "Slim Shady"; }

well, you know what the responses would be like. If you don't know, I encourage you to submit such a sample and enjoy a turn on Worst Nodes.

Seriously think about how you might be tempted to jump off on someone if they posted it. Got it pictured? The unedited version before you nice it up a little.

Now consider that the majority of the HTML that appears in replies/samples here is from the cgi-lib era. And consider how much easier it is to get HTML 4.01, or better, XHTML 1.0, right than weak references or inheritance or web security... And consider the counter arguments that might be given if they were given about perl code instead.

It works the way it is so why change it? If they didn't want me to use <hr> or <center>, they shouldn't let it work. But that's how I learned to do it!

(I know that posts often include things like <font> b/c we can't, and shouldn't be allowed to, inline style and that's not what this is about; sample code should be as close to the ideal as we can manage no matter what language it's in b/c people come here to learn and will imitate what they find. And I submit this not as a critique per se but more as a call to action.)

janitored by ybiC: s/node 9488/[Worst Nodes]/

Replies are listed 'Best First'.
Re: Your kung fu is excellent but what about...
by exussum0 (Vicar) on Dec 11, 2004 at 16:56 UTC
    The truth of the matter, is there should prolly be a disclaimer on the entire site, citing that the site provides solutions or less than ideal versions of such. That good programming practice should be adhered to. That questions are at best, on programs where all of the code is given. Most of the time it's not true. You will get things such as sniplets and why this sniplet does or doesn't do what it does. Sometimes it's enough, sometimes it's not.

    Then the posters meet, as they always have done on this site. Someone wants to know something, there's banter and what not. But rarely, is it the validity of the HTML but the functionality in perl, or what have you, they are trying to achieve. If I wished to pick appart everything a person wrote, and what I wrote, and explain why things are done the way they are, I'd sit here for days, and then argue to death with zealots who claim my way is wrong, when it's really not right for them. Or I will make mistakes and mispeel stuff. My American is terrible.

    Anyway, you have the ideal which you present, that we in ernest strive for, then you have the worst nodes, usually bad code or flames.

    But as I use my invalid html to post this, with my unmatched P tag, and you read this post, from start to end, you walk away with something. Either you agree, disagree, learn or are enforced in new ideas, or counter example (via disagreement) or I've stolen 5 minutes of your life on your question, code related or not. It's life. You take the good, you take the the bad, you take them both, and need to sort it out what's what and where it goes in your mental files.

    ----
    Give me strength for today.. I will not talk it away..
    Just for a moment.. It will burn through the clouds.. and shine down on me.

      Hey, the paragraph tags don't need to be closed on HTML 4.01!
Re: Your kung fu is excellent but what about...
by tilly (Archbishop) on Dec 12, 2004 at 06:53 UTC
    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".

      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!

        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.

      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.

        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).

Re: Your kung fu is excellent but what about...
by Anonymous Monk on Dec 13, 2004 at 15:34 UTC
    I don't think stylesheets are one iota better than FONT or CENTER tags. Sure, the world could be a lot better, but it isn't. The vast majority of the sites that use stylesheets use style sheets in such a way that without the stylesheet, the page becomes incomprehensible.

    Really, what's the difference between replacing an h1 header with:

    <p align = "center"><font size = +3 color = "green"> <b>This is a header</b></font>
    and replacing an h1 header with:
    <style> p.woof {text-align: center; font-size: 150%; color: green; font-weight: bold;} </style> <p class = "woof">This is a header
    It still doesn't degrade gracefully.

      The answer is "not a whole lot". But, there is a world of difference between your examples and:

      <style> h1 {text-align: center; font-size: 150%; color: green; font-weight: bold;} </style> ... <h1>This is a header</h1>

      Especially so if your CSS is only linked to with something like

      <link rel='stylesheet' type='text/css' href='/css/site.css'>

      What people are entirely failing to realize about CSS as opposed to FONT/CENTER tags is

      1. The point is to separate style from content
      2. Doing so makes it easier to make site-wide style changes
      3. And, it allows people with visual impairments or other special circumstances to override your style choices in their client.

      radiantmatrix
      require General::Disclaimer;
      s//2fde04abe76c036c9074586c1/; while(m/(.)/g){print substr(' ,JPacehklnorstu',hex($1),1)}

      That has nothing to do with CSS and everything to do with the designer behind that stylesheet being unable to comprehend how content differs from presentation. The difference is that without CSS, you cannot even begin to make that distinction in a suitable fashion.

      Makeshifts last the longest.