Posted by Jarek Foksa on

I have created a custom block which contains the following markup:

<dl id="links">

  <dt class="first">Users</dt>
  <dd class="first">
    <a href="">About</a>
    <a href="">News</a>
    <a href="">Download</a>
    <a href="">Screenshots</a>
    <a href="">Support forum</a>
    <a href="">FAQ</a>
    <a href="">Feature requests</a>
  </dd>

</dl>

Unfortunately, Firebug shows that generated markup is a bit different: 

<dl id="links">

  <dt class="first">Users</dt>
  <dd class="first">
    <a href="">About</a><br />
    <a href="">News</a><br />
    <a href="">Download</a><br />
    <a href="">Screenshots</a><br />
    <a href="">Support forum</a><br />
    <a href="">FAQ</a><br />
    <a href="">Feature requests</a><br />
  </dd>

</dl>

1. Why Drupal is inserting line breaks even if the input format for block is set to "Full HTML"?
2. Apart from entering the whole markup without pressing enter at the end of line, how can I stop Drupal from generating those non-semantic tags?

⋅ Categories: Drupal 6.x

Comments

Jarek Foksa’s picture

Jarek Foksa commented

I have checked the documentation and this appears to be "a feature":

# Full HTML:

    * Web page addresses and e-mail addresses turn into links automatically.
    * Lines and paragraphs are automatically recognized. The <br /> line break, <p> paragraph and </p> close paragraph tags are inserted automatically. If paragraphs are not recognized simply add a couple blank lines.

What are the reasons for using line breaks all over the place instead of semantic code? Should I report this behavior as a bug?

dnewkerk’s picture

dnewkerk commented

No, it is most definitely a feature. If you do not want it, simply disable the "Line break converter" filter at admin/settings/filters/2

This filter is what makes it possible for me to type the sentence I am currently typing, appearing as a separate paragraph, without using HTML.

Once you change the filters you may need to clear the cache at Site configuration > Performance.

Jarek Foksa’s picture

Jarek Foksa commented

Thanks Keyz, disabling "Line break converter" in filters section solved my problem. But I still think it's confusing behavior, I expected "Full HTML" mode to be equal to "Plain HTML" mode from other editors. <br /> tag should not be used to separate paragraphs in most (all?) cases, we have <p> tag and margin/padding CSS properties for that.

dman’s picture

dman commented

It's there to help the majority of people who want to enter a newline in the textarea and get a newline. Without it, everyone everywhere would be getting all their text in one solid block. impossible to read.
People don't like that. Nor should they need to enter p tags by hand either (unless, like you, they choose to). It's a feature.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

dnewkerk’s picture

dnewkerk commented

Well, as you can see, it does act correctly as a break versus as paragraph (single line break inserts <br /> and adding an additional line makes it behave as a paragraph). This is how Drupal has worked for many years, and I doubt this aspect will change (many people really like it, including myself). For average daily writing in Drupal I (and many others) find this much more preferable over writing those extra tags. I simply keep in mind that they will be inserted when the page is rendered, and this keeps my content editing process cleaner and simpler. I also keep most of my more "intricate" HTML in my template files, and tend to only use basic formatting in the content itself, and sometimes lists, links, etc. I like to use BUEditor to simplify this on my own site (it is an HTML tag inserting editor, not wysiwyg, which you can customize to add any kind of tags you want). Other people choose to use a full wysiwyg editor, and with those the documentation often advises you to disable the Line break filter, as the editor may insert those tags automatically as well. The "average" Drupal user actually wants an optional "full wysiwyg editor" in core, not more HTML to write ;)

Though the presence of the Line break filter won't likely change, what can change in Drupal is the help text or other indications of what is happening. For that, if you have specific ideas on the issue and how to make it better, you should submit them to the Drupal 7 issue queue (it is not too late for suggestions to make it into the next version). For instance, perhaps you might suggest that if the administrator is logged in (not regular users since you wouldn't want to show them such things), some extra help text is shown in the input formats help text, directing them to where they can configure the input formats (and best practices for doing so). It will help most if you give some concrete ideas about what you think it ought to say that would have made it clear to you.

In Drupal, the best practice is to use Filtered HTML for all users other than yourself or other high privileged users ("not" visitors or regular users). Full HTML can easily be abused to break (or even hack) your site (given access to every possible tag, there are a variety which a malicious user can use for unfriendly purposes). You should simply add any HTML tags you do need generally available to the filtered HTML list (of course only allowing those you are sure will be safe), or you can make your own Input Formats as well if you'd like. Personally I do not even give Full HTML to the user accounts I set up for clients to use on their own sites (unless they specifically want it) as I try to protect them from breaking their own site... often the first thing they do otherwise is paste in some craaaazy code that borks the whole page, or perhaps directly embed flash or videos instead of using the specific fields I made for them to do those tasks with.

Hope this helps.

alexrayu’s picture

alexrayu commented

Filtered html is great but if you makr a web site for a client who will want to use FCKEditor and such with full potential, it will have to be "full html

Yes, the break line converter can be a real nuisance.

Jarek Foksa’s picture

Jarek Foksa commented

@Keyz Note that I'm refering to "Full HTML" mode. I agree that it could make sense in "Plain HTML" mode or in simple WYSIWYG editor, but I don't get it why Drupal assumes that user who has chosen to use full HTML mode can't even mark up properly a bunch of paragraphs or definition lists.

As you mentioned, "Full HTML" editor mode is used mostly by admins to code special pages and blocks, not users who create content. I was suprised to find out that the markup I typed manually as a plain text was obscured by Drupal with unnecessary line breaks.

So I'm just suggesting that default filters settings for "Full HTML" mode should be less intrusive.

dnewkerk’s picture

dnewkerk commented

The distinction is that "Full HTML" is not "Plain HTML". Full HTML refers to the point that "all" HTML tags are permitted, but not that it has no input filters that might still run on the content. It means that the restriction on HTML tags is lifted, but nothing more. To disable Line break filter by default in Full HTML and not in Filtered HTML would actually cause issues for those who expect the behavior of the Line break filter. For instance I may make all my content Filtered HTML and then on a particular custom block decide to use Full HTML. When I do this I expect the same behavior as when I use Filtered HTML, only I will have access to the tags that were otherwise restricted. So in this case I used Full HTML format to get access to all HTML tags, not to "write plain HTML".

If you want to make a new input format called "Plain HTML" configured the same as "Full HTML" but without the Line break filter, then feel free. This will give you the behavior you are looking for, and the ability to use either input format as appropriate.

And again, if you feel the help text could be improved, please submit an issue for Drupal 7.

richardburden’s picture

richardburden commented

I navigated to Administer>Site configuration>Input Formats, selected "configure" to the right of "Full HTML", and unchecked the box labeled "Line break converter", and saved the configuration. Still, if the rich text mode is used, paragraph and br tags inserted. For example, if my default editing mode is plain HTML, and I enter some HTML code with linebreaks in it but no p or br tags, then switch to rich text mode, the line breaks disappear, but then when I return to the plain HTML mode, the code will be enclosed in a paragraph tag.

dman’s picture

dman commented

That's WYSIWYG editors for you.
All of them will do that to some extent.
I don't think you will find a way around it in any platform or tool.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

AntonLargiader’s picture

AntonLargiader commented

I have the same thing, but there isn't even a line break in the code. I have <table><col />...<col /><tbody> and the filter is adding a line break before the <tbody> tag. Disabling the filter fixes it (that line break kills the validation!) but for regular purposes the filter is useful. In this case it's just doing something really pointless and unexpected.

I've verified that there is no line break there. At least, I've looked at the database and there is no character between the two tags. And when I look at it in the WYSIWGY editor (ckeditor) the tags are all in a single stream. All indications are that the DB code is clean but the line break is just being inserted there upon output. It happens on every page that has this table structure.

Is there any kind of configuration for that filter, or is there a better one?

egtalbot’s picture

egtalbot commented

I haven't tried changing the filter, as I just stumbled on the thread, so I will do that. But no line breaks on my screen, it's just a piece of text next to a
tag inside a table and it's adding a BR in between the two (confirmed by Firebug). This doesn't seem logical.

On a general level, reading the comments, I understand completely why default behavior is the way it is. It's the most logical thing given the various different options that drupal provides. However, I will say that the HTML editor changing my HTML (it goes far beyond the BR tags) is the single most annoying thing about drupal for me. I really would love the ability to have the option to enter HTML with absolutely no change to what I type on the screen. I only spend a fairly small amount of time working with drupal and a large amount of time with other sites written from scratch, so every time I have to do something outside of drupal's defaults, I run into a costly learning curve. For the most part, I can accept that tradeoff, but there are few things more infuriating to a developer than HTML editors that assume you didn't mean what you typed.

eNG1Ne’s picture

eNG1Ne commented

I've been brought in to tidy up content in a Drupal site, and I too am running into problems with how <br/> is being handled. Pages are made up of a Body section and an Efforts section. In a Body section, I can correctly add a comment beneath a list item with

<li>list item<br/>
comment</li>

and have it render with the expected line break when I go back to viewing the site. The selfsame code in the Efforts discards the break.
So, what do I need to ask the administrator to do? Just ask if you need more information from me to help you first.
Thanks in advance.

dman’s picture

dman commented

What you are getting is the opposite of the original post here. Perhaps this would have been better as a new issue.
The first poster was getting line breaks on the displayed output when they'd put new lines in the input, and didn't like that behavior.

It sounds like you are getting your line breaks taken away? I don't think there are any normal settings that would do that. It's possible that a strange input filter (filtered html that restricts the tags you are allowed to use) could remove it, but that would be a strange configuration for someone to do.
If the two textareas are using the same input format (did you check that?), but you are getting different output - it must be something custom? Perhaps someone messes with the test in the theme before displaying it. That would be bad and annoying, but not uncommon.

.dan. is the New Zealand Drupal Developer working on Government Web Standards

eNG1Ne’s picture

eNG1Ne commented

You're right … turns out there is an "input format" switch between full HTML and filtered HTML. Now I've discovered that, I'm making steady progress updating pages to display what I've asked them to

pfeldman’s picture

pfeldman commented

"simply disable the Line break converter filter at admin/settings/filters/2"

Easier said than done. So far, I haven't figured out how to access this.

BrightBold’s picture

BrightBold commented

If you're using Drupal 7, the path will be admin/config/content/formats/filtered_html (or replace "filtered_html" with the name of the text format you want to edit).

stevenorr_ca’s picture

stevenorr_ca commented

If someone is still confused, I have just answered this question on another article:
https://www.drupal.org/node/689908#comment-10011347

I provided the full path and comments on the other options found there, as well. IMO, if a person has access to the Full HTML text format then they are trusted to know what they are doing and their content shouldn't be manipulated, after the submission.

Asheem.Mehrotra’s picture

Asheem.Mehrotra commented

Go to configuration tab -- text formats -- configure the full html option -- in enable filters field disable the Convert line breaks into HTML option.

I think it will work.

nitin.k’s picture

nitin.k commented

CK editor seems to be inserting line breaks after saving the content.
Please look this thread.

Thank you.

chris_rtt’s picture

chris_rtt commented

For me, the problem was that the visual editor automatically inserts newline + tab after every <br>. I guess that's the behavior that should *really* be turned off. Silly editor, stop changing my code.

But anyway, the settings link provided above has changed. Now you can find this setting in:
admin/config/content/formats/full_html