WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

#8996 closed enhancement (wontfix)

Serve application/xhtml+xml if browser, theme and plugins are compliant

Reported by: sampablokuper Owned by:
Milestone: Priority: normal
Severity: normal Version: 2.7
Component: Template Keywords: dev-feedback
Focuses: Cc:

Description

This enhancement request is based on ticket 4466, especially comment 17 onwards, but with the additional stipulation that application/xhtml+xml should only be served if browser, theme and plugins are all compliant. If any of the three are not, text/html should be served instead.

Attachments (1)

spk_xhtml_rdfa_1_parent.zip (57.1 KB) - added by sampablokuper 5 years ago.
An XHTML+RDFa compatible parent theme which serves as application/xhtml+xml for compliant browsers

Download all attachments as: .zip

Change History (9)

sampablokuper5 years ago

An XHTML+RDFa compatible parent theme which serves as application/xhtml+xml for compliant browsers

comment:1 follow-up: DD325 years ago

  • Component changed from General to Template
  • Milestone set to 2.9

All tickets need a milestone.

I am still of the opinion this is a theme-dependant thing, Its not for WordPress core to figure out if the theme is compliant and serve.. The theme can do that.

i'd nearly say "Go ahead and put a function which the theme can call to register itself as xml-complant", but then, 1 line of code to the theme.. or 3-5 lines and the theme controls it itself..

comment:2 in reply to: ↑ 1 sampablokuper5 years ago

Replying to DD32:

All tickets need a milestone.

Thanks for setting this for me.

I am still of the opinion this is a theme-dependant thing, Its not for WordPress core to figure out if the theme is compliant and serve.. The theme can do that.

Well, yes, a theme developer should be able to determine (and state) that her theme is compliant. But that's not all that's needed; see below.

i'd nearly say "Go ahead and put a function which the theme can call to register itself as xml-complant", but then, 1 line of code to the theme.. or 3-5 lines and the theme controls it itself..

If only the theme needed to be compliant, then you would be correct, but as it stands, there is at least some code (a string containing HTML entities) in the WP core which is not compliant (for details, see the comments in the style.css and functions.php files of the theme I've attached to this ticket), and there is also the possibility of plugins generating non-compliant code even if the theme and the core files do not.

So having the option for themes and plugins to register themselves compliant might be a good way forward; a bit like the way that themes could say they were widget-compatible. This would also simplify handling bugs related to compliance: if a theme/plugin that claimed to be compliant was found not to be, a bug could be raised against it, etc.

Of course, for this to work, all core WP files would need to be compliant too. Most of them are now, though, so this shouldn't be much work to attain.

comment:3 jacobsantos5 years ago

I think it would be better to allow the core to specify sections that aren't XHTML compatible than ones that are. There will be more areas that are compatible with XHTML mime type than not.

I think it is a good idea to allow plugins to specify that it is XHTML compatible. However, it is really only need for areas that are outputted to the main site. I have plugins which don't mess with the actual front page content, so it would not be needed for me to specify that my theme is compatible.

I'm not sure, I think it can be assumed that plugins are XHTML compatible unless otherwise stated as well. There should be hooks in place, so that a plugin can be created that can be set up to specify which plugins are not compatible, so that if they are activated, it will trip the text/html mime type.

There can be a function available for theme authors that allows them to set the MIME type, and if it isn't set, then it is assumed that the theme doesn't want to have the XHTML mime type set. It would have to be set in the functions.php file and hook into wp_init very late..

comment:4 follow-up: Denis-de-Bernardy5 years ago

  • Keywords dev-feedback added

imo, this should be wontfix or invalid.

sending the "correct" header serves absolutely no purpose. at the very best, you'll get hapless users in the forum saying firefox is refusing to load their site, and it'll turn out that it's because tinymce, wpautop, or some funky code in a text widget happens to have output some ill-formatted html. it's just asking for trouble.

comment:5 in reply to: ↑ 4 ; follow-up: sampablokuper5 years ago

Replying to Denis-de-Bernardy:

sending the "correct" header serves absolutely no purpose.

Really?

at the very best, you'll get hapless users in the forum saying firefox is refusing to load their site, and it'll turn out that it's because tinymce, wpautop, or some funky code in a text widget happens to have output some ill-formatted html.

I'd say that's at the very *worst*; the best would be that it all works as it should :)

Of course, to avoid the worst happening, scrutiny is required. One of the nice things about serving as application/xhtml+xml is that bugs that might only have been spotted months or years down the line normally, suddenly become visible, making scrutiny easy. As long as the devs are testing their new code in XHTML compatible browsers, it's pretty unlikely that any such errors would slip through the net.

comment:6 in reply to: ↑ 5 ; follow-up: Denis-de-Bernardy5 years ago

Replying to sampablokuper:

I'd say that's at the very *worst*; the best would be that it all works as it should :)

And to make it work as it should automatically, we'd end up either overcomplicating things (i.e. adding calls and checks to make sure all plugins return xhtml), or adding huge amounts of overhead (i.e. always making sure tinmycme, wpautop et al return xhtml, and double-checking that the entire document is valid on top).

comment:7 in reply to: ↑ 6 ; follow-up: sampablokuper5 years ago

Replying to Denis-de-Bernardy:

... to make it work as it should automatically, we'd end up either overcomplicating things (i.e. adding calls and checks to make sure all plugins return xhtml),

Er, you mean approximately the way WP used to check plugins for widget compatibility when using widget compatible themes? (I'm relatively new to WP, but it did used to do this, didn't it?)

or adding huge amounts of overhead (i.e. always making sure tinmycme, wpautop et al return xhtml, and double-checking that the entire document is valid on top).

From http://wordpress.org/about/features/:

Full standards compliance — We have gone to great lengths to make sure every bit of WordPress generated code is in full compliance with the standards of the W3C. This is important not only for interoperability with today's browser but also for forward compatibility with the tools of the next generation. Your web site is a beautiful thing, and you should demand nothing less.

As it says, we should demand nothing less :)

comment:8 in reply to: ↑ 7 Denis-de-Bernardy5 years ago

  • Milestone 2.9 deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Replying to sampablokuper:

As it says, we should demand nothing less :)

well, please start by closing a few dozen tickets. and then, reopen this one with a real patch. there's just too much clutter in trac for the devs to waste their time on things that will introduce problems.

Note: See TracTickets for help on using tickets.