Ticket #4556 (closed New Feature: fixed)

Opened 3 years ago

Last modified 12 months ago

Html5 and xhtml5 support

Reported by: Exception e Owned by: fredck
Priority: Normal Milestone: CKEditor 3.6.1
Component: Core : DTD Version: 3.0
Keywords: HasPatch Cc:

Description

When fckeditor encounters an html5 tag, it behaves incorrect. It will wrap the html 5 element with p-tags.

Since it is advised to create every new site in html5 already, (basic) support for html5 would be really welcome.

Html5 is backwards compatible with html4. If html4 behaviour needs to be retained, we could introduce extra modes. xhtml
html4
html5
xhtml5

Attachments

dtd.js Download (7.5 KB) - added by jonathantneal 2 years ago.
Modified dtd.js for preliminary HTML5 support
dtd.js-html5.patch Download (4.8 KB) - added by ziggythehamster 16 months ago.
Patch to dtd.js (an improvement over the submitter's) to add minimal HTML5 support
plugins-styles-plugin.js-html5.patch Download (834 bytes) - added by ziggythehamster 16 months ago.
plugins/styles/plugin.js updated for HTML5 support
4556.patch Download (5.7 KB) - added by fredck 12 months ago.

Change History

comment:1 Changed 3 years ago by garry.yao

  • Keywords Confirmed added
  • Version 3.0.1 deleted
  • Type changed from Bug to New Feature

Changed 2 years ago by jonathantneal

Modified dtd.js for preliminary HTML5 support

comment:2 Changed 2 years ago by jonathantneal

Here is a modified dtd.js I wrote to add preliminary support for HTML5 elements. You may use this as a starting block to implement more accurate support.

comment:3 Changed 22 months ago by fredck

  • Milestone CKEditor 3.x deleted

Milestone CKEditor 3.x deleted

Changed 16 months ago by ziggythehamster

Patch to dtd.js (an improvement over the submitter's) to add minimal HTML5 support

comment:4 Changed 16 months ago by ziggythehamster

  • Component changed from General to Core : DTD

I attached a patch with some minor improvements. The submitter had menu listed twice at times, and had the element "m" which I guess is supposed to be "mark", which is also not a block element.

Also, changed component to Core : DTD since this is a DTD issue.

Changed 16 months ago by ziggythehamster

plugins/styles/plugin.js updated for HTML5 support

comment:5 Changed 16 months ago by ziggythehamster

Also, I apologize for screwing up the tabs/spaces in my patches...

comment:6 Changed 16 months ago by ziggythehamster

  • Keywords HasPatch added

comment:7 Changed 16 months ago by jonathantneal

Nice to notice that someone else is living in 2011, ziggythehamster. :)

comment:8 Changed 12 months ago by wwalc

  • Version set to 3.0

Good point with HTML5. Although it will take time till people will learn how to use new tags, it would be nice to at least not destroy the syntax.

One more example (full page mode): 

<!DOCTYPE HTML>
<head>
<meta charset=utf-8>
<title>Sample HTML5 Structure</title>
</head>
<p>This is some <strong>sample text</strong>. You are using <a href="http://ckeditor.com/">CKEditor</a>.</p>

Is transformed into: 

<!DOCTYPE HTML>
<html>
	<head>
		<meta charset="utf-8" />
		<title>Sample HTML5 Structure</title>
	</head>
	<body>
		<p>
		</p>
		<p>
			This is some <strong>sample text</strong>. You are using <a href="http://ckeditor.com/">CKEditor</a>.</p>
	</body>
</html>

Since output_xhtml.html/output_html.html samples include a lot of stuff that needs to be copied if one needs to use it, I think it would be nice to add support for HTML5 as a pure plugin that takes care of all that magic.

Changed 12 months ago by fredck

comment:9 Changed 12 months ago by fredck

  • Owner set to fredck
  • Status changed from confirmed to review

Thanks for the wonderful contributions, guys.

It's definitely time for us to start having some basic support for it. At least to avoid breaking the HTML structure.

comment:10 follow-up: ↓ 13 Changed 12 months ago by garry.yao

  • Status changed from review to review_failed

If we're talking about HTML5 compliant on DTD, there're just many other places left to upgrade, e.g. elementspath (enterkey behavior) and parser (fault tolerant).

comment:11 follow-up: ↓ 12 Changed 12 months ago by garry.yao

Actually it's bad of maintaining DTD as pieces in different places, perhaps some unifying is requires to return the control back to just the dtd file, e.g. elementspath maintains  a forked version of what are blocks and blocklimits.

comment:12 in reply to: ↑ 11 Changed 12 months ago by fredck

Replying to garry.yao:

Actually it's bad of maintaining DTD as pieces in different places, perhaps some unifying is requires to return the control back to just the dtd file, e.g. elementspath maintains  a forked version of what are blocks and blocklimits.

This is out of the scope of this ticket.

comment:13 in reply to: ↑ 10 Changed 12 months ago by fredck

Replying to garry.yao:

If we're talking about HTML5 compliant on DTD, there're just many other places left to upgrade, e.g. elementspath (enterkey behavior) and parser (fault tolerant).

Our intention is bringing basic support for HTML5, especially regarding the DOM structure. Please provide us specific TCs that need to be urgently fixed so we can have the feature included.

comment:14 Changed 12 months ago by garry.yao

I think the point is already quite clear but ok...the following block be manged by the editor (auto paragraphing) 

<article>article</article>

comment:15 Changed 12 months ago by fredck

  • Status changed from review_failed to review

Hum... that's a bad example... having <p> inside article is a very good practice, so the editor is even helping fixing it... but anyway, I'm ok with leaving with occasional bugs on the HTML5 support right now, but we can't continue with no support at all.

This is an urgent feature, so we need to make this first step forward, being able to make it better on future releases.

comment:16 Changed 12 months ago by garry.yao

  • Status changed from review to review_failed

having <p> inside article is a very good practice

We need to distinguish DTD from best practice, always.

Besides, this hand-baked DTD definitely has flaws, a very clear sample is the missing of <a> as blocklimit - assertTrue( dtd.a.p ).

comment:17 Changed 12 months ago by fredck

  • Status changed from review_failed to review

I'm very worried about having <a> as a block-limit at this stage. This is the kind of limitations I was talking about, which we can live with for now.

comment:18 Changed 12 months ago by garry.yao

  • Status changed from review to review_passed

Ok...I agree, the fact is that HTML5 is a "dtd-less" spec, where tag' semantic ambiguity has to be resolved upon the element context. I'm afraid we need to go beyond a static DTD on both arsing phase and the element path, in this specific case, a is considered as block limit only if it contains other blocks.

Here, as the patch tackles just the newly added elements so should have no back-compat issue, let's open at least the following tickets after the commit:

  1. Parser update;
  2. Elements path updates;
  3. Show block plugin updates;

comment:19 Changed 12 months ago by fredck

  • Status changed from review_passed to closed
  • Resolution set to fixed
  • Milestone set to CKEditor 3.6.1

Fixed with [6988]. Thanks to all those who collaborated to this.

comment:20 Changed 12 months ago by garry.yao

#7960 and #7961 opened for unhanded bugs.

Note: See TracTickets for help on using tickets.
© 2003 – 2011 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy