Paragraphs are <br>s about wysihtml5

[tiff]

Thanks for your opinion and time. As already said: feel free to contribute. Just hit the "fork" button above ✌️

[tiff]

Hello Oscar,

Can you please elaborate on this?
How are you inserting paragraphs in wysihtml5? Which browser is affected?

Please be aware that wysihtml5 intentionally inserts <br> when the user hits the enter key.
This is what I think people, who are used to textareas, would expect.

Thanks.

[OscarGodson]

It's not a textarea tho. Nearly all WYSIWYG editors including the most popular tinyMCE create a hard return on enter and a soft return on shift+enter (p should be created on hard return, br on soft) hence the name WYSIWYG. A hard return means a new paragraph. Textareas don't act this way because it's supposed to be raw text. I think its more confusing to have a WYSIWYG act like a textarea and terribly hard to style after the HTML is generated with brs instead or ps

You're never taught to or see (I hope) whole articles with no p tags :)

I'm on Chrome 17

Commented on an iPhone so sorry in advance for misspellings or falty auto corrects :)

[tiff]

Hey Oscar,

sorry to disappoint you but imho creating soft line breaks when the user hits enter is best for the average internet user in terms of usability.
If a user explicitly wants to insert a paragraph then he should use the corresponding toolbar button.

However I agree with you that from a technical view it's much easier to insert a paragraph.
Feel free to fork the project and add an option parameter which toggles between paragraphs and line breaks. I'd be happy to merge that.

Thanks!

[OscarGodson]

Usability? You really think the average internet user even knows what a <br> and <p> is or the issues that will arise when you try to style it, SEO, or the semantics?

If you're going to keep the soft returns, that's fine, but for the love of god create a <p> when there are two <br>s together because that's what the user is expecting. This is how Blogger acts for example. Don't have some major blogging service add this as their editor and have hundreds of thousands of articles with not a single <p>.

Trust me, not a single user in the wild will click a button every time he wants to make a <p>. I was the lead engineer for Portland, OR's official site and we did the same thing and we ended up with over 300k pages with not a single paragraph. When we did a redesign a couple years ago it was impossible to restyle the <p> spacing since they didn't exist. It was also an ugly pile of markup soup of <br><br><br> even sometimes because they wanted to add "more spacing". I've left and they're still restyling all the pages and haven't launched the redesign and are having to reteach all the users how to use the editor.

If it's usability that's your concern, great, but remember the user expects he's making a new paragraph when he hits enter twice.

[andybak]

Out of interest - MS Word now defaults to a paragraph break on Enter instead of a linebreak. My users had no trouble learning the distinction.

(side-note: this behaviour being hard-coded was a deal breaker for me. The distinction between linebreaks and paragraphs is essential and I can't style user-content correctly without it)

[OscarGodson]

@andybak Yep. I moved over the City of Portland (the local government offices) without any issue as well. shift+enter took about 1 min of just sending out a notification that "hey, you press shift+enter now".

[tiff]

Please don't see wysihtml5 as a Microsoft Word for the web. It's rather a lightweight library that enhances how users interact with textarea's.
However as more and more people are requesting this feature I might consider this for wysihtml5 0.4.
Thanks for your feedback.

[micho]

For reference, Markdown considers a linebreak like this a <br>:

asdasd
asdasd

However, having a blank line makes them behave as <p>:

asdasd

asdasd

[hcarvalhoalves]

There's also the option of inserting <br/> the first time the user hits return, and a <p> for another consecutive return. I don't know how hard that would be to implement, thought, since you would have to go back and forth.

That said, a return means a paragraph break, not a new line. @OscarGodson is correct at his reasoning that the default generates bad markup.

[zacstewart]

+1 for paragraphs on return.

[pcardoso]

Like above, +1 for paragraphs on return, breaks on shift-return.

[Lail]

+1

[Lail]

+1 Please do consider creating an option to change the current behavior. I appreciate the impulse to not bloat the feature set, but for many applications this is essential behavior.

[tiff]

Okay got it :)
Here's what I can offer you until this option is available for wysihtml5:

Either add a link to the toolbar and let users insert paragraphs manually:

<a data-wysihtml5-command="formatBlock" data-wysihtml5-command-value="P">insert paragraph</a>

Or set wysihtml5.quirks.insertLineBreakOnReturn to an empty function before initializing the editor (this will enable native browser behavior, which is different across browsers)

[Neener54]

I have to say that one of the reasons why I chose wysihtml5 over tinymce or ckeditor is actually because of the br feature. Inserting a p on enter was causing a lot of headaches. The double enter for p doesn't sound bad though.

[Lail]

@Neener54 There are probably use cases for both, that's why I like the idea of making it configurable (not to mention it would avoid the problem of "breaking" the behavior of older installs).

@tiff Thanks for reconsidering and for the suggestions. Great work with this.

[Neener54]

@Lail Yeah, after talking it out with a colleague and doing some testing in word I actually think the p tag will cause less user frustration. So while I personally like the br tag implementation long-term I'll probably get more mileage out of a p tag.

[OscarGodson]

@Neener54 Curious, what were the issues?

[shankarcabus]

+1 <p>lease!
Since we're talking about html5, we can not forget the semantics. Paragraph is more semantic!

[Neener54]

@OscarGodson The issues we were having is our writers abusing the system and we'd end up with some awful nested p tags or "empty" p tags. That being said I'm not sure the br tag will fix our issue either.

[OscarGodson]

@Neener54 A good WYSIWYG should fix both of those. It shouldn't allow you to make invalid markup like nested p tags and also not use empty ones.

[Neener54]

Funny story, was going along my happy way when suddenly not having the p tags has become a major issue for something I'm doing. I change my vote to p tags.

[OscarGodson]

@Neener54 ha, probably trying to style spacing or something?

[Neener54]

I've actually forked the project so I can try and get this feature implemented. I'm not so good at javascript-foo although it appears fairly straight forward. Compiled though there are 9k lines of unminified code. So if anyone can point me in the right direction that would help.

[Charuru]

<br> for god's sake!

[DouweM]

How's the work on this going? I would love an option to use <p>'s for double enters.

[Neener54]

Well, on the fork that I created I've managed to to get this working for the most part. You assign which time of break element you want (defaults to br) and it'll use that for all instances. Unfortunately, right now it's breaking on divs and I have no idea why. But I've tested it for other block level elements and it was functioning pretty well. On divs it's requiring two enters to create the next line.

[tiff]

I'm currently busy getting a stable wysihtml5 0.3 out. This featured is scheduled for version 0.4.

However I already found some interesting work in some forks concerning this.
See: https://github.com/snookca/wysihtml5/ and/or https://github.com/Neener54/wysihtml5

[DouweM]

Okay, cool, I'll check both of those out!

[andymason]

Great news that <p>'s are going to enabled on enter. One interesting issue I've run into before is when sanitizing pasted content. What happened when naked text nodes are pasted in, do you automatically wrap them or leave that up to the user?

[OscarGodson]

@andymason I've always just wrapped double breaked lines in <p> and single's in <br>. So if a user pasted in:

Paragraph 1


P2

line break on P2

They get:

<p>Paragraph 1</p>
<p>P2<br>line break on P2</p>

[DouweM]

What @OscarGodson described is exactly what I'm looking for in Wysihyml5, but unfortunately it seems that neither @snookca's nor @Neener54's fork supports that as of yet. Does anyone happen to be actively looking into that?

[OscarGodson]

@DouweM Yes, @tiff is working it into 0.4 he said :)

[DouweM]

@OscarGodson I got that he was working on it, not that he was actually planning to make it so that single return => <br>; double return => <p>. ;-)

[OscarGodson]

@DouweM well, I hope thats what @tiff means since that was the original ticket :)

[Neener54]

@DouweM when I forked it I mostly wanted the enter behavior to be customizeable, later today I'll be pushing my changes to my fork and you can check it out yourself. Essentially what it gives you is another config option for which block element to use. By default it will use the br, but you can really set it to almost any block-level element if you want. That being said, divs are still acting a bit goofy for some reason. I don't know how much of that Tiff would want to add into the main repo though.

[andymason]

It's a none trivial task, for example: currently when you change from a list to a non-list you go from a <ul><li>test</li></ul> to test, whereas with <p>'s you'd have to catch that change and wrap the textnode in a <p>.

Also, I'm currently using a hack while evaluating the tool to get the first click in the editor to be inside a <p>:

this.observe("focus:composer", function() {
        if(this.textareaElement.value === '') {
            var self = this;
            setTimeout(function() {
                self.composer.selection.surround(document.createElement('p'));
            }, 10);
        }
      });

[Neener54]

So if you look at my fork I've actually managed to solve this with fairly little modification to the system. You define which element you want for your breaks, defaults to br. I now have it working for divs (had to throw in an explicit br). I debated on whether it should force a tag around the next line or if it should wait until you hit enter. I'm not sure which one will give a better experience to the user. For now it won't format the last line unless you hit enter again. it is working though.

[Neener54]

After thinking about it I like that it formats all the elements so it will format the last element without a break. I also got the divs working.

[robwierzbowski]

Thanks for putting work in on this. Using <br>s instead of paragraphs is the single issue that's been keeping me from trying this project out.

[Neener54]

Yeah I had to move on from this issue unfortunately, it was working well in every browser but IE. For some reason in IE it was putting the first element at the bottom. I would love to finish this at some point in the future but I just can't spend the time on it right now. Tiff is smart though, his version will work a lot better than what I did.

[slikts]

It makes sense to add newlines when editing plain text with a textarea, but not when using a rich visual editor to edit HTML. The rich editor should output HTML as if you had authored it by hand using best practices, and plain text editing should have nothing to do with it. Even Word creates proper paragraphs by default, because you can style the paragraph spacing, text indentation etc. It's also hardly semantic markup to add <br> elements to create paragraphs, instead it's just a visual hack, since it only looks like a paragraph. I would really like for there to be "a better approach to rich text editing", but without real paragraph support this is a backwards approach.

[danillos]

+1 <p> lease!

[fd]

I may be repeating others but I'm adding my comment anyways as we were discussing it on a fork. (it's cross-posted here: yvesvanbroekhoven/wysihtml5-lalala#4 (comment))

<br/> is a line return within a paragraph. It means that after the tag a new line must be started. It has no semantics and is only used for easing the reading experience.

<p></p> is a paragraph. It means that the enclosed content is related. <p></p> does have semantics.

An often made mistake is to use two <br/>'s to make your text look like it has paragraphs.

RIGHT:

<p>Alice was beginning to get very tired of sitting by her sister on the bank, 
and of having nothing to do: once or twice she had peeped into the book her
sister was reading, but it had no pictures or conversations in it, 'and what
is the use of a book,' thought Alice 'without pictures or conversation?'</p>
<p>So she was considering in her own mind (as well as she could, for the hot
day made her feel very sleepy and stupid), whether the pleasure of making a
daisy-chain would be worth the trouble of getting up and picking the daisies,
when suddenly a White Rabbit with pink eyes ran close by her.</p>

WRONG:

<p>Alice was beginning to get very tired of sitting by her sister on the bank, 
and of having nothing to do: once or twice she had peeped into the book her
sister was reading, but it had no pictures or conversations in it, 'and what
is the use of a book,' thought Alice 'without pictures or conversation?'
<br/><br/>
So she was considering in her own mind (as well as she could, for the hot
day made her feel very sleepy and stupid), whether the pleasure of making a
daisy-chain would be worth the trouble of getting up and picking the daisies,
when suddenly a White Rabbit with pink eyes ran close by her.</p>

Usability:
Pages (on OS-X) also makes the distinction between breaks and paragraphs. When you hit RETURN a new paragraph is started (and as a result a blank line will be visible between the new and the old paragraphs). When you hit ALT-RETURN a break is inserted (and as a result there will be no blank line).

Conclusion:
Both <br/>'s and <p></p>'s are valid html content. They just serve different purposes. I would like to suggest going the Apple way and implement both RETURN-to-paragraph and ALT-RETURN-to-break (or SHIFT-RETURN-to-break)

[bobbaluba]

This is a dealbreaker for me too. Please make it optional!

[frahugo]

+1 <p> please!!!

[feronovak]

+1 for <p> and <br>

[ForbesLindesay]

+1 for <p>

I want the option to NOT give users the choice. I want to maintain very strict styling rules, which means that all newlines should be paragraphs. If it's a list, it goes in an <ol> or <ul> so there's no need to have lots of lines grouped together, it has no semantic value and it's hard to style. What I like about this editor is that it should be relatively easy to restrict people to a nice small subset of html.

[odelbos]

+1 for <p>

[emilevictorportenart]

hi, I just found THE trick to support markdown and don't have anymore
. What are you thinking about that:

So firstly: I get my value:

 $('.comment-box form').submit(function(e){
  e.preventDefault();

  var exit = editor.textareaElement.value; // get the value of my textarea - step1
  exit = exit.replace(/
/g,'\n\n'); // repace globally 
 by double breaklines as markdown add a p when you use two breakline. And I assume here that I don't wan't the user can add any 
 but you can replace "

" if you want the p are generated when the user add two breaklines - step2 
  exit = converter.makeHtml(exit); // and I convert with Markdown.converter  http://code.google.com/p/pagedown/wiki/PageDown - step3

  console.log(exit);
});

Step1 :

Waow, I *love* this trick.[br]What a weather with this **sun**.[br]# I love apples.[br]I like wysihtml5. 

Step2 :

Waow, I *love* this trick.

What a weather with this **sun**.

# I love apples.

I like wysihtml5.

Step3 :

[p]Waow, I [em]love[/em] this trick.[/p]

[p]What a weather with this [strong]sun[/strong].[/p]

[h1]I love apples.[/h1]

[p]I like wysihtml5.[/p] 

And that's it. What do you think about this trick ?
PS: I replace all the < by [ cause I don't know how to hard write it there.

[OscarGodson]

@emilevictorportenart I can't tell if you're spam or not... 😄

Your code samples above are totally borked and this thead is about <p>s vs <br>s not markdown at all.

[emilevictorportenart]

@OscarGodson I just edit my comment. And my post was just a solution to convert [br] by [p].

[OscarGodson]

@emilevictorportenart The only problem with that is as much as I love Markdown (which I personally use for all my projects), WYSIWYGs are for people who don't know Markdown. Markdown currently is more more tech savvy way to write.

[emilevictorportenart]

@OscarGodson yes but with this technique you can write both with the rich editor and with markdown. I know people hate learning new things but here if you want to write markdown, just go but if you don't know, just use the icons and the live preview. it's why i think it's really coooool !

[robwierzbowski]

Emile, I understand what you're doing here. I did something similar on a drupal project with CKEditor, removing the editor's js that adds paragraphs, inserting plain line breaks instead, and then running through a markdown processor on submit.

The suggestion doesn't force a user to write in markdown, it just takes advantage of markdown's <br> and <p> handling -- one linebreak turn into a <br>, two turn into a paragraph. Users have no problem with this pattern, especially when the paragraph CSS in the output has padding-bottom or margin-bottom.

I write with markdown so personally I like the suggestion, but making a markdown processor a requirement of wysihtml5 is too much overhead for the simplest use case. Still, planning the default implementation of wysihtml5 editor so that it is easily extended with markdown support would be a nice win.

[OscarGodson]

@robwierzbowski you need to put them in backticks like any code: <p>

[robwierzbowski]

Speaking of markdown...

[emilevictorportenart]

@OscarGodson hardly waiting for this release !

[JedWatson]

+1 for paragraphs on return, breaks on shift-return, so wysihtml comes in line with the other common wysiwyg editors.

It's currently causing havoc in our blogging platform, esp. because users can choose between writing in Textile or WYSIWYG, and then they both generate different code (Textile, like Markdown, creates a <p> on double enter) - which then messes with our ability to apply styles consistently (where you have control over margins on <p> tags but <br> tags are only affected by line-height).

We're looking into integrating a fork to bring this functionality in, but more are looking forward to an official release that supports this!

[robwierzbowski]

Links to any forks that support <p> tags would be greatly appreciated.

Both <br> on single return, <p> on second return, and <p> on single return, <br> on shift return are commonly used behaviors. It would be great to have a plugin or configuration option on the official release to choose between the two.

[snookca]

@robwierzbowski feel free to look at my fork. Some of the stuff I've done should probably be pushed back into master but some of it is unique to our needs (like the auto-linking behaviour for images/youtube).

(and just now realized that you already seem to be watching the repo. nvm)

[edwardmsmith]

@snookca Is this the entirety of the "use 'P's" change? Or where there additional changes mixed in further commits?

https://github.com/snookca/wysihtml5/commit/47e3975c9f07885f89de501e9ed7be28e6e89461

Edit: Oh, also noticed you edited the dist file. Did you redo those changes to the source files so its buildable?

[snookca]

@edwardmsmith this was the entirety of the change but it's also not perfect. It adds a new paragraph but if the selection isn't already a paragraph, it doesn't turn it into one, which I think it should. (Using | for cursor position.)

"this is my text|" If I hit ENTER, I would expect this to be converted to "<p>this is my text</p><p>|</p>"

This is especially important in tables. If I have "<td>this is some text|</td>" and I hit ENTER, I should get "<td><p>this is some text</p><p>|</p></td>" I could try and enforce all text outside of tables to be P or Hx block elements but inside tables, this would be an odd restriction.

This is on my to-do list within the next month.

[nlaplante]

+1 for

[alekseyev]

Yes, please, I am also for <p> on Enter and <br> on Shift-Enter, seems like it's standard for WYSIWYG editors these days.

It would also be great if it added line breaks after <br> and </p> -- so that when I switch from WYSIWYG view to HTML view it's not one big line

[hfjallemark]

+1 for. People expect WYSIWYG editors to work just like Word and Pages.

[davidjohnfarmer]

+1 for

... can't justify transfering from other editors until it's in :-)

[rrooding]

+1 for configurable br/p

[cfassel]

+1 for configurable br/p

[tiff]

Please no more "+1". I got the point and started working on this in a branch. It will be possible to customize the tag that should be inserted on return. Thanks! :)

[shankarcabus]

Yep!!! <p> is the future 🙏 😁

[Bratzilla]

Just wanted to post that the new paragraph menu item plus setting a blank paragraph tag in the editor seems to be a workaround until this issue is officially fixed. Just did some preliminary testing and each time I did this, whatever I typed was properly wrapped in paragraph tags.

@fd, I am especially interested in your comments, as I am building an application specifically targeting writers (novelists) and your points almost perfectly echo what I'm going through in trying to give them a rich creative environment without compromising too much on correct semantics. I can tell you, tags DO matter, especially when you're dealing with front-end presentation issues such as pagination, and the system needs to know specifically what tag to use as a baseline for those page breaks. :)

[edwardmsmith]

@Bratzilla Is "the paragraph menu" in your comment referring to the line_breaks branch?

For the "blank paragraph tag" you're seeding an empty editor with a <p></p>.

I think I'll give this a try today as well.

@tiff - how's that branch going? Is there anything you need help with?

[Bratzilla]

@edwardmsmith I was referring to a paragraph editor option that tiff provided in another thread. Here is the link:
#13 (comment).

And you are correct, I am seeding the editor with an empty paragraph. It's not the most elegant solution, but at least it's something until a formal fix is provided.

I am sorry, I should have been clearer. :)

[tiff]

@edwardmsmith Making good progress. Thanks for asking! I think I'm going to have a proper solution implemented by next week.

[tiff]

I think I have something that works pretty well now.
Check it out and please give feedback: http://tifftiff.de/wysihtml5/examples/advanced.html
Thanks!

[hfjallemark]

Looks awesome! Good job @tiff :-)

[edwardmsmith]

@tiff Looks pretty good, but I thought I'd try what @andymason mentioned in an earlier comment: #13 (comment)

If I type This is the first paragraph, then a return, the click insertunorderedlist, add two list items, hit enter twice to get back to paragraphs, and type again This is the final paragraph, and hit enter one more time, we end up with html:

<p>This is the first paragraph.</p><ul><li>This is a list item</li><li>This is a list item</li></ul><p>This is the final paragraph</p><p><br></p>

Which is correct.

When I click into the unordered list and click (the now bold) insertunorderedlist, the resulting html is:

<p>This is the first paragraph.</p>This is a list item<br>This is a list item<br><p>This is the final paragraph</p><p><br></p>

Which would not be correct - so, just as @andymason said, when switching from a block element like ul/ol - the contents need to be re-wrapped in the <p> tag.

Otherwise, looks awesome!

Edit - I think keeping the <br> tags that ended up after each list item is the right thing to do as well - keeps the visual formatting.

[tiff]

Many thanks for testing, @edwardmsmith! Fixing that should be an easy one. Will do!

[edwardmsmith]

My pleasure! Looks like the same sort of thing happens when switching a paragraph to other block elements and back again.

So something like:

This is my first paragraph.

This is my second paragraph.

This is my third paragraph.

Then, place the caret in the middle of This is my second paragraph and click h1, then click it again to turn it off. The second paragraph will have lost its <p> wrapper.

Guessing the fix is similar or even the same.

[allesklar]

Thank you tiff. This is really good. I find that the editor works as expected when we enter the text in the right order.

Some messy divs were created after pasting a bunch of text.

I guess we'll need a p toolbar button for when we move away from h1 or h2 and into a regular paragraph.

[hrach]

It works lovely, but there is a bug, I can not resize images (Firefox). Thanks for awesome editor :)

[tiff]

@edwardmsmith I think I fixed the things you reported. Please check: http://tifftiff.de/wysihtml5-dev/examples/advanced.html

@hrach I'm able to reproduce this behavior. But I don't have an explanation for this yet.

@allesklar A p toolbar button is always possible to include (I added one to the example page)

[seanhinton]

Is the line break version on github because it doesn't seem to work on the line_break branch but does work on the tifftiff.de site. Is it possible to get the version from the tifftiff.de site?

[tiff]

@hrach I fixed the resize issue in master now.
@Smickie I'm about to merge the line_break stuff into master, then all you have to do is compile (make) and use the freshly generated files in the dist/ folder.

[seanhinton]

Thanks. This is brilliant.

[kirugan]

@tiff hi! After header tag new line became wrapped in , but i need exactly

tag. How i can do this ?

[benbonnet]

no seriously this editor does not work well :/

[OscarGodson]

@bbnnt it hasn't been updated in 2 years so I wouldn't expect it to :)

[benbonnet]

that's why ahahah (:

[GBH]

Just suck it up and use tinymce. I think it got a bit better overall.

[benbonnet]

I though this one was more robust
I'd stick with my old medium-editor https://github.com/daviferreira/medium-editor, which works enough

[Videles]

On line 12 of bootstrap-wysihtml5.js you will find this.

data-wysihtml5-command-value='div'

Change the value "div" to "p" and you have at least a quick workaround with which you are able to insert a paragraph.