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 · 2 comments


None yet
3 participants
Copy link

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

This comment has been minimized.

Copy link

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.

@swissspidy swissspidy added the Feedback label Dec 13, 2018


This comment has been minimized.

Copy link

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment