Stupidity to the power of two



  • Some of you might remember the thread about the city of Tuttle and it's City manager Jerry A. Taylor.
    The story humoured me and couple of my friends for some time. I'm sure you lauhged too if you read it.

    Today in some moment of stupidity i wondered "How good html can a website be, if it's made by an idioit like Jerry Taylor?". Not thinking rationaly, i went to http://www.tuttle-ok.gov and looked up the source-code. It made me literally scream before i laughed uncontrollably for some time.

    If you happen to have some kind of an WYSIWYG editor on your comp, I advice you to paste the code to it just to see the amazing amount of tables.

    Just some fact about the (x?)html:
     - LOTS of tables. LOTS. Haven't seen as many anywhere.
     - No doctype.
     - It seems this guy thinks XHTML ja HTML are the same.
     - Insane names for images ( eg. /vertical/Sites/{136BBA6C-3318-4D9B-8370-02514EF0639E}/images/{1ECF3C12-95A4-4D8D-96CF-66D7AD3CA403}.gif
     - Not a single comment in over 500 lines of code
     - Not a single line indent'ed

    Only one thing to say about this one: "WTF was this guy thinking?!"



  • I'm not suggesting that this site is one to model your career on, but.....

    Some people think the ource of their HTML pages are as important as the source of a Word document.  Word documents are full of undocumented codes, embedded images, no comments, yet they are acceptable.  The author of this website just wanted to put enough effort into it to make it barely work.  There are some major under the hood mistakes, but modern browsers ignore most of those issues anyways.

    So what do you suggest?  Get the site "cleaned up" by a professional for $1000?  Exactly what benefit would that give them?  The site would be more likely to work in oddball browsers, but really nothing else.  Now remember that this site is paid for with taxpayer money.  Would you agree to a small portion of your taxes going to a website cleanup that wouldn't really make any difference?



  • @jsmith said:

    I'm not suggesting that this site is one to model your career on, but.....

    Some people think the ource of their HTML pages are as important as the source of a Word document.  Word documents are full of undocumented codes, embedded images, no comments, yet they are acceptable.  The author of this website just wanted to put enough effort into it to make it barely work.  There are some major under the hood mistakes, but modern browsers ignore most of those issues anyways.

    So what do you suggest?  Get the site "cleaned up" by a professional for $1000?  Exactly what benefit would that give them?  The site would be more likely to work in oddball browsers, but really nothing else.  Now remember that this site is paid for with taxpayer money.  Would you agree to a small portion of your taxes going to a website cleanup that wouldn't really make any difference?



    Yes you are right.
    But my point was something like this: This guy thinks he is good with computers. He claims to have worked with computers for 22 years, and is supposed to be good with them.
    Yes, i know, that doesn't mean that he would know anything about HTML. But with 22years of experience, he would surely know that he isn't good enought at it to do the sites himself. Especially, if it's a site for a whole town.
    Would you prefer to pay few hundred $ for some guy to make you a nice website, or try to make them yourself knowing that htey'll only be bad PR for 1) you and 2) your hometown?


  • Sorry LoeZ, but your point of view is by far too much focused on
    professional contemporary state-of-the-art web design. A few years ago,
    before CSS become useable, table base layout was the most normal thing
    in the world. And while todays web professionals prefer CSS boxes, many
    websites out there are still table-formated. As long as they work, as
    long as every mf browser in the world renders them correctly (because
    tables are, unlike invalid HTML, well-defined), it's almost stupid to
    expect people to change that to CSS boxes, just to make it
    state-of-the-art.

    Thats a benefit for no-one, and it costs money. Where is the ROI? With
    some bad luck, it might even look worse than before (). Only
    nitpickers like you look at the source code as long as the page is
    rendered correctly. HTML code does not require the same quality like,
    say, the source code of an ERP system.



    (
    )

    Some time ago, I've made a website for the sister of my wife. Because
    I'm not experienced with CSS boxes, all layout was made with tables,
    and, well, it worked perfectly with Firefox,  IE, Konqueror, Opera
    and Safari. Than she hired some guys to do search engine optimization;
    for them this mostly means embedding lots of keywords in hidden areas.
    Anyways, along the way, the changed a part of the layout to CSS boxes.
    Now it doesn't work perfectly anymore. It's only a minor difference,
    she probably didn't notice it, but it made me unhappy anyway.



  • >>Not a single comment in over 500 lines of code

    farbeit from me to defend this guy, but he wrote the site in asp, so maybe he used ASP comments.  They are not normally output with the HTML.  It saves bandwidth.



  • @jsmith said:

    So what do you suggest?  Get the site "cleaned up" by a professional for $1000?  Exactly what benefit would that give them?  The site would be more likely to work in oddball browsers, but really nothing else.  Now remember that this site is paid for with taxpayer money.  Would you agree to a small portion of your taxes going to a website cleanup that wouldn't really make any difference?


    Depends.  How well does the site currently work with accessibility technologies like screen readers?  If it works well enough, then yes, no point cleaning it up.  If it doesn't work, then they'd better pay out that $1000 before the first lawsuit hits...

    BTW, it appears this website was created by a special government CMS called GovOffice which prides itself on being usable without any programming knowledge.  I doubt the city manager has so much as looked at the source code.  And that basically explains all the WTFs described - "it's not a WTF because this is generated code!"



  • Anyone else notice the "Powered by GovOffice" link at the bottom of the page?
    I did. It seems that GovOffice is a content creation/management system designed for Government websites.


    Looking at the "featured sites" on the GovOffice page, it seems that GovOffice is responsible for at least some of the problems with tuttle-ok.gov, such as the lack of indents or comments and the GUIDs in pathnames.

    Can we give GovOffice a WTF award?



  • the real WTF is that the site uses comic sans serif



  • @jsmith said:

    So what do you suggest?  Get the site
    "cleaned up" by a professional for $1000?  Exactly what benefit
    would that give them?  The site would be more likely to work in
    oddball browsers, but really nothing else.  Now remember that this
    site is paid for with taxpayer money.  Would you agree to a small
    portion of your taxes going to a website cleanup that wouldn't really
    make any difference?





    Actually, it would make a difference, first and foremost for whoever
    pays the bandwidth. The kind of layout created by certain "smart" HTML
    editors - with tables within tables within tables... - is incredibly
    bloated. As much as 75% can be useless overhead. Second, such a layout
    is likely to render incorrectly at least in one mainstream browser,
    even if the markup is technically valid, either because of a genuine
    bug, or because the browser in question tries to be compatible with
    some older browser. Or indeed, because the editor caters to a particular buggy browser (he he).



    Third, though it's been brought up already, think of the blind people who might want to access such a site...




  • @felix said:





    Actually, it would make a difference, first and foremost for whoever
    pays the bandwidth. The kind of layout created by certain "smart" HTML
    editors - with tables within tables within tables... - is incredibly
    bloated. As much as 75% can be useless overhead. Second, such a layout
    is likely to render incorrectly at least in one mainstream browser,
    even if the markup is technically valid, either because of a genuine
    bug, or because the browser in question tries to be compatible with
    some older browser. Or indeed, because the editor caters to a particular buggy browser (he he).



    Third, though it's been brought up already, think of the blind people who might want to access such a site...



    In the case of http://www.tuttle-ok.gov, the HTML text doesn't seem too bloated; adding "nice" indention and comments would also make it bigger, wouldn't it? Anyway, bloated HTML can go a a long way before it reaches the size of a few small images.
    Technically valid HTML using tables for layout is IMO by far less likely to break in mainstream browsers than XHTML+CSS.



  • DIE, NESTED TABLES, DIE!



  • @Noam Samuel said:

    DIE, NESTED TABLES, DIE!


    Care to tell us why? What is so much better about nested boxes?
    Correct me if I'm wrong, but I think it takes 4 nested boxes to make a nice bitmapped border (with rounded corners, shadows and stuff), but only one table.



  • @ammoQ said:

    @Noam Samuel said:
    DIE, NESTED TABLES, DIE!
    Care to tell us why? What is so much better about nested boxes?


    Coder-speak here, and ignoring the flagrant problems with box-model support on current browsers, but...

    A table is for laying out tabular data.  If your data is tabular, by all means use a table.  It's not, however, terribly common to find tabular data that contains other tabular data (when was the last time you saw a spreadsheet with another spreadsheet embedded in one cell and didn't summarily execute the person responsible?)

    The box model is for splitting up data based on its meaning.  Once split, it can then be styled using CSS.  In theory[1] :)

    Now, that's all very nice and theoretical, and I'm aware that the second option is more work for the developer (and particularly for the developer of the stylesheets used), but it starts winning when you have to deal with accessibility.  A blind user with a screenreader can use a site which uses the box model.  He/she will have a nightmare on something built using nested tables in most cases.

    In theory, again, when you wish to restyle your site, it's merely a question of changing stylesheets, not fucking about trying to get those nested tables to work properly (or, indeed, changing the method used completely)

    The difference is between doing something "properly" and implementing a godawful hack[1].  Given how many godawful hacks get posted up here per week, I'm surprised you can't see why using nested tables for layout is foul.

    Simon

    [1] And yes, I know that to do css styled layout properly may involve some fairly godawful hacks to make the current mainstream browsers do what they are supposed to, but the intention is what counts, and that's more a question of "temporarily stepping outside the problem" than "implementing shite" :)



  • @tufty said:

    A table is for laying out tabular data.  If your data is tabular, by all means use a table.  It's not, however, terribly common to find tabular data that contains other tabular data (when was the last time you saw a spreadsheet with another spreadsheet embedded in one cell and didn't summarily execute the person responsible?)

    Well, I see your point, but in web design, nested tables were state-of-the-art some years ago, and unless I see an immediate advantage in boxes, why should I care about such philosophical issues?

    Now, that's all very nice and theoretical, and I'm aware that the second option is more work for the developer (and particularly for the developer of the stylesheets used), but it starts winning when you have to deal with accessibility.  A blind user with a screenreader can use a site which uses the box model.  He/she will have a nightmare on something built using nested tables in most cases.

    This is a point I can accept. But only if the site is really tested with screenreader-emulators. I've seen websites, all CSS boxes and stuff, but the main navigation was built as a Flash animation.

    In theory, again, when you wish to restyle your site, it's merely a question of changing stylesheets, not fucking about trying to get those nested tables to work properly (or, indeed, changing the method used completely)

    IMO a non-issue, since I would use templates for any web project that consists of more than 5 pages. Changing the template vs. changing the stylesheet - where's the difference in terms of effort?

    The difference is between doing something "properly" and implementing a godawful hack[1].  Given how many godawful hacks get posted up here per week, I'm surprised you can't see why using nested tables for layout is foul.

    There is nothing worse than godawful hacks in a fairly large program, say some 10000 LOC or larger.
    But then, this is HTML, where each and every page is small, and possibly short-lived too. Nobody knows what the next browser will do or won't do; nobody can assume that all visitors use an up-to-date browser (though security issues should force them to do so...)



  • @ammoQ said:


    In the case of http://www.tuttle-ok.gov, the HTML text doesn't seem too bloated;


    Did you manage to pick up the actual, useful text by looking at the source? I couldn't.



    @ammoQ said:


    adding "nice" indention and comments would also make it bigger, wouldn't it?


    Of course it would, especially when coupled with tables within tables whithin tables...



    @ammoQ said:


    Anyway, bloated HTML can go a a long way before it reaches the size of a few small images.


    You'd be surprised... Any idea how much HTML is required to make a box with rounded corners?


    @ammoQ said:


    Technically valid HTML using tables for layout is IMO by far less likely to break in mainstream browsers than XHTML+CSS.


    Except when the user just happens to have the browser set to a large
    font size (as I do), or some other non-standard setting. As it happens,
    www.tuttle-ok.gov looks right. Possibly because it doesn't have rounded
    boxes :D



  • @ammoQ said:


    Correct me if I'm wrong, but I think it takes 4
    nested boxes to make a nice bitmapped border (with rounded corners,
    shadows and stuff), but only one table.




    Care to tell us what is so important about rounded corners and shadows that you can't do whitout? :)




  • @felix said:



    Except when the user just happens to have the browser set to a large
    font size (as I do), or some other non-standard setting. As it happens,
    www.tuttle-ok.gov looks right. Possibly because it doesn't have rounded
    boxes :D


    There is nothing wrong with rounded boxes, except they look kinda old-fashioned. Anyway, it's not difficult to have rounded boxes, while still not breaking with large fonts, with a table-based layout. It even manages to resize properly, something many newer websites seem unable to do (probably because of the incompetence of the designer).
    Warning: shameless self-advertising: this has been my website till 2004, when I decided that rounded boxes are soooo yesterday.



  • Tables equals bloat and is unwieldy to code and maintain.

    I have far more trouble getting tables to work, because most browsers don't respect my width+height settings. Most notably: IE.


    Anyway, bloated HTML can go a a long way before it reaches the size of a few small images.


    Correct point.
    Moot point.
    The point is a reduction in code size of 50%.


    adding "nice" indention and comments would also make it bigger, wouldn't it?


    Barely.
    Have you ever done it?
    I have.
    Lots of times.

    I've seen websites, all CSS boxes and stuff, but the main navigation was built as a Flash animation.


    Please stay on topic, and don't confuse an exception with the rule. This discussion isn't about Flash, and we all know that using Flash for just navigation just because it's flashy, is stupid.

    nested tables were state-of-the-art some years ago


    They were 'state of the art' because HTML was new back then and some visionless gadgeteering idiot said OMG and thus the table technique was born.

    They are not state of the art anymore. There's a replacement. The table blight has a cure. It's called: properly structured XHTML + CSS. Yay.

    Changing the template vs. changing the stylesheet - where's the difference in terms of effort?


    That's a valid point in this day of dynamic websites.
    Still, I'd rather rewrite CSS than dig through my code looking for HTML-strings built up with a multitude of contatenations.

    ignoring the flagrant problems with box-model support on current browsers,


    IE7 is looking up in terms of CSS fixes+support. :) Many problems that will soon belong to the past.

    Care to tell us why? What is so much better about nested boxes?
    Correct
    me if I'm wrong, but I think it takes 4 nested boxes to make a nice
    bitmapped border (with rounded corners, shadows and stuff), but only
    one table.


    Hehe.

    Only one table.

    Ok.

    With three TRs and nine TD's.

    Plus graphical IMGs in four of those cells.

    For a grand total of seventeen (17) elements.

    Yet, I do agree that adding 4 divs just to get some graphical twidge done is foul. CSS3 supports multi-backgrounds. Safari already supports multiple backgrounds on 1 element. Problem solved then. For now, 4 divs it is. And rarely, at that. How often does one create such layouts?

    There are ways of cutting down on the number of elements, if you're smart about it. You don't always have to slice all four corners separately, for example.

    valid HTML using tables for layout is IMO by far less likely to break in mainstream browsers than XHTML+CSS.


    Depends on who's doing the coding.

    as
    long as every mf browser in the world renders [tables] correctly


    Nope. That's not the case.


    Some time ago, I've made a website for the sister of my wife. Because
    I'm not experienced with CSS boxes, all layout was made with tables,
    and, well, it worked perfectly with Firefox,  IE, Konqueror, Opera
    and Safari. Than she hired some guys to do search engine optimization;
    for them this mostly means embedding lots of keywords in hidden areas.
    Anyways, along the way, the changed a part of the layout to CSS boxes.
    Now it doesn't work perfectly anymore. It's only a minor difference,
    she probably didn't notice it, but it made me unhappy anyway.


    Well fine.
    Those new coders were ditzes.
    Don't blame the technique.


    I'm not experienced with CSS boxes


    Aha!



  • I look back at my post and realize it sounds a bit patronizing.

    If so,
    I'm sorry.



  • @dhromed said:

    I look back at my post and realize it sounds a bit patronizing.

    If so,
    I'm sorry.


    No problem. I know my posts sound much like "but in those good old COBOL times everything was better" in this thread.
    It's just that... well, if something is claimed to be better, I'm used to ask: "Why? Show me the improvement! Show me the ROI!"



  • @dhromed said:


    @ammoQ said:
    Changing the template vs. changing the stylesheet - where's the difference in terms of effort?

    That's a valid point in this day of dynamic websites.


    No, it's not.  There may be very little difference in terms of efforts, but changing the markup and structure of your output is something that requires functional testing (does my site still work) as well as stylistic testing (does my site look good / the same in browser x, y and z).  Changing the stylesheet is (or should be) something that requires only the latter.

    As for sites that use flash navigation - well.  The "designers" should be taken outside and shot.  Repeatedly.

    Simon



  • Something else to think about:  Per some governmental regulations (depending where you live and/or do business), an "accessible" site must be readable even if scripting and/or style sheets are disabled.  http://www.cabinetoffice.gov.uk/e-government/resources/handbook/html/2-4.asp for example...  Tables work fine in that scenario; CSS may not.

     



  • Well - one of my favourite subjects it is. I've spent long and hard hours debating this point with the designer at my previous employer. Let me give you the short version.
    [him]: I've been designing using tables for years. What's with this CSS stuff? It's hell to get to work in both IE as well as Mozilla - tables always work! Why switch?
    [me]: Well, yeah, but just look how I've managed to reduce the code by two-thirds... doesn't it look much better?
    [him]: It doesn't look better on-screen - I'm missing a pixel there!
    Etcetera...

    A few simple observations...
    1) most of your visitors don't give a rat's arse about the quality of your HTML/CSS. They use Exploder anyway.
    2) your employer generally won't give a rat's arse about the quality of your HTML/CSS. He wants it to look good in Exploder so the visitors are happy, and preferably at an accetable price.
    3) your employer's customer generally won't give a rat's arse. Well, you get the picture.

    So, why bother?

    I still like to think there's something like professional pride out there. Among many other things, I build websites for a living. I want the HTML and CSS to be good. I want the underlying code (usually PHP) to be maintainable. Yes, using PHP in itself makes that a feat. I like a challenge, and the alternatives aren't much better, Python not yet being widely supported by hosting providers. In short, my visitors, customers and employers won't care, but I do.
    Where this starts to pay off is when any of these three request adjustments. Separating functionality, content and layout is always a good idea, and your life becomes just so much easier. Well, golly - isn't that what HTML was originally designed to do!

    You want a header, one with the title of your site in it? Great, use <h1> (forum software mangling alert!!!)
    You want a list of items? Great, use <ul>. Oh, it's a menu? <ul id="menu">!
    The point being, your tags should describe your data as well as possible - and that means trying to refrain from using tables, unless you're dealing with (hey!) tabular data (product table etc.) In fact, I've taken to using <strong> and <em> instead of <b> and <i> for that exact reason.

    I know full well that <b> and <strong> are interchangable (depending on your CSS) but that's not the point. If nothing else, Google knows <strong> is important. A site with minimal HTML that still looks readable in Lynx is always good for your search engine position, and that's usually the thing that wins over employers :) Oh, that and the savings in bandwidth...might not seem like much, but on a high-traffic site - believe me, it makes a world of difference to the people that pay my salary...



  • While on the subject of nested tables, has anyone seen the HTML for the page you're looking at? For anyone with Firefox and DOM Inspector, do the following:

    1. Open up DOM Inspector.
    2. Click open some of the tables, nested approximately 9 or 10 deep.
    3. Go wash your brain out with vodka.

    P.S. My first post ever. /me sacrifices a goat to the forum software...



  • @ammoQ said:

    @dhromed said:
    I look back at my post and realize it sounds a bit patronizing.

    If so,
    I'm sorry.


    No problem. I know my posts sound much like "but in those good old COBOL times everything was better" in this thread.
    It's just that... well, if something is claimed to be better, I'm used to ask: "Why? Show me the improvement! Show me the ROI!"


    The cliffnotes version:

    When done properly,
    CSS facilitates less and cleaner HTML while offering (far) more power.
    When done properly.

    There are always ways of screwing it up.

    --------------

    I have a coworker who's always amused by how little HTML I use to describe a page. Knowing your selectors goes a long way to prevent classeritis. :)

    The downside -- there's always a downside -- is that part of the bloat is transferred to the CSS file. Especially on large sites with many different sections and much unique functionality. This is just something I've noticed while coding such large functional sites (like intranets) and I'm looking into a way of reducing the CSS load.

    On the other hand, without a Ctrl+F5, the CSS is used from cache anyway, so it's a once-per-session hit so what am I worrying about? 500 K css for the win!



  • @ammoQ said:

    @felix said:
    Actually, it would make a difference
    • first and foremost for whoever
      pays the bandwidth. The kind of layout created by certain "smart" HTML
      editors - with tables within tables within tables... - is incredibly
      bloated. As much as 75% can be useless overhead.

    • Second, such a layout
      is likely to render incorrectly at least in one mainstream browser,
      even if the markup is technically valid, either because of a genuine
      bug, or because the browser in question tries to be compatible with
      some older browser. Or indeed, because the editor caters to a particular buggy browser (he he).

    • Third, though it's been brought up already, think of the blind people who might want to access such a site...

    In the case of http://www.tuttle-ok.gov, the HTML text doesn't seem too bloated; adding "nice" indention and comments would also make it bigger, wouldn't it?

    I usually don't comment HTML anyway (why would I do that? It's not like there is any logic in it anyway... supposedly), and HTTP compression schemes (GZip et all) take care of the indentation "issue" real good. Much better than they do take care of bloated HTML (even though they do a good job on it too)

    @ammoQ said:
    Anyway, bloated HTML can go a a long way before it reaches the size of a few small images.

    Well, I'm the one coding and bloated HTML goes a very short way before it melts my brain, clean semantic HTML is just more readable, and that's not even mentioning information retrieval (when websites don't expose APIs) or DOM stuff.

    @ammoQ said:
    @Noam Samuel said:
    DIE, NESTED TABLES, DIE!
    Care to tell us why? What is so much better about nested boxes?
    Correct me if I'm wrong, but I think it takes 4 nested boxes to make a nice bitmapped border (with rounded corners, shadows and stuff), but only one table.

    Safari and Konqueror implement multiple backgrounds already.

    Even without that, there is half a dozen way to implement borders and rounded corners, the cleanest of them using semantically empty elements such as divs absolutely positioned on top of their parent, putting the lowest possible strain and constraints on the document's meaning and display.

    @ammoQ said:

    @tufty said:
    A table is for laying out tabular data.  If your data is tabular, by all means use a table.  It's not, however, terribly common to find tabular data that contains other tabular data (when was the last time you saw a spreadsheet with another spreadsheet embedded in one cell and didn't summarily execute the person responsible?)

    Well, I see your point, but in web design, nested tables were state-of-the-art some years ago, and unless I see an immediate advantage in boxes, why should I care about such philosophical issues?

    It never was, tables & 1*1 transparent GIF were a hack invented circa 94-95 during the browser wars, and the very author of the technique disowned it as early as 97.

    Nested tables weren't state-of-the-art, they were just easier.

    @ammoQ said:
    Now, that's all very nice and theoretical, and I'm aware that the second option is more work for the developer (and particularly for the developer of the stylesheets used), but it starts winning when you have to deal with accessibility.  A blind user with a screenreader can use a site which uses the box model.  He/she will have a nightmare on something built using nested tables in most cases.

    This is a point I can accept. But only if the site is really tested with screenreader-emulators. I've seen websites, all CSS boxes and stuff, but the main navigation was built as a Flash animation.

    Too many websites, not enough shotgun shells.

    @ammoQ said:
    In theory, again, when you wish to restyle your site, it's merely a question of changing stylesheets, not fucking about trying to get those nested tables to work properly (or, indeed, changing the method used completely)

    IMO a non-issue, since I would use templates for any web project that consists of more than 5 pages. Changing the template vs. changing the stylesheet - where's the difference in terms of effort?

    Even RoR style multi-level templates don't reach the finesse of CSS when it's used properly, and it generates many more areas of change.

    One of the fun things with CSS is that you can use quite a lot of "OOP guidelines" in the CSS vs Tables debate: separate concerns, an item should have only one reason to change, strive for loose coupling between your layers, and even program to interfaces (classes & ids) and not implementations (precise elements at a precise position of the hierarchy).

    @GalacticCowboy said:

    Something else to think about:  Per some governmental regulations (depending where you live and/or do business), an "accessible" site must be readable even if scripting and/or style sheets are disabled.  http://www.cabinetoffice.gov.uk/e-government/resources/handbook/html/2-4.asp for example...  Tables work fine in that scenario; CSS may not.

     

    You're joking right? If anything, this is THE strongest point of using semantic HTML + CSS instead of a bunch of tables: graceful degradation, the document stands on it's own, it doesn't need scripting, it doesn't need styling and it doesn't even need images (unless it's about images of course). No it won't look anything like what it looks like when styled, but it should still be very readable, potentially even more readable than the styled version (if uglier).

    No website author who knows his craft would ever do something that doesn't work in this scenario (and others), and Accessibility oriented websites (such as Accessify) strongly advocate the use of valid and semantic HTML.

    @Monomelodies said:
    So, why bother?

    My main personal reason is "maintainability".

    If I'm the one who'll have to deal with that mess in a few month's time, I want the document, the way it's built and the way it works to be ovious, and I don't want my templates/output to be composed by line noise (tables/trs/tds/1*1 gif images) upwards to 90%.



  • @masklinn said:



    Safari and Konqueror implement multiple backgrounds already.

    Things that don't work in IE, FF and Opera are rather useless for today's work.


    Even without that, there is half a dozen way to implement borders and rounded corners, the cleanest of them using semantically empty elements such as divs absolutely positioned on top of their parent, putting the lowest possible strain and constraints on the document's meaning and display.

    Care to post an example how to do it right, so I can learn a bit? With bitmaps in all edges and corners, and the whole rounded "box" should scale to the size of the window (not the 800x600 fixed-size thingy that looks extremely stupid at 1600x1200), with a margin of 20 pixels or 2% (whatever is easier to do) outside the box.


    It never was, tables & 1*1 transparent GIF were a hack invented circa 94-95 during the browser wars, and the very author of the technique disowned it as early as 97.

    IIRC the browser wars started around '98. Table-based layout became really usable with Netscape 3 and IE4.


    Nested tables weren't state-of-the-art, they were just easier.

    There was no other way to get the same results before CSS boxes were available.



  • Lately, I've been preferring very simple layouts for my code. When opened in Lynx, it works perfectly well, which is what I'm using as a benchmark.

    http://www.krotkov.com

    The entire site is under 30kb, graphics and all. And if only every browser implemented a way to make a layer transparent without making the text transparent, it would be so much better...



  • @akrotkov said:

    Lately, I've been preferring very simple layouts
    for my code. When opened in Lynx, it works perfectly well, which is
    what I'm using as a benchmark.

    http://www.krotkov.com

    The
    entire site is under 30kb, graphics and all. And if only every browser
    implemented a way to make a layer transparent without making the text
    transparent, it would be so much better...




    Make the font larger and your layout breaks...



  • @ammoQ said:

    Care to post an example how to do it right, so I can learn a bit?
    With bitmaps in all edges and corners, and the whole rounded "box"
    should scale to the size of the window (not the 800x600 fixed-size
    thingy that looks extremely stupid at 1600x1200), with a margin of 20
    pixels or 2% (whatever is easier to do) outside the box.

    I'll just redirect you to the original sources.

    You may want to start with this fairly old (febuary 2004) article from A List Apart and then follow up with Roger Johansson's four articles on the subject (the last one using multiple backgrounds and therefore being useful only in Safari or Konqueror at the moment, or for academic purposes).

    To stay in the purely academic stuff for personal interrest, you may also like Stu Nicholls' Curved Corners on CSS Play (and i'd recommend visiting the rest of the site, even though quite a lot of the displays are extremely hacky some are very fun, such as the pure CSS mazes)



  • @ammoQ said:


    Warning: shameless self-advertising: this has been my website till 2004, when I decided that rounded boxes are soooo yesterday.


    It's obvious you know what you're doing :D And your old site proves my
    point, in one regard: I can easily read the content straight from the
    source.



  • @dhromed said:


    [...] we all know that using Flash for just navigation just because it's flashy, is stupid.


    Well, at my company we had to do just that for a site. Customer's
    request. Naturally, they changed their mind after two months. Such is
    life. Or should I say "such is bussiness"?



  • @masklinn said:

    @ammoQ said:

    Care to post an example how to do it right, so I can learn a bit?
    With bitmaps in all edges and corners, and the whole rounded "box"
    should scale to the size of the window (not the 800x600 fixed-size
    thingy that looks extremely stupid at 1600x1200), with a margin of 20
    pixels or 2% (whatever is easier to do) outside the box.

    I'll just redirect you to the original sources.

    You may want to start with this fairly old (febuary 2004) article from A List Apart


    For whatever reason, the lowerright corner image is not displayed correctly on my FF 1.07/Linux... Playing with the font size breaks it in other browsers, too.


    and then follow up with Roger Johansson's four articles on the subject (the last one using multiple backgrounds and therefore being useful only in Safari or Konqueror at the moment, or for academic purposes).


    Nice, these work fine.


    To stay in the purely academic stuff for personal interrest, you may also like Stu Nicholls' Curved Corners on CSS Play (and i'd recommend visiting the rest of the site, even though quite a lot of the displays are extremely hacky some are very fun, such as the pure CSS mazes)



    Doesn't work at all on this machine (not FF, not Konqui, not Opera), probably because I have no Arial font installed... But I understand this is purely academic.

    Thanks for the links!


  • I've used extra curvy corners that stretch vertically on my own site.

    I have no idea why I used four corners if it doesn't stretch horizontally anyway. But hey. Maybe I'll address that someday.


Log in to reply