Do Browsers Create Closures? Sometimes and Its Ugly.

While trying to simplify and extract the crucial binding bits for the Chakra script engine and EdgeHTML engine, I've come head to head with a complicated set of features in my code. These features are trying to add DOM objects to the scope chain for a special classification of functions that are defined the way they are purely due to historical reasons. We often find that only legacy compatibility can bring out such nastiness.

The HTML 5 functionality that I'm referring to is 7.1.5.1 in the HTML 5.1 nightly. This section is on event handler attributes. By themselves they aren't scary. In fact, setting the onclick property of an element is little different from a script engine binding perspective than using addEventListener. They both take an already compiled function whose environment has already been set up and use it as a callback.

Let's combine them with another concept, the internal raw uncompiled handler, and now you are about to see a train wreck. What we have is a new and special way to construct functions whose environment blocks are not the same as normal JavaScript functions. Instead of using normal closure rules to determine how variable names are hooked up, we get to instead inject additional objects like the document, a form and even the element into the scope chain. This can be quite counter intuitive since most developers are likely to think that a markup inline handler and setting the attribute handler to a function are going to do the same thing. They don't, and thus the train wreck begins.

TL;DR; You can still vote for F12 to support visualization of this strange behavior on User Voice.

Element Lexical Scopes

Okay, so let's look at the most basic of lexical scope problems. We'll have a button, on which we'll put some variables. We'll establish an onclick handler using JavaScript syntax. And then we'll access our variables by using the this variable. I've also put in a naked access which shows that our default lexical scope is Closure followed by window (Global).


We will do the same thing using an inline event handler. This time, our variable1 resolves to our button since the element was added to the lexical scope per the rules on creating a function from the markup's inline source text. I've also shown that a callout function doesn't inherit these scopes. This is most likely why people don't write code to rely on this behavior since inline event handlers are usually function calls to another method. This strips away a lot of the magic.

Form Lexical Scopes

If an element happens to have a form owner then we inject that into the scope chain as well. This is pretty important, since forms have a lot of special semantics. For instance, they have their own custom namespace that allows you to find elements owned by the form. When dealing with form instances this allows you to get to form children by specifying an ordinal index or the name/id of the element depending on the promotion rules.

An element can even be outside of a form, but also associated with it through the form attribute. This attribute will take the id of the form you want to bind to and now voila you are a member of that forms submit items collections. This technique is so strange and obscure it can even break you out of your containing form and put you in a different once. I'm not sure you'd ever want/need to do that, but if you want to, you certainly can.

The form gets injected between your element and document. This means you now have 3 new scopes, not normally available to you, in your namespace lookup. The following code snippet exploits all of these behaviors for you so you can play around with them. In this case I'm not showing the fallback to a normal property handle or addEventListener, but note the scopes melt away as you would expect in those cases.

Document Lexical Scopes vs Global Scope

I wanted to exploit a situation where you would get a different value if you used markup inline event handlers versus the property based event handler. The place where this can bite you the easiest is when dealing with differences between the document implicit namespace and the window frames namespace. Here are how the collections break down and I'm also giving them names very close to what we have in our sources:

• window - frames collection - Returns IFRAME and FRAME elements. When indexed returns their WindowProxy of type [object Window].
• window - window collection - All named items in the document. When indexed returns them as an element. Prior to EdgeHTML we did not count objects in forms. For WebKit Interop EdgeHTML now counts all elements, regardless of whether or not they are in forms.
• document - navigator document collection - Can you guess this one is named after Netscape Navigator ;-) This is another smorgasbord collection of random stuff. Images, iframes, objects, embeds, images... The HTML 5.1 Nightly has the write-up on the specific conditions of this collection at the bottom of the document object section.

When looking up on the document, we only have one namespace to retrieve from. However, when looking up from the window, we have 2. We first lookup in the frames collection before falling back to the window collection. This all blows up when you inject the document into the lookup, and you have more than one element or object that collides by name. The following example shows collisions between multiple named items for iframe/embed objects and shows how this collision is avoided by normal function bindings vs markup inline event handlers.

Wrap up

Don't use inline event handlers.

EVER!!!

They are decrepit legacy bindings with some rather non-trivial behavior backing them. And I didn't even get into all of the complexities involved. For instance, since you can't define your own parameter name to accept the event object, we have to create a named parameter called event so you have something to bind to. If we didn't you might be able to get window.event directly, but there is code on the web that just access event. This in turn will break if the element, form or document has a property or named object named event. Wow, how fragile is that!

Figure 1: Chrome showing Lexical Scopes

That said, if you have an interesting use case for when to use one I'd love to hear about it. I'm sure there are some clever uses out there somewhere. For now, this feature feels too much like the with keyword which I hate with a passion. In fact, I think that is how V8 implements these custom scopes, since in their dev tools they display them as With Block's. You can see this in Figure 1.

Sadly these intricate details are not available in the F12 toolbar making them seem like even more magic. I will add a user-voice to this article shortly after posting. I'd like to refer to it, along with the captured image of the Chrome developer tools when describing the behavior I'm after. A chicken and egg problem for sure ;-)

Update: Here is the new link for F12 Support of showing these scope chain items.

The Web No Longer Works Without WebKit

Earlier this week I wrote up the list of remaining MS prefixes. We look forward to the day we can remove each and every one of those in favor of a Standards and Interoperable alternative. No seriously, every engineer on the planet wants to build something to a design and specification that delights their customers. When a Standard lands we get a chance to do exactly that. The Standards are the blue prints and each Browser gets to build its interpretation and contribute back meaningful design changes. Once everything is done the code you write on one platform runs on all platforms. That is pretty cool and it is the promise of HTML 5.

Sometimes the standards don't move fast enough. In steps an innovator. We've all been innovators in the Browser space. Moz, Ms, WebKit and even O have all been innovators of various APIs and pre-standards. We haven't all been extremely successful with every single API proposed, but there are some APIs that stand out for sure. Probably the most successful to date has been WebKit and it's adoption on the mobile platforms. On mobile, you'll find browsers with 250+ WebKit prefixed properties and you'll find entire sites that only work in WebKit since they rely heavily on these prefixes.

WebKit is so successful in fact that to render some corners of the web a Browser has to change its shape. We have to be creative. We have to change our user agent string quite significantly to avoid detection. Then we have to model our type system after the king of the hill for the given platform. Finally we have to change internal behaviors or adapt to different input modalities in order to get reliable experiences. We do all of this so the web just works! It is a lofty goal, fun at times, confusing at others, but never boring.

So what, you might be asking, does it take to just "run the web" today if you start with a Standards browser and add a bit of WebKit to light up any broken scenarios? Well, I have a nice long list for you. So let's get started!

The First 100

EdgeHTML's First 100 WebKit APIs

To the right is our first 100 WebKit APIs for EdgeHTML. You can see that CSS was hugely impactful representing over 75 APIs. The only API layer even close to that is the FullScreen APIs and that is an area where at least Chrome has been working very hard get unprefixed versions of the APIs available. Even after they do these APIs will linger on the web for years due to their large user base. Entire sites that will only work if you have a full suite of the WebKit Fullscreen APIs available for them to use.

Many of the APIs we support are also mobile extensions. Its actually really hard to be a write once, run anywhere platform. In EdgeHTML we made a choice that we want all of your content to work seamlessly across your devices. That sometimes means implementing the mobile web APIs on the desktop and leaving desktop only APIs available on the mobile web. This is simply a price that we pay to achieve a unified platform. We'll have to see how this plays out because I also suspect we'll see cases where our desktop or mobile browser breaks when confronted with certain browser detection logic.

As an example, a few weeks back I brought up an issue around window.platform returning Win64 since we are a 64-bit browser. Chrome, it seems, returns Win32, even if they are running in 64-bit mode. Recently we found a site that was detecting precisely "Win32" and if you weren't that then you must be something else, in this case a phone. You can imagine how absurd that site looked on my 4k monitor.

CSS FlexBox

Multiple FlexBox Versions

So let's talk about FlexBox. You might have thought, 18 APIs is CRAZY, why would there be so many. You'll notice that there are two different implementations hidden in there. One is for mobile Safari and the other is for the current Chrome desktop browser.

We also had the ms prefixed version and the standards version of all the same APIs. While we could do some internal management to share some code, each one has its own little quirks to implement.

If I could pick a single feature that convinced me vendor prefixes hurt the web more than it helps, then it would be FlexBox. Probably only because of the many vendor prefixed iterations and how much of a staggered pickup there was in the web. Along with the fact that the mobile web picked the webkit prefixed versions AS their standard versions at some point along the way and often lacked fallback to anything close to a standards API.

CSS Core

Some Sharks Were Jumped Implementing CSS Core

This is my favorite grouping of properties, but you'll also get my pitch on why FullScreen is a close second in a minute.

What you'll notice is only a small portion of these APIs are actually in ANY BROWSER that we know of other than EdgeHTML. In fact 5 of the 23 are in other browsers. The other 18 are unfortunately aliases we picked up to actually fix sites that were broken. Why were they broken? Because they took another API and appended webkit to it and expected it to work. And sometimes it did.

Okay, that's not the whole story. We also, for various technical reasons, had to implement some webkit properties as aliases of our own standards versions. Due to technical limitations this meant adding WebKit when there wasn't any. If you look at all of the Background and Border properties they all really map to our existing standards versions of those APIs and to make our plumbing work, we had to implement each longhand fully. Unfortunate, but true.

Many of these are now on our clean-up lists and may not survive until the day we ship. I can in all transparency share this with you now because you could find all of this information yourself by simply walking our type system. Nothing to hide here ;-)

Update: All EdgeHTML only webkitBackground* and webkitBorder* style properties have indeed been removed. All other properties are available on at least 1 WebKit platform, whether it be Mac, iOS Phone or iOS Tablet.

FullScreen

The data for fullscreen requires that I print out the data on platform differences. IE supports all of the shown methods and properties while Chrome and Safari only support those that have a 1 in their column.

Wildly Varying WebKit Support for FullScreen Aliases

So, I really, really like this one because of the case-sensitive S in screen differences. Yes, we had to implement two APIs, but so do all the other guys so it is okay. You can also see that we have varying support for different events between the WebKit browsers and that there are some older Safari only APIs (maybe mobile only, but I think it is Safari only) where Chrome either never had them or recently removed them. I actually do apologize that I don't have my normal historical data. Maybe someone can share with me and I can back fill in more details. Or perhaps a site like icanuse might already have it and I just have to go dig it up.

The above set of full screen APIs did not come cheap for us. It came through many different bug fixes and often as a surprise. We never thought there would be APIs that varied only by the case of a single letter. That isn't normally something you search for. Had my PMs done so, they probably would have used a pivot table anyway and those things group case-insensitively and so the APIs would have been lost until we got the bugs ;-)

Table Stakes

Odds and Ends that Make a Huge Difference

This is the last set I'll go into details on before I provide you guys with a nice grouped up final listing of the full 100.

The first group I've named only Browser Detection. That isn't what the APIs were intended for, but when we discovered them on the web, that is primarily how they were being used. The presence of these APIs was almost always to figure out if a Browser was using the "WebKit Rendering Engine". I tried to do a web search for it today and found that OUR MSDN DOCUMENTATION is the first hit. I don't know how to think about that really, but it likely means the time left on this API is short as even the WebKit documentation for it is slim. Chrome already removed it and so it just lingers to support a few mobile sites that can likely now only be viewed using an iPhone or a Windows 10 Phone.

The next group are the purely mobile extensions. They only tend to show up in browsers when running on phones.

Properties like webkitTapHighlightColor are generally useful though and are starting to show up on more desktop platforms, probably due to the prevalence of touch hardware on laptops and tablets. The webkitTextSizeAdjust property is truly only meant for a phone. It helps to control text scaling on high DPI screens and allows the page author control over whether or not the browser is allowed to automatically scale things up and to what extent and tolerances. This is yet generally useful, but in EdgeHTML we'll support it even on the desktop as a property. You can get and set it. You can query your computed style for it. We won't, however, apply any of the scaling logic unless you are using the tools to put yourself into phone emulation mode. Having properties like these generally available is very useful since you can quickly switch between device modes, without reloading your page, to see how things will look.

Wrap-Up

My excitement about getting rid of the MS prefixes was about getting rid of legacy and removing things that would result in a website only working in IE or EdgeHTML. That isn't the web I'm interested in. My excitement about this post is actually much greater. It shows that a major Browser vendor can take on a challenging task to make the web just work and steer towards both Standards and Interoperability in the process. While our hope is always that these webkit properties will slowly be timed out with use counters, we might realistically be looking at a few years. In the meantime, we can hopefully enjoy a web that works better on any Browser and on any device.

Full List

Apologies for not making it a pivot table, but as noted above, Excel likes to group like named entities together into an aggregate and I wanted to show everything broken out. Enjoy!

Entity	Category	Chrome 42	Safari	IE Only
WebKitPoint	Browser Detection	0	1	0
webkitConvertPointFromNodeToPage	Browser Detection	0	0	1
webkitConvertPointFromPageToNode	Browser Detection	0	0	1
webkitAnimation	CSS Animations	1	1	0
webkitAnimationDelay	CSS Animations	1	1	0
webkitAnimationDirection	CSS Animations	1	1	0
webkitAnimationDuration	CSS Animations	1	1	0
webkitAnimationFillMode	CSS Animations	1	1	0
webkitAnimationIterationCount	CSS Animations	1	1	0
webkitAnimationName	CSS Animations	1	1	0
webkitAnimationPlayState	CSS Animations	1	1	0
webkitAnimationTimingFunction	CSS Animations	1	1	0
webkitBackground	CSS Core	0	0	1
webkitBackgroundAttachment	CSS Core	0	0	1
webkitBackgroundClip	CSS Core	1	1	0
webkitBackgroundColor	CSS Core	0	0	1
webkitBackgroundImage	CSS Core	0	0	1
webkitBackgroundOrigin	CSS Core	1	1	0
webkitBackgroundPosition	CSS Core	0	0	1
webkitBackgroundPositionX	CSS Core	0	0	1
webkitBackgroundPositionY	CSS Core	0	0	1
webkitBackgroundRepeat	CSS Core	0	0	1
webkitBackgroundSize	CSS Core	1	1	0
webkitBorderBottomLeftRadius	CSS Core	0	0	1
webkitBorderBottomRightRadius	CSS Core	0	0	1
webkitBorderImage	CSS Core	1	1	0
webkitBorderImageOutset	CSS Core	0	0	1
webkitBorderImageRepeat	CSS Core	0	0	1
webkitBorderImageSlice	CSS Core	0	0	1
webkitBorderImageSource	CSS Core	0	0	1
webkitBorderImageWidth	CSS Core	0	0	1
webkitBorderRadius	CSS Core	1	1	0
webkitBorderTopLeftRadius	CSS Core	0	0	1
webkitBorderTopRightRadius	CSS Core	0	0	1
webkitBoxSizing	CSS Core	0	0	1
webkitFilter	CSS Filters	1	1	0
webkitAlignContent	CSS FlexBox	0	1	0
webkitAlignItems	CSS FlexBox	0	1	0
webkitAlignSelf	CSS FlexBox	0	1	0
webkitBoxAlign	CSS FlexBox	1	1	0
webkitBoxDirection	CSS FlexBox	1	1	0
webkitBoxFlex	CSS FlexBox	1	1	0
webkitBoxOrdinalGroup	CSS FlexBox	1	1	0
webkitBoxOrient	CSS FlexBox	1	1	0
webkitBoxPack	CSS FlexBox	1	1	0
webkitFlex	CSS FlexBox	0	1	0
webkitFlexBasis	CSS FlexBox	0	1	0
webkitFlexDirection	CSS FlexBox	0	1	0
webkitFlexFlow	CSS FlexBox	0	1	0
webkitFlexGrow	CSS FlexBox	0	1	0
webkitFlexShrink	CSS FlexBox	0	1	0
webkitFlexWrap	CSS FlexBox	0	1	0
webkitJustifyContent	CSS FlexBox	0	1	0
webkitOrder	CSS FlexBox	0	1	0
webkitAppearance	CSS Intrinsic Control Styling	1	1	0
webkitColumnBreakAfter	CSS MultiColumn	1	1	0
webkitColumnBreakBefore	CSS MultiColumn	1	1	0
webkitColumnBreakInside	CSS MultiColumn	1	1	0
webkitColumnCount	CSS MultiColumn	1	1	0
webkitColumnGap	CSS MultiColumn	1	1	0
webkitColumnRule	CSS MultiColumn	1	1	0
webkitColumnRuleColor	CSS MultiColumn	1	1	0
webkitColumnRuleStyle	CSS MultiColumn	1	1	0
webkitColumnRuleWidth	CSS MultiColumn	1	1	0
webkitColumnSpan	CSS MultiColumn	1	1	0
webkitColumnWidth	CSS MultiColumn	1	1	0
webkitColumns	CSS MultiColumn	1	1	0
webkitTextFillColor	CSS Text Masking	1	1	0
WebKitCSSMatrix	CSS Transforms	1	1	0
webkitBackfaceVisibility	CSS Transforms	1	1	0
webkitPerspective	CSS Transforms	1	1	0
webkitPerspectiveOrigin	CSS Transforms	1	1	0
webkitTransform	CSS Transforms	1	1	0
webkitTransformOrigin	CSS Transforms	1	1	0
webkitTransformStyle	CSS Transforms	1	1	0
webkitTransition	CSS Transitions	1	1	0
webkitTransitionDelay	CSS Transitions	1	1	0
webkitTransitionDuration	CSS Transitions	1	1	0
webkitTransitionProperty	CSS Transitions	1	1	0
webkitTransitionTimingFunction	CSS Transitions	1	1	0
webkitWritingMode	CSS Writing Modes	1	1	0
onwebkitfullscreenchange	FullScreen	1	0	0
onwebkitfullscreenerror	FullScreen	1	0	0
webkitCancelFullScreen	FullScreen	1	1	0
webkitCurrentFullScreenElement	FullScreen	1	1	0
webkitDisplayingFullscreen	FullScreen	0	1	0
webkitEnterFullScreen	FullScreen	1	1	0
webkitEnterFullscreen	FullScreen	1	1	0
webkitExitFullScreen	FullScreen	1	1	0
webkitExitFullscreen	FullScreen	1	1	0
webkitFullscreenElement	FullScreen	1	1	0
webkitFullscreenEnabled	FullScreen	1	1	0
webkitIsFullScreen	FullScreen	1	1	0
webkitRequestFullScreen	FullScreen	1	1	0
webkitRequestFullscreen	FullScreen	1	1	0
webkitSupportsFullscreen	FullScreen	0	1	0
webkitTapHighlightColor	Mobile Extensions	1	0	0
webkitTextSizeAdjust	Mobile Extensions	0	0	1
webkitMatchesSelector	Selectors API	1	1	0
webkitUserSelect	Text Selection	1	1	0