Support of nesting selector Topic is solved

[WarpEnterprises]

The webpage https://connect.garmin.com/modern has a sidebar menu which is broken in PaleMoon. Only the latest Chromium will display correctly.
When inspecting the styles it displays something like this:

Code: Select all

animation: MainSidebar_expanding__pdaOE 250ms ease;
&.MainSidebar_collapsed__JUDKb { animation: MainSidebar_collapsing__S3tF0 250ms ease 200ms 1 normal forwards;  <== invalid property value

The CSS looks like this:

Code: Select all

animation: expanding 250ms ease;
&.collapsed {
   animation: collapsing 250ms ease 200ms 1 normal forwards;
}

Can someone check if this feature is implemented in PaleMoon?
https://developer.mozilla.org/en-US/doc ... g_selector

[Moonchild]

No, we don't support this.

What's wrong with using

Code: Select all

.elementrule {
animation: expanding 250ms ease;
}

.elementrule .collapsed {
   animation: collapsing 250ms ease 200ms 1 normal forwards;
}

like has been the standard for many years?

[Enobarbous]

Usage examples from mdn:

Code: Select all

.example {
  font-family: system-ui;
  font-size: 1.2rem;
  & > a {
    color: tomato;
    &:hover,
    &:focus {
      color: ivory;
      background-color: tomato;
    }
  }
}

Code: Select all

.card {
  /* .card styles */
  .featured & & & {
    /* .featured .card .card .card styles */
  }
}

Damn it.
What kind of crap have they turned css?

[back2themoon]

Only the latest Chromium will display correctly.

Have you contacted them? Informing them that not everyone uses those browsers?

[WarpEnterprises]

Yes, it's not only me who is annoyed
https://forums.garmin.com/apps-software ... disappears
And it's not only PM.
And of course "we didn't change anything, it must be on your side"
@moonchild I'm not that fluent with CSS, but it probably comes down to "we must use the latest shit".
At least I found the cause of the problems - thanks for clarifying!!

[Moonchild]

Garmin is probably using a framework of some sort, and the framework devs are (once again) not being browser-agnostic because "new shiny, must use". Maybe they didn't consciously change anything on their end, BUT "updated" the framework to the latest available release, causing this issue.

This attitude of pushing always for "only the latest version of biggest market share browsers" by frameworks and library developers is and has been concerning for a long time -- and can be traced all the way back to JQuery, actually. They started this trend, AFAIK.

The problem is that framework devs vehemently defend "using modern technologies" because they want to keep up the image, completely forgetting that their frameworks are being used by 1000s of webmasters who do not necessarily have the knowledge to fix this, have invested in using their framework, and are effectively losing visitors as a result.
You may also insert various theories here about anti-competitive angles, especially when looking at frameworks released by e.g. Google (Angular) who benefit from pushing for "latest Chrome or bust" of course.

[Moonchild]

By the way, before anyone asks: no it's not at all easy to change the way a parser works from linear scope parsing to nested scope parsing. Our CSS parser is already very complex as it is, due to the ambiguity and extent of the CSS standards. Converting that to something supporting nesting is a headache I can't even imagine right now.
Nested scopes introduce a whole can of worms programmatically: extensive error checking, recursion (!), back-referencing, stacked/duplicate keywords, especially if shorthands are in use (merge or overwrite?), I can go on...

[Lootyhoof]

This is literally just SCSS (Sass). I'm not sure why CSS is turning into this when that already exists...

[Enobarbous]

By the way, before anyone asks: no it's not at all easy to change the way a parser works from linear scope parsing to nested scope parsing. Our CSS parser is already very complex as it is, due to the ambiguity and extent of the CSS standards. Converting that to something supporting nesting is a headache I can't even imagine right now.

Hmm. If this selector is used for shorten the record, can't we just modify the css file before it is processed by the engine, instead of making changes in the parser?
Basically we just need to check the css for "&" and if it is present, transpile the file. It doesn't seem too complicated or expensive in terms of performance.

At the simplest level, I think if mess around with regex a bit, can figure out a replacement rule for modify http response....

[vannilla]

Hmm. If this selector is used for shorten the record, can't we just modify the css file before it is processed by the engine, instead of making changes in the parser?

Or, hear me out, devs could just use SCSS like Lootyhoof pointed out and not introduce nested CSS declarations as part of the syntax.

[Enobarbous]

Or, hear me out, devs could just use SCSS like Lootyhoof pointed out and not introduce nested CSS declarations as part of the syntax.

Oh, believe me, I would be all for it. Unfortunately, it's part of the standard now...

Off-topic:
Even if it looks like overcompensation of something

[back2themoon]

If I get this entire, dire situation correctly... the problem is there is no "standard" as such any more. It kind of of an "evolving standard", constantly in motion and worse: subordinate to players like Google etc.

There is no truly independent and authoritative authority/organisation (phrase sounds weird, but seems ok) that can enforce a strict, stable standard on those few browser engines and browser makers out there. The whole thing a moving part, dictated more or less by unreasonable interests and situations.

It'd be nice to have such a strict WWW standard that changes, say, once or twice per year: "This and that changed, and you should ALL adhere to that. Nothing is deprecated until we say so and there's good, valid reason to. Anything else is out-of-spec and should never be mandatory without a fallback to the standards". Or something like that.

[Moonchild]

If this selector is used for shorten the record, can't we just modify the css file before it is processed by the engine, instead of making changes in the parser?

Basically asking us to natively parse SCSS when parsers for that already exist? Why?

[Moonchild]

There is no truly independent and authoritative authority/organisation (phrase sounds weird, but seems ok) that can enforce a strict, stable standard on those few browser engines and browser makers out there.

We used to have something like this with the old WWW consortium... until big players started buying influence and then taking over the standards bodies (looking at you Google) becoming a rapidly-changing mess of specs that "describe what implementers do" instead of setting standards, leading to the monoculture we're a hair away from now because of the descriptive nature of pseudo-standards webmasters and frame devs are using without fallback.
The web also used to be a place where webmasters and web devs understood that websites should be functional and broadly accessible to a variety of browsers, but the segregation between front-end web devs and framework devs caused a setup where everyone can blame everyone else when shit doesn't work, instead of actually providing solutions.

[back2themoon]

Seems unusual no one ever bothered to take this whole thing up legally, in a massive way. Or perhaps they did, and failed. Or perhaps it's too technical and the Internet "just works" so all good and no one really cares (I doubt it though - I know many care, not just us).

[Moonchild]

Seems unusual no one ever bothered to take this whole thing up legally, in a massive way. Or perhaps they did, and failed. Or perhaps it's too technical and the Internet "just works" so all good and no one really cares (I doubt it though - I know many care, not just us).

They did, it was both too technical for lawyers to understand and it failed, as well as being considered too fast/dynamic to take up because of how slow the (especially US) legal system works. I worked with the UK authoritative body that was supposed to have oversight over these things and clearly explained this issue to a panel of "experts" in various fields but before it even got to court it was watered down to something only relating to google search and advertising revenue, completely missing the mark.

[back2themoon]

Right. The usually well-paid "experts". It's always them blocking the way, isn't it...

[Enobarbous]

Basically asking us to natively parse SCSS when parsers for that already exist? Why?

Well, with the inclusion of "nesting selector" in the css spec we basically get 2 ways:
1) implement its support in the parser - which is impractical and requires a huge amount of work;
2) just ignore it and hope that the selector won't be used too often in the wild - and what are the chances of that?
My idea is that since this is a shorthand selector - it does not bring new functionality - instead of changing the parser, you can just add a transpilation layer.
Of course, this is far from optimal, in some cases this approach can lead to the wrong "specificity weight" for elements, performance can suffer - but I think this is the lesser evil.
And I have not thought about full support of scss (except for a proof of concept using an existing library). Just about the functionality of this selector.

P.S. Yes, of course, I too would prefer that developers just not drag sass syntax into vanilla css. But I doubt that will happen... There's already a draft of the “CSS Functions and Mixins Module”...

[FranklinDM]

I haven't looked into it yet, but preprocessing the CSS file could also be an option.