Make WordPress Core

Opened 15 years ago

Closed 14 years ago

#14226 closed defect (bug) (maybelater)

Add XHTML namespace declaration to Twenty Ten/Twenty Eleven to provide XHTML compatibility

Reported by: peaceablewhale's profile peaceablewhale Owned by: iandstewart's profile iandstewart
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Bundled Theme Keywords: has-patch
Focuses: Cc:

Description

The HTML5 Spec allows the html element having a xmlns attribute with value "http://www.w3.org/1999/xhtml" This provides XHTML compatibility to HTML5. I suggest this should be added to Twenty Ten.

Attachments (1)

14226.patch (1.0 KB) - added by peaceablewhale 14 years ago.

Download all attachments as: .zip

Change History (23)

#1 @nacin
15 years ago

application/xhtml+xml != XHTML. See also #14224, #14225.

#2 @peaceablewhale
15 years ago

This issue is a bit different from the other two. Without the namespace declared, the document is not XHTML.

#3 @nacin
14 years ago

  • Keywords 2nd-opinion added
  • Milestone changed from Awaiting Review to Future Release

Suggesting wontfix.

#4 @holizz
14 years ago

  • Cc tom@… added

#5 @ocean90
14 years ago

  • Summary changed from Add XHTML namespace declaration to Twenty Ten to provide XHTML compatibility to Add XHTML namespace declaration to Twenty Ten/Twenty Eleven to provide XHTML compatibility

#6 @peaceablewhale
14 years ago

Merged with #17363. Patch updated.

#7 @peaceablewhale
14 years ago

  • Owner set to iandstewart
  • Status changed from new to reviewing

#8 @nacin
14 years ago

  • Milestone changed from Future Release to 3.2

I'm unsure about this, but these themes are no longer XHTML, but rather now HTML5. While we stick to XHTML tendencies such as closing elements and expanding short attributes, I don't know if there's a necessity to actually declare it with an XML namespace.

That said, since we are continuing our desire for XHTML-like markup, maybe we should drop it in.

Moving to 3.2 for consideration and disposal (commit or wontfix). I'm not sure what the right answer is here. We need something more definitive.

#9 @peaceablewhale
14 years ago

Do hope that this will be commit, because it provides an option for blogger/webmaster to change the Content-Type he/she considers appropriate. See http://www.w3.org/TR/html-polyglot/ for further information.

#10 @ocean90
14 years ago

I thought that this namespace is now standard in HTML5.


The first thing to discuss is the xmlns attribute. This is a vestige of XHTML 1.0. It says that elements in this page are in the XHTML namespace, http://www.w3.org/1999/xhtml. But elements in HTML5 are always in this namespace, so you no longer need to declare it explicitly. Your HTML5 page will work exactly the same in all browsers, whether this attribute is present or not.

Source: http://diveintohtml5.org/semantics.html#html-element

#11 @peaceablewhale
14 years ago

Yes, when the page is served as text/html, DOM methods like document.getElementsByTagNameNS still works even though there is no xmlns="http://www.w3.org/1999/xhtml" declared because HTML does not support namespace and browsers put all elements in html in the HTML namespace automatically. However, when the page is served as application/xhtml+xml, the XML namespace is required as XML processing rules are now used and the default namespace is null.

#12 @nacin
14 years ago

  • Keywords 2nd-opinion removed
  • Milestone 3.2 deleted
  • Resolution set to invalid
  • Status changed from reviewing to closed

We don't support application/xhtml+xml. Simple as that, really. I don't know why anyone bothers with it anymore, either.

#13 @peaceablewhale
14 years ago

  • Resolution invalid deleted
  • Status changed from closed to reopened

When adding the namespace declaration provides better compatibility, why not do so?

#14 @Otto42
14 years ago

If adding the xmlns attribute to the theme is all that is required for it to render properly under the application/xhtml+xml mime type, then I see no problem with it.

However, if the theme doesn't render properly using that mime type (because it's not a valid XML document), then there's no reason to add it.

Does the theme's normal output properly validate as XML and render under application/xhtml+xml after adding that attribute? If so, do it. If not, don't bother.

#15 @nacin
14 years ago

As presented in IRC:

Two gold stars shall be awarded to the person who can present a reasonable argument that application/xhtml+xml has any practical relevance in any sense of either word, given the current standards and browsers of the web, and also given the dynamic content uses of modern day CMSes.

In other words, I need something more than "better compatibility" -- why would you ever use this with WordPress? What's the benefit?

#16 follow-up: @nacin
14 years ago

Upon further reading, the HTML5 parser includes MathML and SVG, which based on cursory research, was the only previous practical relevance to using application/xhtml+xml.

#17 in reply to: ↑ 16 ; follow-up: @peaceablewhale
14 years ago

Replying to nacin:

Upon further reading, the HTML5 parser includes MathML and SVG, which based on cursory research, was the only previous practical relevance to using application/xhtml+xml.

Currently, Safari and Opera (not sure about Chrome) do not support inline SVG under text/html. As a result, application/xhtml+xml is still relevant.

#18 @GaryJ
14 years ago

I think the point is about giving people options - sure, no-one is asking the back-end of WP to be a Polyglot document (though that would be cool), but making a core front-end theme be polyglot to allow users to set up their site as application/xhtml+xml, bears very little burden on those who don't need it, while opening up possibilities for those that do want to make use of it.

#19 @dd32
14 years ago

Those that want to use it can do so in a child theme, There's likely other things that need to change in order to make using it successful anyway, so a Child theme makes sense for all those things.

#20 in reply to: ↑ 17 @holizz
14 years ago

Here's a compatibility chart for inline SVG in HTML by the way: http://caniuse.com/svg-html5

I agree with dd32. It's not at all a popular format (I've only ever seen one Web site that uses XHTML), it can be very easily implemented using a child theme (assuming there's a filter for the MIME type), and the features it boasts over HTML are being implemented in HTML and will be available shortly.

#21 @westi
14 years ago

  • Component changed from Themes to Bundled Theme

#22 @westi
14 years ago

  • Resolution set to maybelater
  • Status changed from reopened to closed

I agree with the consensus here amongst core devs that we do not need to do this in the Bundled Theme at this point.

As dd32 points out for individual installs this can easily be achieved using a child theme.

Closing as maybelater.

Note: See TracTickets for help on using tickets.