I must recommend this post by Marcus Alexander. He moves the argument against pixel perfection - which I have already talked about in a previous post - forwards.
It is my belief that achieving cross browser pixel perfection across a wide range of different browsers costs a project a disproportionate amount of effort and distracts interface developers from the truly important aspects of a website which should be perfect. I am talking here about minor differences, generally related to the rendering of standard elements - form fields for instance.
We should be aiming for valid markup, high quality well organised CSS and unobtrusive object oriented JavaScript - we should never have JavaScript errors. We should be working towards best practices and we should be implementing web standards wherever possible.
We should be listening to what our clients want and delivering a high quality solution which successfully addresses the problems the client wants solved.
However, we should not be expected to work around every single minor layout issue or to change system defaults. Users understand how their default system controls work, they are inherently usable and accessible. A user also does not care if a bit of a text is a few pixels out.
Lets take an example from another aspect of life - television. Television producers will ensure that their program is executed perfectly with a fantastic script, perfect camera work, flawless sound etc. However, if you are viewing a program being broadcast in wide screen on a non-wide screen television, you will miss part of the picture - the edges are removed to fit onto the television. This is a good example as the producer can decide which part of the picture gets cut off.
I must re-iterate however, that it is vital to produce high quality work which conforms to industry best practices and is accessible to as many users as possible. There is a big difference between accessible to all users and perfect for all users.
As Marcus states, no end user of the website is going to be aware of small differences between browsers - and nor should they be. They will only be unhappy if the website does not operate or is so poorly laid out as to be unusable on their browser of choice.
I am not suggesting that anything will do. I am suggesting quite the opposite. We need to be perfect in most things. But as long as the differences are small, the basic site layout is not compromised and the full website is usable to all, achieving pixel perfection does not produce the returns its cost surely demands.
Showing posts with label CSS reset. Show all posts
Showing posts with label CSS reset. Show all posts
23 April 2008
17 April 2008
CSS reset and pixel perfection
This recent post from Jonathan Snook nicely sums up my feeling on CSS reset files.
I have often argued that CSS reset files will end up causing more problems than they solve. Indeed, I am not convinced they solve a real problem.
The problem seems to be that each browser I support does not apply the same default styling to some elements that I may use in my website.
The solution proposed by CSS reset files is to create a base line set of CSS rules which will on first inspection solve this problem. However, I am not sure I agree that the problem is as stated above.
I believe the problem is that each website I code looks and behaves differently and does not use the same set of default styles as other websites I have developed.
The solution I propose is resetting only the CSS styles I actually need in order to make the website look correct in as few styles as possible. Only then will I be interested in the difference between browsers. I would still use the * reset myself as I find that generally is useful and makes a fairly large difference when designing my CSS. I would not employ any more of a reset than that.
As an example, my website may not use any level 3 headings. In that instance, my CSS code will not try and select any 3rd level headings at all. If later during development I need to use a level 3 heading, I will use the tag and add the relevant CSS code. I have always employed this approach and it has so far never let me down.
For more details on my approach to structuring CSS, I suggest reading this post. Of course ideas change over time, but it is still relevant.
I always believe in code being as lightweight as possible, not purely for speed of download but for ease of maintenance and the retention of my own sanity!
The other point raised by the post I mention above is that of producing cross-browser pixel perfect layouts. This is a topic that probably deserves its own post if not a series of posts, however, I rarely strive for pixel perfection. I just do not believe it is that important any more. I would argue that users are becoming aware that websites will look very slightly different on different platforms. I definitely did not perfectly explain my position in my previous post about browser support so I will clarify it here.
In that post, for level 1 browsers (the only relevant browsers in this discussion) I state:
What I should have said was:
That more fully expresses how I feel about pixel perfection. Sometimes it can be done, sometimes it cannot. We should educate our clients that pixel perfection is not always important.
I have often argued that CSS reset files will end up causing more problems than they solve. Indeed, I am not convinced they solve a real problem.
The problem seems to be that each browser I support does not apply the same default styling to some elements that I may use in my website.
The solution proposed by CSS reset files is to create a base line set of CSS rules which will on first inspection solve this problem. However, I am not sure I agree that the problem is as stated above.
I believe the problem is that each website I code looks and behaves differently and does not use the same set of default styles as other websites I have developed.
The solution I propose is resetting only the CSS styles I actually need in order to make the website look correct in as few styles as possible. Only then will I be interested in the difference between browsers. I would still use the * reset myself as I find that generally is useful and makes a fairly large difference when designing my CSS. I would not employ any more of a reset than that.
As an example, my website may not use any level 3 headings. In that instance, my CSS code will not try and select any 3rd level headings at all. If later during development I need to use a level 3 heading, I will use the tag and add the relevant CSS code. I have always employed this approach and it has so far never let me down.
For more details on my approach to structuring CSS, I suggest reading this post. Of course ideas change over time, but it is still relevant.
I always believe in code being as lightweight as possible, not purely for speed of download but for ease of maintenance and the retention of my own sanity!
The other point raised by the post I mention above is that of producing cross-browser pixel perfect layouts. This is a topic that probably deserves its own post if not a series of posts, however, I rarely strive for pixel perfection. I just do not believe it is that important any more. I would argue that users are becoming aware that websites will look very slightly different on different platforms. I definitely did not perfectly explain my position in my previous post about browser support so I will clarify it here.
In that post, for level 1 browsers (the only relevant browsers in this discussion) I state:
All features of the website are fully functional. All content is available. The web pages will match the designs provided completely. The web pages will look the same across all browsers at this level.
What I should have said was:
All features of the website are fully functional. All content is available. The web pages will match the designs provided completely with the exception of system entities such as form fields and rendered fonts which may cause a layout to differ slightly. The web pages will look the same across all browsers at this level within the constraints of the different rendering methods for each platform.
That more fully expresses how I feel about pixel perfection. Sometimes it can be done, sometimes it cannot. We should educate our clients that pixel perfection is not always important.
18 January 2008
Structured CSS
One of the most challenging aspects of starting a new project is deciding how to structure the CSS. Often, not all the designs are complete, and sometimes very few are done and things are not signed off etc. Therefore it is always important to have a structure which allows for quick and easy changes and even the retrospective coding of a style guide into the CSS.
I am personally not a fan of CSS resets such as Eric Meyer's but I do like to have flexibility and structure in my work.
Whilst I get some arguments from colleagues about my approach, those who work on projects with me have so far not had cause for complaint and have commented that my approach seems to work. The crux of it is that I like to do the majority of the CSS work up-front and do as little as possible as more and more pages are added into the site.
I still subscribe to the global reset:
I then like to set all the defaults from scratch on the core elements: headers, tables, anchors, paragraphs, lists etc.
My other practice which causes discussion is my file structure. There are different ways of organising CSS files and some people like to take the one file approach where everything is put into one massive file. I cannot abide this approach - how can you find anything!? The answer is often that good commenting helps, but I don't think developers are very good at commenting well!
My other issue with the single CSS file is that for every page the user has to download every line of CSS and in a rich website, there can be a lot!
I prefer to separate the basic CSS into the following files:
global.css
All global styles including my mini-reset as above, basic styles for the common tags (lists, tables etc). Styling for global site elements.
typography.css
Basic typography styles - paragraphs, headers and text colouring for different elements. Anchor styles as well including hover styles etc.
forms.css
Basic form styling. I always insist upon forms looking very similar across the website so I can style them once.
navigation.css
All global navigation styles typically including primary and secondary navigation (tertiary if it is applicable), footer styles, any in page tabbed navigation etc
ie.css
Included for all IE versions 7 and lower through conditional comments.
ie6.css
Included for all IE versions 6 and lower through conditional comments.
Each of the above files would be included on every page of the website. I would then create further style sheets by section or template or functional usage depending on the website. I would normally not create a style sheet per page or per module, but I do normally create additional special style sheets for the website home page and for search results if it is different enough.
Within my style sheets I try and implement rules such that each section of CSS is commented eg:
I like to have the styles in a sensible order which is normally the same as the markup order. So styling for elements which are children of or appear after the table with ID Inbox would appear later in the CSS file.
And that's it. No magic, nothing too special, just a structure borne out of experience and specifically the experiencing of managing badly written CSS.
CSS is not easy, but a good approach can at least make it simple.
One special note - consistency of approach to CSS on a project is absolutely key until some decent development tools come along.
I am personally not a fan of CSS resets such as Eric Meyer's but I do like to have flexibility and structure in my work.
Whilst I get some arguments from colleagues about my approach, those who work on projects with me have so far not had cause for complaint and have commented that my approach seems to work. The crux of it is that I like to do the majority of the CSS work up-front and do as little as possible as more and more pages are added into the site.
I still subscribe to the global reset:
* {
margin: 0;
padding: 0;
}
I then like to set all the defaults from scratch on the core elements: headers, tables, anchors, paragraphs, lists etc.
My other practice which causes discussion is my file structure. There are different ways of organising CSS files and some people like to take the one file approach where everything is put into one massive file. I cannot abide this approach - how can you find anything!? The answer is often that good commenting helps, but I don't think developers are very good at commenting well!
My other issue with the single CSS file is that for every page the user has to download every line of CSS and in a rich website, there can be a lot!
I prefer to separate the basic CSS into the following files:
global.css
All global styles including my mini-reset as above, basic styles for the common tags (lists, tables etc). Styling for global site elements.
typography.css
Basic typography styles - paragraphs, headers and text colouring for different elements. Anchor styles as well including hover styles etc.
forms.css
Basic form styling. I always insist upon forms looking very similar across the website so I can style them once.
navigation.css
All global navigation styles typically including primary and secondary navigation (tertiary if it is applicable), footer styles, any in page tabbed navigation etc
ie.css
Included for all IE versions 7 and lower through conditional comments.
ie6.css
Included for all IE versions 6 and lower through conditional comments.
Each of the above files would be included on every page of the website. I would then create further style sheets by section or template or functional usage depending on the website. I would normally not create a style sheet per page or per module, but I do normally create additional special style sheets for the website home page and for search results if it is different enough.
Within my style sheets I try and implement rules such that each section of CSS is commented eg:
/* Inbox styles */
table#Inbox {
....
}
....
I like to have the styles in a sensible order which is normally the same as the markup order. So styling for elements which are children of or appear after the table with ID Inbox would appear later in the CSS file.
And that's it. No magic, nothing too special, just a structure borne out of experience and specifically the experiencing of managing badly written CSS.
CSS is not easy, but a good approach can at least make it simple.
One special note - consistency of approach to CSS on a project is absolutely key until some decent development tools come along.
Subscribe to:
Comments (Atom)
Posts
