Use option A: uikit uk-width... to avoid ProcessWire 3.0.184 inline style widths and maxColHeightSpacer

[Chris Bennett]

Hi all, have just upgraded to 3.0.184, a little late to the party.
Not sure about a few things and would love to understand better.

It seems to me like there is now an increased over-reliance on inline style width declarations on Inputfields.
To me, they seem like extra bits of unnecessarily specific css that impede easily customisable CSS.
I can't wrap my head around why they are needed.

Surely CSS and flexbox can do this better, easier, with much greater flexibility, less javascript, less thread work, less bytes and less layout shifts?

In previous versions, data-colwidth on everything with a width worked just fine.
Was very easy to target li[data-colwidth] and use calc to add a margin if desired and use flexbox to flex like a champion, taking up available space.
Lovely, simple, flexible and lightweight. 

Now it seems some wrappers have a style="width: ..." where once they had data-colwidth and some Inputfields have data-original-width. 
Each can technically be over-ridden using ...sigh... a multitude of repetitive !important declarations, but that is not ideal.

Is there something I am missing? Is there a reason the inline width styles were needed?
Is there a benefit I am unaware of? Can I help provide possible alternate solutions to whatever use case necessitated it?

In a similar vein, I also got to see maxColHeightSpacer for the first time.
Can't say it was a pleasure for it to appear.

Similar to the use of inline style="width:..." on Inputfields, in the age of flexbox I don't understand why a spacer div with inline height is needed.
Is there a need for it I just don't get? 

Hadn't seen it before but found some info from a few years ago here:

Anyway, I would honestly love any insight on any of this.
Would love to understand the 'why' and, if possible, help. 

[Robin S]

14 hours ago, Chris Bennett said:

It seems to me like there is now an increased over-reliance on inline style width declarations on Inputfields.

As a general rule (not related to PW specifically), when you see an inline style in the DOM it's almost always an indication that the style was added by JavaScript. It's not because somebody has some preference for inline styles as such. So if you see an inline style in the PW admin it's probably because the style needs to be set dynamically by JavaScript (or needed to be at the time the admin theme was authored).

14 hours ago, Chris Bennett said:

Surely CSS and flexbox can do this better, easier, with much greater flexibility, less javascript, less thread work, less bytes and less layout shifts?

No doubt. But some of the bundled PW admin themes pre-date widespread browser support for flexbox. And fully overhauling a legacy admin theme would be huge job that I expect is not a major priority for Ryan.

14 hours ago, Chris Bennett said:

In a similar vein, I also got to see maxColHeightSpacer for the first time.
Can't say it was a pleasure for it to appear.

I haven't seen this in AdminThemeUikit, which is the most recently added core theme. If CSS3 features like flexbox are important to you then this is the admin theme you want to be using.

[Chris Bennett]

2 hours ago, Robin S said:

As a general rule (not related to PW specifically), when you see an inline style in the DOM it's almost always an indication that the style was added by JavaScript. It's not because somebody has some preference for inline styles as such. So if you see an inline style in the PW admin it's probably because the style needs to be set dynamically by JavaScript (or needed to be at the time the admin theme was authored).

No doubt. But some of the bundled PW admin themes pre-date widespread browser support for flexbox. And fully overhauling a legacy admin theme would be huge job that I expect is not a major priority for Ryan.

I haven't seen this in AdminThemeUikit, which is the most recently added core theme. If CSS3 features like flexbox are important to you then this is the admin theme you want to be using.

Thanks Robin, I appreciate your comments.

I have never used any theme apart from AdminThemeUiKit and 100%, the inline styles are injected by js.
My confusion comes from them not being injected in this way in the previous master dev.

It's why I was surprised both the inline styles that hadn't been there previously and maxColHeightSpacer suddenly appeared after upgrading from 3.0.165.

In fact, looking again, both maxColHeightSpacer and style="width: 35%;" data-original-width="33" are being added on the same custom module.
Previously it had been a perfectly horizontally aligned radio inputfield, with a simple data-colwidth="width: 33%", which could be over-ridden easily allowing margins and borders and fun stuff.
On upgrade, it suddenly had a 24px vertical spacer div inserted underneath, flex alignment was thrown out, and the style="33%" meant it wouldn't flex properly any more.

Examples shown using my tweaked AdminThemeUiKit theme.
Admittedly, I have played around with AdminThemeUiKit for probably way too many hours.
I guess it has to be in the 1000's by now ...sheesh... That means very little, except to say I am pretty familiar with how it works, what it does and how it does/did it.

Results are the same in default AdminThemeUIKit.
Example: Post upgrade, pre addition of formerly unnecessary !important overrides.

Example: Post upgrade, after a long string of formerly unneeded !important declarations applied, back to what it had previously looked like.


But throughout the admin, wherever there was formerly a simple data-colwidth, there is now a new inline style declaration.

It's the new bit that I don't get.
I don't understand why the js injection wasn't necessary for 3.0.165 but needs to be there for 3.0.184.

[Robin S]

Check that the "Inputfield column widths" setting in the AdminThemeUikit module config is the same before and after the upgrade. If you want to avoid the JS-set widths then I think you want the "Uikit uk-width classes" option.

 

[Chris Bennett]

1 minute ago, Robin S said:

Check that the "Inputfield column widths" setting in the AdminThemeUikit module config is the same before and after the upgrade. If you want to avoid the JS-set widths then I think you want the "Uikit uk-width classes" option.

 

Thanks Robin, I will have a play with that. Anything to help me avoid the pain and unnecessary layout shift is welcome.
That said, I was definitely previously using the Percentage based widths option.

[Chris Bennett]

6 minutes ago, Robin S said:

Check that the "Inputfield column widths" setting in the AdminThemeUikit module config is the same before and after the upgrade. If you want to avoid the JS-set widths then I think you want the "Uikit uk-width classes" option.

 

Sweet! ? I love your work and many, many thanks!

Although I am disappointed not to be able to use Option B: Percentage based, this at least got rid of the plethora of inline width declarations and the very unwanted maxColHeightSpacer div.
Also helps narrow down where the issue might lie.

Maybe something about the upgrade has 'reverted' the B option to use the older js inline width and height declarations?
Or perhaps a newly added feature to deal with some use-case.

Either way, I am stoked for your help and mightily relieved.
Love your work, you are a legend!