If you have an element following another element that has float:left and turn on contenteditable in IE8, the following element will be precedet by an empty line in IE8 if you turn contentEditable="true".
An example:
<img src="foo.jpg" style="float:left">
<p>Some random text</p>
in IE8 this will be rendered like this:
See the line before "Some random text"?
This is especially annoying if you use a wysiwyg-editor because this affects some of its functionality. Also, this creates markup you don#t want. In CKEditor, you can see that the dom-path of that line is in the body, not inside any element.
I reported that problem to Microsoft some time ago and they didn't want to fix it: https://connect.microsoft.com/IE/feedback/details/576042/floated-elements-in-contenteditable-can-generate-an-empty-line
The last time that I checked with IE10 pp2 still had the problem.
Manually setting the css of paragraph elements with:
p {margin-top:0;margin-bottom:0}
should resolve this issue.
Related
I'm having a problem with CKEditor changing my original paragraph formatting with negative side effects.
I start with a basic paragraph loaded into CKEditor using setData():
<p><span style="font-size:50px">My Text</span></p>
... more document content ...
In the editor, I move the cursor to the end of the phrase "My Text" and press enter (with config.enterMode=CKEDITOR.ENTER_BR setting enabled). Inspecting the markup inside the editor I now see:
<p><span style="font-size:50px">My Text<br><br></span></p>
... more document content ...
Then, when I call getData() to pull the contents from the editor and save the document to a database, the HTML extracted by getData() looks like this:
<p><span style="font-size:50px">My Text</span><br> </p>
... more document content ...
This is a problem because while editing, the <br> tag was inside the <span> and was subject to the 50px font size style. The user saw a 50px blank line before the next piece of document content. After saving the HTML to a database and reloading later the <br> tag is now outside the <span> and is not subject to the 50px font sizing and the blank line appears much smaller than before.
The round trip fidelity of the text formatting is not preserved and the user is frustrated by the results.
Can someone help me understand the results I'm seeing with <br> tags being reformatted and moved around during the editing life cycle, and how I might fix this problem?
Using CKEditor v4.4.1
I've got a strange probleme here.
If I have this line in the HEAD part
<meta name="viewport" content="width=1200,initial-scale=2,minimum-scale=2">
touching the lines which are not links in the following example causes one of the links to get activated:
<ul>
<li>example</li>
<li>test</li>
<li>Text in between</li>
<li>Even more text in between</li>
<li>something</li>
<li>other</li>
</ul>
This seems to happen only with that line in the HEAD part. Everything is okay with Chrome and Android Browser.
Is there any way to solve this?
Edit:
It gets even worse if I make the line-height small, for example this way:
li { font-family:Arial; font-weight:bold; font-size:12px; line-height:12px;}
Now whether I use that META element or not, it is almost impossible to tap the texts in between without activating one of the links. Again only in Firefox mobile browser.
I think I've found a solution, however, I don't like it very much.
Adding an "onclick" attribute (whether empty or not) to each unlinked element makes it touchable in Firefox browser.
This can be achieved through a small JavaScript loop.
Better solutions are appreciated!
SOLVED. Update - I was mistaken in my original assumption. See my answer below.
I have an app where I initialise inline ckeditors on various contenteditable divs.
I am well aware that CKEditor needs to add
<p><br><p>
to the markup of an empty editor to prevent content collapse, however I have a specific situation where contenteditable div that contains ONLY this html:
<h2>This is a heading</h2>
Has its markup modified to this:
<p><br></p><h2>This is a heading</h2><p><br></p>
When I call
CKEDITOR.inline(element, config);
Where element is the contenteditable div
I am using 4.4.1
This only happens when the markup in the contenteditable div is purely a heading. If there is also a paragraph in the markup this does not happen.
It appears that CKEditor is ignoring the heading when determining whether or not it needs to add content to an empty editor.
To be clear everything else works as I would expect, just this very specific issue.
Any ideas how to fix this?
Ok I figured out this was not ckeditor at all but some of my own code that was adding the tags.
I had some script which was checking whether the innerHtml of the element was a p tag, and if not, it was wrapping the whole thing in p tags.
The reason this was not more obvious is because the p tags were empty and hence collapsed. Only when calling CKEDITOR.inline(element, config) on the element did CKEditor do its thing and fillEmptyBlocks, which created the height of the p tags. This seemed then that they only appeared when the editor was instantiated.
In fact they were there already.
Documentation from abcpdf, http://www.websupergoo.com/helppdf9net/source/3-concepts/g-htmlrender.htm, says that the html element below will cause a page break. It does but for the last page as you can see in the screen shot it doesnt. HTML passes validation, and the breaks are there so is this a bug?
<div style="page-break-before: always"> </div>
This seems to be by design, so no fix for it.
I recently have found a strange occurrence in IE8 & FF.
The designers where using js to dynamically create some span tags for layout (they were placing rounded corner graphics on some tabs). Now the xhtml, in js, looked like this: <span class=”leftcorner” /><span class=”rightcorner” /> and worked perfectly!
As we all know dynamically rendering elements in js can be quite processor intensive so I moved the elements from js into the page source, exactly as above.
... and it didn’t work... not only didn’t it work, it crashes IE8.The fix was simple, put the close span in ie: <span class=”leftcorner”></span>
I am a bit confused by this.
Firstly as far as I am aware <span class=”leftcorner” /> is perfectly valid XHTML!
Secondly it works dynamically, but not in XHTML?!?!?
Can anyone shed any light on this or is it simply another odd occurrence of browsers?
The major browsers only support a small subset of self-closing tags. (See this answer for a complete list.)
Depending on how you were creating the elements in JS, the JavaScript engine probably created a valid element to place in the DOM.
I had similar problem with a tags in IE.
The problem was my links looked like that (it was an icon set with the css, so I didn't need the text in it:
<a href="link" class="icon edit" />
Unfortunately in IE these links were not displayed at all. They have to be in
format (leaving empty text didn't work as well so I put there). So what I did is I add an few extra JS lines to fix it as I didn't want to change all my HTML just for this browser (ps. I'm using jQuery for my JS).
if ($.browser.msie) {
$('a.icon').html(' ');
}
IE in particular does not support XHTML. That is, it will never apply proper XML parsing rules to a document - it will treat it as HTML even with proper DOCTYPE and all. XHTML is not always valid SGML, however. In some cases (such as <br/>) IE can figure it out because it's prepared to parse tagsoup, and not just valid SGML. However, in other cases, the same "tagsoup" behavior means that it won't treat /> as self-closing tag terminator.
In general, my advice is to just use HTML 4.01 Strict. That way you know exactly what to expect. And there's little point in feeding XHTML to browsers when they're treating it as HTML anyway...
See I think that one of the answers to Is writing self closing tags for elements not traditionally empty bad practice? will answer your question.
XHTML is only XHTML if it is served as application/xhtml+xml — otherwise, at least as far as browsers are concerned, it is HTML and treated as tag soup.
As a result, <span /> means "A span start tag" and not "A complete span element". (Technically it should mean "A span start tag and a greater than sign", but that is another story).
The XHTML spec tells you what you need to do to get your XHTML to parse as HTML.
One of the rules is "For non-empty elements, end tags are required". The list of elements includes a quick reference to which are empty and which are not.