CSS refactoring (flexbox, animations, skin variants)

[seballot]

As we discuss earlier with @muxator and @JohnMcLear here is a pull request to improve the css code base

Main idea was to simplify the code, i.e. stop using absolute positioning lead by javascript, stop using table for positioning elements, and use flex box instead to make the design more responsive and auto adjustable

Note re the pull request

• I made one big commit (the last one), sorry for that but it was hard to split it while developing (when changing the UI you constantly do back and forward). I hope that is okay. I made the commit message more detailed than usual
• This pull request breaks the colibris skin. Another pull request will come to adjust colibris skin
• Some plugins (especially the ones who used new element positioned, like table_of_content) will probably be broken. I will have a look to different plugins, @JohnMcLear your help would be very appreciated :)

[seballot]

Actually, please do not review this PR right now, I will still work a bit on it tomorrow, and also run and fix the tests !

[JohnMcLear]

Note that I also worked on the tests so do pull my branch with fixed tests.

[seballot]

I fixed ep_table_of_contents and ep_set_tilte_on_pad, thanks @JohnMcLear for having merged the PR !

Do you see others plugins that might break the UI? I mean plugins which insert content inside the main layout?

[JohnMcLear]

ep_webrtc ?

[JohnMcLear]

ep_comments / ep_comments2?

[seballot]

Thanks ! Is there an easy way have ep_webrtc working for real in local? Or do you know an online etherpad instance using this plugin?

[JohnMcLear]

@seballot just install ep_webrtc and install some certs from letsencrypt on a domain. You need to run https, if not maybe it will work in exceptions?

[seballot]

I just have this empty container for webrtc (I put it on the right)

[JohnMcLear]

anything on console?

[seballot]

WebRTC ERROR: DOMException

[JohnMcLear]

will check.

[JohnMcLear]

Hrm, try remove other plugins and try against latest develop (lots of change lately on develop).

It works for me without anything in settings.json, I just see

Sorry, your browser does not support WebRTC.

To participate in this audio/video chat you have to user a browser with WebRTC support like Chrome, Firefox or Opera. Find out more

I could add a protocol check and if it's http mention why it's not working... I just expect everything to be on https nowadays but I guess if you are running locally...

[JohnMcLear]

I'd remote any ep_webrtc settings too, might be a bug in that?

[seballot]

Thanks ! but if I just have this message it will not help very much :) I wanted to see the others components of the plugin (like where the video appears etc...) to ensure everything works. You do not know an online instance?

Unfortunately settings https on local host in a bit a pain

[JohnMcLear]

https://video.etherpad.com

[seballot]

Amazing ! thanks :) https://video.etherpad.com/p/test

[muxator]

Can I have a brief recap on the status of this and #3726?

[seballot]

Hi muxator !

For this one : etherpad core is now using flexboxes to easily positioning element on the layout (no more absolute positioning with javascript like $(editbox).css('top', $editbar.height())

It simplify a lot the code (both javascript and css) but this change is not compatible with plugins introducing others components in the layout with absolute positioning. I'm am currently fixing those plugins (table_of_content, set_tilte_on_pad, webrtc). But it introduce a compatibility problem between etherpad core version and plugin version, see discussion here about webrtc : https://github.com/ether/ep_webrtc/pull/28#issuecomment-604698324. Your help would be welcome to find a good solution

What remain to be done in this PR is fixing the colibris skin

re #3726, I will wait this refactor to be done so I could rebase the changes on top of it

[seballot]

@muxator @JohnMcLear I gave more thoughts re the problem of compatibility between core code and plugins

Seems to be that the only way to improve the codebase without compatibility problem is to :

• Refactor etherpad removing javascript absolute positioning -> done in this PR
• leave plugins as they are (meaning using absolute positioning), so they will still be compatible with any version of etherpad -> _TODO revert some of the pull request I made on ep_table_of_content, title_onpad, webrtc...
• Add some strong css rules to etherdpad 1.9, so that the javascript positioning made by other plugins on the main containers will have no effect (so old plugins will not break the css in etherpad 1.9) -> TODO in this PR
• Add some css in etherpad core for positioning plugins in the new way (flexbox). It will not be a lot of code, few lines per plugins, seems like only 4 plugins introduce new containers in the layout, other plugins just add buttons or popups below toolbar -> TODO in this PR

WDYT?

[JohnMcLear]

I don't mind dragging people up to 1.9 to implement the new CSS.

The point is we need to make it clear WHY something is broken if it is, currently it fails silently. That's not good enough.. console.warn("upgrade yo shit"); for example...

[seballot]

@muxator WDYT about John proposal? It's a easy solution, fine by me

[muxator]

Hi @seballot, I am ok with your proposal, above all because it outlines a clear deprecation plan for the old features.

I also agree whith @JohnMcLear: when on 1.9 the plugins are going to break, there must be a clear message somewhere that at least points to the documentation on how to fix them.

My only curiosity is how would we do that.

• Via js? If it is one-shot, something like a check that is triggered after all the plugins are loaded, for example, I would be ok with that;
• if it means hooking to some continuously running function (like a timer or a resize event) obviously would be a no no;
• is there a smarter way via CSS (a info box appearing, something like that)?

[muxator]

Wow you are working, man :)

[muxator]

wow reviewing this is going to be a lot of work :)

[seballot]

Yes sorry ! And I'm not finished yet ah ah :)

But lots of commit only involved css, so they should no be very critical to review

[JohnMcLear]

@seballot is this wrapped up?

[seballot]

nop, I'm working on it right now, I did some improvement on the ep_comments_page, and now I'm styling it with colibris

Just few more things and it will be ready, hopefully before the end of the week

[muxator]

I want to make this part of the next release (1.8.3), there is enough material for warranting a release now. Writing the changelog is going to take half a day alone.

[seballot]

Ok ! My changes are finally ready... UI is really a black hole, very time consuming, and also it never end... So I'm ending it for now :)

One thing I couldn't find the energy to do is fixing the tests. I do not know this test language, and with the refactor I guess a lot of specs will break (mostly due to refactor, not to functionality downside)... Does someone would like to fix them?

So main improvements of this PR are

• Using flexbox instead of old absolute javascript positionning
• Simplify the no-skin, so it looks more like a no-skin, and so it's easier to style other skin (otherwise you often need to override some bad rules made in no-skin). Btw, maintenaing the two skin is a bit a pain, I think you should later remove the no skin, have only colibris skin as default, and maybe restore old mechanism for people to add custom code on top of default style
• Improve colibris skin (and also the ni-skin for some aspects): make the skin closer to 2020 standards -> style checkbox, select, scrollbar, smooth popup animations... And make it more "refined", "minimal"
• Adds the skin variants concept, in order to easily customize the rendering of the skin. I made also a skin variant builder so it's easier to test and choose the right config. You access display the skin builder adding #skinvariantsbuilder to the url
• Use css variables in colibris (with fallback for the few non supported browser), so it's quite easy to change the colors if needed

Here are some screens

New theme

Changing Colors

Skin Variants

[JohnMcLear]

Wow! I will look at tests now.

[JohnMcLear]

Initial testing. Gotta say it looks amazeballs and works great. Just some minor polish required :D

• [ ] Stick Chat to side of screen setting option is missing, please add back in. Did anything else get removed? If so, why?
• [ ] Pad Model - Another one for you to do. Clicking anywhere in the pad should close the Timeslider Saved Revision pop up. Persisting it on the screen is not ideal.
  • [ ] Allow the user to select all pad contents when the disconnect dialogue is visible. To simulate, kill the running Etherpad instance. This is an important "feature" not a bug.
• [x] Scroll - These tests are broken anyway.
• [x] Timeslider revisions - It's due to Y position being hard coded in https://github.com/ether/etherpad-lite/blob/develop/tests/frontend/specs/timeslider_revisions.js#L37 afaik

[JohnMcLear]

Timesliders revision test can be fixed with

        var latestContents = timeslider$('#padcontent').text();
        // Click somewhere on the timeslider
        var e = new jQuery.Event('mousedown');
        e.clientX = e.pageX = 150;
        e.clientY = e.pageY = ($sliderBar.offset().top -38);
        $sliderBar.trigger(e);

        e = new jQuery.Event('mousedown');
        e.clientX = e.pageX = 150;
        e.clientY = e.pageY = ($sliderBar.offset().top -33);
        $sliderBar.trigger(e);

        e = new jQuery.Event('mousedown');
        e.clientX = e.pageX = 150;
        e.clientY = e.pageY = ($sliderBar.offset().top -43);
        $sliderBar.trigger(e);

[seballot]

the stick chat option is there for me, not for you?

What I did is remove this option on mobile, because it does not make sense

[JohnMcLear]

Hrm, I see, well that's new behavior and will prolly upset some people who want chat to be a focus on browsers that use 1/2 a screen.

I'm not -1 on it, but if you think about it, depending on the test runners setup the experience of if the browser thinks it's mobile or not will change..

The test will need to be more explicit, essentially saying what width the browser width is of the tester.. Our tests are automated across browsers and across operating systems, so we can't set the screen resolution fixed... I will check that tho

To replicate the bug..

• [ ] Run test on normal monitor, it will fail
• [ ] Run the test on an ultrawide monitor, it will pass.

See what I mean?

[JohnMcLear]

Looks like the runner draws the iframe on the screen, perhaps we can set width there.. Either way we can fix the tests for sticky chat after this is merged in..

[seballot]

On pad.js line 567, sticky option disappear for screens below 800px. You can still have the chat visible on the bottom (it take 100% of the width), but it will no longer stick on the right, otherwise the editor became too small

The problem is that when running the specs, the editor take only half width of the screen, so yes on normal monitor test screen seems like almost like a mobile screen

for running the specs, maybe we could allow the page to be bigger than 100% width (horizontal scrollbar) and so we can set the iframe to a certain width if needed?

[JohnMcLear]

@seballot yeah, defo something we can fix "after". No problem from my side. Focus on the Pad Modal stuff? Afaik I submitted a patch for disconnect too, check PRs, I might have broken it the same as you :D

[seballot]

Ok re pad modal, you are talking about the "gritter popup" right? like the save revision, or when a message in the chat is received?

Allow the user to select all pad contents when the disconnect dialogue is visible

Indeed nice feature broken

[JohnMcLear]

Yea the gritter popup, If you click save revision, you'd expect it to dissapear whe nyou click back on pad or so.. Chat msg will need to persist, I think it's the location & duration that's a problem... Thoughts?

[seballot]

From what I saw about gritter in etherpad there are two options : 'sticky' and 'non sticky'

the non sticky disappear after some time (configurable) the sticky stay until you click the close icon

I added the close icon also on the non sticky one, so you can close them if you want. Closing them also with a pad click is an option yes, I'm just wondering that user close them by mistake (if you are in the middle of an action, and the gritter pops during your action, it will directly disappear). It was like this before? I tried on develop branch, but the gritter message is not even poping up... lol

re chat gritter, if we are talking about the gritter to say that someone wrote a chat msg when my chatbox is hidden, I don't think they need to persist (i.e. they should be non sticky, disapear themself after 3second or so), WDYT?

[JohnMcLear]

I agree, but I think save revision can be there for like 2 seconds tops, else it could be really annoying taking up the viewport.

Chat msg is dynamic information you need to read every time. Saved revision is static informaiton you will never read after you read it once.

That's the point to consider here :)

[seballot]

Yes good point !

So what shall we do? does adjusting the time each notification stay visible is good enough for you? like chat msg for 4s, and save revision for 2s?

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday 17 April 2020 17:30, John McLear notifications@github.com wrote:

I agree, but I think save revision can be there for like 2 seconds tops, else it could be really annoying taking up the viewport.

Chat msg is dynamic information you need to read every time. Saved revision is static informaiton you will never read after you read it once.

That's the point to consider here :)

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[JohnMcLear]

Yea could be a division of the setting value. Try different ones and see what feels right

[seballot]

Hi ! I fixed all specs (except the slider one), and also the ability to copy the pad text when we are disconnected

re the the pad_modal test, actually is was not the gritter popup, but the normal popup like settings or so, and the problem was just how we detect that those popup are open or not

But still made some improvement for gritters

[JohnMcLear]

Wow great job!! I absolutely can't wait to show people this work

[muxator]

It's hard to express the amount of work @seballot has done on this PR. It's gargantuan.

I'm focusing on the js changes:

• farbtastic and gritter are two old vendorized libraries that this PR edited. I've added a note on top of those files (Edited by Sebastian Castro [...] on...) to track the fact that they are no longer the original version. This may come in help when in need of reconstructing the history of those files;
• in the commits of this PR I've stripped the changes (mainly aestetics) that where part of Sebastian's version. In this way the diff consists only of his modifications. I liked his version better, but this is a big PR, and it's important to be able to asses what has changed;
• I have a potential security doubt in a change in src/static/js/chat.js. I'll address that later.

Overall, looking at this PR's diffstat for the js files, it's interesting to observe that the amount of javascript code has indeed decreased, despite the introduction of new functionalities (skin variants, animations).

[JohnMcLear]

We should be looking to contribute to gritter and farbtastic with some changes instead of going off piste.

[JohnMcLear]

I'm gonna write some front end test code that finds every input and tries to inject some xss

[muxator]

we should be looking to contribute to gritter and farbtastic with some changes instead of going off piste

In general, I totally agree. In this case, these libraries were already vendorized: hopefully who decided to vendorize them had already done a cost/benefit analysis. We are paying that cost now.

[muxator]

The skin variants builder at http://localhost:9001/p/test#skinvariantsbuilder is super cool.

We have to mention it somewhere prominent!