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

CommentFileSizeAuthor
do-not-test-2444003-21.diff70.62 KBAki Tendo

Comments

mgifford’s picture

Version: 8.0.x-dev » 8.1.x-dev

Not sure what this is postponed on for 8.0. Maybe it can be dealt with in 8.1 though.

Aki Tendo’s picture

I 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.

mgifford’s picture

@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.

Aki Tendo’s picture

The 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.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

Issue summary: View changes
Status: Postponed » Active
Issue tags: +Bug Smash Initiative

I 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.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

andypost’s picture

is it still reproducible after upgrade?

andypost’s picture

Looks the next target is native css-selectors in PHP as https://wiki.php.net/rfc/opt_in_dom_spec_compliance commited

Version: 11.x-dev » main

Drupal core is now using the main branch as the primary development branch. New developments and disruptive changes should now be targeted to the main branch.

Read more in the announcement.