[wp-hackers] XHTML Strict Mode

[Scott Reilly]

On Wednesday 04 August 2004 06:48 am, Jamie Talbot wrote:
>
> Personally, I think this is a better solution, which if coded properly
> wouldn't (shouldn't!) be dangerous.  But it could easily be altered
> later if required, right?
>

It turned out that detecting self-closing tags only involved replacing the 
single-entity tag-checking if() like so:

if($tag != 'br' && $tag != 'img' && $tag != 'hr' && $tag != 'input' && $tag != 
'') {

becomes:

if((substr($regex[2],-1) != '/') && ($tag != '')) {

Now it can detect any single-entity tag.  Of course if we are looking to 
actively recognize valid singe-entity XHTML tags then we'd be more in the 
realm of a validator.


> Had a look at that.  Nifty. :D  Of course, this still causes
> balancetags to be executed every time a post is displayed.  For
> multiple posts on one page, lots of viewers, page refreshes etc, this
> could add up to quite a lot of work.  The post text is unchanging
> until someone edits it, so the rebalancing on each occasion is
> redundant.  I still think a better solution is to call balancetags one
> time at post/edit time and save the output to a custom field.  This
> could easily be achieved using a few filters.  This statically created
> closing tag list could then be incorporated into the content using
> your own get custom field plugin!  What do you think?
>

To be precise, in the solution I proposed, balanceTags() is only called at 
run-time for posts that (a) make use of <!--more-->, (b) only the 'more' text 
is being displayed (i.e. for non-permalink pages), and (c) if the 
use_balanceTags setting is true.

As you note, pre-balancing the pre-'more' text requires separate storage that 
you'd have to update when posts are edited.  Custom fields could be used, but 
there may be issues with the user seeing them in their Custom Fields section, 
and you probably don't want them to edit it, so you might need some sort of 
special system-side custom fields, that can be utilized by WP and plugins and 
are invisible to the user.  Otherwise, you'd need another db field?

I personally don't have much qualms with run-time filtering of text.  There 
are already other functions filtering the_content (wpauto(), convert_chars(), 
and possibly others based on configuration options; not to mention a good 
many plugins).  If pre-'more' balancing gets cached somewhere, then that 
might beg the functionality to cache ALL filtered text after their first 
retrieval.  (But then, I think that's what Matt's Staticize plugin does, 
right?
http://photomatt.net/2004/07/26/staticize-25/ )


-Scott
http://www.coffee2code.com