Recently, David Hucklesby offered us a problem with fitting list based
navigation to design intentions. His article was titled, "Spreading list
items across total width".
I hate to sound like a doctor, correcting semantic. But what is a total
width? What composite of measurements is used to calculate a total width? If
you are using a "liquid" layout, even that single value for a single
selector like 'body {width:100%;}' says a million different things depending
on layout and what it contains.
David Hucklesby got confused, which seems to be a major theme around
cyber-town these days. He got confused about how to display a desired
design. Let's never mind his particular confusion that carbon copies most
concerns popped into css-d these days. Let's look at resolving why he got
confused in the first place.
Where does our design strategy go when we try and strap our 'black-hole' css
list-navigation style sheet into screen reader, mobile and media. Not the
pretend gimped alternative formats that people mistakenly code with a lame
head statement about style type, while looking the other way. We want, we
need to focus on the real code distributed on real devices read by a
universe full of unique css standards based equipment! How do we setup
rollovers using basic css? That sort of thing. Very basic. People around
here are just not ready for media-rich interaction yet.
Like the mindless majority, David is wasting energy going in a proprietary
direction. Anything squeezing extended (Microsoft calls it enhanced) css
into trial and error compression is black hole coding because it eventually
ties even super-computer assembly into an inability to progress or adapt the
code purpose. Too semantic for you?
It takes some basic learning curve dynamics, but all pixel measurements need
to be replaced with em's. That's simply because pixels are a static
(compressed) unit made to enable display within close-to-standards
environment by software platform engineers. Those engineers weren't black
leather sadists. Think like a font designer, vector layouts. Pixels are for
machines, coders need something more fluid. Em's, on the other hand, are a
call-up of typographic dimension; something any font designer knows is
vector based and therefore very liquid in nature.
Great. So I'm coding in em's, so what's the big deal? Well, now it seems a
no-brainer that any static or quasi static font placement will big-time
throw a wrench in your design wheel: so, make all dimensions %'s.
Finally, if you can adjust your skill-set as far as %'s and em's, you may be
wondering why you ever allowed browser and version compatibility to enter
into your navigation streams. Surely we remember that Apple and Microsoft
display foundations rest on fixed proprietary sizing. UGH! Or rather, (ug).
Body {font-size:100%;} and that problem is solved with M and A still
smiling. Assuming that we've lost all of our pixel fixation on the page.
Now what about that list navigation code? Dump it! WHAT!? That's right! Why
bother with extended css language?
Apart from a garbling war between M and A to show off the best proprietary
fit, there is a much easier and non-confrontational way to code css
navigation. That method replaces OL, UL and DT with DIV.
Lists, as we know them (UL, OL and DT), are page parasites. The extended css
needed to squeeze "lists" into a navigation structure, will knock out older
browsers and seriously deprecate intended design. Examples of selector
parasites typically found in such out-of-control design are as follows.
Pseudo selectors: the basic a:hover/visited/active/link are acceptable, but
focus before and after are all long after 50% of existing browser technology
and 90% of compatibility tests.
Descendent selectors like 'div p', or 'div.p'.
Child selectors like 'div > p'.
Adjacent sibling like 'div + p'.
Attributed selectors like 'body[div=p].
And yes, even grouped selectors like 'div, p' cause almost all of our
viewers headaches.
They can all be displayed on any old machine with properly sequenced code or
code instancing.
To review, when anything like a navigation list refuses to conform to code,
revisit your coding syntax.
http://www.onderhond.com/blog/work/spreading-list-items is a typical code
nightmare. No harm meant to Open Cube, but David's spreading list problem is
sadly typical: geared to proprietary redundancy and upgrade dependent
marketing. People! Given the KNOWN BROWSER CONFLICTS with extended css,
examine a very cubesque segment of David's spreading list css.
ul.issues li {color: .etc (actually, short form proprietary draft code like
'ul issues.li > li' is leaner, two step black hole code; but say no more).
Div's, em's and %'s (without any messy code shortcuts) and the spread
problem never happened. Excepting inconsequential one-pixel, 1% and
left-right variants due to proprietary machine language that makes
absolutely no difference to your website visitor, and that is all an easy
workaround. Conventional lists and tables look great in a few confined
places to present proprietary data (they were never intended to be anything
else). Spatial liquid placement in the div unit is the only true standard
every browser recognizes.
Remember, messes are a great way to draft quick solutions; inside of a
specific design platform or environment, in-house design. Just keep things
in a real perspective. Any liquid layout problem is easily fixed with clean
css, also known as css for the real world. So goodbye float, hello to liquid
tops and margins, relatives and absolutes. Translate that spreading list
mess into non-extended css, basic foundations. Even when you pull down the
layer trip for version 2+ visitors, keep it basic. Double the number of
lines of css, true. But no proprietary gimping.
Then, when you encounter problems, and you'll only find REAL PROBLEMS, bring
them into forum context. Propel a problem, if necessary, right into Bill
Gate's diamond encrusted lap. Be famous (horrible as that thought may become
for you), but stop drooling over draft garbage. Pretending black hole
compression should reach the real world? Ha! WE love the way you fight
reality, David Hucklesby.
As an afterthought, there is a possibility that the final css 3.0
specifications will make it easy to size font shapes vertically and
horizontally. For now we are tweaked into an observance of proportionality
confined to the fonts' axial specifications. Fortunately, our platform
engineers left us line-height and letter-spacing and em font size. And there
are some plain simple 2+ hacks to fit type size like an image object?
Semantically speaking (uh-oh, that doctor just came back), confinement tends
to scare coders into a forest of messy quick fixes. No insult intended. Just
statement of fact. Revisit our navigation layout semantic.
Mark
cssGoat.com
personal note: check-in on Stu Nichol's test of dt script overlays as
proprietary code-hack filter cum tracker environment
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of David Hucklesby
Sent: Wednesday, December 19, 2007 11:11 AM
To: Niels Matthijs; css-d@lists.css-discuss.org
Subject: Re: [css-d] Spreading list items across total width
On Wed, 19 Dec 2007 15:23:24 -0000, Niels Matthijs wrote:
>
> I've been having some problems with a list.
>
> I'm using a list as mark-up for my main navigation, the list has 4 items
and the 4
> items have to be spread evenly across the total width of a container
(4x25%). I'm
> looking for a way to make this work in a liquid/elastic layout.
>
> I've tried many things, sadly I haven't found a solution yet. I documented
the methods
> I have tried here:
> http://www.onderhond.com/blog/work/spreading-list-items
>
[...]
In addition to Thierry's solution for containing floats, I'd also suggest
reducing the 25% to 24.5%. In my experience, Internet Explorer cannot
add, especially where percentages are concerned.
Cordially,
David
--
______________________________________________________________________
css-discuss [EMAIL PROTECTED]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
