parse_texte_paragraphs() broken

[BoboTiG]

I finally found a track for my problem when there are lot of spaces added between blocks.
This line cannot understood hr blocks, because its format is not <hr></hr>. So, when I put a manual <hr> in a post, all following content is parsed as an inline element.

Another thing, I refactored this function (less capturing groups, less code repetitions), if you want I can send a PR and see if we can work on OR we try to fix this issue and then I will send a PR. If you are interested of course.

[timovn]

For the <hr/>, we might convert it to <hr></hr> first, than parse for <p> and in the end convert it back to <hr/>. It’s a bit like Gecko DOM parser seem to work : the DOM tree also contains such things as <br></br> (even if the source document does not).
I’m open to other suggestions for this.

I’ll be happy to see the PR for the refactoring in either cases and put it to the tests.

I’m also asking myself if this function could need a major refactoring, using LibXML. But it could heavily conflict if the user input contains non-valid HTML, scripts or other stuff.

The purpose of this function is to make nicer HTML (instead of doing a nl2br()). This is usefull for applications like Pocket™, Readability.js and screen-readers that format paragraphs in specific ways.

[BoboTiG]

In theory the user input is BBCode formated. For the few who write raw HTML, if the code is bad it is not an error of BlogoText. I used to write raw HTML sometimes but now there is [code=language].
If there were a hr BBCode I think I will not have to write raw HTML anymore.

Do you know if a lot of people write scripts into the post content?
Perhaps you could use a function with libXML and in case of error fallback to this function?

[timovn]

I use much of HTML all the time. No BBCode or markdown will replace its power.
A native HR tag in BBCode could help, and there was such a tag in the past but it would not solve the problem here : parse_texte_paragraphs() always gets HTML as parameter. So the BBCode would be transformed to HTML before the functions is called.

For that, at this point I don’t have any other idea than the intermediate tag (the same trick I use for the [code] tag, transformed into <prebtcode> and then in <pre>.

[BoboTiG]

You are right, using the same trick will be OK.
I will send the PR after your modifications, it is nothing big.

[timovn]

It is done for the hr.
I noticed that the tbody element was forgotten in the block elements and added it also.

[BoboTiG]

It is much better :)
I just found that input blocks are wrong, but it is an unusual special case.

[timovn]

You mean output ?

[BoboTiG]

No, input of forms.
I do not think it is needed to handle this case.

[timovn]

I don’t understand : which inputs?

[BoboTiG]

I talking about manually add a form into a post :)

[timovn]

Aha! But I didn’t planned to support that :O

If we really want to support the totality of HTML elements, we should add them all, and make a special regex for all the self-closing HTML tags.

It might then become quite hard to do to support everything : attributes for instance, can contain actual HTML and/or JS (with fancy characters, including HTML). It’s not impossible but it might be very tricky:
http://lehollandaisvolant.net/?mode=links&id=20130322003640
http://lehollandaisvolant.net/?mode=links&id=20130322223827

IMHO, there would be too much energy put into that for something not widely used and already having a solution.
There is an easy way to make everything work fine, that is not using any \n in the text you enter.

So, don’t do this:

<form>
<fieldset>
<label for="input">Blah</label>
<input id="Blah" value="something here"/>
</fieldset>
</form>

But this:

<form><fieldset><label for="input">Blah</label><input id="Blah" value="something here"/></fieldset></form>

It is dirty and undocumented, but it works and does validate with W3.

[BoboTiG]

Thanks for the trick! And yes, you are right, no need to implement such a thing ^^