Talk

Difference between revisions of "Page Class Suffix"

From Joomla! Documentation

Line 53: Line 53:
 
:Will do. I'll try to have something up within a week or two. [[User:KavaXtreme|KavaXtreme]] 19:09, 8 September 2009 (UTC)
 
:Will do. I'll try to have something up within a week or two. [[User:KavaXtreme|KavaXtreme]] 19:09, 8 September 2009 (UTC)
 
::Here it is: [[Using the Page Class Suffix in Template Code]]. [[User:KavaXtreme|KavaXtreme]] 22:49, 19 September 2009 (UTC)
 
::Here it is: [[Using the Page Class Suffix in Template Code]]. [[User:KavaXtreme|KavaXtreme]] 22:49, 19 September 2009 (UTC)
 +
 +
Looks great. Thanks! [[User:Dextercowley|Mark Dexter]] 17:06, 20 September 2009 (UTC)

Revision as of 12:06, 20 September 2009

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. --CirTap (talkcontribs) 05:45, 23 July 2008 (EDT)

You get a new CSS class if you use a leading space[edit]

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)

Cascading Page Classes[edit]

The "suffix" is the outdated aspect of page class suffixes. The modern best practice approach would be to use page classes applied to the body tag, unleashing the cascading aspect of stylesheets. This means both leaner CSS and much greater flexibility in styling ANY element on the page. It also compliments and simplifies template overrides. This approach can already be applied in Joomla 1.5.x by adding the following code to the template's index.php file:

  <?php
  $menus = &JSite::getMenu();
  $menu = $menus->getActive();
  $pageclass = "";
  if (is_object( $menu )) :
     $params = new JParameter( $menu->params );
     $pageclass = $params->get( 'pageclass_sfx' );
  endif; 
  ?>
  <body id="<?php echo $pageclass; ?>">

(credit: Page Class Suffix in template code)

An alternative use of this approach would be to load a stylesheet unique to the page in question:

  <link rel="stylesheet" href="templates/<?php echo $this->template ?>/css/<?php echo $pageclass ?>.css" type="text/css"/>

Could you write a Tips & Techinques article about this?[edit]

This looks very interesting. Do you think you could write a short Tips & Techniques article in the Wiki about this, with an example of how this would work in both of your scenarios? If so, that would be really helpful to a lot of people. Thanks. Mark Dexter 20:48, 7 September 2009 (UTC)

Will do. I'll try to have something up within a week or two. KavaXtreme 19:09, 8 September 2009 (UTC)
Here it is: Using the Page Class Suffix in Template Code. KavaXtreme 22:49, 19 September 2009 (UTC)

Looks great. Thanks! Mark Dexter 17:06, 20 September 2009 (UTC)