[Gelöst] Add local CSS and JS to individual layout cells and rows

[Author]

Artikel

[Kirill]

I'm happy to see many improvements to the Layouts plugin. I think it's getting better and better!

I would like to suggest an improvement that, on my opinion, would be beneficial for many use cases. I think it would be great to have a separate CSS and JS editor for each cell and each row within a layout editor.

Currently, as I understand, if I want to add a class to a layout cell, I have to do it in the global CSS and JS layout editor. This can be good in some cases (when the same style is shared among several page layouts), but it also has some drawbacks:
1. In order to add styles a user had to switch between between a layout editor and a global CSS/JS editor. That's an unnecessary distraction, I think.
2. Some styles are meant to use for a single cell only. There is no reason to load them on all pages, as global styles do.
3. If layout is deleted, all styles associated with this layout only will still remain in a global CSS editor unless removed manually (and it would be not easy to track such cases). This will pollute a CSS style sheet eventually. However, all local styles associated with a particular layout would be deleted when this layout is removed.

Same applies to JS.

So I suggest, in addition to global CSS and JS editor, have a local CSS and JS editor which content would be loaded on pages with this layout only. That would be highly beneficial as we can use global editor for global rules and local - for rules associated with this layout only. It's a win - win situation.

Please let me know what do you think.

Best regards,
Kir

[Christian Cox]

1. In order to add styles a user had to switch between between a layout editor and a global CSS/JS editor. That's an unnecessary distraction, I think.
Open the Layout editor and the CSS editor in two separate tabs or windows so you can see them side-by-side! This is arguably better than one window, because you don't have to scroll around as much and you can see both simultaneously as you work.

I think it would be great to have a separate CSS and JS editor for each cell and each row within a layout editor.
Let's say right now you have 10 cells on a page, and all the CSS and JS for those cells baked into the Layouts CSS and JS panel. On the front-end of the site, we serve up a single CSS file that includes all the styles from Layouts CSS, and a single JS file that includes all the necessary JavaScript. Some unnecessary code is included because some code is for other pages, but the amount of time it takes to download that extra code is negligible, and the files get cached after the page loads once so future page loads don't have that hit.

If we take the approach you're describing, that means that on each page of the front-end of the site, a single CSS file or JS file just for that specific page's Layout must be included. This means our system must automatically generate separate files for each page representing that Layout's specific combination of cell requirements. Now you're adding an additional two asset files to download, which can lower page rank scores and increase site load times. In my opinion it makes more sense to have everything in one file, not have 30 different CSS and JS files for each combination of possible cells on different Layouts, and to manage all these different files based on the content of each combination of cells in each Layout.

What happens if someone includes conflicting CSS in two different cells? How is that debugged when you have to search through each cell you have created to find the conflicting CSS? Yikes. I find that I'm making minor tweaks to styles more often than completely ripping out sections of a site, so being able to find code is more often important than removing stale code.

3. If layout is deleted, all styles associated with this layout only will still remain in a global CSS editor unless removed manually (and it would be not easy to track such cases). This will pollute a CSS style sheet eventually. However, all local styles associated with a particular layout would be deleted when this layout is removed.
Yes but this is true for all CSS and JavaScript files. I think the better approach is to use classnames to limit the scope of each CSS rule and JavaScript selector. Keep files consolidated so it's easier to make modifications.

I'll ask Nigel to chime in here, as he is the supporter liaison to the Layouts team. He will have some more targeted information for us. Please stand by.

[Kirill]

Thanks for you for your thorough response, Christian!

I agree with a lot of what you was saying. However, I still think some things are not as easy as they might be. Let me describe a typical situation I've been in many times working with my clients. This is when you need to style a one particular element only. Say, you need to add an extra margin space to a specific element because a page content requires that. However, it is required for one page only. Other pages will do just fine with standard margins. So what do I do?

I can use a utility class, something like "mb-50" with "margin-bottom: 50px" in it. However, if this class gets reused on some other page (which is a general idea with CSS rule sets) I'll lose an ability to tweak it for this particular page only: every change I make will be inadvertently reflected on the other page of the site. And it's really hard to keep track of that.

That's the problem with CSS rules for one particular element: if they are exposed in a global CSS stylesheet, there is no way to prevent them form being used somewhere else. That creates a huge problem.

Scoped CSS would be an ideal solution here, but looks like it is pulled out of specs as of now. So the only option left is an inline CSS. Even if I don't like it in general, it would probably make sense to use in situations as described above. They do not generate any extra resource for loading as they are in the page itself. That will generate CSS that will be attached to one element only and cannot be shared by others. But there is no way to add that in Layout currently, as I understand. Maybe adding an inline CSS option would be a good idea, what do you think?

BTW, in my initial suggestion I have no intention to generate any external file resources. My idea was to use embedded CSS (hidden link) that will not result in additional network requests.

All said about CSS is even more true for JS. Very often JS is element specific. For example, to enable a Bootstrap 3 tooltip one has to do "$('#tooltip-id').tooltip(options)". Or it could be adding a specific animation to a specific element within a layout. On my opinion, it would make more sense to to keep such JS closer to the layout than in some global file. For complex sites there can be hundreds or even thousands of such code pieces. A global file would be harder to navigate. And if with build systems like Webpack we can split them into several files, there is no option like that in Layouts. Everything is in on (big) file.

Putting a JS layout specific code to the page is easy. It can just be dropped within "<script></script>" tags right after the layout markup, or at the end of page body. For ease of debugging a block can be marked with the comment of where it belongs.

Maybe having a specific JS for each layout cell is an overkill, but having a common JS block for the whole layout might be beneficial, I think.

Your suggestion of having a layout editor and a CSS/JS editor in separate windows does work, but, on, my opinion, it's more of a workaround. My screen is 1920px wide, may developers have even larger screens nowadays. But even on my screen there is a wasted space at the right of a layout editor (please see a screenshot below). Why not to use it for adding a CSS/JS editor there? Then there will be no need to have it in a separate window which, I think, is still a little unnatural.

Please let me know what do you think. You, guys and gals, are creating a great product. I do believe in you and I think Toolset deserves to be the best offer on the market. Implementing seemingly small usability improvement can make a huge difference for all your users.

It's also often a client decision of what product/technology would be used for a site. It's because he/she pays the money and he/she does some small text/style changes on his/her own. Some competitive layout products have really nice UIs, even though they are not nearly as powerful as Toolset with Views, CRED, and all other goodness. But it's really hard to convince clients as they often (unfortunately) judge by looks. It takes a lot of time to explain, but still does not work sometimes. Making Layouts visually nicer and more user friendly would help with that a lot. And that will help with you market share, too.

[Christian Cox]

I will assign this ticket to Nigel so he can analyze your comments and respond to you about this feature request. Thanks!

[Nigel Supporter Languages: Englisch (English ) Spanisch (Español ) Timezone: Europe/London (GMT+01:00)]

Hi Kirill

I skimmed over the above, it is fairly lengthy.

I think your title and initial statement are not quite the same thing: I don't believe the suggestion in your title makes much sense, but the suggestion in your initial explanation does.

Custom styles and scripts with Layouts are currently added globally, to all pages, which means they are added to pages where they do not apply, amongst other things.

So adding custom CSS and JS on a per-Layout basis makes good sense, and in fact we already have a feature request for this, to which I will add your voice.

Note that certain cells, such as content templates and Views and archives and CRED forms already contain custom CSS and JS sections where you can add your styles and scripts that will only be added when they are used on the front-end.

Also, the Visual Editor cell is for adding any HTML, so can include inline styles and JS and even links to external stylesheets and scripts.

[Kirill]

Thanks for listening! Eager to see this implemented, would be a great feature to have.