Brian Kardell bkardell

It's a very common visual strategy to present data to users in label/value pairs. You see information 'cards' like this presented everywhere which present data points like:

Miles Per Gallon: 36 Engine Size: 2.8 liter

In some applications, these values may be editable in certain circumstances and not in others. A ton of work has been done on a11y and interaction concepts around forms, so you might imagine the following as being a valueable way to express things - you potentially gain a lot of subtle value in terms of how users interact with and understand the UI by using some markup like:

<label for="mpg">Miles per Gallon<label> <input id="mpg" readonly>

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

Go to http://todomvc.com/ in IE10 or 11
using f12 tools, add a rule that says :focus { border: 2px solid green; }
using the mouse click on various bits of text/empty space - you will see elements that are not keyboard focusable get the outline
press tab and you will see that that thing really did 'have the focus' (you can also do document.activeElement to verify)

I cannot see why/what circumstances this happens, when it does setting tabindex=-1 doesn't seem to impact.

I'm concerned that these are receiving focus because the focus indicatoractually seems to be "doing the right thing" from an a11y standpoint, so selectively styling it or not doesn't seem right. To me it seems that the real 'problem' is that it got focus in the first place - other browsers don't seem to do this.

When I was about 21 I started painting and for about 5 years I drew and painted daily, even changing majors in college - eventually TA'ing lifedrawing classes and apprenticing for a well-known illustrator. Then the Web happened, and then life happened. The result was that I stopped drawing and painting about 15 years ago. Then, out of the blue, an online friend, Zed Shaw, who had never painted before decided to started painting. This is exactly the sort of thing that Zed does - finds a challenge, throws himself into it and doesn't give up until he's mastered it. You might be familliar with his "The Hard Way" books. We started talking and he challenged me to do some exersizes - 30 minute self portraits. So - with a $10 box of water soluable oils (which I had never tried before) and a couple of brushes that I had found in an old box, I tried one. It wasn't great, but it was kind of fun:

After a couple of days, I realized that I missed it, so

Forget anything you know about Shadow DOM

This is an attempt to re-frame useful parts in a fairly simpler way. Pretty much everything in the browser that deals with DOM (qsa, node operations, CSS selector matching) is built off the simple concept of a node tree[1] which operates, effectively, off of two types ParentNode[2] and ChildNode[3]. It seems then, if we simply had a concept which introduced a new type: ConnectorNode which maintains non-parent/child kind of link between them. It seems that the most useful things in Shadow DOM would come 'for free' as a simple side effect and 'just work' with minimal changes.

You'd just have to add a .connector property on HTMLElement's interface. It would contain a .root property which was a new ParentNode element and the ConnectorNode setter would remove any of it's siblings, leaving them unsettable while .connector had a value. Since neither of these properties is .parent or .children but both have a similar linking relationship, it provides a

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)

	/* https://github.com/alice/modality */
	document.addEventListener("DOMContentLoaded", function() {
	var hadKeyboardEvent = false,
	keyboardModalityWhitelist = [ "input:not([type])",
	"input[type=text]",
	"input[type=number]",
	"input[type=date]",
	"input[type=time]",
	"input[type=datetime]",
	"textarea",

	document.addEventListener("DOMContentLoaded", function () {
	document.body.addEventListener("mousedown", function (evt) {
	if (!evt.target.setSelectionRange \|\| evt.target.role === 'textbox' \|\| evt.target.hasAttribute("disable-point-focus")) {
	evt.target.setAttribute("point-focused", true);
	}
	});
	document.body.addEventListener("blur", function (evt) {
	evt.srcElement.removeAttribute("point-focused");
	}, true);
	});

	HTMLTemplateElement.fromString = function (serialized) {
	var t= document.createElement('template');
	t.innerHTML = serialized;
	return template.content;
	}

Brian Kardell bkardell

Input Modality - :focus'ing on users

Forget anything you know about Shadow DOM

Input Modality - `:focus`'ing on users