WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 7 years ago

#4716 closed defect (bug) (duplicate)

<br /> tags added in inconsitent way

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

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)

comment:1 follow-up: Otto427 years ago

  • Resolution set to wontfix
  • Status changed from new to closed
  • Version 2.2 deleted

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.

comment:2 in reply to: ↑ 1 hakre7 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

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.

comment:3 hakre7 years ago

  • Resolution set to duplicate
  • Status changed from reopened to closed
  • Version set to 2.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.