I suspect that the prominence of Markdown has held back innovation and progress for digital content.

Ah, ok ok. As a lover of markdown, I’m here to see how my entire world might be upended. Lay it on me:

does [git + markdown] really represent the best workflow for people who are primarily working with content? Isn’t this a case where developer experience has trumped editor experience…?

Embedding specific presentation concerns in your content has increasingly become a liability and something that will get in the way of adapting, iterating, and moving quickly with your content. It locks it down in ways that are much more subtle than having content in a database.

I can agree with some of the sentiments in this article on a certain level.

But there’s another plane of understanding here where I could argue that digital content is cheapened by the promise of quick economical benefit. Much of the content on the web is prepackaged filler, not meant to sustain but merely fill.

What makes markdown compelling, to me, is less about the syntax and more about the focus on the content. Write good, interesting, compelling content and people will read it. You have to do that when all you have is, in essence, plain text.

That said, I can also get behind this idea:

I wish we could direct more energy into making accessible and delightful editorial experiences that produces modern portable content formats.

An illuminating look at the security concerns of allowing third-party browsers in iOS. I always thought Apple's rule—“Apps that browse the web must use the appropriate WebKit framework and WebKit JavaScript.”—wasn’t so great. But there is an interesting security angle on this I’d never considered:

If an app could receive device access permissions, and then included its own framework that could execute code from any web site out there, [the requirement for “what’s changed” notes] in the app store review guidelines would become meaningless. Unlike apps, web sites don’t have to describe their features and product changes with every revision.

This becomes an even bigger problem when browsers ship experimental features...which are not yet considered a standard...By allowing apps to ship any web framework, the app store would essentially allow the “app” to run any unaudited code, or change the product completely, circumventing the store’s review process.

...when considering the current state of web standards, and how the dimension of trust and sandboxing around things like Bluetooth and USB is far from being solved, I don’t see how allowing apps to freely execute content from the web would be beneficial for users.

So interesting. There’s more:

Without drawing a line of “what’s a browser”, which is what the Apple app store essentially does, every app could ship its own web engine, lure the user to browse to any website using its in-app browser, and add whatever tracking code it wants...I agree that perhaps the line in the sand of “Only WebKit” is too harsh. What would be an alternative definition of a browser that wouldn’t create a backdoor for tracking user browsing?

The details in this piece helped me better understand the technical merits that Apple and Mozilla have on to their more defensive approach to building web browsers.

We love to talk about “Atomic Design” and “Pattern Libraries” but I found this to be an even more thoughtful look at why those things aren’t silver bullets and how you need an even more thoughtful, overarching design system.

A strong design is informed by a view of the big picture, an understanding of the context, and strong art direction — even at the cost of consistency or time.

Design doesn’t emerge by skinning or theming components; it needs a perspective and a point of view — it desperately needs creative guidance. However, I can’t help but notice that when we are building these lovely pattern libraries and design systems and style guides using fantastic tools such as Pattern Lab and living style guides, we tend to settle on a single shared view of how a pattern library should be built and how it should appear. Yet that view doesn’t necessarily result in a usable and long-lasting pattern library