180: Panel on “Inline Styles”

01:05:35   Download

Intro

This week we’ve got a panel discussion with Colin, Nicole, Jed and Jeremy talking the hottest of hotdrama: Inline Styles. Is CSS dead? Is JavaScript the singularity that will take over the Web? Tune in to find out!

Links

Sponsors

Braintree

Code for easy online payments. If you’re building a mobile app and searching for a simple payments solution, check out Braintree.

The Braintree v dot zero SDK makes it easy to offer multiple mobile payment types. Start accepting PayPal, Apple Pay, Bitcoin, Venmo, cards, and more — all with a single integration.

Braintree gives you an easy way to accept multiple payment types with one integration. Quick, knowledgeable developer support if you have any questions. Start accepting Apple Pay, PayPal, Bitcoin, Venmo, cards, and whatever’s next — all with a single integration.

With the Braintree v dot zero SDK — one small snippet of code, and you’re all set up in less than 10 minutes. To learn more, and for your first $50,000 in transactions fee-free, click here.

Accessibility Summit

You and your team can learn how to level up with web and mobile accessibility by taking two days with industry’s best accessibility trainers without leaving the office at virtual, live Accessibility Summit. Register at a11ysummit.com.

  • Chris didn’t say “shoptalkshowdotcom” at the end. I am so disappointed.

  • Chris, what is the thought behind it being bad to say “app” now?

  • Andrew Mosby

    Good talk, everyone. I liked the format, for sure, especially with a topic that not everyone will agree on. I have some thoughts, though.

    As someone who answered firmly in the “It kinda rubs me the wrong way, but I’m trying to be open minded about it” category, I tried to hear a good argument for JS replacing CSS. But honestly, what I heard felt more like Inline Styles Apologetics* – which is fine and probably necessary for now since so many seem to be against it, or at least not “for” it – but, I’m really wondering what you gain.

    I heard that you gain the ability to alter themes via the DOM, which sounds nice, but on the bigger ecommerce sites at least we tend to work on, this seems like something that is less necessary.

    Are there other reasons to make the switch? Is there a case for it with performance due to less calls to the server? Do styles load quicker and therefor you get the sense of the page loading faster (and therefor less bounce rate)?

    I’m really searching for something to grab onto, otherwise – at least for me – this is a non-starter.

    Thanks, all.

    * I hope this isn’t seen as an inflammatory term. I think it was Dave that said something like “it seems like every time we have a question, you say, ‘well, there’s an answer for that.'” I was thinking the same thing, so that’s where I’m coming from.

  • Interesting discussion. I understand the need to couple CSS with the modular JS code it supports within a single container, whether it be within a framework like requireJS, React, or Angular. But I see some issues with tightly coupling any single technology, be it a decorator like CSS, with any other dependent framework. The example given, React, would hold complete dependency on CSS authoring going forward. That worries me.

    In an industry where were trying to separate technological dependencies, like server-side and client-side codebases, doesn’t this introduce the next chapter in tightly coupling technologies?

    What many frameworks continue to lack is native support for CSS dependencies. This JSON modified CSS structure adds more rendering bloat to the page, and I would imagine increases page load times having the CSS being rendering with the JS render. This gets even more complicated when you are dealing with stateful CSS namespacing.

    I’m not sold on this approach yet, but I think an evolution of the idea is the right direction.

  • Chris and Dave, awesome show! Loved the format, and like every episode you publish, I feel like I have a million more things to learn now (dangit). Hope you guys do more on ReactJS, and the panel discussion style is great.

    Loved the comparison between JSON and CSS. Eye-opener.

  • Adam Coard

    Loved the panel format. I wouldn’t want to see it completely replace the Rapidfire / single guest format entirely, but having panels interspersed with regular content would be a welcome addition.

    Also, what rendering engine does Browser Dave run on?

  • lozandier

    It would’ve been nice if there were a representatives familiar with other alternatives to Inline Style besides naming conventions (or directly tied with them): Shadow DOM and the other family of emerging specs associated with Web Components that make inline styles through the means of JS perhaps increasingly a worser option (& existing workarounds such as naming conventions associated with anti-specificity sentiments due to a shortage of options when such conventions were created).

    Google’s Rob Dodson, Alex Russel, Addy Osmani, Chris Joels, Daniel Freedman, Monica (the Emojinee for @polymer ), & many others associated with the Web Component of specs, Frameworks that use them (such as Polymer), or the future of CSS styling capabilities such as Tab Atkins would’ve been nice to have part for this sort of panel in the future…

    *Currently have listened to 55:30 minutes of this episode so far…

  • This episode and format was brilliant. It was such a treat to hear both sides of this argument. I think I ultimately sided with Jeremy but was so enjoyable to listen to. Thanks to all involved.