CSS question...or disappointment

[Kirill N]

2 minutes ago, Stuart Silvester said:

Personally, when I'm theming or updating CSS for something on my site, I'm in the browser inspector for most of time. Looking at how the relevant rules interact with each other and determining which change I want to make to achieve my goal.

Browser inspector isn’t very helpful when it comes to responsive elements. Not to mention that it takes 10x more time than just searching for the element in the theme editor.

[Kirill N]

This was such a bizarre choice. I now pretty much have to re-write half of the theme AND keep everything in one file AND do it without any reference.

Ridiculous.

[Jim M]

1 hour ago, Kirill N said:

Browser inspector isn’t very helpful when it comes to responsive elements. Not to mention that it takes 10x more time than just searching for the element in the theme editor.

It's a little more work but simply re-sizing your browser window to the correct size will show the responsive CSS in use. I personally work on breakpoints when it comes to these things so work on one window size at a time (e.g. mobile, tablet, or desktop) and it is not cumbersome.

Additionally, you can use the "Source" tab in the browser inspector to see the full source file.

If you would like to review the CSS, our self-hosted customers still have access to Designer's Mode which allows you to do so.

[Kirill N]

6 minutes ago, Jim M said:

It's a little more work but simply re-sizing your browser window to the correct size will show the responsive CSS in use. I personally work on breakpoints when it comes to these things so work on one window size at a time (e.g. mobile, tablet, or desktop) and it is not cumbersome.

Additionally, you can use the "Source" tab in the browser inspector to see the full source file.

If you would like to review the CSS, our self-hosted customers still have access to Designer's Mode which allows you to do so.

It’s not a little more work — something that used to take literally 10 seconds would now require to writing multiple lines of code.

Just to illustrate, let’s say I want to change the size of userpics in topic view from 90x90px to 120x120px. Before 4.7, I could simply search for “ipsUserPhoto_large” and change “90” to “120”. Takes about 20 seconds.

What’s the correct way of doing that in 4.7?

Edited September 19, 2022 by Kirill N

[Marc Stridgen]

51 minutes ago, Kirill N said:

It’s not a little more work — something that used to take literally 10 seconds would now require to writing multiple lines of code.

Just to illustrate, let’s say I want to change the size of userpics in topic view from 90x90px to 120x120px. Before 4.7, I could simply search for “ipsUserPhoto_large” and change “90” to “120”. Takes about 20 seconds.

What’s the correct way of doing that in 4.7?

You would add a selector for ipsUserPhoto_large to custom.css. It needs to be pointed out that what you have suggested there that would take a short amount of time, was not the recommended way of changing things such as this in any version.

[Kirill N]

2 minutes ago, Marc Stridgen said:

You would add a selector for ipsUserPhoto_large to custom.css. It needs to be pointed out that what you have suggested there that would take a short amount of time, was not the recommended way of changing things such as this in any version.

Would the code be

.ipsUserPhoto_large {
    width: 120px !important;
    height: 120px !important;
}

?

[Jim M]

2 minutes ago, Kirill N said:

Would the code be

.ipsUserPhoto_large {
    width: 120px !important;
    height: 120px !important;
}

?

custom.css is loaded last so typically, won't even need the !important. I would advise reading through some CSS documentation if you are unfamiliar with how selectors get inherited and overwritten from stylesheet order.

[Kirill N]

2 minutes ago, Jim M said:

custom.css is loaded last so typically, won't even need the !important. I would advise reading through some CSS documentation if you are unfamiliar with how selectors get inherited and overwritten from stylesheet order.

The point is, editing something as minor as image size should not be this complicated and should not be done by adding multiple lines of code on top of existing code.

Creating a custom theme should not require pretty much re-writing the existing css from scratch.

[opentype]

1 hour ago, Kirill N said:

Just to illustrate, let’s say I want to change the size of userpics in topic view from 90x90px to 120x120px. Before 4.7, I could simply search for “ipsUserPhoto_large” and change “90” to “120”. Takes about 20 seconds.

It was always wrong though. You would change a core file and so every future update of that file would cause an unnecessary conflict. Adding an override in the custom.css was always the right solution. So, the change just prevents you from doing it the wrong way. 

[Kirill N]

2 minutes ago, opentype said:

It was always wrong though. You would change a core file and so every future update of that file would cause an unnecessary conflict. Adding an override in the custom.css was always the right solution. So, the change just prevents you from doing it the wrong way. 

Fixing something is always the better option that patching something.

Just because the custom file doesn’t get updated this way doesn’t make it the “right” solution.

[Rikki]

Set it in custom.css and then you'll never have to worry about conflicts or updates again.

Quote

should not be done by adding multiple lines of code on top of existing code

That's literally how CSS works (the C stands for Cascading).

[opentype]

1 minute ago, Kirill N said:

Just because the custom file doesn’t get updated this way doesn’t make it the “right” solution.

This is EXACTLY what makes it the right solution. This file was specifically created for this purpose. It even says so when you open the file. 

/**
 * This file is for your custom CSS.
 * This file is not modified or overwritten during upgrades
 */

This describes the purpose and why changes should only be made there.
You have no argument against that, because there is none. You are essentially just in denial. You are saying “if I was allowed to do it the wrong way in the past, you better let me keep doing it the wrong way”. And ironically, this practise is NOT an argument to revert the change, but instead an argument to make sure that this practise is indeed being stopped. 

[Kirill N]

15 minutes ago, opentype said:

This is EXACTLY what makes it the right solution. This file was specifically created for this purpose. It even says so when you open the file. 

/**
 * This file is for your custom CSS.
 * This file is not modified or overwritten during upgrades
 */

This describes the purpose and why changes should only be made there.
You have no argument against that, because there is none. You are essentially just in denial. You are saying “if I was allowed to do it the wrong way in the past, you better let me keep doing it the wrong way”. And ironically, this practise is NOT an argument to revert the change, but instead an argument to make sure that this practise is indeed being stopped. 

That makes it the Invision-preferred solution or upgrade-friendly solution, not the right one.

Saying that it’s the right solution because it makes upgrades easier is like saying that cutting off your arm is the right solution to losing body weight.

 

But clearly I’m in the minority here and the Invision stuff will (rightfully) do whatever they please so arguing is pointless. This new version just isn’t for me.

Edited September 19, 2022 by Kirill N

[Charles]

Just now, Kirill N said:

That makes it the Invision-preferred solution or upgrade-friendly solution, not the right one.

Saying that it’s the right solution because it makes upgrades easier is like saying that cutting off your arm is the right solution to losing body weight.

 

But clearly I’m in the minority here and the Invision stuff will (rightfully) do whatever they please so arguing is pointless. This new version just isn’t for me.

We didn't make this up 🙂 we modeled it after literally every SaaS service out there.

I might submit that an "upgrade-friendly solution" is 100% what we should always choose.

[Kirill N]

15 minutes ago, Charles said:

We didn't make this up 🙂 we modeled it after literally every SaaS service out there.

I might submit that an "upgrade-friendly solution" is 100% what we should always choose.

What is the reasoning for not making the CSS at least viewable in the editor?

Edited September 19, 2022 by Kirill N

[Luuuk]

4 hours ago, Kirill N said:

That’s understandable but we need to be able to VIEW them to know what we are supposed to edit

 

56 minutes ago, Kirill N said:

What is the reasoning for not making the CSS at least viewable in the editor?

As stated, you can use the browsers inspector for this purpose. You can see all currently loaded CSS with their content in the inspector.

In Chrome Dev Tools > Network > select CSS only > click a selected request containing a name of CSS > Preview:

In Firefox Dev Tools > Styles Editor:

 

[Kirill N]

1 minute ago, Luuuk said:

As stated, you can use the browsers inspector for this purpose. You can see all currently loaded CSS with their content in the inspector.

In Chrome Dev Tools > Network > select CSS only > click a selected request containing a name of CSS > Preview:

Thank you, I appreciate the help. I’m aware how the Chrome inspector works, the issue is that it is not very helpful when it comes to responsive elements, and figuring out how something works through developer tools takes 100x times longer than just searching for a class in the editor.

[SeNioR-]

On 9/17/2022 at 3:18 AM, The Old Man said:

Absolutely agree, hiding the CSS templates is ridiculous! It was like a live, instant reference, so useful and tbh having realised, I'm unwilling to update the last of my live sites.

I personally understand this change because it "protects" templates and you can do more with them in the future.

We all want CSS and JS optimization after all, right?

However...

I agree that it makes editing a theme a bit difficult, if only because I sometimes need to look at core.css or framework.css to "make sure" if this or that class is responsible for it. Let's say that I want to make sure and see which class is responsible for the light background or, for example, check what tables I can use (messages.css), etc., so far I have checked it directly in the file, which was convenient and quick. Yes, I know that I can check it in the console or in the documentation,but it's about convenience and the fact that it used to take much less time.

Edited September 20, 2022 by SeNioR-

[Rikki]

Maybe y'all develop differently to me, but personally I wouldn't browse through a random CSS file to find classnames - there's no context (beyond the classname anyway; you don't get any of the cascade, inherited properties etc. that might affect it).

It makes much more sense to use the web inspector to see what is actually being applied to the element you want to change.

It may be a difficult transition at first but i would consider this an opportunity to improve your own development process.

[Rikki]

Also, you can still view the full (concatenated) CSS files in web inspector. Just click the filename:

Then the format button:

[DudeThatsErin]

This is very disappointing. I was trying to use this service to replace Shopify as Shopify is expensive so I was using the CSS files + editing the HTML files HEAVILY to hack together a theme that looks like a similar company's website.

Now, I can't do that. I feel as if I wasted my money as I would never have purchased if I even knew this was in the pipeline 6 months ago. Definitely not renewing. This is too expensive to not be able to mess with the files.

[Adlago]

@Rikki Reading this thread, which I created because "you cut off my quick glance" - I am left with the clear impression that you are making a huge mistake.
Most of your clients are not interested in this at all.
But the few "crazy like me" seekers and experimenters you want to banish. Why?

It's best to ban the themes too - let's all use only one - it will be heaven for your support...

[The Old Man]

4 minutes ago, Adlago said:

It's best to ban the themes too - let's all use only one - it will be heaven for your support...

Don't give them any more bright ideas! 🤯

[Adlago]

2 minutes ago, The Old Man said:

Don't give them any more bright ideas!

Well, at least they leave the colors to choose from...lol

Edited September 20, 2022 by Adlago

[Matt]

11 hours ago, DudeThatsErin said:

This is very disappointing. I was trying to use this service to replace Shopify as Shopify is expensive so I was using the CSS files + editing the HTML files HEAVILY to hack together a theme that looks like a similar company's website.

Now, I can't do that. I feel as if I wasted my money as I would never have purchased if I even knew this was in the pipeline 6 months ago. Definitely not renewing. This is too expensive to not be able to mess with the files.

You absolutely can still do that. You can still add as much custom CSS as you want. The only thing we have changed is to stop the bad practise of editing core CSS files. 
 

CSS cascades. That means we can set the colour of a selector to green, and you can add a cascading rule to change it to red. It’s how it’s always been.