Read on Twitter
The fact that web spec standards language and the language designers use to describe things on the web have almost no words in common is A Problem.
The web platform does not in fact support modern design, it just happens to be a set of primitives you can coerce into that shape.
Progressive Enhancement is now dead. This makes me super sad, but to be honest? The web platform needs to change to make it possible.
I think the dream died with <datalist>.
I think the dream died with <datalist>.
The form data model — ordered list of name-value tuples as strings — is insufficient.
The fact that you cannot express interdependent options in forms puts us in a bad position. Not all problems can have their complexity reduced so far.
The fact that you cannot express interdependent options in forms puts us in a bad position. Not all problems can have their complexity reduced so far.
All of the relationships between elements that we are building cannot be expressed easily in CSS, and if they are, accessibility suffers mightily.
Look at the concepts in the WAI-ARIA specs. Look at the concepts in the HTML specs. Which one reflects the actual practices of using user interfaces, with a human at a computer? Hm?
HTML5 forms are such a travesty too. They implement inputs for abstract data types without even a solid theory for what that type is, and without a way to represent them as anything but a string, and not even that most of the time.
They do not implement controls that help users.
They do not implement controls that help users.
Best practice for entering numbers? <input type="text" pattern="^[0-9]+([.][0-9]+)?">
And then add javascript to make the validation messages make sense.
Nobody wants your spinbox <input type="number"> go away.
And then add javascript to make the validation messages make sense.
Nobody wants your spinbox <input type="number"> go away.
It sure would be nice if we could define application level components that express this stuff. And sharable, too. They're common use cases!
But guess what. Custom elements barely work, they need JS to operate at all, they can't draw anything but stock HTML elements without breaking progressive enhancement.
You cannot use the Shadow DOM and progressive enhancement techniques together in any useful way.
You cannot use the Shadow DOM and progressive enhancement techniques together in any useful way.
And interdependence?
Guess what. All the lifecycle callbacks on custom elements are edge-triggered, and in the order their implementations load, NOT document nor dependency order.
Non-trivial interactions between elements are lessons in state management code.
Guess what. All the lifecycle callbacks on custom elements are edge-triggered, and in the order their implementations load, NOT document nor dependency order.
Non-trivial interactions between elements are lessons in state management code.
All of this leaves us in a situation where the only rational decision is client side rendering and MAYBE server side rendering and hydration to start. But 'time to actually functioning interactive' is now super late in the game.
But now basic browser functions like "back" "forward" and "reload" are borken. Nevermind things like "bookmark" and "share URL"
Oh, and scrolling. Scroll position tracking between pages is completely busted now.
Oh, and scrolling. Scroll position tracking between pages is completely busted now.
Navigation spinners, dirty tracking, scrolling, it's all so bad.
The semantic web spent twenty years languishing in pedantry until someone reinvented it and called it jsonld. It's probably too little too late but as web-native data model you could do worse. Attached to forms by default means that in five years the web might not suck.
If anyone wants to tackle the specs for this start doing interviews with designers about time.
How should dates work? Build a calendar system. Go understand the problem domain of inputs with complex needs.
You can't just emit an ISO date and call it solved.
How should dates work? Build a calendar system. Go understand the problem domain of inputs with complex needs.
You can't just emit an ISO date and call it solved.
Talk about incomplete specs. Recurring specs. Indefinite date specs.
"Tuesday" is a valid date. "11am" (any 11am) is a valid time. These are how humans work with things. "Remind me to do this every day at 11am" is in fact REALLY HARD. Go work through it.
"Tuesday" is a valid date. "11am" (any 11am) is a valid time. These are how humans work with things. "Remind me to do this every day at 11am" is in fact REALLY HARD. Go work through it.
People move across timezones. Timezones _themselves get changed_. Some dates refer to precise moments. Future dates in particular often refer to _conceptual_ moments.
"11am" is "two hours after the US workday starts, which is 9am", but if daylight savings gets changed, that moment moves by an hour. It's not a specific moment until it happens or it's getting close. If a user moves to a new city, it changes.
"This value if filled in overrides the base value" is another complex UI problem. Web forms have to solve this if we're going to have progressive enhancement.
The state of the art is a checkbox that uses javascript to enable and disable a field, and the app assembles an overlay.
The state of the art is a checkbox that uses javascript to enable and disable a field, and the app assembles an overlay.
The idea of null vs blank here is in play. An enabled field, but blank overrides a value with nothing. A disabled field does not override the parent value.
This is common — ACLs, product attributes, a thousand complex business domains need this kind of editor.
This is common — ACLs, product attributes, a thousand complex business domains need this kind of editor.
How do you group these things into controls someone can operate by keyboard? By switch? How do you package up all that _stuff_ into something coherent so it's usable by others?
There's no good answer right now. React I guess, hope you like refs a lot.
There's no good answer right now. React I guess, hope you like refs a lot.
So here we are. We're 3/4 of the way to <dialog> and 7/8 of the way to <details> but that's totally enough to make awesome web apps. Uh-huh.
