<> = Details = Applies to:: moin-1.6 Purpose:: have moin output valid XHTML 1.0 output, as described in [[FeatureRequests/ValidXHTMLOutput]] Description:: Summary of changes: 1. the following elements with EMPTY content model, while properly generated starting from user markup, where generated without the closing tag in some place in the code. They are now correctly generated as empty XML elements (e.g. ). * hr * img * input * link * meta * param 1. the 'disabled' attribute must have a value when outputting xml. Now it is properly generated as 'disabled="disabled"' as required by the XHTML specifications. 1. escaped '&' characters in verbatim javascript snippets and hyperlink endpoints 1. do not rely on browsers for automatically closing

tags generated from wiki markup 1. change DOCTYPE string on sent document to be XHTML 1.0, changed bottom page link label claiming the page is valid XHTML 1.0 '''Note:''' applying this patch will not make Moin output always valid XHTML 1.0, but it will fix a lot of common issues. I (StefanoZacchiroli) am working on testing the whole legacy Moin installation so that all pages in the distribution are output as valid XHTML 1.0, but I'm not there yet. I will keep this patch updated. Help is more than welcome. = Patch = {{attachment:valid_xhtml10_1.patch}} == Comments == * it would have been easier to review if this were split into moin_only_adding_slashes.diff and moin_xhtml.diff. Adding slashes is lots of work, but no big problem (we had patches for this since years). But the other changes needed are more problematic (and this is the reason moin is not xhtml - not the missing slashes). (ThomasWaldmann) * got it, I will split the patch in pieces: slashes, fck, xhtml (e.g. disabled="disabled" attributes) (StefanoZacchiroli) * stuff under wiki/htdocs/applets/FCKeditor needs to be a separate patch (and go to FCKeditor author, too) (ThomasWaldmann) * the

stuff has to get checked thoroughly as it ever breaks when touched. (ThomasWaldmann) * what do you mean? (StefanoZacchiroli) * you changed

handling (auto_closing stuff iirc) (ThomasWaldmann) * yes, I did, and it worked for me. I fail to see how it can be such a fragile piece of code, it just a matter of outputting or not

. But maybe I'm being too naive ... If you have any particolar suggestion about what to test I can do that. (StefanoZacchiroli) * maybe look at mercurial (hg) (ThomasWaldmann) * I'm using mercurial, but on a repository which is available only via ssh. Do you like to have it accessible via http://? Does that substitute or complement making patches available here? (StefanoZacchiroli) * maybe we can use it when merging your stuff. that comment was rather meant for your work being more comfortable to you. if you just have commented, clean changesets (either with trivial stuff ONLY, like the slashes stuff, or with only serious stuff, like the rest for moin, and with some changesets with FCKeditor only stuff, it will be easy to handle) (ThomasWaldmann) * Right now the aspect of mercurial which puzzles me most is that it's hard to get plain patches out of it. I found 'ht export', but if I want to merge several commit to obtain a single patch I have to manually list the changes. Do you know if there is a way to pack several commits in a single one (other than the stupid way I'm using of cloning again from scratch and commit several changesets at once). I will setup a public version of my repo. (StefanoZacchiroli) = TODO = == Known Issues == * Testing is missing. Right now I don't have the time to integrate my patch in the testing framework of Moin (mainly because I don't know its detail). Help is welcome on this subject. (StefanoZacchiroli) * You can safely ignore most stuff that is already there testing html output (most stuff is broken because it is too restrictive). If you can really reach xhtml output, you maybe can use an x(ht)ml parsing framework for the tests. Setting up such a framework did not make sense yet, as we had no x(ht)ml. (ThomasWaldmann) * Table markup may generated non well formed XML, I'll work on that. (StefanoZacchiroli) * Ordered lists (
    ) in XHTML does not have the "start" and "type" attributes. While the latter has a direct mapping to css, the former hasn't. "start" can be emulated using css counters, but that requires re-defining the css rendering of
  1. items from scratch. Is that ok or is better to drop the support for "start" in Moin lists? Regarding "type" is it preferred to change a global moin "css" ot to output "style" attributes on affected list elements? (The latter probably requires also some reworking of some Moin sanitization passes ...) (StefanoZacchiroli) = Discussion = Thanks a lot for your work on this. Especially the more complex things on the todo might be critical as there is no such thing as 99% xhtml. -- ThomasWaldmann <> * I added a (proof of concept) TODO list :-) Regarding 99% xhtml: as a matter of fact it is not possible to achieve 100% xhtml as long as markup permits to output arbitrary HTML. Still, this patch fixes oddities Moin is better without, IMHO of course. Any plan about committing it to the main development branch even if we are 99% xhtml? (StefanoZacchiroli) * What standard wiki markup permits arbitrary html? In case you talk of HTML macro: this is not included in moin and we don't recommend it. So I hope there is no means to insert user defined html in the output. (ThomasWaldmann) * Yep, I was thinking at that. Non issue then. (StefanoZacchiroli) * It is known that some parts of moin just output html fragments (esp. the theme, but also other stuff), but this can be fixed in the code. (ThomasWaldmann) * What do you prefer for that? Invoking the formatter instead of having html hard coded or patch the hard coded html? (I did the latter right now). (StefanoZacchiroli) * About committing to main: it will rather get committed to a testing branch first. We need to test against multiple browsers first and see if they are happy with our output. E.g.: what happens if we claim it is xhtml in the header and there is something in the output (that 1% :) ), that isn't valid xhtml? What does a browser do in that case? (ThomasWaldmann) * I agree on that. Still, I'm not willing to do the test since I only have linux/firefox at hand. Regarding commit I really don't care about commiting to test vs main. I care about having it committed to a place where main development is merged often. Of course I understand if you're not willing to do that. After all that's the dirty work of patch contributors :-) Stay tuned for the split patches ... (StefanoZacchiroli) Please only output CDATA sections if you're outputting application/xhtml+xml ... which I suspect/hope you're not yet, because that requires 100% XHTML. CDATA will break in text/html, even if syntactically it is perfectly XHTML. Otherwise thanks for doing a lot of the tedious gruntwork. -- -- DeronMeranda <> = Plan = * Priority: * Assigned to: * Status: ---- CategoryMoinMoinPatch