Mike Kear wrote:
> Thanks Rick, I appreciate your nice comments.
>
> I started with CSS a couple of years ago, and while the learning curve
> for that was pretty steep too, it was a liberating experience too.
> Separating code from look and feel made everything simpler. The
> code is smaller, more straightforward. Downloads faster, easier to
> maintain. No more searching though nested tables looking for the
> cell I'm trying to modify.
>
> A lot of people try to do things that are far too complex to start off
> with. No sense trying to emulate the Sydney Morning Herald site
> (http://www.smh.com.au) on your first go.
>
> One of the tricks of developing a web app with CSS is to do the code
> first. THEN do the styling.
Or let the styling be done by somebody else :)
I prefer to work together with somebody who does the styling. The
best division of work is that at the end of the technical design
phase we have agreed on a format of the XHTML to be generated by
the application. That can look something like:
<body> # 1
<h1> # 1
<div id="menu"> # 1
<a class="menu"></a> # 0-3
<ul> # 1
<li><a></a></li> # 1-7
</ul>
</div>
<div id="content"> # 1
<h3> # 1 |
<h2> # 1 |
<p> # 1 |
<a> # 0-* |
<h4><a> # 1 | # 1-10
</div>
<div id="extension"> # 1
<h3> # 1 |
<p> # 1 |
<a> # 1-* | # 1-3
</div>
<div id="fineprint"> # 1
<img> # 1
<p></p> # 1
<ul> # 1
<li><a></a></li> # 5-7
</ul>
</div>
</body>
So what do we actually specify here? We start with saying there
will be one <body>. Since there is only ever one body, assigning
an ID is silly. Then there must be one <h1>, followed by a <div>
with the ID "menu". In the menu, there may optionally be 3 <a>,
but they must have the class "menu". Then there must be an
unordered list with minimum 1 and maximum 7 elements (the menu).
Then we get on to the div with id "content". It must contain at
least one and at most 10 groups of <h3><h2><p><h4>. Etc. etc.
This is a very simple example, but don't be mistaken: this goes a
long way to specifying the XHTML structure of a site. I think the
structure of a site like Mike's http://afpwebworks.com/ would
only be double this size (in my experience all the additional
stuff for forms, tables etc. is the same for every site anyway
because it is driven from accessibility and standard compliance
requirements that are always the same).
Making such a specification requires a certain level of
abstraction. You really have to think about the semantic function
of elements. For instance, you may have noticed the ID
"fineprint". That is not because it should be in a very small
font size, that is because it is the legal fine print like a
disclaimer, copyright notice, AUP etc. Typically this is placed
in a footer and many people would use the ID "footer" for that,
but footer is just a position, it is not the function. Same goes
for "extension", that would be named "sidebar" by many people if
this were a 2-column layout, but that is just the position, not
the function.
This also means you need to work with a stylist that has that
same level of abstraction, which are not always that easy to
find. But if you get this going, it is indeed truely liberating.
You just have to make sure the XHTML your application outputs
conforms to the specification. Nothing more then that. No more
issues with moving elements one pixel to the left or right in
version Y of browser X, all of that is somebody elses problem.
Jochem
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Message: http://www.houseoffusion.com/lists.cfm/link=i:4:237290
Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4
Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
