Screen css

[rodrigogiraoserrao]

Closes #2137.
Adds CSS and CSS_PATH class variables to screens.

• Docstrings on all new or modified functions / classes
• Updated documentation
• Updated CHANGELOG.md (where appropriate)

@willmcgugan inside App._load_screen_css, why don't I traverse all the rules that were read and dynamically add a CSS selector to match the screen so that screen CSS only matches the screen it was imported from?

[willmcgugan]

If you were to push and pop the same screen multiple times, will it parse the CSS each time?

[rodrigogiraoserrao]

If you were to push and pop the same screen multiple times, will it parse the CSS each time?

No. That's why there is a _css_screens_loaded set and we check it before calling _load_screen_css.

What do you think of this:

inside App._load_screen_css, why don't I traverse all the rules that were read and dynamically add a CSS selector to match the screen so that screen CSS only matches the screen it was imported from?

[willmcgugan]

If you were to push and pop the same screen multiple times, will it parse the CSS each time?

No. That's why there is a _css_screens_loaded set and we check it before calling _load_screen_css.

That's a weak set, right? Does that not mean that as soon as you pop the screen (and it goes out of scope), it will forget that it parsed the CSS.

This may not be a problem, just wanted to understand.

What do you think of this:

inside App._load_screen_css, why don't I traverse all the rules that were read and dynamically add a CSS selector to match the screen so that screen CSS only matches the screen it was imported from?

Sounds like it may be worth exploring. Do you have an idea how you would implement it?

[rodrigogiraoserrao]

Sounds like it may be worth exploring. Do you have an idea how you would implement it?

I'd load and parse the styles into a separate stylesheet.
Then I'd traverse the rules there and modify the selectors to include the screen in the beginning.
Then, I'd add the new stylesheet to the app's stylesheet.

[willmcgugan]

Sounds like it may be worth exploring. Do you have an idea how you would implement it?

I'd load and parse the styles into a separate stylesheet. Then I'd traverse the rules there and modify the selectors to include the screen in the beginning. Then, I'd add the new stylesheet to the app's stylesheet.

Clever. Lets consider that for a future update.

[darrenburns]

This is such a huge footgun :(

[rodrigogiraoserrao]

I know. I wanted to try and restrict this via this suggestion but I don't think I'm supposed to go ahead and do it now... :(

[ndevenish]

I just shot myself in the foot with this footgun.

[darrenburns]

Nice 👍

[darrenburns]

This looks good to me. Small suggestion: this feels like a good candidate for a snapshot test which could make sure that screen CSS and CSS_PATH works and the precedence is as expected.

[rodrigogiraoserrao]

This looks good to me. Small suggestion: this feels like a good candidate for a snapshot test which could make sure that screen CSS and CSS_PATH works and the precedence is as expected.

I don't understand your suggestion. I have tests that check that the styles imported from the screen CSS and CSS_PATH variables are applied and with the correct precedence.
Are you saying that those would be better as snapshot tests?

[darrenburns]

Possibly, but you don't need to change them now. When I see tests that query the DOM and check styles it feels like it's trying to programmatically do something that snapshot tests give you for free.

[rodrigogiraoserrao]

Possibly, but you don't need to change them now. When I see tests that query the DOM and check styles it feels like it's trying to programmatically do something that snapshot tests give you for free.

Ahhh ok.
When I can, I do things programmatically because it is faster than running a snapshot test. (Right?)
Also, I had multiple variations of pretty much the same thing, so that's why I thought code was better 🤷
Thanks for your input!