Why do I see .closed-dialogue and .open-dialogue so often in commonly-used libraries, instead of .closed.dialogue and .open.dialogue?
the problem with a single class per element
To format all dialogues with the first approach, you would already need two classes in the selector.
Each time you add another difference, f.e. some colour, you would multiply the number of classes in the selector: .warning-dialogue-closed, .error-dialogue-closed, .warning-dialogue-open, .error-dialogue-open.
Now how can that be good practice? This is hardly maintainable!
You couldn't even separate your code in modules, since the basic selector for dialogues needs to know all dialogues that exist!
several classes per element solve this
By concatenating several classes, the code would be way shorter, more maintainable and easier to read:
.dialogue formats all dialogues, no matter how many different you have.
.error.dialogue and .warning.dialogue would add changes for either flavour. .open.dialogue and .closed.dialogue would take care of the other difference.
You even could have another isolated module that defines big and small dialogues, and the basic module doesn't even have to know about it.
So why have I never seen this?
The problem with your approach is that it's more likely to conflict with other classes.
If the page itself has some other unrelated open class, class="open dialog" will pick up rules for that class and get messed up.
This is why libraries like jQuery UI tend to prefix all of their classes with a unique value.
Related
I have been looking into CSS coding methodologies like SMACSS and OOCSS. After doing some homework and inspecting the styles of larger sites (e.g. Google, Facebook) I have noticed very mangled selector names, such as ._50x4 with no stylistic or content semantics.
I am wondering if these larger sites are using some type of name mangling for their css selector naming?
Re the specific selector you specified: ._50x4 in the question.
This selector does look odd, but in fact it's not invalid or mangled.
It is invalid for a class (or ID) selector to begin with a number, so .55x4 would be invalid. But an underscore is a valid first character for a class.
Therefore, the selector ._55x4 is really just a way of having a class named 55x4, but with an underscore at the start of it to make it valid.
Why would you want a class named 55x4? Well, you'd have to ask the developers of the site where you found it if you want the real answer, but you mentioned Facebook and Google, so we can speculate a bit.
Both Facebook and Google are extremely high traffic sites. Therefore, as far as they're concerned, reducing the size of their HTML/CSS/JS code even by a single character makes a big difference to their bandwidth costs.
You or I may have named the class with a more readable name, but when you're trying to save every single possible byte of bandwidth, sensible names go out of the window. So much the same as they've minified their Javascript code to the point of making it unreadable, they will also have optimised their HTML and CSS code to make it as small as possible. Crazy class names like this are the result.
That's not to say this class name is completely crazy -- you've quoted it completely out of context, so there's every chance that the numbers 55 and 4 may apply to something on the page. I don't know, and without any context, no does anyone else.
But I can say this much: This is one case where copying Facebook and Google is not necessarily the best idea. You don't have the same traffic levels as they do, and shaving a every last byte off your code shouldn't have the same kind of priority for you as it does for them. Sure you can optimise stuff, but there's no need to write class names that look like that.
The other thing to say is that for SEO purposes, sensible class names are very helpful. Facebook and (especially) Google can get away with ignoring their SEO rankings, but the rest of us can't.
So regardless of your methodology, class names should be semantic -- ie they should make sense, and help the reader understand what the elements are for.
You're doing the right thing by looking at well known sites to see what they do, but my advice is to try looking at other sites that are closer to your own. Facebook and Google will always be a bit "different" when it comes to how they do things; they're not always the best examples.
I've read this
Why selecting by ID is not recommended in CSS?
which presents arguments for why you would use classes instead of ID's. And many dev's go cold turkey and refuse to use ID's at all for style selectors.
But, I'm sure many if not most experienced devs still use ID's as stylistic hooks(while favoring classes).
What are some possible scenarios that might justify using ID's instead of classes?
You may use ids when you are targeting unique items (you don't want to reuse that particular style) like #header,#footer.
Another good reason to use ids may be if you're a front-end developer thattakes care of some basic javascript too. Javascript access to elements via id is a lot faster than by other chained class names, so for performance reasons , you (as a js developer) might want add an id to your widget that allows you to access that element a lot faster.
For example
#widget
is faster and easier to access through js than something like
.wrapper .container .sidebar .widget:nth-child(n)
From what I've found, people (not all, but most) that try to only use class and attribute selectors make a mess of their style sheets. They end up putting a class on everything and then have long selector strings trying to move one certain element, which is where ID selectors shine. ID's were implemented into CSS for a reason and they are great when used properly.
Just use sparingly.
I was reading this:
"Guideline Number 7: Try to avoid using unecessary classes and IDs.
So, now that we’re keeping our hooks to a minimum, it’s time for our next step in quality over quantity: naming. We want to avoid names that imply presentational aspects. Otherwise, if we name something right-col, it’s entirely possible that the CSS would change and our “right-col” would end up actually being displayed on the left side of our page. That could lead to some confusion in the future, so it’s best that we avoid these types of presentational naming schemes."
So what do I call them if not right-col and not presentational?!?!
I discuss this very topic in "How to Develop with CSS". What you call it depends on the content. Maybe "sidebar" or "links" or "extra".
any naming technique has advantages and disadvantages...try to find a way that help you more in your work, and make well commented css files.
Rather than naming things after their presentation name them for their function, or purpose. Also, try to use a coherent page structure so far as possible, and use the CSS cascade to access/target elements.
As long as it conveys meaning for the html structure and other developers can understand well it should be fine.
check out 960.gs using that gridsystem will save a lot of time, trying to figure out the best naming scheme.
NCSS Sheets is a naming convention and guideline for semantic CSS: CSS class naming convention
I'm faced with a business requirement that I believe may be solved by implementing CSS variables.
Basically, while the front-end developers on this project are in charge of CSS implementation, the designer wants to be able to introduce different "themes" for the site.
By swapping one theme for another, a range of changes (such as font-size, font color, border width, etc) can be made without having to change too much code.
Currently we're trying to fit this requirement by splitting up the styling of components into different CSS files - e.g. one for layout, one for typography, one for colors, etc.
But I don't like this approach. It makes the CSS quite unmaintainable, and it's difficult to separate out all the CSS for one particular component, which is becoming a frequent requirement.
I'm hoping to instead introduce a standard set of "variables", which can be tied to a particular theme.
The CSS will be pre-processed and the variables will be swapped for the actual value depending on the theme used.
This will enable us developers to organize our code most effectively, while still keeping it flexible enough to be customized according to the designer's tastes.
Any thoughts on the pro's/con's of this?
The only disadvantage that I can think of is the added complexity of having to use or write a pre-processor, and appropriately manage the caching of the output in order not to have each request pass through the pre-processor.
You might also have some issues with syntax highlighting in editors when you use your new variable syntax, but that can probably could be solved.
Apart from that, I guess it should be all advantages.
You might be interested in checking out LESS:
#brand_color: #4D926F;
#header {
color: #brand_color;
}
h2 {
color: #brand_color;
}
Pre-processing a CSS seems like a good idea. The disadvantage I see is that, this additional abstraction will entail its own problems - bugs in the processing code might lead to an invalid or buggy CSS. Overtime things might become difficult to maintain.
You might want to have one fully working CSS without the variable, and then have another pre-processed CSS with the minimal required variable stuff, which overrides the original CSS.
I don't see any improvement over just having different css-files for the themes: You say you just add some variables to change fonts, colors and the like. What about borders, alignment and a lot of other stuff? Themes are not just 2-3 color variables. A theme for a bigger webpage can get pretty big and different themes for the same page might not only differ by a few colorcodes. I don't think it's a good idea. Let the front-end designers just create different css-files for the themes and load the css-files that belong to a theme.
A big disadvantage is certainly that you aren't writing CSS anymore. You are writing in a proprietary language, that compiles to CSS. Inventing your own programming language is on page one of the things-that-are-a-bad-idea-for-business book. If you are doing this as an experiment or for a personal project, then go ahead, but otherwise I'd say that you're asking for trouble.
A concrete problem I could foresee is that developers might have editors/IDE's that knows how to deal with CSS, but don't know how to deal with your dialect of CSS. That could restrict said developers quite a bit.
But really - The point isn't listing up pros and cons. The point is that you're moving into uncharted territory, and that's - out of principle - a bad idea, unless it's your core business.
Edit:
I'd just like to moderate my answer a bit. From a technical perspective, it may well be a good idea - Depending on how well you control your environment, how able you are to retrace your steps and a lot more. This is essentially a type of external-DSL, which can be a very powerful instrument. I don't think I would apply it here though, since you're targeting (frontend) developers, and I think external-DSL's are better used at administrators/non-developers. But it could be used successfully.
My main concern is that you're only approaching this from a technical point of view, which is a common fallacy for us developers. From a business-perspective (assuming you are a business), it's probably a really bad idea. That's what I was trying to voice.
I have a messageboard and one of my users has written a greasemonkey script to stylize various elements within the page. He did a great job with it but in order to make his job easier, the first step in his script is to parse the current page and add several css classes to almost all html elements on the page. most of them aren't used to style the page at all, but instead to make it easier for him to query the couple elements per page that he will actually modify. for example class="thread_started_by_user_123 thread_with_456_posts thread_with_789_views thread_last_posted_in_by_user_12345" etc etc
is this a standard practice? are there any downsides to adding lots of unnecessary css classes, either in javascript, or on the server if i were to add them to served pages too.
This looks to be using classes to embed arbitrary metadata into elements, which is certainly not what the class attribute was designed for. Given that its effects begin and end with a greasemonkey script and are thus localized to the client, it seems a harmless enough hack, but not one I'd advise duplicating on the server side.
HTML unfortunately doesn't provide much in the way of alternatives when it comes to metadata other than sticking in invalid attributes, so there is a mechanism that does add semantic meaning to the "class" attribute within existing tags -- namely microformats. There's a lot of breathless buzzwordy hype around microformats, but overall they do revolve around a best practice for areas where going all-xml is out of the question.
In terms of semantics, yes there are downsides. If you have classes that aren't descriptive of what the element actually is and are there for styling purposes only, this can hurt you down the road should you decide to redesign and/or restructure.
for instance, BAD:
<div class="header red left-side">
GOOD:
<div class="header main current-event">
If there is no associated style with a class that's assigned to element, then I believe the browser will just ignore it. So it will not increase your page processing time a lot if that's what you are worried about.
However, if there are lots and lots of classes for each element, then you have to realize that you are using valuable bandwidth and increasing the time it takes to load the entire page that way. You can avoid that problem by externalizing the CSS so that the browser can cache it.
Are you using jquery to query the elements that you really want to modify? It might turn out that its more easy to pick those elements with jquery selectors which seem difficult or impossible with standard JavaScript and thus you can possibly avoid all these extra unnecessary classes.
Bottom line, there is no problem in using lots of classes if they are needed, and that's perfectly fine for production, but if you don't need them, like in your case, there has to be a better solution that you can possibly come up with.
Just for a data point, I took a look at GMail's HTML yesterday (their buttons are very nice) and it's full of that kind of thing.
Here's an example:
class="goog-imageless-button goog-inline-block goog-imageless-button-collapse-left goog-imageless-button-collapse-right"
Classes are not just for CSS, they're for the categorization of sections of markup. Applying styling based on that categorization is just one use. So if the classes are useful for other categorization purposes then that is fine, and perfectly good practice.