I understand how bad managers can create situations like this for developers, that's a given. All I was arguing is that IE10 and IE11 should both be pretty good browsers, capable of HTML5/CSS3 mostly on par with all the other major browsers now. I don't see how you can purposefully create *new* code that works on just IE10, and not IE11, without trying REALLY hard to be an idiot.

For legacy corporate sites, you just need to stick in a X-UA-Compatible to force IE to render in the version-mode you were originally targeting, and for the most part, I think things will keep working. Your IE10 and IE11 browsers can be forced to render everything as if they were IE9, or IE8, etc... This is only a "fix" for old, legacy sites though. For any new development, you should really stick a with IE=edge for X-UA-Compatible and just code to HTML5/CSS3 standards.

Like I said, you have to try REALLY hard to get yourself into such as situation, by explicitly NOT writing webpages to standard HTML5/CSS3. It's probably the result of poorly trained developers copy/pasting in tons of blobs of ancient javascript, or activeX controls that aren't going to work on newer versions of IE, or using some "toolkit" that spits out your HTML/CSS/JS for you instead of writing streamlined code yourself. Who knows. Like I said though, if you write standard HTML5/CSS3, you will have literally no trouble on IE10+ and Firefox, Chrome, Safari, etc. I can pretty much guarantee it.

IE9 will generally also gracefully fall back, as it supports some HTML5, it's just missing lots of features you might want to use in CSS such as gradients, transitions, transformations, text-shadow, and then some basic HTML things like the placeholder attribute for form fields. With IE9 having support for CSS rgba, opacity, box-shadow, nth-child, calc, and some other important things like Javascript's addEventListener and JSON.parse, you can also pretty easily target IE9+ if you know which handful of neat CSS things to avoid.

Targeting IE8 and below requires all kinds of IE-specific code like attachEvent instead of addEventListener, and it's generally not worth targeting IE8 without some shim like JQuery. And for this reason, I've pretty much stopped using JQuery (as it's now mostly superfluous), and stopped targeting IE8 completely. Sorry Windows XP users, but you're going to need to use a 3rd party browser of some sort if you want to stay on the web.

And this highlights an incredibly deep flaw in Unicode... plus, unfortunately, the app I was using on Android wasn't rendering with HTML, so I was basically out of luck there.

I ran into this problem recently. The kanji for "leader" is supposed to be like the diagram at: http://jisho.org/kanji/details... (note the 4 individual lines for the top right piece) but the fonts on my Android phone insisted on rendering this glyph using the Chinese font, that looks like http://www.hantrainerpro.com/h...
It's not just drawn differently, it's actually one less stroke in Chinese, but it's supposed to be the same glyph somehow!
Unicode has no way to indicate which language you actually want characters like this to display in. Sure for single-language documents like HTML, you can use a lang= attribute and hope the browser handles it right, but you certainly can't mix the two together very easily.

I think the problem most people think Apple/Emoji has with compatibility is that old versions of Apple stuff used the private-use codepoint areas for emoji, instead of the Unicode standard code points. This has since been fixed, as far as I know, but there are a TON of free Android keyboards that are supposed to type emoji, but only use the old private-use codepoints, and thus don't display anything but a blank space or a square box on Android without some special app to translate and display them.

If you look harder though, you CAN find Android keyboards that have emoji buttons that produce the proper Unicode standard codepoints. The button on the keyboard may be in full color, but the glyph produced with be monochrome. Basically a limit of the direct font rendering, but it will work in every app without any issue then, and Apple people can still see the glyphs you send them via text just fine, etc.

As somebody who occasionally freelancing HTML5 development, I can tell you I generally target IE10 and up, because IE10 forward has more or less the same feature set that Firefox/Chrome/Safari have had for years. IE9 and below are just lacking in all kinds of basic CSS support. You don't even need any Jquery or modernizer or other "fixes" if you just target IE10+. In fact, at some point, you start noticing that Chrome is actually the least modern of the big 4 browsers here. I know this is a controversial statement for the Slashdot groupthink, but there are many CSS3 features I've tried to use that work great in Firefox and IE10+, but Chrome fails at. Large gradients, for example, still don't render anywhere near what you'd want in Chrome (horrible banding and other weird render errors at angles, still not fixed in the latest version).

I think you'd have to try REALLY hard to specifically write a website that only works in IE11 and somehow not in IE10, as long as you're using HTML5/CSS3 standard stuff. The same goes for IE12. I don't know what features it will bring, but probably not anything real important that's going to change the huge divide between IE9- and IE10+.

It looks to me like the EME would basically be a DLL on Windows, and I don't see why you can't rename the DLL to something else, and drop in a shim DLL that Firefox loads. The shim DLL then loads the real EME DLL, and just proxies all the API calls back and forth. Encrypted data goes into the shim, to the EME, decrypted video comes back. The shim would then be free to copy and redirect the decrypted video elsewhere. I doubt Firefox or the real EME would even know that it was happening.
If the EME is rendering the video itself, Firefox still has to pass it information about what surface to render to, and the shim DLL can just as easily fake that rendering surface and "render" to a file or something.
And it's not like Firefox can be forced to only load a certain signed EME DLL - you'd just recompile your own Firefox with a new key pair to loan your own signed shim.

You can always just Game Genie the F2P games save files. Modify a few bytes and you can have 2,147,483,647 of any power up you want. The biggest upside to this is how you just stop caring about the game because it's just a pointlessly easy task, and not even a game anymore.

That article seems to present a lot of various ways Responsive Images could be implemented, without actually telling me which way was chosen, and which syntax Chrome actually supports now.

Nope, but Firefox still works great on my 192dpi Windows 8.1 laptop. Chrome looks like crap still, completely unusable font rendering.

That sounds amazing. I wonder if said app will run on my AT&T S3 if I go on an extended stay over there and get an NTT Docomo SIM.

So vending machine purchases appear on your cell phone bill?
Does the app have to be opened and accessed to make the purchase, or can you just take your phone out with the screen off and touch it to the vending machine?

How exactly do you pay for things with NFC. Do you have to download and run a specific app tied to your bank account? Or does it get billed to your cell phone bill somehow?

I know it can be turned on/off in code already, because application can choose to ignore system defaults and use or not use ClearType on their own already.

So I generated this B&W example of what this issue does to the fonts, when you take into account RGB sub-pixels: http://ark42.com/win8.1/192dpi...
It's really quite terrible.