[Form] Use self-closing <input /> tags again
#53649
Comments
|
Inviting @ThomasLandauer as the author of #47715 to the discussion. I'd like to learn more about your use cases and why it was important to you to change this? |
<input> again<input /> tags again
|
sidenote: php8.4 will come with proper html5 support |
|
@mpdude Would the HTML5 parser that will be shipped with PHP 8.4 solve your problem? |
|
I haven't yet had the opportunity to try it. But after all I read about it and why it was written in the first place, I assume yes. |
|
Would it be an option to revert the change and postpone it to a Symfony version that requires PHP 8.4? Could this be reverted as a bug fix, or in a feature release only (since it was added in feature release 6.4 as well)? |
|
I opened that PR just because |
|
What would be an acceptable target branch for a PR that reverts the change? |
6.4 I suppose |
|
PR is at #53656 |
…#47715 (mpdude) This PR was merged into the 6.4 branch. Discussion ---------- [Form] Use self-closing `<input />` syntax again, reverting #47715 | Q | A | ------------- | --- | Branch? | 6.4 | Bug fix? | yes | New feature? | no | Deprecations? | no | Issues | Fix #53649 | License | MIT This PR reverts #47715 and puts the trailing slash back into `<input .../>` markup in the form themes. The reasons are outlined in detail in #53649. Basically, the trailing slash in void elements like `<input>` is not required in HTML 5, yet it is perfectly valid and compliant with specs. Writing markup that way is required to parse and process it with an XML parser, like `libxml2` underlying all of the PHP DOM, XML etc. extensions. HTML 5 capable parser support has been added to PHP in php/php-src#12111 and will be available with PHP 8.4. So, we might want to remove the trailing slashes once Symfony requires at least PHP 8.4. Commits ------- 8c92200 Revert #47715
|
Fixed by #53656 |
Uh oh!
There was an error while loading. Please reload this page.
Description
#47715 removed self-closing slashes from
<input>elements in the various form themes, i.e. it changed<input ... />to<input ...>.My request is to revert this change, or at least to make it configurable (either way opt-in/opt-out/opt-back-in).
The reasons given in #47715 were:
The "widely discouraged" reference to https://google.github.io/styleguide/htmlcssguide.html#HTML_Style_Rules does, as of today, state nothing about self-closing tags anymore. And, as of today, the W3 validator merely writes:
That's a far less opinionated statement.
The referenced document at https://github.com/validator/validator/wiki/Markup-%C2%BB-Void-elements#trailing-slashes-in-void-element-start-tags-do-not-mark-the-start-tags-as-self-closing goes on nit-picking that that for "void elements" (like
<hr>or<input>), the trailing slash does not mark the start tag as self-closing, but instead...The other argument against the slash is a possible mis-interpretation when using unquoted attribute values. That, however, is not an issue for the case we're discussing here (the form themes all using quoted attribute notation).
This now brings me to my reason why I'd like to keep the
<input />style for now:When you want to use the PHP DOM extension for parsing HTML5, doing DOM transformations and/or using XPath, you can do so under the requisite of writing Polyglot HTML 5. Basically, this describes a set of extra rules to follow to write markup in a way that it has the same meaning to an HTML 5 and an XML parser. PHP DOM functions are based on
libxml2, an XML parser.Writing Polyglot HTML 5 allows to use PHP DOM extension functions to load, inspect, modify and dump HTML 5 documents. Polyglot HTML 5 requires self-closing tags to be used for void elements.
Removing the self-closing trailing slash as in #47715 takes this possibility from users, unless they completely override the form theme or do quirky string-replacements on the content. This is exactly what was made to get the tests green at https://github.com/symfony/symfony/pull/47715/files#r1280400076 - run a
preg_replaceto use the DOM functions afterwards.The
/may be superfluous and annyoing for purists, but it is officially OK and valid. It allows to keep the PHP DOM use case working.Some more words on libxml2
The
libxml2library powering the PHP DOM functions has been written 20 years ago, long before the advent of HTML 5. It has no HTML 5 support, and that's probably never going to change. To my knowledge, there is no established, proven, fast alternative available as of today.There is https://github.com/Masterminds/html5-php, but as a parser written in PHP it cannot compare with the C efficiency of
libxml2.All the problems surrounding
libxml2and its use on HTML 5 are neatly summarized in https://wiki.php.net/rfc/domdocument_html5_parser. That RFC lead to what seems to be HTML 5 support in the DOM extension – but the implementation has been merged into PHP only two months ago.The comment over at the disputed PR that points to
...loadHTML()is a trap.loadHTMLinlibxml2implements logic that tries to recover non-well formed HTML 4 – a technology from the last millenium only the most seasoned among us might remember – into XHTML 1.0. This is not a sane thing to run on HTML 5 input, and the php.net documentation features a red warning box about this.Example
No response
The text was updated successfully, but these errors were encountered: