+

There's more to it than that, and yet more coming in the future. Yes, media queries tend to be primarily viewport queries. Viewport data is more complex than just pixel dimensions though, because a browser pixel is not a device pixel. This is why device-pixel-ratios are also supported. A 2560x1440 phone likely responds to a media query as ~854x480@3x (the math isn't right, I wonder what the real device pixel viewport size is).

Picture/source also supports mime-type alternation, just like video/audio sources do. This allows content to be delivered in preferred media types (e.g. webm, webp) where possible with fallbacks to less-preferred types (e.g. h264, png/jpg/gif), potentially reducing bandwidth and cost.

The same group that led the picture element is now leading element queries, which will allow size-based queries to be derived from the size displayed on screen, rather than the size of the viewport itself (as in, placing a responsive image in a sidebar will have different download characteristics from placing it in a full-width column).

And browser vendors can develop selection algorithms based on user preference (e.g. prefer faster downloads) and network conditions (e.g. high latency cell, bandwidth limits, etc) rather than viewport conditions alone.

Literally none of the features discussed here are possible with the feature set that existed before picture. Some (some!) can be approximated with JavaScript, generally badly and often with very undesirable consequences.

Living in a society that isn't crumbling?

Standardizing on anything mitigates mixtures of non-standard things. Spaces aren't magically special.

Turning novel programming problems into an implementation that is non-clever, simple and clear is absolutely a creative pursuit. The "cleverness" that is (and/or should be) lambasted in programming is that which hides complexity. It's an expression of lax creativity. Creative programming can be a combination of a keen application of solved problems and actually clever solutions for unsolved problems. That cleverness is expressed by arriving at solutions that are simple and clear.

This is work that is a long way off from being expendable. It will come eventually, but until then a large subset of programming problems require deeply creative work.

Any programmer who feels that their work does not fit what I said above is almost certainly working on solved problems.

No, how do they work?

Windows compatibility, then ARM. While the majority of Mac usage certainly isn't on Windows, the fact that it could be quite likely drove a large part of the surge in sales after the Intel switch.

There's a problem with efforts to make programming more accessible to non-programmers at the technology level: it turns out that you still have to become a programmer to use the technology effectively. This very notion is how programming languages were developed in the first place—what if we could specify what a program should do, rather than writing the code that does it, and then have the computer generate the code? That is a programming language.

Modern programming is increasingly abstracted away from the metal, and compilers are a wonder unto themselves, but ultimately in order to effectively write a program you still need to do two very specialized things:

1. Design the damn thing well enough to at least get it working (and hopefully well enough to maintain and extend it).
2. Either know or discover—usually both—how to work around the warts of the chosen technology (because they all have warts).

Even if programming could be made so abstract that it's essentially a series of opaque building blocks, you'll always need to do #1, and only by vast inefficiencies and ignorance be able to avoid #2.

- - -

Side note:

Speaking of HyperCard, in many ways its spiritual descendant is Flash. Flash hosts a monstrosity of a language, with concepts from Java bolted onto JavaScript. I'm not saying it couldn't have been done another way, but it's little surprise that something designed to be simple for content producers could become so enormously complex.

This isn't really hard, in the abstract. They just have to have much better metadata about the content, and then an ever-deeper analysis of relative ratings can follow from that. Inference of context will never be perfect, but then again neither will a questionnaire (even if people voluntarily devote their time to answering it) which could recursively be subject to the same criticism that it lacks context. Unless Netflix (or any similar service) deeply understands its content, its recommendations will always be lacking.

The reason online retailers can do relatively better is that a given product often has quite a lot of metadata that can be reasoned about, and it's often relatively easy to model in context of a given product's domain. The kind of qualities people discuss about content is generally much more vague and superficial in comparison.

For instance, Netflix is often confused into believing I have any interest in genre. It might be better at predicting my taste if there were a deeper wealth of data on the kinds of qualities I care about in the content I do like, but it's generally pretty self-evident that they don't. They use coincidence of ratings across users to approximate this, but it's all very hand-wavy and often leads to confusing (if unsurprising) results. Nothing is a substitute for a deeper (currently, at least, human) analysis of the content.

I stopped paying attention right there, and I actually know what you're describing (in fact I almost remembered the IRI RFC number off the top of my head even though I haven't looked at it for a couple years; I had transposed the 9 and the 8). It's not the users who are stupid, it's the systems and software designers. I have to know this shit because it's my job. Asking people to remember or comprehend an arbitrary sequence of characters that is not directly meaningful to them is bad design.

And it doesn't end there. URLs are a showcase of bad design. Numerous characters that have different meaning depending on context. Characters that are effectively meaningless but hey, they're required anyway. Characters that are allowed to be meaningless after they're meaningful. Escaping rules that are different depending on context. Segments that are literally never sent down the wire in a request. Fucking interchangeable delimiters in a query string! (But hey, depends on your web server. Good luck guessing. You have one fact on your side if you care enough to know any of this shit, and it's that the worst choice is by far the most common.) It's downright user-hostile to developers, and if you think I'm kidding go look for how developers try to match URLs, and I'm saying that as a guilty party (you can probably find that gem, if you can't I'll give you a few hints). And you want people who don't care to make sense of it?

URLs are probably never going away. There is too much infrastructure and frankly economy around the current design. But for fuck's sake no one should have to read a complete URL unless they want to, and unless they want to it's actually harmful to show it to them. The only thing most people need to know is the domain name and top level domain (and they shouldn't have to know the TLD either, thanks whitehouse.com). The rest is noise for anything but machines and nerds. And if anyone wants to become a nerd, according to the Chrome feature, finding the noise is only a click or key command away.

Navigating to a page with a dangerous payload isn't the only way browser users are exploited, and this isn't intended to address that issue. The point is that a phishing website, with a URL that looks legitimate to users who don't understand URLs, but bother to look anyway because their brat kids told them to, can exploit users that are trying to protect themselves. By hiding everything except the domain name, that user has added protection because they don't need to understand URLs.

It's a logical extension of the current behavior of most browsers to dim the non-domain portion of the URL; but some browsers even get that wrong. Look here:

http://cl.ly/image/0g241U2q1I2...

If I don't understand how URLs work, I might think that I'm at a site called "tech". That could be improved simply by changing the dimming boundaries, but it still requires a user to filter a lot of unnecessary information. If I'm wondering where I've gone on the web, all I need to know is "slashdot.org". Even that is problematic (see http://en.wikipedia.org/wiki/W...).

There are many potential vectors to exploit web users, and there are many potential pitfalls for the less technically inclined even as protections improve. Implemented well, the Chrome approach could come at no meaningful cost to "power users", but potentially improve some users' experience and safety using the web. There is no reason not to do this, unless it is done badly.

And this is his sofa, is it?

It wouldn't even get that far. Anything that could actually make you sick in beer (besides alcohol) would make the beer distinctly unpalatable and therefore unmarketable. As in, worse than (pick your favorite mass market beer to hate on here).

There's always Thunderbolt or direct PCIe.