Consider implementing the new CSS overscroll-behavior property.

## Specification
This feature specification is being incubated in WICG:
https://wicg.github.io/overscroll-behavior/

Additional background on this feature may be found here:
https://github.com/w3c/csswg-drafts/issues/769

## Summary
CSS overscroll-behavior standardizes a supercharged version of "-ms-scroll-chaining". It allows developers to determine the browser's behavior once a scroller has reached its full extent.
The unused delta can be propagated to the parent causing scroll chaining, create a glow/bounce effect without chaining, or just get consumed silently. In particular when used on viewport defining element, it controls if overscroll can be used for navigation actions such as pull-to-refresh or swipe navigation.

overscroll-behavior: auto | contain | none

* `auto`: propagate scroll to the parent scroller. If there is no parent scroller (e.g., viewport) user-agent may perform a default action (e.g. navigation) or show any appropriate overscroll UI affordance. This is the default value.
* `contain`: do not propagate. The user agent may show an appropriate overscroll UI affordance such as bounce or glow.
* `none`: same as contain but also prevents any overscroll UI affordance e.g. bounce or glow.

There will be overscroll-behavior-{x,y} long-hands to control each axis individually.

## Current State
The specification and API has received positive feedback and support from EdgeHTML [1], Mozilla
[2], Chromium[3], and web developers [4,5]. We at Chromium are launching it at M63 and the feature is already in M63-Beta

[1] https://github.com/w3c/csswg-drafts/issues/769#issuecomment-270228948
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=951793#c11
[3] https://groups.google.com/a/chromium.org/d/msg/blink-dev/OqBNF2efmFA/3ByBUKyaCgAJ
[4] https://github.com/w3c/csswg-drafts/issues/769#issuecomment-279832555
[5] https://github.com/w3c/csswg-drafts/issues/769#issuecomment-288878908

** --enable-web-platform-experimental-features or --enable-blink-features=CSSOverscrollBehavior

Per spec, Firefox only supports unified plan and Chrome has now aggressively started moving towards it. Chrome has started supporting both, will move to unified plan by default soon and expects to completely drop support for Plan B by 2019.

https://bugs.chromium.org/p/chromium/issues/detail?id=465349

Testing: https://groups.google.com/forum/#!searchin/discuss-webrtc/unified-plan$20plan-b%7Csort:date/discuss-webrtc/x8lcqHRlWmA/2ycvCHE4AwAJ

The following email provides their expected timeline: https://groups.google.com/forum/#!searchin/discuss-webrtc/unified$20plan%7Csort:date/discuss-webrtc/9mVuJ7g3vgs/0yCYoRoxBAAJ

"End of April 2018: “Unified Plan” and the new APIs stabilizes. We encourage everyone to switch to UnifiedPlan semantics and the new APIs.

July 2018: Default SdpSemantics changes to UnifiedPlan. APIs listed under “Removed APIs” (except CreateSender) are removed at the same time.

No earlier than end of year 2018: PlanB semantics removed and UnifiedPlan becomes the only option."

As a web developer, the fact that ~10% of my users still use IE11, and that its features are frozen in time from 2011, is a huge pain point preventing me from using many new web platform features. (Even with a progressive enhancement mindset, there are times when the IE experience has to be pretty close to the experience in other browsers. In those cases, using the new features often doesn't make sense — it would just mean implementing the same functionality two different ways.)

So, this is a request to add a feature to Edge wherein:

1) If this feature is turned on, the Edge bowser would render websites using IE11's engine by default, but individual websites could opt-in to Edge rendering with a meta tag; or,

2) Conversely, it might be that, if this feature is turned on, websites render with Edge's engine by default, but the user can manually choose to opt-in to IE11's rendering for specific sites.

My assumption here is that some users aren't upgrading to Edge because it would break a site that they need (as opposed to, e.g., because they're familiar with IE's UI).

I know that there are features like "Enterprise mode" that can automatically switch a user into IE for a predefined list of sites, so my assumption further is that people aren't doing this because it's a suboptimal user experience (no common set of bookmarks, the user has to be familiar with two different browser UIs, etc.) and, possibly, because it's too hard to set up.

Having something that uses the IE11 rendering engine, but within the Edge browser chrome, seems likes it would offer a better experience and could be easier to set up (if it were built-in to Edge as a setting).

To me, this looks like MicrosoftWebdriver does not support proxy configuration:

https://docs.microsoft.com/en-us/microsoft-edge/webdriver

I’m using BrowserMobProxy to check if the pages loaded in selenium. It works fine for chrome, firefox and opera. I can’t get this to work with edge. Here’s my code:

public static void main(String[] args) {

String url = "http://gitlab.com";
String edgeDriverPath = "resources/MicrosoftWebDriver.exe";

BrowserMobProxyServer proxy = new BrowserMobProxyServer();

Proxy seleniumProxy = ClientUtil.createSeleniumProxy(proxy);
DesiredCapabilities capabilities = new DesiredCapabilities();
capabilities.setCapability(CapabilityType.PROXY, seleniumProxy);

System.setProperty("webdriver.edge.driver",edgeDriverPath);

EdgeOptions options = new EdgeOptions();

proxy.start(0);
seleniumProxy.setHttpProxy("localhost:"+ proxy.getPort());
seleniumProxy.setSslProxy("localhost:"+ proxy.getPort());
options.setProxy(seleniumProxy);

WebDriver driver = new EdgeDriver(EdgeDriverService.createDefaultService(),options);

proxy.newHar(url);

driver.get(url);

Har har = proxy.getHar();
HarLog harlog = har.getLog();
//That’s were the problem occurs, there are no entries when using egde !!!
HarResponse resp = harlog.getEntries().get(0).getResponse();
logAssert.assertTrue(resp.getError() == null, "Error loading " + url + " : " + resp.getError());

Integer status = resp.getStatus();
logAssert.assertFalse(status == 0, Integer.valueOf(resp.getStatus()).toString() + " " + resp.getStatusText() + " for " + url);
logAssert.assertFalse(status == 404, Integer.valueOf(resp.getStatus()).toString() + " " + resp.getStatusText() + " for " + url);

}

It works fine with chrome,firefox and opera, but when used with edge there are no entries in the harlog… There should’nt be a firewall - problem, since it’s working with the other browsers.

So maybe, simply ms-webdriver does not care about the proxy.

The video surveillance industry relies heavily on the RTSP protocol (as implemented by ffmpeg, vlc media player, live555, etc) for streaming h264 and h265 video content.

It's not a new protocol by any stretch but it is part of the ONVIF standard that essentially all video surveillance manufacturers use as well as part of the PSIA standard which a subset of the manufacturers also support (in addition to ONVIF).

It's a simple protocol and there are plenty of open source implementations.

HTML5 does not include equivalent functionality.

WebRTC pushes VP8/9 and while it may support h264 it's often online baseline h264.

Media source extensions + Fragmented MP4 + websockets can work, but it feels very hackish and it a lot of work in javascript, packaging, server side, etc just to watch a video. A couple vendors are doing it (myself included) and so while it's technically possible it's not ideal. Also the latency still isn't as good as a native RTSP connection. This is particularly important for Pan-Tilt-Zoom cameras. 1+ second latencies are very difficult to manage.

Other concerns: The video surveillance industry is starting to move to h265. Google and Mozilla seem reluctant to go there.

In my opinion it's an under-served industry and easy market share if you want it. It would also be beneficial for building UWP apps if RTSP and H264 (and H265 if possible) just worked for video elements.

https://html.spec.whatwg.org/multipage/embedded-content.html#attr-img-decoding

> Decoding of large images can block the main thread for hundreds of milliseconds or more, interrupting fluid animations and user interaction. Currently, there's no way for a web author to specify that they want an image to be decoded asynchronously, so there are scenarios where it is impossible to avoid UI stalls.

Thus the new `decoding` attribute for the `img` element, with possible values:

* `sync`: Indicates a preference to decode this image synchronously for atomic presentation with other content.

* async: Indicates a preference to decode this image asynchronously to avoid delaying presentation of other content.

* auto: Indicates no preference in decoding mode (the default).

Background discussion: https://github.com/whatwg/html/issues/1920

Tests:

* https://w3c-test.org/html/dom/reflection-embedded.html
* https://w3c-test.org/html/dom/reflection-original.html