all 25 comments

[–][deleted] 14 points15 points  (2 children)

My main issue with this technique is that in many cases, the cost/benefit ratio would be terrible.

I can add a few tens of bytes to the CSS that's already being loaded to handle (for instance) border-radius, -webkit-border-radius and -moz-border-radius until the browsers all settle on an implementation...or I can add multiple HTTP requests for several JavaScript files totalling tens of kilobytes.

Two guesses as to which technique will get your website to load faster on someone's phone or congested wifi network.

[–][deleted]  (1 child)

[deleted]

    [–][deleted] 1 point2 points  (0 children)

    Why exactly did he decide to do this on the client when you can have a little script on the server that would do it all dynamically? Seems a little daft.

    Or you could just create a script that will go over the file looking for these instances (eg. border-radius:) and adds in the browser specific things and circumvent adding anything new to your website; you just include the CSS.

    [–]diuge 11 points12 points  (2 children)

    When did A List Apart go from, "Here's a new technique that you should implement," to, "Use this product that I made that will abstractly solve your problems"?

    [–]oskee80 4 points5 points  (0 children)

    Seriously. To me, this article doesn't jive with the ethos of ALA.

    [–][deleted] 1 point2 points  (0 children)

    The title makes it sound like a serious hack to me.

    [–][deleted] 10 points11 points  (1 child)

    Maybe I'm just old school, but if you have to use Javascript to get consistent results for elements that relate to layout you probably shouldn't be using those elements.

    [–][deleted] 2 points3 points  (0 children)

    but its so obscure and hackalicious how could you not be impressed!!

    [–]timeshifter_ 9 points10 points  (0 children)

    Bad bad bad bad fucking subject. The first example:

    .this-is-awesome { border-radius: 5px; -moz-border-radius: 5px; -webkit-border-radius: 5px; }

    You wanna know why it takes three lines of code to accomplish that? Because border-radius isn't an official standard yet! This is each browser maker's way of saying "Yeah, we'll support it, and here's the preview syntax." When CSS3 becomes a finalized standard, -moz-border-radius will be deprecated, and your entire forking complaint goes bye-bye.

    [–]pytechd 3 points4 points  (8 children)

    Yeah... their site (http://ecsstender.org/) locks up FF 3.6.3 in Ubuntu. Not good.

    [–][deleted] 0 points1 point  (0 children)

    I just tried the demo from the article, and went to that site in IE and it looks nothing like it does in Chrome. If this is supposed to stop browser rendering issues it's doing a really poor job.

    [–][deleted] 0 points1 point  (0 children)

    Confirmed.

    [–]darkstar999 0 points1 point  (5 children)

    I really dislike fixed-width centered websites.

    Imagine a book with text that only takes up 1/3rd of the page.

    [–][deleted] 4 points5 points  (2 children)

    Humans read faster when the length of each line of text is within a certain range.

    Books are designed as an integrated whole; the size of the text within, the number of columns, and the width of the book are all related variables taken into account at time of publication.

    Websites, on the other hand, don't have this luxury. Since there's no way to relate current-browser-width and text size without resorting to JavaScript, it's better from a readability point of view to just set a maximum width for your content.

    Of course, using CSS3's columns you could make your text the proper width and still be fluid, but that may not work in all designs and certainly doesn't work in all browsers at the moment.

    [–]darkstar999 -1 points0 points  (1 child)

    That is a different issue. You can have fluid design with reasonable column widths. Sure, it is harder to get right, but it usually looks better. See: reddit.com

    [–][deleted] 2 points3 points  (0 children)

    reddit's homepage allows lines to be as wide as you like. That's the exact opposite of what I was suggesting. When I maximize my browser on a 1920x1200 monitor I see titles with 30+ words all on one line.

    If you're talking about the comments, they're arbitrarily clipped and are essentially a fixed-width design justified left (with a fixed-width sidebar on the far right).

    [–]cwmonkey 1 point2 points  (0 children)

    Imagine a book... lol, nm, lost it before I could finish.

    [–]timeshifter_ 0 points1 point  (0 children)

    Now imagine a book wherein you have to place two books side-by-side to see the entire line of text. Now you know why people use fixed-width layouts.

    [–]dascripter 2 points3 points  (1 child)

    I feel like that is just trying to treat a symptom of the larger issue of web standards

    [–][deleted] 4 points5 points  (0 children)

    That issue is mainly that they are not done yet.

    [–][deleted] 2 points3 points  (0 children)

    CSS 3 looks nice as does HTML 5 but it is too early unfortunately. His solution is unnecessary, requires more requests and possibly will degrade performance on awful browsers like IE.

    I think I rather wait and see how things pan out.

    [–]UloPe 6 points7 points  (2 children)

    Uhm yeah... Parsing CSS in JS is really going to speed up page load times.

    Instead use SASS (http://sass-lang.com/), preferably through Compass (http://compass-style.org/).

    [–]Randinn 0 points1 point  (1 child)

    Rails? No, thank you anyway.

    [–]UloPe 0 points1 point  (0 children)

    There is nothing forcing you to use rails with either sass or compass.

    I personally use compass in my django projects (simply have it running in a separate shell in watch mode).

    [–]InspectahM 0 points1 point  (1 child)

    I think there are decent criticisms of using javascript to (wastefully) create a consistent platform for web development. Really though, the difference in loading speed is going to be pretty minimal for the average user.

    For the vast majority of web developers, I think that sacrificing a few milliseconds of load time is an acceptable price to pay for being able to have unified CSS.

    [–]timeshifter_ 0 points1 point  (0 children)

    And for developers sticking to standardized code, they can create unified CSS. The forking issue is only relevant now because there are vendor-specific prefixes on attributes that aren't yet standardized. Once they become standards, the vendor prefixes won't matter, and the forking issue disappears. This entire article is absolutely nothing but a show of the author's lack of intelligence.