Microsoft's CSS Scrolling Snap Points web standard proposal revealed

Microsoft announced this week it has created a proposal for a new website coding standard, CSS Scrolling Snap Points, that was made while developing the APIs for both Internet Explorer 10 and the newly launched IE11. The standard is called CSS Scrolling Snap Points and Microsoft has now submitted the proposal to the Worldwide Web Consortium with the goal of having it be supported by all modern web browsers.

In a blog post, Microsoft says that CSS Scrolling Snap Points was made to give websites better support for panning features such as photo galleries on touchscreens as well as mice, keyboards, and trackpads. Microsoft has already coded CSS Scrolling Snap Points into the Windows 8 IE10/11 optimized version of MSN.com, shown above.

Microsoft says:

Users can swipe left or right to browse the day’s headlines. Using CSS Snap Points, Internet Explorer lights up this experience using the same hardware-accelerated panning technology used for panning a Web page with touch in IE. Users get the stick-to-your-finger performance with inertia panning and over-pan bounce that they expect. Additionally, the browser snaps the content to the nearest headline after the user pans.

This feature can be enabled with just two lines of CSS code, according to Microsoft, as opposed to hundreds of lines if coded in JavaScript.

Microsoft previously submitted another website coding standard, Pointer Events, to the W3C, in 2012. Since then the W3C has approved the standard for Candidate Recommendation and Microsoft has offered Pointer Events patches that will allow the standard to work with Firefox and Chrome.

Source: Microsoft | Image via Microsoft

Report a problem with article
Previous Story

Ofcom forces U.K. networks to let customers end contracts if they raise prices

Next Story

Interview: We chat with Microsoft's David Carmona Salas about Visual Studio 2013

23 Comments

Commenting is disabled on this article.

Since its MS's proposal Google will refuse to comply with it in their worthless Chrome browser and the braindead Webkit hipster fanboys will think that since something works differently in IE than it does in Chrome that must mean something is wrong with IE.

How about mouseovers in tablets? My site uses lots of mouseovers. Somebody do something for them while using a tablet. These don't work very well with tablets (if at all). 10,000 pages shot to hell.

Even with a mouse I don't like mouseover activated things. And yes I can't use a lot of websites because they require mouse overs to trigger certain features.

Mouse over isn't a gimmick. It's very useful for giving visual feedback on what will happen when you click especially with a tight grouping. You still shouldn't depend on it for your UI to function.

annotate said,
How about mouseovers in tablets? My site uses lots of mouseovers. Somebody do something for them while using a tablet. These don't work very well with tablets (if at all). 10,000 pages shot to hell.

1) IE11 supports mouseovers
2) If you are hiding content waiting for hover/mouseover then you need to rethink your UI design.

Why not use it?

Well, as with most hover/mouseover code, rarely is it implemented in a way that all browsers can interact properly with the content when using display/resolution independence.

This is where you have a nice hover effect for a drop down menu, and then end up with 5 pixels between the menu and the drop down, that when your 'hover off' the menu to select an item, it disappears. Serious testing of the website ends up being a deployment nightmare trying to get it to scale/align properly across browsers with various scaling

Rethink your UI design, and stick to design guidelines that are common to most computer users based off of OS UI models.

http://msdn.microsoft.com/en-u...y/ie/jj583807(v=vs.85).aspx


Matthew_Thepc, said
"I believe there was an article here a while back about mouseover support in 8.1, on IE11 on a tablet you can long-press a mouseover, then the mouseover stays open so you can use it."

Thanks for the link. That's nice to know. Most of my mouseovers are menus as shown in the video. Have a Surface 2 coming so I will get a chance to see it firsthand. Most sites, this one included, use mouseovers. Good and bad to everything. I also use popup windows and layers all over my site. And the vast majority of my users are on a desktop. But I am becoming concerned about the mouseovers.

Edited by annotate, Oct 23 2013, 9:46pm :

Snap to H tag actually makes a good amount of sense. I'm not crazy about horizontal scrolling in general though, nor any of the javascript libraries that exist that use it currently.

adam7288 said,
It would take years to adopt as a standard any way.
CSS Pointer events took a year from submission through candidate recommendation. Perhaps though, the whole HTML5 thing should be dropped altogether if we're concerned about how long things take?

This is not necessary for a CSS Spec - it can be easily implemented in javascript as a small library. It would take years to adopt as a standard any way.

adam7288 said,
This is not necessary for a CSS Spec - it can be easily implemented in javascript as a small library. It would take years to adopt as a standard any way.

A lot of things in CSS could be implemented in javascript as a small library, and historically HAVE BEEN (rounded corners, for instance). Doesn't mean that we shouldn't be moving towards making it easier.

adam7288 said,
This is not necessary for a CSS Spec - it can be easily implemented in javascript as a small library. It would take years to adopt as a standard any way.
I think that I'm able to do everything CSS can with just Javascript, so CSS is pointless now?

adam7288 said,
This is not necessary for a CSS Spec - it can be easily implemented in javascript as a small library. It would take years to adopt as a standard any way.

No, not well. There should be a relationship between scroll velocity & acceleration on a surface with snap points that is not accessible to JavaScript. I'm not saying this is the solution, but there is work to do on the spec side.

waded said,

No, not well. There should be a relationship between scroll velocity & acceleration on a surface with snap points that is not accessible to JavaScript. I'm not saying this is the solution, but there is work to do on the spec side.

Style != behavior

adam7288 said,
This is not necessary for a CSS Spec - it can be easily implemented in javascript as a small library. It would take years to adopt as a standard any way.

Virtually anything could be done in a javascript library; however, this is missing the point entirely.

Standards are there for consistency and can also be leveraged for performance.

Having 50 javascript variations with each developer's 'goofy' version would just create a big mess with no touch/scroll consistency.

If implemented at the browser level, performance can also be factored and controlled with a completely seamless end user experience from site to site and browser to browser and platform to platform.

The odd side effect of opposing this standard, is that it would give IE an advantage. IE already has native support developers can use and even if left to javascript implementations, the way it handles rendering this type of content on the GPU would still leave it with an additional performance advantage over Webkit and Firefox.

If the Microsoft proposal is lacking, then let the standard be evolved and that version be implemented.

adam7288 said,
This is not necessary for a CSS Spec - it can be easily implemented in javascript as a small library. It would take years to adopt as a standard any way.

Next time, read the article?

>This feature can be enabled with just two lines of CSS code, according to Microsoft, as opposed to hundreds of lines if coded in JavaScript.

Lets just dump CSS altogether since we can do everything with Javascript instead with only 5 times the work, and since standards take years to fully adopt lets get rid of those too.

Studio384 said,
I think that I'm able to do everything CSS can with just Javascript, so CSS is pointless now?

Ha ha ha. I'm afraid it doesn't work like that. JavaScript can only manipulate the DOM (the page data generated by HTML) and CSS. Back when we were using JavaScript to make rounded corners, we were actually just creating new hacky looking HTML elements that don't mean anything.