WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

Last modified 2 years ago

#42972 closed defect (bug) (duplicate)

XHTML CDATA compliance regression in preview script

Reported by: sephr Owned by:
Milestone: Priority: normal
Severity: normal Version: 4.9.1
Component: General Keywords:
Focuses: Cc:
PR Number:

Description

The following script is injected on post preview pages without CDATA for XHTML compliance. I remember this issue being fixed a few years ago, and it has regressed.

	<script>
	( function() {
		var query = document.location.search;

		if ( query && query.indexOf( 'preview=true' ) !== -1 ) {
			window.name = 'wp-preview-530';
		}

		if ( window.addEventListener ) {
			window.addEventListener( 'unload', function() { window.name = ''; }, false );
		}
	}());
	</script>

The script needs /*<![CDATA[*/ at the start and /*]]>*/ at the end to fix rendering errors when served as application/xhtml+xml.

Change History (3)

#1 @dd32
2 years ago

  • Component changed from Revisions to General
  • Focuses coding-standards removed
  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

I believe this is covered in #36036 which never got any traction.

Serving sites as application/xhtml+xml never really gained traction, and HTML5 moved away from that requirement of strictness.

@sephr you should probably consider moving away for a smoother experience in the future IMHO. If #36036 ever gets any traction, it'll break again in the future for sure.

#2 @sephr
2 years ago

@dd32 I understand that XHTML isn't very popular nowadays. I've been using XHTML(5) with my custom theme on WordPress since 2007, and the codex still says that you support it (and has ever since I started using WordPress). I would really appreciate if the core devs could take a definite stance on this issue so that I don't need to manually patch my site after every couple updates.

If you wish to officially drop XHTML support, codex.wordpress.org will need to be revised. Here are some codex.wordpress.org links that suggest that XHTML is still supported by WordPress:

WordPress prints XHTML from all its internal functions

https://codex.wordpress.org/HTML_to_XHTML#Why_Should_I_use_XHTML

improving XHTML compatibility (don't mess up people's code)

https://codex.wordpress.org/Testing#Testing.2FJavascript_and_WYSIWYG (Implies that there was usage of XHTML and that WordPress developers should be mindful of compatibility)

Some changelog entries with descriptions related to fixing XHTML compatibility: https://www.google.com/search?q=inurl%3Ahttps%3A%2F%2Fcodex.wordpress.org%2FChangelog%2F+XHTML

I haven't had any issues with WP core XHTML support until recently the past couple years. The majority of my issues have been from components that I've been using for over a decade emitting proper XHTML that have been absorbed by Jetpack (e.g. WP Stats) and recently updated to emit malformed XHTML.

Last edited 2 years ago by sephr (previous) (diff)

#3 @dd32
2 years ago

The codex is a Wiki and not an official support document, it's community powered.
Most of the article was written between 2005 and 2009, the only changes in the last 8 years have been minor changes. Please feel free to update it.

As far as I'm concerned, WordPress never supported it well, and it was never adopted by enough people to matter (I used to use it FYI).

This is still a duplicate of a 2 year old ticket, and is unlikely to ever be fixed.

Note: See TracTickets for help on using tickets.