.modal { position:absolute; left:50%; top:50%; width:50%; height:50%; transform: translate(-50%,-50%); background:#ccc; }

Depending on what you're trying to do, sometimes transform:translate(); can be amazing.

Here is a list of some stuff that all the other major browsers support and IE9 does not:

CSS3 text-shadow
CSS gradients
Web Sockets
Web Workers
CSS3 Transitions
HTML Form validation
CSS3 Border images
CSS Columns
HTML Offline Applications

And lets also not forget that IE9 has no support for:

a decent "browser extensions" mechanism
recent free, open-standard and open-source audio, image and video formats (e.g., WebM, ogg/vorbis and ogg/theora)
other platforms, besides Windows

So, no, IE9 is not "pretty much on par with firefox and chrome", in my books.

Sources: here and here

Edit: added point about (lack of) cross-platform support

Main ones:

Stop suing over software patents
Stop collecting patent licensing fees for software they didn't produce, do not own, have nothing to do with, and are competing with.
Update IE9 to support all the HTML5 stuff they left out.

Nice to have:

Participate in good faith in developing open standards.
Get rid of DRM in MS products.
Open up all formats, protocols, and web runtimes they've developed.

TIL that you can get lossy compression way better than jpeg BUT with full browser support by encoding a png (or other lossless source) as a single-frame mp4 (example uses ffmpeg on OS X installed via Homebrew)

cross-browser mp4 compatibility

It's not as if IE7 isn't a browser and has no HTML and CSS support. You should be able to answer your own question as a web developer. The answer is "don't use features IE7 doesn't support."

http://caniuse.com should help you if you aren't sure.

/u/WrasslorMonkey posted some good information. However, I think using the various tools to "make IE7 support new stuff" could lead you down a path of sorrow and headache. If IE7 can't do something natively, I'd tell your supervisor that it isn't supported or will blow the budget up.

Very visually impressive, and extra awesome after less than half a year. I'm going to be a bit harsh on browser compatibility, but don't let that discourage you! Fix it, learn from it, and you'll be in a great place.

> I've only tested this in Chrome desktop and mobile.

Then you don't know if your site works for 50% of the desktop and mobile web. In fact, your site only works in Chrome. It is broken in different ways on each of Edge, Safari, and Firefox.

Standards-based, cross-browser development isn't optional: the Web is too heterogeneous for any other approach to work. You can't expect users to happen to be on your preferred browser, and even if they wanted to, they may not have the choice: corporate laptops, library terminals, and smart devices are often locked down.

This is especially important for a portfolio site: if your site is broken on 3/4 of the major engines, you've not demonstrated that you can actually build for the Web.

Edit: Also, look into learning Flexbox. It should dramatically simplify the markup and stylesheet for your #nav, among other things.

Or text-overflow: ellipsis; is now fully supported cross browser (Firefox 7 was the last browser on the bandwagon)

Well, browsers will only load the one they need, they're not downloading every version of a font each time. Woff is fairly agreed upon btw (http://caniuse.com/#feat=woff), you only really need woff + an IE8 fallback for decent support now. Of course, it's fragmenting again with woff2 (http://caniuse.com/#feat=woff2), got to keep that treadmill going..

Making Brotli generally available makes a lot of sense since browsers need it (and already ship it) for WOFF2 anyways.

http://caniuse.com/#feat=woff2

https://code.google.com/p/chromium/issues/detail?id=452335
https://bugzilla.mozilla.org/show_bug.cgi?id=366559

I also think that the high decompression speed makes it very interesting for video games. In order to speed up the loading process, you need something which can outrun your local storage mediums. Deflate is still a popular choice for this, but Brotli would do it significantly better.

Being ahead on javascript alone does not make any browser "up to date" and Edge is the worst of them all:

http://html5test.com/

http://css3test.com/

http://caniuse.com/#compare=edge+13,firefox+44,chrome+48,safari+9

> ES2015 and custom elements are now supported in most major release channels

I haven't been keeping up with custom elements, so forgive me if I'm wrong on this.

CanIUse lists custom element support at 50% of users in the USA, with only Chrome and Opera offering full support. IE obviously offers no support and never will, Edge offers no support, and Firefox only supports through changing a configuration value.

Does the author mean "supported with a polyfill"?

Hey all, I made this silly thing. A few things...

Browser events it uses: https://developer.mozilla.org/en-US/docs/Online_and_offline_events

Browser support: http://caniuse.com/#feat=online-status

React wrapper: https://github.com/chrisbolin/react-detect-offline

Why isn't the article technical? I wanted it to be for a broader audience. Sorry, I didn't post it here 😬

AFAIK this is the oldschool way to do <script async src=...>

http://caniuse.com/#feat=script-async

Old IEs for instance still don't support this feature.

Desktop browsers that support VP9 universally support the battery status API. Would it be possible to integrate an option so that VP9 is disabled only when the battery is discharging?

That way, you'd get efficiency when it's most crucial and (potential) bandwidth savings the rest of the time.

Popular sites using SPDY

Google.com
Facebook.com
Youtube.com
Yahoo.com
Twitter.com
Vk.com
Wordpress.com
reddit.com

It's supported by most current major browsers (via caniuse.com):

Firefox
Chrome
Safari
Opera (not Opera mini)
iOS Safari
Android Browser
Chrome for Android
IE 11 has "partial support" (doesn't work in Win 7)

Well because -moz-border-radius and -webkit-border-radius was a reaction to people wanting rounded corners and guess who didn't wanted to listen to the webdev community and give them rounded corners | border-radius support. What i am trying to say is people don't want to wait for Microsoft to become standard compliant .

Support for border radius by date

Mozillla : 2009-oct partial(with -moz-border-radius) 2011-march full

Chrome : 2010-jan partial(with -webkit-border-radius) 2010-may full

IE: 2011-march full

So let's wait for microsoft to become standard compliant and HTML 5 will be fully supported in 2020 .

Introducing HTML5 provides a pretty good overview. It covers the new elements (and their semantics) and some of the new JS APIs.

CSS3: The important parts are selectors, border radius, text shadow, box shadow, gradients, media queries, and @font-face. Read the specs.

JS: Take a look at the ES5 additions. There are polyfills for things like forEach, filter, map, [etc], bind, and Object.create. There are also a bunch of new APIs. Again, read their respective specs if you want to use them.

For a quick overview, take a look at caniuse. It's nicely organized in a bunch of categories, there is a short description for each puzzle piece, and there is also always a table which informs you about the current state of browser support.

You can drag'n'drop files in Firefox, but not a folder. You need Filesystem API to do that http://updates.html5rocks.com/2012/07/Drag-and-drop-a-folder-onto-Chrome-now-available.

Firefox does not support Filesystem API http://caniuse.com/#feat=filesystem

I like SVG. I don't it see it as often as I'd like on the web, with the good cross-browser support. It's perfect for many places today using PNG, especially with modern HiDPI scaling for effortless crisp schematic images, and it's easy to kind of forget that we have established vector support on the web.

It's funny that it's this small even when XML based. I'd like to see a "binary SVG" format for the web that is a direct and documented translation of the XML. I imagine it would allow this to happen in just a few dozen bytes!

Edit: Or maybe, a more abstract and flexible standard would be binary XML since SVG could be implemented in it.

There's a new feature called flexbox that is already supported in most browsers. If you hate floating layouts like I do, it's worth to give it a try next time you have to wrangle with CSS.

You can use the HTML5 clipboard api http://www.htmlgoodies.com/html5/other/working-with-clipboard-apis-in-html5-web-apps.html#fbid=eh9tM7GHJWF

But do note that not all browsers fully support it as of now: http://caniuse.com/#feat=clipboard

Rather than state the obvious argument that CSS3 is usually used side-by-side with HTML5 and is effectively a requirement of it, I will instead point out some HTML5 shortcomings for IE9.

Things not supported in IE9 that (almost) all the other major browsers currently support:

Web Workers
History management
new form features and client-side form validation
DOMTokenList interface
async attribute for external script
WebGL
Web Sockets
XMLHttpRequest 2
Server-sent DOM events
Typed Arrays in JS
File (and FileReader) API

Hey, and if we're limiting the list of shortcomings to HTML5, then I probably also shouldn't mention the lack of support for open standard video codecs and browser extensions either, should I? :o)

Sources: here and here

ES6 (ES2015) is a spec related to JavaScript the language, whereas window.fetch() is a WebApi (you can use it in the browser): https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API

Availability: http://caniuse.com/#feat=fetch

Oh no! This fix would only support 97.55% of web traffic. I agree it is important to not just blindly implement all the latest features but placeholder is plenty safe to use these days. Especially considering steam demographics are probably more likely than generic traffic to have placeholder support.

http://caniuse.com/#feat=input-placeholder

Sorry buddy. I can't make IE or Edge do colour blending which is a pretty integral part of the effect.

http://caniuse.com/#feat=css-backgroundblendmode

http://caniuse.com/#feat=css-mixblendmode

Seems IE is the one lagging here anyway.

Well that's annoying too, but im referring specifically to how vendors don't push updates for correct consistent implementations as they should.

An example would be flexbox.

Previously the only way people positioned elements on a page was using css positioning / floats (everyone remembers clearfixing the crap out of things right).

Flexbox was a long time coming, yet before the spec was fully ratified several browser versions were released supporting draft spec 2012 version.

Now several years later we currently have the situation we're facing now, where those same browser versions that implemented the draft spec either :

a. failed to upgrade the spec for that version of the browser (IE10)
b. Updated without bugfixing / full feature support (IE11, FF22 - 27)

http://caniuse.com/#search=flexbox

Despite all of this devs are supposed to be the ones who write workarounds for this and are expected to provide comprehensive backwards compatibility / Xplatform support with extra CSS bloat and hacky workarounds and yet still achieve great performance for SEO, etc?

Bullshit.

Granted this is less significant for browsers that have a consistent release / update cycle to use a linux term "rolling release" type browsers, install once, keep upgrading because as you can see from the FF / chrome examples there have been many versions between now and back then bugfixed with full feature support thus providing backwards compatibility is not as difficult.

However it's highly relevant when discussing browsers that do not follow this release model or are less frequently updated (IE, Safari, Android browser).

It should be the vendors responsibility to recompile / patch and force upgrade their older versions of browsers so devs can write the CSS once. Not just declare the browser end-of-life and expect devs to provide 5 different browser prefixes and then still have to consider how the same syntax may or may not break in different versions of browsers.

IF INSIDE AN APP:

In order to accomplish this you have to LOCK DOWN orientationchange ( forbid it )
Then you have to animate each UI elements depending on your orientation sensors: https://groups.google.com/forum/#!msg/android-developers/tO3MSHwfKNc/0tN77_6IA0wJ

IF INSIDE A WEBPAGE:

There is an html5 spec for that:
http://www.w3.org/TR/orientation-event/
http://caniuse.com/#feat=deviceorientation

TlDr;

YES!

GIF is, ultimate, just a horrible image format that happens to also support animations. It was primarily intended to have a lossless image format that compresses files to be small because they're limited to 256 colors and don't support partial transparency. It just happened to also support animations as well.

Nowadays, we have much better formats (JPEG! PNG! SVG!) but none of them support animation. Well, APNGs do, but those never caught on with browser support. So, when people need to make animated images that all browsers support they're stuck with GIFs. That's why you tend to only see GIFs as animations nowadays, because there's no reason to use them otherwise.

It will be an amazing day when something like APNG is actually supported. But that day is a long way off http://caniuse.com/apng

I take it you are not a web developer or designer since you apparently aren't familiar with the standardization processes.

HTML5 and CSS3 reflect what's been implemented and adopted by browser vendors, not vice versa, and both represent fundamental changes in the standardization process.

The general way it works (for several years now) is that one vendor implements a feature, others follow suit if that feature makes sense and it eventually becomes a standard. The CSS3 spec has also been split into modules that can be updated independently.

IE, up to an including IE9, has lagged behind other browser vendors in implementing features, often lagging very far behind. For instance, http://caniuse.com/#search=text-shadow

As noted, the spec process no longer is based on the notion that things are standardized before being implemented. Rather, it's exactly the opposite.

HSTS has been (at least partially) supported in both Chrome and Firefox since version 4. Opera since version 12, Safari since version 7, and IE is retarded.

source

Ahh, should have been more clearer: fetch is actually a polyfill for the window.fetch command, which actually has a good coverage right now (http://caniuse.com/#search=fetch). The other two are AJAX/XMLHttpRequest wrapper that feature some more functionality like canceling requests.

So, but yeah. Depending on the stack of features you actually use, I would rather go with some polyfills and fetch (or if needed axios or request) than with jQuery. It's such a difference when looking at the file size..

> but every article I read on it, says Flexbox is not ready for production.

It has nearly 97% browser support if you don't mind prefixing (either by hand or with autoprefixer). Unless you really need IE8 support, it's ready for production.

I actually wrote this. For browsers that support canvas, it can convert images to ascii by pulling pixel data from the 2d context. For browsers that support the webRTC/getUserMedia standard, it can use the web camera to perform the conversion in real time using the same technique. Chrome 21 and above supports this by default and chrome 20 can support it by turning on a special setting. Opera 12.0 also supports this, and Firefox with gain support with version 17.

If you guys are curious, the “pixels” are ASCII characters corresponding to the illumination value of the surface at each point: [space].,-~:;=!*#$@ from dimmest to brightest. No raytracing required. This brightness value is a simple rgb to hsv conversion. You don't need the hue and saturation, the "value" (brightness) is obtained by getting the max value of red, green, and blue and dividing it by 255 to normalize it to a percentage scale.

edit: updated browser support information http://caniuse.com/stream

> Do you have any recommendations for courses or reading material?

Silvaeri's right: CanIUse.com is your bible.

Honestly, one of the best things you can do is not use Chrome as your primary development browser. I'm partial to Firefox, which is why I chose to work for Mozilla, but Edge and Safari are also great. Odds are, if your site works in one of those browsers, it's much more likely to work everywhere, including Chrome.

The reverse isn't true: Google has a bad habit of shipping things before they're standardized or even have consensus amongst vendors, just like Microsoft did around the turn of the century. While Chrome is a great browser, if that's where you're developing, you're more likely to accidentally end up using things that are half-baked or have poor support in other browsers.

Opera used to be really great at this back in the day. They never had huge market share, and they could be a bit slower to implement things, but when they did, they were utterly scrupulous about following standards. If it looked right in Opera, you knew your code was good. I'd like to think that Firefox is close to that same ideal today, but pragmatically speaking, using any alternative engine for development will put you in a better place for cross-browser compatibility.

My eyes!

You should really consider changing that background to something less... intense.

Edit: For anyone designing for "the fold"; learn to love the <code>vh</code> unit. Also keep in mind that you can write vertical media queries as well.

>Chrome has turned into a bloated mess

Try Chromium. It's the base for Google Chrome, and is basically Google Chrome without the Google.

The IE circlejerk is still legitimate. IE still lags behind Chrome and Firefox. See the table here. It's not nearly as bad as it was, but part of the problem is that IE updates relatively infrequently compared to Chrome and Firefox. Remember that many users are still on IE9 or IE10.

For many users, IE11 is a fine browser; but that goes out the window as soon as the user visits a site taking advantage of some bleeding-edge features, or wants to use a browser extension.

[Edit] I should also add that IE is Windows-only. So Linux and OS X users, while obviously a minority, rely on cross-platform solutions, like Firefox and Chrome[ium]. There's also the fact that some users might not be comfortable using a closed-source browser.

Noob developer here, I'm wondering how long it takes before new technologies gets accepted? As seen here it's supported by a small number right now. But I think this looks great, when could/should I start consider using this?

>For clarification, this is embedded in CSS right?

It is a W3C standard supported naively by most browsers.

> Also, what are the implications of using this on unsupported browsers? How do you design around that?

I wouldn't bother (if you have the option). Its supported widely enough that you shouldn't have to worry about the browsers that don't support it at this point.

http://caniuse.com/#search=flex-box

edit: here are two more resources for learning flexbox that are pretty cool:

http://www.flexboxdefense.com/

http://flexboxfroggy.com/

Nice work. I also built a jQuery plugin a while back for the same purpose.

https://github.com/BGStock/jquery-background-video

I also added stuff like an optional pause/play button, fading in over the background image, etc.

One tidbit you might be interested in... In your blog post you wrote:

> It seemed like JavaScript is the only solution to this problem.

That's true, but only because of browser compatibility. There's a CSS property that does exactly what we want, it's just not widely supported yet. object-fit: cover; would do all the same stretching and positioning as your JavaScript. I was pretty excited to learn that so thought I'd share :)

'Floats' is the answer to the question "what flexible layout approach can I use instead of tables that will work in IE6." It's not that it's bad per se, just that there are options with fewer gotchas which were designed expressly for layout that now work on 95.31% of browsers.

Flexbox is supported by 93% of Internet users. (http://caniuse.com/#feat=flexbox)

That's 3% more support than borders radius (http://caniuse.com/#search=Border-radius).

Just saying, flex has arrived and it's totally reasonable to expect people to be able to support it (especially with a polyfill).

Yes, SVG is amazing – tiny file sizes, unlimited scalability without major distortion (btw check out those websites using SVGs on mobile, it's crazy crisp). Moreover, you can go pretty much wild with CSS on SVGs, using e.g. this approach to manually extract SVG contents into your HTML (without this, SVG elements aren't directly accessible via CSS).

Nowadays, I generally use SVGs for everything, that isn't a photo – logos, simpler graphics etc. And for icons as well, but those I transform to webfont, which is even more awesome.

Cons? Browser support – but if you don't care about IE<9, go ahead ;)

Why not using the native Promises? Their cross browser support is actually pretty good. For the non supported browsers, you can find some great polyfill easily.

Native Promises are known to be slower than Q or whatever, for now. But what's great about them is that:

They're being used for next EcmaScript/JavaScript features (like async/await)
They're actually native, and future proof
The performances will eventually rise
You can find some great debug tools, like the Ember Promises manager

Just to add some additional information:

There are some interesting things happening here:

The video is being scaled with simple CSS width/height changes.
The width changes to match the browser window width. The height scales automatically.
The margin is only there to account for the cookie usage notification.
Notice the two different formats.
- WebM is supported by Chrome and Firefox.
- MP4 is supported by IE and Safari.

The overlaying (user-interactive) element is given a big z-index to make sure it displays on top of the video.

> jQuery, for example, provides a really powerful element selector which saves you writing a lot of code compared to writing it in vanilla JS.

Nowadays, the selector itself doesn't really considering there's the standard querySelector and querySelectorAll methods, jQuery has a few useful custom pseudo-classes but the situation has much improved since 3-4 years ago when you'd pretty much have to walk your DOM tree by hand (using getElementById, getElementsByName and childNodes) if you didn't use a selectors library.

Where jQuery still shines is:

Fluent/literate syntax, the DOM simply has no provision for doing something like getting an element, setting an attribute, setting a property and changing the content text all in one expression, you'll need at least an assignment or two in there
Bulk operations, they can also be a performance trap, but with raw DOM you'll have to manually iterate that shit, no selecting half a dozen elements via CSS and trivially setting their color or whatever. Well at least querySelectorAll ~~returns a native Array, not a fucking NodeList~~ actually it still returns a bloody shit of a nodelist, thanks mkantor for fact-checking me.
Events handling. First is the events binding itself, while IE9 finally implements the standard addEventListener IE8 doesn't and will still require either building a shim or having multiple paths for events handling. Second addEventListener is way more verbose than on or bind. And third, doing event delegation manually (.on with a selector or .delegate) is Not Fucking Fun: IE8 doesn't (of course) support Element.matches() at all, but more annoyingly all Element#matches() implementations at this point are prefixed so filtering your target is going to be verbose and repetitive.

No, not at all. As a web developer I can tell you there are many things that IE does not do or does wrong.

Here is a nice table showing what I mean: http://caniuse.com/#compare=ie+8,ie+9,ie+10,firefox+16,firefox+17,firefox+18,chrome+22,chrome+23,chrome+24,safari+6

IE is slowly getting better but since I (and lots of other developers) still have to support IE8 you can understand our frustration.

According to CanIUse, flex: 0 1 autoisn't universally applied; IE 10's default is still flex: 0 0 auto. So defining it is still warranted, although specs call it the "initial" value.

Specs are ultimately recommendations or suggestions of what "should" be, not definitions of what everyone's actually using. It's therefore unwise to approach them as what you, the coder, "should" be doing.

It's like how e-books can have JavaScript in them, but most vendors won't accept them that way. (Which is rather annoying if you want to build in a language switch.)

> The spec really should include something to clear out all previous CSS styles on a given element and its children.

all: unset; is supported in all relevant browsers except IE11.

> Edge beats both Safari and Firefox for HTML5 compliance.

Edge does not beat Firefox for HTML5 support. I'm not sure where your Imgr pic came from, but CanIUse Browser Scores for Edge (v14) and FireFox (v48) are 200 and 241, respectively. Edge is a huge step forward for Microsoft in the browser world, but it does not beat FF (yet), nor does it hold a candle to Chrome.

Edge does beat Safari. CanIUse scored Safari 189.

Source: http://caniuse.com/#compare=edge+14,firefox+48,chrome+52,safari+9.1

Here is the browser support:
http://caniuse.com/#feat=css-transitions
No real reason to not use transitions imo.

csgo is using jQuery .fadeIn() and .fadeOut().
To fix the bug you would use .stop() or .finish() before these.

As others have mentioned: It just haven’t been a priority.

It’s been in the CSS3 specs for 4-5 years, and it’s slowly getting adoption, with Firefox, Safari and IE/Edge supporting the prefixed format. Chrome (incl. Chrome Android) still don’t support it, although work on it is scheduled for sometime 'early next year'.

For modern browsers, yes: http://caniuse.com/typedarrays

And typed arrays can only contain primitives, like int or float. For all practical purposes JavaScript does not have an array the same way Java or C++ does.

That said, typed arrays are essential to WebGL and are used to implement VMs and emulators in the browser. They're worth knowing about, but are not much use in day-to-day JS work.

It's has to do with HTML5 video support in Firefox, nothing to do with google. Chrome just happens to be ahead of other browsers when it comes to certain features ( like playing Netflix on Linux)

Edit: I think the root commenter must have had a really old version of Firefox as they've supported VP8 for awhile now and the last VP8/4k bug I see is for FF version 37

Things looking right to you have little to do with whether IE9 is a good web browser.

Scroll down to the bottom of these compatibility tables to see the summary:

http://i.imgur.com/Qdegv.png

Also look at specifically what's missing entirely from IE9:

CSS3 selectors
Drag and drop
WebGL
File/History API
etc

CSS grid layout is still in working draft & has almost no browser support at the moment, so a major site like New York Times wouldn't be using it.

I thought it might be flexbox, but I'm guessing they need a lot of legacy support.

> object-fit: cover;

I have found the easiest way to do this with wide browser support is ...

Then support with

#video-container { position: fixed; top:0; left:0; width:100%; height:100%; video { position: absolute; top:50%; left:50%; transform:translate(-50%,-50%); -ms-transform:translate(-50%,-50%); /* IE 9 / -moz-transform:translate(-50%,-50%); / Firefox / -webkit-transform:translate(-50%,-50%); / Safari and Chrome / -o-transform:translate(-50%,-50%); / Opera */ min-width:100%; min-height:100%; } }

Setting min-height/min-width both to 100% ensures it "covers" the parent element in just about everything, plus transform to vetically/horz center it works a ton better than "object-fit" whose support is still super ropey.

I tend to fallback to an image background for IE unless it is absolutely essential video works. I also use images on mobile because I would personally hate it if a site preloaded/played a massive video background on my own data plan :)

It may be fast, but IE still trails behind when it comes to feature support. See: HTML5 support, JavaScript API support (scroll down for the feature summaries).

(And yes, it has been improving, but some obvious things are still missing outright, like the Web Audio API, which is in every other major desktop browser, but still isn't even in the latest Technical Preview)

Based on what?

Here's a chart comparing HTML5 support in different browsers..

Also, check out the chart on the bottom of this page, which breaks down what features you can use on each browser.

I'm sorry, but IE is still way behind in a lot of areas.

As a webdev, here are some reasons. Though I agree, IE11 is massively better than its predecessors and is no longer a bad choice. I still think Firefox/Chrome are better choices, but I would be happy if all of the IE10 and under users upgraded to 11. Also, 11 has auto-update on by default, which will be a huge boon for future version adoption.

This article was a bit too opinionated for my taste and shows a clear disrespect for people who spend time and effort to eleborate on their reasoning. Where it does eleborate it comes with a use case where it nearly takes other approaches in jest. Almost feels like a strawman if you ask me. A bit tasteless if you come up with a conclusion that doesn't align with the title.

"In an ideal world, everyone would just believe everything I say without me having to back it up with ‘evidence’. But I have been told this is not the case, so please, follow along as I begrudgingly assess each of the reasons for using these flimflam units of measure." < fuck you.

If the writer wanted to make a clear solid point rather than an opinionated piece he should have come with up with the cross device support incompatibillity first. Most of it is based upon a single testpage. "If I limit my reasoning with cherrypicked homebrew concepts, I am probably always right"

If this article was the result of a rant against a hype it would make sense to me, but the way it was written almost feels childish to me.

Here's the thing: sometimes it is really usefull to build your pages module based and use some kind of root text element to define a pixel value, now other elements in this module can base their proportians of this base. REM units do not work as expected in all cases. http://caniuse.com/#feat=rem .A sense of scaling can provide logical structure to such modules. Wether you use px, ems, percent or other values, you should always test and review choices before putting it on a production envirement and it helps to use the right elements, properties and units/values. When in doubt, check the w3c spec, caniuse and make sure to test it for the problem child browsers.

It's for example it's behind on common audio/video encoding, and can't use the camera. This means a HTML5 video conferencing tool will work on Edge, Chrome, even the stock Android browser, but not safari. You can play video, but you need to use H.264, which officially requires a license to use.

WebGL has been absent for years after Chrome has implemented it. The code is open source and Apple could enable it any time they wanted.

There's notifications: on desktop and on Android websites can push notifications to a user's device. On iOS you'd need to write and publish an app to do so. My source says notifications are impossible on iOS using just Safari.

There's also the fact that in order to update Safari, you need to update iOS. If your device can't run the new iOS, you can't run the latest Safari. Google has solved this by updating the browser from the Play Store so even devices running on Android 4 get the same compatibility as devices running Android 7. If your device is too old to install the latest iOS, you literally can't get a better browser until you buy a new device.

Industry standards: there aren't tonnes, but there are lots of people with slightly different opinions. My advice: read a bunch of articles about how people do it. Atomic design, material design, BEM, Smacss, etc. Everyone has their own setup, and you need to try a few out and see what you're most comfortable with. http://caniuse.com/ is invaluable for working out whether a css rule is widely supported or not. Video tutorials are also a good way to see how people have things set up.

Where do you learn design? well, I did a course in graphic design, which is helpful, but a lot of the time, I learn by copying. make big collections of work you admire, and copy bits here and there until you have a good idea of how things are normally structured. I'd advise against trying to design in the browser, because the design is a visual thing, you shouldn't limit your designs to only stuff you can immediately get working. Try designing the elements with a pencil on paper, or a program like photoshop, illustrator or sketch. Then replicate that exactly on the screen (I often use codepen to create individual elements, before incorporating them into a project)

Hosting The main story with hosting is that there's one big company which is buying up many of the major hosts: Bluehost, hostgator, asmallorange, arvixe. They're called EIG, and they have a tendency to turn well managed hosts to crap. Try to avoid them. Others to avoid: 1&1 (worst host I ever dealt with) and I tend to avoid godaddy too (not especially bad service, but will try to sell you on more than you want to buy.). My current recommendation to clients is namecheap, but I've also heard good things about dreamhost, amazon web services, and Digitial ocean (if you want to set up your own server and stuff, slightly more advanced.)

http://caniuse.com/apng

Apparently because half the things don't support it. Such a shame too, I thought it was the GIF killer back when it came out in 2008. It went underground in less than a few months though.

Safari does not currently support the shadow DOM.
http://caniuse.com/#feat=shadowdom

In Safari, the letterboxing overlays just fine. The problem is that the video controls are z-indexed through a CSS pseudo-selector that belongs to the shadow DOM. Hopefully it will be supported soon.

From a cursory glance the NYT doesn't bother with a fallback, and BBC always uses Flash.

But really though, it's 2014. I'd argue that considering mobiles/tablets you'll reach more people if you go HTML5-video exclusive than Flash-exclusive. Every modern browser supports <video>, since IE9.

tbh no browser fully supports CSS at the moment. I'm sure that if you need to support IE you know you won't be able to use CSS4 anyway, but Edge will probably support most of these functions in the future.

Ugh, downvoting you for pointing out a perfectly valid consideration. Modern browsers support calc() and that's great, but every project is different and may have different demographics using different devices and browsers.

If people looked closely at the traffic stats for various projects they'd be surprised at the number of visits sites get via rickety old browsers or browsers you never heard of. You can say, "Tough luck, upgrade" if you want, but for business websites the owner may want every possible lead / customer they can get. They're not going to turn away a customer because they're running Opera Mini or an outdated IE.

I use calc(), it's awesome. But on a client site I would be extra careful. Ideally I would look at their traffic stats to see what browsers are actually, (not theoretically), being used by their specific customer base. A tiny percentage of visitors on a high traffic business website can still translate to a lot people and hence a lot of lost money.

And additionally, even if you only want to include recent browsers like IE11 in your target you still need to be aware of compliance because it has a number of quirks when using calc(). See "Known Issues" at http://caniuse.com/#feat=calc

Honestly, downvoting someone for advocating cross browser testing in web design? Really??

Yea, this will target mainly the IE users :( So of course some workarounds and polyfills might be needed, like Flexibility.

Luckily more and more people around the world are using the better browsers nowadays, so in my honoust opinion it's not bad to start using it right now, and deliver some alternatives for browsers that lack the support. But that's just me thinking that Flexbox is a great candidate for a new upcoming standard in layout building.

So Kraken is blaming the issues on CloudFlare downgrading them from the paid business account to the free account.

By their own tweets, the restrictions that were imposed on them are SNI (SNI is accepted by 97% of browsers) and a new certificate which was TLS1.1 or greater (which they say is an issue with WinXP)

Meanwhile the USERS are complaining about slow loading pages, broken JavaScript, and internal server errors (5xx). It seems like the real issues are completely unrelated?

Compatibility doesn't mean you have to deliver the same experience in every browser. It just means that every experience should be a good one. Also, IE 9+ doesn't require a lot of accommodation.

http://caniuse.com/#search=canvas

Thing is, they do focus on supporting web standards (example ; scroll down to see what they've implemented of just these features over the last few versions). In fact one of their primary focuses for the past 6-8 months has been MSE, but it's a huge spec that is arguably still not fully complete. But people don't really care about such details. They just want it yesterday.

While I appreciate the idea, many of these require additional markup (an extra span — Picasa has 2 extra spans!). This, combined with a fairly ugly CSS rules, and the difficulty of modifying the content, makes this a harder to argue over just using inline SVG graphics.

Inline SVG gives you all or most the benefits of an icon font, without the additional request(s) for the font and css. And SVG has darn good support now.
It's very easy to replace the inline SVG with new content if a single logo changes, but it most likely is more difficult to update the icon font and CSS for a single icon.
There's no reason to download the entire icon font if you only need a few of the icons. This isn't a huge issue with caching or building a custom icon font, but still might matter.

I think there is some argument for using both :before and :after to create a 2-color icon using a single element, but that's about it.

A few misunderstood concepts,

node.js IS the server (it will replace whatever backend stack you are using, such as Apache+PHP).
> set up a connection (or socket), with the server

You are talking about WebSockets

WebSockets have nothing to do with node.js, apart from the fact that node.js is capable of serving WebSocket clients
Not all major browsers support WebSockets: http://caniuse.com/websockets

If you want your <IE10 users (which isn't even out yet) to be able to use your chat app, use ajax polling.

As for bandwidth, WebSockets has far lower overhead per message than AJAX requests, but there are other considerations introduced when dealing with persistent connections (mainly on the server).

From the console.log of the website:

>But how does it work?

>Check out https://github.com/chrisbolin/react-detect-offline (if you're online!)

>Spoiler: window.addEventListener with 'online' and 'offline', plus navigator.onLine

>If it isn't working for you, maybe your browser isn't supported - http://caniuse.com/#feat=online-status.

>If that's the case, run window.help() for the spoiler.

>Content is cached for offline use.

This kind of markup clutter is why I wish more browsers would get a move on and ship Web App Manifest.

At this point, an HTML file is just sort of a bootstrap for JavaScript. The smaller and simpler we can make it, the better.

> I never noticed how far FF was behind other browsers in terms of supported frameworks until I tried to build a website.

What exactly are you referring to...?

http://caniuse.com/#compare=edge+14,firefox+49,chrome+53,safari+9.1

https://html5test.com/compare/browser/firefox-48/chrome-52/edge-14/safari-9.1.html

That you claim that Safari is up to date... I don't even know what to say about that.

Did flexbox join yet? I thought support was still lacking.

edit Apparently I've been out of the loop. Flexbox is supported: http://caniuse.com/#search=flexbox but the comments below say there are still some bugs in the implementations.

OK, a website that tells the best techniques to optimize for performance meanwhile having 131 requests and a load time of 3.6 seconds - and I'm on a 1Gbit connection. With uBlock that blocks all the ads, analytics and tracking scripts.

This is just telling the same story for the 100,000,000,000th time, and even then it doesn't even mention the new HTTP/2 push feature that's available in every major browser which allows you to push all the required assets through a single, multiplexed connection.

It's more than past time to move completely to flexbox for modern projects.

Do you use position: fixed? Have you used calc() in any css property?

Guess what, both of those have less browser support than flexbox. Browser support is absolutely no longer a valid reason to not use it.

Source: caniuse.com for calc, position: fixed, and flexbox.

Why use gif? HTML5 supports video via the <video> tag. Pixel for pixel video is going to be less KB. It has good support - http://caniuse.com/#feat=video

Unless you want to create a slided gif which only changes action 4x per second or so, then Photoshop or Fireworks can be used with screenshots.

As a web developer, let me tell you it's not. While one reason is that IE8 still has a high enough market share for some customers to justify supporting it, IE9 all the way up to IE11 lack more features than other browsers do.

It got better, but I still hate you for using it.

It's close, but it's still not quite there.

No support for:

iOS Safari < 7.1
Android < 4.3
Opera Mini (any)
IE8

That's about 14% of users right there (and I think that's conservative from what I see on GA).

http://caniuse.com/#feat=viewport-units

Modernizr does however have a non-core detect for vh/vw.

Chris Coyier made a good point in his article. Use Modernizr.load to detect support and load up FitText.js as a polyfill. FitText is pretty solid too.

> I won't comment on JavaScript since it is proprietary to Oracle across the board

Actually, no. You're confusing JavaScript with Java. Java is proprietary to Oracle. JavaScript was developed by Netscape at about the same time and called it JavaScript because Java was the cool thing at the time. The proper name for the JavaScript language (which nobody uses) is ECMAScript, because ECMA is the standards organization responsible for it. You're probably not very interested but here's a copy of the standard (the license is at the beginning).

As to the speed of the JavaScript engine, it's not option 1, since Firefox and Chrome support more APIs than IE. It's also not necessarily that the implementations use less code, but the code may be better optimized -- for example, I believe Firefox and Chrome use a JIT compiler (just-in-time compiler) to compile the JavaScript to bytecode while executing it. This is more complicated to implement, but it really improves performance especially when code is run many times over the life of the page (e.g. an application like Gmail or Google Docs, or even something like RES). It looks like the newest versions of IE's JavaScript implementation uses a JIT compiler as well.

The quote line is part of reddit's Markdown syntax. Click "formatting help" under the edit box.

JavaScript was originally proprietary to Netscape, and was turned into a public language called ECMAScript, though most people still call it JavaScript. Recently, they have decided to come out with yearly updates to the language, and use year names, but the specifications are still versioned, causing some of the confusion.

These versions are released at the end of June.

ES6 = ES2015, which is the first major update in a decade. Most of the "new things" in JavaScript are ES6.
ES7 = ES2016, which was only two small additions.
ES8 = ES2017, which includes async/await.

Current browsers have pretty broad support for ES6, but there are some small gaps that you may need to watch for if you are pushing the limits.

You can check out support for specific functionality in the Browser Compatibility section of most MDN pages. or look at caniuse.com for the feature.

Edit: formatting.

http://caniuse.com/css-grid/embed

Sadly it doesn't look like it's support is that good yet, but it's not too bad. In a couple years it will probably be widely supported.

Edit: I can read the chart, and have since realized that mobile support doesn't matter much after finishing the video. Thank you all for pointing out what is already on the chart to me.

I've heard a bit of WebAssembly, which is similar to assembly (the language), but still in a VM (like Javascript). It allows languages like C or C++ to be used in a browser.

It won't necessarily replace JS, but WebAssembly is faster than JS, so it's better for system intensive tasks.

Here's the current support for WebAssembly

EDIT Correct a few things

Das liegt daran, dass das CSS-property für automatisch Umbrüche von einigen Browsern noch nicht supported wird. Sich darauf zu verlassen ist daher imo ein Fehler des Entwicklers. Entweder setzt man die möglichen Umbruchpunkte schon im html (per Hand ne Riesenarbeit und für ne Zeitschrift daher eher unrealistisch) oder man lässt es halt mit dem Blocksatz. Gibt dann noch so mehr oder minder ausgegorene javascript-basierte Lösungen aber so richtig toll ist das alles nicht.

Aber das die Textzeilen kurz gehalten wird, hat schon seinen Sinn. Wenn die zu lange werden, verliert man schnell die übersicht in welcher Zeile man nun war. Aber ich stimme schon zu, dass die hier vlt zu kurz sind.

First off, location and the DOM (Document Object Model) are two different things and this issue does not expose your DOM. That said, it could be used in attacks by, for example, replacing the opener page with a fake Facebook login page to steal credentials.

Also, the issue isn't target="_blank" specifically. The issue exists for any use of target that results in an open window. So if you are using named windows like target="sponsor", this problem also affects you.

And be careful that you use both noopener and noreferrer, since the former is only supported currently in Chrome and Opera (that is, Blink-based browsers). Any browser based on Gecko or Webkit will have this problem.

And a couple of points Ben mentioned that might not pop out at you:

The same issue exists if you are using window.open() instead of simple hyperlinks. This was the recommended way of opening new windows in HTML4 (when target was deprecated) and may still be standard behaviour in HTML4 software (such as some Wordpress plugins). You need to explicitly unset opener there as well, or the linking page could be victim to the same problem.

And if you did use window.open(), this issue cannot be fixed for Safari. Webkit added noreferrersupport in 2009 but seems never to have extended the support into scripting.

Flexbox works in 95% of browsers now. It's generally safe to use, lest there is need to support IE9 and down.

For IE9 support, lost is a pretty nice grid system.

Usually I just throw this is in for a quick and dirty grid.

.row { display: table; table-layout: fixed; width: 100%; }

.col { display: table-cell }

Then something like this will create a grid-like row with four equal width columns.

For anyone else interested, webGL is supported only in the latest versions of IE11. caniuse

Edit: most other browsers have supported it for a while. (Thanks /u/ellisgeek)

I learned a while ago. w3schools is pretty much a not bloated listing of what attributes are available for each tag, how is that horrible? I'd understand pointing to http://caniuse.com/ or something to find out how well things are implemented.

Hey!

Whenever you're curious whether or not a technology is a good idea for your project, you should always think of at least these few things:

Who is my target audience? Does my target audience need this technology in any way?
- Simply customer and audience research will do the trick here, ask if they see any difference between two prototypes, etc.
What devices/browsers will my target audience be using? Do these devices/browsers support the technology and how do I implement this?
- For this specific case, you can look for browser support here: http://caniuse.com/#search=svg
- Then for each browser, look up specifically what the restrictions are and how you implement it
Is it worth the time you're putting into this? This one is very hard and somewhat subjective. I maintain the thought that you cannot predict the future, but whenever you see an opportunity to do something better for the benefit of your target audience, always try to implement it if you can get away with it.

And specifically about your subject: SVG is somewhat of a new technology for some browsers. Specifically IE is a bit late with implementations (SVG Filters for example). Gecko (Firefox) and Webkit (Chrome, Safari) browsers have been supporting SVG a bit better.

If you're planning on having a very big target audience, you might want to use SVG with PNG fallback so you'd at least see an image where it should be.

Also, if you're planning on using SVG animations (SMIL: http://www.w3.org/TR/2001/REC-smil-animation-20010904/), do not embed your SVG image as backgrounds, because the animation won't work in Firefox or IE.

text-shadow, specifically. Every browser supports the more basic text effects, like underline, but some of the more advanced stuff like text-shadow is only implemented in the more recent browsers.

Fun thing about text-shadow, by the way. It was described by the original CSS2 spec, all the way back in 1998, but nobody ever bothered implementing it…except the rather obscure KHTML engine, which for a long time was the only one that implemented text-shadow.

But then, KHTML became non-obscure very quickly when Apple decided to use it as the basis for their new WebKit engine, inheriting its text-shadow support in the process. This likely helped to convince the teams behind the other major engines (Microsoft's Trident and Mozilla's Gecko) to get around to implementing it. Today, at long last, the current version of every major browser supports it.

Browsers interpret information and display it.

Every now and then new features will get added to the code languages that make up websites.

IE quickly fell behind when staying up to date.

An example of IE failing to keep up is the WebM video format.

Browsers like Chrome and Firefox not only perform better, but have more features and capabilities.

IE's UI was also pretty outdated at one point, they've caught up a bit, but they're still not on par.

To sum up, IE is outdated.

This is of relevance. Browser support for flexbox isn't quite there yet, but the most recent version of every browser you should care about has solid support for flexbox, and it should be ready for prime-time in terms of the support of previous versions of browsers relatively soon.

As usual that's an "it depends" answer. Having a lot of HTTP requests can really hurt your page loading speed, so if it's a lot of small images it's probably best to go with the data URI, or even better put them in a spritesheet.

Data URIs won't compress as nicely though so once they start growing larger it's probably worth the cost of an HTTP request. Besides, then the image is cached and can be referenced on other pages without cost.

Browser support is another thing to consider. IE7 and below can't use them, unfortunately.

One issue I have with embedding base64 data is it's just a pain in the ass to work with. You can't search for logo.png anymore, and making small adjustments require not just updating the file, but updating the file, converting, and updating the text.

If you're looking to do speed comparisons check out http://webpagetest.org and run a couple tests with each configuration.

You seem to be confused - IE totally supports min-width and max-width, see here: http://caniuse.com/minmaxwh

Make sure you always use the standard HTML5 doctype for best strict mode rendering:

<!DOCTYPE html>

For IE7 and IE8, I do not support responsive design. They are obsolete and should just be served a single layout. What I do is I use Susy which creates an IE-only stylesheet based on my desktop media query layout automatically.

/* modern browsers / @media (min-width: 45em) { article { text-weight: bold; } } / IE stylesheet */ article { text-weight: bold; }

See the documentation on building an IE stylesheet automatically from your media queries here: https://github.com/ericam/susy/blob/master/docs/source/guides/reference.html.md#breakpoint-ie-output

This is an update to *JS. Here's the previous post on *JS and the link to the project.

Changes seem to be:

a new name. More searchable!
generated JS side-by-side with the LLJS. Impressively small!

Adopters beware the choppy browser support for typed arrays.

If a modern browser can be assumed, you could use:

document.querySelectorAll('#blog-entries > li').length

querySelectorAll isn't available on IE < 8, however. See http://caniuse.com/queryselector

Support is currently at 37% and climbing rapidly. The best part is that you can use @supports (82%) to enable grids in your CSS, and just use Flexbox (97%) to get Good Enough layouts for the folks who haven't caught up yet.

Obv the usage stats on your website may vary.

What is Reddit's opinion of Can I use?
From 3.5 billion Reddit comments

➔ Can I use website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

IF INSIDE AN APP:

IF INSIDE A WEBPAGE:

TlDr;

What is Reddit's opinion of Can I use? From 3.5 billion Reddit comments

➔ Can I use website

By popularity on Reddit, this Service is:

100 reviews of this app found across Reddit:

IF INSIDE AN APP:

IF INSIDE A WEBPAGE:

TlDr;

What is Reddit's opinion of Can I use?
From 3.5 billion Reddit comments