> For the developer, clearly having A) is more important.
My thought too.
>
> I have had the same problem with various sites, and I've abandoned the
> associated accessibilty benefits of B). A "skip to content" link is
> easy enough to implement, and while not solving the problem
> completely, it does mitigate the effects somewhat.
>
> Also, many of my current sites use Javascript in ways that throw away
> other accessibilty issues, forcing different HTML representations
> (layout templates, not resources) for screen-readers anyway.
>
> > The best method for that that I've seen using the jiggery pokery is that
> > used by the Drupal Zen theme, ( technique called "body politic" which I
> > believe comes originally from the positioniseverything site). This works
> > great, but the way you size your columns and middle content is quite
> > confusing to a new user and requires a bunch of interlocking arithmetic
> > on widths between the sidebars and the page and the main content.
>
> I'm a big fan of declaring the main layout dimensions once and only
> once, preferably all in the same section of the file, so I would go
> with A. Adding a "skip to content link" to the main TG template might
> be an acceptable compromise.
I ran a comparison yesterday while doing some drupal work ( The zen
layout for drupal is a really good css framework actually! ) and the
body politic method required changing those numbers in 4 places instead
of one in addition to the funny business of pulling everything past each
other with negative margins. I think maybe the best bet is to go with A,
and have comments or an example of how to convert to B for production if
desired.
Another direction I am thinking of going is to basically leave id's out
of the whole shebang. I want to make sure my work can be integrated
easily into other systems, and of course ids are one-and-only. This
would mean the framework ( such as it is, hardly merits the name
framework ) would only define roles for classes, and you can use id tags
as you see fit.
so say a fixed height header in a fixed width page block with a
container expanding to fill the header would attributes like this:
<div id="page" class="region r_1 fixed-x shrunk-y">
<div id="page-container" class="container">
<!-- Header: a shrunk-x stretched-y region -->
<div id="header" class="region r_1-1 stretched-x fixed-y">
<div id="header-container" class="container">
<div id="header-component" class="component">
<h3>Header container in region, working</h3>
</div>
</div>
</div><!-- end region-1-1 -->
...
But, those id tags would be totally optional. The framework rules would
be working off selectors like so:
/* fixed width column stretching to parent in the y */
.region.fixed-x.stretched-y { }
.region.fixed-x.stretched-y .container { }
And you could specify selectors for your own site specific rules on a
region basis:
.region.r_1-1 { }
or use your ids
#header.region {}
This would preserve the possibility of semantic css style of this kind
of thing:
#header ul li a.menu_item { }
I'm also *very* interested in Deliverance. I'll certainly be trying to
integrate the system with that. I like the idea of a Deliverance/WSGI
based theming app/framework that can be stuck over mixed
TG/Pylons/Plone/Django/Drupal frankensites. So keeping IDs clear may be
important in that regard. I wonder whether I should make the framework
classes use some kind of namespace tag prefix to keep options open? I
guess that could be an optional download or something you run a script
to achieve? Crap, then I need a name! ;-)
Iain
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk?hl=en
-~----------~----~----~----~------~----~------~--~---
