Schwebach: Would be nice if css had a parent selector but I can imagine that getting abused horribly
Seman: Maybe. The problem isn’t that, though. It’s speed.
Anis: I think there was a proposal for something like the parent selector but more limited. Basically at a given element, select it only if children have some property cl*** or whatever.
Brighter: Well, internally css is p****d right to left, looking at the child before looking to see if the parent matched
Talerico: You don’t walk back up, just walk down to find stuff.
Pizzolato: So if you write a “.parent .child { background: red; }” the css engine first looks for every .child and then checks to see which has a .parent
Kudla: The problem is number of combinations and such. What happens if you were able to do “div span + foobar blargh” for example. or replace + with ~.
Dayer: You have made checking for matches much more complex than just going back up and determining that all parents satisfy.
Delmar: The two proposals I saw to fix this was a target indicator and a “has”. The target indicator was applied to part of a regular selector and said “when you match this selector, apply the styles to the element with the target indicator”. The other said “from this element, match it only if the items inside the ‘has’ clause match on any children” or something like that.
Avellar: Both of these are, in theory, simpler.
Sponholz: And they cover what people seemed to really want anyway.
Retchless: Do I think we’ll ever see them? No. They can’t even finish implementing things already on the table. :
Propst: WebKit/Blink or whatever still has things that haven’t been unprefixed that other browsers finished a long time ago.
Felsenthal: IE is implementing more and more things under Edge but nothing out there.
Banks: It’s one of those things that eventually we’ll see broken implementations with vendor prefixes and it’ll take a few years to settle
Anthony: Nah, no prefixes. Those have been dropped.
Jerrell: Things that already have them will keep them until they’re unprefixed completed but browsers now put things behind preferences.
Dieguez: You have to enable the preference to use it until it is completed and moved to live.
Wylam: I can’t. They might be slow on some things and prone to writing bugs but neither Blink or WebKit devs would implement something that fugly.
Spotwood: It would be behind a “secret” preference option buried in Chrome or whatnot.
Panagakos: Once there is some sort of likely standard it wouldn’t be too hard to write a polyfill
Jazwa: You can read a bunch of articles online why prefixes have gone the way of the dodo. They were kind of flawed.
Oblow: Polyfill for this sort of thing might be even slower than the browser itself.
Kurgan: Shrug, I’m still running into prefixed crap even now
Marlow: I didn’t say it went away for existing things.
Kaines: I mean no new things are being introduced in testing with prefixes.
Steuer: Pollyfill will never be as fast as native, but better than not having the feature at all
Kissel: I’d prefer usually not to use stuff that needs to be polyfilled if I can work around it. That way I don’t have to implement something twice.
Angleton: When we really needed it was several years ago.
Stakem: Yep, back when everyone was doing the ie css hacks
Synan: Bah. I should really be designing this token I’m working on. darn distractions! š
Candozo: I’m only about halfway through it, maybe. Kinda hoping to get it fabbed this week so definitely needs to get done. :
Colten: Is there a way to markup a link that points to the active page?
Goehner: Iām at /about/ and i want to style the link to /about/ in the nav
Fenton: By ‘the active page’ you mean the current URL?
Fenton: Can you add something to body that indicates what the current URL is?