Make WordPress Core

Opened 14 years ago

Closed 12 years ago

Last modified 12 years ago

#14264 closed enhancement (duplicate)

Add support for HTML5 Section elements to editor

Reported by: cyberskull's profile cyberskull Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: TinyMCE Keywords: HTML5 wpautop
Focuses: Cc:

Description

Currently the visual editor does not support the HTML5 Section elements: article, section, aside, nav, hgroup, header & footer. As a matter of fact, it clobbers them when switching from source view to the rich view.

Because of the clobbering, it is impossible to add any HTML5 elements when switching between the two modes. This makes me quite sad as I adding sections to long pages really helps with the layout and organization.

Change History (24)

#1 @azaozz
14 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

Currently the visual editor doesn't support HTML 5.0 as a great number of the currently used browsers don't support it either (i.e. an HTML 5.0 enabled post would look quite differently to different users and may get mangled if edited with a browser that doesn't support HTML 5.0).

Support for HTML 5.0 tags and even custom tags can be added relatively easy to TinyMCE by using its extended_valid_elements setting (I'm thinking of making a small plugin to make changing TinyMCE settings even easier for WordPress users. If you're interested of testing this please contact me directly).

Closing as wontfix for now. I'm sure we will enable HTML 5.0 support by default when it becomes possible.

#2 @nacin
14 years ago

  • Milestone Awaiting Review deleted

#3 @nacin
14 years ago

  • Component changed from Editor to TinyMCE

#4 follow-up: @MarcusPope
12 years ago

  • Cc marcus.pope@… added
  • Resolution wontfix deleted
  • Status changed from closed to reopened

Hey @azaozz, just wanted to report that I have successfully enabled editing HTML5 documents in the admin area. It required changes to both tinymce (doctype, extended_valid_elements, and valid_children) and the wordpress core (wpautop), but it works and works well with all modern browsers as of this comment.

There is one remaining issue that I'm having which is the anchor tag now supports containing flow elements (block level elements) in html5, yet wpautop doesn't handle that aspect properly. If I disable wpautop entirely everything works perfectly.

I'd like to either re-open this ticket now that other html5 features have been added in #13982 or open a new ticket.

I'm not sure if it's as simple as adding "|a" to $allblocks or if it will require more customization because for my purposes I had to completely disable wpautop anyway (for client-specific reasons.) With wpautop enabled the behavior is similar to #15918 so there may not even be a need for a new ticket.

I'd contact you directly, but I don't know how :( so hopefully you see this comment :D I can be reached either here, or at marcus.pope at springbox.com

Thanks!

Last edited 12 years ago by scribu (previous) (diff)

#5 @SergeyBiryukov
12 years ago

  • Milestone set to Awaiting Review

#6 in reply to: ↑ 4 @azaozz
12 years ago

Replying to MarcusPope:

Hey @azaozz, just wanted to report that I have successfully enabled editing HTML5 documents in the admin area.

The visual editor supports all HTML5 tags (i.e. doesn't remove them) however it doesn't insert/use them. There are still a lot of older browsers that won't work properly with HTML5 (IE7, 8, etc.).

If we start using HTML5 there it would limit the browsers the front-end of the site supports. That seems highly undesirable.

#7 follow-up: @MarcusPope
12 years ago

Actually with a small bit of javascript and css HTML5 support is available for IE6+ And currently the visual editor does NOT support HTML5 Block Level Anchor tags, you have to customize the allowable_children config setting and completely disable wpautop to get them to work.

Here are some reference points for you:

http://remysharp.com/2009/01/07/html5-enabling-script/

http://html5doctor.com/block-level-links-in-html-5/

Thanks,
Marcus

#8 in reply to: ↑ 7 ; follow-up: @azaozz
12 years ago

Replying to MarcusPope:

Actually with a small bit of javascript and css HTML5 support is available for IE6+

Yes, there are hacks to make HTML5 partially work on older IE but hope you're not suggesting we have to force all WordPress installations and all themes to use them? That would potentially break all themes that serve the front-end as XHTML 1.0 and there seem to be some that serve it as XHTML 1.1 or even xml.

And currently the visual editor does NOT support HTML5 Block Level Anchor tags.

These seem to be handled by the error correcting in many current browsers rather than implemented as standard feature and a bit buggy in some. Not sure what the support in contentEditable mode is. In any case this is a "feature request" for TimyMCE rather than WordPress.

#9 follow-up: @MarcusPope
12 years ago

C'mon Azaozz, partially work? http://html5boilerplate.com/ this stuff is solid, and has been around for a couple years now.

And no, I'm not suggesting that we force all installations to use it, but that doesn't mean we should leave code in the system that prevents their usage in a plugin. Even better make it an option in the admin. Only the latest browsers are supported for the admin area anyway, and they all support HTML5 now.

HTML5 style Block Level Anchor tags have actually been supported for years (10+) now. They weren't considered valid markup by xhtml standards, but browsers knew what to do with them. I'm pretty sure even IE3.0 supported them, but my memory is fading these days.

But this is NOT a TinyMCE issue. TinyMCE actually supports them completely (except for around tables of course, but then again I don't think any browser supports that yet.) I am sure about the support in contentEditable mode because I developed a solution for it. You even said yourself tinyMCE supports all HTML5 tags.

Mostly I was opening this ticket because of your comment: "Closing as wontfix for now. I'm sure we will enable HTML 5.0 support by default when it becomes possible." Well, now it would be possible via a plugin if it were not for some broken (ok outdated) logic in WPAUTOP.

And the only reason I suggested enhancing the allowable_children option in the core config options is because WP has already added other html5 tags to the core config for tinyMCE in the changeset I referenced above. It wouldn't impact editing of xhtml content unless someone actually used the construct (ie wrapped an anchor around a block element.)

But if you do that today, and you save or switch tabs the markup is completely mangled because wpautop mucks it up.

I don't really care either way, I have managed to disable wpautop for my own projects and my life is much happier as a result. But I figured for those who enjoy the use of wpautop formatting, they might also enjoy block level anchor tags if their theme supported html5 too.

#10 @nacin
12 years ago

What specifically is out of date in wpautop? Sounds like a good (distinct) bug report.

#11 in reply to: ↑ 9 ; follow-ups: @azaozz
12 years ago

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

Replying to MarcusPope:

C'mon Azaozz, partially work? http://html5boilerplate.com/ this stuff is solid, and has been around for a couple years now.

Yes, partially work in IE7 and 8. Using JS + CSS hacks makes these browsers recognize most HTML 5 elements but doesn't make them "HTML 5.0 compatible". And there is also a (small) group of users that are forced to use old IE with JS disabled and cannot upgrade their browsers. Allowing the front-end of all WordPress sites to be broken in that case is a very bad idea indeed :)

And no, I'm not suggesting that we force all installations to use it, but that doesn't mean we should leave code in the system that prevents their usage in a plugin. Even better make it an option in the admin. Only the latest browsers are supported for the admin area anyway, and they all support HTML5 now.

We are not talking about the admin here. See above.

HTML5 style Block Level Anchor tags have actually been supported for years (10+) now. They weren't considered valid markup by xhtml standards, but browsers knew what to do with them. I'm pretty sure even IE3.0 supported them, but my memory is fading these days.

Yes, this works in all browsers but is buggy in some. However the reason it works is not because it is a standard feature, it's because the browsers error-correct it. Check the comments on the site you referenced above.

But this is NOT a TinyMCE issue. TinyMCE actually supports them completely (except for around tables of course, but then again I don't think any browser supports that yet.) I am sure about the support in contentEditable mode because I developed a solution for it. You even said yourself tinyMCE supports all HTML5 tags.

TinyMCE is very configurable (as you already know). You can set it to allow all kinds of input, custom HTML tags and attributes, etc. Using and allowing these is a "plugin material" though.

Mostly I was opening this ticket because of your comment: "Closing as wontfix for now. I'm sure we will enable HTML 5.0 support by default when it becomes possible." Well, now it would be possible via a plugin if it were not for some broken (ok outdated) logic in WPAUTOP.

Still think this ticket should be closed as "maybelater". I'll be glad to add support for all HTML5 tags, not just for <section>, on the front end but that doesn't seem possible at present.

As @nacin suggests, feel free to add comments to existing tickets (or open another ticket if the existing tickets don't cover this) for any needed updates to wpautop.

#12 @SergeyBiryukov
12 years ago

  • Milestone Awaiting Review deleted

#13 follow-up: @MarcusPope
12 years ago

Sorry, we're talking about two different aspects. I'm not advocating forcing the front end or back end to use HTML5. HTML5 usage can be turned on in the backend content editable iframe only without having the parent document switched from xhtml. And the front end is purely up to the theme.

I completely meant this as a plugin / configurable option for users who want it. My point was that it is not possible now without disabling wpautop because it considers the anchor tag an inline content only tag and will break block anchor tags in the markup. And there is no way of changing that without "subclassing" the filter. With wpautop disabled, the browser does not mangle the output (all modern browsers, and many older variants.) I'm not saying force it on everyone including ie7 users with disability access, but just to make it available to those who want an HTML5 site AND make use of block level anchor tags without disabling wpautop.

I suppose I could duplicate the entire wpautop logic in a plugin, but that seems like a bad choice. Allowing block level anchor tags in markup (whether by configuration setting or by default) doesn't affect users who want to continue using xhtml layouts.

I know this works because I'm using it now by completely disabling wpautop. I'll work on the solution in that function and propose a patch if that's what needs to happen.

I'm sorry for the confusion here.

#14 in reply to: ↑ 13 @azaozz
12 years ago

Replying to MarcusPope:

I suppose I could duplicate the entire wpautop logic in a plugin, but that seems like a bad choice.

Agreed. That's why I suggested commenting on (or opening) a ticket about patching wpautop. It needs some updates especially around handling of blocks that can contain other blocks. This also includes <a> tags containing blocks.

#15 in reply to: ↑ 8 @WraithKenny
12 years ago

  • Keywords wpautop added

#16 @WraithKenny
12 years ago

  • Cc Ken@… added

related #17105

#17 in reply to: ↑ 11 @WraithKenny
12 years ago

What a long, strangely surreal, conversation on this ticket. I carefully read every line of the back and forth between MarcusPope and azaozz, and could find no flaw in any sentiment shared by Marcus.

After a thorough reading of the responses, I understand the decision to be to intentionally obstruct HTML5 usage even on the theme-side of the blog for the expressed purpose of protecting blog readers from HTML5, regardless of what the actual blog owners want.

I think this is a bad decision.

#18 follow-up: @MarcusPope
12 years ago

Thanks WraithKenny for the vote of confidence. I ultimately gave up on the fix because I pointed out the very specific flaw of wpautop with regard to anchor elements and both nacin and azaozz wanted me to be more specific.

And then for azaozz to say that browsers error-correct the block level anchor tags so we won't do it is just an obstinate point because error-correct or not, the results prove to work almost universally. Sure, there are some really edge case caveats, but this is the web. And instead of pointing out those caveats here (which would have been useful) he leaves it up to every reader to peruse 150 comments only to find out that one person reported an odd, semi-reproducable behavior in firefox 3.5, and a problem with an invalid construct of li tags - best reasons ever to break a landmark feature of html5 right?

Given that wordpress touts html5 compliance and the effort it takes to get any traction on improving that compliance, I simply walked away - there are plenty of other open source projects to support and the I have yet to experience such defensiveness towards enhancements from other core teams.

#19 in reply to: ↑ 18 @azaozz
12 years ago

Replying to WraithKenny:

...I understand the decision to be to intentionally obstruct HTML5 usage even on the theme-side of the blog for the expressed purpose of protecting blog readers from HTML5, regardless of what the actual blog owners want.

Not sure where that understanding comes from... Can repeat the answer from 6 months ago: http://core.trac.wordpress.org/ticket/14264?replyto=17#comment:14

Replying to MarcusPope:

...browsers error-correct the block level anchor tags...

This can be tested pretty easy/fast: make a webpage containing <a><h3>...</h3><p>...</p></a>, then look at the internal browser representation of the html.

...effort it takes to get any traction on improving that compliance...

You're right, however the original problem in this ticket has been fixed. TinyMCE supports article, section, aside, nav, hgroup, header, footer, and some other HTML 5 tags now so the ticket should be closed.

If you want to work on a patch for handling block tags inside <a> in wpautop, feel free to open new ticket and add the patch there.

Last edited 12 years ago by azaozz (previous) (diff)

#20 in reply to: ↑ 11 @WraithKenny
12 years ago

Replying to azaozz:

Replying to WraithKenny:

...I understand the decision to be to intentionally obstruct HTML5 usage even on the theme-side of the blog for the expressed purpose of protecting blog readers from HTML5, regardless of what the actual blog owners want.

Not sure where that understanding comes from...

From here (emphasis mine):

MarcusPope:

I'm not suggesting that we force all installations to use [ "JS + CSS hacks" ], but that doesn't mean we should leave code in the system that prevents their usage [HTML5 elements] in a plugin.

azaozz:

Using JS + CSS hacks makes these browsers recognize most HTML 5 elements but doesn't make them "HTML 5.0 compatible". And there is also a (small) group of users that are forced to use old IE with JS disabled and cannot upgrade their browsers. Allowing the front-end of all WordPress sites to be broken in that case is a very bad idea indeed :)

Still think this ticket should be closed as "maybelater". I'll be glad to add support for all HTML5 tags, not just for <section>, on the front end but that doesn't seem possible at present.

I do apologize if I'm interpreting this wrong (and I certainly could be wrong, happens all the time).

If I am wrong, please just say so directly.

#21 @MarcusPope
12 years ago

@WraithKenny already pointed out where our impressions came from with regard to azzaoz so I'll just focus on the other half of his point:

Replying to @azaozz:

This can be tested pretty easy/fast: make a webpage containing <a><h3>...</h3><p>...</p></a>, then look at the internal browser representation of the html.

You are right, it is very easy to check that, so I did:
http://www.marcuspope.com/img/block/block.html

http://www.marcuspope.com/img/block/opera.png

http://www.marcuspope.com/img/block/ff.png

http://www.marcuspope.com/img/block/chrome.png

http://www.marcuspope.com/img/block/ie.png

As expected the browser properly constructs the document without any error correction or dom coercion. These are internal representations of the document using their respective tools, not simply views of the downloaded source. And they were compiled with the oldest versions of every browser I have installed.

Replying to @azaozz:

You're right, however the original problem in this ticket has been fixed. TinyMCE supports article, section, aside, nav, hgroup, header, footer, and some other HTML 5 tags now so the ticket should be closed.

??? Again, I'm really confused because this ticket is "closed enhancement: maybelater." Additionally the BUG is that when you switch from the HTML tab to the Visual tab in the edit screen it clobbers the HTML. This has NOTHING to do with TinyMCE and EVERYTHING to do with the wpautop hook that wordpress binds to the tab switch event. If you disable wpautop (both the client and server side implementations) and you try to reproduce this bug, you will find that TinyMCE doesn't clobber the HTML. Even worse is that the client side implementation is slightly different from the server side implementation so they don't always "correct" the html in the same way.

Honestly I didn't see any reason to open a new bug when this ticket clearly and exactly outlined the use case and resulting problem. And there was nothing in the responses that I, @CyberSkull, and others received that led me to believe my new bug ticket wouldn't be changed to a nice to have feature enhancement and closed for "maybelater"

I think this thread continues to outline difficulty in communicating with the core team.

Last edited 12 years ago by MarcusPope (previous) (diff)

#22 @nacin
12 years ago

  • Resolution maybelater deleted
  • Status changed from closed to reopened

I think this thread continues to outline difficulty in communicating with the core team.

You're trying (and, I'll admit, failing) to communicate with one developer, not the whole core team.

It's really tiring to read all of the back and forth here. This ticket is being closed as a duplicate. Of what? Of a yet-to-be-created ticket that outlines the specific issues. A ticket you are welcome to create. If that means the bug report needs to be filed against the JS and PHP versions of wpautop, then that is the bug that should be filed. (Per #17105 it appears wpautop is updated.)

I am happy to consider any bug report and patch to fix whatever is broken for 3.4. Let's stop wasting time talking process (which clearly failed here) and just concentrate on the bugs, the steps to reproduce, and what need to be fixed.

#23 @nacin
12 years ago

  • Resolution set to duplicate
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.