CKeditor does not seem to be rendering the correct text colour when retrieving data? - ckeditor

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

Related

Pandoc 2.x renders images' alternative texts in an inaccessible fashion

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 ![](test.jpg), 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 ![Hello](test.jpg):
<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 ![](test.jpg) 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 ![Hello](test.jpg)
<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

HTML in vuetify hints

Previously (I thought?) it was possible to put HTML into vuetify hints but for me this is no longer working. For example, in one of my components I have:
<v-checkbox
v-model="create"
label="Nice label"
persistent-hint
hint="<span class="red--text">Red hint</span>"
/>
This hint used to display in red but now I see the full HTML code. Has something changed or am I doing something wrong?
In the Vuetify forum, MajesticPotatoe pointed me towards the bug report https://github.com/vuetifyjs/vuetify/issues/9647. This gave the following slots workaround, which works in my code:
<v-checkbox
v-model="create"
label="Nice label"
persistent-hint
hint="<span class="red--text">Red hint</span>"
>
<template v-slot:message="{ message, key }">
<span v-html="message"></span>
</template>
</v-checkbox>
It seems that this used to work without slots before the patch https://github.com/haggys22/vuetify/commit/f0d5edd7ddf7e01ba057b7f3d14604199b6db68d was merged.
behaviour changed from 1.5.19 to 1.5.20
1.5.19 (and before) treats html tags as expected
1.5.20, 1.5.21 treat html tags as simple text
'hint' is the 'string' type so you can't add HTML tags. Here is the screenshot from documentation: https://prnt.sc/qlag61
So, I think you can apply red color from CSS / SCSS using this class name '.v-messages__message' if you really need red color in hint.

CKEditor unable to override styles on non-span tags?

I am trying to use CKEditor to edit some html created with a different tool (Quill) that has a different opinion on which tags one should place style attributes.
For example:
<p>
<strong style="color: rgb(230, 0, 0);">TEST</strong>
</p>
When one tries to use CKEditor (standalone V4.6) to change the color of this line of text one gets the following (which doesn't work due to the new color being overridden by the old color)
<p>
<span style="color:#00ffff;">
<strong style="color: rgb(230, 0, 0);">TEST</strong>
</span>
</p>
It seems obvious that any inner tags should get their color style removed when the color is set but I have been unable to find a way to configure CKEditor to do that. It seems like a bug that it doesn't. Is there any way to get CKEditor to do this? (this applies to all style properties, not just color)
If not, is there a way to get CKEditor to normalize the html on load so that all styles are extracted out to spans?

CKEditor moving br tags

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

IE8 shows empty line after floating elements in contenteditable

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.

Resources