Make WordPress Core

Opened 19 years ago

Closed 19 years ago

#4716 closed defect (bug) (duplicate)

<br /> tags added in inconsitent way

Reported by: hakre Owned by:
Priority: normal Milestone:
Component: General Version: 2.2.2
Severity: normal Keywords:
Cc: Focuses:

Description

WARNING

Related to WP 2.2.2 but this version number could not be selected while submitting the ticket in Trac.

Maybe a classic defect in WP since ages but this is a very specific thing in the process applied on Page and Post Source.

source:

<label>...</label>
<input ... />

is the same in output html source.

source:

<label>...</label><input ... />

differs in output html source:

<label>...</label>
<br/>
<input ... />

this is nothing in specific maybe but compare it with a combination of <label> and <textarea>. there it is the other way round:

source:

<label>...</label>
<textarea> ... </textare>

will become in output html source:

<label>...</label>
<br/>
<textarea> ... </textare>

and source:

<label>...</label><textarea> ... </textare>

is the same in output html source.

so you can see that it is exactly the other way round. this is an inconsitency that leads to confusion for Authros and Developers.

Change History (3)

#1 follow-up: @Otto42
19 years ago

  • Resolutionwontfix
  • Status newclosed
  • Version 2.2

You're seeing the effects of the autop filtering, which happens at page display time and not at post creation time. Carriage returns become br tags. Double carriage returns become P tags.

There's many plugins to disable autop if you don't want to use it. Use one of them.

#2 in reply to: ↑ 1 @hakre
19 years ago

  • Resolution wontfix
  • Status closedreopened

Replying to Otto42:

You're seeing the effects of the autop filtering, which happens at page display time and not at post creation time. Carriage returns become br tags. Double carriage returns become P tags.

I'll ignore the fact that it's quite useless to install a plugin to circumvent not working code. IGNORE.

I can not confirm what you state here. If a \n or \r creates a <br/> well that's fine. And that's not the problem I was talking about. I was talking about the fact that applying <br/> elements is done in an inconsistent way.

As you can see in my example <br/> elements are added in places where no \r or \n characters in the source exist. By source I mean the text typed in into the editor in the wordpress admin. That's the text that is written in the database. output html source is meant the rendered html that is send to the browser. this only for clarification.

back to your argument that \r and \n will be converted to <br/>s. let's take my example:

source:

<label>...</label><input ... />

will become the following output html source:

<label>...</label>
<br/>
<input ... />

If wordpress's autop would work the way you described, there should be no <br/>.

you can add as many <br/>s as you like but it should be done in anycase the same way. not <br/> in one and nothing in another line. or popping up <br/>s out of nowhere. I repopened the bug therefore because what you wrote ignores the facts I was reporting.

#3 @hakre
19 years ago

  • Resolutionduplicate
  • Status reopenedclosed
  • Version2.2.2

Added a patch in Ticket #4605 that solves this problem as well. There might exist more faults in the code that lead to similar results with other xhtml elements or html tags combinations but until then I close this ticket because it looks like it is a duplicate in this specific combination with <input> elements/tags.

Note: See TracTickets for help on using tickets.