I am using a heavily-modified version of box_grey on my site, which is -among other things- completely table-less now. Additionally, I deliver the page as application/xhtm+xml content type, if the browser advertises itself as understanding it (e.g., Firefox, Opera). This has the advantage that popular, annoying markup-errors like unclosed tags etc. are reported directly by the browser's XML parser. Also it's better for popular XHTML extensions like MathML, but will perhaps break things like TinyMCE. The advantages of tableless design should be apparent. My variant should work well with IE6, too.

I suggest making these two changes, anyway. If TinyMCE breaks XHTML compliance, than this module needs to be fixed. box_grey is XHTML compliant, so it should deliver the proper Content-Type. I also volunteer for doing the changes. In fact, if someone is willing to submit it to CVS, I can provide a current, modified version for 4.6 in short time, or a diff.

Comments

adrinux’s picture

adrinux commented
Status: Active » Closed (works as designed)

Serving a site as application/xhtml+xml is a server level descision surely, not one that can be made in a theme? I'm aware of the arguments about the correct mime-type to use for XHTML, although I will admit you forced me to refresh my memory, two good reads on the subject if anyone else is interested:

http://hixie.ch/advocacy/xhtml

http://www.456bereastreet.com/archive/200501/the_perils_of_using_xhtml_p...

And I can only answer thus:
1. XHTML sent with an html mime type works in current web browsers.
2. By working with XHTML now we take a step forward into the XML world, it should be less hard to correct things when we really do want to serve XML.
3. Although we can control the conformance of the theme, and to an extent Drupal and contrib modules, we have no way of ensuring user submitted content is conformant with XML at the moment.

Tables for layout.
Box_grey uses a hybrid table+CSS based layout. A single table is used to contain the central (two or three, depending on settings used) columns. The header is above the table, the footer below. Like you I have several sites based on box_grey that use CSS for layout. I replace the table with divs, empty the stylesheet and start from fresh. But there are a lot of people out there that find using CSS-P hard, and there is a secondary issue of user submitted content, which can often break CSS based layouts. I used the table to layout the columns because it's the best compromise for people with week CSS-P skills, and those that want to allow users free reign to submit content.

I always intended to make a more hardcore all CSS layout theme for contrib too, and I'll probably get around to doing it soon - but there are a lot of box_grey users that want and need the compromise layout.

Marking this issue 'by design'.

Kalessin’s picture

Kalessin commented

About the MIME type: since the theme decides -not to a small extend- what markup is served to the user, I think it should be decided there. If the theme is producing well-formed markup, assuming that all the modules are doing it as well, then we can deliver application/xhtml+xml. So this is not really an issue that has to be decided by Drupal itself, but can very well be decided in the theme. Just my $0.02. And yes, I do know of the problems that serving application/xhtml+xml exclusively produces, therefore I am not doing it. Exclusively, I mean. I rather do something like this:

<?php if (stristr($_SERVER["HTTP_ACCEPT"],"application/xhtml+xml")): ?>
<?xml version="1.0" encoding="UTF-8"?>
<?php drupal_set_header("Content-Type: application/xhtml+xml; charset=utf-8"); ?>
<?php endif; ?>

which sends the XML content type and header to the browser only if it advertised itself as XML capable. So I get the enhanced feedback (on well-formedness etc.) from my Firefox without shutting IE users out.

About table-design:I know that the template uses only this one table. But apart from being semantic nonsense (a table is a table is a table: not a design element), this has strong accessibility issues. The table expects the markup in the "chronologic" order (left-middle-right), whereas it is semantically much more sensible to put the content first and the side bars afterwards. Remember, I am talking about braille and text browser users here. CSS-box positioning does not care (as much) about markup order, so it is much more powerful here. My variant is quite stable and even IE6-compatible, so apparently it can be done without big disadvanteges concerning usability. Therefore I would suggest making a tableless variant at least available as an alternative.

Kalessin’s picture

Kalessin commented

...and yes, I do realise that there are (some) other tableless templates already available. But box_grey has a very nice, clean style and is indeed easy to modify, which are properties that the other templates are not as good at.

adrinux’s picture

adrinux commented

since the theme decides -not to a small extend- what markup is served to the user, I think it should be decided there.
No. The content that is served is a mix of theme, drupal core, module and user submitted content.

sends the XML content type and header to the browser only if it advertised itself as XML capable
I think this approach is interesting from a theme and module development perspective, but I'm not convinced it's a wise thing to do on a live site, particularly a community based site where you may not have full control over user submitted content. You still haven't addressed the issue of malformed user content.

being semantic nonsense
Yes, yes. I'm aware of all of that - as I said I modify box_grey to use CSS-P for layout whenever I use it. But once again, you fail to address the issue of user submitted content breaking CSS based layout. It's fine when you have complete control over the content, but on community sites this becomes a big issue. Are you 100% certain that every site that uses box_grey will have perfect layout if they just switch to a CSS-P version, will all their legacy content look fine?

But box_grey has a very nice, clean style and is indeed easy to modify
Well, yes, that's entirely the point. The table based layout is a part of that. And there are a lot of people out there that can handle css colours, text and borders but flounder when they start dealing with floats and other positioning.

There are two things you can do Kalessin.
1. Submit a patch for box_grey that makes the change to CSS-P and ask people to test it on their sites ( I don't have time myself).
2. Apply for a CVS account and create a new theme project that encorporates your changes, but otherwise duplicates box_grey.

I'm not about to force these changes on hundreds of site admins without proper testing. (And create seperate issues and patches for the mime-type and table-layout suggestions if you do submit patches.)

krlklm’s picture

krlklm commented

Kalessin, would you mind making your modified tableless version of Box_grey available? Is it working with 4.7.x as well? I'm looking for a phpTemplate based, 4.7.x compatible and accessible simple theme that could be the base for my Drupal projects. Thanks in advance.

Kalessin’s picture

Kalessin commented

I have not yet switched to 4.7 on my private site. However, I will soon, and the modifications were not that hard. In the worst case I will repeat my modifications on 4.7 box_grey (sorry for the late response, did not log in for a while).