Forgot your password?
typodupeerror

Comment: Re:You want IE to be relevant? (Score 1) 105

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.

Comment: Re:You want IE to be relevant? (Score 1) 105

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.

Comment: Re:Han unification (Score 1) 108

by Ark42 (#47254339) Attached to: Unicode 7.0 Released, Supporting 23 New Scripts

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.

Comment: Re:Why emoji? (Score 1) 108

by Ark42 (#47254255) Attached to: Unicode 7.0 Released, Supporting 23 New Scripts

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.

Comment: Re:You want IE to be relevant? (Score 5, Interesting) 105

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+.

Comment: Re:Silver lining? (Score 2) 202

by Ark42 (#47164389) Attached to: Netflix Ditches Silverlight For HTML5 On Macs

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.

Are you having fun yet?

Working...