bkardell

Input Modality - :focus'ing on users

Throughout the history of Web development, we're always trying to find ways to make the user experience better while maintaining a 'works for everyone' approach. CSS had media queries which allowed us to express that this stylesheet was for print, while that one was for screen. Later, we found that we could do a lot better in servicing the user if only we could know something about that screen and thus the responsive design movement was born. Now, we find ourselves in a similar place - different user agents support different means for interacting with elements and each has potentially different implications.

Consider the humble focus ring - you see it when you are filling out a form with text boxes. It's an important visual indicator because you're about to type and you want to know where those characters are about to land. This is true regarless of the device that you are using because the only way to interact with that element is to type some text. But now

bkardell

I've pieced together the below history of W3C TAG membership from various searches. It has holes, and it doesn't tell us who was nominated either. I'd love to capture this data somewhere for posterity, really for no other reason than that I love history. If you are able to help me fill this in and where you got that information from, it would be really awesome.

---

2014

• Domenic Denicola (Lab49)
• David Herman (Mozilla Foundation)
• Daniel Appelquist (Telefónica; co-Chair)
• Yehuda Katz (JQuery Foundation)
• Sergey Konstantinov (Yandex)

bkardell

<!--
Gist for discussing https://twitter.com/ryosukeniwa/status/547131291527704576 thread in a better format...

My perspective:
Shadow root can be created on any element, regardless of whether it is a custom element... 
This creates a piercable membrane which allows the CSS for the page to not worry about the stuff inside the shadow root, until it wants to.
This allows the stuff inside to work within the page and let certain safe things through, when it wants to.
Style element can use @import to share stylesheet information across many instances.
The design allows numerous means of possible 'import' optimizations, but locks you into none (in theory)
This allows DOM inside and outside the shadow root to answer selector matching the same way as CSS.

bkardell

require(["foo"], function (foo) {
    try {
      foo.bar(); // foo does nothing with z below, or x
    } catch (e) {
      debugger; // sometimes I hit this and it reports z undefined?
      console.error("wtf", e);
    }
});

function x () {

domenic

ARIA + Custom Elements Solution Scratchwork

Note: I don't like these ideas very much. I might be able to make them less gross with some work, and that's what I'll end up doing if nobody comes up with a different approach. But I did want to throw them up here, in their current gross form, so that people could see where I was heading.

Proposed Solution

The basic idea is that when registering a custom element, you are optionally given the ability to manage its true ARIA roles and stoperties. This would probably be done via something similar to the revealing constructor pattern given to its createdCallback. You would then opt-in to manually managing your ARIA roles and stoperties yourself.

Concretely, the registration would take as an arugment a customAria boolean property. If it is truthy, the createdCallback would be supplied with an ariaSetter function, which you could invoke like ariaSetter("role", "separator") or `ariaSett

annevk

Not really in any particular order. Some are more logical than others.

• TextDecoder / TextEncoder
• URL
• fetch() (unclear yet how we are going to namespace this, CORS behavior also does not make much sense outside browser context)
• Worker / SharedWorker (and all the port business, structured cloning is on its way already; would require events to be ported too)
• window.btoa() / window.atob()
• window.setTimeout(), …
• ImageBitmap
• EventSource

bkardell

Topic:

CDNs and other optimization techniques. This comes up a lot, it crosses numerous mailing lists and twitter. If you have thoughts on this, let's discuss and we can easily cite/refernce in the future....

Here is a statement from @scott_gonzales on twitter, and some thoughts from me to open the discussion

Scott: CDNs have much higher cache-miss rates than you'd think, and JS should be concatenated and deployed from the server

Me: It's true cache-misses are higher, but I don't want to throw the baby out with the bathwater. The advantages of concat will largely disappear with HTTP2. CDNs have a number of things (some in theory and some in practice) which seem good. At an incredibly utilitarian level, if I can offload that from my own infrastructure and maybe reduce hops for this requests too - seems good. At a more conceptual level, the idea that some resources are highly shareble and deserve a special home/cache seems good even if CDNs don't currently fully enable that - seems maybe not so much a