Show HN: Get pinged when standards hit 90% browser support | Hacker News Reader

Show HN: Get pinged when standards hit 90% browser support

frontendhq.com

199 pointsAlexMuir48 comments

I built this over the weekend because browser support is a moving feast. I'd find myself exploring SVG, thinking "That's great - I can't wait to use it." And then not noticing that there is basically 95% support now.

Very cool. Signed up. I often find myself looking at technologies and thinking "Oh, I'll use that someday," then forgetting about them.

Feature request: Allow user to set minimum required browser support more granularly, e.g. 'IE>9 && 90%', kind of like how https://github.com/postcss/autoprefixer does

Great idea. I wonder if there is public data making a ping by market segment possible too. For example I have to maintain a web app which is aimed at corporate users thus our current baseline is "it has to work in IE8 but it's allowed to look ugly until IE10" so if some sample of usage by IPs owned by known businesses fell below a certain threshold I could be informed.

In addition to email, could you provide an RSS feed as well?

I think there's an RSS feed at caniuse.com so that should probably be the primary source. But it's been requested a couple of times so I'll write it on a list and get it up at some point.

This is so cool, I had a similar idea when Yo came out (a Yo app that Yo's you when there are changes in web standards and adoption rates). This implementation is great and very straightforward!

This is probably a rather unpopular position among web developers, but please don't let your desire for the new and shiny get in the way of making the content on your site widely accessible. I've seen quite a few sites turned from simple and easily readable to complex, slow-loading and irritatingly gimmicky because the developers felt like putting in all the bells and whistles they could.

Sometimes it's the other way around.

Designer wants a specific effect anyway, and switching from an ugly Javascript/jQuery implementation to a simple (but recent) CSS rule can greatly improve accessibility and performances.

Of course, and there are a bunch of beautifully designed websites consisting mostly of text and images where scrolling is laggy even on a modern computer. On the other hand, new features in HTML, CSS and JS occasionally let you replace a complex, slow-loading and irritatingly gimmicky workaround with simple, clean code :).

maybe it's not just useful for the now.

it could tell you in 5 years time to tweak a few things.

Anything over 90% is good enough for me personally, I can't be bothered to not use recent features in CSS/HTML because IE>9 us god awful and Opera Mini doesn't support it.

This is pretty useful!

As an aside, please consider sending a confirmation email to the address and subscribing only afterwards.

...why? Send an email to confirm that it should send one more email?

> ...why?

So that if somebody mis-types their address and ends up entering mine, I don't get bombarded with crap that I don't want. It's incredibly annoying when this happens.

This service sends one email. Confirmation would just mean you get bombarded with the exact same number of unwanted messages: 1.

Confirmation would still be useful, though, to let the actual user realize they entered the wrong address.

It sounds as though it actually sends you multiple emails

This is typically so you can't simply subscribe someone else using their email. The 'victim' would only get a single email and they'd have to subscribe to keep receiving them. It also avoids typos etc.

I had the impression that you chose a standard you care about and it is going to send exactly one email. With confirmation, that would become two.

http://www.lsoft.com/resources/optinlaws.asp

Great idea! We need the same for ES6/7/etc. — http://kangax.github.io/compat-table/es6/

Cool! Any possibility you'll add an RSS feed in the future? (Unless there is one and I missed it)

I'm not sure "user-select: none" is "2 days away." I shudder to think about the hacks I've done to make it work. My favorite is capturing clicks on an overlay, then translating the click point to where it needs to be and simulating a new click with the modified values on the underlying layer, which also happened to be in an iframe. I still get shivers.

I'm curious what you're trying to do. That rule sounds like it would be perfect for causing the same sort of irritation as the "disable right-click" and "disable copy-paste" scripts that were popular years ago.

The spec suggests that it would more be to avoid selecting things that are not part of the text flow of the document, which would be a usability win. i.e. captions that are in the middle of the flow, etc.

But you're right to point out it could be used by the unscrupulous sort of people who also like to disable right click, and that would indeed by highly annoying.

If you have suggestions on how to mitigate that (making the feature less useful as a copy protection without affecting (too much) the intended use, I'm happy to update the spec.

Is a modifier key possible? E.g. holding down shift allows you to select all text? Or a context-menu option on the unselectable text to copy the whole block? Excuse my naiveté.

CSS is device neutral and works on things that don't have shift keys or context menus, so we can't specify the mechanism. However, we can make it allowed, or even recommended for browsers to provide a way to select anyway, even if the spec leaves it up to the browser what UI it wants to use for that.

Done: https://twitter.com/CSScommits/status/587951029661990912

It's not, I promise. For our product (https://populr.me), we want to keep our interface's styles and javascript completely separate from our user's themes' custom styles and javascript. Our editor actually loads the user's themed page into an iframe and overlays interface elements in the parent page on top of everything.

If you care for "user-select: none", you might be surprised to know that there wasn't an official spec for it to help the browsers interoperably converge, and you might be happy to learn that I just made one: http://dev.w3.org/csswg/css-ui-4/#content-selection

Awesome, thanks for submitting that!

Love that standards are being written in the discussion here. As each standard hits 90% I'm going to write a detailed post on the use of them which will go with the email - I've made a start on user-select. I'd be happy to credit you along with a link to this standard if you'd like. Or I'd love to get your feedback on a draft of the article as you seem to be the authority on this! Drop me an email (me@alexmuir.com) if you get a moment.

I got a moment, so I did drop you a mail:) Thanks for looping me in.

This is my first exposure to "user-select: none" and it strikes me as a copy control mechanism. Is that the only reason for this, or are their other use cases?

Off the top of my head, I could imagine it being useful to prevent accidental selection of text in, say, a paint app or something. *I may be misinterpreting the purpose, however.

Very useful for kiosks where people interact with a screen and have no clue they are using a maximized browser. Selecting text of labels is not expected in a "native" app

I'm confused. Is this if it is supported by 90% of browsers, or 90% of global traffic?

What might be interesting here is using my own web site traffic to know whether 90% of my visitors will be supported. A simple transparent GIF should be enough to send the UA to an analytics server (or use Google Analytics)

> A simple transparent GIF should be enough to send the UA to an analytics server (or use Google Analytics)

That's a hell of a scope creep.

90% of global browsers.

I believe you can import your Google Analytics data into http://caniuse.com for this depth of information.

What browsers are considered in this percentage?

If 27 (lots of obscure) browsers support it, but 3 major ones (e.g. chrome, firefox, ie) don't, is it considered 90%?

Knowing when it "works", including polyfills and graceful degradation, is more useful, but may involve more human input to decide.

(The country you target can have a big impact on support numbers too, due to differences in browser usage)

Very cool, always been a bit of a struggle. I know this has been mentioned slightly before, but what about making this data intersect with the traffic usage.

I know this could make it very difficult but maybe combining a couple of sources with summarized data can be relatively easy and one can have a "get pinged when standards hit 90% of internet usage"

I find it an odd coincidence that both CSS3 Animations and CSS3 Transitions hit 90% support in the same week (both pretty major features).

It seems unlikely that a large percentage of people decided to update their browsers simultaneously. Is there another way features can gain browser support that I am missing?

They both launched in the same browser version of a major browser?

Updated measurement methodology gave them both a boost?

The first would still require a large number of people to update their browser in a short period.

Seems they are pulling data from caniuse.com which uses StatCounter Global. StatCounter updates their data 4 times a day and doesn't seem to have changed recently. http://gs.statcounter.com/faq#methodology.

Since most browsers shipped these together (as they're closely related), it would be very surprising if this didn't happen at the same time for both.

Nice work! I'd been using http://caniuse.com/#info_news, but it requires some manual checking still :)

This is a great idea! Useful to us :)

Reply on news.ycombinator.com