Topic: Bug in default templates

PunBB has a minor bug in the default XHTML templates. The 'html' element is missing the required 'xmlns' attribute. The HTML Validator doesn't report on this, because it has some XML limitations, mostly because it validates based on the XHTML 1.0 DTD, which doesn't notice the missing 'xmlns' attribute.

In the upcoming version of the W3C HTML Validator, it will be able to notice the missing 'xmlns' attribute and thus render all existing PunBB installations "invalid". Read more about that here. Thus I would suggest to include the 'xmlns' attribute in the default templates.

I'd also vote for inclusion of the 'xml:lang' and 'lang' attributes, so the used language in the forums is specified (if that information is available somewhere, that is).

Re: Bug in default templates

1.3 seems to include it: … e/main.tpl
The lang attributes don't seem to be there (yet) tho.


Re: Bug in default templates

The lang attributes are part of <!-- pun local --> so are output by header.php. A page output by 1.3 looks like this
<html xmlns="" xml:lang="en" lang="en" dir="ltr">

Re: Bug in default templates

Ah, voila! Excellent! smile

Re: Bug in default templates

Oh, looking at those templates, I see that the PunBB element syntax has moved from <tag> to <!-- tag -->. I'm not sure that's an improvement. An even better and more XML-esque option would be to introduce a namespace in the XML and use elements and attributes in that namespace instead. The main PunBB template would then look like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html xmlns="" xmlns:pun="" pun:attr="local">
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    <pun:fragment id="head" />
    <div pun:attr="page">
      <div id="pun-head" class="a-section a-all">
        <pun:fragment id="skip" />
        <pun:fragment id="title" />
        <pun:fragment id="navlinks" />

      <div id="pun-intro" class="a-section a-all">
        <pun:fragment id="visit" />
        <pun:fragment id="crumbs" />

      <pun:fragment id="announcement" />

      <div class="divider"><hr /></div>

      <pun:fragment id="main" />

      <div class="divider"><hr /></div>

      <pun:fragment id="stats" />

      <div id="pun-foot" class="a-section a-all">
        <pun:fragment id="crumbs" />
        <pun:fragment id="about" />

      <pun:fragment id="debug" />

It's a bit harder to parse for the PunBB parser, but since the templates doesn't change very often, this can be done on a when-changed-basis, so it doesn't have to hurt performance. What it gives is templates that are truly well-formed XML and thus can survive and be used in an XML ecosystem without any problems.

Let me hear what you think and if you've thought about this at all! smile


Re: Bug in default templates

They are not tags so I can't see any advantage in making them look like xml or anything else. Their only function is to provide a unique placeholder for the str_replace function to work on. There is no reason at all why the templates need to be well formed xml, all that matters is that the output page is valid. I could do the templates as follows and still produce a valid page.

**:}do header crap{:**
+++do main stuff+++
&&&&do footer stuff££££

I actually do all my testing serving PunBB as xml via a content negotiation script and I haven't experienced any problems apart from the occassional syntax error due to sloppiness.

The reason for the change in the format is that you don't need to replace unused items e.g. the announcement box or statistics. You can just leave them in place as harmless html comments which saves running str_replace just to get rid of them.

Can you give me an example of why you would need the template itself to be well formed xml as opposed to the page that is produced from the template?

Re: Bug in default templates

Paul, I just posted the example and the idea itself because I found it neat to be able to process and produce PunBB templates in an XML ecosystem, for example with XSLT. I don't have a particular uncatered-for use case up my sleeve at this very instance, so it's hard to argument for this feature's inclusion. If it's hard to implement, then by all means don't. smile