Opened 15 years ago

Closed 13 years ago

Last modified 13 years ago

#4556 closed New Feature (fixed)

Html5 and xhtml5 support

Reported by: Exception e Owned by: Frederico Caldeira Knabben
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 (4)

dtd.js (7.5 KB) - added by Jonathan Neal 14 years ago.
Modified dtd.js for preliminary HTML5 support
dtd.js-html5.patch (4.8 KB) - added by Keith Gable 13 years ago.
Patch to dtd.js (an improvement over the submitter's) to add minimal HTML5 support
plugins-styles-plugin.js-html5.patch (834 bytes) - added by Keith Gable 13 years ago.
plugins/styles/plugin.js updated for HTML5 support
4556.patch (5.7 KB) - added by Frederico Caldeira Knabben 13 years ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 15 years ago by Garry Yao

Keywords: Confirmed added
Type: BugNew Feature
Version: 3.0.1

Changed 14 years ago by Jonathan Neal

Attachment: dtd.js added

Modified dtd.js for preliminary HTML5 support

comment:2 Changed 14 years ago by Jonathan Neal

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 14 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 3.x

Milestone CKEditor 3.x deleted

Changed 13 years ago by Keith Gable

Attachment: dtd.js-html5.patch added

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

comment:4 Changed 13 years ago by Keith Gable

Component: GeneralCore : 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 13 years ago by Keith Gable

plugins/styles/plugin.js updated for HTML5 support

comment:5 Changed 13 years ago by Keith Gable

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

comment:6 Changed 13 years ago by Keith Gable

Keywords: HasPatch added

comment:7 Changed 13 years ago by Jonathan Neal

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

comment:8 Changed 13 years ago by Wiktor Walc

Version: 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 13 years ago by Frederico Caldeira Knabben

Attachment: 4556.patch added

comment:9 Changed 13 years ago by Frederico Caldeira Knabben

Owner: set to Frederico Caldeira Knabben
Status: confirmedreview

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 Changed 13 years ago by Garry Yao

Status: reviewreview_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 Changed 13 years 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 13 years ago by Frederico Caldeira Knabben

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 13 years ago by Frederico Caldeira Knabben

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 13 years 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 13 years ago by Frederico Caldeira Knabben

Status: review_failedreview

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 13 years ago by Garry Yao

Status: reviewreview_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 13 years ago by Frederico Caldeira Knabben

Status: review_failedreview

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 13 years ago by Garry Yao

Status: reviewreview_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 13 years ago by Frederico Caldeira Knabben

Milestone: CKEditor 3.6.1
Resolution: fixed
Status: review_passedclosed

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

comment:20 Changed 13 years ago by Garry Yao

#7960 and #7961 opened for unhanded bugs.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy