Page Class Suffix
From Joomla! Documentation
Revision as of 16:01, 16 January 2009 by Dextercowley
Apologies for the following rant, but this sounds like "Page class suffix" would be a good feature to use, where in fact it is not, because if used, it can quickly result in a very big stylesheet mess. It's the worst feature Joomla! (still) offers -- thanks to the obsolete, unintended backward compatibility with a dead browser named "Netscape Navigator 4" and unfortunately carried over from Mambo.
I suspect that the implementation dates back to the old days when web designers still had to fight the buggy implementation of CSS in Netscape's browser, who required repetitive and additional selectors and rules whenever a page was disrupted by things like TABLEs, and at the same time being completely unaware of multiple classnames. This browser is dead for good! but eight years later, it's legacy is still with us in the core templates of Joomla! (I'm going to write a White Paper for 1.6 forum so we can get rid of this, finally.)
No graphical browser released in the last 7-8 years had required such a bad workaround in order to style individual pages. While the idea itself is nice, a proper implementation, facing reality of the 21st century, would apply the value of 'pageclass_sfx' to the BODY element only, and nowhere else.
Nobody with a good understanding of how Cascading Style Sheets really work would ever use this parameter as unfortunately demonstrated in the overrides of Beez and the way it's applied in the core "views". The implementation is so unbelievable utterly wrong, it successfully destroys the cascade and inheritance rules of CSS.
Template Designers and Users should in fact be warned to not use the Page class suffix at all in combination with any view template or override that contains the following statements all over the place:
class="contentpaneopen<?php echo $this->params->get( 'pageclass_sfx' ); ?>"
Read: get rid of the misbehaviour to concatene and thereby create brand new classnames using the best new feature of J! 1.5: template overrides.
Comment on the above: I think that before throwing away the page suffix class feature, we have to find another solution for multi-lingual sites, which use RTL and LTR content in the same site. It is impractical to change style direction on paragraph basis, and it does not influence headings. Page suffix class enables (to limited extent) a RTL suffix, that will make all the content in some pages Right to left, within a Left to right site. Template overriding is not a good solution to the above issue.
- Intersting argument. There's actually another (and better?) way to determine the writing direction in J!1.5 -- at least per article: the content language setting in the parameters. If J! wouldn't limit this to the languages installed but make this a "free" choice, this parameter can be used to determine (by language) whether the page should run RTL or LTR. Like adding the pageclass_sfx, adding the dir attribute nonetheless has to happen inside the templates. Per paragraph and per "word" tagging is still possible and necessary using HTML attributes; i.e. english text in a hebrew article or vice versa. Adding a parameter for RTL/LTR is a no-brainer as is "teaching" the templates to recognise it.
- I'm not against pageclass_sfx in general; I think the way it is (still) implemented in the core templates is plain wrong and counter productive in regards of using Cascading Style Sheets. -- 05:45, 23 July 2008 (EDT)
You get a new CSS class if you use a leading space
I don't know if this changes your thinking or not, but if you enter the parameter with a leading space you get a new CSS class, which makes this much easier to work with. Mark Dexter 21:01, 16 January 2009 (UTC)