This guide will attempt to take you step by step, through the process of creating a fully functioning CSS layout. I will try my best to explain the concepts behind each step, but a lot of the time other people have already covered these things better than I can. Because of this there will sometimes be links to more information on external sites.
Which sections will require containers (
Now that we've planned out how we are going to make the design a reality, it's time to get get your hands dirty.
The first thing that needs to be added to our basic XHTML shell is our (empty) CSS file.
How will we import our CSS? That decision is guided by our intended browser support. Since we don't want to send any CSS to Netscape 4 or IE mac, we will use the following
CSS neogations
By setting the
Because we don't want to feed IE/mac a style sheet which it cant handle, we include the ‘backslash hack’ to send that browser on its merry way.
Now we are serving our CSS to all intended browsers, while legacy browsers are left with unstyled mark-up.
Those who have read my article on this subject would know that I prefer to keep all IE specific hacks in an external file and reference that file via conditional comments. For this project, however, we will be retaining all IE hacks (valid hacks!) in the main CSS file to keep down the number of server requests per visitor.
Setting the limits
IN Just 1 hour
Making Simple Work of Complex CSS Layouts
What we are going to create
- A flexible layout, one which is happy to contort to the requirements of its contents and surroundings
- Decent browser support (...or support for decent browsers, at least!)
- Graceful degradation in legacy browsers
- Something that will make the bosses and marketing types happy while still allowing even access to all customers — current and potential
The design
Design notes -basic elements
- Simple header/banner with vertically centered text
- Horizontal menu
- 3 columns, with a main column which is 200% the width of the side columns
Rough code map
Mark up Plan containers
divs)?- Header - Two images needed, therefore a container is required as an extra ‘hook’
- Menu - not necessarry, due to ability to style
<ul> - Columns - individual columns are required due potentially varying content on each page. If the left column was a sub-menu, a container may not be necessarry.
- Footer - Multiple elements that need to sit horizontally aligned. A container will help with this.
- Outer Container - IE<6 doesn't support styling of the
<body>, so an outer wrap is needed.
Future code generation
- We need a 'page level' anchor menu for people using assistive technologies (AT’s)
- We want our main content as high in the source order as possible, which is where it starts getting tricky...
Bring on the code
The first thing that needs to be added to our basic XHTML shell is our (empty) CSS file.
How will we import our CSS? That decision is guided by our intended browser support. Since we don't want to send any CSS to Netscape 4 or IE mac, we will use the following
@import method...CSS neogations
<style type="text/css" media="screen,projection">
/* backslash hack hides from IEmac \*/
@import url(default.css);
/* end hack */
</style>
What does that do?
media attribute to screen,projection (note comma seperated list — do not add a space), we are locking out NN4 and also telling Opera to use this style sheet in projection mode (full-screen mode).Because we don't want to feed IE/mac a style sheet which it cant handle, we include the ‘backslash hack’ to send that browser on its merry way.
Now we are serving our CSS to all intended browsers, while legacy browsers are left with unstyled mark-up.
Those who have read my article on this subject would know that I prefer to keep all IE specific hacks in an external file and reference that file via conditional comments. For this project, however, we will be retaining all IE hacks (valid hacks!) in the main CSS file to keep down the number of server requests per visitor.
Setting the limits
I mentioned previously that we will use a wrapperdivto hold our design together, but thisdivalso fills a much more important role &mdash it will control the scaling of the design.In an ideal world, our design would expand and contract to fit within the available screen real-estate while still maintaining a legible line-length regardless of font-size or resolution.
%orem? BOTH!Not at all (well, maybe a little); this utopian goal is achievable — even in IE10(not released)! Part:1 Holding it together : Letting it flow
He's gone mad with power!By combining a percentage width withdiv#outer { width:94%; min-width:40em; max-width:70em; }emmin. and max. widths, we can be assured of the following:
- Our design will fill the available screen space, but will not expand further than
70em, keeping line lengths manageable.- Our design will fit perfectly on an 800x600 res. screen, our minimum requirement for this site.
- Because
emis a relative unit and is controlled by the user, font-size will always take precedance over screen-width for deciding the width of the layout. If a user with a res. of 800x600 increases their font-size to 'xx-large', the design will expand and cause horizontal scroll. Is this a Good Thing™? I believe so.- ...and then there's IE, our backwards friend that we keep inviting to every party. IE doesn't understand
min/max-width, so we will employ a great little scriptto add that functionality. Whilst it is far from best practice to use javascript for layout purposes, the page will still function like any other fluid-width design sans-scriptFurther Post click here:-- Click here
0 comments:
Post a Comment