Is Bootstrap a programming language?
-
In Web forms, you can have multiple same server-side ids, but in actual rendered HTML, they get mangled to include the context, so that they're actually unique. Sadly, that means you have no reliable way to query by ID in your client-side code.
In MVC, you just write HTML. And valid HTML can't have two elements with the same ID anywhere on the page, so if you want to render your partial twice, you need to either do the mangling in JS, or use a class/data attribute and query with context.
Ah, you're talking about controls that you will be reusing multiple times on the same page. I feel sorry for you. My solution didn't even require server-side IDs, since when I'm building custom controls I put them in a single div like:
<div id="myControl"> <!-- Custom HTML --> </div>My CSS always works out for me.
-
that's for the client to apply custom overrides
If they define the same selectors as in the base style sheets, and it doesn't specify to load the custom styles before the standard ones, you wouldn't need
!importantthere either.just let you specify the specificity
The more specific the selector specifies which conflicting style wins out. 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!importantworks 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.It's use should be minimized, yes, but it shouldn't be forbidden.
-
Here's what I think: you have no idea in Belgium how to use CSS, so you rely on pre-built files like bootstrap.css to do the work for you. How about you get your head out of your ass and shut up. Go learn how to use CSS before you come around trying to school a forum full of IT professionals.
You leave Lotus Notes Guy alone! We need people like him here for entertainment.
-
Why are people styling based on IDs? You shouldn't be doing that, it is akin to sticking !important everywhere anyway.
As for querying by ID in your client side code, why would you want to do that?
-
Why are people styling based on IDs? You shouldn't be doing that, it is akin to sticking !important everywhere anyway.
It's actually very useful when you want to limit the scope of your styles to a given area. Let's say that you want certain styles to only apply to elements within a certain div. You give that div an id and use it in your CSS targeting.
As for querying by ID in your client side code, why would you want to do that?
Really? How else do expect to find a specific control from your client side code without an ID?
-
Really? How else do expect to find a specific control from your client side code without an ID?
Well, you can loop over every
btnobject and query on its attributes to figure out if it's indeed the one you're looking for. That's very efficient.BWT, I'm only commenting because @antiquarian suggested this would be more fun... but is not.
-
Well, you can loop over every btn object and query on its attributes to figure out if it's indeed the one you're looking for. That's very efficient.
But what if your page has a grid of data with identical edit buttons for each record? What do you do then? What then?!
This meltdown has been brought to you courtesy of Discourse®.
-
I couldn't agree more!
-
The more specific the selector specifies which conflicting style wins out. 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!importantworks 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.It's use should be minimized, yes, but it shouldn't be forbidden.
You are doing CSS very very very wrong.
-
You are doing CSS very very very wrong.
Or he's doing shit the creators of CSS never anticipated (because: idiots), like doing A/B or multivariate testing through JavaScript.
-
It's actually very useful when you want to limit the scope of your styles to a given area. Let's say that you want certain styles to only apply to elements within a certain div. You give that div an id and use it in your CSS targeting.
You should do that via class. You really shouldn't be using ID in your CSS unless you really really have to.
Really? How else do expect to find a specific control from your client side code without an ID?
You might want to do this if you are changing the innerHTML on an element.
if you are doing on say a btn event you have the e.target attribute and it is trivial to get parent elements with something like jQuery. I tend to build a lot of my JS as either a jQuery plugin, or as a web component so it never has to rely on an ID being present on the page.
-
How does A/B testing have anything to do with how you structured you CSS?
If you are using important that means you haven't though about your CSS correctly. If you are inheriting a mess (like I normally you do) you might have to do that ... but it really is a last resort.
If you are starting a new project you really should build proper "web components" aka like this
Bootstrap is pretty much built around the same set of ideas.
If you do things like that, you don't have weird specificity issues.
-
How does A/B testing have anything to do with how you structured you CSS?
Because you're a 3rd party who has no control or input over how the site structured their CSS. So you have to work with the shit you're given. Which means, you're shitting !important all over the place.
-
You should do that via class. You really shouldn't be using ID in your CSS unless you really really have to.
Some people don't want to apply a class to every on their site. Sometimes it's easier to apply an ID to one
divin define a CSS scope for all of the elements inside. It's a difference of style and preference, so don't come at me with "should" and "shouldn't". You don't like to do it, fine. But it has certainly made things a lot easier for me in some scenarios.You might want to do this if you are changing the innerHTML on an element.
if you are doing on say a btn event you have the e.target attribute and it is trivial to get parent elements with something like jQuery. I tend to build a lot of my JS as either a jQuery plugin, or as a web component so it never has to rely on an ID being present on the page.
Sometimes I want my client code to do some quick calculations based on user input when a button is clicked. Finding the input fields is 10 times easier if they have an ID.
I don't understand what your aversion to using IDs on an HTML page is, but they are useful. They make some things significantly easier to do, both in client code and in CSS.
-
Ever heard of an iFrame?
-
Some people don't want to apply a class to every on their site. Sometimes it's easier to apply an ID to one
divin define a CSS scope for all of the elements inside. It's a difference of style and preference, so don't come at me with "should" and "shouldn't". You don't like to do it, fine. But it has certainly made things a lot easier for me in some scenarios.You can do the same with class and not have to worry about how many times you may use it on the same page in the future. There is no benefit in using ID in this situation, so you may as well use a class.
#my-web-component pvs
.my-web-component pThere is no difference other than the number of times you may want to use it on the page. If you are writing CSS so it is reusable, you should without question use the latter.
Sometimes I want my client code to do some quick calculations based on user input when a button is clicked. Finding the input fields is 10 times easier if they have an ID.
I don't understand what your aversion to using IDs on an HTML page is, but they are useful. They make some things significantly easier to do, both in client code and in CSS.
Why are you trying to find the input field, you already know where it is via its click event!
IDs can be useful in JavaScript (I did make a blaise statement earlier, I probably shouldn't have done), but almost never in CSS.
-
!important
Whoever thought that up deserves the bastinado. That reads as "not important" to me.
-
It reads "Your CSS needs refactoring" to me.
-
It reads "Your CSS needs refactoring" to me.
It means a multitude of things, all of them bad.
-
You can do the same with class and not have to worry about how many times you may use it on the same page in the future. There is no benefit in using ID in this situation, so you may as well use a class.
It depends how reusable you want it to be. Maybe you only want it to be focused to a specific div on a page, in which case using an ID makes sure that you shouldn't be able to accidentally use it more than once.
There is no difference other than the number of times you may want to use it on the page. If you are writing CSS so it is reusable, you should without question use the latter.
Be careful with absolutist phrases like "without question". There's bound to be an exception that will bite you in the ass.
Why are you trying to find the input field, you already know where it is via its click event!
No, you have a hook into the button via the click event, not the input field(s). Take the mockup I just made here:
The user enters values 1 and 2, clicks the sum button. Do you know where the fields with the user entered data are? Nope, not with IDs to grab those fields. Of course, in this case, you can just grab all the text inputs and you're good to go. How about if we add a parallel set of fields for subtraction?
Well now you're really screwed. Better start using those IDs!
As an additional point to combined my two arguments, let's say that you have a control which needs an ID so it can be accessed in client code. Let's also say, for arguments sake, that control needs to be uniquely styled. Would you create a CSS class just for that control, or would you use the control's ID to target the CSS styling? I'd use the ID since you need it anyway. What's the point of creating a one off class in that situation?*
*Yes, I have done this. I can't give details though, due to an NDA.
-
Would you create a CSS class just for that control, or would you use the controls ID to target the CSS styling?
The only point I would do this is when you can't be sure of the ID for what you're styling (WebForms pre-.NET 4.0). Otherwise, I have no qualm with styling targetting an ID.
-
Ever heard of an iFrame?
Of course.
I don't see how that helps solve the problem at all, though.
-
I can't be arsed with the quote pyramid.
- If it is CSS why would you ever care if it is one or more times? Unless your UI design is WTF. Even then you can still use another class to cascade over that one ... you know using the cascading part of cascading style sheets.
- If you are creating reusable CSS i.e. you can use it anywhere you shouldn't be relying on IDs.
- Yes you do, because the parent should be a form and you can do form.input.whatever, maybe your form should have an ID, but your inputs don't need it. If you were specifically talking about mobile dev, I might agree because selector speed really matters there, on a desktop ... not unless your customers are using IE7.
- Just create a class and apply it to the element. If you only add the class once ... it doesn't matter. If it is purely unique for the element you should use the style attribute as that is what it is there for.
This pretty much sums up what I am talking about.
-
I'm just going to leave this here, because I find it amusing given the current conversation:
/* Taken from http://www.w3.org/2008/site/css/advanced, line 172 */ .w3c_home #w3c_most-recently{ margin-top:0 !important; }
-
Why would a 3rd party component on another web page be anything else?
-
1. If it is CSS why would you ever care if it is one or more times? Unless your UI design is WTF. Even then you can still use another class to cascade over that one ... you know using the cascading part of cascading style sheets.
2. If you are creating reusable CSS i.e. you can use it anywhere you shouldn't be relying on IDs.Just create a class it doesn't matter how many times, it can be once or many it doesn't matter and the browser doesn't care. If it is purely unique for the element you should use the style attribute as that is what it is there for.
So it basically comes down style preference. Your preference is to avoid IDs in CSS. Got it.
Yes you do, because the parent should be a form and you can do form.input.whatever, maybe your form should have an ID, but your inputs don't need it. If you were specifically talking about mobile dev, I might agree because selector speed really matters there, on a desktop ... not unless your customers are using IE7.
Ok, you obviously have a very religious viewpoint on this, which amounts to:
IDs in web development are the spawn of the devil and must be abolished wherever they are found. Those who use use IDs in web development are ignorant and must be shown the error of their ways.
Oh, ummm ... are you familiar with TCotCDCK?
This pretty much sums up what I am talking about.
Will not watch. Especially if it takes half an hour to "pretty much" sum up your point.
Filed Under: @lucas is to not using HTML IDs as Jeff is to Discourse
-
Why would a 3rd party component on another web page be anything else?
Gee, I dunno. Web analytics? Tag management? A/B or multivariate testing, like I just fucking gave as an example?
Do you... make... websites? Do you seriously make websites with zero 3rd party components that aren't in iframes? I mean, maybe you do, which is great-- but 95% of websites have them.
-
It isn't style preference, it is just makes sense ... ignore me if you want. You can do it anyway you like, I certainly can't stop you through the ether of the internet comments. However most of the CSS frameworks are designed in the manner I describe.
I don't think IDs are the spawn of the devil, I just use them very sparingly. As I said previously I was blaise in my first comment because I was wound up because I am fighting developers that do CSS very very wrong ... maybe this was the wrong topic for me today..
The video is 30 minutes, he talks about how you should use IDs for minutes. The rest is about the idea of OOCSS (which I was alluding to). It is a good presentation and changed my thinking about how I write CSS and generally IMO has made my CSS better as a result. Choose to ignore if you wish, but there are some really good tips.
I am out of this discussion.
-
A/B multivariate testing ... when should an !important make any difference?
If they are 3rd party components that are part of the website, why can't you control what classes they expose. Even if you can't control that you can certainly you could wrap them with a div with the class .my-third-party-component where they are injected, still won't have to use !importants. Looks like a lack of imagination on your part.
I make websites, possibly more than you as you actually asked earlier what a "CSS framework" was.
-
A/B multivariate testing ... when should an !important make any difference?
"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."
That came up about once a week while I was doing A/B and multivariate testing work.
If they are 3rd party components that are part of the website, why can't you control what classes they expose.
The third-party component is the JavaScript and/or CSS file. I didn't have any control over the website.
Sure, "technically" you could stomp over all the classes with JavaScript, but that's a lot more WTF-y than adding a single !important to your CSS patch.
I make websites, possibly more than you as you actually asked earlier what a "CSS framework" was.
Ok Mr. Super-Expert. Your penis is larger than mine, or whatever.
For the record, I didn't know what a "CSS framework" is because I'm not a front-end designer. I'm kind of a "middle-end JavaScript guy who does analytics and testing work, but has the artistic ability of a mentally-deranged ferret."
-
- Change the parent class and override it using basic specificity ... the cascading part is there for a reason. If it is built as a web component (like I have been banging on about) it becomes trivial.
- Surely if they are JS or CSS and they aren't injected by an iFrame you can change the source to suit? It is pretty impossible to obfuscate CSS.
- I am neither a "front-end designer", I am a full stack developer that happens to do a lot of JS and CSS from my last two roles.
-
-
Get fucked mate.
-
Change the parent class and override it, use the cascasding part of the acronym
I have no control over the site. I think you're having trouble with this concept. I can't change the site's classes. I can't change anything the site serves up.
(I mean, like I said, I could technically using JavaScript, but it's pretty shitty to load JavaScript on a site that really only needs a CSS patch. Especially when the only reason I can't use a CSS patch is Lucas's Holy Rule Of Never Using !Important Bow Before Him!!!)
Surely if they are JS or CSS and they aren't injected by an iFrame you can change the source to suit? It is pretty impossible to obfuscate CSS.
You mean writing a JavaScript to dive into their in-memory CSS DOM object and fuck around with it? That's a nightmarish amount of work to obey your dumb and arbitrary "rule".
I am neither a "front-end designer", I am a full stack developer that happens to do a lot of JS and CSS from my last two roles.
And you've never made a site with analytics or testing? What kind of sites are you making, seriously? Bob's Fishing Bait World Headquarters Dot Com? Help me visualize what kind of chintzy site has no third-party code on it.
If you're not doing at least analytics, you're not serving your client's needs at all. If you're not at least trying to sell them on testing, you're depriving both them and yourself from tons of revenue.
-
Get fucked mate.
Aww, I got insulted by someone who can't see that there might possibly be way to do something other than his own! It's almost like Jeff never left!
Also, as a side note, my wife does a very fine job of helping me with what you suggested, TYVM. ;)
-
Surely you are testing your own companies site and get this added as part of the test plan. I have no idea on your specific requirements, but it doesn't sound like you are actually devving the actual site.
-
-
I have given quite a lot of reasoning why I something should be done as I suggest, even with links and videos which you said you wasn't going to watch ... what other response is appropriate after that last comment?
-
Surely you are testing your own companies site
No, I wasn't.
Why is this such a hard concept to grasp?
The only control I had over the site was either a JS file injected via a Atlas Universal Action Tag (which, of course, being Mr. Super Web Developer Man, you know exactly what that is), or a JS/CSS file injected via Omniture Test&Target or whatever it's called now.
I have no idea on your specific requirements, but it doesn't sound like you are actually devving the actual site.
Well, however you define "web developer", maybe I fell under the definition or maybe I didn't. Whatever, that's not the point.
The point is that CSS !important is really handy in some situations, and used for legit reasons every goddamned day of the week.
Saying that merely using it is a WTF is just ignorance of the web industry. Which is strange coming from such a Mr. Super Expert web developer like you.
-
-
Right you never said that, and that changes a huge amount of things about the assumptions of what you are doing and why you are doing it. Sorry I come from the mindset where I have full control or at least can make sure the requirements state that I the things I mention are possible.
-
Being a grammar nazi is possibly the poorest attempt at proving anything.
-
Right you never said that, and that changes a huge amount of things about the assumptions of what you are doing and why you are doing it.
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.
Sorry I come from the mindset where I have full control or at least can make sure the requirements state that I the things I mention are possible.
Obviously, since I had to explain it like 65 times until your tiny little brain cells were able to absorb some of the information.
BTW, you're still cheating your client/employer by not doing analytics or testing on your sites.
-
Honestly, my only problem at this point is that you are in a situation where you cannot claim to be absolutely, 100% correct. But you aren't. It's a style preference. You are Jeffing.
Filed Under: It's so much fun poking an angry tiger through the bars! | Something new for the Discopaedia
-
My point still stands, if you are using IDs all over the CSS it is done wrong from an architecture point of view. You can throw as many little insult as possible but it doesn't change the fact that something is very wrong with how CSS is built, which means the markup is probably a bit shit as well.
But hey ho, lets make "your specific usecase" completely undermine the main point that I was making that CSS should be done from a web components point of view.
-
Being a grammar nazi is possibly the poorest attempt at proving anything.
Wasn't trying to prove anything with that. Just having fun.
-
Actually now I'm more annoyed that a super expert genius web developer like you aren't doing any kind of testing.
-
I stopped having fun chatting with you quite a while ago.
-
I do actually. So don't make assumptions
-
