self closing tags validation

colak · 2022-09-29 09:10:39

It appears that the w3 validator is becoming intolerant to self closing tags such as <br />, <meta name="description" content="" /> etc. Maybe the time has come to drop the slash in the output of the html5 tag parser, as much I personally find it very semantically correct.

phiw13 · 2022-09-29 09:53:58

It is a warning, at the moment.

From one of my pages, link to atom feed in the <head /> with <txp:feed_link />:

Warning: Self-closing tag syntax in text/html documents is widely discouraged; it’s unnecessary and interacts badly with other HTML features (e.g., unquoted attribute values). If you’re using a tool that injects self-closing tag syntax into all void elements, without any option to prevent it from doing so, then consider switching to a different tool.

I personally fully agree that message. The closing / should not be there!

Bloke · 2022-09-29 11:14:58

We can certainly look into removing the closing slash in the parser for HTML elements. Probably need to revisit Textile too.

Not sure where that leaves our Txp: tags. Do we carry on as normal? Or do the same and forbid closing slashes on self-closing tags? That’s going to break a lot of sites on upgrade. Or just throw a Testing/Debugging mode warning for a few big release versions, that encourage people to remove their self-closing tags? And then eventually remove support for them.

I’m easy, whatever the consensus is.

phiw13 · 2022-09-29 11:22:28

Not sure where that leaves our Txp: tags. Do we carry on as normal?

Yes. That is (pseudo-)XML. A different world. The output of those tags is what matters to the HTML validator.

The output of my example above is

<link rel="alternate" type="application/atom+xml" title="Atom feed" href="https://domain.name/atom/" />

It is here that the closing / matters (for the validator).

BTW – while testing above, I noticed that theHTML validator now first checks if the site is secure, then proceeds with it is job.

colak · 2022-09-29 11:31:54

Bloke wrote #333926:

Not sure where that leaves our Txp: tags. Do we carry on as normal? Or do the same and forbid closing slashes on self-closing tags? That’s going to break a lot of sites on upgrade. Or just throw a Testing/Debugging mode warning for a few big release versions, that encourage people to remove their self-closing tags? And then eventually remove support for them.

I would leave txp tags as they are:) I might be in a minority, but I do believe that self closing tags makes markup more readable.

colak · 2022-09-29 11:47:57

If you’re using a tool that injects self-closing tag syntax into all void elements, without any option to prevent it from doing so, then consider switching to a different tool.

I really object to this aggressive attitude by a supposedly independent organisation.

Bloke · 2022-09-29 13:23:29

colak wrote #333928:

I would leave txp tags as they are:)

phiw13 wrote #333927:

Yes. That is (pseudo-)XML. A different world. The output of those tags is what matters to the HTML validator.

Great, that suits me just fine. So all we may need to do is tweak what the tags output to remove self-closers. That’s comparatively easy. We could go through and edit the markup output where necessary. Many of them will be handled by our meta functions like doTag() and doLabel(), so it’s not too onerous. However, most of those are considered deprecated now. So I’d be tempted to leave them alone.

Under the new UI library in 4.9.0+, this kind of thing is abstracted away to the render() method of each class. There’s a flag (self-closing) that can be set or passed in when constructing UI elements. This will output self-closing variants where necessary but ONLY if the scheme is xhtml. If it’s html5 (the default) then it outputs standard tags.

What this means is that, as we move our internals over to using the new UI library instead of the old functions, it should gradually fix the output of all our tags automatically. We can then decide if we want to drop support for xhtml-style tags and remove it from the library. Or we can leave it in for legacy support reasons and ditch it later.

colak · 2022-09-29 15:30:32

We can then decide if we want to drop support for xhtml-style tags and remove it from the library. Or we can leave it in for legacy support reasons and ditch it later.

Judging from the general stats I guess we can drop xhtml. We all nevertheless know that many computers in state and local authorities offices are older. It’s a tough choice, but on the positive side, txp will lose a few kbs.

phiw13 · 2022-09-30 01:05:58

We all nevertheless know that many computers in state and local authorities offices are older.

Those older computers are much more likely able to parse HTML tags than XHTML tags, unless you serve the latter as text/html, in which case there is no point in using the XHTML format (the closing slash is silently treated as a error, typo, and ignored in HTML parsing mode). And IE up to version 11 has never been able to handle application/XHTML + XML correctly.

PS. well spotted, that zealous quasi missionary message at the end of the warning. I think I have become immune to that kind of language coming from the W3C, and ignore it. I’ve seen too many of them of late.

Textpattern CMS

Textpattern CMS support forum

#1 2022-09-29 09:10:39