Add Body Class to next release
I write to Evan about this, he suggested to post my idea here, so here it is...
It would be nice to include something like wordpress's <body <?php body_class(); ?>> tag.
You know, something that will give each page a defferent body class. It should be included in next version of elgg, since it could help a lot to designers. You know, I could target .blog > .elgg-body or .files > .elgg-body thatway without messing with code. And updates will be easier to do, too.
Feedback and Planning
Discussions about the past, present, and future of Elgg and this community site.
- Paweł Sroka@srokap
Paweł Sroka - 0 likes
- Matt Beckett@Beck24
Matt Beckett - 0 likes
- Paweł Sroka@srokap
Paweł Sroka - 0 likes
- Steve Clay@steve_clay
Steve Clay - 0 likes
You must log in to post replies.Actually I think it's very bad idea. It will cause creating lots of context-bound dead css code that is valid only on narrow set of pages. I think it's better to use elgg_register_css('customized-blog', 'URL_TO_CSS') and than elgg_load_css('customized-blog') on chosen (by elgg_get_context?) pages.
From my experience, reducing big sets of context-dependant css rules becomes nearly impossible on complex sites and serving big css files impact loading performance.
I like very much philosophy of elgg 1.8 CSS of avoiding code that's dependant on context or crosses views boundaries.
I think using elgg_register_*/elgg_load_* functions is really powerfull when it comes to optimization and you can easily combine multiple files together in context-specific packages when it comes to reducing amount of resources.
@srokap - I've used both methods, but I have an issue with the elgg_load_* functions in views when using ajax. Have you done anything with those kind of situations?
Personally I like having the contextual body class anyway. Though it's extremely easy to do in a theme, a designer shouldn't need to expect it in core.
@Matt Beckett: Fellow developper is working on sth like that, but it's 2 layer system much different from typical Elgg install. In general, content pulled via AJAX contains additional info about CSS/JS dependencies that are then processed and dynamically loaded if not already present. It's especially problematic when it comes to JS code.
If we talk about AJAX retrieving bare HTML (assuming core /ajax/ page handler) I would try sth like:
* detect if elgg_is_xhr
* while rendering top view attach piece of code to the output (JS or sth to be postprocessed on cliend side) determining dependencies
* load missing assets dynamically
It should be rather easy for CSS only.
In general building some basic client side JS framework for AJAX content refreshing is a good idea and allow more elegant implementation of passing additional information, which quickly becomes necessary.
See also http://trac.elgg.org/ticket/4830
In general I agree that registering CSS files as needed is better, but the body classes added automatically in WP/Moodle2 can be really helpful in a pinch. I've got plugin code to do both alter the class and set names based on the URL ill try to release soon.