Make WordPress Core

Opened 11 years ago

Closed 10 years ago

Last modified 10 years ago

#23185 closed defect (bug) (fixed)

Hyphens surrounded by non-breaking spaces are not texturized

Reported by: redsweater's profile redsweater Owned by: wonderboymusic's profile wonderboymusic
Milestone: 4.0 Priority: normal
Severity: normal Version: 2.8
Component: Formatting Keywords: has-patch wptexturize 4.0-early
Focuses: Cc:

Description (last modified by SergeyBiryukov)

Thanks to Ticket #8161, a single hyphen or double hyphen surounded by space is converted to an en-dash or em-dash, respectively.

The problem is this conversion doesn't take place as expected when the space immediately before or after the affected hypehns is a non-breaking space.

Example paste the following into a post as HTML and view it in a browser after texturization:

Line 1&nbsp;-&nbsp;Non-breaking spaces around the hyphen.<br>
Line 2 - Regular spaces around the hyphen.<br>
Line 3&nbsp;- Non-breaking space before the hyphen.<br>
Line 4 --&nbsp;Non-breaking space after the double-hyphen.<br>
Line 5 -- Regular spaces around the double-hyphen.

Only the lines where "Regular spaces" are around the hyphens get converted as expected.Lines 1, 3, and 4 are not converted to match their regular-space counterparts.

It's reasonable to use non-breaking spaces in web content and I think that for situations where a non-breaking space is used it should imply the same kind of texturization for the hyphens as a regular space does.

The attached patch removes the static replacement rules for hyphens and adds dynamic rules to meet this expectation. I had to add a dynamic rule '--' to prevent it being prematurely converted in the static phase, when it was surrounded by appropriate spacing. Since I havd to move that one from static to dynamic, it made sense to me to just have all the hyphen-conversion behavior in one place in dynamic.

Attachments (3)

FixHyphens.diff (1.4 KB) - added by redsweater 11 years ago.
FixHyphens-Tests.diff (1.1 KB) - added by redsweater 11 years ago.
Patch to wp-tests to confirm fix applied by FixHyphens.diff
miqro-23185.patch (2.9 KB) - added by miqrogroove 10 years ago.

Download all attachments as: .zip

Change History (16)

#1 @redsweater
11 years ago

Note: I will come up with a unit testing case for this and attach it ASAP.

11 years ago

Patch to wp-tests to confirm fix applied by FixHyphens.diff

#2 @redsweater
11 years ago

  • Keywords has-patch added

#3 @pavelevap
11 years ago

  • Cc pavelevap@… added

Yes, I noticed the same thing: #16957 (point 2).

#4 @SergeyBiryukov
11 years ago

In 1185/tests:

wptexturize() test for non-breaking spaces around hyphens. props redsweater. see #23185.

#5 @SergeyBiryukov
11 years ago

  • Description modified (diff)
  • Version changed from trunk to 2.8

#6 @nacin
10 years ago

  • Milestone changed from Awaiting Review to 3.9

Seems good. Should we also handle &#160;?

#7 @nacin
10 years ago

  • Keywords wptexturize added

#8 @miqrogroove
10 years ago

This will need to be refreshed after #22692 because the editor currently does not save nbsp as an HTML entity.

#9 @nacin
10 years ago

  • Keywords 4.0-early added
  • Milestone changed from 3.9 to Future Release

The editor isn't going to save nbsp as an HTML entity until at least 4.0. See #26842. Also, with #22692 moving forward (and doing a big rewrite here), I'm pushing this to 4.0.

#10 @miqrogroove
10 years ago

In miqro-23185.patch:

  • The two new regexp patterns allow both &nbsp; and UTF-8 nbsp.
  • The one pattern without spaces will never match "xn--".
  • Input containing "xn&#8211;" is no longer converted to "xn--".
  • Unit tests updated.

#11 @wonderboymusic
10 years ago

  • Owner set to wonderboymusic
  • Resolution set to fixed
  • Status changed from new to closed

In 28718:

In wptexturize(), treat &nbsp; like whitespace when texturizing hyphens.

Adds unit tests.

Props redsweater, miqrogroove.
Fixes #23185.

#12 @SergeyBiryukov
10 years ago

  • Milestone changed from Future Release to 4.0

#13 @miqrogroove
10 years ago

#29142 was marked as a duplicate.

Note: See TracTickets for help on using tickets.