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.
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!
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 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.
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 :).
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 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.
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.
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.
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
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.
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?
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
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.
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.
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.
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)
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?
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.
