#to see both shows blended into one [kinda like the avatar in a sense] was wonderful

[dorkynerd23]

NOT ALL CARTOONS NEED TO HAVE LORE AND BE STORY-DRIVEN

I just gotta say this real quick because it's honestly been on my mind lately and I think more people need to see this because this issue is kinda an ongoing problem with cartoons these days, especially with cartoons with high expectations from some people out there, and with the recent TCS hate that's been happening around lately on Twitter, I'd figure I make a post and give my thoughts and also give my thoughts on people who expect every cartoon now to be story-driven and have lore.

Not all cartoons need to be deep and serialized, have shipping, ect to be good and watchable, not every cartoon needs that and it isn't always necessary. I'm saying this because people still whine and complain about the reasons TCS and shows like it, (like BCG, TGAMM, and more) are just bad because it doesn't have deep storytelling and isn't dark, (Hell, some haven't even watched the show and given it a chance, and still call it shit) but it isn't really relying on that and besides, cartoons are supposed to be fun and give you a good and fun time, it shouldn't matter what the story is just as long as you're enjoying watching them. Now let me just say this, there's absolutely nothing wrong with liking shows that have lore, the issue is setting up high expectations for other shows and being upset because it doesn't have lore, not every show needs to be like Steven Universe, The Owl House, Amphibia, and so on, not all shows need that, AT ALL. Sometimes it's good and fine to watch characters going on wacky adventures and just be episodic and fun, not everything needs to be serialized to be good.

And also, let's not forget before shows like Avatar The Last Airbender came around, we always mostly had shows that were episodic and didn't take themselves all that seriously and we're just there to make you laugh and have fun. :) Trust me, I enjoy and love serialized shows (even though they aren't always my cup of tea, it depends sometimes) as much as others do, and I do get interested in what'll happen next and things to theorized in lore type of shows and enjoy seeing the world-building and strong storytelling. But, at the same time, sometimes I just wanna step away from serialized shows and just laugh and turn my brain off and a thing I love and enjoy about slice of life/episodic shows is rewatchability. And while yeah, overarching narratives can be rewatched, but it's kinda hard to pick out an episode in a serialized show because some episodes might include some important details that you might've missed and such and have to go back, if that makes sense. So most of the time I usually wait until a show ends to really catch up and watch them, since it's kinda difficult to watch a show that's still ongoing.

Now, even though I absolutely love and adore Cuphead and the show, I'm not gonna act like everything in the show works because it doesn't, there are some issues. TCS isn't perfect at all and is pretty flawed and there's things I hope they approve on if they get renewed hopefully, but I just wish some would appreciate the series more, because most criticisms I've seen of the show is that it's not like the game and doesn't have lore, which is criticisms I'm honestly sick of when it comes to shows like TCS. It's understandable if you don't like the show and just aren't a fan, but at least understand and see that not every cartoon needs to be grand and epic to be good and give actual reasons for not liking it! To conclude, I just think episodic shows should be more appreciated and deserve so much better, and it isn't fair for how people treat slice of life shows, it's okay to like and enjoy both serialized and episodic shows, they're both good and great in their own way.

Sometimes, all a cartoon needs is a blend of fun, comedy and along with heart, you don't always need a deep, grand epic story for cartoons. There's no need to fight and harass others over which one is better and more superior, just let people love and like what they love, let people enjoy their cartoons!

I'd totally recommend watching these videos by Alpha Jay Show + KashCash when it comes to my post, because I think they do a better explanation and talking about this ongoing issue in the cartoon community and the high expectations people seem to get when it comes to certain shows. Again, this isn't me trying to start a fight and harass anybody, I just wanted to give my opinion on this issue because it's really starting to be talked about on Twitter, so many people are really just tearing down The Cuphead Show for simply not being serialized. Even though as I've mentioned, not all cartoons need to be that and besides, shouldn't we remember that TCS is clearly trying to be based off 1930's cartoons, especially shows like Looney Tunes, Mickey Mouse + Disney cartoons, and Tom & Jerry. Which didn't take themselves seriously and we're just very simple and there to make you laugh and smile! They're also still very loved and appreciated by so many today and they didn't rely on anything big and epic, and give anything complex to be entertaining and enjoyable.

(Links To The Videos I've Mentioned!)

[Alpha Jay Show - https://youtu.be/0jSXat7kEa4]

(A Deep Dive Into The Awful Criticisms Of Cuphead)

[KashCash - https://youtu.be/UcB3ZtziXvg]

(Not All Cartoons Need To Have Lore)

[theswartzreport]

Musings: Buffy the Vampire Slayer

               “I Think I’m Kinda Gay”: Evil Willow and Duality in the Buffyverse

If you’re one of those people who sings through half of “Once More, With Feeling” in the shower, you may have found yourself dwelling on Evil Willow. To be clear, this is not Willow from the final two seasons - that baroque and self-contradictory jumble of ham-fisted addiction stereotypes and grief-as-anger manifestations warrants its own treatise. Rather, this is the alternate-reality Willow introduced in “The Wish” (S3 E9), after Anya grants Cordelia’s wish that Buffy had never come to town, and the world is transformed into Bizarro Sunnydale, complete with a leather-clad pansexual vampire version of Buffy’s bookish bestie.

First off, to state the obvious: Evil Willow is awesome. When she pops into the show’s restored reality in Doppelgangland (S3 E16), she serves as a counterpoint to Good Willow’s crisis of confidence. Appearing shortly after the unfortunate labeling of “Old Reliable,” Evil Willow’s swagger, style and unbridled sense of self causes her friends to sit up and take notice, to reconsider their treatment of her as a bland goody-two-shoes. She also turns the tables on a bullying jock, which is always good fun.

But therein lies the dichotomy and, indeed, the genius of the Buffyverse’s moral compass: Evil Willow is also, well, evil. She is a murderous vampire, one who tortures for her own pleasure, declaring “bored now” when a victim begs for mercy. The same lack of restraint that allows her to glory in her power and her sexuality, also frees her from even a hint of empathy. She is the negative framing of Spider-man’s creed: with her great power, she can elect to not take responsibility.

This blend of heroism and villainy, of kick-ass girl power and devastating consequences, is what always grounded the Buffyverse’s horror hijinks in recognizable moral reality. Reams have been written, courses taught, on Buffy herself as an inherently fascist avatar: like all superheroes who operate outside the bounds of law enforcement (or in Buffy’s case, Principal Snyder and the corrupt Watcher’s Council), her might makes her right, and she is unconstrained by societal strictures. When Faith goes rogue in Season 3, we see the damage that a slayer unbound can do, but we also root for Buffy (mostly) without reservation as she sets her own hierarchy of which demons must die, and which are more useful alive. With her blonde hair, blue eyes, and impressive roundhouse kick, she is the überfraulein, striking with the hand of God based on her own judgement.

This blurring of traditional roles is pervasive among the Scoobies: Xander is fiercely loyal and commonly coded as the “heart” of the group, while also being a sexist pig with a chip on his shoulder about being the only one without supernatural abilities; Giles manages to be both hidebound and a loose cannon, providing fatherly advice while eliciting childlike rebellion; Anya’s hilarious forthrightness about the idiocy of human customs highlights her other-ness and struggle to assimilate into humanity; and Spike is a master class unto himself on relative good within one person. Angel comes off as the simplest case, because his dividing line of a soul puts him squarely on the side of good, or bad, depending on how recently he’s experienced true happiness.

Which brings us back to Willow (Good Willow, the show’s in-universe Willow), and her last-second intervention to spare her doppelgänger from Buffy’s stake. Despite Evil Willow’s more outré tendencies, Good Willow still sees herself in her: she recognizes the loss of kinship and purpose beneath the soulless demon shell. Evil Willow serves as both warning and premonition, prefiguring Good Willow’s growing power, eventual fall from grace, and difficulty in separating boundaries worth breaking from those that cut her off from her innate goodness. (And the “I think I’m kinda gay!” foreshadow, a full year before Willow comes out, is still one of my favorite Whedonisms.) Like all the Scoobies – like all humanity – Willow contains darkness and light, and she has learned (through her lived experiences, her relationships, her faith, and her luck) how to tamp down the parts that don't fit her persona, or the ideals of her surroundings. When Evil Willow gives free reign to all of those sequestered traits, she releases the bad (murder, torture, lackey bullying) along with the good (her sexual identity, confidence, a taste for skintight leather). Good Willow suppresses her id to a fault; Evil Willow has let hers run free – and catches a splintered 2x4 in the heart for her troubles.

[superemeralds]

sonic forces review

EDIT: added day after thoughts under read more

Hey nyall! Time to review forces!

First, a broad, spoiler free, review. Under the cut will be a more in depth review containing spoilers for both, the main game AND episode shadow.

Please note that this is from the perspective of someone with adhd. I can’t tell how some of the things that peeved me would affect neurotypicals.

General info:

There is an easy and a hard mode. (hard mode is just normal mode “for ppl who played sonic before”) It took me 7 hours and 44 minutes to complete the entire game including episode shadow. Granted, I took quite a few breaks for breathers and shitpostingly liveblogging me playing the game on a discord server + I think I’m just bad at the game.

There are over 30 levels to play, of which a few did repeat and you just play with a different character, but it was still fun!

The hub map got increasingly confusing and hard to navigate and i really hate it now that i completed it because there’s too much happening at once on the screen.

Game play:

There was a Classic Sonic, Modern Sonic and Custom Character type game play.

I personally do not enjoy Classic Sonic game play but it was very well playable once I remembered I could use the arrow key pad instead of the left joystick.

Modern Sonic was often too fast in platforming sections and the absence of drift made sharp curves in 3D areas hard to handle, mainly when you activated boost (as the game intends you to). But it was very fun and refreshing to be able to boost again.

The Custom Character could use different wispons to do progress in the game. This is probably what has the most replay factor, as you can go back to levels using different wispons to clear new paths that you were previously unable to go through. The wispon use can be kinda sloppy at times, but once you get used to it it can be very fun.

The tag team game play was sloppy. It was never clear which character you are playing as right now (until later I realized you are playing both at the very same time ? I think? i am still confused).

Visuals:

The lighting in the cutscenes and levels often comes short and can even ruin the atmosphere at times. A lack of detail in some scenes undermines this. 

The characters are not as expressive as they could be, but there are some iconic expressions to spot throughout the game.

Sometimes camera angles shift weirdly or zoom out too much (some times the character even blends in with the stage and you don’t see it at all anymore when you are in movement) and you lose track of your character and most probably fall off the stage or get hurt. Sometimes there is also a little too much going on in the background.

On the contrary, the game had also tried to pull quite a few visually stunning shots and lighting in both levels and cutscenes.

It is overall still better than previous games because it has more heart and life in it and I hold it dear.

Overall feelings about the game:

The game had mostly been very fun! There was a lot of variety between stages and the wispons gave the gameplay a very fresh kick.

Some stages were frustrating because the character was too fast/very hardly visible for the platforming and I ended up dying a lot in the same spot. 

Not to say too much about the story, but Classic Sonic was pure fanservice and was not important to the plot whatsoever and the game would’ve done very well without him.

Character development was pretty absent.

The pacing of the game in general was very sloppy and almost even uncomfortably fast (rushed) and bland.

Most of the levels were very short to a point where you’d expect there to be multiple acts of it because you refuse to accept that this was already the end of it.

The story had some strong points, though, and the music was absolutely phenomenal, like always, BUT the music was not as recognizable as it was in previous games. I played the final boss only a very few hours ago and i cannot remember the tune to it at all.

The game had a lot of potential but it was executed rather sloppily than exceptionally.

All in all this game gets a 7/10 for effort from me.

because im very generous and i still had fun and was hyped and enjoyed it despite all the annoying parts. I mean i am also 06fucker69

Longer and more in depth review including spoilers under the cut

!!!! WARNING SPOILERS START HERE !!!!

I will try to stay in chronological order, but that is the first thing that is kinda peeving me in this game. 

(warning i quickly grew tired and couldn't write anymore but i forced myself to finish)

The time skips and flashbacks are inconsistent and have a harsh transition. For example the 6 months between Sonic’s defeat and the recruitment of the Rookie is just white text on a black screen that isn’t even narrated. Sometimes the time between perspectives is very disorted and you forget about Classic and Tails while you are busy with another mission that is forced upon you thanks to the linear 1 perspective story.

I would’ve had a 3 perspective story, with 3 story modes. Each story mode would explore the same story from the different perspectives like in SADX, SA2, heroes and Sonic the hedgehog 2006. (mostly 06 though)

The stages were perfectly arranged and build to be incorporated into a 3 perspective story. Classic might have had more time for character development and relevance. Also more, mostly consistent, time with him would make us more attached and feel actual emotions about his parting in the very end.

The idea of having Mania connect with forces like that and have a “reason” for Classic to appear is good, but Classic just arrives and is there. For not reason at all besides the sake of being there in order to please 2d/classic enthusiast fans. Great concept in theory, sloppily executed though.

Modern Sonic

The game play was very sloppy as Sonic just could fall off the stage and you just had a very huge lack of control of his speed. Mostly when you were in boost in a place that intended you to boost. The absence of drift was very unnerving.

The thing about Sonic being imprisonment was just. so..... unrealistically done. Sonic just came out of the cage and he’s been doing just fine. But he’s gotta be down, because couldn’t run. He absolutely hates being stuck in a place and it’s been SIX FUCKING MONTHS. The bars are also so far apart he can just slip out. Also Sonic can easily break out of prison.

This was not the first time he was imprisoned. In SA2 he had a far greater emotional response, and he broke out the moment he knew what he had to do to make things right. (He volunteered to be imprisoned in SA2, in forces he was forced in prison.)

This is not just out of character for him, but also very lazy writing. The time skip between was badly done, in a black screen with text. No context as to why Silver is suddenly here (if you didn’t read the comic you have no idea whats going on) or how the resistance formed.

Everyone thinks Sonic died, Knuckles is very upset and admits he cant get used to him being gone; and suddenly he gets the news that Sonic is fine and it doesn't trigger any emotional response in him. Or anyone really much besides Amy; who had refused to believe he died in the first place.

He just immediately goes on a mission and fights Infinite.

Tag Team

It was a very good idea to incorporate this mechanic and was mainly well done and fun; the double and triple boost was a nice lil kick off to regular gameplay.

As mentioned was it never clear who you are playing right now and it didn’t warn you about swiches. It could’ve been done better with the heroes mechanics of swicharound. There were more than enough characters to have multiple teams that could be playable.

Avatar

The custimization options aren’t spectacular, but that was not to be expected. I was positively surprised to have the option to chose between 3 voices. 

Villains

Chaos is. Just there. He wasn't even a boss. He was just there for the shock value/fan service.

The Metal Sonic fight was okay.

Zavok was annoying but okay and reasonable.

Shadow wasn’t even a bossfight he was also just shock-factor. He joined the team but was of very little value. (Except for DLC, will talk abt later.)

Infinite has 4 boss fights. And in the end he just vanishes. He’s basically still existent? I think? what happened? Are we just going to accept this?

The final boss was lame and not memorable at all. At least nega wisp phase 2 was iconic.

Infinite

Infinite is a very interesting character with much potential, which they sadly didn't really use much at all except for him being extra. He didn't show off much of his personality and we couldn't learn to appreciate/hate him. 

The game doesn't mention much about his origin, so you will have to read the online comic in the social medias to understand. This might be good marketing to get consumers to consume media on different platforms, but it does not make much sense for newcomers who know nothing about Sonic and don’t follow the social medias to begin with.

Someone who just picked up the game and it’s their first Sonic game.... They won't understand shit.

I want to see more of him. He got so much potential to grow and ultimately redeem himself. Maybe in a future game? Or in the comics at least.

Episode Shadow

The 3 levels were well. One time it was a sonic level but with shadow and some lil things changed. The other was a custom character level but with shadow. The other was just generic 2d platforming with cubes. None of these were long or new. It was fun, sure, but it wasn't exciting.

I was kinda peeved that even though infinite was revealed, we still didnt get to see his face.

Visuals

Lighting harsh, sometimes interesting, but not completely fleshed out/good/atmospheric. 

There are scenes/levels that have stunning visuals (the sonic level in space and the scene with the sun.) even when its not perfect.

Just. The characters sometimes float above the ground and the lighting is very white and harsh and not atmospheric. (The colors are meessed up and too bright. The characters look like they have a completely different light source from the environment)

EDIT: A DAY AFTER ADDITIONS

okay so a day after, replaying some stages, I still think the game is very fun.

There are quite a few things that are peeving me still. I just remembered the whole null space thing, which is totally wasted potential. You could’ve had a few levels in that space with fucky gravity and weird cube shit going, but you just had to double boost out and that was it.

Many tricks the villain packs out are treated as something they can oercome easily and they just. Win “because they always do”.

I want to see the heroes doubt themselves and have character development. The only character that does have character development at all is the custom character. Infinite arguably does undergo some development too; in episode shadow.

There is a lot of potentials for DLCs and I hope they release them and have more characters playable.

[coredrill]

ok, finished LoK s2 last night and it made me Feel Things:

first of all WHY are only the first two seasons on cbs??? why not have the rest of them as well??? y’all really gonna make me pay $8 for the nick channel on amazon huh 😤

listen…korra NEEDS to get her connections to the past avatars back. seeing aang and roku and kyoshi disappear hit me fucking HARD. like???? oh my god. oh my GOD. i don’t have the words to process this right now because i don’t even know how to quantify such a loss. god. FUCK.

overall i liked it though! not as much as i liked s1 but i still enjoyed watching it!

give 👏 asami 👏 more 👏 screentime!!!! every time she shows up i’m reminded of how much i LOVE her but then she disappears for the next three episodes 😭 she would probably be my favorite character if she showed up more!

but since she doesn’t, i think my favorite character is tenzin. he’s just such the perfect comedic blend for me and i LOVED that they showed his nuanced relationship with kya and bumi and how him being aang and katara’s only airbending child made them feel like he was the favorite. i loved that they talked about how much pressure tenzin felt trying to both rebuild an entire race / culture AND live up to aang. i loved his conversation with aang in the spirit world. he’s just. SO GOOD.

also if anyone touches his little family of airbending kiddos they are gonna feel my WRATH. they are PRECIOUS 🥺

alright i Have to mention it but. me thinking that korra / mako was over after episode three was literally 🤡🤡 LIKE! i am boo boo the fool here!!!! PLEASE let korrasami be next season PLEASE—

korra’s journey this season felt super earned and she hit such highs and lows and i loved it. i feel like she grew more in this season than s1 and i enjoyed it!!

also i personally loved the wan episodes. the animation, first of all, was GLORIOUS. and everything about his story was SO GOOD. the fact that he chose to be good and unite the humans and spirits and collect all the elements…i loved it!!!

(also, a quick aside: i feel like one of the best strengths that the show has as a whole is that it doesn’t do nostalgia for nostalgia’s sake. i definitely wouldn’t have been able to appreciate it if i had watched the show any earlier, i.e. before the sw reboot mess and e*dgame. LoK is clearly a different show from atla, and it has the utmost respect for its predecessor. it expands the worldbuilding and builds on the work of atla without throwing in blatant fanservice. i just love that SO much.)

…but my previous point just makes the moments of fanservice, which are few and far between, honestly worth it! like with general iroh, when he opened his mouth and it was zuko’s voice. i love that so much 🥺 and with seeing og uncle iroh in the spirit world! it made sense to his character and it warmed my heart lol.

and now to talk about mako and bolin, lmao. i feel like mako doesn’t have a whole lot of personality, and i mostly like him, i just don’t like his ~romantic~ storylines (a.k.a. he’s kissing korra! but dating asami! but has feelings for korra! and now he’s dating korra! and broke up with korra! so now he’s kissing asami! but korra’s back so he’s kissing her again! like make up your mind dude!!!). also i am CONVINCED that there is something shady going on with him. he said in s1 that a firebender killed his parents, but…wouldn’t one of his parents have to BE a firebender? and the other an earthbender? in order to birth both mako (firebender) and bolin (earthbender)? and they would, y’know, fight back? idk, maybe i interpreted wrong, but something seems off with that story.

bolin owns one single brain cell and i feel line 95% of the time, he’s loaned it to one of his friends (asami). i really liked him in s1 but in s2 he was kinda annoying with the whole propaganda storyline (which i thought atla did way better when aang went to that fire nation school). i’m hoping that s3 bolin gets back on track lmao.

but yeah, overall i’m excited to keep watching!!

[kendrixtermina]

Baby Reacts to: “Voltron Legendary Defender”

I’m not familiar with either of the show’s previous incarnations but from what I’ve heard they completely overhauled the characters anyways - supposedly Pidge was once an annoying tagalong kid (and a boy), Keith was a standard issue “hot-blooded mecha pilot”, Shiro was not there, or killed of in the first storyarc, and Allura was a completely different character with a wholly different design, more of a ‘princess classic’ with the looks & personality to macth, supposedly they redesigned her to make her more alien & then threw in the skintone as a hommage to her voice actress. In any case only the name is the same. 

I’ve seen some clips and it seems they had a much more outwardly fantasy-aesthetic going on with carriages & period costume, sort of more like Star Wars or Sailor Moon,  whereas the newest version seems roughly Star Craft esque in terms of their particular blend of Magitek. 

Otherwise it’s pretty straighforward: Evil Empire, Ancient Artifacts, Giant Robots, Space Fights, timefrozen hightech city left behind by the precursors etc. 

The evil empire has a renegate splinter faction but that too isn’t so exceptional (though welcome), the BoM reminded me somewhat of the Tok’Ra from Stargate in their reclusive, slow-to-act approach in that they have tons of futuristic tech but limited ressources & had to be won over first & there still being a lot of mutual distrust on both sides, at least at first.  

Rare in this day and age (and very refreshingly IMHO) the show unapologetically sticks to the basic genre & tropes without falling over its own feet trying to be clever  & meta - sure, they evened out the gender ratio a bit & made the structure of the battles less monotonous but we’re not beaten over the head with any of these things/fit them in naturally & the show never seems like it has something to prove & just lets its story be a straightforward giant robots & explosions kinda thing.

It helps that the artwork is great. 

The best summary of my general impression is that I’ll pobably tune in for season 3. My favorite character so far would be Keith closely followed by Pidge, and Shiro, but AFAIK everyone likes Shiro? I’m prolly b/c I’ve heard it’s terrible (The Umbridge effect is probably in full force...) also I’ve been told there’s a trailer out and I’d rather see season 3 unspoiled. 

Clearly there needs to be some payoff for Shiro grooming Keith as a potential sucessor but I’m hoping that after a few drama-filled episodes, they all go rescue Shiro from wherever he’s gotten to, Keith hands him back his helmet and they all go home together. I mean, he just got his own Bayard. It’s unclear what happened to him in any case, perhaps he was absorben Evangelion style. 

That said one of the show’s strenghts is the clear aversion of the “annoying comedic sidekick” even though it has many characters that has could theoritically fit that description - They try their best to give each of the characters something to do & various skills & likeable traits - Like you get why each of them is there and why they’re our heroes - they also took the time to make sure everyone got a few character establishing moment in the first episode (Shiro’s arrival, Pidge & Keith were already on their own quests by their own means, Hunk & Lance served as the PoV characters etc) and throughout the show they try to bring out everyone’s personalities through reaction shots etc. Like, ALL of them are awesome.

Also apparently this fandom has brutal shipping wars? Some ppl I was sitting next to kept cracking jokes about how [random yaoi pair] was obvliously into each other and after a while it got annoying through sheer persistence. 

I don’t think the show as a whole is going for that like if there was going to be a decent/central romantic subplot they’d have introduced it by now they seem to be content to simply be an action show & there’s not much content like that at all except for the occassional teasing for the sake of humor & Lance’s flirting (which is really more there to exposition his being a bit of a showoff) - the most that will come out of it is that when we see some epilogue telling us what became of everyone, Lance will be shown to have found a girlfriend after returning home to his mom & impressing his siblings with his heroic stories. 

To begin with they seem to be going for a different vibe with the main characters, with how all of them (including Allura) refer to each other as “family” or “brothers” all the time like I get the impression we’re supposed to interpret them more as simply comerades or quasi-siblings with Shiro as the big brother and Coran as the kooky uncle.  

Like I hate it when ppl dismiss already existing romantic subplots as “uneccesary”, “silly” or “pandering” but at the same time it’s not like every show needs to have one or like it immediately needs an explanation when one character doesn’t get a love interest(that they must be gay, ace etc... nothing wrong with those type of characters, or headcanon, but “we’re not doing romance genre RN/ the characters are busy fighting a war” should be a sufficient explanation in and of itself whatever the characters’ orientations are.) 

General Character Impressions:

Their secret seems to be rolling with the basic tropes but connecting them into an interesting structre, so it comes off neither overly in your face nor one dimensional.

Lance - ‘Average Joe Relatable PoV character’ except they made him not-boring by making him the snarky/funny one & giving (he’s got ice powers & is the designated long range fighter, both very cool powers, pun not intended but retroactively appreciated) as well as drawing logical consequences (He’s the most attached to earth because of his relatively ‘normal’ background & wants to prove himself because it seems he was the midle child among numerous siblings, hence the rivalry with the local ace pilot.) Sorta calls to mind the likes of Kyon from Haruhi or Sokka from Avatar.  

Hunk - For once the “all around nice heart of the group with the more intuitive, roundabout type of reasoning” isn’t the token girl but I’m glad that role’s still there because niceness & group cohesion is a valid attribute. The “nice person” is typically the healer or magic user but making them the defensive fighter makes just as much sense, especially with his personality as the more cautions common sense-y one who becomes committed to the mission through the desire to protect innocents. 

Pidge - The “secretly a girl” thing is kinda trite but it makes sense as a reference to the original and they still eschewed the tropes by how she was badass well before & doesn’t get treated any different afterwards - The plot twist is more that she’s related to the scientists from the prologue. Otherwise another potential spirit animal of mine, VERY relatable in ways I can’t count, fro the nerdy reactions all the way to the short stubby arms XD I’m also grateful that they didn’t give us that trite old “nature vs science” contrast but instead portrayed these as connected.  It’s like Kensuke from Evangelion, except as a girl & she actually got to be a pilot. 

Keith - The Rival Character. Second-best fighter  of the paladins, sort of a ‘larger-than-life’ superhumanly good ace pilot, to Lance’s ongoing chagrin (and indeed he turns out to be part warrior alien), also, predictably, the local cynic. Seems to have the least ties to earth/ have been looking for a purpose in life anyways.    Not quite a ‘stoic number two’ though - He’d probably like to be but he absolutely doesn’t really know when to shelf it, hence his being highly suceptible to Lance’s provocations & flunking out because of a “discipline issue” despite his aparent talent. 

Shiro - Former Ace Pilot & personal hero for both Lance & Keith. Got alien abducted & subjected to the full repertoire (gladiator fights, experimented on, augmented etc.) & is understandeably still rather shook from it. Serious disciplined military type & natural leader, hence ends up taking over almost immediately wheen stranded with a bunch of ragtag space cadet rejects and, as a result, becomes everyone’s beloved big brother figure./mentor. Supposedly just as loved by the fandom?  Actually still pretty young, he just looks mature in comparison to the others but he’s not above getting in a snowfight. 

Allura - There’s the “sweet princess classic”, the “fierce alien warrior princess” and the “glittery plot magic princess” and in Allura’s case they seem to have been thrown in a blender & put together in such a fashion as to make a more complicated character - She’s certainly fierce, somewhat agressive, suspicious & hellbent on her mission but she also has the diplomatic grace one would expect of a royal & ultimately she does have a sweet side (hinted at early on with her adorable animal companions) - The basic gist of it is that she’s a regular teenage girl somewhere, but has been trained for asskicking & diplomacy all her life, & now she’s the last survivor & feels the pressure to carry on her father’s torch & stop the evil empire so she affects a comanding presence most of the time. 

Also there seems to be some meme about calling her a racist (Ugh tumblr) ? This seems to me as one of this stuations where people want complex characters but cannot handle it if they’re not perfect or fitting into easy boxes. 

The whole point of her is that she comes from a different time & culture with it’s conlicts outside of the human character’s PoVs. Like point me at any angry alien princess who is NOT suspicious. Both being unfrozen and heck, even Zarkon’s betrayal are still relatively recent for her, and in the end she was just kinda avoiding Keith (granted, in what must’ve been a confusing uncertain time for him) more than actively being mean and she came through on her own & apologized. Like, it was just like Hunk said: She just needed processing time, something she’s been afforded preciously little of at any point ever, I mean she goes straight from realizing everyone she ever knew (except Coran) is dead to launching an offensive.  

Bonus: I shall attempt to MBTI the bunch

(In Order of certainty)

Hunk - most obvious ISFJ to ever SiFe 

Allura - ESTJ

Pidge - INTP

Keith - ISTP or possibly ISFP, certainly Se-aux tho. One the one hand he uses Fi-ish language in places (”If I don’t do this, I’ll never find out who I am...”) on the other hand he tends to prioritize the mission & is the most cynical/pragmatic of the bunch & tends to be stoic & objective unless provoked (”The rest of the universe has families too.” “Yeah but can we afford to rescue the princess?”) - His relative reactiveness when provoked is sufficiently accounted for by Se. 

Zarkon - ESTJ 

Shiro - ISTJ (though his instant commanding presence makes me doubt the I somewhat that said politician/leader ISTJs do happen. He seems to have been serious & dilligent even before all the trauma tho.)

Lance - ESFJ or possibly Se-dom, ESxx for sure tho. 

Coran - Clearly has Si and Ne but not sure in which order. If I had to guess I’d say he’s either a very dutiful ENFP or a very quirky ISTJ. 

[suzanneshannon]

How @supports Works

CSS has a neat feature that allows us to test if the browser supports a particular property or property:value combination before applying a block of styles — like how a @media query matches when, say, the width of the browser window is narrower than some specified size and then the CSS within it takes effect. In the same spirit, the CSS inside this feature will take effect when the property:value pair being tested is supported in the current browser. That feature is called @supports and it looks like this:

@supports (display: grid) { .main { display: grid; } }

Why? Well, that's a bit tricky. Personally, I find don't need it all that regularly. CSS has natural fallback mechanisms such that if the browser doesn't understand a property:value combination, then it will ignore it and use something declared before it if there is anything, thanks to the cascade. Sometimes that can be used to deal with fallbacks and the end result is a bit less verbose. I'm certainly not a it's-gotta-be-the-same-in-every-browser kinda guy, but I'm also not a write-elaborate-fallbacks-to-get-close kinda guy either. I generally prefer a situation where a natural failure of a property:value doesn't do anything drastic to destroy functionality.

That said, @supports certainly has use cases! And as I found out while putting this post together, plenty of people use it for plenty of interesting situations.

A classic use case

The example I used in the intro is a classic one that you'll see used in lots of writing about this topic. Here it is a bit more fleshed out:

/* We're gonna write a fallback up here in a minute */ @supports (display: grid) { .photo-layout { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); grid-gap: 2rem; } }

Nice grid! Repeating and auto-filling columns is a sweet feature of CSS grid. But, of course, there are browsers that don't support grid, or don't support all the specific features of it that I'm using above there.

For example, iOS shipped support for CSS grid in version 10.2, but iOS has had flexbox support since version 7. That's a decent gap of people with older iOS devices that do support flexbox but not grid. I'm sure there are more example gaps like that, but you probably get the idea.

I was running on an older version of mobile safari and many many many many many sites were flat out broken that used grid

I’m waiting another year or so before messing about with it

— David Wells (@DavidWells) February 6, 2019

It may be acceptable to let the fallback for this be nothing, depending on the requirements. For example, vertically stacked block-level elements rather than a multi-column grid layout. That's often fine with me. But let's say it's not fine, like a photo gallery or something that absolutely needs to have some basic grid-like structure. In that case, starting with flexbox as the default and using @supports to apply grid features where they're supported may work better...

.photo-layout { display: flex; flex-wrap: wrap; > div { flex: 200px; margin: 1rem; } } @supports (display: grid) { .photo-layout { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); grid-gap: 2rem; > div { margin: 0; } } }

The "fallback" is the code outside of the @supports block (the properties above the block in the example above), and the grid code is either inside or after. The @supports block doesn't change any specificity, so we need the source order to help make sure the overrides work.

Notice I had to reset the margin on the divs inside the @supports block. That's the kind of thing I find a bit annoying. There is just enough crossover between the two scenarios that it requires being super aware of how they impact each other.

Doesn't that make you wish it could be entirely logically separated...

There is "not" logic in @supports blocks, but that doesn't mean it should always be used

Jen Simmons put this example in an article called Using Feature Queries in CSS a few years ago:

/* Considered a BAD PRACTICE, at least if you're supporting IE 11 and iOS 8 and older */ @supports not (display: grid) { /* Isolated code for non-support of grid */ } @supports (display: grid) { /* Isolated code for support of grid */ }

Notice the not operator in the first block. That's checking for browsers that do not support grid in order to apply certain styles to those browsers. The reason this approach is considered bad practice is that the browser support for @supports itself has to be considered!. That's what makes this so dang tricky.

It's very appealing to write code in logically separated @supports blocks like that because then it's starting from scratch each time and doesn't need to be overriding previous values and dealing with those logical mind-benders. But let's go back to the same iOS situation we considered before... @supports shipped in iOS in version 9 (right between when flexbox shipped in iOS 7 and grid shipped in iOS 10.2). That means any flexbox fallback code in a @supports block using the not operator to check for (display: grid) {} support wouldn't work in either iOS 7 or 8, meaning the fallback now needs a fallback from working in browsers it otherwise would have. Phew!

The big reason to reach for @supports is to account for very different implementations of something depending on feature support where it becomes easier to reason and distinguish between those implementations if the blocks of code are separated.

We'll probably get to a point where we can use mutually-exclusive blocks like that without worry. Speaking of which...

@supports is likely to be more useful over time.

Once @supports is supported in all browsers you need to support, then it's good to start using it more aggressively and without having to factor in the complication of considering whether @supports itself is supported. Here's the support grid on that:

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

ChromeOperaFirefoxIEEdgeSafari2812.122No129

Mobile / Tablet

iOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox9.0-9.246all4.47164

Basically, IE 11 and any iOS device stuck on iOS 8 are the pain points. If your requirements are already past those, then you're good to use @supports more freely.

The irony is that there hasn't been a ton of CSS features shipping that have big clear @supports use cases — but there are some! Apparently, it's possible to test new fancy stuff like Houdini:

Using it on my wedding website to check for Houdini support 🎩🐰

— Sam Richard (@Snugug) February 6, 2019

(I'm not sure entirely what you'd put in the @supports block to do that. Has anyone else done this?)

When @supports isn't doing anything useful

I've seen a good amount of @supports uses in the wild where the end result is exactly as it would be without using it. For example...

@supports (transform: rotate(5deg)) { .avatar { transform: rotate(5deg); } }

On some level, that makes perfect logical sense. If transforms are supported, use them. But it's unnecessary if nothing different is happening in a non-support scenario. In this case, the transform can fail without the @supports block and the result is the same.

Here's another example of that shaking out.

There are browser extensions for playing with @supports

There are two of them!

Feature Queries Manager by Ire Aderinokun

CSS Feature Toggle Extension by Keith Clark

They are both centered around the idea that we can write @supports blocks in CSS and then toggle them on and off as if we're looking at a rendering of the code in a browser that does or doesn't support that feature.

Here's a video of Keith's tool applied to the scenario using grid with a flexbox fallback:

This is fun to play with and is very neat tech. But in this exact scenario, if I was able to pull off the layout identically with flexbox, then I'd probably just do that and save that little bit of technical debt.

Ire's tool, which she wrote about in the article Creating The Feature Queries Manager DevTools Extension, has a slightly different approach in that it shows the feature queries that you actually wrote in your CSS and provides toggles to flip them on and off. I don't think it works through iframes though, so I popped open Debug Mode to use it on CodePen.

More real world use cases for @supports

Here's one from Erik Vorhes. He's styling some custom checkboxes and radio buttons here, but wraps all of it in a @supports block. None of the styling gets applied unless the block passes the support check.

@supports (transform: rotate(1turn)) and (opacity: 0) { /* all the styling for Erik's custom checkboxes and radio buttons */ }

Here are several more I've come across:

Joe Wright and Tiago Nunes mentioned using it for position: sticky;. I'd love to see a demo here! As in, where you go for position: sticky;, but then have to do something different besides let it fail for a non-supporting browser.

Keith Grant and Matthias Ott mention using it for object-fit: contain;. Matthias has a demo where positioning trickery is used to make an image sort of fill a container, which is then made easier and better through that property when it's available.

Ryan Filler mentions using it for mix-blend-mode. His example sets more opacity on an element, but if mix-blend-mode is supported, it uses a bit less and that property which can have the effect of seeing through an element on its own.

.thing { opacity: 0.5; } @supports (mix-blend-mode: multiply) { .thing { mix-blend-mode: multiply; opacity: 0.75; } }

Rik Schennink mentioned the backdrop-filter property. He says, "when it's supported the opacity of the background color often needs some fine tuning."

Nour Saud mentioned it can be used to detect Edge through a specific vendor-prefixed property: @supports (-ms-ime-align:auto) { }.

Amber Weinberg mentioned using it for clip-path because adjusting the sizing or padding of an element will accommodate when clipping is unavailable.

Ralph Holzmann mentioned using it to test for that "notch" stuff (environment variables).

Stacy Kvernmo mentioned using it for the variety of properties needed for drop capping characters. Jen Simmons mentions this use case in her article as well. There is an initial-letter CSS property that's pretty fantastic for drop caps, but is used in conjunction with other properties that you may not want to apply at all if initial-letter isn't supported (or if there's a totally different fallback scenario).

Here's a bonus one from Nick Colley that's not @supports, but @media instead! The spirit is the same. It can prevent that "stuck" hover state on touch devices like this:

@media (hover: hover) { a:hover { background: yellow; } }

Logic in @supports

Basic:

@supports (initial-letter: 4) { }

Not:

@supports not (initial-letter: 4) { }

And:

@supports (initial-letter: 4) and (transform: scale(2)) { }

Or:

@supports (initial-letter: 4) or (-webkit-initial-letter: 4) { }

Combos:

@supports ((display: -webkit-flex) or (display: -moz-flex) or (display: flex)) and (-webkit-appearance: caret) { }

JavaScript Variant

JavaScript has an API for this. To test if it exists...

if (window.CSS && window.CSS.supports) { // Apparently old Opera had a weird implementation, so you could also do: // !!((window.CSS && window.CSS.supports) || window.supportsCSS || false) }

To use it, either pass the property to it in one param and the value in another:

const supportsGrid = CSS.supports("display", "grid");

...or give it all in one string mirroring the CSS syntax:

const supportsGrid = CSS.supports("(display: grid)");

Selector testing

At the time of this writing, only Firefox supports this sort of testing (behind an experimental flag), but there is a way to test the support of selectors with @supports. MDN's demo:

@supports selector(A > B) { }

You?

Of course, we'd love to see Pens of @supports use cases in the comments. So share 'em!

The post How @supports Works appeared first on CSS-Tricks.

How @supports Works published first on https://deskbysnafu.tumblr.com/

[siliconwebx]

How @supports Works

CSS has a neat feature that allows us to test if the browser supports a particular property or property:value combination before applying a block of styles — like how a @media query matches when, say, the width of the browser window is narrower than some specified size and then the CSS within it takes effect. In the same spirit, the CSS inside this feature will take effect when the property:value pair being tested is supported in the current browser. That feature is called @supports and it looks like this:

@supports (display: grid) { .main { display: grid; } }

Why? Well, that's a bit tricky. Personally, I find don't need it all that regularly. CSS has natural fallback mechanisms such that if the browser doesn't understand a property:value combination, then it will ignore it and use something declared before it if there is anything, thanks to the cascade. Sometimes that can be used to deal with fallbacks and the end result is a bit less verbose. I'm certainly not a it's-gotta-be-the-same-in-every-browser kinda guy, but I'm also not a write-elaborate-fallbacks-to-get-close kinda guy either. I generally prefer a situation where a natural failure of a property:value doesn't do anything drastic to destroy functionality.

That said, @supports certainly has use cases! And as I found out while putting this post together, plenty of people use it for plenty of interesting situations.

A classic use case

The example I used in the intro is a classic one that you'll see used in lots of writing about this topic. Here it is a bit more fleshed out:

/* We're gonna write a fallback up here in a minute */ @supports (display: grid) { .photo-layout { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); grid-gap: 2rem; } }

Nice grid! Repeating and auto-filling columns is a sweet feature of CSS grid. But, of course, there are browsers that don't support grid, or don't support all the specific features of it that I'm using above there.

For example, iOS shipped support for CSS grid in version 10.2, but iOS has had flexbox support since version 7. That's a decent gap of people with older iOS devices that do support flexbox but not grid. I'm sure there are more example gaps like that, but you probably get the idea.

I was running on an older version of mobile safari and many many many many many sites were flat out broken that used grid

I’m waiting another year or so before messing about with it

— David Wells (@DavidWells) February 6, 2019

It may be acceptable to let the fallback for this be nothing, depending on the requirements. For example, vertically stacked block-level elements rather than a multi-column grid layout. That's often fine with me. But let's say it's not fine, like a photo gallery or something that absolutely needs to have some basic grid-like structure. In that case, starting with flexbox as the default and using @supports to apply grid features where they're supported may work better...

.photo-layout { display: flex; flex-wrap: wrap; > div { flex: 200px; margin: 1rem; } } @supports (display: grid) { .photo-layout { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); grid-gap: 2rem; > div { margin: 0; } } }

The "fallback" is the code outside of the @supports block (the properties above the block in the example above), and the grid code is either inside or after. The @supports block doesn't change any specificity, so we need the source order to help make sure the overrides work.

Notice I had to reset the margin on the divs inside the @supports block. That's the kind of thing I find a bit annoying. There is just enough crossover between the two scenarios that it requires being super aware of how they impact each other.

Doesn't that make you wish it could be entirely logically separated...

There is "not" logic in @supports blocks, but that doesn't mean it should always be used

Jen Simmons put this example in an article called Using Feature Queries in CSS a few years ago:

/* Considered a BAD PRACTICE, at least if you're supporting IE 11 and iOS 8 and older */ @supports not (display: grid) { /* Isolated code for non-support of grid */ } @supports (display: grid) { /* Isolated code for support of grid */ }

Notice the not operator in the first block. That's checking for browsers that do not support grid in order to apply certain styles to those browsers. The reason this approach is considered bad practice is that the browser support for @supports itself has to be considered!. That's what makes this so dang tricky.

It's very appealing to write code in logically separated @supports blocks like that because then it's starting from scratch each time and doesn't need to be overriding previous values and dealing with those logical mind-benders. But let's go back to the same iOS situation we considered before... @supports shipped in iOS in version 9 (right between when flexbox shipped in iOS 7 and grid shipped in iOS 10.2). That means any flexbox fallback code in a @supports block using the not operator to check for (display: grid) {} support wouldn't work in either iOS 7 or 8, meaning the fallback now needs a fallback from working in browsers it otherwise would have. Phew!

The big reason to reach for @supports is to account for very different implementations of something depending on feature support where it becomes easier to reason and distinguish between those implementations if the blocks of code are separated.

We'll probably get to a point where we can use mutually-exclusive blocks like that without worry. Speaking of which...

@supports is likely to be more useful over time.

Once @supports is supported in all browsers you need to support, then it's good to start using it more aggressively and without having to factor in the complication of considering whether @supports itself is supported. Here's the support grid on that:

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

ChromeOperaFirefoxIEEdgeSafari2812.122No129

Mobile / Tablet

iOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox9.0-9.246all4.47164

Basically, IE 11 and any iOS device stuck on iOS 8 are the pain points. If your requirements are already past those, then you're good to use @supports more freely.

The irony is that there hasn't been a ton of CSS features shipping that have big clear @supports use cases — but there are some! Apparently, it's possible to test new fancy stuff like Houdini:

Using it on my wedding website to check for Houdini support 🎩🐰

— Sam Richard (@Snugug) February 6, 2019

(I'm not sure entirely what you'd put in the @supports block to do that. Has anyone else done this?)

When @supports isn't doing anything useful

I've seen a good amount of @supports uses in the wild where the end result is exactly as it would be without using it. For example...

@supports (transform: rotate(5deg)) { .avatar { transform: rotate(5deg); } }

On some level, that makes perfect logical sense. If transforms are supported, use them. But it's unnecessary if nothing different is happening in a non-support scenario. In this case, the transform can fail without the @supports block and the result is the same.

Here's another example of that shaking out.

There are browser extensions for playing with @supports

There are two of them!

Feature Queries Manager by Ire Aderinokun

CSS Feature Toggle Extension by Keith Clark

They are both centered around the idea that we can write @supports blocks in CSS and then toggle them on and off as if we're looking at a rendering of the code in a browser that does or doesn't support that feature.

Here's a video of Keith's tool applied to the scenario using grid with a flexbox fallback:

This is fun to play with and is very neat tech. But in this exact scenario, if I was able to pull off the layout identically with flexbox, then I'd probably just do that and save that little bit of technical debt.

Ire's tool, which she wrote about in the article Creating The Feature Queries Manager DevTools Extension, has a slightly different approach in that it shows the feature queries that you actually wrote in your CSS and provides toggles to flip them on and off. I don't think it works through iframes though, so I popped open Debug Mode to use it on CodePen.

More real world use cases for @supports

Here's one from Erik Vorhes. He's styling some custom checkboxes and radio buttons here, but wraps all of it in a @supports block. None of the styling gets applied unless the block passes the support check.

@supports (transform: rotate(1turn)) and (opacity: 0) { /* all the styling for Erik's custom checkboxes and radio buttons */ }

Here are several more I've come across:

Joe Wright and Tiago Nunes mentioned using it for position: sticky;. I'd love to see a demo here! As in, where you go for position: sticky;, but then have to do something different besides let it fail for a non-supporting browser.

Keith Grant and Matthias Ott mention using it for object-fit: contain;. Matthias has a demo where positioning trickery is used to make an image sort of fill a container, which is then made easier and better through that property when it's available.

Ryan Filler mentions using it for mix-blend-mode. His example sets more opacity on an element, but if mix-blend-mode is supported, it uses a bit less and that property which can have the effect of seeing through an element on its own.

.thing { opacity: 0.5; } @supports (mix-blend-mode: multiply) { .thing { mix-blend-mode: multiply; opacity: 0.75; } }

Rik Schennink mentioned the backdrop-filter property. He says, "when it's supported the opacity of the background color often needs some fine tuning."

Nour Saud mentioned it can be used to detect Edge through a specific vendor-prefixed property: @supports (-ms-ime-align:auto) { }.

Amber Weinberg mentioned using it for clip-path because adjusting the sizing or padding of an element will accommodate when clipping is unavailable.

Ralph Holzmann mentioned using it to test for that "notch" stuff (environment variables).

Stacy Kvernmo mentioned using it for the variety of properties needed for drop capping characters. Jen Simmons mentions this use case in her article as well. There is an initial-letter CSS property that's pretty fantastic for drop caps, but is used in conjunction with other properties that you may not want to apply at all if initial-letter isn't supported (or if there's a totally different fallback scenario).

Here's a bonus one from Nick Colley that's not @supports, but @media instead! The spirit is the same. It can prevent that "stuck" hover state on touch devices like this:

@media (hover: hover) { a:hover { background: yellow; } }

Logic in @supports

Basic:

@supports (initial-letter: 4) { }

Not:

@supports not (initial-letter: 4) { }

And:

@supports (initial-letter: 4) and (transform: scale(2)) { }

Or:

@supports (initial-letter: 4) or (-webkit-initial-letter: 4) { }

Combos:

@supports ((display: -webkit-flex) or (display: -moz-flex) or (display: flex)) and (-webkit-appearance: caret) { }

JavaScript Variant

JavaScript has an API for this. To test if it exists...

if (window.CSS && window.CSS.supports) { // Apparently old Opera had a weird implementation, so you could also do: // !!((window.CSS && window.CSS.supports) || window.supportsCSS || false) }

To use it, either pass the property to it in one param and the value in another:

const supportsGrid = CSS.supports("display", "grid");

...or give it all in one string mirroring the CSS syntax:

const supportsGrid = CSS.supports("(display: grid)");

Selector testing

At the time of this writing, only Firefox supports this sort of testing (behind an experimental flag), but there is a way to test the support of selectors with @supports. MDN's demo:

@supports selector(A > B) { }

You?

Of course, we'd love to see Pens of @supports use cases in the comments. So share 'em!

The post How @supports Works appeared first on CSS-Tricks.

😉SiliconWebX | 🌐CSS-Tricks

[suzanneshannon]

How @supports Works

CSS has a neat feature that allows us to test if the browser supports a particular property or property:value combination before applying a block of styles — like how a @media query matches when, say, the width of the browser window is narrower than some specified size and then the CSS within it takes effect. In the same spirit, the CSS inside this feature will take effect when the property:value pair being tested is supported in the current browser. That feature is called @supports and it looks like this:

@supports (display: grid) { .main { display: grid; } }

Why? Well, that's a bit tricky. Personally, I find don't need it all that regularly. CSS has natural fallback mechanisms such that if the browser doesn't understand a property:value combination, then it will ignore it and use something declared before it if there is anything, thanks to the cascade. Sometimes that can be used to deal with fallbacks and the end result is a bit less verbose. I'm certainly not a it's-gotta-be-the-same-in-every-browser kinda guy, but I'm also not a write-elaborate-fallbacks-to-get-close kinda guy either. I generally prefer a situation where a natural failure of a property:value doesn't do anything drastic to destroy functionality.

That said, @supports certainly has use cases! And as I found out while putting this post together, plenty of people use it for plenty of interesting situations.

A classic use case

The example I used in the intro is a classic one that you'll see used in lots of writing about this topic. Here it is a bit more fleshed out:

/* We're gonna write a fallback up here in a minute */ @supports (display: grid) { .photo-layout { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); grid-gap: 2rem; } }

Nice grid! Repeating and auto-filling columns is a sweet feature of CSS grid. But, of course, there are browsers that don't support grid, or don't support all the specific features of it that I'm using above there.

For example, iOS shipped support for CSS grid in version 10.2, but iOS has had flexbox support since version 7. That's a decent gap of people with older iOS devices that do support flexbox but not grid. I'm sure there are more example gaps like that, but you probably get the idea.

I was running on an older version of mobile safari and many many many many many sites were flat out broken that used grid

I’m waiting another year or so before messing about with it

— David Wells (@DavidWells) February 6, 2019

It may be acceptable to let the fallback for this be nothing, depending on the requirements. For example, vertically stacked block-level elements rather than a multi-column grid layout. That's often fine with me. But let's say it's not fine, like a photo gallery or something that absolutely needs to have some basic grid-like structure. In that case, starting with flexbox as the default and using @supports to apply grid features where they're supported may work better...

.photo-layout { display: flex; flex-wrap: wrap; > div { flex: 200px; margin: 1rem; } } @supports (display: grid) { .photo-layout { display: grid; grid-template-columns: repeat(auto-fill, minmax(200px, 1fr)); grid-gap: 2rem; > div { margin: 0; } } }

The "fallback" is the code outside of the @supports block (the properties above the block in the example above), and the grid code is either inside or after. The @supports block doesn't change any specificity, so we need the source order to help make sure the overrides work.

Notice I had to reset the margin on the divs inside the @supports block. That's the kind of thing I find a bit annoying. There is just enough crossover between the two scenarios that it requires being super aware of how they impact each other.

Doesn't that make you wish it could be entirely logically separated...

There is "not" logic in @supports blocks, but that doesn't mean it should always be used

Jen Simmons put this example in an article called Using Feature Queries in CSS a few years ago:

/* Considered a BAD PRACTICE, at least if you're supporting IE 11 and iOS 8 and older */ @supports not (display: grid) { /* Isolated code for non-support of grid */ } @supports (display: grid) { /* Isolated code for support of grid */ }

Notice the not operator in the first block. That's checking for browsers that do not support grid in order to apply certain styles to those browsers. The reason this approach is considered bad practice is that the browser support for @supports itself has to be considered!. That's what makes this so dang tricky.

It's very appealing to write code in logically separated @supports blocks like that because then it's starting from scratch each time and doesn't need to be overriding previous values and dealing with those logical mind-benders. But let's go back to the same iOS situation we considered before... @supports shipped in iOS in version 9 (right between when flexbox shipped in iOS 7 and grid shipped in iOS 10.2). That means any flexbox fallback code in a @supports block using the not operator to check for (display: grid) {} support wouldn't work in either iOS 7 or 8, meaning the fallback now needs a fallback from working in browsers it otherwise would have. Phew!

The big reason to reach for @supports is to account for very different implementations of something depending on feature support where it becomes easier to reason and distinguish between those implementations if the blocks of code are separated.

We'll probably get to a point where we can use mutually-exclusive blocks like that without worry. Speaking of which...

@supports is likely to be more useful over time.

Once @supports is supported in all browsers you need to support, then it's good to start using it more aggressively and without having to factor in the complication of considering whether @supports itself is supported. Here's the support grid on that:

This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up.

Desktop

ChromeOperaFirefoxIEEdgeSafari2812.122No129

Mobile / Tablet

iOS SafariOpera MobileOpera MiniAndroidAndroid ChromeAndroid Firefox9.0-9.246all4.47164

Basically, IE 11 and any iOS device stuck on iOS 8 are the pain points. If your requirements are already past those, then you're good to use @supports more freely.

The irony is that there hasn't been a ton of CSS features shipping that have big clear @supports use cases — but there are some! Apparently, it's possible to test new fancy stuff like Houdini:

Using it on my wedding website to check for Houdini support 🎩🐰

— Sam Richard (@Snugug) February 6, 2019

(I'm not sure entirely what you'd put in the @supports block to do that. Has anyone else done this?)

When @supports isn't doing anything useful

I've seen a good amount of @supports uses in the wild where the end result is exactly as it would be without using it. For example...

@supports (transform: rotate(5deg)) { .avatar { transform: rotate(5deg); } }

On some level, that makes perfect logical sense. If transforms are supported, use them. But it's unnecessary if nothing different is happening in a non-support scenario. In this case, the transform can fail without the @supports block and the result is the same.

Here's another example of that shaking out.

There are browser extensions for playing with @supports

There are two of them!

Feature Queries Manager by Ire Aderinokun

CSS Feature Toggle Extension by Keith Clark

They are both centered around the idea that we can write @supports blocks in CSS and then toggle them on and off as if we're looking at a rendering of the code in a browser that does or doesn't support that feature.

Here's a video of Keith's tool applied to the scenario using grid with a flexbox fallback:

This is fun to play with and is very neat tech. But in this exact scenario, if I was able to pull off the layout identically with flexbox, then I'd probably just do that and save that little bit of technical debt.

Ire's tool, which she wrote about in the article Creating The Feature Queries Manager DevTools Extension, has a slightly different approach in that it shows the feature queries that you actually wrote in your CSS and provides toggles to flip them on and off. I don't think it works through iframes though, so I popped open Debug Mode to use it on CodePen.

More real world use cases for @supports

Here's one from Erik Vorhes. He's styling some custom checkboxes and radio buttons here, but wraps all of it in a @supports block. None of the styling gets applied unless the block passes the support check.

@supports (transform: rotate(1turn)) and (opacity: 0) { /* all the styling for Erik's custom checkboxes and radio buttons */ }

Here are several more I've come across:

Joe Wright and Tiago Nunes mentioned using it for position: sticky;. I'd love to see a demo here! As in, where you go for position: sticky;, but then have to do something different besides let it fail for a non-supporting browser.

Keith Grant and Matthias Ott mention using it for object-fit: contain;. Matthias has a demo where positioning trickery is used to make an image sort of fill a container, which is then made easier and better through that property when it's available.

Ryan Filler mentions using it for mix-blend-mode. His example sets more opacity on an element, but if mix-blend-mode is supported, it uses a bit less and that property which can have the effect of seeing through an element on its own.

.thing { opacity: 0.5; } @supports (mix-blend-mode: multiply) { .thing { mix-blend-mode: multiply; opacity: 0.75; } }

Rik Schennink mentioned the backdrop-filter property. He says, "when it's supported the opacity of the background color often needs some fine tuning."

Nour Saud mentioned it can be used to detect Edge through a specific vendor-prefixed property: @supports (-ms-ime-align:auto) { }.

Amber Weinberg mentioned using it for clip-path because adjusting the sizing or padding of an element will accommodate when clipping is unavailable.

Ralph Holzmann mentioned using it to test for that "notch" stuff (environment variables).

Stacy Kvernmo mentioned using it for the variety of properties needed for drop capping characters. Jen Simmons mentions this use case in her article as well. There is an initial-letter CSS property that's pretty fantastic for drop caps, but is used in conjunction with other properties that you may not want to apply at all if initial-letter isn't supported (or if there's a totally different fallback scenario).

Here's a bonus one from Nick Colley that's not @supports, but @media instead! The spirit is the same. It can prevent that "stuck" hover state on touch devices like this:

@media (hover: hover) { a:hover { background: yellow; } }

Logic in @supports

Basic:

@supports (initial-letter: 4) { }

Not:

@supports not (initial-letter: 4) { }

And:

@supports (initial-letter: 4) and (transform: scale(2)) { }

Or:

@supports (initial-letter: 4) or (-webkit-initial-letter: 4) { }

Combos:

@supports ((display: -webkit-flex) or (display: -moz-flex) or (display: flex)) and (-webkit-appearance: caret) { }

JavaScript Variant

JavaScript has an API for this. To test if it exists...

if (window.CSS && window.CSS.supports) { // Apparently old Opera had a weird implementation, so you could also do: // !!((window.CSS && window.CSS.supports) || window.supportsCSS || false) }

To use it, either pass the property to it in one param and the value in another:

const supportsGrid = CSS.supports("display", "grid");

...or give it all in one string mirroring the CSS syntax:

const supportsGrid = CSS.supports("(display: grid)");

Selector testing

At the time of this writing, only Firefox supports this sort of testing (behind an experimental flag), but there is a way to test the support of selectors with @supports. MDN's demo:

@supports selector(A > B) { }

You?

Of course, we'd love to see Pens of @supports use cases in the comments. So share 'em!

The post How @supports Works appeared first on CSS-Tricks.

How @supports Works published first on https://deskbysnafu.tumblr.com/