+1 for the icon, +0 for the placeholder. The placeholder needs to be done properly if we want it to be useful. IMO a placeholder should provide more specific info than just Filter (see <input>: The Input (Form Input) element - HTML: HyperText Markup Language | MDN). Doing it properly would mean at least providing a new parameter for each column so that the livedata creator can specify whatever placeholder would fit the column filter.
+1
Maybe we can implement this idea in another way :
- Replace the content of the right side panels with the options (with a button to close them and display the regular panel-column content). IMO this could be nice because I don’t think there’s not many use cases where the user would look at the livedata options and want to quickly use anything in the right side panel. A big downside is that it would break consistency. Users expect panels to be here, and we’d replace them.
- Display livedata options in a modal (maybe even a drawer without a backdrop?)
I don’t know the exact solution we would go for, but implementing responsive designs with modern CSS should not be difficult given we think about it when creating the DOM templates. Having a “mobile” design for the layout would make sure we properly take it into account (and would make the choices in HTML implementation that much easier to take 
).
Overall 
I’m still having issues with the way we don’t highlight and/or separate actions but that’s discussed in parallel in Style Live Data actions as buttons - #6 by mflorea , I won’t go further into it here.
As a side note, it might be interesting to provide the font-weights we use often as variables. As of now, I see a lot of font-weights in our codebase that are hard coded.
don’t hard code colors in properties
from https://dev.xwiki.org/xwiki/bin/view/Community/CodeStyle/XhtmlCssCodeStyle/#HCSS. We have this codestyle to ensure we are consistent across UIs on colors, but we should probably do the same for font-sizes ^^’
Thanks for your proposal!
Lucas C.