-
Notifications
You must be signed in to change notification settings - Fork 3.4k
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
Normalizer seems overzealous when stripping whitespace between elements #149
Comments
+1 |
Just to clarify this is limited to the setHTML call only correct? If you have two words "one two" and bold one and italicize two through the UI the space remains (at least this is the behavior I'm seeing on my Chrome). |
That's correct -- there's no InsertOp entry for the space (since it's pre-stripped), so the HTML is set without it, and getHTML naturally then returns the editor's contents without it. |
+1 |
If I understand the purpose of the whitespace stripping, a more complex RegExp that avoids stripping space between inline elements might work. Instead of this (in Normalize.stripWhitespace): Use this: In that example, there is a negative lookahead which skips any cases that match these tags noted by MDN: https://developer.mozilla.org/en-US/docs/Web/HTML/Inline_elemente#Elements |
I think this issue needs to be re-opened. Unfortunately, simply patching
While these repro steps may seem a bit convoluted (who would apply formatting to just whitespace?), in practice this happens often while editing rich text, especially when the One could probably patch the Perhaps I need to fix this issue on my fork before 1.0 is released. Which path forward would you anticipate would be most compatible with the 1.0 branch? |
Normally HTML dictates consecutive whitespace be collapsed into one. To explicitly display more than one whitespace character you can use HTML entities such as The only issue introduced by this solution is when HTML is written for human readability (including tabs and newlines for nested HTML tags) it's surprising to discover those characters would actually show up. Also copying and pasting the example docs code to try out Quill (which does include nicely indented HTML) is a use case I want to support without the aforementioned surprise. So the quick solution was to get rid of whitespace between tags which is proving to not be such a robust solution. I'm willing to believe a more complex regex could be the solution (which I'll explore for 1.0) but if it's the case that you're saving/loading Quill's content through the API and not with nicely indented HTML in the markup then the best and easiest solution is probably to get rid of stripWhitespace in the editor. |
You can override this behaviour in your application. No need to modify the sources. normalizer = Quill.require('normalizer')
stripWhitespace = normalizer.stripWhitespace
normalizer.stripWhitespace = (html) ->
stripped = stripWhitespace(html)
stripped.replace(/></g, '> <') |
My browser (Chrome 35) doesn't insert
between e.g.<b>foo</b> <i>bar</i>
when I've selected and formatted each word, so the normaliser eats the space when running setHTML(), giving the run-together "foobar" rather than the expected "foo bar".I locally changed what equates to line 117 in src/normalizer.coffee from:
to:
to normalise to a single space and solve my problem, although depending on what else that might be required for, it could make the line redundant due to normal HTML whitespace-collapsing.
Is there another (better) way to solve this, and prevent genuine spaces from being removed, without manually inserting
?The text was updated successfully, but these errors were encountered: