chat widget is inconsistent and have some display issues

[jalberto]

Describe the bug
Using the default CSS I get discrepancies between the preview and final widget

Also, I can see hot mostly component display scrollbar when not needed

To Reproduce
Create a simple campaign and check how it looks in the tester section

Expected behavior
A more similar result

[jalberto]

This is how the conversations section looks in brave + inux

[jalberto]

Another scroll issues, I don't know if it's related or even expected:

[michelson]

It would be great if you could help us with this when you have some time. I don't have a Linux here to make the proper debugging for this.

[jalberto]

I will! As soon I have everything working correctly, I will review the css/html side of thing in case I can find some tweaks to improve it.

I assume that this does not happen in win/mac?

[jalberto]

@michelson a quick one:

I can see 2 issues:

• overflow: scroll forces to display scroll always, the simple solution is to set it to auto so the scroll will only show up when it is needed
• there is a lot of inline css in the style attribute, this makes it much harder to apply a custom css without modifying the code

Are these intentional ?

[michelson]

This is how the conversations section looks in brave + inux

I've fixed those here: #708

[michelson]

Describe the bug Using the default CSS I get discrepancies between the preview and final widget

Also, I can see hot mostly component display scrollbar when not needed

To Reproduce Create a simple campaign and check how it looks in the tester section

Expected behavior A more similar result

This one is not reproducible on mac/chrome

[michelson]

I've merged to master the fixes for the agent side conversation view

[jalberto]

thanks @michelson

I can see you changed some pixels to adjust the sizes and margins.
I wonder if the use of inline css is to solve some previous issue or is something you plan to move out, I am not familiar to react so I would prefer to touch only the CSS side of things but inlines styles has more priority than any other rule,

regards

[michelson]

@jalberto yeah, inline styles are for those really custom styles, It would be great to get rid of them, for now they just work. also, note that there are no .css files, the CSS is added as utility classes (tailwind) or as a styled-components (react components as styles)

[jalberto]

Would you consider adding component/domain classes (chaskiq-widget--box)?

Then that class can be used for small tweaks, as you do inline right now, then if the CSS is served in its own file or as an embedded React class is indifferent.

This will allow for some customization without modifying the code.

[michelson]

not really. those inline styles are in just very specific places and I would not want to add specific classes or separate CSS files for now. what we do right now is utility classes (tailwind) or styled-components (react components as styles)

[jalberto]

I understand, I am not a big fan of utility CSS for all the cons, but I understand it can be convenient when a lot of manipulation is required from JS side.

I am not familiar with react, but if it's similar to other frameworks, you can “embed” css scoped in the components, so not separated CSS file is required (if that is your main concern)

[michelson]

yes, that's how styled components work. it's a component with the styles in it, then the styles are compiled in a css class

[jalberto]

sorry, but then I do not get why to use an inline style, instead of a css class (css class are cacheable, inline styles are not)

[michelson]

you can do it with a styled component, that will generate a CSS class. PR are open