Why Drupal adds <br /> tags to markup entered in "Full HTML" view?

jarek - June 27, 2009 - 08:07

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?

Update

jarek - June 27, 2009 - 08:51

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?

No, it is most definitely a feature

Keyz - June 27, 2009 - 09:04

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.

Problem solved

jarek - June 27, 2009 - 09:26

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.

Press enter, get a new line.

dman - June 27, 2009 - 09:53

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.

.

Keyz - June 27, 2009 - 10:04

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.

But no editor with filtered html

Alexei Rayu - June 27, 2009 - 10:36

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.

- Alexei Rayu.

Drupal Related Services | Sitehound Drupal | Worm Catcher Alpha - blacklist needed!

.

jarek - June 27, 2009 - 11:10

@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.

.

Keyz - June 27, 2009 - 12:52

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.

 
 

Drupal is a registered trademark of Dries Buytaert.