Page 1 of 1
comment plugin - html change request
Posted: Sun Feb 05, 2006 9:32 pm
by carl_galloway
Are we able to add a wrapper around the comments in the comment plugin, so that the code looks like this;
Code: Select all
'[b]<div class="plugin_comment_wrap">[/b]<span class="plugin_comment_author">' . $user . '</span>',
' <a class="highlight" href="' . serendipity_archiveURL($row['entry_id'], $row['subject'], 'baseURL', true, array('timestamp' => $row['entrystamp'])) .'#c' . $row['comment_id'] . '" title="' . htmlspecialchars($row['subject']) . '">'
. htmlspecialchars($row['subject'])
. '</a><br />' . "\n"
. '<span class="plugin_comment_date">' . htmlspecialchars(serendipity_strftime($dateformat, $row['stamp'])) . '</span><br />' . "\n"
. '<span class="plugin_comment_body">' . strip_tags($entry['comment'], '<br /><img>') . '</span>'
. '<br /><br /><br />[b]</div>[/b]' . "\n\n"
This change will not affect the handling of comments in themes that don't support the wrapper.
Cheers
Carl
Re: comment plugin - html change request
Posted: Mon Feb 06, 2006 1:30 pm
by garvinhicking
You should not need this, as a generall wrapping element for the sidebars already exist!
Like this:
Code: Select all
.container_serendipity_plugin_comments .serendipitySideBarContent {
// Blar
}
So I'd like to not swamp the code with too many selectors.
Regards,
Garvin
Posted: Mon Feb 06, 2006 5:46 pm
by carl_galloway
Garvin, the wrapper you refer to goes around the whole plugin, not the individual comments, and this is what I want. Basically I want each comment to appear within its own box. Check out
my themes site and look for the contest theme, you'll see what I mean.
This might not be desired by everyone, but we're pushing s9y forward in directions that give it the edge over WP, MT et al, so we need to figure out ways of allowing this kind of fine styling. The pro designers will start hopping onboard and using s9y if we can show them that s9y allows them to show off their talents without having to hack the core code, which you don't want anyway because then upgrades become difficult, and part of the theme design gets taken out of the theme which means that other users won't be able to use the theme the same way as the designer. Personally I think fill s9y with selectors like 'css zen garden' have done on their site, let people create art with s9y, and then go back to the code and finds ways of optimising the php.
Also, isn't it true that smarty automatically creates a php-rich template (cache/templates_c) the first time a page is read, so you should only have to worry about performance once. The smarty website says that smarty has a virtually zero overhead after that first read.
Carl
Posted: Mon Feb 06, 2006 5:49 pm
by garvinhicking
Sorry, I didn'T understand your first posting correctly then.
Now I do, and I'll commit this change of course. It is useful, I agree.
I was also more talking about HTML and transfer size, and Code "leanness"...
Regards,
Garvin
Posted: Mon Feb 06, 2006 6:12 pm
by carl_galloway
my apologies, I also misunderstood what you said. I still think think fill s9y with selectors so designers can pick and choose how to theme things, and maybe we just need to put some standards in place so that ALL html output must conform so that we don't get creeping bloat. Also, I wonder if maybe it might be time to review all the plugins and see whether it is worthwhile merging some of them back into the core code, like for example, the entry paging.
Carl
Posted: Mon Feb 06, 2006 6:18 pm
by carl_galloway
following on from before, if you view the source in your browser of any s9y page, the code doesn't look very nice, and sometimes hard to find things - the problem is all the spacing, tabs, comments, line-breaks etc. Could we think about standards for this as well, or maybe use a script to remove all the whitespace within the code to make the core code smaller? Every space adds an extra character to file size.
Tell me to go away if you don't like this suggestion
Carl
Posted: Mon Feb 06, 2006 7:17 pm
by garvinhicking
Entry paging does cost performance, and since there are people that don'T need or want it, I want to keep the footprint low and don't really want to merge this to the core.
I've just committed the wrapper patch!
The problem of the HTML output spacing is that Smarty tags like {if...} introduce linebreaks with previous code. So you cannot indend Smarty {if} things for good templating code and have a good HTML output. One needs to choose which one is more important, and I think it's better that the smarty .tpl file looks pretty...
We could add many spaces before and after every Smarty {command}, but that would bloat the .tpl file and wouldn't look visually appealing, IMHO.
Stripping whitespace would then reall ylook ugly to those HTML fetischists out there. But a config.inc.php entry with a smarty prefilter would do that to you.
Regards,
Garvin
Posted: Tue Feb 07, 2006 9:26 pm
by judebert
With Smarty post-processing, you could even rip out all the blank lines. You could even write an HTML pretty-printer, but I have no desire to write THAT plugin. Yet.
Styling every possible block will allow all kinds of neat templates. And if you're interested in lightweight markup, we could make a custom template for that, too.