requinix Posted October 15, 2018 Share Posted October 15, 2018 (edited) So we all (most of us) know some CSS. You might not consider yourself a web designer, be fluent with all the popular libraries, but you know your way around how to do it. Like if you want to make something bold you could inline it <span style="font-weight:bold;">An important statement</span> but you're smarter and you know you should .bold { font-weight: bold; } <span class="bold">An important statement</span> A trivial example, of course, but it demonstrates how you should use CSS. Right? No. God damn *#(*^y$&#ing NO. So maybe it's a bad example. People don't actually do that. Okay. Let's look at some official Bootstrap examples instead. <button type="button" class="btn btn-lg btn-default">Default</button> No. <table class="table table-striped"> Stop that. <ul class="list-group"> <li class="list-group-item">Cras justo odio</li> Dude. What's the problem here? You're restating the obvious! I know that button is a button. It's got #*^(ing "button" right in the (*^-@$ markup. Ooh, it's a LARGE button. Wow! And hey, that table has stripes? Amazing! And you mean to tell me that UL is a list and the LI is an item? You're blowing my mind! You're also DOING IT WRONG. The power behind CSS is (a) not having to tell the browser that yes, in fact, that button really is a button, and (b) not having to say the same thing over and over again in different places. And that is where Bootstrap fails miserably. You want to create a button? Go ahead. Create the button. Then throw a few classes at it so it looks the way you want. Want another button? Create another button and throw classes at that one too. Created a button and it doesn't look right? Oh damn, you forgot one of the classes you have to include. Ha ha, oops. "But that's how CSS should be used!" No. You're all missing the (*@#*^ing point and making everything hard on yourself and the people who have to deal with your crap. What if I want to add a dropdown list of items? What should I do? The page already has a couple dropdowns on it so I know the styling is in place. I'll add a simple <select> and... nope, looks like a plain list. No styling applied. What happened? What happened is that I didn't apply the handful of classes necessary to make the list appear like the damn list it should already be. What happened is that I forgot I have to add in the presentation aspects to my HTML. And that's what this whole stupid thing boils down to: people can't shift their mindset away from the presentation, and while they know not to mix presentation with markup they've not noticed that all they did was trade one syntax for another. The problem is still (@^$ there. "Oh, right, yeah, if you're so smart then how would you do it?" Thank you for asking. You want a button. You want a large button. You want a large button that draws peoples' eyes to it because it's the button they probably want to use and so it's the default. That's presentation. Forget about presentation. You want a default button. That's it. That's all you should have to care about. <button type="button" class="default">Default</button> Done. "But no, it doesn't look the way I want!" I don't give a damn how you want it to look. I want to know what the button means. What is the significance behind the button. What does it represent. Because ultimately that's what the HTML markup needs to concern itself with. Write semantic markup and leave out the presentation crap because it has no place in the document. "Oh, so you think we shouldn't have any CSS at all or what?" Take those words out of my mouth before I cram them back down yours. button { /* make it look like a nice button */ } button.default { /* blue or whatever */ } There. Now the presentation is accounted for in the @(!^)$ place where it should be: CSS. And if I want to add another default button somewhere I don't have to look up the Bootstrap reference because I don't remember which 5 classes are relevant. Default button? Default button. The only way this could improve is if HTML added a way to actually identify the default button of a form, in which case that class=default goes right out the damn window and the CSS targets that new attribute or whatever it is instead. "Noo, it's not a large button!" Alright. Fine. Let me take a deep breath before I have to deal with you. So. Why do you want it to be large? Don't give me some stupid reason like "because I want it to be large". What is the reason behind making it large? What decision process did you go through in your head that resulted in the button needing to be larger? Why is the normal size for buttons not appropriate? Maybe the form is a modal and you want larger buttons? Okay. Did you mark the form as modal? Because that's the first thing you have to do. <form class="modal"> form.modal button { /* larger */ } And done. Problem solved. Problem solved in a way that keeps the appearance of the button separate from the markup of the button. Want to add another button to the modal? Go on. Add another stupid button. One that doesn't require any classes just because it's supposed to be larger. What you might be able to realize here is that now I've established a rule saying "buttons in modal forms are larger". And it applies everywhere you have a modal form. If you make another modal form then magically the buttons are larger there too! And without having to find that first place you had that one modal form, what page was that again, oh right, over here, now what classes and CSS files did I have to use for it to make it look that way, oh right, those classes. How about a striped table? Why is it striped? Because it's a table that will grow vertically and has enough data in its columns that people need help scanning through them? So what you're telling me is that the table is, say, "dense"? <table class="dense"> table.dense > tbody > tr:nth-child(odd) { /* striped */ } Somehow I'm able to rub a couple brain cells together and end up with a way of identifying the table for what it is and not what I want it to look like on the page. How about a regular list? Nothing special? <ul> <li>Cras justo odio</li> Nothing (*&^!@ special. Now when I come along, I can write markup into your fancy page you spent a couple days tweaking until it looked oh so pretty, and I don't have to run off to the kitchen where I can cool my heels instead of planning your "accidental" death because I can write simple, logical, and minimal HTML that represents what I'm adding without having to fire up five different browsers to see that I got all the required classes. What's more, if someone decides that modal dialogs on mobile devices need to look a little different, I don't have to spend a day searching the codebase for anything modal because the work has gone from "go fix all the modal dialogs to use this new CSS class someone wrote" to "apply media queries to adjust the existing modal dialog to better suit mobile screens". This isn't damn rocket science. I know you web designers had a hard time in college with your liberal arts degree and that's it's so unfair you have to work with computer graphics instead of living in a loft painting bowls of fruit all day, but surely even you are smart enough to understand these principles. Stop thinking with your eyes and start thinking with your brain. And now I go back to work. Dealing with stupid crap. That I put off by ranting about it here. Edited October 15, 2018 by requinix 2 Quote Link to comment Share on other sites More sharing options...
kicken Posted October 16, 2018 Share Posted October 16, 2018 I lost track of the number of of times I've forgotten those dumb bootstrap classes on buttons and wondered "WTF isn't this looking like it should?" I always hated this about css grid setups too. Having 'col', 'row', 'col-x', etc scattered everywhere, but I guess that's what happens why you try and use a generic grid framework. Now that I'm using SCSS more often I'll generally use a grid that includes a scss distribution so I can integrate it into my more meaningful rules. I'm still not perfect, but I'm a lot better now than I was 5 years ago at this stuff. Quote Link to comment Share on other sites More sharing options...
requinix Posted October 16, 2018 Author Share Posted October 16, 2018 (edited) 8 minutes ago, kicken said: I always hated this about css grid setups too. Me too. "Tables are not for layout" happened a few years back and that's nice, but people are still using tables for layout - just not with a <table>. What happened was people went right off the deep end, fixated on avoiding <table>s even for tabular data because people got it drilled into them that Tables Are Bad (tm). No. Tables are not bad. Tables have a purpose. What's bad is using tables for the wrong purpose, but it's just as bad as not using tables for the wrong reason. Tabular data doesn't have to involve numbers or math. It simply involves rows and columns, and if the stuff being put on the page has a row/column or other 2D nature then the row/column element is a good place to go. And responsive design can happen just as well with tables as it can grids. It's just as easy to force inline-block on a div as on a table cell. If you really have to do that. But damn, don't get me started on responsive design, one rant for today is enough. Edited October 16, 2018 by requinix Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.