|
Specifically, I sometimes break out the CSS to represent specific style attributes, used like this:
<table class='noborders fixed fill'>
and sometimes I lump a bunch of attributes into on CSS, used like this:
<textarea class='taeditor'>
and sometimes its a mishmash, used like this:
<div class='preview h100p'>
The only rhyme or reason is that some CSS styles are reused, like "h100p" (height 100% if you want to know), and some are specific to the container.
Obviously, I could create a style for each tag that contains all the style attributes, but that rather blows CSS re-use out of the water.
So what do you do? Do you have any guidelines you live but won't die by?
And while we're at it, how often do you actually use the "C" part of CSS -- cascading? I've come to avoid that aspect like the plague because as soon as I change something in the layout, the cascading element/class/id structure changes, and I have to go back and fix the CSS. The rare exception is when the container and its children need to always be moved as a unit. You're experience?
|
|
|
|
|
Marc Clifton wrote: Do you have any guidelines you live but won't die by?
Yes, I don't go anywhere near that Web stuff.
|
|
|
|
|
PIEBALDconsult wrote: es, I don't go anywhere near that Web stuff.
Don't worry. It's just a fad and will pass soon.
Social Media - A platform that makes it easier for the crazies to find each other.
Everyone is born right handed. Only the strongest overcome it.
Fight for left-handed rights and hand equality.
|
|
|
|
|
I know, right?! This internet thingy and these web pages I think they call them, just silly, through and through.
|
|
|
|
|
I basically do the same thing, if it's only going to be used in a certain place and only once I do inline but if it's used more than once I put it in a css file.
I also have a bad habit of putting a style link at top of html page "temporarily" for testing and end up leaving them there until I go back and clean up.
Technician
1. A person that fixes stuff you can't.
2. One who does precision guesswork based on unreliable data provided by those of questionable knowledge.
JaxCoder.com
|
|
|
|
|
I generally try to break the application up into sections and then write the css to match. For example an application might have a "main menu", "main page", "edit page". Then the CSS can be like:
div.main-menu {
}
div.main-menu a {
}
div.main-menu div.sub-menu {
}
div.main-menu div.sub-menu a {
}
It starts out well, and works for the most part, but with larger applications it quickly gets messy and it's too easy to change something by mistake.
The truth is, I find CSS to be a massive headache to keep organised, and I am surprise Visual Studio have never added better tools for managing a CSS file or at least try to encourage a specific standard.
The bottom line is, I don't think anybody really knows how it's supposed to be done. We just make do and hope nobody asks for too many changes! 
|
|
|
|
|
musefan wrote: I don't think anybody really knows how it's supposed to be done.
Heh, that's definitely my experience!
|
|
|
|
|
musefan wrote: I generally try to break the application up into sections and then write the css to match
I tried that, initally, but it ended up with having to make change after change after change affecting multiple files, which was not a pleasant experience.
Now, I do mock-ups with the css in the header of up to three files, and when it's right, I export it to a css file, and form the other files on that.
I wanna be a eunuchs developer! Pass me a bread knife!
|
|
|
|
|
You need to look at LESS or CASS. This lot would become
div.main-menu {
...
a { ... }
div.sub-menu {
...
a { ... }
}
}
cheers
Chris Maunder
|
|
|
|
|
did you mean SASS by any chance?
|
|
|
|
|
I leave that stuff to front-end devs while I get on with proper development.
|
|
|
|
|
|
Two main types:
Bulk classes to control a lot of styles at once.
Trees, styles subordiante to an top-level style (like td and td automatically for a given table)
Mini classes to control very specific attributes (bold, center, shadows, position, etc)
and sometimes the latter to modify the former two - and even inline style='' for some final touches if needed
So - pretty much the same. The final tweaks are much more often for functionality than esthetics.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Firstly, I make it a point to put nearly all formatting in CSS. This will make all the pages look similar. Too many times over the years, the web page style would change depending on the programmer. If I'm working with someone that is not strong in CSS, I tell them to just use divs and do not add any styling; I'll do it.
I typically have a Main (parent) CSS document and then it's children, based upon its function. In the Main, the basic structure of the web pages, fonts, size, and other selectors that will be reused. For the children CSS documents such as a sidebar, formatted tables for tabular data, printing, and even colors I have separate. Having all colors separate allows me to easily create themes and plug style such as a sidebar or tabular data when needed. And yes, I do use multiple selectors for HTML attributes; such as:
<div class="content theme p8 mt50 b red"></div> And for the CSS coding guidelines, I put everything on one line; I don't make it look like a programming function because CSS is not a programming language.
|
|
|
|
|
Quote: And for the CSS coding guidelines, I put everything on one line; I don't make it look like a programming function because CSS is not a programming language.
Ha, I do and I don't. Generally depends on the project I'm working on and the mood I'm in where CSS is concerned as to whether they get the "one-liner" treatment or not. But in most cases if I'm defining something that has only 1 - 3 attributes, say for basic <p>'s, then they get put on one line. But if I need something more complex, such as adding gradients or something that needs a lot of attributes, I don't put them on one line (the minifier can deal with that one) because it's simply easier on my eyes to see what I'm doing (classic example - styling stupid form elements...  )
p { ... }
form { ... }
...
input[type="blah"] {
blah;
blah;
blaaaaaaah;
}
...
CSS can be a massive pain for sure, no one can ever deny that one (!!) and get way out of control all to easily, so I stick with a "standard" (more of a personal convention in reality) I've molded for myself over the years that works quite well for me and other's can easily grasp. Urg... haha.
Lately though I've been leaving it all to Bulma or Bootstrap and run the other way so I can do the actual work I need to do and deal with it after, not gonna lie
|
|
|
|
|
Yea, that is a good idea to add line breaks on complex styles. I'm old school CSS and followed Eric Meyer's style back in the early 2000's, though I do break up complex styles to a certain point. I compare it to SQL. I hate it when I have to fix someone else's select statement and it has 50+ attributes all on separate lines and I have to scroll up and down to just get to the tables.
|
|
|
|
|
Are you asking what my best practices are or what I actually do? 
Best practices (in my view) are to use CSS to describe the function of the element, not the style.
So instead of
<div class="centered bold padded info-background">A message</div>
I would do
<div class="alert-box">A message</div>
So that when you decide all your alert boxes will be flush left, or be in italics, or by pinned to the bottom, you're not changing classes on elements, you're changing the style definition of the alert-box class.
For layout I try and define broad types of layout (container, row, column etc) and use them in combination CSS classes that provide intent, not style. I'm not a fan of throwing HTML onto a pile and then using CSS to reorganise it on the screen, so if I'm changing layout I'm changing HTML, and so will change the element's CSS classes at the same time so everything reads sensibly.
cheers
Chris Maunder
|
|
|
|
|
I think what Chris writes here, and Marc alluded to in the original post, is an important point to be emphasized for beginners.
You want to describe the functionality. So, not that "this is a green message", but "this is a success message", so the style name gives some meaning to the use.
Often, this means that you have what seem like repeated (or very similar) styles, because the "success" message looks just like the "informational" message--but doing it on a functional level allows those things to more easily migrate away from each other in the future.
I still find it difficult to properly break the style from the structure of the page, so when restructuring happens, it often means style changes as well.
As to Marc's other question, I'm not so familiar with the cascading part.
At my last place, we just started using bootstrap for styling, it seemed like that was a really nice approach.
|
|
|
|
|
Totally agree.
This rule is violated in many other places besides CSS!
Like code that used to be:
... WARNING ... something about a color and maybe an icon.
Referenced as WARNING
Refactored to
... YELLOW ... yellow
Referenced as YELLOW.
Why is it yellow? (that information has been lost now)
|
|
|
|
|
If you like Bootstrap you might also like Semantic UI. I find their approach a little neater and more expressive.
cheers
Chris Maunder
|
|
|
|
|
It's appropriately named!
|
|
|
|
|
For perfect CSS in an ideal world (which seems to be what you want to talk about), I would say you should put every set of styles that occurs separately elswhere in the same project in a separate CSS class, while keeping the overall number of classes as little as possible. It can also be a good idea to draw additional separation lines between CSS classes "by subject" (page layout, object style, colors, fonts, ...) and put them not only into separate classes but into separate CSS files. This is an object-oriented CSS approach. By this, you for instance gain the possibility to have your design person maintain the colors.css for you, which means more control for her/him and less work for you.
But all this means a lot of effort, because as your project progresses, you sometimes have to split one CSS class into two or vice versa and then refactor all usages of these classes. But the more experienced you become with this approach, the less this will happen bc you will learn to think ahead to avoid the pain of refactoring. And that's when your initial effort will pay off, for yourself and for your company as well.
Cascading can be very useful in everyday practice for doing a rather loose specification in a more top-level element and be more precise in a child/descendant element. Or a second use case I can think of from my everday practice is to define a "base" style for a bunch of elements and still be able to "override" them and specify exceptions in particular cases.
|
|
|
|
|
I didn't think cascade was bad until my ~3 year stint as a front end specialist. In that time I learned to use B.E.M[^] and the world was good. Cascade is bad.
Elephant elephant elephant, sunshine sunshine sunshine
|
|
|
|
|
I have a device with a USB-C cable to charge it.
I have no USB-C ports, but I do have a very nice little fast charger (Qualcomm support) with multiple USB 2 / 3 connectors (Type A style).
"Ah!" I thought. "I'll get a simple little USB-A male to USB-C female converter".
FleaBay sells 'em cheap.
They arrived today. All five of them. "Odd." I thought. "I only need one".
"They are a little small." I further thought.
There's a reason for that Griff, you idiot. Those are USB-C Male to USB-B female. 
Not one detail is actually correct.
Oh ... c**k.
Sent from my Amstrad PC 1640
Never throw anything away, Griff
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay...
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
