Problem/Motivation
Ran across this while working on the Attribute system code - I wrote the code to output Boolean attributes in accordance to HTML5 standards. However the testing system uses XPath for validation, and Boolean attributes are one area where XHTML and HTML have never matched. I set the code to output this:
<option selected value="some value">Label</option>
But Xpath, as an XHTML validator, is looking for
<option selected="selected" value="some value">Label</option>
When I adjusted my code it passed all tests, and this close to 8.0 roll out its not remotely worth it to resolve this or any other XHTML vs. HTML validation issue - but long term if the codebase is to output valid HTML (not XHTML) code a parser other than XPath will have to be chosen.
Marked as 8.0.x dev since that's where the bug was observed, but realistically 8.1.x is the earliest it can be fixed.
Attached is the prior patch from template assertions which is outputting valid HTML 5 code in the manner that the tester fails because it isn't valid XHTML
Steps to reproduce
Proposed resolution
TBA
Remaining tasks
Search for an existing Meta issue and if one does not exist, create one.
Make this a child of the meta
Address #19.
User interface changes
API changes
Data model changes
Release notes snippet
| Comment | File | Size | Author |
|---|---|---|---|
| do-not-test-2444003-21.diff | 70.62 KB | Aki Tendo |
Comments
Comment #1
mgiffordNot sure what this is postponed on for 8.0. Maybe it can be dealt with in 8.1 though.
Comment #2
Aki Tendo commentedI wrote this particular issue while I was still getting my feet wet as it where. I've since seen it rear it's head a couple times forcing tests to use regex to validate. So it's a real problem, but agreed - it's not something solvable in the 8.0.x window.
Comment #3
mgifford@Aki Tendo can you give me some steps to repeat it? It may not be a big change if we can track down where the bug is occurring and what we need to change.
Comment #4
Aki Tendo commentedThe problem is Xpath itself. It' an XML validator, which means the HTML it tests must be XHTML conformant. This means it can't validate HTML markup that isn't XML compliant. One example is in the issue summary - HTML allows boolean attributes that have no value: selected, required, checked, and so on. XML doesn't permit these values to be expressed as a single word - instead they have to be put in as 'selected="selected"' and so on. The resulting pages will not pass HTML 5 validation though - there is no markup that will pass HTML 5 and XML validation for this case.
Browsers are flexible enough that this doesn't matter, so the issue itself is minor. And there's no easy solution - as I pointed out in another thread the leading candidate solution is the HTML 5 version of Tidy, but that doesn't have a very wide install bases. If we replaced XPath with Tidy then there'd be a lot of sites that wouldn't be able to run the unit tests where Tidy is involved. Production sites wouldn't be affected, nor would fly by night operations that don't test their code. But is this situation, where part of Drupal has a very specific requirement, acceptable? I'm inclined to think not.
Comment #19
quietone commentedI asked about this in #bugsmash, dww and larowlan responded. They both agree that this is valid and that should open discrete issues to resolve things. It seems a meta issue is needed and then this can become a child.
larowlan added that for "this case \Drupal\KernelTests\AssertContentTrait::assertOptionSelected need not assert that $elements[0]['selected'] is !empty, only that it exists"
There is no indication why this is postponed, so I am setting it active.
Comment #21
andypostis it still reproducible after upgrade?
Comment #22
andypostLooks the next target is native css-selectors in PHP as https://wiki.php.net/rfc/opt_in_dom_spec_compliance commited