Head flexibility really needed

[Jick]

Could we come up with a way to be able to give control over the head to the designer of the site.

I need to be able to change or edit the head without having to hack the core files in the library/document/html directory.

The designer should have control over this because not every site needs the same standard tags and not always in the order that joomla decides now.

This will also give the designer the option to loose caption.js and mootools if those aren't needed for a certain site.

I can of course drop the the whole but that will give me problems when 3pd components shoot css or js in the head so that will cause trouble than.

There must be a more flexible way than it is done now and with the overrides it is finally possible to create valid and accessible sites but this static head doesn't fit the new gained power for the designer.

Many thanks up front for the hero that makes this flexible,
Arno

[masterchief]

Arno can you give examples please of what the issues are?  Thanks.

[Jick]

Hi Andrew,

Have a look at this http://webrichtlijnen.overheid.nl/toetsen/status/175/ (hope the link works) this is a test for government sites, all Dutch government sites need to pass this, not all do yet but it's the standard.

That test gave me only 43 points (which is a lot already really because of great markup) with the standard joomla head and now I have 47 points for all pages but one.

What have I done to accomplish that: (I had to hack the core head generating sites)
In joomla/document/html/html.php I have commented out:
//$this->setMetaData('Content-Type', $this->_mime . '; charset=' . $this->_charset , true );

and placed:





right after the in the template index file gave me 8 out of 10 test pages 47points.

In:
In joomla/document/html/renderer/head.php I had to add htmlspecialchars() to line 78
$strHtml .= $tab.' out and loose the fact that components can shoot css and js into the head.

An other good reason for designer control is the yes or no use of cation.js and mootools, if I don't need it I don't want it loaded.

Here is a piece from a html4 strict site:


Articles and news on web standards, accessibility, and usability





You see the missing / at the end of the tags, that would require joomla core file hacking to accomplice that and that shouldn't be needed really.

I hope you understand what I mean, the joomla overides finally make joomla ready for taking sites to the max and make them completely valid xhtml strict like over&over or even html4 strict but that also requires the head to be flexible.

Arno

(I now have 10 out of 10 :-) )

[masterchief]

Ok, lets do this slowly.

& is easy to fix.  That's a bug - put it on the tracker.

In terms of the "points" I'm a bit lost so what does the head look like "now" and what should it look like to address your issues.  Then, do you have an idea of just how we could change the ordering - where would it happen (global config / arguments in the jdoc tag / etc)?

[Jick]

The head shouldn't be fixed but given to the designer just like modules.php

There should be an easy way for the designer to completely put together the head and still have the 3pd adding css and js feature and the other params that come from the config if needed.

It's separation of html from the framework just like the templates/overrides and module renderer html, it belongs to the template and the designer.

I hope you see what I mean let me know if not.

(I just heard mootools needs to be turned of for mobile applications so thats another reason to have the head easy adjustable) - thanks for the tip Joris

Arno

[masterchief]

The head shouldn't be fixed but given to the designer just like modules.php

That's an interesting idea.  Can you look how that could work in theory?

[Jick]

Have a file in templates/html called head.php

Have check for that file before rendering the standard joomla head.

In that head file all vars should be available like charset, baseurl, keywords etc which joomla generates or gets from the config file.

There should also be something like for the js files from 3pd and a for the 3pd css files.

Maybe or for html4 reasons like the missing / and no caps.

Mootools and caption should be hardcoded just like you would add js in the template file so the designer can remove them if he likes.

I think that way you can basically create your own head with whatever tags you like and still have the dynamic add js and css feature and the possibility to change keywords etc in the joomla configuration.

That helpful? If you need more I'll think again.

Arno

[ghazal]

Jick's remarks are very accurate and I fully second his proposals.

[masterchief]

An attempt at a patch would be really helpful

[ghazal]

Just a precision:
What is not  mentionned here is that mootools is mandatory in J!1.5 when it is  allowed to users to publish articles through the front-end.

[Jick]

If you use frontend publishing that is, I have no client that uses that and I never use it myself :-)

Thats why it should be an optional thing and easy to turn off or remove.

I'll see what I can do Andrew but you're the php/Jframework wizard here not moi ;-)

Arno

[ghazal]

If you use frontend publishing that is, I have no client that uses that and I never use it myself :-)

Thats why it should be an optional thing and easy to turn off or remove.

Exactly what i think and meant. I should have been more clear.

But i wanted to explain why mootools is always included in tag through ,
only in com_content though and one or 2 other core com_XXX.
Now,
1- it is true that it should depend on the site's goal, and being able to choose interactivity or not
2- i'd like also to use other libraries (jQuery, Prototype) which have some functionalities better suited for my needs, without having to resort to additional coding to minimize conflicts

[Jick]

We agree just fine :-)

Arno

[AmyStephen]

Please consider Charl's work when thinking about Joomla!'s future with semantic xHTML. He has implemented Microformats where appropriate and cleaned up the xHTML significantly, etc. Semantics are far broader in implication than just these header metadata. Some of the real useful stuff that will make the Firefox 3.0 browser light up are in the body of the document. (Even SEO discussions will change from keyword loading to improved, semantically presented content.)

Charl indicated once v 1.5 rolls out, he will go through his extension and bring it up to current levels, given the core code changes. That extension is where this type of improvement should go. But, you might first want to look and see what he's already done.

Also, bear in mind that the Dublin Core metadata specifications are not a "standard," yet, it just finally became a "draft" and the call for public comment opened two days ago on November 5 and will run for a month. Then, the standards body reconvenes after the holidays, etc.

It would be awesome if this topic got broader involvement with the those interested in the community from many different areas. I, for one, am also interested in semantic web issues since, in the US, universities are intent on accessibility and required to meet high standards or forfeit eligibility for federal funding. I already use much of Charl's overrides and have fixed them, where necessary.

Also, there are many emerging semantic discussions. I think Microformats are a good introduction to this and am thrilled to see it in Charl's work. Beyond that, though, how "deep" and which direction should Joomla! go? Ultimately, we will see data model changes and more XML and web service integration, but which path to take? There is RDF, there is Dublin Core, there is SCORM for LMS, and that can also be integrated into RDF formats, etc., etc.. Plone is WAY out front on this and very vested in Dublin Core. That tends to be more publisher focused than the FOAF Microformat direction. Drupal is also just starting to discuss these topics; several discussions at the DrupalCon in Spain focused on this topic and there are several Drupal groups organized for various topics where the semantics theme is linking these subjects together.

It is very important to watch both the social networks and the mobile market since semantics will be the integration and glue between all of these areas. And, wow, there is not a less stable part of the technology world than what's going on with Facebook, Orkut, OpenSocial, MySpace, and now the Open Handset Alliance. Woo-hoo! I believe the social networking / mobile markets will push the ultimate semantic direction, regardless of what many of the academic boards propose. We are less likely to wind up with a "proper" answer and more likely to wind up with a "well marketed" solution.

Point is, this is BIG and it's going to take serious thought. I believe Charl's work provides the very best start we have and I hope we will all rally behind that work as the beginning of semantics and then begin discussing where that should head once we understand what Charl has provided already. It also should be expected that those of us wanting to head in this direction are and will be hacking the core as we study and try to get our arms around this emerging topic. That early exploring is useful to the discussion and open source is what makes it possible for us to innovate on someone else's work.

In my opinion, this is not the place for a patch, but I am glad to see the issue raised. This could be the beginning of a community discussion on strategy and planning and lots of collaboration for semantics. Sadly, this means time. Certainly not v 1.5. Post v 1.5, we will have Charl's work. On that, I suggest, we build.

Amy

Edit: word choice.

[Jick]

Amy,

Thanks for all your info and of course I agree with all there is to say for better ways to create perfect Joomla sites qua markup etc etc but what you write is an other discussion I would love to be part of.

But:

The point I raised is needed now and shouldn't be taken as far as you write because there is just no time for that, we need a stable 1.5.

The key thing here and just simply that for now, the head belongs to the template and should not be created by joomla without an option for a designer to create his own head without loosing joomla functionality.

The site I created validates all the max 125 checks the Dutch government has set for all government sites and that was only possible by hacking the head core files, the rest I could do by using the template overrides and the module.php file to control the html modules spit out. So the head not being in the hands of a designer is bad for joomla and accessible 1.5 sites.

Please understand what I am saying, I agree with you and certainly am with Carl but the head override option is needed in 1.5 stable.

Arno

[AmyStephen]

Arno -

Have you looked at Charl's work? It is possible he already provided a good solution (or path) for head metadata for you to implement the Dublin Core draft. Charl's code addresses semantics strategically for both the head and body. IMO, his work should form the basis of any advancements in this area - he has already accomplished something; he is well beyond talking about it, he's doing it.

But, this request will necessitate new code for a specific purpose. That will create further delay and already many are expressing real frustration in how long it is taking to release v 1.5 and because of a lack of delivery date offered by the core team. To add a request for new code for a specific type of semantics when there is already a more strategic solution soon coming after v 1.5 goes live makes very little sense to me.

Finally, let's not forget, our hands are not tied. Early adopters of draft standards will hack core code. That's the way it is supposed to happen - it is the basis of innovation in open source, made possible in our case by the GPL.

With respect,
Amy

[Jick]

It's not about implementing Dublin Core Amy it's about joomla generating something that belongs to the designer just like template overrides and modules.php, plain and simple.

As far as I have seen Carl's template and core changes still use the normal include:head and joomla is still generating it automatically.

I give up since you don't seem to understand the direct need for this and the way joomla is doing it now is wrong, we could go on and on about it but you use joomla differently than I do.

Again, I don't disagree with you on any of the semantic stuff and would love to work with Carl on the final solution etc but the head should just be part of the template period.

Arno

[AmyStephen]

Please don't ever give up, Arno. We need you. I thank you for hearing me and I appreciate your leadership in this area, and always.

I love the site you are discussing and blogged it a week ago, or so.

Thanks very much for all you do for us,
Amy

[masterchief]

This may be related:
http://forum.joomla.org/index.php?topic=231105.new#new

Arno, would you like to gather up a few other of the css gurus around here and thrash out all the competing issues for implementation and have a look at a few options for implementation - not "necessarily" the code in JDocument for instance , but looking at the simplest way to get maximum impact.  Yes, I know the framework but I'm very unclear on exactly how to implement "we need this to be easy".  Certainly there's a bug fix or two here, the HTML4 vs XHTML is a valid point and for the rest we will just need to assess how far we go in this round.  Would be good to get at least about five people working on this if you can.

Once you've settled on a final direction give me a ping.

Thanks.

[Jick]

Andrew,

I don't think this is really a css issue but a php framework level issue.

As I see there should be a head object that contains everything joomla generates from params, ini, server etc in a plain format so no html in it, I think most of it is in the document object already.

There should be a new file called head.php in templates/system just like modules.php or the other default but overridable files in there.

That file should build the base head like joomla does now but build like this:

Code: Select all

<meta http-equiv="Content-Type" content="<?php echo $this->_mime; ?>; charset=<?php echo $this->_charset; ?>" />

etc etc

// Dynamic scripts
<?php
foreach ($this->_scripts as $scripturl => $scripttype)
{
?>
<script type="<?php echo $scripttype; ?>" src="<?php echo $scripturl; ?>"></script>
<?php
}
?>
// Dynamic css
<?php
foreach ($this->_styleSheets as $styleurl => $styletype)
{
?>
<link rel="stylesheet" href="<?php echo $styleurl; ?>" type="<?php echo $styletype; ?>" />
<?php
}
?>

etc etc

The standard joomla js files(mootools, caption) should be hardcoded just like the standard joomla css files in the template (system and general css) so they can be easily removed. (system and general css don't validate so I remove them)

That way you can build the head just like joomla builds it now if I'm correct.

The should check for a head.php in the active template html directory before loading the one in the system directory.
If there is one in the active template directory it should take that one and pass the default in system dir.

There I would be able to build my own head just like the one in system but with my own tags and order or whatever while still being able to use the joomla vars if I want them.

What do you think, does that make sense or am I thinking to simple here because this is the way I see it, remove the whole html generating from the framework level and just do that in templates where it belongs.

Arno

[masterchief]

But isn't a "head.php" going to be just as complex as JDocumentRendererHead::fetchHead, or worse if you want to tune the ordering?  I'm struggling to find ways to make it easier for you.  Now, what *could* happen is you can say turn off adding stylesheet references so that you can do that yourself.  If you want to tune order I really need to see what Joomla! does natively, and then the difference between that and the desired result.  I need the picture of what you are aiming for, because I'm just not getting it at the moment and don't understanding why you say Joomla! is doing it all wrong.

Basically that fetchHead method is everything you need to take into account.  If you want 100% control you have to reinvent that.  If you want 100% easy, use .  Remember the template has to honour what the 3PD's are expecting the default head to provide for them.

I can see the sense in doing something like , that's a valid technical issue (it needs to go on the tracker) but I'm not sure about the rest.

As an aside, there is nothing stopping you from putting a module position in the head instead of the jdoc tag. You could roll your own parameters to tune however you want.

[Jick]

Why would head.php be complex?

It's just a html head with some in it and I think two foreach statements for the loading of the 3pd css and js.

So it is just like a normal template index.php plain html with here and there a would make it more complex because there would even be more html or checks in the framework files and you are still limiting the creation of whatever head.

With the default head.php in system people who don't need it don't have to wory about anything because it will render the head just like it does now.
For people who want more the override head.php in mytemplate/html with some php would be a great thing.

Arno

[masterchief]

Ok then.

Here's the code for your head.php file:

Code: Select all

		// get line endings
		$lnEnd = $document->_getLineEnd();
		$tab = $document->_getTab();

		$tagEnd	= ' />';

		$strHtml = '';

		// Generate base tag (need to happen first)
		$base = $document->getBase();
		if(!empty($base)) {
			$strHtml .= $tab.'<base href="'.$document->getBase().'" />'.$lnEnd;
		}

		// Generate META tags (needs to happen as early as possible in the head)
		foreach ($document->_metaTags as $type => $tag)
		{
			foreach ($tag as $name => $content)
			{
				if ($type == 'http-equiv') {
					$strHtml .= $tab.'<meta http-equiv="'.$name.'" content="'.$content.'"'.$tagEnd.$lnEnd;
				} elseif ($type == 'standard') {
					$strHtml .= $tab.'<meta name="'.$name.'" content="'.$content.'"'.$tagEnd.$lnEnd;
				}
			}
		}

		$strHtml .= $tab.'<meta name="description" content="'.$document->getDescription().'" />'.$lnEnd;
		$strHtml .= $tab.'<meta name="generator" content="'.$document->getGenerator().'" />'.$lnEnd;

		$strHtml .= $tab.'<title>'.htmlspecialchars($document->getTitle()).'</title>'.$lnEnd;

		// Generate link declarations
		foreach ($document->_links as $link) {
			$strHtml .= $tab.$link.$tagEnd.$lnEnd;
		}

		// Generate stylesheet links
		foreach ($document->_styleSheets as $strSrc => $strAttr )
		{
			$strHtml .= $tab . '<link rel="stylesheet" href="'.$strSrc.'" type="'.$strAttr['mime'].'"';
			if (!is_null($strAttr['media'])){
				$strHtml .= ' media="'.$strAttr['media'].'" ';
			}

			$strHtml .= JArrayHelper::toString($strAttr['attribs']);

			$strHtml .= $tagEnd.$lnEnd;
		}

		// Generate stylesheet declarations
		foreach ($document->_style as $type => $content)
		{
			$strHtml .= $tab.'<style type="'.$type.'">'.$lnEnd;

			// This is for full XHTML support.
			if ($document->_mime == 'text/html' ) {
				$strHtml .= $tab.$tab.'<!--'.$lnEnd;
			} else {
				$strHtml .= $tab.$tab.'<![CDATA['.$lnEnd;
			}

			$strHtml .= $content . $lnEnd;

			// See above note
			if ($document->_mime == 'text/html' ) {
				$strHtml .= $tab.$tab.'-->'.$lnEnd;
			} else {
				$strHtml .= $tab.$tab.']]>'.$lnEnd;
			}
			$strHtml .= $tab.'</style>'.$lnEnd;
		}

		// Generate script file links
		foreach ($document->_scripts as $strSrc => $strType) {
			$strHtml .= $tab.'<script type="'.$strType.'" src="'.$strSrc.'"></script>'.$lnEnd;
		}

		// Generate script declarations
		foreach ($document->_script as $type => $content)
		{
			$strHtml .= $tab.'<script type="'.$type.'">'.$lnEnd;

			// This is for full XHTML support.
			if ($document->_mime != 'text/html' ) {
				$strHtml .= $tab.$tab.'<![CDATA['.$lnEnd;
			}

			$strHtml .= $content.$lnEnd;

			// See above note
			if ($document->_mime != 'text/html' ) {
				$strHtml .= $tab.$tab.'// ]]>'.$lnEnd;
			}
			$strHtml .= $tab.'</script>'.$lnEnd;
		}

		foreach($document->_custom as $custom) {
			$strHtml .= $tab.$custom.$lnEnd;
		}

		echo $strHtml;

You can simplify it if you want, putting in echo's as you go, but that's everything you have to take into account.

Then replace with



But if that's not what you want then again I ask: show me the output you get now compared with the output you want.

[Jick]

Here is a simple example of the head.php file that should go in system/templates and would also be the base for the override.

Code: Select all

<meta http-equiv="<?php echo $this->variable; ?>" content="<?php echo $this->variable; ?>; charset=<?php echo $this->variable; ?>" />
<meta name="robots" content="<?php echo $this->variable; ?>" />
<meta name="keywords" content="<?php echo $this->variable; ?>" />
<meta name="description" content="<?php echo $this->variable; ?>" />
<meta name="generator" content="<?php echo $this->variable; ?>" />
<title><?php echo $this->variable; ?></title>
<link href="<?php echo $this->variable; ?>" rel="alternate" type="application/rss+xml" title="RSS 2.0" />
<link href="<?php echo $this->variable; ?>" rel="alternate" type="application/atom+xml" title="Atom 1.0" />
<link href="<?php echo $this->baseurl ?>/templates/<?php echo $this->template ?>/favicon.ico" rel="shortcut icon" type="image/x-icon" />
<script type="text/javascript" src="<?php echo $this->baseurl ?>/templates/media/system/js/mootools.js"></script>
<script type="text/javascript" src="<?php echo $this->baseurl ?>/templates/media/system/js/caption.js"></script>
// 3pd scripts
<?php
foreach ($this->_scripts as $scripturl => $scripttype)
{
?>
<script type="<?php echo $scripttype; ?>" src="<?php echo $scripturl; ?>"></script>
<?php
}
?>
// 3pd css
<?php
foreach ($this->_styleSheets as $styleurl => $styletype)
{
?>
<link rel="stylesheet" href="<?php echo $styleurl; ?>" type="<?php echo $styletype; ?>" />
<?php
}
?>

Hope that makes it more clear.

It removes the html from the framework level and gives all power to the designer.

Arno

[masterchief]

That won't work.  It doesn't take enough into account for 3pd's or the system in general.  See the code I posted before.  That's everything you have to take into account.

[Jick]

Well it was a simple version so there will probably need to be some if and else in the file but with that it will still be better to have it on a template system/override level.

The designers that would use this are advanced enough to use php and html just like in templates or component template overrides.

I don't know anything else than that the head is such an important part of the template and should be manageable by the designer.

Could you move the framework head renderer to the templates system dir and make it possible to copy that to the mytemplate/html folder which if exists would be used over the one in systems?

Arno

[masterchief]

I just showed you how.

[Jick]

Ok, I'll do it myself, no important change on core level than :-)

Thanks for thinking with me anyway Andrew.

Arno

[tcp]

Moving to J1.5 Templates board as this topic is about customizations to templates.

tcp

[Jenny]

It isn't about customization of templates.  It is about head information/meta being forced to be one way.  This is hard coded into Joomla!.  It isn't about templating.

Once this moves out of hard code it would then be a templating issue.  Please move this back from where it came.  It was a legitimate wishlist item.