comment plugin - html change request

[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

[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

[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

[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

[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

[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

[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

[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.