Is Bootstrap a programming language?
-
I stopped having fun chatting with you quite a while ago.
Then You're Doing It WrongTM.
Filed under For Your Information.
-
-
Believe what you like, doesn't change what is.
-
gets out popcorn
Watching flamewar threads is almost as much fun as participating in 'em.
-
OMG @antiquary was right. This thread is quite amusing. A little predictable since I knew Lucas was going to be burned by saying what he did four hours ago, but amusing none the less.
-
Have you ever heard of a blaise comment? Doesn't make any of the other stuff I said was wrong.
This is what fucks me off about forums, I write a blaise comment on my phone because work is shite and I have all this shite as a result.
-
Dude, whatever, this is not my kind of flamewar, but on the other hand, once blakeyrat got involved, you should have abort praising whatever you were or be ready for a loooong and painful road.
-
Don't comment on the flamewar if you don't want to be part of it.
You are right I should have left it. I made the mistake of trying to be actually helpful ... won't that mistake on here in the future.
-
-
No
-
Aww.
-
Not only did I get the spelling wrong, I got the meaning wrong.
Blasé Definition & Meaning | Britannica Dictionary
BLASÉ meaning: having or showing a lack of excitement or interest in something especially because it is very familiar
Good thing I suppose I am a web dev rather than an English Teacher.
-
Not only did I get the spelling wrong
If people around here weren't so stubborn about not flagging for pendantry the rest of us would probably get bored of it.
-
@lucas said:
Get fucked mate.
Also, as a side note, my wife does a very fine job of helping me with what you suggested, TYVM.I see we've decended into pegging again....
gets out popcorn
Watching flamewar threads is almost as much fun as participating in 'em.
/t/3986. Or was last time I looked. 243 unread which I'm leaving for later...
-
But if you have a situation where you need a general selector (e.g. .error) to be applied to an element that has a more specific selector defining styles (e.g. .parent li.item), that's where !important works well, because it means you don't have to effectively copy every style where that additional class may show just to override a few styles.
To semi-quote Raymond Chen, "what if two people wanted to do it"?
Say you're writing a couple of reusable components.
ComponentA, ComponentB, ComponentC, etc. And you have a lot of rules, all of them of the form:.componenta li div.somethingsince you want them to be reusable on the same page (so you use classes), and you don't want to screw with any other elements (so you prepend all of them with a class specific to your component).
And you run into the aforementioned situation. So what do you do?
.componenta .error { background-color : #FF0000 !important; /* note: BAD IDEA, not only due to !important */ }And all is fine and dandy, until someone decides they don't really like that color, perhaps because they're making a website for The National Organization of Colorblind People. And they're stuck - either they need to separately override each of those rules for every component (so
.componenta .error,.componentb .error,.componentc .error), or use a hack (.error.error), because there's no way to specify "more important than!important".I did use
!importantonce, and that's because of the retardedness of jQuery UI's BlockUI. Basically, you get an absolutely-positioned<div>shown on the center of your screen, and an overlay which makes it modal. Except it's positioned by upper-left corner, so the centering only works for default width.You can pass a CSS parameter to the Javascript, but if you want to set the width and margin-left in your stylesheet, you're fucked, because BlockUI styles the element, inline, which gives it a specificity equal to 100 fucking classes. So it's either
!importantor.blockPage.blockPage.blockPage.blockPage.blockPage(...)100 fucking times.Ah, you're talking about controls that you will be reusing multiple times on the same page. I feel sorry for you.
You're telling me that's never your use case? It popped up pretty much all the time in my project. It used an awful lot of DataTables, which are cool, but require a huge amount of initialization code - so I made a partial which fills the data- attributes from the model, and a JS initializer which grabs those attributes and does the initialization proper.
But I digress. The point is, you really can't use IDs outside of the top-level page, and if you're like me, your top-level page is mostly a collection of
@Html.RenderPartial.As another side-note - that project was even more fun when I started to load those partial views via AJAX. And it's up for code review now, so I do expect it to turn up here.
Some people don't want to apply a class to every on their site. Sometimes it's easier to apply an ID to one div in define a CSS scope for all of the elements inside.
There's not a lot of difference between:
<div id="uniqueId">and
<div class="uniqueClass">The first is somewhat faster, but it really shows up only if you're already doing something wrong (like having a Discourse-like level of DOM complexity). The second, however, you can then use twice, which might be a huge benefit when you decide you actually need two of those elements.
So I'd really go with classes on that one. Unless you're really, really, really sure you're on the top level.
Finding the input fields is 10 times easier if they have an ID.
It's just as easy if instead of
<input id=...you use<input class=...with the same name. If it stops being unique, you can even keep the name and refactor your selectors to[#.]form1 .input1,[#.]form2 .input1, etc."Does a CTA with a red background work better than our green background? Let's add a CSS rule for that-- oh, hm, conflicts with the site's stylesheet and there's no way to make the rule more specific. Well, I guess we have to use !important."
Isn't that the point? That if the site's stylesheet used !important there, you'd be fucked, because you'd have no way to override it? And that's why you shouldn't use !important in the site's stylesheet?
-
But I digress. The point is, you really can't use IDs outside of the top-level page, and if you're like me, your top-level page is mostly a collection of @Html.RenderPartial.
Not true. I have some controls which I created only because I need them on multiple pages, not because they are needed on the same page multiple times. This is actually my primary use case for user controls. On several of these controls, I am using ID's to help target CSS, and it is working just fine.
It's just as easy if instead of <input id=... you use <input class=... with the same name. If it stops being unique, you can even keep the name and refactor your selectors to [#.]form1 .input1, [#.]form2 .input1, etc.
Now you're just playing the devil's advocate, arguing to abuse classes in a situation which IDs were clearly designed for.
-
I have some controls which I created only because I need them on multiple pages, not because they are needed on the same page multiple times.
You still need to guarantee that no ID from one control clashes with any ID from the other control, if you even want two different one at a page. It's usually pretty easy to achieve, that I can give you, but it breaks encapsulation for me too much.
Now you're just playing the devil's advocate, arguing to abuse classes in a situation which IDs were clearly designed for.
Personally, I tend to abuse data- attributes, but it's the same thing really.
And whatever IDs were designed for - they were designed badly. It's pretty much a Web analogue of global variables - they work, but they're smelly.
-
You still need to guarantee that no ID from one control clashes with any ID from the other control, if you even want two different one at a page. It's usually pretty easy to achieve, that I can give you, but it breaks encapsulation for me too much.
Very easy to achieve. Each control I build has a top level
div. That div has an ID which matches the control's name. That ID is the one I use to help target the CSS. In cases where the control may be used on the page multiple times, I use a class instead of an ID, for obvious reasons.
-
And it coincidentally makes your hard rule a piece of utter crap when it comes to getting real work done on the real web with web sites.
@lucas, please just tell him that you were talking about the ideal case and I'm sure he'll understand.
blaise
The word you're looking for is blasé.
-
In cases where the control may be used on the page multiple times, I use a class instead of an ID, for obvious reasons.
I tend to design a bit defensively here and just do that for every control. There, the whole point of discussion.
-
I tend to design a bit defensively here and just do that for every control. There, the whole point of discussion.
I'd say that designing a single-use-per-page control such that it breaks when placed on a page multiple times is a form of defensive design.
-
This thread makes me reslly glad I don't do CSS. Application development FTW.
-
JavaFX would like to have a word
forwith you.
-
I'd say that designing a single-use-per-page control such that it breaks when placed on a page multiple times is a form of defensive design.
Except you're in HTML/Javascript land where things don't break nicely. You won't get an exception when you have two controls on a page, or even when you start to query them by ID - but one of the controls won't work in JS, and I'm not sure about CSS.
Besides, I can't envision any kind of control which should break when placed multiple times. And by "should break" I mean "it can't possibly ever work with another one", not "current design doesn't require us to have two of these anywhere".
Not thinking ahead is a big problem. I once had a project which had 10, let's say, "product types". Each type had some properties specific to it, but for some kinds of products, the set of properties was the same. So the dev wanted to go full DRY and instead of copy-and-pasting, made a "ProductAorBorC" class and generally went with that.
And all was fine, until I was tasked to add a property to product B only. Decoupling that was a bitch.
-
CSS is simple and fun, a nice break from programming to goof around with colours and stuff.
This whole thread is just weird. Ids are fine, so are classes, !important is a bit of a headache if you can't avoid it, but apart from that, this ain't C++ here people :P
-
a "ProductAorBorC" class
Oh dear. Why couldn't he just define the same rules for 3 different classes A, B and C?
-
Oh dear. Why couldn't he just define the same rules for 3 different classes A, B and C?
Uh, I didn't make myself clear. I meant backend classes, as in C#.
Basically half the code was centered around those three products having the same set of properties. So a DAO would return a
ProductAorBorCobject, the viewmodel would have aAorBorCfield, the validators would check whether the product isAorBorC...
-
Besides, I can't envision any kind of control which should break when placed multiple times. And by "should break" I mean "it can't possibly ever work with another one", not "current design doesn't require us to have two of these anywhere".
As I stated before, the project I'm working on has control that are needed on multiple pages, but those controls should never exist more than once on a given page. If the controls are needed multiple times on a page, then the page is designed wrong. Mostly, this is to work around scenarios where there multiple possible views for the same data, but coding all of those views into one page would make the page enormous and difficult to maintain. Instead, each view is maintained as a separate page, with the common parts in controls.
Honestly, the architecture we are using right now is not the best fit for our web app. We are currently using an MVP architecture, when we would be better off with an MVC architecture. Unfortunately, that architecture choice was made about 5 years before I started here.
