Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dash types different in front-end and back-end output. #12860

danielmcclure opened this issue Dec 13, 2018 · 3 comments

Dash types different in front-end and back-end output. #12860

danielmcclure opened this issue Dec 13, 2018 · 3 comments


Copy link

@danielmcclure danielmcclure commented Dec 13, 2018

Describe the bug
Typing - – — on the backend shows three different lengths, but on the front end, the first two appear as equal length characters. Using HTML entities seems to create different types of dashes again.

To Reproduce
Steps to reproduce the behavior:

  1. Go to post editor and type - -⎇ -⎇ ⇧ - into a paragraph block.
  2. Type ‐ – — ― into a Custom HTML block.
  3. View difference between front end and back end.

Expected behavior
Described above and below.

It seems as if maybe Gutenberg converts manually typed dashes and em dashes into en-dashes? The list below shows the steps I took and the code output below was copied from the front end page on brand new installation using WP 5.0.1 and 2019 Theme.

  • In the first line I manually typed - – — into a paragraph block (which the editor also tried to turn into a list block)
  • In the second line I used ‐ – — ―
<div class="entry-content">	
Manual Typing (first two characters appear to become the same):
– – —
HTML Entities 
‐ – — ―

Desktop (please complete the following information):

  • OS: MacOS
  • Browser: Chrome / Firefox
Copy link

@swissspidy swissspidy commented Dec 13, 2018

WordPress has a function called wptexturize() which converts dashes like that on the front end. This has been around since the beginning of WordPress. At the same time, the dashes and quotes are never touched in the editor.

So I don't see any regression nor any unexpected behavior here.

Copy link

@danielmcclure danielmcclure commented Dec 14, 2018

Ah, this must just be the first time I've noticed that particular quirk.

If we are really going for WYSIWYG then I'd prefer retaining what is typed, but if it is filtered on the front then shouldn't it be filtered on the back-end rendering as well for an accurate preview?

Copy link

@ellatrix ellatrix commented Jan 29, 2019

See also #13240. We could do this directly in rich text, but it's low priority atm. Closing because the issue exists since a long time in core. Perhaps better to report at

@ellatrix ellatrix closed this Jan 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants