YouTube change served lower-quality video to Firefox 43 for 2 weeks

This is true, which is not particularly useful when deciding if a feature is available. Using the user agent to make this decision incorrectly assumes that all user agents of a particular browser+version all support exactly the same set of features. This is obviously not true.

The user agent may be meaningful[1], but the meaning that it communicates isn't feature data.

[1] If you take the header at it's word; as the bug being discussed demonstrates, user ages may be lying.

I've worked with video format streaming, though, and encountered a situation where there was a driver on a certain Android device manufactured by a major hardware vendor that you've certainly heard of, and their driver silently corrupted video that was using low-latency streaming options. And by "corrupted" I mean that, while a few of the pixels looked almost right, sometimes, it was mostly just garbage and blank grey screens.

I gave them a sample stream that failed, and they verified that yes, it's their fault. And that no, they weren't going to ship an update for it. Sorry. Device had been out for two years. Apparently no one thought to actually test the various standard options in that video codec. It works with the "normal" options? Ship it!

So I totally understand the need to look at UA strings. I had to look for that particular device hardware profile and disable the low-latency streaming options in order for our product to work on that device.

Edit: Not saying that's always correct, but there does seem to be a tension between: "make sure your code can work well, even in a bad environment" and "don't mask bugs, instead fix them where it makes the most sense to do so" (in this case: in the dozens of browsers instead of in millions of websites).

If I don't have this line in my .wgetrc, I get 403's sometimes from sites using Cloudflare.

user_agent=Mozilla/5.0 (compatible; CloudFlare-AlwaysOnline/1.0; +https://www.cloudflare.com/always-online)

The average screen resolution in 2007 was 1024x768. Most of us now have ~1080p-ish type screens or on mobile where it's even higher. We also now have the bandwidth to watch 720p/1080p videos whereas in 2007 that was less true to a broader audience.

360p is pretty unwatchable for me on my screen from 2011/2012, let alone anything that's been released in the past 2 years.

There are a certain kind of app on Android that makes the device FS available via a web browser.

Thing is that these apps invariably makes use of a Chrome-ism when dealing with drag and drop.

In Firefox you can only drag a single file at a time. drag over multiple, or a folder, and there won't be much of a result.

In Chrome however it will transfer over just fine.

This has been sitting in the Mozilla bugtracker for some time, because the Chrome behavior goes beyond the HTML spec for file uploads.

Aside/Rant: I also get the impression that frontend devs have never read the CSS2.1 spec or bothered to understand it (CSS3 is longer, and consists largely of special-purpose extra modules, so a complete reading is less valuable and more difficult). There's somehow this feeling that since CSS "isn't a real programming language" you should be able to use it intuitively. And when things don't work out and you fiddle until it works without giving thought to why, that's OK. That's such a huge waste of time. The box model may not be 100% intuitive, but boy, if that's your standard, what you doing in IT?

Web standards seem, from where I'm standing, to be very post-hoc.

Indeed, I think that's the way it ought to be. How many times has it worked out well when you've fully specified something, before you attempt to actually build it? For me that number is very close to 0.

Are there any features they are pushing in Chrome they are simultaneously not pushing on w3c to adopt? The problem with IE6 is that it not only did its own thing, it did the opposite thing the standard said to do. If Chrome is just standard + new stuff, and that new stuff eventually becomes standard, it isn't a problem. But its standard + new stuff + anti-standard bullshit, the latter is the issue and Google should be criticized for it.

Just wish Vivaldi had gone mobile first...

Does it look the same on Chrome, with no indentation for comments and replies? I've removed Chrome so I'm unable to test but I thought this was just a bug.

I just checked too and Firefox looks different in the comments and it has been broken since the beginning of the mobile changes.

The comments on FF for Android do not have any additional indentation to suggest they are children. On firefox every comment takes the entire width of the screen, even if it's a heavily nested reply. On chrome comments have additional space on the left side indicating if they are children and who they are replying to.

The frontpage looks fine on Firefox. The comments do not look fine. When you view a stories comments on Firefox for android it's impossible to tell what comments are children.

The indentation for one. Notice that the second comment is an answer to the first, but is on the same level of indentation. Following discussions like that is highly annoying.

Weird: While grabbing the phone to answer your question I noticed that "threads", i.e. the view of my comments, works fine. Just the comments below submission links are broken.

Compare to Chrome: http://m.imgur.com/Wpusprq

Note that I do use uBlock in Firefox. Now that I think about it, that might be relevant as well. But then again, why would that break the submission view and not the "threads" link?

Cost: bajillion man-hours of CEOs, companies and committees trying to negotiate that they all do this at once, then about 10 minutes of developer time to actually code this into reality.

Then some sites would be broken, but old stuff eventually rotting and dying is nothing new on the web. Unfortunately, no idea about the numbers, but I suppose it would be low. If someone has the actual statistics on how much sites become practically unusable without a legacy User-Agent header, that'd be great.

That's not really true though. The code that's going to load the video will be downloaded and then the code will request the video. So those two requests happen no matter what. Cache the feature detection so it's slightly faster after the first time.

> The client has to do this for every browser session, too, since browsers are frequently upgraded and the features change week-to-week.

Browsers are unlikely to lose the ability to use whatever codec you think is best so I think this is a safe assumption. Bonus points if you can detect its failure and re-run the feature detection in case something odd like that would happen.