CSS is for wimps



  • @blakeyrat said:

    You know, I see where you're coming from. But the problem is when you take that attitude and go, "well, since a lot of people who use it day-to-day can understand it, it doesn't need improvement."

    I never said that. There are plenty of areas that need improvement otherwise there would be no CSS2 or CSS3 specs. All I'm saying is that, in spite of the issues with CSS itself, layouts built with CSS are more semantically correct, more robust and more flexible than a table layout. Just like using CSS instead of font tags is semantically more correct, robust and flexible.

    @blakeyrat said:

    Firstly, because CSS has glaring flaws that anybody who's worked with it for even a few minutes can spot. (For example, lack of columns.)

    Text columns aren't missing, they're in the spec, but they're just not supported very well, or at all, mainly because they make no sense on the web. The web isn't a newspaper meaning that if the user's browser is even a bit shorter than what you deem an appropriate block height they'll be forced to scroll up and down several times just to read your article. If you mean layout columns, that's been solved a million times over with floats. If you don't like having to deal with floats yourself then use the 960 Grid System to do it for you. It has the added benefit of being a proper grid so you can give the grid template to any designer and know that the design you get back will fit your HTML without having to measure everything.

    @blakeyrat said:

    Secondly, because every technology can, and should be, improved. Computers suck right now... if you think anything about developing software or websites is good, then you're mistaken.

    I find this ironic considering you were claiming that table based designs, a relic from the 90's, is good enough yet you're now claiming that CSS-based designs are dated? I never claimed that these technologies don't need improvement, I'm just saying they're not as broken as you think they are. By your logic, every programming language, framework and platform is broken and "not good" because they all happen to have warts.



  • @blakeyrat said:

    But here's a quick little hint: here in the US? We don't label people.

    You're only saying that because you're a west coast liberal hippie geek.

    @blakeyrat said:

    At least not institutionally.

    Ah - that's all right then.



  • @Soviut said:

    this would be akin to someone writing their resume in Excel rather than word. Sure, with enough effort, they could get everything positioned to look right. But zoom the document, try to print it, try to export a PDF of it or export it for html on the web and this layout quickly breaks because it was hack to begin with.
    I'm not defending using Excel to write a resume, but claiming that you wouldn't be able to zoom, print or convert to pdf is just plain wrong.  I know because I've had to do it when working on a WTF project that is a whole separate story.

    As for exporting to html, Word doesn't do such a great job either.



  • @El_Heffe said:

    I'm not defending using Excel to write a resume, but claiming that you wouldn't be able to zoom, print or convert to pdf is just plain wrong.  I know because I've had to do it when working on a WTF project that is a whole separate story.

    I don't mean the document won't zoom or print at all. I mean that using the tabular structure of an excel sheet is fragile since content doesn't flow around entire document and instead flows only within each cell. If the font size changes slightly it all the cells reflow and the overall layout suffers. Add a paragraph to your excel sheet and now you have to tediously go through and shift cells around to make it fit again. Meanwhile, in a word doc, adding a paragraph simply reflows the entire document and the layout will survive even if you tell it to print at a different font scale, for example.

    A similar principle holds true for CSS layouts in that when they don't fit certain media (mobile, print, large format, accessibility, etc.) they can be easily reflowed.



  • I, personally, would like to do away with typing HTML and CSS as much as possible, because I think it's an obsolete way of doing things, akin to writing assembly by hand.

    I have made some strides by using tons of templates and macro snippets, but I think that's a bit of a dead end, and I'm not sure what the real solution is. Perhaps I need a better problem statement.



  • Realistically what we need is to do with HTML completely. It's nice but a bit impractical in a lot of ways. Design a new document format kind designed to be downloaded with an inbuilt, simple scripting language, both client and server side, designed for GPU rendering so it'd play nice with smartphones and run smoothly and native support for modular pages. (such as having the actual content as a form of iframe but still being able to link to the right page) Hell, 3D models in webpages'd be pretty damned nice too. And let's do away with this XML stuff, it was nice before WYSIWYG editors were impractical but now they ARE practical and a spec that's open to interpretation in a lot of ways is one that's going to be a pain when there are several implementations. Everything shall be defined. How text is spaced, how incomplete space is managed. A way of using fonts from websites without installing them into a system folder.



    Oh, and it should all be done by next Friday. That should be no problem for you guys right? I'm willing to pay in caps. Say, 20 or maybe 30 if it comes with a lot of shiny fragment shaders.



  • @nexekho said:

    Realistically what we need is to do with HTML completely. It's nice but a bit impractical in a lot of ways. Design a new document format kind designed to be downloaded with an inbuilt, simple scripting language, both client and server side, designed for GPU rendering so it'd play nice with smartphones and run smoothly and native support for modular pages. (such as having the actual content as a form of iframe but still being able to link to the right page) Hell, 3D models in webpages'd be pretty damned nice too. And let's do away with this XML stuff, it was nice before WYSIWYG editors were impractical but now they ARE practical and a spec that's open to interpretation in a lot of ways is one that's going to be a pain when there are several implementations. Everything shall be defined. How text is spaced, how incomplete space is managed. A way of using fonts from websites without installing them into a system folder.

    Oh, and it should all be done by next Friday. That should be no problem for you guys right? I'm willing to pay in caps. Say, 20 or maybe 30 if it comes with a lot of shiny fragment shaders.
     

    plz give me teh codez..!!.. ..URGENTT..!!..



  • @Soviut said:

    I never said that. There are plenty of areas that need improvement otherwise there would be no CSS2 or CSS3 specs. All I'm saying is that, in spite of the issues with CSS itself, layouts built with CSS are more semantically correct, more robust and more flexible than a table layout. Just like using CSS instead of font tags is semantically more correct, robust and flexible.

    Then we agree on those points. (Except I've never use an meaningless academic phrase like "semantically correct", because I'm not a douche.) But I'd still advise people who have an existing and working table-based layout to keep it as long as it continues to work for them.

    @Soviut said:

    Text columns aren't missing, they're in the spec, but they're just not supported very well, or at all, mainly because they make no sense on the web.

    You. Are. Missing. The. Point.

    On the web, your left-hand navigation *is a column*. Your right-hand navigation *is a column*. CSS has no support for entities like this, at all. (It does support enclosing your navigation in a block element and "floating" it left or right, but odds are, that's not what you want.)

    Look, when we say the word column, it could mean one of two things:

    1) Creating a vertical separation in part of the page so that different content could be put in either side of the vertical separation

    2) Creating re-flowing text columns like those used in a desktop publishing tool

    Right now, CSS2 supports *neither* of those two scenarios. *NEITHER* You keep acting as if it supports the first, but it doesn't! You can fake it, by abusing the "float" property, but it isn't officially supported. CSS2 HAS NO COLUMNS. Do you understand?

    Now going back to my previous point, the fact that CSS has something as gimmicky as rollover effects *before* it has anything as basic as columns does nothing but proves that CSS was developed by morons, half-assed, backwards, and upside-down. There is no excuse for supporting rollover effects *before* supporting columns.

    @Soviut said:

    The web isn't a newspaper meaning that if the user's browser is even a bit shorter than what you deem an appropriate block height they'll be forced to scroll up and down several times just to read your article.

    Fine; re-flowing columns don't make sense. But that's no excuse for not supporting non-reflowing columns, which are used on virtually every website ever made.

    @Soviut said:

    If you mean layout columns, that's been solved a million times over with floats.

    It's not solved, that's a work-around. A hack. There is no "solution" because the language doesn't support it. Any language that requires 99% of its users to engage in hacks to get their job done is a shitty language, and should not be defended.

    @Soviut said:

    I find this ironic considering you were claiming that table based designs, a relic from the 90's, is good enough yet you're now claiming that CSS-based designs are dated?

    ... when did I say CSS-based designs are dated? That's not in the quoted text...

    @Soviut said:

    By your logic, every programming language, framework and platform is broken and "not good" because they all happen to have warts.

    Yeah, but I'm not required to use a nasty hack in WinForms to add a fucking Menu Bar. Because the designers of the language actually built-in features developers use most often. Shocking!



  • @nexekho said:

    Realistically what we need is to do with HTML completely. It's nice but a bit impractical in a lot of ways. Design a new document format kind designed to be downloaded with an inbuilt, simple scripting language, both client and server side, designed for GPU rendering so it'd play nice with smartphones and run smoothly and native support for modular pages. (such as having the actual content as a form of iframe but still being able to link to the right page) Hell, 3D models in webpages'd be pretty damned nice too. And let's do away with this XML stuff, it was nice before WYSIWYG editors were impractical but now they ARE practical and a spec that's open to interpretation in a lot of ways is one that's going to be a pain when there are several implementations. Everything shall be defined. How text is spaced, how incomplete space is managed. A way of using fonts from websites without installing them into a system folder.



    Oh, and it should all be done by next Friday. That should be no problem for you guys right? I'm willing to pay in caps. Say, 20 or maybe 30 if it comes with a lot of shiny fragment shaders.

    You're joking, but... that already exists in the form of Silverlight. Give your caps to Microsoft. (Just drive by the RedWest campus and toss them out towards the lobby, they'll know what you mean. Ooo, or even better, put them in the RedWest MSN mail box.)



  • @b-redeker said:

    @blakeyrat said:

    But here's a quick little hint: here in the US? We don't label people.

    You're only saying that because you're a west coast liberal hippie geek.

    @blakeyrat said:

    At least not institutionally.

    Ah - that's all right then.

    Can you imagine living in a country where the government goes "you're a Beta. You go to Beta schools! HEIL HITLER!" (Well, ok, I guess they don't do that last part anymore...)



  • @blakeyrat said:

    Can you imagine living in a country where the government goes "you're a Beta. You go to Beta schools!"
     

    I sure can't.

    It's just a sort of convention. Not a hard limit on which an educational subsystem is pinned.



  • @blakeyrat said:

    Can you imagine living in a country where the government goes "you're a Beta. You go to Beta schools!

    Nope, I can't.

    The origin of this alfa/beta/(gamma) thing is not to categorise people, but universities/studies. It's similar to (arts & something)/natural science/social sciences. It just so happens that typical geeks are usually attracted to natural sciences (beta), they are "typical beta's". Others are typical "alfa's" (artsy fartsy). And obviously, other people have multiple interests and can't be categorised.

    So nothing in the way of an official government approved stamp. Except a bit in schools, where you can often choose between certain combinations of courses; so you choose the language/art track (a typical "alfa package") or the science track ("beta package"). But that's something you and your parents decide.

     



  • Welcome to Google School! [img]https://psu.oss.cayey.upr.edu/images/beta-starburst.png[/img]



  • @blakeyrat said:

    It's not solved, that's a work-around. A hack. There is no "solution" because the language doesn't support it. Any language that requires 99% of its users to engage in hacks to get their job done is a shitty language, and should not be defended.

    I don't think we're ever going to agree, but just out of curiosity: why do you keep saying creating columns using floats is "a hack"? It's not, it's exactly what they're meant for. Let me explain.

    The CSS box model assumes mostly two kinds of markup: inline elements and block elements. Inline elements have no layout (like words), block elements specify a block - e.g. a paragraph. Hence, a block implies a "newline after this". A block, by definition, spans the entire available width.

    Obviously, there are situations where you want a block to occupy less width. For instance, in a sidebar or a menu. You'll also want to be able to align it, and have the content superseding it to "wrap around" it (in layman's terms: "begin on the same line"). Hey! That's exactly what floats are for!

    Maybe I'm truly missing your point, but you keep repeating floats "are a hack" (they're not) and "CSS doesn't support columns" (it does: you need to use floats).

    There is one thing CSS /doesn't/ properly support, and that's a (say) 3 column layout where all the columns are forced to the same height. If you really want to do that, you indeed have to resort to either a hack, or a table (which, by definition, assigns all columns in a row the same height). And there's actually good reason for CSS not to support that: webpages weren't meant to be laid out in that way. A webpage != a magazine page. So, if your design requires you to implement three non-related-but-the-same-height columns, the design is TRWTF. And like I said before, the advent of tablets MAY (or may not) require us to rethink this paradigm.

    A comparable argument can be made for the non-support of "calculations" in dimensions, e.g. "10em+1px". By default, box elements expand to the entire available width. So usually, it's not a problem - it only becomes a problem when you muck about with a myriad of floated elements that all "need to fit". But more than 9 out of 10 times, you'll have a sidebar (in a div or - in HTML5 - an aside) that's, say, 200px wide, and boxes inside of it (more divs, or sections) that have no specified width but instead a padding or margin of, say, 1em. It doesn't bite. If I find myself needing to "calculate" a width by adding ems to pxs, I'm probably Doing It Wrong, and that's maybe once a year.

    Oh, and if you don't want to specify your colours all over the place, you can always group the declarations, as in "p, a, em, strong, div { color; red; }". CSS supports that perfectly, just not in the way that you'd LIKE it to work.

    As a final thought, dhromed stated CSS was easy to learn, but hard to master. I disagree: it's not hard to master at all. It DOES, however, require a certain way of thinking, one that's maybe somewhat alien to a programmer. But keep in mind, someone who only knows CSS will say the same of $yourprogramminglanguageofchoice.



  • @Monomelodies said:

    So, if your design requires you to implement three non-related-but-the-same-height columns, the design is TRWTF.

     

    Navigation on the left, additional info on the right, content in the middle, separated by black borders. How is that a WTF? 



  • @Monomelodies said:

    There is one thing CSS /doesn't/ properly support, and that's a (say) 3 column layout where all the columns are forced to the same height. If you really want to do that, you indeed have to resort to either a hack, or a table (which, by definition, assigns all columns in a row the same height).
     

    FWIW, this is now possible in non-primitive browsers: just assign the parent "display: table;" and each of the equal-height children "display: table-cell".  No floats needed, and heights automatically align.  Yes, it's using table display properties, but it's a heck of a lot more flexible and maintainable than wrapping your non-tabular content in spurious data-table markup.


  • I'd agree that learning css isn't hard, it's just that people somehow can't be bothered to read the actual spec about how point attributation works and how elements behave but instead rely on w3cschool etc.. 

    but CSS is surely severy limited, float and inline-block's are not enough, vertical-align is just weird and etc..  But this was to be expected really, because afaik CSS was created without consulting actual designers and at the time web pages didn't really have a design anyway. It wasn't until people from marketing and ad agencies started to get into webdesign that the idea emerged that you might want to have a pretty webpage.



  • @Monomelodies said:

    There is one thing CSS /doesn't/ properly support, and that's a (say) 3 column layout where all the columns are forced to the same height.

    Ding ding ding, we have a winner. You've just described exactly what about 75% of websites want to do with columns. And, in the same sentence, admitted CSS doesn't support it.

    So you're replying to counter my point by agreeing to my point. Congratulations.

    @Monomelodies said:

    And there's actually good reason for CSS not to support that: webpages weren't meant to be laid out in that way.

    Oh, so CSS doesn't support it because CSS was designed by some design-Nazi who wants to tell me how to lay out my webpage? That's even WORSE than me just assuming they're incompetent. (You're not helping your case here.)



  • @Monomelodies said:

    And there's actually good reason for CSS not to support that: webpages weren't meant to be laid out in that way. A webpage != a magazine page.
    Really?  Says who?

    Magazines and newspapers have been around for a really long time.   We are familiar with them.  We like them.  We want them.  And it is perfectly normal to want a web page to look like a magazine page.  There's nothing weird or crazy about that.  That's why people want things like multiple columns.  That's why people go to great lengths (and hacks) in their attempts to make web pages look like magazine pages.

    Obviously, not all web pages need to (or should) look like a magazine page.  Depending on the content involved there are a number of other layouts that are more appropriate.  But, saying things like "A webpage != a magazine page" is really just a flimsy excuse attempting to cover up the fact that after all these years HTML and CSS are still crude, primitive tools that can't do one of the things people want most -- make a web page look like a magazine page.



  • @El_Heffe said:

    And it is perfectly normal to want a web page to look like a magazine page.
     

    When creating a website, one must strongly consider the fact that it's a different medium with a different viewing method, different possibilities and a radically different interaction model.

    So, wanting a web page to look like a magazine page is a matter of degree.  If it has to look exactly like it, then that's an undenyable WTF. If it has to carry the general look & feel, then that's the correct way of doing it.

    You probably agree, but I thought I'd be explicit.

    Porn.



  • @Monomelodies said:

    why do you keep saying creating columns using floats is "a hack"? It's not, it's exactly what they're meant for. Let me explain.
     

    A person speccing out the behaviour of floats and then claiming it is intended to do columns, leaves me rather... underwhelmed. In fact, I doubt it's true. Do you have a reference for that?

    So far, floats are a workaround for a common layout use case that is poorly supported by CSS.

    @Monomelodies said:

    You'll also want to be able to align it, and have the content superseding it to "wrap around" it

    Columns don't wrap. What you're referring to is, for example, the sidebox in Wikipedia articles, that sits in the text on the right, and text flows around it. That's good. I like that box, and it looks fine.

    What we're referring to, is the entire left side of Wikipedia, which visually has a fixed width all the way down to the bottom.I'm not saying that's impossible or even hard to do, but it would have been better if CSS supported specifying that, say, children of elemeny X are to be laid out as (block) columns, without resorting to flots or display:table-cell.

    I did some superficial experiments with display:inline-block, but browser support was sketchy and variant, and it didn't behave like the holy grail I was looking for.

    It happens to be not a problem for Wikipedia, only because its visual design works around the fact that the left column isn't actually 100% high but just looks like it. This is the advice I give to designers I work with: don't rely on stuff stretching down.

    @Monomelodies said:

    And there's actually good reason for CSS not to support that: webpages weren't meant to be laid out in that way.

    Yes the are. It is the explicit intent of CSS to bring rich layouting and formatting abilities to web pages.

    @Monomelodies said:

    Oh, and if you don't want to specify your colours all over the place, you can always group the declarations, as in "p, a, em, strong, div { color; red; }". CSS supports that perfectly, just not in the way that you'd LIKE it to work.

    That is true, but it doesn't solve the problem. It only moves it. Instead of hunting down colors when you want to modify them, you're hunting down selectors when you want to change an element.

    I only go that route — to great effect — when a website has some manner of skins of color schemes. Then one separates color definitions form the layout bits into a seperate stylesheet with the name of the scheme.



  • Speaking of skinning engines, I think they can be seen as a clear indicator that CSS didn't fulfill its original purpose yet, even if it has simplified many things to a great extend.

    If CSS really were capable of turning arbitrary "semantic" HTML into any design/GUI you wanted (as, from what I know, goes the official lore regarding the "separation of content and presentation" mantra), there would be no need for skinning engines at all. You'd just have your system output a fixed "semantic" HTML document, throw a bunch of stylesheet definitions at the top and let the browser do the rest.

    Yet however, every skinning system I've seen on the web also changes the HTML they output depending on which skin you have chosen, in addition to the CSS. In fact, many skinning enginesabstract away from the HTML completely and have the authors specify their documents in some other language that they then translate to HTML/CSS. Do those things exist because web authors just love unnecessary complexity? Probably not.



  • @dhromed said:

    @El_Heffe said:

    And it is perfectly normal to want a web page to look like a magazine page.
     

    When creating a website, one must strongly consider the fact that it's a different medium with a different viewing method, different possibilities and a radically different interaction model.

    So, wanting a web page to look like a magazine page is a matter of degree.  If it has to look exactly like it, then that's an undenyable WTF. If it has to carry the general look & feel, then that's the correct way of doing it.

    You probably agree, but I thought I'd be explicit.

    [b]The Internet is for [/b]Porn[b]![/b]

     

    AQTFY.

    This is where I'd put the tag "Avenue Q'd That For You" on this post to explain that, but since the tags are horribly broken, I won't be doing that today.



  • @Someone You Know said:

    The Internet is for Porn!

     

    Thankfully, porn in no way requires columns to do its job.



  • @HighlyPaidContractor said:

    @Someone You Know said:

    The Internet is for Porn!

     

    Thankfully, porn in no way requires columns to do its job.

    Hmmm, yes it does require this for some scenes, or else gravity will take its toll.

    //Curse you CS, I'm tag deprived



  • @dhromed said:

    A person speccing out the behaviour of floats and then claiming it is intended to do columns, leaves me rather... underwhelmed.

    That person would have to be so monumentally incompetent that, like the "webpages shouldn't look like magazines" argument, it actually makes Monomelodies' case worse.

    I mean, I was just assuming CSS sucked shit because they neglected to add columns at all. If it turned out they were attempting to add columns, and "float" was *the best they could come up with?* That takes the group from "academic dork who didn't interview actual website designers" to "unbelievable retard who pisses his pants daily."



  • @blakeyrat said:

    I mean, I was just assuming CSS sucked shit because they neglected to add columns at all.
     

    I won't argue that an explicitly defined way of doing columns wouldn't have been an improvement to CSS, but for why it doesn't have one, you have to take a look at the history of the standard itself.

    CSS1 was basically about being able to standardize things like font faces, sizes, colors, and text alignment across your site without having to worry that you had all the same font tags in the right place.  It was released in 1996, when the web was still essentially limited to universities, some very early adopters, and the AOL crowd.  Domain names had *just* ceased to be free to register.

    CSS2 was drafted in 1998 (the remaining time before it was finalized in the mid '00s was basically spent wrangling over details).   In 1998, corporations were only just starting to discover the web, navigational bars were new and shiny (anyone remember button makers?), and frames were a widely accepted method of implementing columns (and the only thing people used columns for was navigation).  Netscape was the most widely used browser, and when you resized a window that contained tables, it would reload the entire page from scratch, including a new HTTP request to the server.  If you really wanted to set your navigation in a separate column from your text, it could be accomplished fairly easily with absolute positioning in about 99% of the designs that were in use in 1998.

    Around 2001 or 2002, a few people began playing with the CSS spec and discovering some really cool things you could do with it (I remember being blown away by a "fixed" background image demo).  They discovered that it was much more friendly to the search engines and screenreaders of the time than tables were, and also that you could use it to make pages print prettily.  They began to work out ways to lay out entire web pages with it.  In the same way that CSS font styles were infinitely more maintainable than a morass of font tags, it became clear that markup for CSS layouts was much more flexible and easier to maintain than that for table layouts.  The CSS Zen Garden demonstrated that you could use different stylesheets to display the same page in radically different (and beautiful) ways, without changing the markup. 

    By this time, of course, the internet was starting to take off; the word "weblog" had entered the lexicon.  People actually had uses for more complex layouts by this time, and series upon series of articles were written detailing new techniques and tips and tricks and ways to make CSS do multi-column layouts with cleared footers and all the rest.  By the time the standard was officialized, or display:table and display:table-cell were properly implemented in any browser, multi-column layouts using floats (which also -- no small virtue -- worked in IE6, a market-dominant browser that wasn't going to be updated or go away any time soon) were already a solved problem.

    Which brings us to CSS3, begun in 2005.  Perhaps the W3C should have added explicit column declarations to this spec -- but by the time they began working on it, columns were, as described above, a solved problem in CSS2 using floats; and once the CSS2 display:table-* properties (which allow for proper equal-height columns) were implemented by the browsers, any separate column declaration in the spec would basically just be a duplicate syntax for a feature that already existed.  Text flow columns are another story (also not relevant in 1998).  They now exist in the spec and are supported in most of the non-IE browsers; the big holdup is, as usual, Internet Explorer.

    So I won't say there's no WTF in the fact that there's no column declaration in CSS -- but there is a historical reason for the WTF.



  • @blakeyrat said:

    I mean, I was just assuming CSS sucked shit because they neglected to add columns at all. If it turned out they were attempting to add columns, and "float" was *the best they could come up with?* That takes the group from "academic dork who didn't interview actual website designers" to "unbelievable retard who pisses his pants daily."
    There's a much less confusing way of giving a site a columnar layout using CSS without resorting to floats.  (I never got the hang of floats. I mean, I can use them fine, but it's not easy to intuit how they'll turn out or how to fix them when they break.  Therefore they suck.)

    I maintain a few sites with a basic title, left-hand-nav, right-hand content block layout.  My favorite way to make this layout is to just specify a width on the nav bar and position it absolutely along the side.  The absolute position makes other elements flow under it.  Then, the right-hand content block is given a margin of the same (or slightly greater) value as the nav bar's width.  Having three columns this way is just as easy.  Add any more than three and you'll have to resort to wrapping divs in divs.

    Filed under: In semantic HTML, the div element means "CSS needs this to work"



  • @sprained said:

    They now exist in the spec and are supported in most of the non-IE browsers; the big holdup is, as usual, Internet Explorer.

    Considering how burned IE got when they implemented the CSS1 spec "early", you can't blame them for holding-out until CSS3 is final. You seem like a person who understands the history of the web, so I find it perplexing that you still repeat the "IE is eviiil" thing that Linux users love so much.

    In any case, nothing in your post justifies:

    1) Not even bothering to start fixing CSS2 until 2005, when it was clearly obvious the standard sucked significantly earlier
    2) Taking a fucking FIVE YEARS (and still counting!) to replace the shitty CSS2 standard, even after they started working on it
    3) Deciding that a hackish work around is "good enough" for non-reflowing columns instead of fixing it in the fucking standard itself
    4) All the other non-column-related shit about CSS mentioned in the other posts in this thread

    There really no way to get around the fact that the W3C sucks and has always sucked. They are even capable of taking good work done elsewhere (for example, the HTML5 spec) and turn it into suck using their special powers. The W3C is the best argument against standards committees I've ever seen.



  • @blakeyrat said:

    @Monomelodies said:
    There is one thing CSS /doesn't/ properly support, and that's a (say) 3 column layout where all the columns are forced to the same height.

    Ding ding ding, we have a winner. You've just described exactly what about 75% of websites want to do with columns. And, in the same sentence, admitted CSS doesn't support it.

    ORLY? I've got five open right now, and none of them do that (okay, I'm cheating a little cause one is a project I'm working on so I built it myself :)). Okay, I'm actually cheating a lot since one of the others is the phpMyAdmin interface and it DOES do it, only with a frameset. But the others are this wonderful forum and Facebook. And hey, guess what? Neither display this behaviour you seem to think is so common. I'm not saying it NEVER occurs, but it's by no means the glaring oversight you seem to think it is IMHO.

    @blakeyrat said:

    @Monomelodies said:
    And there's actually good reason for CSS not to support that: webpages weren't meant to be laid out in that way.

    Oh, so CSS doesn't support it because CSS was designed by some design-Nazi who wants to tell me how to lay out my webpage? That's even WORSE than me just assuming they're incompetent. (You're not helping your case here.)

     

    No, it was designed by people who had a strong idea of the medium "website", which is that it's a top-to-bottom display model, as opposed to the traditional "left-to-right" model in print.



  • @dhromed said:

    @Monomelodies said:
    why do you keep saying creating columns using floats is "a hack"? It's not, it's exactly what they're meant for. Let me explain.
     

    A person speccing out the behaviour of floats and then claiming it is intended to do columns, leaves me rather... underwhelmed. In fact, I doubt it's true. Do you have a reference for that?

    Not columns: it's meant to FLOAT stuff, and columns are, essentially, floating boxes. I fail to see the discrepancy here. And no, I don't have written proof of that, just like I can't prove to you 1 + 1 equals 2.

    @dhromed said:

    @Monomelodies said:
    You'll also want to be able to align it, and have the content superseding it to "wrap around" it

    Columns don't wrap. What you're referring to is, for example, the sidebox in Wikipedia articles, that sits in the text on the right, and text flows around it. That's good. I like that box, and it looks fine.

    I admit "wrap around" was a very poor choice of wording. I should have said "...and the content superseding it to not give a donkey's balls about the floated element and go about its own business". But, natively it WOULD wrap (like your Wikipedia example); it's just that you can prevent it wrapping (in a number of ways, but most common are a fixed width and/or a float on the other element, or give it a margin-left/right) if you so desire. If anyone can explain to me how a column is anything more than a floated box, with the adjacent content typically not wrapping around it, I'm all ears.

    @dhromed said:

    This is the advice I give to designers I work with: don't rely on stuff stretching down.

    Here's one thing we agree on. The first thing I tell designers is to NEVER rely on stuff stretching down when designing a web page. When they start out, they create designs with perfectly aligned boxes of the same height. I then ask them what they think will happen if a user has his or her font-size set to something different than them.

    @dhromed said:

    @Monomelodies said:
    And there's actually good reason for CSS not to support that: webpages weren't meant to be laid out in that way.

    Yes the are. It is the explicit intent of CSS to bring rich layouting and formatting abilities to web pages.

    See my earlier comment on left-right vs. top-bottom. Do you like to scroll horizontally? I didn't think so.


    @dhromed said:

    @Monomelodies said:
    Oh, and if you don't want to specify your colours all over the place, you can always group the declarations, as in "p, a, em, strong, div { color; red; }". CSS supports that perfectly, just not in the way that you'd LIKE it to work.

    That is true, but it doesn't solve the problem. It only moves it. Instead of hunting down colors when you want to modify them, you're hunting down selectors when you want to change an element.

    I only go that route — to great effect — when a website has some manner of skins of color schemes. Then one separates color definitions form the layout bits into a seperate stylesheet with the name of the scheme.

     

    Sure, and I agree some form of variables would quite often come in handy. I'm not saying CSS is perfect, but Blakey pretending it to be complete crap got me going. OTOH, changing a variable is hardly more effort than a global search/replace, and if done right you shouldn't need THAT much repetition. If you find yourself repeating certain colours all over the place, there's maybe something wrong with your entire setup (e.g., you have your defaults and exceptions the wrong way round). Of course, I can think of designs where it really would be a problem, but they're not the standard I think.



  • @blakeyrat said:

    @sprained said:
    They now exist in the spec and are supported in most of the non-IE browsers; the big holdup is, as usual, Internet Explorer.

    Considering how burned IE got when they implemented the CSS1 spec "early", you can't blame them for holding-out until CSS3 is final. You seem like a person who understands the history of the web, so I find it perplexing that you still repeat the "IE is eviiil" thing that Linux users love so much.

    In any case, nothing in your post justifies:

    1) Not even bothering to start fixing CSS2 until 2005, when it was clearly obvious the standard sucked significantly earlier
    2) Taking a fucking FIVE YEARS (and still counting!) to replace the shitty CSS2 standard, even after they started working on it
    3) Deciding that a hackish work around is "good enough" for non-reflowing columns instead of fixing it in the fucking standard itself
    4) All the other non-column-related shit about CSS mentioned in the other posts in this thread

    There really no way to get around the fact that the W3C sucks and has always sucked. They are even capable of taking good work done elsewhere (for example, the HTML5 spec) and turn it into suck using their special powers. The W3C is the best argument against standards committees I've ever seen.

     

    Chill.  I'm not trying to justify anything, and I totally agree that the W3C has been suckitudinous for at least a very long time.

    FWIW, they started CSS3 in '05 after finalizing CSS2 in '04, IIRC.  Not that that justifies taking 6 years to finalize CSS2.

    And the anger at MS over IE is partly over the fact that they took so freaking long to release *any* new browser after IE6 that the damn thing became ridiculously entrenched, and we're still (in places) having to deal with the POS.  It took them until IE8 to "fully" support CSS2; and I don't see that it would be unreasonable to start implementing parts of CSS3 that EVERY other browser in the world now support, since there are clauses in the CSS3 spec about de facto standards.  Meantime, us poor schlubs who work on the web still have to support IE7, probably for the next 7 years, and on corporate-targeted sites, STILL support IE6. Why even bother learning CSS3 if you won't be able to use reliably until 2017?



  • @Monomelodies said:

    @blakeyrat said:
    @Monomelodies said:
    There is one thing CSS /doesn't/ properly support, and that's a (say) 3 column layout where all the columns are forced to the same height.
    Ding ding ding, we have a winner. You've just described exactly what about 75% of websites want to do with columns. And, in the same sentence, admitted CSS doesn't support it.

    ORLY? I've got five open right now, and none of them do that (okay, I'm cheating a little cause one is a project I'm working on so I built it myself :)). Okay, I'm actually cheating a lot since one of the others is the phpMyAdmin interface and it DOES do it, only with a frameset. But the others are this wonderful forum and Facebook. And hey, guess what? Neither display this behaviour you seem to think is so common. I'm not saying it NEVER occurs, but it's by no means the glaring oversight you seem to think it is IMHO.

     

    You sample set is 5 websites, one of which you designed?  You really need to stop feeding the Blakeyrat.

    @Monomelodies said:

    @blakeyrat said:
    @Monomelodies said:
    And there's actually good reason for CSS not to support that: webpages weren't meant to be laid out in that way.
    Oh, so CSS doesn't support it because CSS was designed by some design-Nazi who wants to tell *me* how to lay out *my* webpage? That's even WORSE than me just assuming they're incompetent. (You're not helping your case here.)
     

    No, it was designed by people who had a strong idea of the medium "website", which is that it's a top-to-bottom display model, as opposed to the traditional "left-to-right" model in print.

    Blakey accusses CSS of being designed by someone intent on enforcing his personal vision, and you respond by arguing the exact same thing.



  • @Monomelodies said:

    Here's one thing we agree on. The first thing I tell designers is to NEVER rely on stuff stretching down when designing a web page. When they start out, they create designs with perfectly aligned boxes of the same height. I then ask them what they think will happen if a user has his or her font-size set to something different than them.

    I expect all of my columns to extend equally, as if the columns were related somehow (perhaps in a table).

    @Monomelodies said:

    If anyone can explain to me how a column is anything more than a floated box, with the adjacent content typically not wrapping around it, I'm all ears.

    A column is a box with the same height as each of its neighbor boxes.

    @Monomelodies said:

    Sure, and I agree some form of variables would quite often come in handy. I'm not saying CSS is perfect, but Blakey pretending it to be complete crap got me going. OTOH, changing a variable is hardly more effort than a global search/replace, and if done right you shouldn't need THAT much repetition. If you find yourself repeating certain colours all over the place, there's maybe something wrong with your entire setup (e.g., you have your defaults and exceptions the wrong way round). Of course, I can think of designs where it really would be a problem, but they're not the standard I think.

    When using a variable, you can be sure that when you change its value, it changes in every relevant location, and no others.  Search-and-replace easily lends itself to clbuttic mistakes.



  • @Monomelodies said:

    See my earlier comment on left-right vs. top-bottom. Do you like to scroll horizontally? I didn't think so.

    It doesn't matter what I like or dislike. C# doesn't tell me what kind of applications I can build, and CSS sure as shit shouldn't tell me what kind of websites I can build. Here's a short play in one act to demonstrate what you're defending:

    Contractor A: "This hammer can only build apartment buildings. If you want to build a garage, you can't use this hammer."
    Contractor B: "Well, ok, hand me the garage hammer."
    Contractor A: "No such thing."
    Fin.

    @Monomelodies said:

    I'm not saying CSS is perfect, but Blakey pretending it to be complete crap got me going.

    I don't think it's complete crap, I just use a lot of hyperbole because it makes my writing funnier.



  • @HighlyPaidContractor said:

    Blakey accusses CSS of being designed by someone intent on enforcing his personal vision, and you respond by arguing the exact same thing.

    Some people obviously never took debating class in high school.



  • @sprained said:

    And the anger at MS over IE is partly over the fact that they took so freaking long to release any new browser after IE6 that the damn thing became ridiculously entrenched, and we're still (in places) having to deal with the POS.

    When you think Microsoft think "pragmatic." Why should they bother releasing a browser when they have ~95% market-share with zero effort? Hell, from Microsoft's pragmatic perspective, they'd be stupid to waste the time working on IE. (BTW, take a look at Office and note which applications in it suck. Excel and PowerPoint. The two that have the least effective competition.)

    In other words, if the Mozilla people wanted IE to improve, they should have actually been releasing products. Once you understand how Microsoft works, you realize they had only themselves to blame.

    Plus, what a lot of the anti-IE squad forgets, IE6 wasn't actually *preventing* you from doing anything. It just made things a little more difficult, and harder to QA. You could still write AJAX sites. (I love to quiz the anti-IE people, "ok, tell me what, exactly, IE6 was missing that prevented you from writing your killer website?" I've never gotten an answer.) A lot of products, including AJAX-y ones like 37Signals stuff and Gmail, made a lot of money on the web despite IE6 having a monopoly.

    Note that as soon as IE got some effective competition, development of new IE versions re-started as if it never stopped. IE8 is complaint with virtually every released standard currently. And when IE9 is released they'll be back on-par with everybody else, including the unreleased standards.

    @sprained said:

    It took them until IE8 to "fully" support CSS2; and I don't see that it would be unreasonable to start implementing parts of CSS3 that EVERY other browser in the world now support, since there are clauses in the CSS3 spec about de facto standards.

    Fool me once, shame on you...

    @sprained said:

    Meantime, us poor schlubs who work on the web still have to support IE7, probably for the next 7 years, and on corporate-targeted sites, STILL support IE6.

    Yup, but again: what exactly is IE6 missing that prevents you from creating your awesome AJAX site? Google can pull it off, why can't you?

    @sprained said:

    Why even bother learning CSS3 if you won't be able to use reliably until 2017?

    To be fair, Microsoft is trying to kill-off older IE versions as much as everybody else. The problem is that they're contractually obligated to support IE6 as long as they support XP, which is until 2014 (unless the date has shifted recently). If they would weasel out of that contract without being sued, you bet your ass they'd do it in a heartbeat.



  • @blakeyrat said:

    [Note that as soon as IE got some effective competition, development of new IE versions re-started as if it never stopped. IE8 is complaint with virtually every released standard currently. And when IE9 is released they'll be back on-par with everybody else, including the unreleased standards.

    @sprained said:

    It took them until IE8 to "fully" support CSS2; and I don't see that it would be unreasonable to start implementing parts of CSS3 that EVERY other browser in the world now support, since there are clauses in the CSS3 spec about de facto standards.

    Fool me once, shame on you...

    @sprained said:

    Meantime, us poor schlubs who work on the web still have to support IE7, probably for the next 7 years, and on corporate-targeted sites, STILL support IE6.

    Yup, but again: what exactly is IE6 missing that prevents you from creating your awesome AJAX site? Google can pull it off, why can't you?

    @sprained said:

    Why even bother learning CSS3 if you won't be able to use reliably until 2017?

    To be fair, Microsoft is trying to kill-off older IE versions as much as everybody else. The problem is that they're contractually obligated to support IE6 as long as they support XP, which is until 2014 (unless the date has shifted recently). If they would weasel out of that contract without being sued, you bet your ass they'd do it in a heartbeat.

     

    Google doesn't support IE6 any more.  Consider using a different argument.

    Anyway, as for CSS,  absolute positioning exists and does what most websites actually want when they say they want columns... they want their navigation to appear to the left or right of their normal content.  Fixed positioning, where only one part of a page scrolls, also exists, but is not supported in (you guessed it) IE6.  Luckily, IE6 is being killed off, with major companies refusing to support it any longer (Google and Microsoft to name two).



  • @blakeyrat said:

    In other words, if the Mozilla people wanted IE to improve, they should have actually been releasing products.

    So Mozilla Suite (later Seamonkey) 1.0 - 1.7 and Firefox 1.0, 1.5, and 2.0 don't count?  How about Safari 1.0, 2.0, 3.0, or Opera 7.5, 8, and 9?

    Plus, what a lot of the anti-IE squad forgets, IE6 wasn't actually *preventing* you from doing anything. It just made things a little more difficult, and harder to QA. You could still write AJAX sites. (I love to quiz the anti-IE people, "ok, tell me what, exactly, IE6 was missing that prevented you from writing your killer website?" I've never gotten an answer.)

    Missing?  How about hover states on non-link elements.  PNG-24 transparency (there are partial workarounds, but for instance you couldn't use a transparent PNG as a background image if you wanted a link above it).  Z-indexing (changing which elements appear on top of others).  Position:fixed.  Max-width and max-height.  Proper background image positioning.  Zooming of text specified in pixel sizes.  Proportional adjustment of pixel-size line heights upon text zoom.  (Remember when font-size stylesheet switchers were all the rage?  That was why.) Fucking HTML comments (or display:none elements) directly following floated elements (explanation here). 

    Not to mention the aspects that could be worked around but were a giant goddamn pain in one's ass: Quirks mode.  Attribute selectors.  Child and sibling selectors.  Pseudo-classes.  Margins doubling on floated elements.  Really bizarre margin and padding bugs that resulted in stair-stepping of list elements.  Content properties.  Overflow properties.  display:table et al.  text-align:center centering block-level elements as well as text.  A zillion things that would break if you used them in the wrong combinations.  And don't even get me started on hasLayout.  IE quadrupled the time required to implement a lot of things, and mastery of all its quirks took fucking ninja skills.

    And finally, if you were ever stuck having to use the damn thing as your primary browser, the simple lack of tabs or any semblance of a popup blocker could quickly drive a "power user" (read: someone who works on the web and often has 30 pages open at once)to the loony bin.

    Yup, but again: what exactly is IE6 missing that prevents you from creating your awesome AJAX site? Google can pull it off, why can't you?

    Maybe because, in case you hadn't noticed, Google has a hell of a lot more resources than your average indie web shop.  Besides, it's not the "awesome Ajax site" I'm concerned about.  With a good framework like jQuery you can make IE 6 do most of the interactive things you want, sure. 

    It's the many times as long it takes to code a design to work in IE 6 as it does in a standards-compliant browser, and the fact that it requires more complex (i.e. less maintainable) HTML and CSS, and that some things simply can't be done.  These days it's all well and good to say "oh, it's OK if it doesn't look quite as good as in Webkit because that transparent PNG doesn't work in IE 6 and we can't do the rounded borders" ... but in 2005, when the client was using IE6 (or worse, IE5.5) and hadn't even heard of Firefox?  Then you spent the better part of a week creating ugly hacks to work around the damn bugs, and if you were really unlucky, finally had to go back to the client and tell them that the gorgeous design they'd handed off to you simply couldn't be implemented.  At least, not in their browser.

    EDITED TO ADD:

    @powerlord said:

    Anyway, as for CSS,  absolute positioning exists and does what most websites actually want when they say they want columns... they want their navigation to appear to the left or right of their normal content.

    The trouble is that there's no way to clear an absolutely-positioned element to make a footer display beneath it.  If more than one of your columns are variable-length and you need a footer, absolute positioning won't work.

     



  • @powerlord said:

    Google doesn't support IE6 any more. Consider using a different argument.

    Gmail became popular with ~95% of web users were on IE6. In the context of the discussion ("IE6 isn't nearly as bad as people say"), the argument makes perfect sense.



  • @sprained said:

    So Mozilla Suite (later Seamonkey) 1.0 - 1.7 and Firefox 1.0, 1.5, and 2.0 don't count?  How about Safari 1.0, 2.0, 3.0, or Opera 7.5, 8, and 9?


    Mozilla Suite was a bloated, buggy hog just as bad as Netscape 4.7 back in the day. It certainly wasn't displacing IE users

    Firefox wasn't effectively displacing IE installs until it hit version 1.5 or so; at which time Microsoft was already working on IE7. (Heck, Firefox 2 and IE7 were both released in October, 2006)

    Safari didn't exist on Windows until 2007, and wasn't effectively competing with IE until they fixed the font rendering (which I believe was in mid-2008 or so)

    Opera wasn't free until April, 2007 at which point (again) Microsoft was already working on IE development. (Not that anybody adopted Opera after it went free, anyway)

    So in conclusion, no. None of those count really.

    @sprained said:

    And finally, if you were ever stuck having to use the damn thing as your primary browser, the simple lack of tabs or any semblance of a popup blocker could quickly drive a "power user" (read: someone who works on the web and often has 30 pages open at once)to the loony bin.

    IE6 has had a pop-up blocker since August, 2004. I find it odd you can come up with 2 paragraphs of highly specific IE6 flaws, then make an error like this... are you sure you've used IE6?

    @sprained said:

    Maybe because, in case you hadn't noticed, Google has a hell of a lot more resources than your average indie web shop.

    So...? I didn't say it could be done easily or cheaply, I said it could be done.

    @sprained said:

    Besides, it's not the "awesome Ajax site" I'm concerned about.  With a good framework like jQuery you can make IE 6 do most of the interactive things you want, sure. 

    So... you agree with me? Why the long post then?

    @sprained said:

    It's the many times as long it takes to code a design to work in IE 6 as it does in a standards-compliant browser, and the fact that it requires more complex (i.e. less maintainable) HTML and CSS,

    Yeah, well, nobody said it would be easy going in. As someone who coded plain old C on Mac Classic with no pre-emptive multitasking or protected memory, I have little sympathy-- debugging web apps is trivial in comparison. In addition to my other egging-on, web developers are cry-babies. Cry more, baby.

    @sprained said:

    and that some things simply can't be done.

    Like what?



  • @blakeyrat said:

    Yeah, well, nobody said it would be easy going in. As someone who coded plain old C on Mac Classic with no pre-emptive multitasking or protected memory, I have little sympathy-- debugging web apps is trivial in comparison. In addition to my other egging-on, web developers are cry-babies. Cry more, baby.
     

    Waaaaaah!  Fine, your dick is bigger than mine.  Happy?



  • @blakeyrat said:

    I just use a lot of hyperbole because it makes my writing funnier.
     

    That kind of thing never works.



  • @dhromed said:

    @Monomelodies said:
    Oh, and if you don't want to specify your colours all over the place, you can always group the declarations, as in "p, a, em, strong, div { color; red; }". CSS supports that perfectly, just not in the way that you'd LIKE it to work.

    That is true, but it doesn't solve the problem. It only moves it. Instead of hunting down colors when you want to modify them, you're hunting down selectors when you want to change an element.

    I only go that route — to great effect — when a website has some manner of skins of color schemes. Then one separates color definitions form the layout bits into a seperate stylesheet with the name of the scheme.

     

    <style>
      .strong { color: red; }
      .large { font-size: 20px }
    </style>

    <p class="large strong">Zero maintenance</p>



  •  @JvdL said:

      .large { font-size: 20px }

    You don't get to talk about CSS anymore.



  • @dhromed said:

     @JvdL said:

      .large { font-size: 20px }

    You don't get to talk about CSS anymore.

     

    Request denied.

    My point was not about pixels or font sizes in particular but this: Different classes can style different aspects of the layout. By combining several such aspect classes on one element you can easily modify a particular aspect (like  strong color) without changing anything in HTML and by changing just one line in the CSS.



  • ...assuming it has a perfectly adequate class scheme to start with

    ...unless you're forced to use wrappers for layouts

    And if you use the same company-approved color for the header text as you do for the background of the nav links and the border color of the content box, you end up repeating yourself in the CSS.  I mean, even if you do sane stuff like this, it's still not optimal:

    h1,h2,h3,h4 { color: trademarkedblue; }
    .content { border-color: trademarkedblue; }
    .nav-links { background-color: trademarkedblue; }

    But oh wait, we can't have the background color of the .nav-links be trademarkedblue because it's burried in 3 div wrappers in order to position it off to the left and vertically centered (which may I add is a pain and a half with CSS).

    .nav-links-wrapper-wrapper { border-color: trademarkedblue; }

    Multiply that times a mildly complex layout and you're back to the problem stated by dhromed.

    What we want is to style HTML like this in any way we want:
    <body><ul class="nav-links">...</ul><div class="content">...</div></body>

    But invariably what we end up with is a unsemantic mess just to get CSS to work:

    <body><div class="nav-links-wrapper-wrapper left"><div class="nav-links-wrapper please-make-it-center"><ul class="nav-links disable-builtin-styles"><li class="nav-link"><span class="inside-nav-link">... [etc etc etc]



  • @dhromed said:

    @blakeyrat said:

    I just use a lot of hyperbole because it makes my writing funnier.
     

    That kind of thing never works.

    Not sure if serious...

    Well, I think my writing is hilarious, and that's all that matters really.



  • @blakeyrat said:


    Opera wasn't free until April, 2007 at which point (again) Microsoft was already working on IE development.

    September 2005, but don't let facts get in the way of your rant.

    @blakeyrat said:

    (Not that anybody adopted Opera after it went free, anyway)

    This is the important part, not Opera's free release date.  Hell, I used Opera for several years, but even to technical people, they seemed to make a number of technical gaffes (and random UI changes between versions) that eventually got me to move back to Firefox.



  • @powerlord said:

    @blakeyrat said:


    Opera wasn't free until April, 2007 at which point (again) Microsoft was already working on IE development.

    September 2005, but don't let facts get in the way of your rant.

    Sorry; I opened up the Wiki page and searched "free". Mis-read the search results, and copied the wrong date. (Apparently that was when the Wii version was free to download.)


Log in to reply