Bootstrap is one of many sites where I have noticed this practice, that to me seems bad but it is widespread enough, and done by people more experienced than me that I think I must be missing something. Take for instance the 2.1.0 version of Bootstrap, if you view source, lines 44-46 (the top of page menu) are these:
<div class="navbar navbar-inverse navbar-fixed-top">
<div class="navbar-inner">
<div class="container">
I understand the associated CSS properties of each class, and the shortcomings of using a framework that is made to be useful to as many people in as many situations as possible but having largely finished a design I am now trying to clean my markup. Is there a reason to use 3 divs when 2 would (from what I can tell) suffice?
While '.container' has a set width, clear properties, and margin settings for centering, I don't understand why '.navbar-inner' is in a separate div from it's parent. It seems like it would make more sense to add it as a class to it's parent div and reduce one layer of nesting.
Is there a reason why I should leave this structure in place (or for that matter something I should incorporate into future coding practices)?
Nesting divs allows you to style and access them separatelly, which can come in handy. But of course it depends on your actual needs, and as you state, a lot can be accomplished just by using css without excess divs.
In most cases you could reduce the complexity of the markup by combining several classes like
<div class="navbar navbar-inverse navbar-fixed-top navbar-inner container">
or
<div class="navbar-inverse-fixed-top-inner-container">
But for that kind of markup to work, you would have to generate quite a lot of CSS rules to satisfy every case.
By separating most use-cases in CSS and with the markup, you end-up with something quite readable and not so heavy on both CSS and HTML sides.
This also allows you to satisfy lots of combinations for a lot of users.
IMHO, the main principle behind that hierarchy is scalability. Because you can easily remove the .container to put something else - or just move it elsewhere. This is only for later use, when you'll read your code again, in 10 years maybe.
Another principle I'd like to point out is encapsulation. If you program in object oriented languages (JS, C++, C#, Java, many others..) then you must be familiar with it.
Based on your example :
<div class="navbar navbar-inverse navbar-fixed-top">
<div class="navbar-inner">
<div class="container">
The .container should not be aware of its container - you seem to agree with that - but nor should the .navbar-inner be aware of its own .navbar state : whether it's fixed, inverse, or not even a navbar.
The .navbar-inner should only serve to provide its children the appropriate behavior, and I think that's why it's best to keep it separated, even if you could mix it with the navbar.
Maybe in some new versions, or just if you want to change the default behavior, there may be conflicts between the navbar and its inner.
Let's try to avoid that and keep the intended structure. It doesn't look so messy anyway...
Thats the way styling (in this case for example width/height, border, margin, padding) works best on different browsers (IE vs. the rest).
Related
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 3 years ago.
Improve this question
<div class="navigation header-transparent-light aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--14 aem-GridColumn--offset--default--0">
Why do classes of a division have all this information? Isn't a class supposed to be simply for allowing a CSS file to target it and customize it on the stylesheet?
This is from line 126 in the homepage page source of www.marcus.com.
And the body starts off with a bunch of div creations.
<div class="root responsivegrid">
<div class="aem-Grid aem-Grid--14 aem-Grid--default--14 ">
<div class="responsivegrid aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--14 aem-GridColumn--offset--default--0">
<div class="aem-Grid aem-Grid--default--14 ">
<div class="experiencefragment aem-GridColumn--default--none aem-GridColumn aem-GridColumn--default--14 aem-GridColumn--offset--default--0">
What's with all the long class names that are pervasive in large websites?
Disclaimer: I'm just getting started with HTML (3 days in).
Looking at all this for the first time, I ask myself.. "how do they not lose track?"
I think I might be able to shed some light on things here.
Naming conventions in CSS have become an important part of web development over the past decade in an attempt to prevent your styles from "leaking" across your application and to ensure you don't have to write CSS that's overcooked with specificity.
By conforming to a naming convention it should hopefully mean writing styles unique to an element and not battling global styles. BEM is probably the most common convention used but it can lead to massive class names and it can get tricky when to know what to define as a "block".
These days with web components hopefully a lot of these issues are going to disappear. I'd advise reading css-evolution-from-css-sass-bem-css-modules-to-styled-components to get a good understanding of why CSS looks the way it does today and get a sense of where is could be going.
As another little nice to know HTML class names are case insensitive. So whilst you may see pascalCasing in class names typically a class name should be kebab-case ie .global-header instead of .globalHeader.
Just to add to #stwilz excellent answer a short version :
One of the most gruesome tasks in web development is refactoring CSS. Refactoring means that you sometimes want to split or join rules for some scopes.
CSS has no purpose-driven semantics, which means rules are all about the result, there is no way to convey meaning. There is also no scoping, all rules are global. SASS can help to some extent. But largely, you need to use very descriptive class names with some kind of inheritance marking (like the --s you see) so that:
1) Descriptiveness: when you revisit your code a year from now, you can tell why in the world that rule exists, where it applies and how it can be moved or dropped or split and what it will probably affect.
2) Modularity: to prevent rules that are very specific to a scope from leaking global, or even more troubling, from leaking to inner elements, you will usually prefix all rules in that scope with a same prefix. Now, in your design you may decide that a scope needs a -sub and a -sub-sub scope... Imagine, if you will, a programming language where all variable names are global. You would surely use a similar strategy to name them...
some designers create their own framework it's a bit like bootstrap https://getbootstrap.com/ we use this framework to build websites more faster
for example : when we write
<div class="col-md-9 hidden-xs fixed-top text-center"></div>
in the classes above we make the div width 9/12 from the screen width , hidden in mobiles , fixed in screen top and finally the text align center
so some designers create their classes and use them so the classes seem to be complicated but it let them to write less CSS or design a complete website without writing any css only using the classes they have in the framework
currently the best framework is bootstrap because its classes names is easy to learn and it has a lot of features but with time you'll probable create your own framework and you own classes that specific your needs .
i hope that this answer helped you , Have fun :)
As a designer you'll learn separating your CSS code from 'layout' related code to 'typology' related code will allowing for refactoring later when changes are required. Plus, it makes the code easier to read.
In order to make the above task easier, adding multiple classes to an object helps.
I can give you a simple example to illustrate the point:
<div class="container top left"></div>
<dic class="container bottom right"></div>
When making a media query, I know I can reference the 'top' and 'bottom' and at another viewport, I can reference the 'left' or 'right'. It's just easier to write and remember.
Please note the above may not be convention and is personal preference.
[Note: for those who may be confusing this question with "why not use tables for HTML layout", I am not asking that question. The question I'm asking is why is a grid layout fundamentally different from a table layout.]
I'm researching CSS libraries (in particular Bootstrap) for a project. I am a programmer rather than a web designer and I feel I could benefit from a library that encapsulates good design.
We all know that it's bad practice to use HTML tables to accomplish basic site layout because it mixes presentation with content. One of the benefits provided by CSS libraries like Bootstrap is that they offer the ability to create "grid" layouts without using tables. I'm having a little trouble, however, understanding how their grid layouts differ in any meaningful way from the equivalent table layout.
In other words, what is the fundamental difference between these two examples of HTML? Am I wrong in thinking that the grid layout is simply a table with another name?
<div class="row">
<div class="span16"></div>
</div>
<div class="row">
<div class="span4"></div>
<div class="span4"></div>
<div class="span4"></div>
<div class="span4"></div>
</div>
and
<table>
<tr>
<td colspan=4></td>
</tr>
<tr>
<td></td>
<td></td>
<td></td>
<td></td>
</tr>
</table>
The difference is that the first example is semantically marked up, assuming the data being marked up is not actually tabular. <table> should only be used for tabular data, not for any data which happens to be displayed in a layout similar to a table.
It is correct though that using CSS packages like Bootstrap, which require you to assign classes to HTML elements which are not semantic but presentational, reduces the separation of content and presentation, making the difference somewhat moot. You should be assigning semantically meaningful classes to your elements and use lesscss mixins (or similar technology) to assign presentational behavior defined in the CSS framework to these classes, instead of assigning the presentational classes to the elements directly.
Say:
<div class="products">
<div class="product"></div>
</div>
.products {
.row;
}
.products > .product {
.span16;
}
Note that I say should. In practice this is not necessarily always the more workable option, but it should be the theoretical goal.
I believe that CBroe comment is the best option, so I chose to clarify it.
Avoid div's. A div should be your last resort, not your first option. Instead, try to use Bootstrap classes on the actual elements. For instance:
<form class="container">
<fieldset class="row">
<label class="span4" for"search">Type your search</label>
<input class="span6" type="text" id="search" />
</fieldset>
</form>
It is a shame to use fieldset to contain a single field, but it is semantically best than using a div for the same thing. The HTML5 standard defines many new container elements, such as article, section, header, footer and many more. In some cases you will have to use div's, but if you minimize it's use then your code will be way more semantic.
The fundamental difference is that you can "reflow" the layout with Bootstrap for different display sizes simply using media queries without needing to change your markup. For example, I can decide that on desktops, I want your 4 divs to be on same row because user has high resolution wide display but on phones I want 2 dives on one row and next divs on next rows. So this way I can adapt my column count in each row using media queries. If you use hard coded HTML tables then it is very difficult to do this.
Having said that, I don't really like bootstrap implementation for the following reasons:
It has breakpoints hard coded in pixels. This means, as phones and tables advance in display resolution, your website may start showing unexpected layouts on those devices. Pixel count is poor proxy for display size.
It limits maximum used display area to 1170px which is again a bummer for users with nice wide displays they can actually use to see more content in your app.
Bootstrap's layout is not source independent, i.e., you can't change column order that is set in HTML. This is however more of a pedantic point.
The default layout is for very small resolution and higher resolution layouts trigger only when media queries fire, which IMO, is a poor choice considering phones will continue to have better resolution and sooner than later your website would have default layout set for outdated mobile devices.
Bootstrap layouts are not truly "worry free" in the sense that you have to read their fine print to see all the bugs and browsers they didn't see worthy of supporting but which you may care about. If you are targeting users in South Korea or China, you would be in for surprise, for example.
So, not everything is gold in bootstrap and their approach is not necessarily always the best possible (as an aside, one other thing I despise in bootstrap is their obsession with so called "jumbotrones" - those real estate wasting inconvenient in-your-face headers - which I hope community doesn't start taking as "new standard"). Personally I use CSS table layout (display:table) these days which has similar benefits as bootstrap without hardcoding <table> in my markup. I can still use media queries to rearrange rows depending on portrait or landscape orientation, for example. However the most important benefit is that my layouts are truly pixel or even percentage independent. For example, in 3 column layout, I let content to decide how much space first and last columns should take. There is no pixel or even percentage width. The center column grabs up all the remaining space (which is good thing for my app, but it may not be for others). In addition, I use ems in media query break points which bootstrap surprisingly doesn't.
I use the Bootstrap grid for page layout, tables for tabular data.
I think of the grid in Bootstrap, not as a grid in the developer sense, like a gridview control, but more in the design page-layout sense - as a grid to contain the page contents. And even though the Bootstrap grid could be also used to create a conventional grid containing tabular data, as deceze pointed out, this kind of grid is better suited for HTML tables - which are still acceptable to use in this scenario.
if you just use tables i think you will miss out on alot of flexibility in re-sizing your document for mobile/tablets without having to make a separate page for each device. once your table structure is defined all you can really do is zoom in and out.
While there's not necessarily much semantic difference between the two sets of markup (since the classes used by Bootstrap's grid system are indeed purely presentational), one very important distinction is that the grid system is much more flexible.
It would be very difficult, for example, to make your table-based layout respond to different screen sizes. There's no way to tell the browser to display one td element below another td in the same row. Whereas with the div example, that's easy to do, and the same markup can be presented in different ways even when the classes are "presentational" in the sense that they define the relative proportions and positioning of the elements on the page.
If I may, I'd like to summarize what I gathered from the other comments and the link explosion I experienced from this page:
The problem with using tables isn't the grid layout, it is the attempt to express it with HTML instead of CSS.
Bootstrap allows grid layouts through (mostly) pure CSS, which is why it is OK. The 'mostly' part comes because your HTML will still be contaminated by your layout data, but more subtly:
<nav class="span4"> ... </nav>
<article class="span8"> ... </article>
This is surely significantly more semantic and maintainable than the old tabular designs, but the 'span4' and 'span8' are still display-data embedded into our HTML. However, since design can never be truly be decoupled from our data (e.g., nested divs), this is a reasonable price to pay.
That being said, even this coupling can be broken, if you use some more modern CSS features provided by a pre-processed language such as LESS. The same example:
<nav id="secondary-nav"> ... </nav>
<article id="main-content"> ... </article>
Coupled with the following LESS:
#secondary-nav{
.span4;
// More styling (padding, etc) if needed
}
#main-content{
.span8;
}
This creates fully decoupled HTML and Stylesheet, which is ideal, because the HTML is cleaner and more readable, and redesigns can be made with less HTML modification. However this only works if you use LESS or some other CSS pre-processor, because CSS currently does not support mixins (AFAIK).
We already use LESS in my workplace, so I know I'll be pushing towards using this type of solution. I'm a very strong believer in semantic HTML and data-design decoupling. :)
Basically DIVs are DIVs & Table elements are simply table elements. The problem with tables is often just keeping track of all of the columns & the rows because it is ultimately a strict data construct. DIVs are far more flexible & forgiving.
For example, if you wanted to to take the four DIVs with the class that equals "span4" and just change them to a 2 column width, all you would need to do is adjust a wee bit of CSS for the outer class "row" and maybe the class "span4". In fact when doing DIVs like this I would avoid calling individual DIVs "span4" or some other number.
My approach would be to create a parent wrapper DIV that is called "rowspan" and the inner DIVs would have some generic ID like maybe "cell".
<div class="rowspan">
<div class="cell"></div>
<div class="cell"></div>
<div class="cell"></div>
<div class="cell"></div>
</div>
Each "cell" class could have a width of 100 pixels for example, and then the parent "rowspan" could be 400 pixels. That would equate to 4 columns in a row. Want to make it 2 columns? No problem! Just change "rowspan" to be 200 pixels wide. At this point it is all in CSS so it's easy to do without rejiggering page structure in the DOM.
But with tables? Not easy. You would have to basically re-render the table with </tr><tr> tags to create new rows.
Version with table, tr, td depends on browser algorithms - wrapping, dynamic width, margins, centering etc.
Version with div can be more easily tuned by css and scripts.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have been reading around about best practices when doing developing a website. But I am still curious because the answers are found are mostly various, depend on a project's scope and many other considerations.
But just to cut it short, basically I wanted to ask about a proper formatting for 3 main elements in a website.
Header
Main/Body
Footer
How is the structure should be build? Are those three should be wrapped in a container like this:
<div class="wrap">
<div class="header"></div>
<div class="body"></div>
<div class="footer"></div>
</div>
And how is the styling should be done? I saw some people advised to use position:absolute for the CSS, while some others use relative instead. Sorry for the very basic question, but I am really confused about this at this current point of my learning.
The only reason a pseudo-standard like having a lot of wrappers exist is because it has proven useful when creating layouts. Basically it's all there for a reason. If you can design the page you want without having a <div id="mainwrapper"> around it - then you don't need a main wrapper like that. :)
My tip would be to simply start creating a site and try to get it to look like you want using simple elements and CSS styling. If you can't make it work - for example you don't understand how to create a flowing column layout - then just search the web for something like "HTML flow column layout" and go from there.
Edit: "Making it work" usually means not having to result to using tables, a lot of magic numbers and loads of elements to create something simple.
A rule of thumb: Don't cut and paste code/solutions if you don't understand 1) what they do 2) why you need them. It's better to try building it yourself and then, as you work with it, realise why some patterns (clearfix, avoiding tables, floating layouts and so on) are so common. It might not save you time right now, but it definitely will make you a better developer in the long run.
HTML layouts are very subjective and it depends on your requirements / preference as a developer. The two main layouts are static (using absolute positioning etc) and floating (using floated divs for a liquid layout).
This is a good article that covers these principles in more depth
Basically, you should be using block level elements i.e. div tags to structure your page. In cases where you have tabular data tables are perfectly fine, but don't use them for your layout as they're slow to render and can make things difficult when you need full control on your page layout.
Best practice for styling suggests that you use CSS to position and style your elements via class attributes and not inline. This will then allow you to minify your CSS scripts and reduce the overhead of your page. CSS has evolved very well, and there are a lot of selectors available to you to reduce the number of classes in your markup. See CSS selectors at W3C for more information on them.
HTML 5 example. Now a days best Layout width is 960. .content{ width:960px }
<!-- Outer Div -->
<div id="content">
<!-- Inner Content -->
<div id="content-inner">
<!-- header -->
<header>
<div class="header">
<div id="header_wrapper"></div>
</div>
</header>
<!-- body -->
<div id="content-body">
<section></section>
<section></section>
</div>
</div>
<!-- footer -->
<footer>
<div class="footer">
<div id="footer_wrapper"></div>
</div>
</footer>
</div>
When writing HMTL you need to bear in mind readabillity of the markup and the ease with which it can be altered in the future.
Try and bear in mind seperation of concerns. Which parts of your site are related to others in a structural sense and which are not reliant on others. Try and group the reliant elements together (using div's etc.) and keep the unrelated ones apart.
Try and structure your CSS in a similar way, if 2 elements position is reliant on the other, but the other isn't, group the related elements under a single class and then use inheritance to structure the differences. where as the unrelated one should probably be in a separate css class altogether.
Also try and structure your CSS so it can be re-used.
Bit general those points but hopefully it'll help?
There are plenty of sites which offer various SEO friendly layouts and they all provide the css
http://www.searchenginefriendlylayouts.com/
http://www.davidjrush.com/blog/2011/02/seo-friendly-two-column-layout/
http://matthewjamestaylor.com/blog/perfect-3-column.htm
I see this being done on websites (ex: http://www.abookapart.com/):
.left {
float: left;
}
<div class="col two left" />
Is the above good practice? I thought it was generally frowned upon to create classes that describe style. If I wanted the above div to float right at a later date I would have to go into the markup and change left to right. No better then adding a style attribute to the element it would seem.
You're right. Most developers avoid class names like "left" or "blue" for that exact reason. Other than the class name, I don't see anything wrong. I would include that float in the "col" class and then just override it with "right" later on if need be.
I've seen it become useful where multiple people are editors for a single website, and you don't give them all full html access.
By setting up classes of styles that they're allowed to use, you can allow them a certain amount of style control without giving them the power to mess everything up.
It's really down to personal/team choice.
I've always preferred this technique as I favor convention over style, I like my concerns separated and I dislike ambiguity.
if I see a div like this:
<div class="clearfix left bordered">
...
</div>
I like the fact that its intent is clearly emphasized and won't make me have to dive into the CSS file to find out what it means.
But based on your example above, if you did go down the more declarative route:
<div class="importantTextDiv">
...
</div>
On the one hand, you have to investigate the CSS file to determine its properties (or run it and inspect the element in your Firebug equivalent) but should you choose to change it, you don't need to make a source change, or change whats emitted from your server side language.
To me, both situations are a pain, but in my experience, changing a div between float:left and float:right is the kind of thing you'd have got finalised before a final deployment anyway.
My answer ? there's no technical reason to prefer one path over another, choose which one feels more comfortable!
I generally use a manual process:
Look at the page, figure out the semantic elements, and build the HTML
Slice up the images I think I'll need
Start writing CSS
Tweak and repeat different steps as necessary
Got a better approach, or a tool?
I have a fairly natural way of coding. The key is to treat the page like a document or an article. If you think of it like this the following becomes logically clear:
The page title is a top level heading
Whether you make the site title or actual page title the h1 is up to you - personally I'd make About Us the h1 rather than Stack Overflow.
The navigation is a table of contents, and thus an ordered list - you may as well use an ol over a ul.
Section headers are h2, sections within those sections are h3s etc. Stack them up.
Use blockquotes and quotes where possible. Don't just surround it with ".
Don't use b and i. Use strong and em. This is because HTML is structural rather than presentational markup. Strong and emphasis tags should be used where you'd put emphasis on the word.
<label> your form elements.
Use <acronym>s and <abbr>s where possible, but only in the first instance.
The easiest: always, always give your images some alternate text.
There's lots of HTML tags you could use that you probably haven't - address for postal addresses, screen code output. Have a look at HTML Dog for some, it's my favourite reference.
That's just a few pointers, I'm sure I could think of more.
Oh, and if you want a challenge write your XHTML first, then write the CSS. When CSS-ing you aren't allowed to touch the HTML. It's actually harder than you think (but I've found it's made me quicker).
Well, when I build a website I tend to try and forget about the design completely while writing the HTML. I do this so I won't end up with any design-specific markup and so I can focus on the semantic meaning of the elements.
Some pointers how to markup things:
menu - use the UL (unordered list) element, since that's exactly what a menu is. an unordered list of choices. example:
<ul id="menu">
<li id="home">Home</li>
<li id="about">About</li>
</ul>
if you'd like an horizontal menu you could do this:
#menu li {
display: block;
float: left;
}
Logo - use a H1 (heading) element for the logo instead of an image.Example:
<div id="header">
<h1>My website</h1>
</div>
And the CSS (same technique can be applied to the menu above if you would like a menu with graphical items):
#header h1 {
display: block;
text-indent: -9999em;
width: 200px;
height: 100px;
background: transparent url(images/logo.png) no-repeat;
}
IDs and classes - use IDs to identify elements that you only have one instance of. Use class for identifying elements that you got several instances of.
Use a textual browser (for instance, lynx). If it makes sense to navigate in this way, you've done good when it comes to accessibility.
I hope this helps :)
I essentially do the same thing Jon does, but here are a few other ideas:
Use Guides in Photoshop (and lock to them). Figure out all of your dimensions for each box/ region ahead of time.
Collect all of your dimensions and color hex values into an info file (I use a txt file) that you can easily reference. This will reduce your alt-tab tax and selecting colors in Photoshop multiple times.
After all my Guides are in place, I slice out the entire website into my images folder, starting with photos and grouped elements, and ending with the various background tiles/images, should they exist. (Tip: Use ctrl-click on the layer preview to select that layer's content).
Notes on using Photoshop:
Use Guides or the Grid.
Use the Notes feature for any pertinent information
Always use Layer Groups for similar elements. We need to be able to turn entire regions off in one click. Put all 'header' content in one Layer Group.
Always name your layers.
You can put each page template in one PSD file and use nested Layer Groups to organize them. This way we don't have to setup all of our guides and notes for each page template on a site.
No shortcuts :) but everybody works slightly differently.
This tutorial that popped up in my feedreader yesterday shows the process from start to finish and might help people who have never done it before but as you are an old hand it's just about streamlining your own methods.
EDIT:
The listapart link certainly is more automated for 'flat' designs where both imageready and fireworks have had pretty good support from day one and it's got better and more semantic with every release but if you have a more complex design it's the twiddly bits that make the design what it is and these have to be done by hand.
I just thought it was worth pointing out that in addition to the excellent advice you've had so far I'd recommend getting a printed version of the design, using a red pen to mark up all the block elements on the design you think you can spot and sitting down with the designer for half an hour and talking through how they envisioned their design working for the use cases that don't fit the static design.
What happens when more text is put in the navigation?
Is this width fixed or fluid?
Is this content pane to the right fixed height or fluid? If it's fluid why did you put a background on it that can't be repeated?
You have a border extending down the page that breaks two otherwise connected elements. Visually it makes sense, but semantically I not can't just use an li to house both those elements. What do you think is more important?
It'll also help you spot potential problems that you might otherwise not have realised were going to be issues until your elbow deep in css.
Not only does it make your job easier after a few times doing it your designer will get a much stronger sense of what is involved in marking up their work - some designers have real trouble comprehending why something they think looks visually very simple will take a few days of css tweaking to make work.
Some of the designers i know, usually uses Illustrator to make the design elements.
This page shows how to do it a little more automated.
Also, get to know the "Layer Comps" feature. I use this for changing button states.
Create layer comps for normal, hover, and active.
In each of these, set up the effects/color overlays and visible layers which belong with that state.
Save for web: go to a different folder for each state, unless it's easier to rename each slice (otherwise your hover button slices will overwrite your regular slices).