Make it pass an xhtml validator

[Cyrana]

I'd love to see this done. ;) I'm mainly complaining about the & in url strings instead of the & # codes, but I'm sure there are other things.

[Xenboy]

+1 Standards compliance would be good for everyone.

[Antony]

I think Matt said this would happen in 3.0, and I agree its needed.

[ph_bradley]

as part of a series of search engine optimisations, this would be great. +1!

[serversoftware]

Have to agree with this the next version should validate as xhtml 1.0 transitional

[Fabien]

I agree :)

[cthree]

That has a lot to do with the skin. The code shouldn't be outputting anything directly. I realize that it still does in a few spots but it shouldn't and Matt knows this and has made big strides towards that goal. If IPB can reach the point where all of the output is passed through the template engine then validation becomes a given or at least something that can be made to pass any validation suite.

Few seem to "get" what I'm about to say so feel free to skip it:

- $ipsclass->document extends DOMDocument
- IPB and all modules, components, plugins extend $ipsclass->document adding XML elements and attributes which constitute the fruits of their labors
- Templates for all forms of output are XSL documents
- $ipsclass->document is passed to the browser as XML linked to XSL documents for transformation by the browser
-or-
- $ipsclass->document is passed through libxslt linked to XSL documents for transformation by linxslt or similar and sent to the browser as XHTML, PDF, etc.

Consider the following:

myApp wants to display the list of new posts on www.yourSite.com. In myApp I write some javascript to:

1) do an xhttprequest to www.yourSite.com/index.php?act=Search&code=getnew&xml=1
2) yourSite does nothing special, it just returns the page as requested but doesn't perform any transformations on $ips->document, it just sends it as-is as XML
3) myApp loads the XML from yourSite into a DOM document object and proceeds to iterate the list of new post entries applying an XSLT style sheet that I provide to format such entries ENTIRELY WITHIN THE BROWSER.
4) the server that myApp comes from never sees any of the post data, it simply serves the client side javascript to fetch new posts in XML format from a url and provides the .xsl style sheet and .ccs style sheet files (probably already cached by the browser). If the javascript were in a .js file it too would be cached meaning you could reload the list of new posts with absolutely no data transfer (or bandwidth) whatsoever from the server serving myApp. The browser would grab the new post list directly from the yourSite url and apply the templates itself.
5) yourSite requires no code changes to make this possible at all. The only conditional is the &xml=1 parameter which would apply to any url or page and do nothing except prevent IPB on yourSite.com server from transforming the document and force it to send it as XML instead (regardless of what browser detection or logic might dictate within IPB).
6) yourSite has no template processing overhead at all. It does everything it would normally do except try to make the raw data presentable.
6a) IE6, Mozilla/Gecko and Opera all include XSLT engines so yourSite has the added benefit of passing raw, untransformed data to those browsers along with a style sheet and the template processing burden shifts entirely to the browser FOR ALL IPB PAGES. Since yourSite is passing only the raw data to the browser the transfers are much, much smaller because all of the markup data, inline scripting and comments are removed and cached by the browser
7) for browsers that don't have an XSL transformation engine you can do the transformation on the server for no gain. Since 90% of browsers in use do have XSLT the extra overhead of using libxslt on the server side for the 10% that don't far outweighs the cost of using IPB's template engine for 100% of browsers
8) you can provide different style sheets to different browsers, for example a set of PDA sized style sheets for some browsers, normal for others. Since no extra code is required within IPB to generate PDFs or other output formats other than XHTML IPB gets smaller, had fewer parts and requires less maintenance. IPB no long requires a template engine, that's gone, the server and PHP have one built in. Same benefits, smaller code base, fewer bugs. The module API is implicit and universal. It's DOM, simple as that. Just provide the schema for how the document is laid out.
9) you can transform $ips->document into anything, not just XHTML using additional style sheets. For example PDF, DocBook, Word, etc. Again, no code changes required at all, just use a different set of style sheets to transform the DOM XML data that comes from IPB into whatever output flavor you like.

If this intrigues you even a little then I recommend going to www.w3.org and reading the tutorials and articles on the topic. If not, oh well, move on.

Sorry for hijacking, I thought it was ultimately related to the issue of validation as it applies to templates, output from IPB and the like.

[cajetanus]

Another Vote for validation.

[Luke]

I think there are some browsers that dont accept & in url links, or something like that. Could have sworn there was an issue during the 2.1 development process.

Plus when & does not work in the header command when used.

[bfarber]

& amp; doesn't work in headers, but that is besides the point, as headers are never sent to a validator.

& amp; doesn't typically work in js either if I remember correctly, which is a limitation that is tough to get around. I could be wrong about that, or it could be js parsers in certain browsers only, but I remember running into that problem back when I was modding.

@cthree...I read your post about 2-3 weeks ago and it intrigued me. Since then I've been looking into (somewhat at least, as it wouldn't happen in the immediate future) what would be necessary to implement IPB to output pure XML and use stylesheets to do the formatting. I've seen sites that you can view, it looks like a regular html document, but you view source and it's really an XML document linked to a stylesheet.

It looks just as seamless as HTML, but it's more structured, and less-browser dependent.

Some things have come to mind though that question the practicality of implementing such a system.

1) All modules we offer would have to be rewritten, though this isn't a big deal if IPB itself were to introduce the structure and templating engine anyways

2) All old skins would not be compatible, though this tends to happen with major upgrades anyways

3) Many users aren't going to feel comfortable with editing any XML or XSLT documents. I think this would be a major limitation, as then IPB's skinning capabilities (which many users require of course) while, still present, may not be as easily understood and usable as they are now. I think that most attempts at simplifying the interface to edit these would still result in confusion for many users (most people know what a p and b tag does, but may not feel as comfortable using style='font-weight:bold;' for example).

4) There are still browsers that don't support XML or XSLT fully (and some that don't support it at all probably). I noticed you provided a suggestion to use libxslt. This would work of course, but 90% of our users do not have the ability to install php modules (or even to get them installed by their hosts) so we would not be able to rely on this. We would instead need to provide alternate engines which would actually make the installation bigger (we'd need the XML/XSLT engine and the standard HTML engine present now).

5) PHP's XML libraries only support ISO-8859-1, US-ASCII, and UTF-8 character encoding sets. With 2.1.x's introduction of alternate character sets I've seen all sorts of alternative character sets being used, and the 3 listed above would not work for a lot of our users.


The above bullets are just some notes I've come up with in preliminary research into the feasability of this idea. Passing a validator is of course a good idea for IPB, but I just don't think switching IPB to an XML only format would work for a lot of people. It might work for 70% of the users (more than half by a long shot), but the other 30% should not be forgotten either. :)

[Australia4WD]

Just a passing comment, and not one to say dont get Xhtml validated - but last year I was using another CMS and I spent ages getting it the portal page to pass (note the core program actually was but the mods mucked it up).
Then someone came along and made a post - the title and content had "normal" text in it - but it made it non -compliant.
Also if I remember right you can only make validate it per page - I think I gave up when I looked at trying to get the Forum Index validated (even after I changed a couple of thread titles to see if it could be done.

I am going to take all that back now as I just tried and none of the forum entries appear - so I guess the way IPB does it is differnt to my old software - sorry about that. :blush:

[Matt]

I had come to similar conclusions about having the data passed through a "real" display class to change the mark-up.

As it is, we have three separate areas: Normal Display (HTML), Lo-fi (Stripped HTML) and RSS (XML). It would be nice to have one content generator and a display class for each.

I don't really think XML / XST is the way forward for the reasons Brandon listed (complex editing, patchy server support, MB langauge problems).