denise: Image: Me, facing away from camera, on top of the Castel Sant'Angelo in Rome (Default)
Denise ([staff profile] denise) wrote in [site community profile] dw_dev2016-10-02 02:04 am
Entry tags:

Help poke at the new RTE for the beta update page!

[github.com profile] wohali has been working on issue 664 to add a RTE to the new beta update page, and is ready for more eyeballs to poke at it and try to hit weird/unusual use cases or things that could be improved!

If you have a few, please poke at the new RTE on [github.com profile] wohali's dreamhack. To test it:

* Go to http://www.wohali.hack.dreamwidth.net/ and create an account.
* Go to http://www.wohali.hack.dreamwidth.net/beta to turn on the beta update page and http://www.wohali.hack.dreamwidth.net/update to make a post with it.

The update page should default to RTE on the beta update page. To disable it, go to Settings and check "Completely disable the Rich Text Editor (use plain textarea only)". (Historically speaking, a lot of RTE glitches happened when switching from HTML mode to RTE mode, so it's probably worth testing that a bunch.) Accessibility help is available by pressing Alt+0 (zero) while the editor is focused.

If you run into a problem or want to give feedback, you can comment on this entry. If reporting a problem, please include a link to the entry you made so [github.com profile] wohali can see the markup!
wohali: photograph of Joan (Default)

[personal profile] wohali 2016-10-03 10:31 pm (UTC)(link)
So here's the two issues with what you've said as I see it.

When someone goes from RTE to HTML mode, without special handling by the HTML writer code, all newlines are purged, semantic or not.. This is why I immediately have to convert all newlines to br tags the instant someone transitions from HTML to RTE mode - this protects the semantic newlines by transforming them into tags.

This is also why the box gets checked the instant you move into RTE mode. Because we insert non-original newlines when going back from RTE to HTML mode, if we preserve the state of your checkbox when returning to HTML mode, you'll get newlines where you don't expect them, say around newly-inserted paragraph or div tags. So sure, I can preserve the state of your checkbox but if you roundtrip HTML->RTE->HTML, leaving the checkbox unchecked upon submission will corrupt the result of the output as well.

If we shifted to double-new-lines as paragraph markers, I could preserve the state of the checkbox and we'd be ok, because the HTML writer would never insert two linebreaks in a row; these would only ever be represented by br tags, which I could reverse-translate back into double newlines if desired. But this only works if we change the standard.

But things are not all sunshine and roses with a double-newline-as-br standard. Remember that the DW backend preserves any newlines in entries verbatim and converts them at render time to newlines if the checkbox is not ticked, which is why submitting text with newlines in it in raw/HTML mode with the checkbox checked will preserve those newlines in rendered posts. We could have the new RTE default be to convert double-new-lines to paragraphs, but we'd probably want to still save the post with the checkbox ticked and double-newlines converted to br tags, meaning the backend's auto-newline-to-br-tag processing would never be triggered and the RTE itself would be responsible for ensuring proper HTML is saved into the backend. (We can't change the backend's linebreak processing without breaking the rendering of thousands (millions?) of old posts.)

This is a bit of a braindump, so if anything is unclear please ask away.

[personal profile] swaldman 2016-10-03 10:48 pm (UTC)(link)
Re the first half: Yes, I understand that, and that's why I don't think we can reach what I'd consider to be a good solution while supporting the single-newline-means-linebreak feature[1]. That feature forces you to have the page do user-unfriendly things, such as resetting that check box every time.

Re second half: Damn, I didn't realise that the old system did it at display time rather than submit time. That's awkward :-/ With that said, if we could find a way to make things work right within the RTE, I don't actually see a reason *not* to just add br tags at submit time and never set the backend newline-to-br bit again...
(editing old posts might be awkward, I guess. And there are probably other gotchas that I haven't thought of :-/)

Once again, your work on this is appreciated, and I'm sorry for bringing up problems!



[1] Please bear in mind that I have absolutely no authority around here; I just talk a lot. Just because I don't like soimething doesn't mean that it isn't acceptable to the powers that be!

[personal profile] swaldman 2016-10-04 07:40 am (UTC)(link)
Radical idea: if we have to keep single-newline-means-linebreak, then we don't offer that in conjunction with the RTE. Remove that option from the RTE and add the checkbox, working as it used to in setting a database flag, to the form that is shown if the "disable RTE completely" option is selected. If you want to use the "auto-format" thing, you don't get to use the RTE on the same post.

This does arguably mean removing a feature. I don't know how many used the newline-to-br functionality and round-tripped things in the old RTE. But it's another way to proceed without requiring user-unfriendly kludge. I don't think there's a way to make this work that won't make somebody unhappy...

Now I'm feeling that I'm the only voice on this issue, so I'm going to shut up for a while, and hope that others have opinions.....
Edited 2016-10-04 07:42 (UTC)

[personal profile] pinterface 2016-10-05 03:26 am (UTC)(link)

To use a colloquialism, I don't really have a dog in this fight, but: removing the auto-format checkbox when the RTE loads seems like a pretty reasonable compromise. The newlines-to-br functionality is basically a really low-grade RTE, so when there's a not-terrible RTE available it seems reasonable to let it subsume the functionality of the less-good one.