CSS is for wimps
-
@dhromed said:
In CSS, you have selectors, which are a kind of nephew to XPath,
I don't know jack shit about XPath, so that doesn't help me.
@dhromed said:
I hope I'm not being too patronizing or vague, but you say you can't wrap your head around it and don't ask a direct question so I can't give a direct answer.
I'm not writing any CSS at the moment. But the exact problem is that I really don't have direct questions... when I'm working on it, the questions are like "why is this thing over on the left when I said it should float right?" "Why is that box taller than the other when they have the same class?" stuff like that. The questions pretty require a webex or something, and since I'm not working on it at the moment, I can't provide one at the moment.
When I say I can't wrap my head about it, what that means is that I can't get a screenshot or Photoshop of what a webpage should look like, then duplicate that look in CSS, without a lot of trial and error. Unlike programming, where someone can give me the spec for a program and I can write the whole thing up without ever executing the code, and usually end up with something that comes pretty close to meeting the spec (barring bugs).
Instead, the way I end up working is creating all the needed DIVs, then basically 'cheat-coding" them somehow (usually with a background color), then just dinking with the CSS until they all seem to be in the right place in most browsers at most window sizes. "Dinking" meaning, in general, trial-and-error. Then, invariably, when I add content, I need to do more dinking.
(Or, the alternative is, I just find a webpage that already looks like the one I want, and rip-off their CSS.)
I'm sure there's *someone* out there who can "parse" the CSS in their head, and say "oh to get result X you need to add a clear:both on element Y". But I ain't one of those people, and I don't think I ever will be. Maybe I have a defective brain; like I said, I also dropped out of college because after 4 course with 4 different profs, I still couldn't wrap my head around Calculus. (This is the point where you point and laugh and call me stupid. But I was smart enough to realize calculus doesn't mean shit when you want to program UIs, and get out of that worthless school, and now I'm making more than most of my classmates. So there.)
But more to the point: CSS is *not* an easy language for me. It might be easy to learn the syntax, but it's certainly not easy from a "how to do the thing I want it to do" perspective. And even when I'm using GUI editors, I end up doing trial-and-error, it just makes the trial-and-error cycle faster.
-
@Rootbeer said:
In short, the entire HTTP/HTML/CSS/JS technology stack is four kinds of shit piled on top of each other.
I can't wait for Google to come up with a sane, integrated alternative and add support for it to Chrome.
JS is a good kid! He's just in a bad neighborhood, and foster parents never gave him the love and respect he needed.
When Silverlight first came out, I actually was hoping and praying it would be the thing you describe, but being Microsoft automatically means 40-50% of Linux-snob/OS X-snob web developers will never use it.
And of course, nothing will remove legacy sites from the web. In the year 2085, browsers will still have to parse this pile of crap (view source). (Edit: oh wow, JCP has improved their site. It used to have no BODY tag-- at all. And HEAD was called "HEADER". Still fucking awful, though.)
-
@dhromed said:
@blakeyrat said:
CSS is not a simple language; I've been trying to learn it for 5 years and failing.
I don't understand why that is. It really is a rather rudimentary descriptive syntax. It doesn't even support variables and dynamic stuff. Regex is more complex.
See my latest reply. The syntax isn't the issue, and in fact two of my complaints are that it doesn't support variables, and it doesn't support "dynamic stuff" (that is, simple addition of two measures.) I get variables; if I knew the rest of CSS, variables wouldn't throw me, they'd help me.
(BTW, I don't really get RegEx either, and avoid it whenever possible. You guys should know by now that I don't have the "geek brain". If I did, I'd probably be fucking awful at usability and better at things like "making CSS work for me".)
-
@blakeyrat said:
CSS selector
property. ;)
So yeah, CSS has its share of shit. A broad range of browsers with varying levels of support constitutes about 70% of the headaches.
-
-
@dhromed said:
@blakeyrat said:
CSS selector
property. ;)
See I can't even wrap my head around the terminology! :)
@dhromed said:
You poor alpha.
I don't get it.
-
This has been one of the most enjoyable threads ever. Like many people, I've read all the articles that say "tables are stupid and evil -- use CSS you moron!". But many years later I still find CSS utterly confounding. I just thought I must be a complete retard, but it's nice to learn that it's not just me, CSS really is a confusing pile of suck.
-
@blakeyrat said:
@dhromed said:
See I can't even wrap my head around the terminology! :) @dhromed said:@blakeyrat said:
CSS selector
property. ;)
You poor alpha.
I don't get it.Alpha male?
-
@blakeyrat said:
when I'm working on it, the questions are like "why is this thing over on the left when I said it should float right?" "Why is that box taller than the other when they have the same class?"
Firebug and the WebKit Inspector can really shed light on questions like that. I find it highly impractical to develop HTML+CSS without Firebug.
@blakeyrat said:
Instead, the way I end up working is creating all the needed DIVs, then basically 'cheat-coding" them somehow (usually with a background color)
I do the same. Write HTML first in a proper, meaningful structure with standard snippets that I've been using and tweaking or the past years, and then I add CSS. I add background colors to elements to see where they go because it's just silly to not do that. The outline: property is handy for adding borders that do not affect layout.
@blakeyrat said:
I still couldn't wrap my head around Calculus.
Then you're in luck, because calculus is an order of magnitude more difficult than CSS rendering. All you need to calculate in CSS is width + padding + border + margin.
As I said earlier, 70% — maybe 90% — of CSS headaches are rendering inconsistencies across browsers, and the plethora of %$#! gotchas that are encoded in the spec as proper behaviour. Floating, collapsing margins and selector specificititycifytyficty* are such beasts. The rest is just things like, "Hey CSS, make it that width." "OK". "Now, that background image" "Sure,". "Dashed border, please" "There you go."
*) fucking fuck
-
@blakeyrat said:
@dhromed said:
You poor alpha.
I don't get it.
Alphas en Betas.
As in, Language, Art, History, etc, versus Math, Physics, Biology, Chemistry.
Is this distinction not used in places other than Dutchland?
-
@dhromed said:
Is this distinction not used in places other than Dutchland?
It would appear not. Even the Flemish can't adhere to this simple categorisation.
I guess blakey might be more of a Γ btw.
-
@dhromed said:
@blakeyrat said:
And the state of quirks mode, and the [code]display[/code] mode, and the [code]position[/code] mode, and the subtle interactions between what you tell it and the 90s-era built-in styles, and if the style applies to itself or its children, etc, etc...I still couldn't wrap my head around Calculus.
Then you're in luck, because calculus is an order of magnitude more difficult than CSS rendering. All you need to calculate in CSS is width + padding + border + margin.I would take high-order differential equations over CSS almost any day. At least the answer is always correct.
-
@dhromed said:
@blakeyrat said:
@dhromed said:
You poor alpha.
I don't get it.
Alphas en Betas.
As in, Language, Art, History, etc, versus Math, Physics, Biology, Chemistry.
Is this distinction not used in places other than Dutchland?
It may be related to the concept of right brain vs. left brain thinkers, which was a popular pop-psychology concept in the US during the 1990s. Supposedly the left hemisphere of the brain is, in most people, more devoted to logical, objective, low-level analysis, while the right hemisphere is more intuitive, subjective, and high-level. It's common for people who don't know anything about human psychology to try to pigeonhole people into one group or the other.
-
@Rootbeer said:
In short, the entire HTTP/HTML/CSS/JS technology stack is four kinds of shit piled on top of each other.
I can't wait for Google to come up with a sane, integrated alternative and add support for it to Chrome.
Yes, and then cancel it or keep it in perpetual beta forever.
The original post was about the fact that frontpage was using ActiveX and Java applets to do simple navigation. ActiveX and Java were supposed to be the "sane" replacement for the standard HTTP stack back in in 1998 and we see how well that turned out. Like it or not, the HTTP stack is mature, proven and people have been able to do some miraculous stuff with it. As I've said before, some people whined, other people solved it and moved on.
-
@El_Heffe said:
This has been one of the most enjoyable threads ever. Like many people, I've read all the articles that say "tables are stupid and evil -- use CSS you moron!". But many years later I still find CSS utterly confounding. I just thought I must be a complete retard, but it's nice to learn that it's not just me, CSS really is a confusing pile of suck.
And that's how a "tables are fine for layout, who cares if it sucks for mobile/accessibility/etc. it looks fine on my desktop" advocate is born.
-
@Soviut said:
Yes, and then cancel it or keep it in perpetual beta forever.
This is how we get stuck with 386 architecture on the desktop and COBOL running our banks and healthcare systems. We can do better!The original post was about the fact that frontpage was using ActiveX and Java applets to do simple navigation. ActiveX and Java were supposed to be the "sane" replacement for the standard HTTP stack back in in 1998 and we see how well that turned out. Like it or not, the HTTP stack is mature, proven and people have been able to do some miraculous stuff with it. As I've said before, some people whined, other people solved it and moved on.
What we really need is two distictly defined protocols: one for stateful transactions and one for stateless transactions. In my numerically-fictious opinion, 90% of the web server messes, application server behemoths, security oopsies, and client-side garbage is caused from toggling between stateless and stateful protocols down the modern web app stack from AJAX down to IP. It's pretty dumb. Of course, that has nothing to do with the annoyances of HTML and CSS, but if we're going to burn down the house, we might as well burn down the planet!
-
@El_Heffe said:
I just thought I must be a complete retard, but it's nice to learn that it's not just me, CSS really is a confusing pile of suck.
I'm glad other people feel that way, too. I was almost certain that there's a significant number of people who do CSS via guess-and-check, since I have several co-workers who do, but it's good to see the confusion is bigger than our little group.
@serguey123 said:
Alpha male?
That was my guess, but it really doesn't fit. Alpha males are almost always non-geeks, but non-geeks aren't necessarily alpha males. (Think about Ralph Wiggum from The Simpsons, for example.)
@dhromed said:
Firebug and the WebKit Inspector can really shed light on questions like that.
They can tell you what styles are attached to a particular element, but they don't shed any light on the more important question: "why does it look how it does?" Or, more precisely, "how do the styles on this element relate to the elements around it?" Knowing an image has "float:right" doesn't help when you're trying to figure out why the holy fuck the image is on the left-hand side of the window.
@dhromed said:
Is this distinction not used in places other than Dutchland?
I have no fucking clue what you're talking about. But here's a quick little hint: here in the US? We don't label people. At least not institutionally.
@Xyro said:
And the state of quirks mode, and the display mode, and the position mode, and the subtle interactions between what you tell it and the 90s-era built-in styles, and if the style applies to itself or its children, etc, etc...
I would take high-order differential equations over CSS almost any day. At least the answer is always correct.
Thank you, this is pretty much exactly the shit I'm talking about. Look, I don't like DOM. But if I put: "setTimeout( DoStuff, 500 );" in a JavaScript, I know that in (close to) 500 milliseconds the function DoStuff() will be called. I know it. It's deterministic. If I type "a = a + 1" in JavaScript, there's only two possible results, and I know exactly which one I'll get. (Depending on the type of a.)
CSS is the same way for some properties, but not other. Take the border example: border: 3px solid black. Usually, about 80%+ of the time, that'll add a thick black border around an element. The rest of the time it'll also change the position of the element.
Now, intellectually, I know that the position changed because the border is added outside the CSS box, and the width of the element changed to exceed the width of its container, and so it was moved down to "the next line", the way a long word would be moved to the next line if I typed it into a text box. Maybe I couldn't have predicted it, because the parent was defined in terms of % and my border is in terms of pixels. But, intellectually, I know what causes this.
But that still doesn't change the fact that, when adding a border to an element, I have no shitting clue what the resulting page will look like. And that's a simple case! Trivial!
With C#, JavaScript, etc, I feel like I'm in control. I have understanding of how everything works, I know before I type a statement exactly what the result of that statement will be. CSS? CSS feels non-deterministic to me, like it's under the control of some hostile omnipotent computer entity.
-
@Soviut said:
ActiveX and Java were supposed to be the "sane" replacement for the standard HTTP stack back in in 1998 and we see how well that turned out.
No they weren't.
@Soviut said:
Like it or not, the HTTP stack is mature, proven and people have been able to do some miraculous stuff with it.
The reason the stuff is "miraculous" is because they're bending and twisting it into applications it was never designed for. If it was designed to do stateful e-commerce transactions in the first place, you wouldn't have to do "miraculous" things because it would be fucking designed for it.
The fact that an entire industry, a huge one, depends on bending and twisting a protocol like this is not a good thing, it's a terrible thing.
It's exactly like (to use your own example against you) using fucking Excel to make resumes! Except the whole fucking INDUSTRY is using Excel, and we've happened to get good enough that the resumes don't entirely suck, and there's even people like you going "hey guys, Excel is awesome! it can do everything we need!" and the people like Silverlight developers are going, "hey we invented this thing called 'Word', it's really good for resumes" and you're going, "but we're not going to use it because your Excel templates aren't very good, also we have a new version of Excel which lets us make slightly more complicated resume templates, so we don't need your 'Word' abomination."
(Edit: I'm bolding this paragraph because I think it's important.)
That metaphor sucks, but I hope you get the point.
@Soviut said:
As I've said before, some people whined, other people solved it and moved on.
The two are not mutually-exclusive. I'd actually expect the people who are "solving it" (via stupid workarounds) to be the ones "whining" (pointing out its flaws) the loudest.
@Soviut said:
And that's how a "tables are fine for layout, who cares if it sucks for mobile/accessibility/etc. it looks fine on my desktop" advocate is born.
You haven't yet demonstrated there's anything wrong with using tables for layout. I know it works on mobile devices; I have a fucking Android phone in my pocket and a iPhone on my desk. I know it works for accessibility apps, since those apps existed before CSS did. You have to provide evidence, not just repeat it over and over.
-
@blakeyrat said:
But the exact problem is that I really don't have direct questions... when I'm working on it, the questions are like "why is this thing over on the left when I said it should float right?" "Why is that box taller than the other when they have the same class?" stuff like that. The questions pretty require a webex or something, and since I'm not working on it at the moment, I can't provide one at the moment.
When I say I can't wrap my head about it, what that means is that I can't get a screenshot or Photoshop of what a webpage should look like, then duplicate that look in CSS, without a lot of trial and error. Unlike programming, where someone can give me the spec for a program and I can write the whole thing up without ever executing the code, and usually end up with something that comes pretty close to meeting the spec (barring bugs).
No disrespect intended, but you simply don't understand CSS, and therefore are of the (misguided) opinion that "it must suck" - after all, YOU don't get it. Whereas probably, the problem isn't in fact with CSS, but with your less-than-perfect understanding of it. Yes, that was meant to sound cynical.
Now, CSS isn't perfect, I'll definitely grant you that. Then again, what is? Silverlight sure as hell ain't - I'll need a plugin that doesn't exist for many platforms. And don't even get me started on its binary nature (the web being a plain-text medium).
Multi-column layout? Won't be in CSS 'till version 3. I miss it too, every once in a while. But, you know what? CSS was designed for webpages, and webpages have vertical orientations, not horizontal ones. Fluid column layout in webpages rarely makes sense, they ain't no newspapers or magazines (though this is likely to change with the advent of tablets, but you can't blame the W3C for not foreseeing that. Oh wait, it's in CSS3 so they did actually foresee it).
Floats. Ah, floats. Perfectly logical (and used for a lot more things than mimicking fluid columns, mostly, erm, floating stuff) IF you take the time to actually read up on how they work. It's really not that hard, but if you'd rather go mope in a corner about how they don't do what you THINK they should do, be my guest.
Properties are, on the whole, perfectly logical. A few edge cases require memorisation. Name me one program language where they don't (okay, Python maybe).
And what's with the rant on CSS-style comments? They're perfectly C-style. HTML, THAT uses a weird (though perfectly understandable) commenting syntax.
What I find the weirdest is that you pride yourself on your skills in UI design. Yet you constantly approach CSS (and, presumably, HTML) as if they were some sort of programming language. They're not; they're markup languages. An entirely different cup of tea. A UI designer should be able to grasp that, methinks. This is precisely why they don't support variables etc. If you want those, generate your HTML with a scripting language (there's a fair bunch out there, take your pick) and, if you must, bung your CSS through something like LESS or SASS.
To be fair, I've rediscovered tables recently as a very handy tool to mimick Flipbook-style pages. But then, CSS was never meant to do that, so I can't blame it for not supporting it.
-
@Monomelodies said:
No disrespect intended, but you simply don't understand CSS, and therefore are of the (misguided) opinion that "it must suck" - after all, YOU don't get it. Whereas probably, the problem isn't in fact with CSS, but with your less-than-perfect understanding of it. Yes, that was meant to sound cynical.
If it's hard-to-learn, it sucks.
@Monomelodies said:
(the web being a plain-text medium).
It only is because we say it is. Why does it have to be? Why should it be? Why couldn't an entire hyperlinked web of Silverlight documents work just as well or better?
@Monomelodies said:
Fluid column layout in webpages rarely makes sense, they ain't no newspapers or magazines (though this is likely to change with the advent of tablets, but you can't blame the W3C for not foreseeing that. Oh wait, it's in CSS3 so they did actually foresee it).
You're missing the point:
*All* columns in CSS, re-flowing or not, are a hack. The "float" property was not designed to create columns; that it does works only by accident. Which is why it's so fucking awful at it. Re-flowing columns like in CSS3 will be nice to have, but being able to specify normal non-flowing columns in a non-WTF way is just as important. CSS2 has no support for columns of any kind, making it (functionally) equivalent to table layouts which also have no support for columns of any kind.
When I say *all* columns, I mean *all* columns... even those without articles. That means that your left-hand webpage navigation menu? It's a hack. CSS2 has no explicit support for something like that, the only way to get it is to abuse the "float" property to do something it wasn't intended to do.
(Another related WTF: the "float" hack to create columns is so universal now that people apparently don't consider it a hack anymore.)
@Monomelodies said:
What I find the weirdest is that you pride yourself on your skills in UI design. Yet you constantly approach CSS (and, presumably, HTML) as if they were some sort of programming language. They're not; they're markup languages.
1) WTF does CSS have to do with usability?
2) I realize that aren't programming languages, but if the *markup* language defines measures that are meaningful at design-time (like pixels) and measures that are only meaningful at run-time (like ems) and you can't fucking add them together, then it's a woefully incomplete *markup* language.
The lack of variables also makes it hard for CSS to do the very thing it's (purportedly) designed to do: centralize all style descriptions in one place. If you have a single background color, you might need to use it 5, 10, 25 times in the same CSS document. What if I want to change the fucking background color? Find-and-replace, that's all we got.
-
Wow. Lot of hatred for CSS here.
CSS layout basically requires learning three things:
1) The box model (width, padding outside width, borders outside padding, margins outside borders. That simple). Of course, earlier versions of IE completely screwed this up (even if their interpretation was arguably more sensible), so we're only finally getting to a place where it's reliable (especially since IE 6 tended to revert to the broken model if you gave it the wrong doctype).
2) The positioning model. "Relative" and "absolute" positioning are confusing at first, and maybe not well named, but in the end it's fairly straightforward: "relative" moves an element compared to where it would be if you didn't move it. "Absolute" sets the location within the nearest relatively-positioned ancestor (or the document if there is no relative ancestor.
3) The float model. Think of a floated element as comparable to an image in a magazine that has text wrap around it. If you want columns that don't wrap, you have to float both columns (typically in opposite directions). What gets confusing is that a non-floated parent of a floated element does not by default expand vertically to contain the floated element, so you end up with messy clearing hacks that force the parent to expand. However, simply setting "overflow: hidden" or "overflow: auto"on the parent, you can force it to expand to contain the floated child.
Of course, IE tends to be broken about a lot of things, and to get it to behave correctly, you need elements to have the hasLayout property set, which can typically be accomplished by either setting an explicit width/height on an element, or setting "zoom:1" (a proprietary IE property that I think has something to do with resizing, but doesn't seem to affect anything other than hasLayout.) You'll have a much easier time understanding CSS if you develop it in a Gecko or Webkit browser than in Trident.
Vertical centering is a WTF (although it now works in non-IE browsers if you set the parent element to "display:table" or "display:table-cell"; and you can vertically center single-line text using line-height). The proprietary versions of properties are also a WTF, although my understanding is that they essentially relate to the fact that CSS3 STILL hasn't been finalized as a standard: the browser devs don't want to put the properties into the official namespace until they're certain they'll comply with the eventual standard.
Not being able to combine pixels and ems and percentage values in a single property declaration is a slight WTF and immensely infuriating, and basically makes flexible layouts that depend on graphics a humongous pain in the rear.
Since learning CSS, I find table-based layouts tremendously inflexible and infuriating. The simplicity of markup in a properly-designed CSS-based layout is a joy. Nested tables, by contrast, are a giant freaking pain in the rear, and miserable to reconfigure without a graphical tool like Dreamweaver. (I will admit that poorly marked-up pages for CSS layouts are not a *whole* lot better. Learn your HTML instead of using divs for EVERYTHING.)
Could CSS be better? Sure. Is it difficult to learn? Not if you choose the right teaching sources and apply yourself. Is it a tremendous WTF? Not at all. It's a tool that allows the presentation of content to be separated from the content itself. It allows you to present separate desktop and mobile and print layouts for the same content using nothing but 3 different stylesheets linked from the same page, rather than writing three different views in your application to generate different markup. What's WTF-y about that?
-
@dhromed said:
@blakeyrat said:
@dhromed said:
You poor alpha.
I don't get it.
Alphas en Betas.
As in, Language, Art, History, etc, versus Math, Physics, Biology, Chemistry.
Is this distinction not used in places other than Dutchland?
I was thinking it was from "Brave New World", but that would have been the other way around. As summarized at Wikipedia:
Fetuses chosen to become members of the highest caste, 'Alpha', are
allowed to develop naturally while maturing to term in "decanting
bottles", while fetuses chosen to become members of the lower castes
('Beta', 'Gamma', 'Delta', 'Epsilon') are subjected to in situ chemical interference to cause arrested development in intelligence or physical growth.
-
@blakeyrat said:
I'm sure there's someone out there who can "parse" the CSS in their head, and say "oh to get result X you need to add a clear:both on element Y". But I ain't one of those people, and I don't think I ever will be.
There's an entire generation of web designers who have wrapped their head around it. They use tools like Firebug, Web Developer Toolbar and Webkit Inspector (right click in chrome, inspect element) to get layout details, dimensions, as well as inherited styles. It's no different than using debugging tools when you code.
The concepts are simple and constant, it's all a matter of taking the time to actually learn what each does. Don't just blindly set "display: block" or "float: left", understand what that does. Hell, the fact that you're clearing things instead of using newer clearfixing techniques is a clear indication that you're not actually trying to understand, just hammer it until it sort of works.
This was the article I read way back in 2006 that taugh me how to do CSS layouts (including list-based navigation). As I mentioned, I used the Web Developer Toolbar for Firefox and Firebug to debug my layouts, draw outlines around all my blocks, measure how big they were, etc.
After that it was simply a matter of understanding what each attribute was actually doing; Things like display, float, clear, position, etc. This is easily searched on Google.
-
@Rootbeer said:
In short, the entire HTTP/HTML/CSS/JS technology stack is four kinds of shit piled on top of each other.
I can't wait for Google to come up with a sane, integrated alternative and add support for it to Chrome.
Google is paying the salary for the main editor of HTML 5 (and, incidentally, CSS3 and a couple of JS and HTTP extensions). So depending on your point of view, they either are already doing just that or odds are pretty bad they ever will.
As for an HTTP replacement, they got that covered, too.
-
@Monomelodies said:
stuff
You're not helping.
Try to help. It's better to help.
@Monomelodies said:
CSS-style comments? They're perfectly C-style.
/* */ block comments suck. CSS has no single-line comment. Stop defending CSS comments.
@Monomelodies said:
This is precisely why they don't support variables etc.
I'm a frontent guy, and I feel strongly that CSS is often too rigid.
@Monomelodies said:
Floats. Ah, floats. Perfectly logical
Nope.
-
@blakeyrat said:
If it's hard-to-learn, it sucks.
CSS falls under easy to learn, hard to master.
This is unfortunate, because it should be easy to learn and easy to master.
@blakeyrat said:
1) WTF does CSS have to do with usability?
It produces a layout.
@blakeyrat said:
The lack of variables also makes it hard for CSS to do the very thing it's (purportedly) designed to do: centralize all style descriptions in one place. If you have a single background color, you might need to use it 5, 10, 25 times in the same CSS document. What if I want to change the fucking background color? Find-and-replace, that's all we got.
+1 concise problem statement
-
@blakeyrat said:
The fact that an entire industry, a huge one, depends on bending and twisting a protocol like this is not a good thing, it's a terrible thing.
It's exactly like (to use your own example against you) using fucking Excel to make resumes! Except the whole fucking INDUSTRY is using Excel, and we've happened to get good enough that the resumes don't entirely suck, and there's even people like you going "hey guys, Excel is awesome! it can do everything we need!" and the people like Silverlight developers are going, "hey we invented this thing called 'Word', it's really good for resumes" and you're going, "but we're not going to use it because your Excel templates aren't very good, also we have a new version of Excel which lets us make slightly more complicated resume templates, so we don't need your 'Word' abomination."
Couldn't have summed it up better. Or, to give another, non-fictional example, look at how thanks to a lot of probably very bright people that invented a number of extremely clever hacks, we can now use HTTP almost like a halfway-done, extremely bloaty, and unpredictable implementation of TCP - on top of TCP. That's what I call progress!
(Actually, this problem seems to be
solvedmitigated somewhat by WebSockets. Then again, they have their very own set of WTFs...)
-
@sprained said:
However, simply setting "overflow: hidden" or "overflow: auto"on the parent, you can force it to expand to contain the floated child.
My God. It works. In all my time I haven't come across this detail. Where did you learn this little nugget?
Let's just say that it's another fucking arbitrary thing, but it really slices bread, so that's good. I'll put it to rigorous testing next time I'm thrown a psd.
@sprained said:
Since learning CSS, I find table-based layouts tremendously inflexible and infuriating. The simplicity of markup in a properly-designed CSS-based layout is a joy.
+1
@sprained said:
I will admit that poorly marked-up pages for CSS layouts are not a *whole* lot better. Learn your HTML instead of using divs for EVERYTHING.
I'm sure you and me both have seen the guy who wraps everything in a div and uses classnames like "blue" and "page_title_big". ;)
-
@blakeyrat said:
They can tell you what styles are attached to a particular element, but they don't shed *any* light on the more important question: "why does it look how it does?" Or, more precisely, "how do the styles on this element relate to the elements around it?" Knowing an image has "float:right" doesn't help when you're trying to figure out why the holy fuck the image is on the left-hand side of the window.
They also tell you what styles override which styles, and where the box is placed.
Have you tried looking at that element's parent?
You've quoted that particular issue for the second time now. Perhaps upload a snippet?
-
@sprained said:
Of course, IE tends to be broken about a lot of things,
It's already been alluded to in this thread, but I feel like spelling it out because it's an often seen misconception:
IE's implementation of the box model was 100% compliant with the W3C spec they working off of. So was Netscape's. The fact that IE and Netscape interpreted the box model completely, utterly differently gives you a clue to how good the spec must have been.
W3C *changed* the box model out from under the IE developers before CSS1 became finalized, decreeing that Microsoft "did it wrong" and Netscape "did it right". Microsoft refused to change their design due to backwards compatibility (and probably not a little bit of spite), since by the time the CSS spec was corrected, there were already hundreds of sites using CSS in IE.
(Then people wonder why IE is hesitant to implement other non-final W3C specs, like HTML5 and CSS3. Gee, I wonder!)
@sprained said:
It's a tool that allows the presentation of content to be separated from the content itself.
We already had that long before CSS. It's called a "Content Management System."
@sprained said:
It allows you to present separate desktop and mobile and print layouts for the same content using nothing but 3 different stylesheets linked from the same page, rather than writing three different views in your application to generate different markup. What's WTF-y about that?
Nothing. Don't get me wrong; there are a lot of good points about CSS.
-
@dhromed said:
@sprained said:
However, simply setting "overflow: hidden" or "overflow: auto" on the parent, you can force it to expand to contain the floated child.
My God. It works. In all my time I haven't come across this detail. Where did you learn this little nugget?
Been using it so long I can't remember, but it's a lifesaver. Tons of little <div class="clearfix"> elements all over the place offend my semantic markup OCD. There's just one catch to this technique: if you have a set width/height and need child content to overflow the parent for some reason or other, the overflow properties will either cut it off or create scrollbars (ugh).
I'm sure you and me both have seen the guy who wraps everything in a div and uses classnames like "blue" and "page_title_big". ;)
Oh, yes. And the guy who uses paragraphs for everything and gives them "heading" and "subheading" classes. Or who styles his navigation by using the top-level "ul" selector, so that you have to explicitly *un*float every <li> in the page body (when you actually use lists instead of <br> and ·).
-
@dhromed said:
@blakeyrat said:
1) WTF does CSS have to do with usability?
It produces a layout.
... WTF does CSS have to do with usability?
-
@dhromed said:
You've quoted that particular issue for the second time now. Perhaps upload a snippet?
Tell you what, next time I'm working with CSS, I'll set up a WebEx you can join. But it might be months/years down the road, because I've pretty effectively distanced myself from any CSS development around here. (I do it sometimes when implementing A/B tests.)
-
@blakeyrat said:
@dhromed said:
... WTF does CSS have to do with usability?@blakeyrat said:
1) WTF does CSS have to do with usability?
It produces a layout.
well bad page layout contributes to bad usability and vice versa.
-
@blakeyrat said:
@dhromed said:
@blakeyrat said:
1) WTF does CSS have to do with usability?
It produces a layout.
... WTF does CSS have to do with usability?
A layout is an interface.
-
@DescentJS said:
well bad page layout contributes to bad usability and vice versa.
Well duh. But couldn't the bad page layout be done using tables? Or on a Flash site? Or with the site being a huge image-map?
What I don't get is the link between not knowing CSS well, and being bad at usability. (Or for that matter, not knowing *any* web technology and being bad at usability. But CSS was mentioned specifically.)
BTW, you know a layout engine I instantly understood after barely working with it? Windows Forms'. Give me "Anchor" and "Dock" over CSS "float" any fucking day of the week and twice on Sundays.
-
@blakeyrat said:
1) WTF does CSS have to do with usability?
About as much as MVC has to do with usability. But it has everything to do with maintainability.
-
@sprained said:
Oh, yes. And the guy who uses paragraphs for everything and gives them "heading" and "subheading" classes.
Haha, this is the worst. Let the markup do its job, I say! I've created my own styleguide pages that contain a base set of all html elements which I style separately from my layout. This way I know if I've forgotten to set margins on my paragraphs or accidentally hid the bullets on all the lists by mistake.
I especially hate it when someone decides to use classes for everything rather than give the elements a default style. For example, rather than styling their form elements directly, they'll use .textfield classes on every single textfield. Meaning if you create a text field you have to remember to apply that class or it won't look right. Classes like this should be used as the exception, when the form field differs from the default, for example .wide-textfield
-
@DescentJS said:
well bad page layout contributes to bad usability and vice versa.
There's a good chance that your layout will break on anything other than a desktop browser. If people can't properly access your site because it doesn't gracefully degrade on their mobile device, screen reader, high contrast display, print document, etc. Then you have a usability issue.
@blakeyrat said:
BTW, you know a layout engine I instantly understood after barely working with it? Windows Forms'. Give me "Anchor" and "Dock" over CSS "float" any fucking day of the week and twice on Sundays.
Have fun trying to produce a compelling web design with winforms. The reason they're easier to use is because their focus is narrow, aimed at laying out form controls, not describing a document. What you're describing is akin to what the original post was about, copping out and using an ActiveX control rather than properly building the menus in an accessible, compatible manner.
-
@Soviut said:
I especially hate it when someone decides to use classes for everything rather than give the elements a default style. For example, rather than styling their form elements directly, they'll use .textfield classes on every single textfield. Meaning if you create a text field you have to remember to apply that class or it won't look right. Classes like this should be used as the exception, when the form field differs from the default, for example .wide-textfield
Mostly I agree with you, but class="textfield" is a pretty common workaround for older browsers (i.e. IE), which don't support attribute selectors and can't distinguish <input type="text"> from <input type="checkbox"> or <input type="submit">. It allows you to, say, give your text fields colored borders and extra padding and float them left while leaving default styling and inline display for checkboxes, and right-aligning your submit buttons.
-
@Soviut said:
@DescentJS said:
well bad page layout contributes to bad usability and vice versa.
There's a good chance that your layout will break on anything other than a desktop browser. If people can't properly access your site because it doesn't gracefully degrade on their mobile device, screen reader, high contrast display, print document, etc. Then you have a usability issue.
You still haven't shown that there's a good chance table-based layouts break on anything other than a desktop browser. Seriously, stop flogging this point without an ounce of evidence.
That said, I agree with you, that would be a usability issue. If it existed. Which I don't think it does.
@Soviut said:
@blakeyrat said:
BTW, you know a layout engine I instantly understood after barely working with it? Windows Forms'. Give me "Anchor" and "Dock" over CSS "float" any fucking day of the week and twice on Sundays.
Have fun trying to produce a compelling web design with winforms.
If any browsers supported it, I sure as fuck would. But none do, so.
@Soviut said:
The reason they're easier to use is because their focus is narrow, aimed at laying out form controls, not describing a document.
Praytell, what can you do with CSS that you cannot with Windows Forms? Specifics, please. And if you don't mind, try avoid "it won't work on mobile devices!!!!" as an answer.
@Soviut said:
What you're describing is akin to what the original post was about, copping out and using an ActiveX control rather than properly building the menus in an accessible, compatible manner.
At the time Frontpage 6.0 was made, the ActiveX/Java control was the compatible manner.
-
@Soviut said:
By all means, have fun making your site with tables and have it easily port to mobile devices that aren't the iPhone. Then let's see how well your pages survive when you apply accessibility tools to the page such as screen readers, large font stylesheets, etc. Usually the "I love tables because I can't be bothered to learn a few CSS rules" crowd says "who cares, it looks fine on the desktop".
1: None of the users of the site I look after use mobile devices. 2: My site works fine with screen readers (according to my blind users). 3: Most of the data on my site is tabular. Are you really suggesting I should jump through some crappy CSS hoops to display data which ARE TABLES? If so, please do tell me how I should be using CSS to display an eight column by fifty row table, with different styles for the header row and for each column. I'd really be interested to see your reply to this.
-
@blakeyrat said:
You still haven't shown that there's a good chance table-based layouts break on anything other than a desktop browser. Seriously, stop flogging this point without an ounce of evidence.
Load up a table-based layout on a blackberry web browser. It's broken and you have to scroll all over the place to hopefully see the content within. With the CSS layouts the degrade gracefully into a clean column that, will less pretty than what the desktop browser displays, is still usable and only requires vertical scrolling to use. I'm not talking out of my ass here, I deal with it on a day to day basis!
Screen readers are another case where they assume they're reading tabular data. When you don't include thead and th tags the reader can't read out a nice name like "Soviut in Name column on row 3". Instead it just says "image at column 1 row 1", how is a blind person supposed to know that's your rounded corner image?
And what about printing? What happens when your table layout exceeds the width of a page? Wrapping hell, that's what. Meanwhile, a simple print stylesheet can take my screen layout and reflow it to fit easily on a page without cruft, wrapping issues or other headaches.
@blakeyrat said:
That said, I agree with you, that would be a usability issue. If it existed. Which I don't think it does.
If you want to do what winforms does, simply use nothing but absolute positioning on all your elements and set width and heights with percentages. It totally ignores page flow, but it gives you virtually the same level of functionality.
@blakeyrat said:
Praytell, what can you do with CSS that you cannot with Windows Forms? Specifics, please.
Flow text around an image, wrap a list, etc. That's why there are hundreds of custom controls out there, all the things winforms can't do by default. CSS is intended for document layout, there's a reason Word documents aren't written using winforms, they describe a document, not a form!
@blakeyrat said:
At the time Frontpage 6.0 was made, the ActiveX/Java control was the compatible manner.
Even back then it was possible to achieve what they were trying to do without resorting to a custom plugin. This was a cop-out plain and simple and that's why even IE is reluctant to load it these days.
-
@Cad Delworth said:
Are you really suggesting I should jump through some crappy CSS hoops to display data which ARE TABLES? If so, please do tell me how I should be using CSS to display an eight column by fifty row table, with different styles for the header row and for each column. I'd really be interested to see your reply to this.
No, I was saying that only tabular data should be displayed using tables. Just like only paragraphs should be displayed using p tags, headings should use h tags, and so on.
What I was saying was tables should NOT be used for layout, which is what all the "use CSS for layout" articles have always said.
-
@Cad Delworth said:
3: Most of the data on my site is tabular. Are you really suggesting I should jump through some crappy CSS hoops to display data which ARE TABLES? If so, please do tell me how I should be using CSS to display an eight column by fifty row table, with different styles for the header row and for each column. I'd really be interested to see your reply to this.
You absolutely should be using tables for that. That's what tables are meant for. The argument is that tables are a really ugly hack for laying out the supporting content that shares the page with your tabular data (mastheads and logos and navigation and instructions and paginators and whatever the hell else).
The idiots who think that using CSS for layout means shoehorning tabular data into some completely fucked-up div-based approximation of HTML tables (and I've been unfortunate enough to have to maintain websites coded like this) are the worst sort of cargo-cultists and have no idea why they're doing what they're doing. They should be taken out back and shot. After having their feet boiled in oil.
HTML markup, done properly, is meant to indicate the structure and meaning (semantics) of the document: this is a section heading; this is a list; this is a table of data; this is another section heading. Note that there are tags specifically meant to denote tabular data, and they should be used as such. HTML5 makes this even better (this is our navigational menu; this is the page header; this is the page footer). Using tables for layout mixes up the structural tagging with "I want the search box to display in the top right quadrant" and pretends that your page elements are tabular data, which they are not. For end-user human readability little of this matters, but for computer parseability, your document has much more potential meaning when you use semantic HTML and CSS layout rather than table-based layout.
-
@sprained said:
Using tables for layout mixes up the structural tagging with "I want the search box to display in the top right quadrant" and pretends that your page elements are tabular data, which they are not.
Exactly. As I mentioned earlier, 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.
-
@Rootbeer said:
Eh, HTTP isn't TOO bad.In short, the entire HTTP/HTML/CSS/JS technology stack is four kinds of shit piled on top of each other.
The other 3, though, total shit and the very bane of my existence.
-
@Soviut said:
@blakeyrat said:
That said, I agree with you, that would be a usability issue. If it existed. Which I don't think it does.
If you want to do what winforms does, simply use nothing but absolute positioning on all your elements and set width and heights with percentages. It totally ignores page flow, but it gives you virtually the same level of functionality.
Have you even used Windows Forms? Only people who don't know how to use the various container controls and positioning options available to the controls use absolute positions on all the elements on the form.
-
@DescentJS said:
Have you even used Windows Forms? Only people who don't know how to use the various container controls and positioning options available to the controls use absolute positions on all the elements on the form.
Yes, I've got several years of experience using them, including building them from scratch back in the 1.0 beta days before VS supported them.
I've also got years of experience with CSS and HTML and know the difference between a document layout model and a form layout model. It always seems that those who complain the most about CSS layouts are the ones who don't actually use it in their day to day. They get frustrated easily, claim they're "not a designer" and then give up and use tables.
Just to put this into perspective, this would be like a programmer claiming they don't understand functions and that GOTOs are easier. SpectateSwamp did just that.
-
@Soviut said:
@DescentJS said:
Have you even used Windows Forms? Only people who don't know how to use the various container controls and positioning options available to the controls use absolute positions on all the elements on the form.
Yes, I've got several years of experience using them, including building them from scratch back in the 1.0 beta days before VS supported them.
I've also got years of experience with CSS and HTML and know the difference between a document layout model and a form layout model. It always seems that those who complain the most about CSS layouts are the ones who don't actually use it in their day to day. They get frustrated easily, claim they're "not a designer" and then give up and use tables.
Just to put this into perspective, this would be like a programmer claiming they don't understand functions and that GOTOs are easier. SpectateSwamp did just that.
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."
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.)
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.
SitePoint Blog – The Best Web Development & Design Blog
Web Developer
