502: Text Select in Notion, Safari Hot Drama, Writing in VS Code, and Other Browsers on Mobile Safari

We're talking Safari drama, wondering why Apple won't support other browsers on mobile, some solutions to writing in VS Code, and solving problems in isolation.


, , ,


Chris Coyier and Dave Rupert in silly sunglasses and a sign that says Shawp Tawlkk Shough DOT COM

Chris Coyier and Dave Rupert

This episode is with just Chris & Dave, ShopTalk Show's hosts. Chris is the co-founder of CodePen and creator of CSS-Tricks, and Dave is lead developer at Paravel.

Time Jump Links

  • 00:59 Text select in Notion and the web
  • 03:35 Safari hot drama
  • 11:01 When Dave's old, here's what he's gonna do...
  • 19:21 Sponsor: Notion
  • 20:37 Why doesn't Apple support other browsers on mobile?
  • 44:39 Sponsor: WordPress
  • 45:21 Solving problems in isolation

Episode Sponsors 🧡


[Banjo music]

MANTRA: Just Build Websites!

Dave Rupert: Hey there, Shop-o-maniacs. You're listening to another episode of the ShopTalk Show, a podcast all about front-end Web design and development. I'm Dave Rupert and with me is Chris Coyier. Hey, Chris.

Chris Coyier: Darn right. It sounds like spring in Austin. Are there little birds chirping?

Dave: Oh, we've got birds chirping. The grass is green. We had snow last week, but now we don't have snow. Now it's 70. [Laughter]

Chris: It's going to be 70 here, too, which is freakin' unheard of for this time of year.

Dave: Whoa! That's kind of bad for skiing. [Laughter]

Chris: Yeah. I actually don't know how. I mean it's probably not great, but the mountain weather is very different than the down here weather.

Dave: Oh, yeah. I guess it stays up there. Yeah, yeah, yeah. Altitude. It's an old -- yeah.

Chris: Hmm.

Dave: That'll do it.

Chris: I'm selecting text in our ShopTalk. Did you see they released? They said, "Oh, you know--" Remember how selecting text used to suck between blocks, kind of?

Dave: Oh, yeah. Yeah.

Chris: As soon as you move to a second block, it selected all of both blocks. You're like, "Ack. That's not how selecting text is supposed to work," and now it doesn't. Now it's all--

Dave: Like in the Notion? Now it's good. Notion improved. This is great. Yeah.

Chris: That's a really under the covers improvement that is kind of a big deal because it affects how people overall feel about the product, even though if they can't put a finger on it, like I just did.

Dave: Yeah.

Chris: You might be annoyed by it and not really be able to articulate why you're annoyed.

Dave: You know what's interesting? It's because text is like a continuous stream. We add paragraphs to break up the text. But as a computer programmer, I know what's going on. The paragraph is another block. That's another entry in the database or another line, another - whatever - comma angle bracket in the JSON. You know? [Laughter] Then to be able to select text across two components fluidly, that's kind of - I don't know - minor miracle.

Chris: I could see why. It is a little bit like I'm selecting half of one piece of data and half of another piece of data. It's weird, but they pulled it off, and that's good. I think this is going to be an overall improvement for them.

It reminds me a little bit of some new APIs coming to the Web as far as text selection because we've had -- like let's say there's no DOM wrapper around, like Dave Rupert, the text is just sitting in the DOM and you want to highlight the word Rupert. You can't, really. You have to put a span around it or something. Style the span.

Dave: Okay. Yeah. Yeah.

Chris: But you can style it a little bit. You can use ::selection in CSS and then say background orange - or whatever. Then if I manually highlight Rupert, it will be orange.

Dave: Right.

Chris: Then through JavaScript, you can tell the browser, "Hey, I want to programmatically select between these two text ranges of this element," so there's some of that possible. But all that stuff is rather complicated.


Dave: Well, and there's even the new thing where you go #:text:= -- what is the Chrome text selection thing?

Chris: Oh, it's the URL.

Dave: Yeah.

Chris: The URL version of it, yeah.

Dave: That would select some text. That's a little weird. I only know that -- I'm only thinking about it because there's been a lot of Safari drama lately, right? Hot drama.

Chris: Hmm. Indeed.

Dave: But I was like, "What's missing? What are people mad that's missing in Safari?" [Laughter] It just so happens that the URL text hash or whatever that's called, the deep linking to text selection is a missing feature.

Chris: Yeah. Oh, but it's not even spec'd, I don't think. I think Chrome just invented that and said, "Here's a thing that happens in Chrome." It doesn't feel like a thing that maybe needs to be standardized, although don't quote me on that. Maybe it should.

Dave: Yeah. I think there's a spec, but it's so clumsy sometimes. I don't know. I go to a URL and it's all there. I'm like, "No, I don't want my old search terms in this URL."

Chris: Oh, right. The back button, it affects that because it's a URL thing. Yeah.

Dave: Yeah.

Chris: Yeah, and I would never share a link like that, I don't think, unless it's just a context that I don't care that much about. But I don't know that I'd put it in a blog post and expect it to work because, obviously, it's not cross-browser compatible all that much. You know?

Dave: Yeah.

Chris: Yeah.

Dave: Yep.

Chris: Oh, that's tricky. But if it really was a strong standard, maybe I would. But I definitely prefer to link to something more old-school like an ID hash or whatever.


Dave: Are you saying there's going to be some kind of ::highlight-this sort of API kind of thing?

Chris: Yes.

Dave: Oh, really?

Chris: CSS is involved, but JavaScript is involved, too. I just read an article about it. It's not published yet on CSS-Tricks, but it's from Patrick Brosset. You know him because, in our video where you did the select menu dropdown with the browsers, that was his original demo.

Dave: Oh, okay. Well, there you go. Yeah. Perfect.

Chris: Yeah. He's just involved in open UI stuff and open UI is behind this too, somehow - maybe.

Dave: Well, I've missed a few meetings, but I bet.


Chris: Related. Okay. Well, that's interesting. What it enables, it means that you could build, for example, a search and replace mechanism on a website without--

Dave: Uh-huh. Uh-huh.

Chris: It would be easier than it is now, let's say.

Dave: Yeah. Yeah. Yeah.

Chris: You know?

Dave: Okay. Yeah. Well, you know there's also -- I wonder if this is all related. There's grammar and spellcheck. We have spellcheck, right?

Chris: It is. It's 100% related.

Dave: Okay. Yeah. Yeah.

Chris: Yeah.

Dave: There's spellcheck coming or that exists, like in a forum. You can add a spellcheck attribute, I think, and it'll do red squigglies under there. But I think that only kind of works because forms are weird. But I think it's coming to div content editable soon, too.

Chris: Oh, I didn't know that it wasn't there. Yeah, that's interesting. It should be there because it's a strong feature, and I think that comes from the OS--

Dave: Mm-hmm. Yeah.

Chris: --more than the browser, I think.

Dave: Yeah, because I think the browser is not going to ship with the big grammar engine - I don't think. [Laughter] I think that's going to just tie into some kind of - whatever - Windows or Mac.

Chris: Yeah, but there's a lot of value there because you want it to work natively, and you want stuff like Grammarly to work. You want things to be able to hook into it and all that stuff. Yeah, very valuable. In fact, when you're in a situation that doesn't have it, you've got to be careful.

Dave: This is something I want. I write blog posts in Notion. That's kind of my flow now: Notion, Markdown, export, go to VS Code, tidy it up. But in that tidying up phase, I do grammar checking and remove the word "just." It's a weak meaning or a weakened meaning.

Chris: Right. Right. Right.

Dave: I try to catch all the ones I can. Obviously, if you've read my blog, I don't. [Laughter] But I try to catch them all and just clean up my passive voices and stuff like that. I would love that in Notion. I would love a grammar check in Notion that I could turn on, or Grammarly, or whatever. Just some sort of -- Microsoft has this editor, Microsoft Editor product thing.

Chris: Hmm.

Dave: I would love that in Notion. It would be cool if there was a Web API or something that just made that easy and you didn't have to - you know - futz around.


Chris: Yeah. I agree. I was just seeing that some third-party somebody made a VS Code for Grammarly. I like Grammarly, but I don't know that much about them. They always seem on the verge of going slimy or something because there's a lot of upsell action going on in there - or whatever.

Dave: I don't want to throw anyone under the bus, but it is. They give you the hard sell real quick, right? They're like, "Great. Did you see how I fixed your grammar?" It's $1,000 or $100 or something a year.

Chris: Yeah.

Dave: You're like, "What?!"

Chris: Yeah. I write enough that I don't remember if I paid or if I use their affiliate program or something, but I don't get a bill for it at the moment.

Dave: Okay.

Chris: It really does help me, so mostly I want to shake their hand and be like, "Thanks for making my posts better."

Dave: Yeah.

Chris: Because it works within the WordPress block editor where I do most of my writing and all that. Okay. What I wanted to say, though, is, isn't it a shame? What I was going to say is there is a third party that adds that functionality to VS Code.

Dave: Mm-hmm.

Chris: As soon as I saw that, I'm like, "Oh, yeah." It turns out, to me, I couldn't really get it working right, which was a shame because, in that context, which is not a text area. VS Code uses Monaco internally, which is like Code Mirror-esque thing. It's like their version of it. It's very much like let's replicate text editing.

Dave: Yeah. Yeah. Yeah.

Chris: There's no text.... It's very much hand-rolled functionality. Because it is, spellcheck just doesn't work - really.

Dave: Mm-hmm.

Chris: I think there's probably various answers to it. There's a very, very popular spellchecking plugin for it that I use, but the UX of it is totally bespoke to VS Code. You get a squiggly. Then there's a little lightbulb that shows up in the gutter area. You click the lightbulb, and the lightbulb has a context menu of possible word replacements.

It works okay. I'm glad I have it. But you don't have the same muscle memory as you do as everywhere else on the Web that gives you the red squiggles and whatever.

Dave: Right. Yeah, it's very -- is it Write Good Linter? Is that what it is? I think that's what I use, write-good-linter.

Chris: You mean specifically for VS Code?

Dave: For VS Code, that's what I use, and it gives me the same block. Then I use -- what is it? -- error hints or whatever where it highlights the whole paragraph if there's a problem. Anyway, it's pretty cool. Error Lens, that's it. That's it. It's big, beefy, like, "Hey, you messed up." Anyway, I like it. It's a good combo. Yeah, it doesn't feel like a text editor. It feels a lot like a code editor that's doing text, linting, or something. [Laughter] It's like failing rules. Yeah.

I was thinking about it the other day. I was thinking about when I'm old, here's what I'm going to do. I just was like--

Chris: Ooh... Yeah?


Dave: This is the not money-making plan. [Laughter] I've got a money-making plan and I've got a lot of non-money makers.

It's like a VS Code for static sites. You basically just open it, and you get access. You tell it, "I'm going to open the project." It's VS Code for content editors, I guess. You open the project, and you get a list of Markdown files. You say, "The Markdown files are in these folders," and it only shows you those folders. It doesn't show you the rest of the crud.

Chris: Hmm.

Dave: Maybe there's some NPM run start is the only [laughter] thing you need to have on your system.

Chris: Hmm. It's a UI play? It makes it for--

Dave: It just gives you a really good UI for editing documents.

Chris: For writing.

Dave: Yeah, for writing documents and organizing them. Maybe that could be trouble, like rearranging stuff.

Chris: Hmm.

Dave: But what a powerful tool. [Laughter] You know what I mean? There's just so much. It's such an unfriendly environment. Then you could even come up with, like, how would you teach people about branches? You don't want people to be like, "Save, deploy changes." Maybe you do.

Chris: Yeah, maybe.

Dave: Maybe it's like, "Deploy preview," or something. There's some UX that kind of has to happen there.


Chris: I think of it because I just used Netlify CMS the other day. I have a couple of static sites I put it on absolutely ages ago, and I'm so glad I did because sometimes when I want to go add a conference to my conference site - or whatever - I don't really want to pull it down from VS Code, make sure I have the latest changes, make sure I'm on the right Node version because the chance of running NPM run dev working is getting lower and lower on old projects.

Dave: [Laughter] Right. Right.

Chris: And all that - but I don't have to. I just go to /admin right on the Web. Thankfully, I installed Netlify CMS. I have a UI for blah-blah-blah. I put that stuff in there, which could be a Dave-esque. What if you redesigned something like that but with a stronger focus on actual content creation.

Dave: Yeah.

Chris: You know? Slap Gutenberg in there or something. I don't know. Maybe you don't like that.

Dave: No. Well, no, something like that.

Chris: But they have this thing in the top that says, "What status is it? Is this a draft? Does this need feedback? Is it published? Is it unpublished?" Make it have kind of a workflow.

We also use gather content for stuff, and that has that kind of vibe, too, where it's designed for workflows.

Dave: Right. Right because you need an editorial flow, like this is in a draft.

Chris: Yeah.

Dave: This is final draft. This is published.

Chris: Yeah. The point of a lot of those is that they don't make those statuses for you. You make those statuses, so it works for any workflow, not some predetermined workflow.


Dave: Yeah. Over in the D-d-d-d-discord, Andrew and Alex, who work for We Are Traina, they kind of did -- Alex did a live stream over on his Twitch. They basically made a Nuxt to Netlify CMS bridge. They figured out a way to render Nuxt inside the Netlify CMS editor, which is kind of wild.

It sounds like, "What's the big deal?" The big deal is the Netlify editor is a React app. [Laughter] How do you turducken the whole Vue Nuxt app Webpack situation inside the React app?

They ended up using iframes. I can put a link to the--

Chris: Oh, iframes. Yeah, I was going to say isn't that what micro front-ends were that everybody was so hot on for a while?

Dave: Yeah. You configure NGINX to put in one slice of code. Yeah. Somebody tried to sell me on that and I was like, "Probably not." [Laughter] Anyway, yeah.

Chris: Well, then what do you do once you have it in there?

Dave: Well, then what comes back from Netlify is a big JSON dump, right? That's what your page comes back as, or the component in the preview. It sends this big JSON that says what the block type is. You basically have four blocks in blocks render this. Then you have to write your own components. I think he had an image block and a Markdown block that just renders without the Markdown in Markdown or whatever. Then you can add custom blocks.

Chris: Oh...

Dave: There's--

Chris: Part of it is the previewing ability, right?

Dave: Yeah.

Chris: I don't think you get that. CMS doesn't concern itself with that problem, right?

Dave: Yeah. Netlify basically just says -- well, it has a React app, so whenever you go through the tutorials or whatever, they're like, "Just make a React component that renders out the page," or impact your React components and do a big bridge.

Chris: Oh...

Dave: Hialeah, Andy Bell's thing, has some examples of how it kind of works, but he's using handlebar templates, I think, or Nunjucks templates, so you have to compile the Nunjucks into a React. It's a big, gross [laughter] thing you don't really want to do. It's not a big deal, but it just makes it hard. You know what I mean? It's not where you'd want it.

Chris: Yeah. It's some crossing the river stuff that never really feels good.

Dave: Yeah, so anyway, they figured out a way to do it with iframes and post message and stuff like that. In theory, you hit save. The React app then tells the Nuxt iframe, "Hey, here's the new data." Then the Nuxt iframe just reacts and sets a variable.

Chris: Yeah.

Dave: And resets it.

Chris: You don't have to care about previews - in a way. For example, on your site, I know you don't necessarily use Netlify CMS. I'm sure you don't. You could just use it to write -- like, I don't care. I just make some Markdown, and I use it.

The magic of it is that when you push, it doesn't touch any database or anything. It just makes a Git commit.

Dave: Right.

Chris: And blasts it out. I trust my super simple template that I don't even need a preview. I don't care. [Laughter] But then Netlify will build a preview for you just by virtue of it being Netlify.


Dave: Absolutely. Yeah. Netlify can. You don't have to use the Netlify CMS. You can just write in your Markdown editor, and that's where I'm kind of going with this VS Code for content editors kind of thing. It would just be cool to have that, and it would be cool to have different linters. There's Grammarly to fix your grammar, Hemmingway to fix the level of speech you're at, like this is way too complex. This is simple.

Chris: Oh, right. This is for USA Today readers.

Dave: Yeah, because that's what we do. I don't work on it actively, so I shouldn't say that's what we do, but over at Accessibility Project. We kind of set out with, it's an eighth-grade reading level. That's where we're targeting, and so articles kind of have to fit that metric. If they're way too complex or way too academic or way too out there, then we kind of missed the mark. We're trying to make it simple, so we just kind of agreed on an eighth-grade reading level. It's something to think about.

Chris: Awesome. Awesome. There's a lot to think about there. We're three rabbit holes deep at this point.

Dave: This podcast now is a liability because every time we get on here, we start making companies, and it's just a problem. [Laughter]


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by Notion. Learn more and get started at Notion.so.

It's this wonderful app that I couldn't possibly recommend more to use for essentially writing documents, but it's so much more than that. It could be a place for your Kanban boards, for project planning, meeting notes, calendars, and notes of any kind.

You know a little side thing I see people doing a lot is writing out a quick document, which will look beautiful because Notion looks great. Making it public and then using it as a job posting website, like a quick way to get a URL to share with the world that says, "Hey, we're hiring." That kind of thing.

Their sharing model is so great. Any given page -- it can be nested as deep as whatever -- you can kind of just mark as public. A little toggle switch and then share that with anybody who wants to see it on the Internet.

What's cool about that is it doesn't have to be totally public. Another way you could do it is in type in an email address and invite somebody to the document (either just to see it or to have write access to it and collaborate with you on it). It's a great collaboration tool in that way.

For example, we have a show calendar for this show. We invite collaborators (even from outside the ShopTalk Show organization) to collaborate on the calendar--like our editor, our sponsors, and stuff--so we can all have this shared understanding of what's happening with the show. Notion really enables workflows like that. it's so cool.

Thanks for the sponsorship, Notion. That's Notion.so.

[Banjo music stops]


Chris: Well, we mentioned some Safari drama stuff. You could probably cover that a little bit, but I do have a way to boil down the question for you that I'm curious how you would answer it. What do you--?

There's this fact, right? That on iOS or iPad OS device, specifically those two, you cannot run a browser that's not mobile Safari. I know there's some nuance between whether it's the real mobile Safari or some sandbox one that you use in apps. But they're all mobile Safari, and they support what mobile Safari supports - for the most part.

There is no real Chromium. There's no Firefox. There's no -- literally anything else. Although, those are the other main two that anybody would want anyway as far as today I'm concerned.

Okay. I've spoken too much. Why?! Apple has never said why - as far as I know. Like straight from the Apple's mouth, clear language, this is why we only support mobile Safari on iOS, even though they could support other rendering engines. All I want to know is the why.

Since they're not going to tell us, apparently, what do you think is why?


Dave: Yeah. Well, yeah. Apple is tight-lipped, right? We know that just about Apple, in general. iPhones, iPods, the mixed reality, the Apple Car, they're really tight-lipped about all this stuff. Remember Apple Car? We never got Apple Car. That's just too bad.

Apple TV was supposed to be a whole TV and it wasn't a TV. Anyway. Steve Jobs said he solved TV.

In the App Store review guidelines, Rule 2.5.6, apps that browse the Web must use the appropriate WebKit framework and WebKit JavaScript.

Chris: Yep.

Dave: That's it. The reason there is a singular browser on iOS is because of this rule. I think, if I'm going to guess -- I mean we can't be naive to business decisions, especially at the time.

Chris: No. Well, make that case. What's the business reason?

Dave: Well, it's purely -- okay. This is tinfoil hat - tinfoil hat time.

Chris: Yeah. Yeah.

Dave: Everyone, put on your tinfoil hats at home. I think there is a weapon of warfare, corporate warfare where you can undermine Google's tracking business by having a browser that does not allow tracking. I think there's a business there, right? A potential way to do corporate warfare.

I think, back in the day, in the context in which Steve Jobs outlined this and kind of put his foot down on this, Flash was a big fricken' deal, and he knew if another browser shows up and gets on here, the first thing they're going to do is implement Flash, and that's terrible for our phones. It's terrible for our business. It doesn't work. [Laughter] It's just going to nuke the phones entirely and create a bunch of security problems.

All of Apple's -- I think there's some data about the Flash and the Apple thing, but it's something like 60% of all security problems on Mac OS at one point - or whatever - OS 10, OS 9, was purely because of Flash. This was an insecure thing that got on the system.

Don't sue us for liable or whatever. [Laughter] This is just some speculation and some bad regurgitation of facts. Everyone, don't--

Chris: Oh, so it could be security. It could be the second they open the door and say other rendering, browser rendering engines can exist on this platform, internally they're saying there are security problems there. We have opened a door on our own hardware and platform to security issues and we don't want to do that, so we're not going to do that.

Dave: You basically give root-level access to a browser and a browser is something that can execute code, JavaScript, like executes third-party code, JavaScript.

You open up a big attack factor by allowing a browser that is bad to execute JavaScript. Think about your credit card, your contact book, your everything just going out the window.

Chris: I'm sure if you're on team Chrome, you might say, "No, it doesn't," for X, Y, Z reason. I don't know what those reasons are, but you could see somebody having a back and forth argument about that. Okay, so that's a possibility. There's a security issue there.

Doesn't it become Apple's problem then? Do they have to sandbox it in a special way? Does it produce a bunch of work, which is a business reason? If we're going to allow this, we need to hire 38 people to be on the other browsers, other than ours, review squad, or something.

Dave: Right. The security task force, which I'm sure they have that. Yeah, I think it would probably be a lot of work.

Chris: To open the door.

Dave: To open the door to a high profile thing. But I'm, again, kind of brainstorming.

Chris: That's one.


Dave: I know Chrome could say, "Hey, we're good at security and stuff." Microsoft, too, like, "We know how to put a browser on a phone."

Chris: It's certainly not their goal, right? It's not Google's goal, like, "I can't wait until they allow our rendering engine on there. We're going to nefarious crap." Although, I'm sure some people think that. I would think, you know, largely that's not the goal of anybody working on it. They just want more capability.

Dave: Coolapes.eth, the Web browser, is super excited for my business. Really wants that door open, you know?

Chris: Yeah.

Dave: I think there's a potential big problem. Yeah, Google and Microsoft, let's say.

Chris: Isn't there precedent, though? Android runs Firefox, the real one. Is that a big problem?

Dave: That could just be the way they have it containerized - or whatever. They have this idea of intents. You offer a big browser intent, and so any app you use just says, "Don't use my browser. Use the browser intent the user has and use that."

There's a bit of, I guess, maybe some technical things that wouldn't be supported. But I think what my -- this is maybe my big thought here.

Chris: Do it. Yeah. Yeah.

Dave: Hold on. Before I do the big thought. I do have a big thought.

There is actually kind of some irony here. Part of the reason this is all very excited right now is because there was an unfixed IndexedDB bug that went on for months that was in Safari that was leaking private data if you used IndexedDB. Thankfully, IndexedDB is not a heavily utilized feature, partly because it didn't work in Safari for a very long time. [Laughter]

Chris: Mm-hmm.

Dave: IndexedDB is not a heavily utilized feature, so that's hopefully okay. But I think a lot more apps are trying to see how it fits in their whole--

Chris: If you assigned that a ten out of ten big problem for the Web for you, you could say then at least users should have had some kind of choice (knowing that this bug existed) to hop over to another browser where it's not a problem, and they didn't have that choice.

Dave: There's the argument, the capitalistic, freehand of the market argument that because there is no browser, other browser, Apple was not incentivized to fix it faster. The competition breeds innovation.

Chris: Yeah. You could make that argument the other way that, "Oh, crap! We have to fix this really fast because we're the only option." You know?


Dave: Yeah. But I think the idea there is it did not get fixed very fast.

Safari has increased their release cycles. I think people still think it comes out once a year. That is not true.

People still think Safari is coupled to iOS and Mac OS updates. That is not true. It updates independently now. It just happens that people tend to, like, "Oh, hey. My phone is yelling at me about an update. I should update," or your computer or whatever.

They are decoupled, so Safari can release stuff. I think there's still a lack of communication about when that thing is going to come out and be fixed. Apple is not on a six-week. We're releasing Chrome on April 13th, 2022. They're not that company. They don't do that, so we don't know when the fixes come.

Chris: Okay.

Dave: If there's anything I want, it's just a schedule, [laughter] a rough roadmap, Q1, Q2. I don't know.

Chris: Okay. Okay. Okay.


Dave: Yeah, the big thought. There are a lot of people mad, and there are a lot of people directing their anger. I wrote a blog post. I can talk about that in a bit.

Chris: Oh, this is great! Yeah, let's do that after your big thought here.

Dave: A lot of people are directing their anger at Safari people. I'm not trying to hold water for the Safari team, but people are like, "Safari needs to -- WebKit needs to open up. Blah-blah-blah-blah."

They don't control that, man. This is an app store review guideline. That's a different part of the company. WebKit can go to their bosses and say, "We shouldn't exist anymore," or "We should just open the door." Okay. Who makes that decision? Team Apple does it. Tim Cooke has to make that decision.

Guess what. Tim Cook is famous for creating an aluminum monopoly. [Laughter] He bought up all aluminum on Earth, and that's his claim to Apple fame.

Probably not him. He's probably not the guy who is going to open up the big platform. I don't think--

Chris: Yeah. It doesn't seem like -- it'd be like, "Okay. Internally, make the case for it," and making the case for it, you'd be hard-pressed to make it, I would think, internally. They'd be like, "This is abstractly good for the Web." They'd be like, "Ew... I don't know." You know?

It seems like it has more trouble than it's worth. I would think that that's exactly what it is. It's that you just can't get a yes from anybody because the value of it seems pretty low. Meaning that I think that people that are really pissed about it aren't interested in that angle. They're not trying to appeal to Apple. They're trying to appeal to laws. I think this gets changed, and I think there's starting to be precedent for this that Apple changes stuff based on legal rulings.

Dave: I think that is 100% the route it should take. Unfortunately, it's big lawsuits that are going to take a lot of time. You have to prove a monopoly.

I still don't know if we know all the details from the Apple-Epic ruling where Epic kind of put their foot down. It would take something like Facebook or Gmail just saying, "We're not going to render Gmail on iOS devices. We're not connecting to iOS devices," or something big like that to be like, "Apple's monopoly on the browser impacts our business, you know, impacts the features we can roll out."

Can I say another thing?

Chris: Yeah.


Dave: I've got more. [Laughter] I'm rolling here. I've put a lot of thought into this.

Let's say Apple opens the door, Chris. Tomorrow, any browser can be on. Ta-da!

Chris: Right.

Dave: We don't get PWAs. That doesn't happen because there's a new browser on the thing that can't just install apps by itself. That's an OS feature. You have to appeal to the OS.

Chris: Right.

Dave: That's the operating system. That's the app store.

Chris: It doesn't mean we get push notifications, native push notifications immediately.

Dave: We don't get that. No, we don't get that because that's an OS feature.

Chris: Right.

Dave: You have to talk to the people in the OS. That stuff doesn't just show up day-one just because we opened the door.

Chris: Mm-hmm.

Dave: There are sheering layers.

Chris: Do you want it, though? Do you think it's a good idea?

Dave: Man, at this point, get rid of the Apple touch icon, please, and then give me a way to trigger an install prompt. It doesn't even have to be an OS native install prompt. Give me the before install prompt event so I can pop open my own install prompt and a new dialog element -- which they now support, which is radical. I can do my own install. If they click okay, it goes to the home screen. That's all I want. Give me a way. You know?

Chris: Yeah. You've lowered your expectations and getting alternative browser rendering engines is kind of not on the list anymore?

Dave: I mean, no.

Chris: [Laughter]

Dave: If I can just get -- I'm more interested in--

I mean that's part of it. I think there does need to be competition. I think we'd get better because there was, I will say, a dearth of features in development in Safari land for a long time. It got pretty far behind.

Chris: Mm-hmm.

Dave: I think it has done a great job in the last year to years catching up - if I look at it on paper.

Chris: Right.

Dave: Even looking at the stuff Safari does not support list, a lot of it is Fugu stuff that they've just said straight up, "We're not doing it. We're not doing Web midi. Sorry."

Chris: Yeah.

Dave: That's a big bummer for my midi business I'm also starting.

Chris: [Laughter] Yeah. Yeah. Yeah.

Dave: My midi-based controller business. Yeah.


Chris: Okay. What about this idea that what if the experience is worse? We don't have Flash anymore, but let's say the day they open the door -- and I mostly think about Chrome here because that's the dominant player, right?

Dave: Mm-hmm.

Chris: They're going to get the installs. First of all, browser diversity takes even more of a nosedive than it's already been, right? The only thing that happens there is there are less Safari users and more Chrome users, right?

Dave: Yeah.

Chris: Obviously, that internal conversation at Apple is not great either. If you really want browser engine diversity, it feels weird. It almost feels like kicking -- not allowing Chrome on the platform is actually better for browser engine diversity, which is weird because it's exactly backward. You'd think, give choice; that is diversity. Well, choice in this way leads one direction.

Dave: It leads to a monoculture, yeah. I mean I think we know how the numbers would shake out.

Chris: Yeah. People would use it.

Dave: Quite literally, right now there are three apps I have to use Chrome on.

Chris: This one. [Laughter]

Dave: Riverside FM, which we are in right now, Zencastr, and Roll20, also, which is just a D&D app - whatever. But it has a voice com thing. It yells at me if I use a browser other than Chrome. I can still use it, but it still has a warning that's like, "You should be using Chrome."

Chris: Yeah.

Dave: I'm using Chromium.

Chris: Man, we lived through some years where that would have been national news - or whatever.

Dave: The early 2000s, yeah, dude. It would just be like, "Breaking news."

Chris: Yeah.

Dave: "Riverside sucks." No. [Laughter]

Chris: Yeah. People just would have waggled their fist a lot harder than they do now.

Dave: Yeah. There'd be ten Tech Crunches about it.

Chris: Yeah. Okay. Well, that was all very interesting stuff. I don't even know how I feel about it. I'm kind of a collector of opinion.

Some part of me obviously is like, "Dude, yeah. Apple, come on." It feels like a good choice to have different rendering engines. But I just can see how freakin' complex it is. Even in my own little business, making some kind of choice is like, we don't just wing it. There's got to be a case made for it.

Dave: Well, what if somebody--? I don't know. This is kind of a hard one to do. I'm trying to think of a technology CodePen couldn't support or would be a backflip to support - or something.

Chris: I don't know. PHP?

Dave: Yeah. You have to support PHP in CodePen, Chris.

Chris: Yeah. [Laughter] Like the government? Oh, there's community outcry that says it?

Dave: There's a swell against you because you do not support WordPress in CodePen.

Chris: Yeah.

Dave: What are you going to do?

Chris: Yeah, right.

Dave: WordPress is secure, Chris. People work on it, and it's super secure.

Chris: The easy way to do it is just to put your fingers in your ears and go, "La, la, la, la. I'm not even going to publicly respond to those questions."

Dave: Right. Right. There's just so much. And I feel like people are yelling at the wrong people, like, "WebKit, Safari, you need to do this!" It's like, they don't control it, man.

Chris: Well, that was your blog post, right? If you want something to change in browsers. Your blog post was probably more about features and stuff. I want an existing browser to change in some way. That was what your post was about, right? Your Twitter yelling is probably the least effective thing you can do. [Laughter]


Dave: Yeah. Man, my whole Twitter is just people yelling about browsers right now. Part of it was in response. I'm putting everybody on notice here. Okay? [Laughter] This is people on every browser.

The level of discourse, it just turns into finger-pointing like, "Oh, yeah? Well, you didn't support Web midi." It's just this constant old beef gets pulled up. I hear about Brendan Eich's $100 donation to a bad idea in 2007, every day. I feel like it's Groundhog Day in my feed.

Chris: Yeah.

Dave: Not that we shouldn't forget this stuff.

Chris: Yeah. You have to make a mental health call for yourself, right?

Dave: Yeah. Yelling on Twitter doesn't do it. If it did, man, browsers would be great. [Laughter] Everything would be fixed, dude.

Then people are always like, "Oh, it's the new IE." I'm just like, "That doesn't work, dude." Every browser is the new IE. Every browser, especially in the next year when CSS all happens at different times, every browser is going to look like the new IE real quick. You know?

Then you can yell about privacy. This was another point I made. I think privacy is important, but people just go all privacy, and then it's not private. It's like, "What do you mean by that?" If you just yell privacy is this bogeyman that's going to come and steal your data, what do you mean by that? Is it trackers?

It might mean that. I maybe don't agree, but I do appreciate Laura Kalbag and Jeremy Keith's articles on CSS-Tricks over the holidays.

Chris: Mm-hmm.

Dave: I like that they drew a line in the sand, and they specifically said nothing, no third-party. You know? But my thing is just like, don't yell about privacy and say what that means specifically because otherwise Chrome or Safari is going to run off and define privacy for you. Don't let them do that. Make it a thing.

But my whole thing is just like blogging is the way to do it because I've seen first-hand people at Edge, people at Safari, people at Firefox, people wherever. They take your blog post, and they go run them up the flagpole. They say, "Look. This guy is having a problem," or this girl is having a problem. "They're having a problem with this, so let's try to fix this."

Chris: I don't even think it's because it's a blog post. I think it's because it's articulated reasoning.

Dave: For sure. I'm sure.

Chris: Right? I mean it's helpful that it has a URL and stuff. But I guess if it was a Word Doc they could send, they'd send that too. The point is that it makes the case. It's not just angered nugget.

Dave: Yeah. It's not just a turd in the stream of Twitter. [Laughter] It's like I thought about this enough, and here are my reasons.

I know for a fact, CSS-Tricks articles are cited on spec things. People are like, "Oh, this is a need." Browsers are constantly looking for signals -- whatever that means -- about what developers need and what authors need and what users need. It's up to you to express those needs in a way that's going to get some traction internally that they can show to their boss.

If you're just like, "Fuck you. Support container queries," guess what. That person's boss, Tim Cook, is not going to be moved by that argument.

Chris: [Laughter]

Dave: He's laughing on his pile of a trillion dollars saying, "Try again." [Laughter] It's just not going to work the same.

Chris: Yeah. It's very different than saying, "Oh, I am working on a weather widget for this high profile website. We have to display it under these four different circumstances. It's a real challenge for us." That type of thing, you can have an intellectual conversation about it.

Dave: Well, and that too. People's brains -- this is a people's brains thing. If you give somebody--

This is bikeshedding, basically. If you give somebody a big problem, they can't solve it. They'll start talking about what color to paint the bike shed at the nuclear power plant, right? You describe the nuclear reactor, and people are like, "I don't know. But what color is the bike shed? Let's fight about that."

People zero in on the thing they can fix. And so, if you zero in on a fixable thing, it's probably going to get fixed. But if you're like, "Browsers need florps," what does that mean, dude? What do you mean by that?

I don't know. In my opinion, I think there's so much we can do to actually get things fixed, progressed, and moved forward.


[Banjo music starts]

Chris: This episode of ShopTalk Show is brought to you in part by WordPress.com, an excellent place to go spin up a WordPress website if I don't say so myself. I've done it many times.

They have a brand new YouTube channel, youtube.com/wordpressdotcom (where the dotcom is spelled out). Might as well head over there and subscribe if you do any kind of WordPress work. There's already all kinds of educational content there on how to make the most out of your WordPress site.

I know for a fact that they are heavily invested in this and going to make it a great place for customer showcases, which are cool to watch because then you see how somebody else builds their website. You see yourself in it. You see all the possibilities of what you might be able to do with your website. It's going to be awesome. Subscribe at youtube.com/wordpressdotcom (spelled out).

[Banjo music stops]


Chris: It's like a weird spectrum of, yes, it's good to question things. If you question too much, you've gone too far down red string on the wall territory - or whatever. I've seen plenty of this in people that email me and said, "Listen. I know you're the CSS guy. I've reinvented CSS. Here's a GitHub repo. Nobody has ever seen it before. I've been working on it for four years. I've spent 790 billion hours on it, and you're the first person that's going to see it. Here you go."

I'm like [scoffs], I'm not even going to look at it. You took the wrong--

Dave: [Laughter]

Chris: You took the wrong path here. You know? Really wrong for a really long time. I'm not trying to crush your dreams, but I can't be. I'm just not going to be roped into this. There is no way that, in isolation, you solved computers. [Laughter]

Dave: Right. The way to get -- that's it. If you want to invent CSS 9000, you're fixing CSS, it's not to go out and invent a whole thing. It's to say, "It's CSS, but the one big rule change is the longest class name wins." You know?


Dave: Always. You know? And so, it's like Z index for CSS rules - or whatever. That's your one big rule change.

Implementing that is actually way easier than a whole new dialect, a whole new compiler, a whole new style builder. You just have to -- that's kind of about knowing what's good and fast and cheap. You have to figure out what the possibilities are. You have to choose.


Chris: Yeah. I want to give you extreme credit, too, for the most deft clickbait I've ever seen. He basically said, "before I die, here's some advice."

Dave: [Laughter]

Chris: Then the first sentence is, "I'm not going to die, but here's the rest of my blog post." [Laughter]

Dave: I'm into it. I'm going to do a thousand of these. I want people to do a thousand of them as well because you have those things.

I've been thinking about this thing for my whole damn life, my whole damn career.

Chris: Yeah. Okay. You can't just say, "Uh... Before I die. Uh..." and then be like, "Oh, The Witcher is a good show."

Dave: Yeah, yeah, yeah.

Chris: It has to be connected to a long-term thought.

Dave: It has to be. Yeah. I think the format has to be to a long-term thought, just some things you wanted to get off your chest for a long time, you've just been thinking about, mulling over.

I've got another one about criticizing technology choices, I think I'm going to put out. There are quite a few. I don't know. You just see people criticize. Experiences I've had, too. It's just like here's one where I made fun of something and that hurt the maintainer's feelings. Now they don't talk to me anymore. [Laughter] You know?

Chris: Hmm. Been there. [Laughter]

Dave: Yeah. You're just like, "Whoops! I talked about it wrong, so here's what I know."

Chris: Yep.

Dave: It's just sharing what you know. I would love that for somebody who does accessibility. Like, "Before I go, here's what you need to know about accessibility." [Laughter]

Chris: Yeah. I was asking. It was probably a month ago now, but I was asking around on Twitter for those, if people have any favorite of those, like, "Here are 40 things I learned," posts. There was some pushback like, "Those are all dumb and bad," because I think there's just general pushback to the, like, clickbait format of that kind of blog post.

But I actually met the exact opposite. I was like, I like those because people don't write them every day. If you're writing one of those, it helped unlock your brain because you maybe don't write as much - or something. It has forced your hand into thinking philosophically about what you know.

I actually like it as a format, like maybe it's better to break up those 40 into individual blog posts so you can elaborate a little better. But if you don't have the time for that, I don't mind a good 40 things I've learned as 10 years as a Python developer - or whatever crap.

Dave: I love it. What's that book? 101 Things I Learned in Architecture School, or whatever, as an architect. That's a great book. It's good for Web designers. It's just like, "Here's what I learned. I learned how to draw a straight line. You have to go from top to bottom, and that's the only way to draw a straight line. You can't do it left to right." [Laughter] It's just simple stuff, like, "Here's an idea of space in a building. You should build space into your architecture."

I like it. I don't know. I'm just kind of like, if you can just make a list. But what I don't like -- can I say what I don't like?

Chris: Let's go.


Dave: I'm listening to this book right now. It's called Everything is Figureoutable. It's a self-help book. I like the genre. This person, Marie something, seems nice, seems great. But the book is just kind of like -- you know she's like, "I was not-- I got a job out of college at Wall Street. Then I didn't like it. Then I worked for an ad exec thing at a magazine, and I didn't like it. Then I decided my job was going to be life coach." [Laughter]

I'm just like, "Wait. Wait. Time out. Are you sure?" She's really good at it, so it worked out, obviously. It's just kind of funny. I think where I don't like the 40 things I learned is when you've been learning Python for 2 weeks. [Laughter] I think I like it more from a holistic, big career perspective more. I think that's where it becomes way more valuable. Something you've been thinking about for a long time, not just two and a half weeks for the article. You know?

Chris: Right. Right. The extreme example is when people look at an API for one second. They're like, "I wouldn't use that." You're like, "Oh, I'm glad, in 30 seconds, you haven't found a use case for this API for the entire Internet. Good for you."

Dave: [Laughter] Yeah. Yeah, yeah. People just can hop in real quick. They make a gut decision.

Oh, shoot. We had some drama the other day. Here's more hot drama, Chris. Hit the button.

["Dun-dun," Law & Order SVU]

Dave: "PRs are bad" - guy on Twitter.

Chris: Oh, we should have saved this for the next one. We're right at the end of the show.

Dave: Oh, we'll save it for the next one.

Chris: [Laughter]

Dave: We'll push it to the next because it is about a three-hour conversation about this.

Chris: Yeah, it probably is.

Dave: Okay. We'll push this to next week. But there are just so many. People just make these big epiphanies. I'm probably in that bucket, too - but whatever. I like these. I like blogging, dude. Blogging is great.

Chris: [Laughter] All right. Let's do some -- we'll do some more user questions and that on our next show.

Dave: All right. We'll wrap it up. Thanks, dear listener, for downloading this in your podcatcher of choice. Be sure to star, heart, favorite it up. That's how people find out about the show. Follow us on Twitter, @ShopTalkShow, for tons of tweets a month. And join us on the Discord, patreon.com/shoptalkshow.

And we have a YouTube over on the real CSS-Tricks YouTube channel. It should be videos coming out there. Although, we haven't really planned that out, but we'll figure that out soon. [Laughter]

All right. Thank you, Chris. Do you got anything else you'd like to say?

Chris: Nope... ShopTalkShow.com.