Not planned Designer mode improvement

[CyberAP]

It struck me hard when I found out that Designer mode outputs all the changed templates, but still uses css.php to serve CSS code. Since all modern browsers support LESS for development (at least with js plugin) I see no reason using plain compiled CSS when designer mode is enabled. That would require 2 changes to the system:

1. Designer mode always writes down all the templates, including unmodified ones (we could separate modified files with a star at the end of filename, since the system knows what's changed and what's not that should be possible in theory).
2. css.php is replaced by direct .less template calls, which mirror the css.php functionality. So instead of 2 calls for core css and page css you get about ≈20 less calls. This is absolutely useless in production, but a huge improvement for development.

Please note that this suggestion is different from this one: https://xenforo.com/community/threa...d-skyrocket-style-development-for-xf2.134907/
This suggestion focuses primarily on designer mode, which is limited to 1 style. And the linked one is for any style, even without designer mode and debug enabled.

 

[CyberAP]

This is even more important with upcoming Workspaces 2.0 in Chrome 63.

To view this content we will need your consent to set third party cookies.
For more detailed information, see our cookies page.

Accept third party cookies

 

[Mike]

I think I'm going to say that this is "not planned" for the most part. There are 2 distinct suggestions here but they both have reasons they are unlikely to happen.

Outputting all templates regardless of customization
We thought about this quite a lot when designing the system and ultimately felt that only writing templates that are customized out was the only way to go.

Writing out all files leads to situations where templates become customized unexpectedly, particularly with an older version of a template. Essentially it creates ambiguities. You did imply one method of getting around that which is to use something to indicate whether a file is customized, but we felt that this would also create confusion. It doesn't entirely eliminate the previous issue as it may also lead to situations where the "default" template is different from the default in the database.

Direct LESS calls
This won't happen because we have some layers of functionality on top of LESS including use of template syntax, support for XF options, style properties, custom LESS functions, and RTL swapping (which is implemented as a plugin for our LESS parser).

We could split the CSS out into individual calls, but it still needs to go through our processing.

 

[CyberAP]

That's a very solid reasoning and I can understand that. Unfortunately that means that you can't completely move all the template editing to IDE, which I was really hoping for. And current CodeMirror editor is far from perfect IDE replacement, but I believe it will gradually improve.