|Perl: the Markov chain saw|
Re: Re (tilly) 3: PerlMonks XHTML+CSS: an implementationby Masem (Monsignor)
|on Feb 26, 2002 at 17:59 UTC||Need Help??|
(Not necessarily replying to tilly, but my comments pick up where he leaves off).
My understanding of what those working with the CSS additions have been saying is that they are simply planning on adding CSS classes and IDs to nearly all tags so each aspect of the page can be customized by the end user. The styles that the user can select on their user settings would basic now just switch between different stylesheets that is added to each delievered page, as opposed to hardcoding the FONT, BGCOLOR and other tags in a template file. Positioning would still be done by TABLE layout as no browser including the 6.0 versions does CSS layout well; this is also the area that NS4 had the most trouble.
Additionally, using <FONT><SPAN>...</SPAN></FONT> (or SMALL, TT, or any other character level tag in place of FONT) would allow CSS definitions to override the FONT settings, but would allow FONT settings to work for those not using CSS or with that specific class undefined.
The biggest problem is that NS4's CSS support, if used, required that all tags be closed including P's, which can be a major problem since these come from the bulk of the posts here. (It's also very touchy on the format of the CSS, but that's not important here).
So implimenting the CSS correctly, using only the class and id attributions for any tag, and specifying the style aspects in the stylesheet only, should make the site usable but otherwise bland for all users if no stylesheet is specified, even if they are using NS4, etc; (since basically there are no class definitions, and therefore, no styles to use). Again, pointing out above, we should still rely on Table layouts to format the page (ugh, but that's another issue altogether). Assuming that we can verify that the site works under those conditions under all browsers, then we can start reworking the styles that we currently render the pages as CSS sheets; there should remain a default style that has none and/or minimialistic CSS that is known to work on all browsers. Additionally, we still have the option of the user supplying their own, overriding, CSS.
I wouldn't expect any problems with the above (using css classes/ids, but no sheet specified), but there might be. If there is a problem with CSS use on any browser, then for the cost of a few additional cycles, it should be possible to implement user-triggered CSS tags that, if a flag is set in the user profile, the tag is otherwise not rendered. EG, using DIV_CSS and SPAN_CSS that either resolve to DIV and SPAN if the user wants CSS, or disappear entirely if not. We may also be able to strip class and id attributes from other tags if this flag is set, such that NO CSS-related tags or attributes are present. Again, the resulting page would be bland but still usable.
I have not looked yet at the CSS offered at the root of this thread to see how it works, but I suspect based on additional comments that it can be improved. I'll try to take a look in the next day or so and see what can be done such that those using older browsers still get a good experience. Of course, if/when the CSS is finallized, I strongly suggest that it's run on a special virtual/second server for about a week or three to make sure that no one has problems, bugs are reported, etc., so that the current version of the PM HTML remains in tact and uninterrupted.
Update: I just took a look at the CSS file, and while it appears to do much of what I suggest, it has a big huge 'error' of using the float: attribute. Sadly, as mentioned, CSS positioning is a horrible horrible mess. Years ago, I tried setting up a site with sidebar tables using float, and whatever trick I used, the table failed in one of the major browsers (IE4 PC or Mac, NS4, etc), typically NS4 getting the buzz. I know it would be great to allow people to float these sections but (X)HTML and CSS is just not made for that yet. We need to stick to the main table layout that we have now for this to work. Possibly we can add another variable to the user settings that allows people to put the nodelet bar on the left, but otherwise, leave the tables as they are.