Hello i'm creating a webpage from scratch and I'm running into a problem
I know using the style tag is not very good, but would it be in this case okay to use? or maybe is there a better way of doing it?
let's say I have this CSS
.group-box {
margin-left: 10px;
margin-right: 10px;
margin-top: 10px;
display: inline-block;
background-color: rgba(30,30,30);
padding: 15px;
height: 100px;
border: 1px solid rgba(10,136,0, 0.2);
}
and I have
<div class="groupbox"></div>
but now let's say I wanted to make my groupbox bigger for one-time use, is it okay to do?
<div class="groupbox" style="height: 300px;"></div>
or should I just make a whole separate class like a small-groupbox and a big-groupbox with all the same properties, just different heights values? I'm leaning more towards the style attribute. But maybe there is a better way?
I am wondering what the CSS "coding" standard would say about this question. my question is subjective, but I want to know what most others who are more experienced at CSS would do in my situation.
Thanks
It totally depends on ‘your situation’. In particular considering maintainability/readability for future developers. There can be no one right answer. Both methods are allowed by the standard.
The thing to watch if using classes is cascading/specificity which you can be confident are dealt with if using style.
But set against that is the ability in a stylesheet to use class names which have meaning. And there is true separation between styling and semantics, the styling not being ‘buried’ amongst HTML. You can also group settings so the maintainer isn’t hunting through many lines of code to find changes.
You can use both, however, it's always best practice to use external CSS, and class than inline-CSS, however if it's very few line, then it'll not affect the performance much.
Related
New to the forums here, as well as HTML and CSS. In working on a project page for myself, I've got a table. Reading around how to center it, I went with something like this:
<table class="center">
And then
table.center {
margin-left: auto;
margin-right: auto;
}
My question is why is a class used to center here? Couldn't I just do:
<table>
and then
table {
margin-left: auto;
margin-right: auto;
}
I've tried this code, and it works, so I'm guessing the browser is covering for me here because I have not seen this applied anywhere. What am I not understanding here?
It’s a case of convention. They both work; but it’s better to segregate your styles into only the elements that need it. Without using a class then the style will apply to all tables, which may not be the case for all pages and is generally considered bad practice.
Oftentimes the same style sheet will be used on multiple pages of a site for consistency - so it’s better to select only certain tables rather than all - as it might not be the case that you want all tables on all pages to look the same. This doesn’t just apply to center styles, it applies to all.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
For example:
class="profile profile-image profile-image-large"
OR
class="profile profile-image profile-image-small"
Is there something wrong with these names or dashes?
A good rule of thumb when naming classes is to describe the purpose of the element's content.
PREFERRED
<div class="copyright"></div>
OR
<div class="social-media-buttons"></div>
In contrast, for reasons described below, being overly precise should be avoided.
LESS BENEFICIAL
<div class="column-1"></div>
OR
<div class="right-bottom"></div>
Here are some guidelines from the W3C:
Use class with semantics in mind.
Often people use class names like bluetext, or redborder. A much
better way to name your classes is with the role a certain HTML
element of that class has.
Good names don't change
Think about why you want something to look a certain way, and not
really about how it should look. Looks can always change, but the
reasons for giving something a look stay the same.
Good names
warning, important, downloadableImage and submenu are all
good names. They describe what a certain element represents, and they
are not likely to change. A warning will always remain a warning, no
matter how much the look of the page changes.
Bad names
border4px, lighttext and prettybackground are examples of bad names. You
might fatten that border to a whopping 5 pixels, or the background may look
pretty old after a while, and not pretty at all. An advantage of using
CSS is that you won't have to change much in order to change the looks
of your website. If you have to change all light text into dark text,
and thus change all classes lighttext to darktext in all your HTML
pages, you're likely to miss a few.
So, to answer the question:
Is there something wrong with this?
class="profile profile-image profile-image-large"
class="profile profile-image profile-image-small"
Well, do these class names represent "the role [the] HTML element of that class has"?
It's mixed. profile and profile-image are clear roles. But large and small simply represent how the image should look, which, as the W3C points out, can change. And if the size changes then the class name may have to change, as well.
Which leads me to this: The important issue isn't really the prefixing, suffixing or hyphenation of class names. What really matters is the quality of the name itself.
Maybe this would align with the W3C guidelines and offer greater benefits in terms of reusability, flexibility, and maintenance.
class="profile profile-image profile-image-main"
class="profile profile-image profile-image-thumbnail"
To be perfectly honest, this comes down to individual developers and their own feelings. There are two equally good ways of structuring CSS classes, just like you suggested:
.profile.image.large{
width: 300px;
}
/* Or: */
.profile-image-large{
width:300px;
}
They achieve the same thing, but when you start thinking broadly, you see just how wide the gap between these styles becomes.
Separating classes makes them re-usable: The DRY convention is to never repeat yourself. By separating the large or image classes, we can reuse the same class:
.blue{
border: 3px solid blue; /* All .blue's will have a blue border */
}
.profile.blue{
border-style: dashed; /* Inherits from the previous blue and replaces the solid with a dash. */
}
In the second approach - using - separators, the code would be:
.blue{
border: 3px solid blue; /* All .blue's will have a blue border */
}
.profile-blue{
border: 3px dashed blue; /* We had to redefine the entire style */
}
On a simple example like a border, this doesn't seem to matter. But take into account a much larger CSS chunk that you may want to re-use dozens of times throughout your code. You'll be repeating yourself a lot.
Logically grouping styles is still a good thing: I'm not saying that -classes are a bad thing - they help define a namespace for your code, so in the sense of maintaining modular code, prefixing your styles with an identifier will help prevent conflicts, especially if you're developing code inside a web agency that will be re-used, or if you're building a plugin (in which case, style prefixing is absolutely needed).
Developing in a compiled language like SCSS (my preferred environment) changes how you think too. In SASS/SCSS we can easily do this:
.profile{
display: block;
&-image{
border: 1px solid blue;
}
}
And that evaluates to the same as profile profile-image on the element. Alternatively SASS also supports:
.profile{
display: block;
&.image{
border: 1px solid blue;
}
}
Which evaluates to profile image on an element. Very similar - but both styles are restricted to their parent element .profile and can't be used globally. The styles are protected, whereas in my first 'natural' CSS example, the blue class could freely be added and incorporated by any element in the HTML page.
Edit: You could still use a global .image style in your SASS code, and then override individual examples, but personally, I feel this violates the DRY principle and I try to avoid doing it where possible.
So what's the TL;DR?
In my opinion, there's no "right answer". From a conventions standpoint, it's worth noting that frameworks like Twitter-Boostrap use a hybrid of the two styles - global classes that can be applied everywhere, mixed with prefixed classes that protect their children's styles.
The most important thing for any programmer is that your code is clearly readable and defined, and that you use as little code as possible to achieve your result - no matter what method you use.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
It seems there are two major schools of thought on how to structure CSS and HTML. I was taught to keep the HTML as clean as possible, and all things stylistic should be on the stylesheet. This has served me well thus far, but with this approach I often notice redundancies and inefficiencies.
I read up on the atomic approach, and I really like the idea. It seems to be the method I naturally gravitate toward anyway.
My question:
Which way is really faster, considering the two following blocks of code:
HTML:
<div class="main">
<h1 class="m-10 theme-c1">header with margin and theme color 1</h1>
<p class="fz-1 theme-c1 m-10">paragraph with font-size 1em.</p>
<div class="m-10">
<p class="fz-1 m-10">blah</p>
<p class="sub-paragraph">Sub paragraph</p>
</div>
</div>
Stylesheet:
/*margin-left rule*/
.ml-10 {margin-left:
/*font-size rule*/
.fz-1 {font-size:1em}
/*theme color*/
.theme-c {color: #333};
/*display rule*/
.dps-blk {display: block}
/
/*sub paragraph styles*/
.sub-paragraph {
margin-left: 10px;
font-size: 1em;
font-color: #333;
}
Elements in the HTML above all get whatever style they need, and the styles above are non-descendants except for .sub-paragraph.
So is it faster for each element to cherry pick which styles it needs, or is it better to just give it a chunk of styles (like for .sub-paragraph)? With .sub-paragraph, I can see how it only takes one match to get all the styles. The trade off, however, is that there isn't much else you can do with that set of styles except use it on sub-paragraph, or override some of its properties with another rule when applied to something else.
I'm think with these two approaches, it's a decision on whether to the cost on data size or on processing time.
Edit
I appreciate all the feedback. I forgot to mention that I'm specifically interested in the processing speeds of the different approaches.
This is interesting nonetheless.
If you were to begin cherry picking individual styles, you would end up with a stylesheet like:
.red{ color: red; }
.green-background{ background: green; }
.w500{ width: 500; }
.ml20{ margin-left:20px; }
Which is not very maintainable.
It sounds like what you are looking for is a way to extend certain classes (i.e. .sub-paragraph) with pre-existing classes, adding the styles of other classes into .sub-paragraph. SASS's .extend directive is a great way of doing this.
Sass and other preprocessors are great at merging the ideas of maintainable code and semantic code together.
Edit 1:
If you are looking into which method (more classes/less properties or less classes/more properties) is faster, I would suggest doing some testing with Chrome Dev Tools' Timeline. The two methods of coding aren't the only thing that are going to affect how fast a page renders/paints, so it is always a good idea to test these if you are concerned about speed.
I organize my CSS by grouping certain types of classes together. When creating CSS classes I ask myself, am I going to reuse this class definition for anything else? Is it logical for me to separate this class' definition, will someone who has to read this after me want to shoot themselves?
Basically I would say, go for maintainability, an extra 1Kb on your Css will not choke anyone.
CSS is designed to use classes for certain groups of styles. The .sub-paragraph method is usually way better than the seperate classes method. If you are going to assign classes for each style seperately, you might as well just use inline styles, via the style attribute. You should usually try to avoid that for maintenance reasons though.
I think there is a place for both.
I don't feel that the abstraction belongs at class names like .p1-gr-brdr, though.
If you're writing very tightly-composed, atomic HTML partial-templates (for things like AngularJS directives), then you'd likely get more mileage out of .title, .subtitle, .just, .content, where you can specify very specific output for those components.
Changing those components will be very simple and straightforward, as they're so compact and self-contained.
And if you find yourself in a position where you need to override one, to compose an inherited class, then you either have the option of composing a new class-name, which now might not be 100% semantic/generic (".big-green-subtitle"), but is still 100% self-contained for those moments where you want your special-cases to feel loved, too...
...or you can then specify behavior with a second-level selector.
If your .header has a padding, but you don't want your .update > .header > .subtitle to be subject to that padding-bottom, on mobile-phones, in landscape orientation, on Tuesdays, then you can simply have an exception which states .update > .header { padding-bottom : 0; }.
Otherwise the cascade will continue as normal, and things will either pile on top of one another, or you will cancel out side-effects with specialized classes which cover the same properties...
Otherwise, I don't see why all CSS sheets don't look like:
.p1-br { border-width : 1px; }
.p2-br { border-width : 2px; }
.p3-br { border-width : 3px; }
.p4-br { border-width : 4px; }
.gr-br { border-color : green; }
.lgtgr-br { border-color : lightgreen; }
.sfmgr-br { border-color : seafoamgreen; }
.aqmr-br { border-color : aquamarine; }
.em1-wd { width : 1em; }
.em2-wd { width : 2em; }
.em3-wd { width : 3em; }
.rm1-wd { width : 1rem; }
.pc1-wd { width : 1%; }
...et cetera, until you've written out every atomic option you could possibly want, for any theme your project (and all of its components) might want to support, across all platforms.
That seems like a terrible use of your day, to write a unique class-name for every possible edge-case out there:
<div class="pos-rel
p1-br
p18-ng-tp
mrpc12-br-r
lggr-bg
bg-im-spr-id-123
pc15-bg-im-algn-lf
ofl-x-hd
ofl-y-aut
brd-bx">
Seems hefty for a single div, for instance.
This would not, however, be a bad idea, if you could write CSS rules, give them to classes, where you expect flexibility, and later had the hard-numbers to those rules.
Such that, say, you write out a class which expects to treat height in rems, margins in percents, border-radius in ems, will take a background-colour and an image-sprite (say it's a backdrop container for a corporate/retail site, with a watermark and logo, where other content will scroll above it).
Now you want to reuse that set of classes on the same component, but for a different client...
It would help if you could simply have some variables, which could live in a separate file, and be referenced by your classes, so that your units don't necessarily need to change, but you can modify all of your hard-coding stuff in one or two places, and swap different variable values in for different clients as easily as pointing at a different sheet...
...but that's what SASS already does, if you take the time to sit down and figure out how you want to engineer something, and make your build process adhere to that desired outcome.
Lately I'm using a CSS structure that makes HTML much cleaner but I don't know if there's something wrong with this.
Instead of using:
.top { //properties }
.top-wrapper { //properties }
.top-logo { //properties }
And for HTML:
<div class="top">
<div class="top-wrapper">
Logo
</div>
</div>
I'm actually coding like this:
.top { //properties }
.top .wrapper { //properties }
.top .wrapper .logo { //properties }
And for HTML:
<div class="top">
<div class="wrapper">
Logo
</div>
</div>
Is it wrong to do this?
It is not wrong, but the more selectors you have, the higher the resulting specifity of your style. For more information about specifity see http://www.w3.org/TR/CSS21/cascade.html#specificity.
Imagine your example
.top .wrapper .logo { font-size: 10px; }
followed by this:
.logo { font-size: 20px; }
The <a class="logo"> will have a font-size of 10px, even though you specified it to be 20px for the second declaration.
It isn't necessarily "wrong" to do this, it works and if you find it easy to use I'd say go for it!
However - there are some drawbacks to this approach, for example your CSS file will end up larger, which will mean longer download times for anybody viewing the website (granted this effect may be negligible)
There's also the issue that, if you want to re-use the styles of top-wrapper on another element, you have to place that element inside a div with a top class, this ends up cluttering your HTML.
(For more information on the above point see OOCSS)
At the end of the day there are benefits and drawbacks to any approach, if you feel really comfortable with this approach, and it is working for you - then stick with it!
EDIT:
It should also be noted that you're second approach will take longer for the browser to render than you're first approach (the browser has to check multiple conditions instead of just one) for more info see this question
Nope.
What your second code is doing is saying, "target all the elements inside elements that have class top, that have the class wrapper and apply such and such properties"
On the other hand, your first code is only targeting the elements that have the class top-wrapper (or whatever) regardless of their parents class.
Depends how you will use that specified class
.logo { //general properties }
.top .wrapper .logo { //specific propery to top wrapper properties that overrides .logo }
.bottom .wrapper .logo { //specific property to bottom wrapper that overrides .logo }
HTML
<div class="top">
<div class="wrapper>
Logo
</div>
</div>
<div class="bottom">
<div class="wrapper>
Logo
</div>
</div>
Generally, it is better
It's not wrong, but it may get verbose and a little slower if you are have 10 levels of nesting. The result may also be harder to debug if both .logo and .wrapper .logo are styled.
On the other hand it may be nice to have a .button looking different in .content or in .menu. In general, use what makes sense in a specific use case.
No right and wrong here: everything depends on the site you are building, if you are in a team and what makes sense to you.
Personally I don't think the html is any cleaner now than it was previously (in this small example) but your CSS specificity has increased and that could have a detrimental knock on effect.
I now ask myself 'why do I want this element styled in this way?'. Sometimes it's because of inheritance, sometimes because it's a specific case that happens to be in a certain area. The example you use seem a good candidate for inheritance, but looking at the rest of the site might lead to a different conclusion.
Adding longer class names doesn't, to my knowledge, greatly decrease performance. I suspect the only effect would be marginal and is unlikely to be noticeable. Really dependant on the implementation
Additionally if you were 'reading' the html it may make more sense to read have class names like top-logo, other wise you need to look for the appropriate ancestor (bearing in mind there may be more than one that could be applicable).
I'm busy moving toward an OOCSS / BEM method (google these for more, so many resources out there...) myself because I believe it will make maintenance easier in the future, plus I find it makes more sense within a team environment. These are approaches that could lead to 'classitis' or otherwise 'messy' html. I don't mind that though and think the larger the site the more sense this makes. If you're making a 4 page site, maybe don't bother.
But this works for me and may not for you. So I go back to my original statement, there's no right or wrong here :)
I am coding a .psd image to html. But i confused with the best practise to do so. i.e
for styling a achor like a button i use following style attributes
.button {
padding: 10px;
display: inline-block;
text-decoration: none;
background-color: #3f4551;
color: white;
background-image: url("../images/icons/icon_left.png") no-repeat 10px center;
}
now i can use the to get the desired result.
However i have lots of anchor which have same styling as before only with minor changes like icon on right side instead of left and different color,gradient etc.. so i decided to break it in multiple class i.e
.button{
padding: 10px;
display: inline-block;
text-decoration: none;
background-repeat: no-repeat;
}
.icon_left{
background-position: 10px center;
}
.color_blue{
color:blue;
}
now i can use these classes to style i.e <a href="#" class="button icon_left color_blue></a>"
But in this way the markup is getting more and more clumsy and weird.So i decided to ask for which is the best practice ??? THANKS in Advance :)
That's a good start and you are going in the right direction.
Some further hints though, considering best practice:
Use descriptive names which are not explicitly telling their value. For example, do not use color_blue as class name because the color could change if you redesign your application. Better are names that reflect the purpose of that element, like default-action, disabled or emphasized. In the same manner, with-icon would be a better class name than icon_left. Names are about semantics, and not the visual representation.
Use specific selectors if applicable. For example, if the button classes are used by button elements use selectors like button.emphasized. That let's you reuse that class name for other types of elements (i.e. div.emphasized), so that you do not have to rename them into .button-emphasized and .block-emphasized.
If you know more about the structure of your document, you could even distinguish between #content > button.emphasized and #sidebar > button.emphasized and use different button classes depending on the element hierarchy.
Use selector inheritance if applicable. If a class shares the same property-value pairs amongst others that differ, you should use inheritance. For example .emphasized for rules that apply to all elements using this class, and button.emphasized & div.emphasized for specific rules, which can overwrite the more general ("parent") selector.
Apply naming conventions. Usually, the names are lowercase and the minus sign is prefered instead of using the underscore. Therefore, with-icon is better than with_icon. You can also use uppercase letters like so: withIcon. Personally i prefer the first version.
If I understand correctly ..Your on the right path! I know it looks like your source code is too stuffed but that's the way it works.Remember that classes are used for styling more than one element, and Id (if used in the proper way) are used to style a single entity/element