CSS Enhancement
-
Hi @nuprn1,
I made some slight (and probably not too elegant) adjustments to your plugin so that the output numbers were surrounded by their own CSS class (just like in you Community Stats plugin). That way the numbers can be styled independently from the rest of the text.
Here’s some sample output from the modified php file:
http://screencast.com/t/YmMzMTQ1Z
http://screencast.com/t/YzQ2NGYyMDCould I send you my modified php file for inclusion in the next version of your plugin?
-
Gonna jump on the band wagon here as well
Couple of things:
If modifying stuff, adding a few classes is not a bad thing, however what would be, and is more important is to re-factor the markup to render semantic elements; divs and spans are semantically null elements used as aggregaters and as such convey no meaning of their own. Adding a more defined structure would mean that the spans could be used to wrap the data such as numbers and styling would be by decedent selector #stats-item span {}It strikes me that a simpler approach, perhaps?, to the markup rendering might be to remove all the mixed HTML/script in the functions, simply returning the data, in the two blocks – e.g the function bp_member_profile_stats_header_meta() – actually contains all the markup, if you think about this it’s a mixed bag at the moment, the parent block is written then the various functions directly returned within it. From a maintenance point of view not having markup throughout various functions in the file makes sense, creating the markup structure within the one single block far easier to modify, for instance I have a mind to render the data as a DL list but to action that means modifying many functions throughout the file as opposed to simply working on a primary block.
These remarks are not really aimed at this plugin per se but more in general at the issue of separation of markup from scripting where humanly possible.
At further risk of being annoying
but to show by example how I might modify things:
http://pastebin.com/siydMqKUThat is rough and ready and a simple paragraph wrapper for the output – spans are maintained within the functions which while not 100% ideal and be justified to the extent that the plugin knows best exactly what data it’s generating and spans are legitimate used to section specific inline pcdata no one would or should object to the spans being there the important thing would now be the ease at which one can add/change the parent markup.
The absolute ideal? return the data as an array of parts so you could access the ‘[number]‘ the ‘[itemtitle] the ‘[metastuf]‘ then one could decide exactly how that data was rendered.
Sorry Paul for hijacking your post!
You must be logged in to reply to this topic.
