CSS Regions is not a W3C standard. It is a Working Draft. The entire point of publishing a working draft is to solicit feedback from the community. There have been several working drafts that were never promoted to final recommendations, because there was no community consensus that they were a good idea. What Google and Mozilla are doing is a perfectly constructive part of the standardization process.

A new error code won't help, because for that to work the original website would have to send it. But if a link is broken, then they already negelcted to send a usefull response code. This feature is about how the client responds to a 404 error, in which case the most honest thing to do is show the user the 404 message that the site provided, but also let them know that they can access an older version of the page if they wish. Which is pretty much how the existing Wayback plugins work.

None of those examples should result in a broken link if you are maintaining your website correctly. And this feature is only "fixing" broken links; that is links that once existed and are now 404'ed.

If you want to discontinue a product, then replace those pages with one that explains that the product is discontinued, and provides links to simular current products, as well as the support page for the discontinued product. If a users is clicking on links in reviews or forum posts about your old product and receive 404's, or redirection to a completely unrelated and unhelpfull page on your site, they will be frustrated with or without this feature.

In the second case, just redirect the entire demo website URL tree to a current list of examples.

In the third case, you shouldn't do that without redirecting the old url to the new one. Seriously, are you trying to make your content hard to find?

Again, redirect to the new menu.

In no case is sending a user a 404 useful or benificial, nor is it the most appropriate thing to do according to the HTTP standard. If you really want to be pendantic then send a 301 or 303 to perform the redirect, otherwise use URL rewriting, or just change the contents of the existing URL, whichever is easiest. The user should only see a 404 if they clicked an invalid link that was never a real URL for your website. Otherwise, you have failed your users, and it's no-one's fault but your own if they choose to use a service that tries to make up for your short-commings.

If you sue someone for patent infringement you have always had the burden of proof, even before this ruling. All this ruling is saying is that if you threaten to sue someone, and they go to a judge first asking you to put-up or shut-up, the burden is still on you as the patent holder, same as if you had sued them.

Secondly, this ruling does nothing to limit the discovery process. As a small inventor suing a big company you still have the same subpoena powers during discovery as you did before.

In other words, the Supreme Court simply reaffirmed that accused infringers are innocent until proven guilty, regardless of the procedural nuances of how the lawsuit is initiated. None of the concerns you voiced will become worse due to this ruling.

Not for long: http://www.wired.co.uk/news/ar...

Yeah that was my reaction as well. The link has slightly more information, and seems to imply that the current policy may comply with French Law, but the way the change took place did not:

If that is true, then the change was a one time offense, and a one-time remedy is fitting. That said, I think the remedy ought to have included a "redo" of the policy change not just a fine; declare that Google's users may choose to be bound by either the old or new policy until Google enacts the change in a manner that is in compliance with the law.

If they plan on implementing this in hardware, then they should have people who are capable of answering that question. If instead, they are just a manufacturer and aren't capable of doing the actual hardware design, then you have bigger problems than answering this question. That is something you should find out about ASAP.

The Supreme Court hasn't even heard this case - it was decided by a federal judge. And if it does get to the Supreme Court they most likely will choose not hear it since there is nothing (legally) controversial about the ruling as it stands.

Not quite. It's true that for the majority of western music it performs just as well as AAC and Vorbis, however there are certain classes of audio that it does poorly with, in particular polyphonic music. This is an inherent limitation (steming from the pre/post comb filter), that cannot be overcome in future encoders.

For streaming audio, this isn't a big deal as it is somewhat of a corner case and people don't hold streaming audio to flawless standards. However, for a music library, you want an audio format to encode anything you throw at it to transparent level of quality, without thinking about the technical details or limitations.

Opus uses less computational resources than Vorbis, to the point where doing it in hardware is almost pointless for a smartphone (especially for streaming where the radio will be active and using more power than the encoding/decoding), and ultra-low power dedicated MP3 players are becoming scarcer. So it's less of an issue that it was in Vorbis's day.

Opus wasn't designed for audio files, but for streaming audio. In that realm it's adoption looks very promising. It has already been integrated into the Skype codebase and will likely be used in the next major release of Skype. It is also one of two mandatory audio codecs for in the draft for WebRTC, which is a new standard for browser-based chatting.

Too lazy to write a cross-platform website? No worry dawg, we put a browser in your browser, so you can suck while you suck.

It is actually quite easy to do, and RMS has been talking about it for a while, this recent article mentions it in passing and links to something a more detailed reference. Think of those VISA debt gift cards that you can buy today. If you are allowed to pay cash for them without showing ID, then they are truly anonymous (unlike bitcoin), and can be used both online and in person. The systems he has in mind are basically refined versions of that basic concept.

The main thing holding back HTTPS is advertisements. Browsers (especially IE) complain if your encrypted page includes unencrypted content (like iframes served from a a third party ad server) and rightly so. Google can get away with it because they serve their own ads, and Wikipedia doesn't have any ads. Arstechnica ran an article a few years back describing the reasons why they couldn't switch to HTTPS by default, but most of it boils down the fact that they can't get rid of the third party content in their pages.

Dude, they reverted your posts because what you posted was flat-out wrong, not because they are shills. You stated that Dan Pulcrano owns backpage.com, but he doesn't own it, operate it, or have any direct control over what goes on it. His newspaper does business with it, but that is a far cry from what you actually posted.