I need to do a CSS layout. I need to know the best practices to avoid the pain of the CSS multi-browser compatibility.
What I should use to avoid issues in this regard? Should I use a CSS Framework? If yes which one?
Best Regards,
First, know your audience; this lets you know what browsers your site will be accommodating. Second, make sure you have a good grasp of CSS. Third, get familiar with the concept of "progressive enhancement." Lastly, consult this website: Do websites need to look exactly the same in every browser?
For starters, good clear code, thats styled once, and once only helps LOADS. When i say this, I mean, insure all your CSS is in an external file, and no in page or in line css calls are made.
Second, start with a good body,html statement. Get everything defaulted from the work go, your margins, your padding, font size and family, maybe simple calls, but doing it as this step, will save you countless calls of code later on. Even more so when dealing with large sites with 100's of lines of CSS code.
Lastly, keep your CSS organised, make comments, put them into catagories.
Most cross browser related issues are down to one thing, user error. Style it right, style it once, and you and your users will be happy!
I use HTML5 Boilerplate as a a starting point for css and html.
For a grid-based site, I might also use Fluid 960 GS
I write my code to be standards compliant first, and cross-browser friendly second. Don't kill yourself for the bad browsers.
You can use something like Modernizr to feature Progressive Enhancement. Here are some good reasons to do this
For bad browsers, let's just call it IE, wherever something is breaking, just give it more space, and make sure everything is readable. If you do that, it should look ok, but don't kill yourself trying to make it pixel perfect to the design. You can use that link in point 4 to explain to your client / boss why it isn't the same in every browser, and why that's a good thing, not bad.
If you can do all that, your code will be nicer to write, quicker to run and much closer to being future-proof.
If all else fails, use padding instead of margins whenever you can, and things will be more consistent when viewed in IE. And if you're supporting IE6 try and not use too many transparent png images.
There are some other good suggestions here, but I'll add one: YUI's reset CSS stylesheet. It gets rid of some of the more obvious incompatibility problems, without adding a whole lot of page weight.
QuirksMode.org is an excellent resource for browser compatibility information.
Related
After much reading on the subject, I have decided to use a grid when creating my websites. I understand previously grids had a problem with bloating the HTML with unsemantic content.
Now this problem can apparently be avoided by using a grid such as "The Semantic Grid System". However, up until this point in my learning I have used pure CSS, and I understand I would need to adopt LESS were I to start using this particular grid system.
Is this the case with all others as well? Are there any that avoid cluttering up the markup, that also do not require LESS?
Should I even be bothered about finding one, or should I just go ahead and use LESS anyway? Obviously I am still learning so if LESS is something I should definitely be getting into then I will happily learn it and implement it.
You should be able to implement any of these grid systems in a compiled form without touching any LESS files.
But LESS will make your life a lot easier anyways - so yes you should take a look at it.
in absolute terms, you can't go any more semantic than HTML5 standards. Everything else is relative and depends on you and your use, nobody will give you an award or congrat you because of your subjective approach to semantics. This being said, you can obviously use any grid system with just regular CSS, and you can also use LESS or SASS or OOCSS or whatever, I think you're mixing and confusing everything here.
Bottom line is: try to find an adequate way to work, some kind of process or scaffolding with which you're comfortable and that will be it, there's not a real answer to your question
I have found that setting a very basic style reset or style sheet initialization as I prefer to think of it has caused an unexpected result as certain browser defaults were effected. This (me being stupid) led me on a merry dance until I realised that I had turned off the default by employing the reset.
I am now carefully picking through all the pages identifying any other adverse effects.
I suppose that it very much depends on personal preference whether you use a reset or not and I may of course be over thinking this which is the curse I carry. Nevertheless I would like an opinion on whether this is good practice or a good way of over complicating everything.
If it is good practice is there a particular time when it is appropriate to apply a reset.
Eric Meyer's article reset reasoning made perfect sense to me hence employing a very basic reset. I did not employ the full Eric Meyer reset which of course may well have been my downfall. I am not intending to revisit that at this stage.
However I would like to know going fwd what considered opinion is and whether I should be attempting to apply this in future.
Regards
This absolutely depends on the way you write your webpages and the size of your project. Most pages would be 'meh, okay' without reset, but not perfect or consistent on all browsers.
It's trivial why one might use CSS reset -- the more interesting question why not use it?
If you rely on browser-defined default styles (like, for instance, the way h1, h2, h3, h4, h5, h6 get rendered or how ul bullet-lists behave by default, or default margins/paddings, etc...), then resetting your CSS will probably have you do some extra work. In other words, doing reset will bring back all HTML elements back to almost 'nothing' -- just a bunch of semantic grouping tags...
Which is good.
It's what HTML is supposed to be like, not for styling; but for logical and semantic grouping. Styling your elements from scratch will give you much more control, and will save you some browser-specific tweaks and pain.
Plus, jsFiddle does it, so it must be some good!
as certain browser defaults were effected.
Any other defaults that weren't effected would be a bug, since that's the whole point of a reset css.
The one bad point about a reset stylesheet (assuming it has no bugs in itself), is that you have to think about the style of every element used.
The good point about a reset stylesheet, is that only you have to think about every element used. Not using one is a bit like working with a colleague you don't communicate well - it'll save time when they happen to do things that go well with your work, but whether you are duplicating work or letting some case fall between the gaps and get ignored won't be obvious.
In practice, it depends upon which of the two philosophies suits a project best:
You're happy for a lot of styles to depend upon the browser default and (the plus of this approach) user settings. You only add what CSS is necessary, and let such things as default sizes and fonts depend on the browser.
You strive to have a very precise say on every element.
There are pros and cons to both these approaches, and the pros of the second approach has increased lately, as the mechanism used by browsers for re-sizing text for legibility has changed meaning that more of them resize the whole page rather than just the text (this was a big problem with taking the second approach before - you would either have some settings break your design, or have your design break settings some users depended upon to be able to read it at all).
With the first approach, using a reset sheet smashes through the very philosophy you are taking, ruining everything for you.
With the second approach, using a reset sheet is a good first step to getting going. Any time you find that the reset sheet caused a problem, what you really found was that there was something you should have been doing, that you didn't do, and it highlighted that problem for you. If you accomplish the second approach without a reset sheet, then you've effectively arrived at the same result you would have with it, at least as far as those elements used go.
I've been reading a lot of ways recently of how to avoid having to use Photoshop for things like gradients and shadows on buttons, when you can use CSS3 Box Shadow for such features. Now this is great, but obviously legacy browsers and most IE browsers don't yet implement CSS3 features, so my question is, why save yourself extra work in Photoshop when you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects? Isn't that just extra work?
you can use CSS3 but then HAVE to use Photoshop for other browsers to see the desired effects?
Often you don't really care whether the other browsers see the desired effects. If it's just a subtle background gradient effect, the site's going to work fine and still look reasonable with a flat background in downlevel browsers.
Compatibility was more of a problem when CSS 2 Positioning was at this stage: an unsupported positioning feature could lead to an unusable layout. But for essentially frivolous effects like backgrounds, borders and shadows, it's not critical if the effect goes missing.
There are a few reasons. From a developer/designers perspective, using CSS3 can be more flexible. An image is more or less just a static image. With CSS you can use script or CSS to animate or adjust the styling, and have advanced integration between the various technologies. This allows you to be able to do some things that are not possible or difficult just using images.
The page weight is also lower usually when using CSS, which allows the page to load faster, especially on slow connections or mobile devices. It also reduces HTTP requests (although you can use data uris too) which reduces latency and thus speeds up page loading.
Using CSS is often more maintainable and quicker, as you can adjust say a background colour or a shadow quickly just by changing the CSS, while with images you have to open up photoshop, edit the file, resave, etc. This is fantastic for quick tweaks.
There are also some people (myself included) that are much more comfortable in code than they are using graphics packages. For me it is easier to use CSS, but your milage may vary.
Also from the browser perspective we want to move the web platform forward and increase the capabilities. SVG is an example of another technology that doesn't work across all browser versions yet, but adds a lot of power. Although it may not be possible to deploy sites using certain CSS3 properties or SVG without fallbacks right now (depending on your audience or client) there will be a time in the future when old browsers are dead and what we are adding today works for all users. There was a time when most of CSS2.1 wasn't supported for example, while now you can rely on most of it if you don't need to design for IE6.
There are some parts of CSS3 that you can happily use without fallbacks, if you have a client that doesn't require all browsers to look the same. border-radius is an example, or giving a solid colour fallback to old browsers and applying transparency for newer browsers.
The world is moving forward, you can't ignore it. as long as old browser will show a button and new browser will show a more nice one, you are ok.
Otherwise, we were still be working on VT100... as why using "Windows" if most monitors doesn't support more than 4 color graphics and has 80X22 resolution....
If your bosses accepts the idea of having two versions of looks and feel and a warning. CSS3 is a good idea.
So, you use CSS3 features in your code and forget about the browsers that are not compatible -- they will see the "low-graphics version", you might want to issue a non-intrusive warning (like the one we get as alerts in StackOverflow), saying, "Your browser is not compatible with CSS3. To see this website in high graphics please upgrade your browser. Click the link here to update now."
But, depends on where you work. Big companies with lot of resources may like to stick with Photoshop and smaller once may like a light-weight CSS3 code that degrades silently in non-compatible browser.
Well you can always use ChromeFrame, to impose nice behavior on IE. Assuming that a lot of products will insist for it the near future (yeah we can argue against this), chances are that most IE users will have chromeFrame even before your application would insist for it. Once you take a decision on this, decision on using CSS3 properties or HTML5 elements is - well - hell yeah!!
Marvin
Having asked this question How to reach CSS zen?, I now understand that the issues I have are mostly related to positioning. I've found some articles telling that CSS is not always good enough as a layout system.
http://echochamber.me/viewtopic.php?f=11&t=40154
http://www.flownet.com/ron/css-rant.html
http://blog.workaround.org/2009/03/17/dont-abuse-css-for-page-layout/
Do you as CSS designers limit yourselves upfront to designs that CSS can handle? Should I avoid things that seems perfectly easy are in fact difficult to do with CSS?
Of course you limit yourself. As a designer, you should always think about the medium you're working with. If I were designing a magazine ad, I wouldn't be thinking about animations or video. There are certain rules you must adhere to, and it doesn't make sense to ignore that.
But of course, rules were always meant to be broken.
Why?
If you are "designing", why would you limit yourself based on a the limitation of one technology? When you design your site, you should always try to achieve the most usuable interface for the user.
If you do limit yourself, then you are just asking for the site to not be used, and then what's the point of creating it?
I don't limit myself upfront to any designs that CSS can handle (within reason of course), just figure out your design and there will be someway that you can get it looking right using CSS, but it might involve a lot of hair pulling, especially if IE6 is involved!
When implementing a web design (assuming I've got an image/drawing of what the site will look like) I always follow these steps:
I look at the design and determine what components it has. Examples are navigation areas, headers, content areas, and so on.
I implement (X)HTML that can represent the content areas without really taking the design into account (there are certain things such as content order that I use the design to determine.)
I start making the CSS and images needed for the site to look the same way it did in the original design document. Depending on the complexity of the design, I might come up short of elements to use for styling the page, and may end up adding elements that don't really make sense for the content. I try to avoid it as much as possible, though, and I try to create the elements in a way that isn't obtrusive to the content.
As you can see, I never limit the design to the capabilities of CSS. CSS comes last. Now, depending on the complexity of the design, it might not look exactly like it did in the original design document, but the goal is always to make it as identical as possible, while still maintaining clean HTML so that the design can easily be updated in the future.
Most layouts I find can be done with CSS. There are a very few exceptions (normally to do with verically centering text).
For me the main factor which limits my designs is a reluctance to use huge background images. If an effect can't be done by combining/repeating a few tiny bg images I tend to reject or tweak it. Eg a diagonal gradient on a box with curved corners which could be any height might fall into this category using CSS2.1
Almost every painter limits themselves to paint on canvas, almost every sculptor makes 3D shapes from stone or clay or metal...
But there's also the few who dream new dreams and create new things. Some flop, some shine.
Should you limit yourself based on what CSS can do with layouts? Not completely. I say dream big.
Once you've got your dream design, either figure out how to create it, find a technology other than CSS that can do it, or go start inventing!
You can do absolutely almost anything using CSS 2.1 as far as layout. Its a complete pain in the ass that has no reason to ever exist, but you can do rounded corners (using background images), gradient backgrounds (more background images) and all kinds of other bloated crap you don't need all together and still not completely destroy the semantics of your HTML.
Doing all that garbage and still attempting to be standards compliant reduces usability, because its the designers who need round corners and other frivolous crap and not the users. Usability tests have confirmed this. Sites that are bloated to accommodate presentation and usability at the cost of semantics and efficient fail in usability tests compared to their competition. I work for a website that gets several million visitors a day and I have seen the results of our usability tests.
CSS provides a very good way to create an overall design that easily can be changed by small changes in one CSS file, and instantly applies the design changes to all your pages. Of course there are things that are tricky to do with CSS, and in those cases you might want to do it in other ways, but even if your layout is mainly based on CSS, doesn't mean that you can't do some special parts using other technology! You can mix!
So you don't limit yourself when you go for CSS. You just make use of a powerful technology that can be used in perfect harmony along with others!
My one of web designer friend still making sites with table but he use css very nicely and I also use css nicely but with <div> and i face cross browser problem in layout more than my friend.
and i given some reason to my friend about cons of <table>. read my whole discussion with friend?
I - you site will be problematic with screen reader
My friend - OK, but i never got any call from any client regarding this.
I - you will devote more time to make any changes in layout, if changes comes from client
My friend - I don't think so, but if it is then show me how can i save time with <div>?
I - your sites will not work well with search engine.
My friend - it's not true. I've made many site and no problem with any site or client regarding this
I - layout is old way, non w3c and non standard way.
My friend - what is old and what is new, Who is W3C i don't know, What is standard? Whatever i make works in all browsers, it's enough for me and my client will not pay for standard and W3C guidelines rules
I - Your site will not work in mobile browsers
My friend - No problem for me, my client don't care about mobile phone
I - Your sites are not accessible?
My Friend - What do u mean not accessible? Whatever i make works in all browsers. my any client never asked about accessibility
I - You will not get more work in future, with table?
My friend - OK, no problem when clients will not accept site with table then i will learn about div based layouts in future.
My questions?
Is it still true, to make cross
browser layouts for desktop browsers
using table+css is easier then
div+css?
What is the benefit for developer to
use DIV+CSS layout in place of
<table> layouts if client would not
mind if i use ?
Personally I find it much easier to think about the layout in terms of independent chunks rather than a table where the cells are tightly coupled to each other and dependent on each other. Having used both methods extensively, divs are easier when you've learnt about them.
Tables are a nightmare to maintain, too. If you want to add a column you need to make sure other rows aren't affected. Even with CSS, the HTML for tables is still very bloated and difficult to understand "at a glance" (particularly with nested tables).
I'd be surprised if tables really are a huge problem with screen readers (one would hope the software is smart enough to deal with all types of web pages). However, you should take all reasonable steps to make sure the site is accessibility to all, since it's the law.
Mobile phones can display tables fine. The only problem here is if you want to create a separate mobile stylesheet it's virtually impossible to remove the column format.
Finally for SEO, it makes no difference. SEs say time and again that the validity of code makes no difference.
Laying web pages out with tables is probably a bit more intuitive for most people than CSS.
Depends on the layout though. Deeply nested tables can get pretty hairy. CSS layout options (basically float, at the moment) are a different way of thinking about page layout. I find it easier than tables nowadays, as I’m used to thinking about layouts in terms of CSS floats.
IE has a few float-related bugs. I think they’re the main source of cross-browser issues with CSS layouts.
Using a CSS framework makes creating layouts with DIV's a cinch!
I personally use 960 Grid System, but theres plenty of others out there too.
CSS is more flexible and cleaner. Period. I personlly think that 3 nested divs with meaninglful names is much more readable than 3 table tr td s right? There is a reason it's the new accepted standard. I use tables. But only when displaying tabular data. Once you learn the tricks in CSS you can write super clean div structures that are completely cross browser compatible.
I remeber a time I felt like your friend. It was mainly based out of fear. Don't be afraid. And remember it's us developers that determine the future of code and browsers. Agree with all the other answers on here too. No matter how you do it (from scratch) or grid layouts, you'll be much happier with a tableless layout. And to agree with the above, thinking of the site as blocks helps a TON. Good luck!
As nobody mentioned this: HTML aims for semantic markup. That means, the tags you use have a semantic meaning.
So using table for tabular data is fine and the only way to do it.
But using table for layout contradicts the semantic meaning.
And the relevance of semantic should not be underrated as semantic is what the WWW is striving for now (Semantic Web). I know that Semantic Web and HTML are not necessarily connected, but I guess using HTML the right way can only help.
Creating appealing layouts with divs might be more difficult. This comes with the advantage of greater flexibility.
And as already mentioned, maintainability can be a pain with tables.
I personally try to keep my HTML files as semantically correct as possible, i.e. using the right tags for the right purpose. The look (which a layout belongs to) is a matter of CSS.
Btw. if you are searching for CSS vs tables get a lot nice comparisons (most in favor of CSS).
table layouts results in more html, more html results in more code to write and maintain, and less clarity for dom manipulations via js. the amount of css code will remain almost the same (I'm not talking about 2004 inlinestyle markups, that surely will dramatically reduce the amount of css). and there is always the better seo factor that speaks against table layouts. so it can't be easier if you fully understand css. maybe you need to clarify what browsers do you include in your "cross broswer" statement, since its not even self-evident to support ie6 and ie7 nowadays.