Post by anaix3l on Jan 24, 2023 4:22:08 GMT -8
Perhaps this is a silly question, but I've never dug into what's under the hood of a forum or into LESS before this past weekend when I started modifying the existing theme for the first time in my life (so I'm probably going to have other other silly questions too, mostly in the "what does this button do? I've messed around to find out, but I'm still not sure what conclusions to draw" category).
Is there a visual guide (or any kind of guide for that matter) of what LESS variables correspond to what Visual editor options/ the other way around? And how do I prevent values set one way from getting botched when I switch to the other option?
Thanks!
I'm a very hands-on person and I find it easier to change stuff directly in the code than via a GUI. But not everybody is the same way and others may want to use the Visual Editor. So if someone tells me they've changed X via the Visual Editor, I'd like to know what that means in terms of what got changed in the LESS stylesheet.
Some I've already figured out, like @wrapper_width - if I change the Forum> Width > Width in the Visual Editor from 100% to 90%, the @wrapper_width value also changes to 90% in the LESS stylesheet. And the other way around, if I change the @wrapper_width value from 90% to 95% in the LESS stylesheet, it gets changed in the Visual Editor.
So far, so good... so what?
While I have mapped out some of these (more than those annotated in red below), I haven't been able to do it for all... that's a lot of variables to find in a stylesheet of over 1500 lines. Especially when I don't know what these variables are called.
So is there some sort of visual annotated guide like the one I've started below or, even better, a LESS stylesheet listing all variables that can be changed via the Visual Editor with comments like:
See the light grey ones? Calendar, Members and so on... I had a hunch those were light grey/ disabled-looking because they weren't in the LESS stylesheet, so I removed the @wrapper_width from the LESS stylesheet to test, both from where it was declared and where it was used.
It did turn light grey/ disabled-looking in the Visual editor and I also got an otherwise pretty cryptic error dialog:
I could however close the dialog and the forum look updates just fine even without that variable in there and in spite of getting slapped with the dialog on every update.
Now this variable is indeed in a section at the beginning that says:
So I guess that's why I'm getting slapped with that dialog... However, some of the other variables I've identified as corresponding to Visual Editor options (some of them even among those annotated on the screenshot above) are not in that section, but further down the page and nothing in the LESS stylesheet says whether a certain variable being declared can have its value modified from the Visual Editor.
Even more interestingly, if I now set a value for it from the Visual Editor, this value does not get set to a @wrapper_width variable in the LESS stylesheet. There's obviously nothing more set to that variable in there, so I never expected setting it from the Visual Editor in these conditions would still actually modify the forum look, but I thought setting it from the Visual Editor would add it to the LESS stylesheet. Well... I was wrong about that!
Hm, then what about the sections that were light grey from the beginning, before I modified anything?
I went to Pages > Calendar > Calendar View > Background Color and set it to some kooky value that's unlikely to show up elsewhere in the stylesheet, like a "burn your eyes" lime #00ff00. Saved, then switched to the LESS stylesheet and did a search for #00ff00. Sure enough, it found the value... set to a cal_background variable... along with a scroll value!
Wait, what?! I had not set the Pages > Calendar > Calendar View > Background Attachment value from the Visual Editor, neither of the two radio button options checked when I had saved the theme. Now I know that visually, having that scroll value there does exactly nothing as there's no background-image set and even if there was, scroll is still the default value for background-attachment, so whether it's explicitly written in the background shorthand or just omitted changes nothing visually. Which begs the question why even ever explicitly set it in the shorthand and not just set it to nothing when a scroll value is selected from the Visual Editor.
Interestingly, if I go back to the Visual Editor, the scroll radio button is now selected, even though it wasn't when I clicked Save after setting that lime background. I clicked the reset CSS source to default and repeated the setting a lime calendar background process a bunch of times just to make sure. Yes, setting a background-color there also automatically sets background-attachment to scroll.
And since they're both set to the same LESS variable and I suppose the other background-* properties available to be set via the Visual Editor would be as well, this means that there's no one to one correspondence between what can be set via the Visual Editor and LESS variables?!
---
On top of that, I've noticed some other weird things while tweaking the values in one way (either via the Visual Editor or the LESS stylesheet) and checking what happens when switching to the other tab.
Setting the @wrapper_width in % or px or em works fine whether it's done via the Visual Editor or the LESS stylesheet. I can also set it to 65rem in the LESS stylesheet and all looks fine in the Visual Editor. But if I then change it from 65rem to 67rem in the Visual Editor, then it somehow gets interpreted as 67px!
If I try to change it to something like min(100% - .5em, 65em) from the Visual Editor (on top of the field being too short to contain that, so I need to add some custom CSS to the Visual Editor page to make that field bigger), it gets auto-changed to 100%. By that, I mean 100% is the value I see when I switch to the LESS stylesheet. If I try to change it to the same min(100% - .5em, 65em) value from the LESS stylesheet... well, it gives me a red error message:
... and it won't let me save, in spite of min(100% - .5em, 65em) being perfectly valid CSS, supported in Safari since 2017 (for 6 years), in Blink browsers since 2019 (for 4 years) and in Firefox since 2020 (for 3 years). Now, as I've mentioned before, I knew absolutely nothing about LESS beyond the fact that it exists and variables have that @ in front. My first thought was that maybe this conflicts with a LESS min() function? So I looked at the LESS docs and yes, there's a min() function and since LESS is a preprocessor, it cannot do operations that mix units without a fixed relation between them (like % and em in this case). Okay, but CSS itself is not case-sensitive, so Min() should work just fine in the compiled code, while maybe not confusing LESS into thinking it's its own min() function that cannot mix % and em? Hm, nope. Is there any way of making LESS put it in the compiled CSS as it is? Perhaps something like:
Nope, same error. This is perfectly valid CSS, for Odin's sake! It's also something that's immensely useful for having responsive pages. Is there really no way to use calc(), min(), max(), clamp() and other CSS functions as values?
And if I can, is there a way editing them from the Visual Editor won't botch them as it's happening with rem values?
Or like it happens with CSS gradients as values for background-image. I can set:
... in the LESS stylesheet and it works just fine on the actual page. And it's the value I see in the value field (Forum > Background > Background Image) when I switch to the Visual Editor. However, if I then try to change the gradient to go to purple from the same Visual Editor Forum > Background > Background Image field, the value in the field auto-changes to inherit.
This is disheartening. Out of all the changes I've made to the theme this past weekend, switching from external image gradients to easy and fast to tweak CSS ones has been the most appreciated. A basic single CSS gradient background like the one above is pretty self explanatory even if you've never heard about CSS (when I first started tweaking CSS gradients and other pretty self-explanatory stuff, I didn't even know what I was changing was called CSS, I just knew I was changing how things look on a page). So it would be cool to have the option of tweaking gradients from the Visual Editor without digging into the LESS stylesheet. Digging directly into the stylesheet may be my default, but it's not everybody's default and I don't want to be the single point of failure, the one person who can modify something.
There is also no Visual Editor option to set the background-size, which is how the size of background patterns can be controlled. There are no space or round value options for background-repeat, nor a local value option for background-attachment. And this is just what I've noticed playing around for a weekend.
Is there a visual guide (or any kind of guide for that matter) of what LESS variables correspond to what Visual editor options/ the other way around? And how do I prevent values set one way from getting botched when I switch to the other option?
Thanks!
I'm a very hands-on person and I find it easier to change stuff directly in the code than via a GUI. But not everybody is the same way and others may want to use the Visual Editor. So if someone tells me they've changed X via the Visual Editor, I'd like to know what that means in terms of what got changed in the LESS stylesheet.
Some I've already figured out, like @wrapper_width - if I change the Forum> Width > Width in the Visual Editor from 100% to 90%, the @wrapper_width value also changes to 90% in the LESS stylesheet. And the other way around, if I change the @wrapper_width value from 90% to 95% in the LESS stylesheet, it gets changed in the Visual Editor.
So far, so good... so what?
While I have mapped out some of these (more than those annotated in red below), I haven't been able to do it for all... that's a lot of variables to find in a stylesheet of over 1500 lines. Especially when I don't know what these variables are called.
So is there some sort of visual annotated guide like the one I've started below or, even better, a LESS stylesheet listing all variables that can be changed via the Visual Editor with comments like:
@body_background_color: #000000; // Forum > Background > Background Color
@body_background_image: inherit; // Forum > Background > Background Image
@body_background_attachment: @empty; // Forum > Background > Background Attachment
@body_background_repeat: @empty; // Forum > Background > Background Repeat
@body_background_position: @empty; // Forum > Background > Background Position
@wrapper_width: 100%; // Forum > Width > Width
/* and so on, for all the LESS variables that can be changed via Visual Editor */See the light grey ones? Calendar, Members and so on... I had a hunch those were light grey/ disabled-looking because they weren't in the LESS stylesheet, so I removed the @wrapper_width from the LESS stylesheet to test, both from where it was declared and where it was used.
It did turn light grey/ disabled-looking in the Visual editor and I also got an otherwise pretty cryptic error dialog:
Cannot read properties of undefined (reading 'value')
Now this variable is indeed in a section at the beginning that says:
/* Required for proper functioning of the Colors & Theme Creator */So I guess that's why I'm getting slapped with that dialog... However, some of the other variables I've identified as corresponding to Visual Editor options (some of them even among those annotated on the screenshot above) are not in that section, but further down the page and nothing in the LESS stylesheet says whether a certain variable being declared can have its value modified from the Visual Editor.
Even more interestingly, if I now set a value for it from the Visual Editor, this value does not get set to a @wrapper_width variable in the LESS stylesheet. There's obviously nothing more set to that variable in there, so I never expected setting it from the Visual Editor in these conditions would still actually modify the forum look, but I thought setting it from the Visual Editor would add it to the LESS stylesheet. Well... I was wrong about that!
Hm, then what about the sections that were light grey from the beginning, before I modified anything?
I went to Pages > Calendar > Calendar View > Background Color and set it to some kooky value that's unlikely to show up elsewhere in the stylesheet, like a "burn your eyes" lime #00ff00. Saved, then switched to the LESS stylesheet and did a search for #00ff00. Sure enough, it found the value... set to a cal_background variable... along with a scroll value!
/* Calendar Page */
@cal_background: #00ff00 scroll;
@cal_border: 1px solid @container_inner_border_color;
@cal_border_radius: 10px;
@cal_inner_border: 1px solid @container_inner_border_color;Wait, what?! I had not set the Pages > Calendar > Calendar View > Background Attachment value from the Visual Editor, neither of the two radio button options checked when I had saved the theme. Now I know that visually, having that scroll value there does exactly nothing as there's no background-image set and even if there was, scroll is still the default value for background-attachment, so whether it's explicitly written in the background shorthand or just omitted changes nothing visually. Which begs the question why even ever explicitly set it in the shorthand and not just set it to nothing when a scroll value is selected from the Visual Editor.
Interestingly, if I go back to the Visual Editor, the scroll radio button is now selected, even though it wasn't when I clicked Save after setting that lime background. I clicked the reset CSS source to default and repeated the setting a lime calendar background process a bunch of times just to make sure. Yes, setting a background-color there also automatically sets background-attachment to scroll.
And since they're both set to the same LESS variable and I suppose the other background-* properties available to be set via the Visual Editor would be as well, this means that there's no one to one correspondence between what can be set via the Visual Editor and LESS variables?!
---
On top of that, I've noticed some other weird things while tweaking the values in one way (either via the Visual Editor or the LESS stylesheet) and checking what happens when switching to the other tab.
Setting the @wrapper_width in % or px or em works fine whether it's done via the Visual Editor or the LESS stylesheet. I can also set it to 65rem in the LESS stylesheet and all looks fine in the Visual Editor. But if I then change it from 65rem to 67rem in the Visual Editor, then it somehow gets interpreted as 67px!
If I try to change it to something like min(100% - .5em, 65em) from the Visual Editor (on top of the field being too short to contain that, so I need to add some custom CSS to the Visual Editor page to make that field bigger), it gets auto-changed to 100%. By that, I mean 100% is the value I see when I switch to the LESS stylesheet. If I try to change it to the same min(100% - .5em, 65em) value from the LESS stylesheet... well, it gives me a red error message:
Operation on an invalid type on line null
... and it won't let me save, in spite of min(100% - .5em, 65em) being perfectly valid CSS, supported in Safari since 2017 (for 6 years), in Blink browsers since 2019 (for 4 years) and in Firefox since 2020 (for 3 years). Now, as I've mentioned before, I knew absolutely nothing about LESS beyond the fact that it exists and variables have that @ in front. My first thought was that maybe this conflicts with a LESS min() function? So I looked at the LESS docs and yes, there's a min() function and since LESS is a preprocessor, it cannot do operations that mix units without a fixed relation between them (like % and em in this case). Okay, but CSS itself is not case-sensitive, so Min() should work just fine in the compiled code, while maybe not confusing LESS into thinking it's its own min() function that cannot mix % and em? Hm, nope. Is there any way of making LESS put it in the compiled CSS as it is? Perhaps something like:
@wrapper_width: ~"min(100% - .5em, 65em)"Nope, same error. This is perfectly valid CSS, for Odin's sake! It's also something that's immensely useful for having responsive pages. Is there really no way to use calc(), min(), max(), clamp() and other CSS functions as values?
And if I can, is there a way editing them from the Visual Editor won't botch them as it's happening with rem values?
Or like it happens with CSS gradients as values for background-image. I can set:
@body_background_image: linear-gradient(90deg, black, midnightblue)... in the LESS stylesheet and it works just fine on the actual page. And it's the value I see in the value field (Forum > Background > Background Image) when I switch to the Visual Editor. However, if I then try to change the gradient to go to purple from the same Visual Editor Forum > Background > Background Image field, the value in the field auto-changes to inherit.
This is disheartening. Out of all the changes I've made to the theme this past weekend, switching from external image gradients to easy and fast to tweak CSS ones has been the most appreciated. A basic single CSS gradient background like the one above is pretty self explanatory even if you've never heard about CSS (when I first started tweaking CSS gradients and other pretty self-explanatory stuff, I didn't even know what I was changing was called CSS, I just knew I was changing how things look on a page). So it would be cool to have the option of tweaking gradients from the Visual Editor without digging into the LESS stylesheet. Digging directly into the stylesheet may be my default, but it's not everybody's default and I don't want to be the single point of failure, the one person who can modify something.
There is also no Visual Editor option to set the background-size, which is how the size of background patterns can be controlled. There are no space or round value options for background-repeat, nor a local value option for background-attachment. And this is just what I've noticed playing around for a weekend.
