I needed somewhere where to store <head> in a more structured way so that modules can modify head easier. Jeff Eaton suggested to put it in $page. I tried to get an idea about what $page is but I'm not sure I got it. eg. block uses _page_alter to fill $page elements. node doesn't. Finally everything is somehow "serialized" in template_preprocess_page But most of the things that end up in the $page (theme.inc template_preprocess_page) arrive there from functions that don't take any parameter eg. drupal_get_breadcrumb(), menu_main_menu(), drupal_add_css() etc... Currently very few things reach $page directly or through _alter_page. I definitively don't like the idea of adding one more global object but I can't see any way to fill $page in the same context in which content is created. $page doesn't look as a global object but still doesn't get passed to modules hook. Let's stick to the initial itch (structured head) and see how things may work. Still you can extend the problem to other page "sections" and you'll have the same hook vs. global problem. Currently anything that need to "modify" head... is actually modifying a global object through drupal_add_html_head. So when I'm preparing a page content, no matter if it is a node or just something pushed to a page I can access head. Now if I plan to use _page_alter... I won't be able to access head content in the same context in which I'm creating the page content. On the other side if I add one more global object, wrapped up in a function with a static variable (that should be declared in core so that everything can access it) as the many already used in template_preprocess_page I can't see the real advantage of having head in $page. I remember I've read something about handlers... by Larry Garfield... Is there any shift in policy about "objects" in Drupal? http://api.drupal.org/api/file/developer/topics/oop.html/7 mainly for a namespace reason at the moment. -- Ivan Sergio Borgonovo http://www.webthatworks.it