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
Related
Since I upgraded from Pandoc v1.19 to 2.9, decorative images are not exported as expected anymore.
First of all, when generating HTML from , in v1.19 a <p class="figure"> structure was wrapped around the image, but now it's only a <p>:
<p>
<img src="test.jpg">
</p>
This makes it harder to style in line with other images that have an alternative text.
But what's really a problem here: there's no alt="" attribute produced anymore! This means that e.g. screen readers will not recognise this as a decorative image anymore.
So let's see what happens to an image with an actual alternative text, e.g. when generating HTML from :
<div class="figure">
<img src="test.jpg" alt="">
<p class="caption">Hello</p>
</div>
Here we get a class="figure" in the surrounding element, but now it's a <div> instead of a <p> (I don't bother too much about this, but again, it makes it harder to style everything the same).
What again is a big problem though is the fact that the alt attribute is now set empty: this prevents screen readers from perceiving them at all, which is horribly wrong! I guess that Pandoc concludes that having alternative text and caption would be redundant, which is correct, and that the caption below would be the right thing to show - which it is not.
The right structure would look something like this:
<div class="figure">
<img src="test.jpg" alt="Hello"><!-- Leave the alternative text on the image -->
<p class="caption" aria-hidden="true">Hello</p><!-- Hide the redundant visual alternative text from screen readers -->
</div>
Any reason why this behaviour would make sense? Can it be changed somehow? Otherwise I will have to fiddle around with some post-processing JavaScript...
The  example is no longer treated as a figure, because pandoc now requires that
the image is the only element in a paragraph, and
it has a caption.
Wrapping of figures with <div> happens when exporting to HTML4. Using the latest pandoc 2.9.2.1 and running pandoc -t html5 on the input 
<figure>
<img src="test.jpg" alt="" /><figcaption>Hello</figcaption>
</figure>
The rationale for emitting an empty alt attribute is that screen readers would read the caption twice: first the alt, then the figcaption. Your suggestion seems much better, please open an issue.
If you can't wait for a new release, then use a Lua filter to create figures the way you like:
function Para (p)
if #p.content == 1 and p.content[1].t == "Image" then
local image = p.content[1]
local figure_content = pandoc.List{}
figure_content:insert(image)
figure_content:insert(
pandoc.RawInline('html', '\n<p class=caption aria-hidden="true">'))
figure_content:extend(image.caption)
figure_content:insert(pandoc.RawInline('html', '</p>'))
local attr = pandoc.Attr("", {"figure"})
return pandoc.Div({pandoc.Plain(figure_content)}, attr)
end
end
I asked about this question a few months back, but unfortunately it has not solved my issue, so I am asking it again with more information.
I am using CKeditor 4.4.5
Original Question
I have experimented with the online demo of CKeditor. What works is that the colour is rendered when making the edit in CKeditor, however when one retrieves a content with the coloured span element within it, as it correctly should do, the colour is not rendered in CKeditor. Also it seems that tags are not being stripped out at all. It just seems that CKeditor is not rendering something like :
<textarea class="RTE" cols="20" disabled="True" id="Content" name="Content"
rows="2">
<h1><span style="color:red">I should be coloured red</span></h1>
</textarea>
with:
I should be coloured red
in red.
I have checked for "!important", in relevant CSS, and I cannot see any that would affect this text.
Thoughts on why CKeditor is not respecting the "color" attribute of this "span" element when retrieving/displaying data, rather than initially editing it would be very helpful.
Thanks in advance.
EDIT
Source in "source" view:
<h1><span style="color:red">I should be coloured red</span></h1>
EDIT2
This works:
<p style="color:red">I should be coloured red</p>
EDIT3
This works
<h1 style="color:red">XXX red text XXX</h1>
EDIT4
This does not work:
<p><span style="color:red">XXX red text XXX<</span></p>
It seems I have some code in my CKeditor config which is causing this behaviour, but not sure why. When I comment it out, my colour coding works. Also I have turned ACF off, as I fine all my inline style attributes gets stripped out. So I have altered my config to :
//config.protectedSource.push(/<span[\s\S]*?\>/g); //allows beginning <span> tag - now commented out
//config.protectedSource.push(/<\/span[\s\S]*?\>/g); //allows ending </span> tag - now commented out
config.allowedContent = true; //Added
I've seen this problem touched on in many questions but none have been specific enough to help me. So I hope it offends no one if I simplify it and ask again. Hope springs eternal!
Is it really IMPOSSIBLE to control the width of an image embeded in an email when Outlook renders it? I.e. control the width of an image for which the html code is
<img src="cid:seal">
I.e. when the html code expects an embedded image instead of one stored elsewhere.
[Note: "seal" is the content ID I assigned when creating the MimeBodyPart with the embedded image].
Details:
I use a Javamail application to send a multi-part email message. The body part is an html document. Another MimeBodyPart carries the image used in the html doc. I've simplified the html test to nothing more than a two column table with the left column for the image and the right column for text.
And absolutely NOTHING I have tried has been able to control the size of the image when opened in OUTLOOK.
The image is always what I assume must be some native size for the image ... which is too big ... so it forces the first cell to be more than 15% wide. Or if I give the cell a fixed width the image overflows the box, i.e. get's clipped.
I put the basic code stripped of all font styling colors etc. below.
I have tried every combination of using width attributes and css style properties on the img tag. I've wrapped the image in another table ... or wrapped it in a div block inside the main table cell ... and even wrapped it in a div block inside a table cell inside the parent table cell. And I've tried specifying widths in fixed pixels and %'s.
It would really be nice if we all knew for sure if this is simply IMPOSSIBLE with Outlook.
Or if it is possible possible, to publish sample code that works. [It's hugely attractive to have the email open its images immediately, and not rely on the reader downloading them.]
NOTE: I seem able to control width when I load the image from an outside source afterwards, i.e.
Thanks for any help.
<html>
<head>
<meta name="viewport" content="width=980, initial-scale=1">
<title>Test Email</title>
</head>
<body style="width:100%; border:0;margin:0;padding:0;">
<table align="center"
style="width:980px; border-collapse:collapse;
margin-left:auto; margin-right:auto;">
<tr style="border:0; margin:0; padding:0;">
<td style="width:15%; border:0; margin:0; padding:0;">
<img src="cid:seal"
style="width:6em; height:auto;">
</td>
<td style="width:85%; margin:0; padding:.5em 0em 0em 0em; border:0;">
Some Titles and stuff
</td>
</tr>
<tr>
<td colspan="2" style="border:0; margin:0; padding:1em 1em 0em .5em;">
<p> 1st paragraph
....
<p> last paragraph
</td>
</tr>
</table>
With help from Eugene above, I discovered at least one good solution.
<img src="cid:seal" width="300" or "300px" of "15%"> DOES NOT WORK.
But when I ditched the quotes this worked
<img src="cid:seal" width=300 height=300>
It does of course mean setting width in % is still a problem since it requires quotes.
But I'll take what I can get. Email now pops open with logo without the user needing to download pictures. AND ... this css body selector also works rendering the background with an embedded image. [I stored the background image with a Content ID of"bkg".]
AGAIN ... unlike the img attribute src="cid:id" that uses quotes, url() requires the id w/o quotes.
<body style="background-image:url(cid:bkg);
background-repeat:repeat;
width:100%;
generic-family:Sans-serif;
font-family:Verdana;
border:0;margin:1em 0 1em 0;padding:0;">
Outlook uses Word as an email editor. The following series of articles provides reference documentation related to supported and unsupported HTML elements, attributes, and cascading style sheets properties:
Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 1 of 2)
Word 2007 HTML and CSS Rendering Capabilities in Outlook 2007 (Part 2 of 2)
You can design the page in Word and then save the resulted document as a web page. Thus, you will find the required HTML markup to use.
I have a problem that has taken me days to figure out.
The social follow icons I get from AddThis website appear vertically instead of horizontally. I want to make it appear horizontally but I have found that it is impossible to do so.
Below is the code I got from https://www.addthis.com/get/follow
<!-- AddThis Follow BEGIN -->
<p>Follow Us</p>
<div class="addthis_toolbox addthis_default_style">
<a class="addthis_button_facebook_follow" addthis:userid="TheMostafaAbedi"></a>
<a class="addthis_button_twitter_follow" addthis:userid="theMostafaAbedi"></a>
<a class="addthis_button_google_follow" addthis:userid="106914586115617584077"></a>
</div>
<script type="text/javascript" src="http://s7.addthis.com/js/300/addthis_widget.js#pubid=xa-506a607f490b6601"></script>
<!-- AddThis Follow END -->
The specific page that the problem occurs is http://www.under-review.com/about under Mostafa Abedi description.
You've got line breaks between lines of code, which makes the icons go one below the other. You're most likely using the WordPress editor to insert the code, which alters the formatting.
If you're using Visual editor, switch to HTML editor and give it a try.
If you're using HTML editor, at the very least remove all the spacing between items, making them placed in one line, which would prohibit WordPress from entering new lines, i.e.:
<a class="addthis_button_facebook_follow" addthis:userid="TheMostafaAbedi"></a><a class="addthis_button_twitter_follow" addthis:userid="theMostafaAbedi"></a><a class="addthis_button_google_follow" addthis:userid="106914586115617584077"></a>
From my experience, about 90% of all formatting issues are fixed by good code and as a rule I follow W3C. I suggest you validate against that because at the moment it fails (both the HTML and CSS fails)
http://validator.w3.org/check?verbose=1&uri=http%3A%2F%2Funder-review.com%2Fabout%2F
http://jigsaw.w3.org/css-validator/validator?profile=css21&warning=0&uri=http%3A%2F%2Funder-review.com%2Fabout%2F
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.