I build websites for a small-ish media company. Unfortunately, around 45-50% of our client base uses IE6, while the other half are pretty much equally split between Firefox and Webkit-based browsers, with a sprinkling of Opera users.
I start every one of my sites with a reset stylesheet similar to Eric Meyer's, with a few modificaions. I've been using the Blueprint CSS "framework" a lot recently, and it's made my life a lot easier, though I am not especially attached to it.
Roughly 60% of my development time is spent making sure the sites I create don't look incredibly different in each browser. I code for Firefox 3 then tweak from there.
Does anyone know of any stylesheets/frameworks out there that attempt to preemptively account for all of those stupid little browser quirks? I know that nothing out there can totally account for all the browser weirdness, but it would be nice to have something a little more solid to start with.
I'm working on creating my own, but it would be nice to have something to start with.
The Yahoo YUI library helps deal with a cross browser rendering issues. Namely, the Reset component (http://developer.yahoo.com/yui/reset/) will revert all browser specific rendering (margin and padding on certain elements for instance), creating a level playing field to start from when designing your site.
Take a look at YAML.
Read and inwardly digest Transcending CSS by Andy Clarke, Molly E. Holzschlag, Aaron Gustafson, and Mark Boulton.
It gives a set of techniques for dealing with those quirks you can deal with, and advice on making web sites accessible to older or less capable browsers, or those using other technologies, such as screen readers.
The fundamental thrust is on making sites that degrade gracefully.
It contains lots of links to resources that deal with these issues.
Dean Edwards' IE7 library copes with some of the Internet Explorer quirks.
Blueprint was one of the early appearances in this space, and is considered to be quite mature.
http://code.google.com/p/blueprintcss/
Here's a huge list of available frameworks:
http://www.cssnolanche.com.br/css-frameworks/
There was a lot of interesting debate in the web dev community about css frameworks at the time. Many were worried this violated some stucture/presentation seperation, and introduced non semantic class names and structure.
Some views:
http://jeffcroft.com/blog/2007/nov/17/whats-not-love-about-css-frameworks/
http://playgroundblues.com/posts/2007/aug/10/blueprints-are-not-final/
http://www.markboulton.co.uk/journal/comments/blueprint_a_css_framework/
http://peter.mapledesign.co.uk/weblog/archives/blueprint-semantics-markup-frameworks
Have you looked at the Yahoo YUI stuff? They have a cross-browser CSS Framework.
Related
I've been using XHTML for about 3 years now, and didn't care much about HTML5 and CSS3 arrival. Several months ago I've stumbled upon HTML5 Boilerplate and I'm starting to get very interested in it right now.
The only thing I can't find yet is drawbacks of using this set of best practices. I know, that the main goal of it to make site look the same on wide variety of browsers, but is there something I should be aware about?
Is there something I should be aware about?
Yes, definitely. It's not a plug-and-play thing. Or at least, it could be like that but it hasn't been conceived for that. And if you use it this way you can't enjoy its best. Boilerplate is very flexible and you have to learn how to customize it. Full stop.
My personal suggestion is to start experimenting with it and study the features it has to offer. Luckily for us it's well documented and you can learn a lot. Not only the boilerplate itself, but also the rules and best practices about HTML5, CSS3, resources loading and related issues/workarounds on performances, browsers quirks and how to fix them, tricks for mobile development, polyfills and conditional loading and a lot of other crazy stuffs. Once you are aware of its possibilities, if you'll find drawbacks you'll be able to customize the base boilerplate.
Start from here, read the docs, follow every link and don't be tempted to take shortcuts. It takes time, but you'll be rewarder very well. If you have troubles ask.
For something more concrete, a drawback I found very quickly (but someone consider this a plus) is that the boilerplate doesn't provide a CSS grid. Not a huge problem, I discovered that adapt.js is easily integrable, so I replaced normalize.css with adapt.js's reset stylesheet and used the grid.
Two things I noticed couple months back is the way javascript gets loaded at the bottom of the body. I'm not a big fan of this if not only it looks dirty. Also I tested the loading myself and didn't notice any better loading of javascript. In fact it ran a couple ms slower on a huge script.
Also the normalize.css I tried couple of times but found myself restyling more paddings and margins than before. Which is normal ofcourse since it's goal is somewhat similar but a different approach. I changed this to Eric Meyer's reset.css just because I'm used to it.
I really like the modernizr script and the way to implement things for x-browser results.
Google Analytics implementation for example.
Another small thing I remember was the placing of the title tag. I changed it to the top position for SEO reasons.
I am learning how to program and my goal is to build a simple functional prototype...I'm at the very beginning.
I am not concerned with the visual design at this stage, other than as it relates to being able to demonstrate the functionality.
My question is: do I need to worry about ironing out cross-browser bugs in the HTML/CSS, or can I do development on a single browser? (Perhaps a better way of asking this is does the back-end programming have any effect on which browser is displaying it).
If you are at the very beginning and only want a functional prototype, do not worry about cross browser HTML/CSS. In fact forget the CSS altogether and focus on printing just standard HTML. Since the visual design will change, focus on the content, styles can always be applied and switched later.
If you need Javascript/AJAX stuff I would recommend using a library like JQuery that has already solved many cross browser problems for you.
The back-end stuff "Perl, PHP, Python, etc" shouldn't care about the browser as it is simply printing text for the browser to render as it will.
The back-end programming will affect the way a given browser displays your page and there might well be two schools of thought on whether you should be picky about the browser compatibility issues.
On the one hand, if you're just finding your feet in web development it might be asking too much to expect to have a standards-perfect, cross-browser site or application every time. It might be better to focus on actually accomplishing a finished result and learning as much syntax and technique as possible.
On the other hand, it might be argued that it's a good idea to get into the habit of adopting good practices now and recognising the sorts of things that are going to give you headaches... probably when you view your page in Internet Explorer. This takes more time to reach a finished product, but it would teach you good habits up-front.
Really it comes down to your own approach and preferences. Do you want to be detail-oriented and turn out a polished result in a longer period of time, or would you prefer to just get to the finish line and identify issues on a case-by-case basis?
Do car prototypes have a working stereo, leather upholstery, chrome rims, dice, and other random stuff which does not demonstrate the functionality of the newly-designed car?
My rule of thumb is that if it takes you more than 10 minutes to make it look acceptable to others (I'm completely fine with a disgusting design when prototyping), you're spending too much time on the aesthetics and less time on the actual clockwork.
What good does a "pretty-looking" site do if it has no functional layout?
This depends on both your audience and on your tooling. If you are trying to support all users on all browsers, then you will certainly need to do testing on those browsers (although actively developing on those browsers may not be necessary), whereas if you only need to support WebKit-based browsers (Chrome, Safari) or WebKit-based browsers and Firefox, that is less testing that you need to do.
It also depends on your tooling. For example, if you are writing directly in HTML and CSS, then you are much more likely to run into browser compatibility issues. However, if you use a tool such as GWT, which can generate browser-specific output automatically, there are fewer such issues to deal with.
Note that you can use Selenium (aka WebDriver), to automatically test your code on multiple different browsers, even if you only actively develop within a single browser environment. That way, you can know if you've broken something, but not have to constantly manually test in multiple browsers.
Recently, I have been battling with: weird table borders/margins, div alignments, positioning problems, and am having a down right nightmare supporting Internet Explorer 6. I know a lot of you like me are forced to support, IE6-IE8, Web-Kit, and Mozilla based browsers.
My questions to you are:
What are the important rules you use before hand, when developing across multiple browsers to save you time?
How do you prevent yourself from writing incompatible tags?
What is the best way to avoid hacking your code?
Where do you find research on browser compatibility, do you use any tools?
Finally, when do you cross the line/where do you draw it?
I usually code against Firefox (or Safari) first. That usually produces the best results across browsers other than IE. I then hit IE8, IE7, then finally IE6.
Know what tags are going to cause you trouble and avoid using them at all costs. It's all about how familiar with each browser's issues.
Don't use hacks. Use IE conditional comments. By using conditional comments, you can load one stylesheet for all other browsers, one for IE8, one for IE7, and yet another for IE6 (if you need that kind of granularity to fix your issues). It will give you nice clean stylesheets with as little hack-i-ness as possible.
LitmusApp
There really aren't lines to cross. If you need compatibility, you need compatibility. You just whiddle down your issues as best as you can one at a time until you have something usable.
I would say to start with standards-compliant code. Always test in a standards-compliant browser first like Firefox, or Safari/Chrome. I prefer Firefox for the addons (such as Firebug, HTTPFox and the Web Development Bar). Then work your way DOWN (and by down, I mean all versions of Internet Explorer).
Try to stay away from temporary fixes per situation or site and generalize your code as much as possible. For example, as Justin Neesner said in his answer, using conditional comments and a general style sheet for IE6 , 7, and 8 will knock out most of your problems with layout and formatting, without using (too many) hacks. You can reuse the IE stylesheets, and just place the site-specific code in it.
Use a testing platform like browsershots, netrenderder or LitmusApp so you can see what your site is doing in as many versions of browsers out there. Studying browser compatibility deeply will make you pull your hair out, but any great resource like quirksmode.org can give you information on the little gnats of incompatibility, so you don't go crazy, and bald.
As far as when do I cross/draw the line, it's 99% Internet Explorer issues, and if it's close enough to looking like FF or Chrome/Safari, I'm done. Almost like art, it's not when you're finished adding, it's when you're done removing the crap you don't want to see; that's when you know it's done.
I say there is not that much you can do except sticking to the basics:
Code standards compliant HTML
Validate early, validate often
For Javascript, use a framework like JQuery, Prototype or Dojo
Pick one "main browser" you optimize for first.
in every project, there will be a number of issues, but if you stick to these points, not too many.
I find it extremely helpful to build 100% W3C valid code. Not because it matters - much of what the W3C validator complains about will not make any difference in real world browsers - but because being able to run a validation, and getting a green light and knowing that all is well on that end is very helpful.
To test multiple IE instances at once, you can use IETester. It's not perfect - conditional comments won't work in it for example - , but mostly usable in everyday development work.
use a doctype like html 4.1 transititional which makes ie6 render in standardsmode. You can also use a reset stylesheet.
Use strictly compliant HTML and CSS markup and do not use browser proprietary extensions to CSS.
IE 6 does not implement CSS correctly beginning with its absolute ignorance of the box model.
IE 8 on the other hand has a test suite to prove they implement every aspect of CSS 2.1 correctly (which no other browser does).
Develop for Firefox as stated above and make a decision about supporting IE 6 & 7 or not. Frankly, I no longer develop separate style sheets for those browsers. They don't have enough market share (at least on my site.)
Given the interest in HTML 5 and the lack of interest in XHTML 2, develop HTML 4.01 Strict and follow these practices: (which are recommended in HTML 4, and required in HTML 5 and XHTML 1.1)
all elements and attribute names must appear in lower case,
all attribute values must be quoted,
non-Empty Elements require a closing tag,
no attribute minimization is allowed,
In Strict mode, all inline elements must be contained in a block element.
Why to learn HTML 4.01 Strict with references.
Also see the CSS 2.1 Test Suite
So I have been running around for a while now, 26 days later I think I am ready to give some feedback to my findings.
Coding:
First of all, I found that column systems seem to cut down the amount of HTML and CSS written. They are also very cross-browser friendly. Although there are many of them, I found that the 960 Grid System works the best for me: http://960.gs
Next up I found that Ruby has a cool extension for CSS called, LESS. This has been ported over to .NET and can be found at: http://www.dotlesscss.com. It is easy to setup, and is very powerful when used right.
Javascript, can be tricky but I found out that avoiding certain selectors and shortcuts in languages like JQuery will not only speed up the performance of your application, but exhibit less awkward behavior.
Testing the browsers:
Here comes the interesting part. Without any software I found that testing my applications against Internet Explorer 6 and Safari at the same actually helped increase the speed of my development. Firebug and Firefox actually cause me to develop around the problems and this is what causes a lot of extra code. When developing simple code against IE6 and Safari I found that going back to Firefox and IE8 is incredibly easier. Most problems I have had were with border widths, which were easy fixes.
The best software solution I found that was accessible to me was Expression Web with Superpreview, if you ever wonder why Microsoft releases a bunch of version of IE, its probably so they can sell you tools like these.
Anyway, that's my 2 cents for right now.
I am a Web developer and in my projects I have noticed that my weakest point is not being good at the front-end design. Relying on other designers can be annoying if they are not able to produce as quickly as I want.
My perspective on HTML/CSS is that it is basically a big hack that amazingly works. There are too many CSS and browser specific bugs/quirks to learn and remember them all without spending extreme amounts of time trying to untangle everything. Is there a fast track route to getting CSS into my brain? I have looked at some CSS books, but to me they really read as long lists of how to render things correctly in IE6 and how to make corners rounded. (Seriously why does it require so many tricks to make a sharp corner round? On any platform but the Web this would be called a major oversight.)
Does there exist something that does the analogous to CSS that jQuery does for JavaScript? Using jQuery you don't need to know JavaScript well to make things that work.
I am not interested in learning why IE6 does things in weird ways because I don't care about supporting it at all. I am more interested in a method of learning how to use CSS to do what I want without spending hours and hours reading obscure blogs.
Pencil and paper to sketch out your ideas (think in boxes, not triangles or hexagons), then just break down all the little parts and learn how to do each one. No problem is too big that it can't be broken down. And, like always, TMTOWTDI!
Find examples and learn from it—at least that's how I started learning. Study the styles used and play around with them. When you find something that does what you like, create a mock-up and play around with it. Then test it for cross-browser compatibility.
If you get frustrated because something works in Firefox and Chrome, but not in IE (this will happen a lot), don't give up. I find cursing Bill Gates' name and all he stands for is a great stress reliever. :-)
A great tool I like to use is Firebug, a plugin for Firefox that allows you to, among a great many other things, edit CSS rules in-browser and see the results as soon as you do it.
I agree that CSS was kind of an afterthought in the web design world, but it's one hell of an invention and makes things so much easier and quicker to develop.
Yes, there are CSS frameworks that are the 'jQuery of CSS'. Some of the more popular ones include 960 and Blueprint. I personally use 960 and have found it takes a lot of the guesswork out of layout.
As others have said CSS is hard to learn by reading. It ends up being one of those things you just need to develop an instinct for through lots of experience (which typically means lots of trial, error, and frustration). It is, as you've highlighted, not an ideal situation, but it is what it is.
Another difficulty is that the methodologies or workflow that is employed can really differ between individuals. Some people do a mock-up in Photoshop first, then produce an exact pixel-by-pixel "rendering" with HTML/CSS. Others use Photoshop, Illustrator, or another tool to simply sketch out and idea, and then re-create it from scratch in HTML/CSS. And still others prefer to start directly with HTML/CSS and just a few thumbnail sketches. Figuring out which of these methods fits you best is anthoer important piece of the puzzle.
It pretty much takes time and practice. But you can save yourself a lot of trouble if you keep your html clean and straightforward. Here are a few rules I can think of that have helped me:
Use DOCTYPE in your html pages, start with transitional since it has the most lax rules, and validate your html. If you keep your page in standards mode rather than quirks mode, you will have significantly fewer problems across the board.
Pick what browsers you will support early on and support them in a logical order. For me, I develop in firefox, then make sure that things are solid on chrome / safari. IE can use a special kind of comment that lets you insert html visible only to IE. Use that to add on stylesheets for IE7, then IE6 to override styles and fix any display issues in those browsers. You should generally start with the best browser first and work your way backward.
Be careful with padding. That is one of the most problematic properties I've dealt with. When you can, opt for using a little sub-container element with a margin in place of padding. It's more markup but margin is handled much better across all browsers.
Absolute-positioned elements inside of relative-positioned elements. This solves a LOT. When you relative position an element, it stays in it's normal flow. When you absolute position elements inside of a parent that is relative, the absolute items work in reference to the location of the parent.
In this case I don't think books will help much. CSS is extremely easy to learn, and extremely difficult to master.
All I can suggest is learn as you go.. You need a lot of experience!
Or, you can drop support for IE7 and especially IE6. If you do that you'll find very very few and very very rare quirks :)
Take some classes in graphic design. No programming language will make you an artist, and artistry is required for good user-interface design.
[or you could find better graphic designers to work with]
Subscribe to css-discuss, play with the common problems and talk with other people about your progress. The wiki is a very useful resource too.
I'm looking for feedback on peoples experiences with developing sites that work across browsers. It seems to me there are at least two obvious ways to approach the task of making your site/webapp work across browser:
Constantly test across all supported browsers every step of the way; or
Pick a browser, get everything working in it as a reference implementation and then make all the other browsers match the reference implementation.
Each approach has an obvious drawback -- the problem with #1 is that you end up doing a lot of unnecessary work -- especially if you are developing a webapp that is going through a lot of iterations/prototyping/spikes etc. You will make a bunch of stuff work across browsers that will subsequently be discarded/removed.
The disadvantage to approach #2 is that while it makes the initial development much quicker and more painful it makes it much harder to figure out where some of the specific errors arose, especially for more complex issues -- whereas if you had been developing for all browsers at once you should catch it right away and know what change(s) introduced the problems.
A somewhat obvious third option would be a hybrid approach, but it seems to me that you would end up losing more by experiencing both of the problems with #1 and #2 than you would gain from the benefits of doing both.
What have you found to be the most effective way(s) to approach this challenge?
I’ve found that if you get too deep into developing a website without looking at other browsers you’ll quickly get to a place that is too much of a headache to debug. I consistently open my web pages in all the browsers I care about.
I strongly suggest you verify all browsers each time you make a large change to the site.
Make it work with all browsers up front. This will mean extra testing during development but will cause you less pain later. I find it's usually easier to diagnose problems if I've just developed the thing, rather than coming back later and trying to figure it out...along with a list of other issues.
It partly depends on whether you know it's going to have to work in all browsers up front. If you do, then you really are better off just making it cross-browser to begin with. You don't need to test that everything is 100% compliant every step of the way, but you should code toward that.
And really, it's not that hard, especially what with JS frameworks like jQuery and Dojo around that take care of the scutwork. If you find yourself continually battling one browser or another, you might want to reconsider your design, as you may have chosen to do things in a way that is inherently more difficult to do when cross-browser compatibility is important.
Well, you do #1, but you do it whilst greating a style guide. A litle bit like this: http://www.sitefromscratch.com/content/html-xhtml-css-testing.
So when designing a new site or design, you create a page containing the desired HTML for all the visual elements that will be used on your site. Ignore style for now, just use the HTML that makes the most sense.
Then you style it. Preferably, your style guide would be all on 1 page so it can be open in each browser you're supporting and all you need to do is hit refresh between changes, (avoid opting for several pages, because it will take you longer to inspect them all).
When you build your site, build from the style guide. If it's not in the style guide, add it and test it there first. If you discover a problem when building the site, (perhaps you didn't consider a particular element when it wrapped, for example), replicate and fix the problem in the style guide.
Here's the killer advantage: A new version of one of your supported browsers is released, what would you prefer to test, your entire site, or the style guide?
So that's the CSS taken care of, now you need to do that all over with your generic JS functions, if any.
I created an interface compatibility layer between the browser and my code - basically, I wrapped certain functionality and made the wrappers determine what javascript/html was needed.
As browsers change, you change this compatibility layer and you can leave the rest of your code alone.
If you have this layer in your architecture, the answer to your question becomes "whenever you want".
If you can get an enterprise lock-in then multiple browser support can become less of an issue, e.g. if your customers are all companies using Internet Explorer then why build the site to look good in Safari or Chrome?
If though you are making something for the general public then there is a hybrid approach I'd use which is that I use one browser to get all the functionality there and working and then test across browsers when I'm in that "pretifying" phase of the project. Initially the key is for it to work, then it has to look good.
I don't think I could see a logic to testing across all browsers as I initially fill out a form or do some other basic functionality as it could be a big productivity drain to test across at least a few browsers, e.g. IE 6 & 7, Firefox 2 and 3, Opera 9.5, Safari, and Chrome if one wants to get all the big boys, and at least a couple O/S as Safari on a Mac can be different than Safari on Windows, which is a lot of tests even for just one or two pages. On the other hand, near the end, this is when I can refactor my CSS and inline styling and make the code better for handing off for someone else to maintain, archive until a service pack project is planned, or keep some documents just in case something has to be done. Also, by waiting to clean things up, I can have more confidence in the final UI parts as these can evolve and change considerably over a short period of time.
I usually start out ensuring that all the HTML and controls that I write/use adhere to the specification.
Tools-->Options-->Text Editor-->HTML-->Validation-->Check Show Errors and choose your Target
This starts me out on a solid base. I functionally test new features in a single browser and then about once/twice a day test the full set of them across all browsers.
Using this approach, CSS and JS are the usual suspects when something isn't right, its rare that it's the actual HTML markup.
If you can do it right the first time. Do it then. It will probably never be right later.
Depends mostly on your experience, which could be applied to any programming activity including this one. If you know in advance what likely pitfalls you're going to have to avoid (eg. in cross-browser development, don't make it hard on yourself by trying to do something that is going to be a hassle in a different browser), then you can probably safely develop everything in one browser and then go in after it's done and tweak things to get it working everywhere.
I usually advise junior developers to keep all browsers open during development and to refresh each browser when making changes, but I myself tend to write everything with Firebug for support and then go back and see how it's doing in IE7 (etc) afterwards. Since I've been doing this for several years, most of the time I can predict what's going to be causing a headache and often immediately know where to look to fix it.
If you are new to Web Design/Development then getting things right in different browsers can be a chore at times.
However, it's really not that hard to get a website working in every major browser and coded towards the W3C standard. In my opinion EVERY designer/developer should do this out of principle, otherwise they are no better than they were in the IE years.
Develop cross-browser code, make sure it validates and never think about designing for one browser again.