I saw a lot of issues about tags getting stripped from text, but I can't find any solution.

The text I want, and is as such in db, is this:

<div class="socials">
<p>Volg ons</p>
<ul class="social-list">
	<li><a target="_blank" href="https://www.twitter.com/" title="Twitter"><i class="fa fa-twitter"></i></a></li>
	<li><a target="_blank" href="https://www.facebook.com/" title="Facebook"><i class="fa fa-facebook"></i></a></li>
</ul>
</div>

On editing the custom block I get this:

<div class="socials">
<p>Volg ons</p>

<ul class="social-list">
	<li>&nbsp;</li>
	<li>&nbsp;</li>
</ul>
</div>

The used text format is Full HTML. The setting "Limit allowed HTML tags and correct faulty HTML" is off. So I assume no limits in allowed tags.

I hope I can get a working solution here. Thanks in advance.

Comments

capono created an issue. See original summary.

Wim Leers’s picture

Title: tags get stripped from body » Tags are stripped even with "Full HTML" (i.e. without ACF)
Assigned: Unassigned » mlewand
Issue summary: View changes

Hm… reproduced (but with a slightly different result, I'm assuming you just had a copy/paste error). Bizarre. This looks like a CKEditor bug.

Wim Leers’s picture

Title: Tags are stripped even with "Full HTML" (i.e. without ACF) » [upstream] Tags are stripped even with "Full HTML" (i.e. without ACF)
Issue tags: +Needs upstream bugfix
Wim Leers’s picture

Pinged the CKEditor folks about this.

Tade0’s picture

In most cases this problem can be solved by manipulating the Document Type Definition:
http://docs.ckeditor.com/#!/api/CKEDITOR.dtd-property-S-removeEmpty

If the content is a single, empty paragraph(or block element) CKEditor by default removes it. To disable this set the ignoreAutoParagraph config option to false.
http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-ignoreEmptyParagraph

Wim Leers’s picture

In most cases this problem can be solved by manipulating the Document Type Definition:
http://docs.ckeditor.com/#!/api/CKEDITOR.dtd-property-S-removeEmpty

In other words, in the case of <i>, this is technically invalid. Right?

If the content is a single, empty paragraph(or block element) CKEditor by default removes it. To disable this set the ignoreAutoParagraph config option to false.
http://docs.ckeditor.com/#!/api/CKEDITOR.config-cfg-ignoreEmptyParagraph

This is for the case of <div data-something></div> or <custom-element data-something />, right?

Tade0’s picture

In other words, in the case of , this is technically invalid. Right?

This is still valid HTML, but note how in this example you cannot place the selection at any of the bullet points.

This is for the case of <div data-something></div> or <custom-element data-something />, right?

Here's a list of tags that are removed this way: p,div,address,center,pre,h1,h2,h3,h4,h5,h6. <custom-element></custom-element> won't be removed by the DTD nor detected as an empty paragraph for removal.

Wim Leers’s picture

<custom-element></custom-element> won’t be removed by the DTD nor detected as an empty paragraph for removal.

Try it at http://ckeditor.com/demo#full: paste <custom-element></custom-element> while in source mode, switch to non-source mode, switch back. It's gone.

Tade0’s picture

That's right because in this example the ACF is enabled and filters out any non explicitly allowed content.

With the filter disabled the expected result is that if you have a <custom-element></custom-element> in the source it's going to get wrapped in a paragraph like this:

<p><custom-element></custom-element></p>
Wim Leers’s picture

Title: [upstream] Tags are stripped even with "Full HTML" (i.e. without ACF) » <i> tags without content are stripped by CKEditor even with "Full HTML" (i.e. without ACF)
Category: Bug report » Support request
Status: Active » Fixed
Issue tags: -Needs upstream bugfix

You're right, I confused two things. I'm sorry.

So, to go back to the original issue: to prevent <i class="fa fa-twitter"></i> from being stripped, Drupal would have to modify the DTD. But really, the problem is that it's questionable HTML. Let's look at https://developer.mozilla.org/en-US/docs/Web/HTML/Element/i:

The HTML Element represents a range of text that is set off from the normal text for some reason, for example, technical terms, foreign language phrases, or fictional character thoughts. It is typically displayed in italic type.

In the example given in the issue summary, there is no text range. So, the problem is wholly on the content author's side.

Conclusion + recommendation

DON'T
<i class="fa fa-twitter"></i>
DO
<i class="fa fa-twitter">Twitter</i>

You already have CSS to ensure that i.fa-twitter shows an icon. Just make that CSS hide the text too. Then you'll be fine.

Wim Leers’s picture

Assigned: mlewand » Unassigned
HansKuiters’s picture

I agree with the conclusion and recommendation.

For future reference: changing the CSS like the commonly used {text-indent: -9999px;} should do the job.

Thanks Wim Leers and Tade0 for the effort in this.

Tade0’s picture

I also agree with the conclusion and recommendation.

I found something interesting regarding this ticket:
http://fontawesome.io/icon/twitter/

Looking at the styles it seems that the fa class turns the display of the element to inline-block.

I guess the idea here was to have an icon that would fallback to a dimensionless element. I don't see why the mere fact that the stylesheet is unavailable should make it impossible to click that link, so for me it makes sense to put some fallback text there and hide it using CSS.

Wim Leers’s picture

Awesome, everybody happy :)

wmad’s picture

Thanks for the hint guys. I wish we could make this more visible for the folks that want to use fontawesome. It took me a while to find this post and solve my issue. Perhaps in documentation so that it's easily found upon googling?

HansKuiters’s picture

Well, 'awesome' is mentioned a few times now at this page now, so search engines will pick it up in the right context I guess.

Wim Leers’s picture

I wish we could make this more visible for the folks that want to use fontawesome.

Or better yet, work with those projects that use incorrect HTML to fix their HTML.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.