Ticket #9300 (closed PLIP: wontfix)
Well formed, valid XHTML
Reported by: | benglynn | Owned by: | benglynn |
---|---|---|---|
Priority: | minor | Milestone: | 4.x |
Component: | Templates/CSS | Version: | |
Keywords: | Cc: | matthewwilkes, plip-advisories@…, grahamperrin@…, keul |
Description
Moving beyond SEO considerations and W3C validation links, Plone 4 should aim to seamlessly slot into modern production environments, and be accessible for users at all administration levels.
Plone’s output should be entirely well formed XML, and valid XHTML. This seems to be the case for an out-of-the-box Plone for an anonymous user, but when logged in, the output becomes badly formed and contains validation errors.
Some examples
- Validating /news produces 4 validation errors because of duplicate id attributes.
- Validating /front-page/edit results in 55 errors, though many of these are caused by Kupu, which injects a unique XML vocabulary without a unique namespace.
- Without Kupu, /front-page/edit has 4 errors. Two of these are validation errors, a missing attribute and an invalid attribute. The other two are caused by bad nesting.
- As custom types are developed, automatically generated forms contain more badly formed errors, such as input elements of type checkbox which are not closed.
Motivation
Well formed XML is important for interoperability with other programs. These may include assistive devices used by an administrator with particular accessibility requirements for example, or any program that needs to parse Plone’s output as XML.
When the XML is also valid, it can be parsed against a DTD with a less error tolerant XML parser. It is then far easier to work with. For example, XSLT transformations behave as the programmer will expect and be familiar with from other environments. This kind of interoperability is increasingly important with modern techniques such as WSGI pipelines.
Implementation
If Kupu is no longer to be the default editor, then there’s no need to undertake the daunting task of changing it.
XHTML validation might be added to automated testing of all the templates and all XHTML generated by Plone.
TinyMCE should ideally progressively enhance compliant XHTML, and inject only valid XHTML into the DOM (this may already be the case, I’m unfamiliar with it in detail). Any user entered content should also be cleaned, if necessary, either on the way in, or when added back into pages.
Risks
I cannot think of any particular risks for this proposal.
Change History
comment:3 in reply to: ↑ 1 Changed 7 years ago by jvloothuis
Replying to limi:
Setting up some sort of automated XML well-formedness testing like we had in the past (and make it part of the nightly test report!) would ensure that this doesn't fall back into disarray once completed — and I'd argue that it's almost as important, and that it should probably be part of this PLIP.
This could be done using a subclass of the testbrowser which would invoke lxml or xmllint (which has better error reporting). There is a RelaxNG schema available for various flavours of XHTML. This could be done in a separate test file to avoid any hard dependencies on these tools or slowing down all tests. I would be willing to help out with this.
comment:6 Changed 7 years ago by erikrose
Clearing Owner field of 4.0 PLIPs so we can use it to mean "implementor". (Many of these owners were automatically assigned from choosing a Component that had a default owner.)
comment:9 Changed 7 years ago by rossp
Does this have an owner? If so, then FWT vote is +1. Otherwise, -1.
comment:11 Changed 7 years ago by davisagli
FWT vote: +1. This really does need automated testing if we want it to happen consistently.
I think the main kupu issue has already been fixed on kupu trunk.
comment:12 Changed 7 years ago by raphael
FWT vote: +1
And don't forget the transformations that generate HTML from plain text, structured text, restructured text, markdown, etc. (you get the idea)
comment:13 Changed 7 years ago by calvinhp
FWT Vote: +1
comment:14 Changed 7 years ago by esteele
Approved by FWT vote.
comment:16 follow-up: ↓ 18 Changed 7 years ago by limi
Just a note to preempt any upcoming confusion here: The new theme for Plone 4 will use HTML5.
We're still using the XML variant (also called XHTML5 informally), so it doesn't really affect this PLIP outside of the fact that the DOCTYPE will be different. We should still be well-formed and go by the same rules as XHTML 1.0 does.
comment:18 in reply to: ↑ 16 Changed 6 years ago by keul
- Cc keul added
Replying to limi:
Just a note to preempt any upcoming confusion here: The new theme for Plone 4 will use HTML5.
We're still using the XML variant (also called XHTML5 informally), so it doesn't really affect this PLIP outside of the fact that the DOCTYPE will be different. We should still be well-formed and go by the same rules as XHTML 1.0 does.
Can this be the right moment for thinking about move Plone to be also XHTML Strict? http://dev.plone.org/plone/ticket/4379
This issue is very old, I'm quite interested in helping for reach this!
comment:19 Changed 6 years ago by limi
Any updates on this? Was there ever a test suite set up to keep our XHTML from regressing? (Hanno said that there was work done on this during the Bristol sprint)
comment:20 Changed 6 years ago by limi
- Component changed from Unknown to Templates/CSS
- Milestone changed from 4.0 to 4.x
comment:21 Changed 6 years ago by ldr
Adding XDV in front of Plone will ensure output is well formed XML. It won't help with the duplicate id issues though. I think those are mostly down to content viewlets using ids, which breaks in listings are multiple content viewlets end up being shown.
comment:22 Changed 5 years ago by rossp
- Status changed from assigned to closed
- Resolution set to wontfix
Superceded by #11300
I'm very much in favor of this, especially now that Deliverance and/or xdv is gaining momentum. There was already some work done on this for Plone 3.3, but there's definitely more that can be done.
Setting up some sort of automated XML well-formedness testing like we had in the past (and make it part of the nightly test report!) would ensure that this doesn't fall back into disarray once completed — and I'd argue that it's almost as important, and that it should probably be part of this PLIP.
Thanks for the proposal! Excited to see some action in this area. :)