Which led to:
This is adapted from the record taken at the time by Chaals and Rowanis= syntax isn’t lovely, but we’re still waiting for a viable alternative to be offered. These were pasted into a chat channel, but nobody much was watching it:
Léonie Watson, Chaals McCathie Nevile, Steve Faulkner, Alice Boxhall, Ben Scott, Paul Lloyd, Orde Saunders, Adam, Rowan, Katie, Ada Rose, Hidde, Rodney Rehm, Peter, James, Peter Greston
LJW: There are 4 specs, accessibility has focused around custom elements and a bit on Shadow DOM. There are some good things - we
will be able to prototype new elements e.g. panels /
panelsets, and we can road-test that for accessibility with web components ...If you make custom element there’s nothing about
it that the browser knows. There is a conversation about type extensions, extending the functionality of an existing element, with <button
is=”my-button”> that feature is at risk, some people hate it. I’d like to come out with a sense of how serious these
problems are in the real world. There is also a meeting on WC.
Peter: I like is= on the surface. It works really nicely for a button, but extending an iframe or something isn’t
always helpful
Alice: Why would you do that?
Peter: Because there are use cases for this.
Alice: Button is what we see. What are the use cases? Rodney: Tried extending fieldset. Was hoping to inherit state
management, to save me the work, but I couldn’t make it work.
Orde: Don’t Repeat Yourself. Dev should be able to just inherit the work done.
Ben: Unconvinced by the complex use cases…
Peter: There is a limited set of cases. Are the use cases so limiting that they force a way of doing stuff?
SF: Use case sounds like the usage would be limited. There are some common extensions that will be used all over the place.
Peter: Sure. I see the use case conversation as broader than we see it.
LJW: What are the cases where it works.
Chaals: would be really useful to try and find the combinations where it works and where it doesn’t, and to document and share those. There’s a lot assumptions that when elements are extended their behaviour is extended, but the observed results may not match the expected results (especially as the current behaviour is not documented)
Orde: Maybe there are a subset of things that is= can extend, and be documented.
Steve: It is useful to look at what is= gives you in browser X. Which today is {Chrome}.
Alice: only looked at buttons. Adding in shadow root, you lose the keyboard handling. Not sure if it is an implementation bug or spec issue.
Rodney: is= should let you upgrade the element, using the fallback as default. Other way around, there isn’t an upgrade path. If you wanted to do that, when registering the component, use the prototype of the thing you are extending as a base, e.g. to inherit disabled standing.
Peter: Components aren’t in broad use, and we don’t have a lot of use cases. I can think of the github extension of time element, but not much in that one. We need to see more things in productive use to see how it goes
Alice: There is a distinction to make between landmarks and interactive things. If it started to do more, that could be useful. For interactive elements, messing with the shadow root gets messy. Another one for me is dialog - again only works in Chrome. What if there is a polyfill for dialogs?
Steve: time element is interesting. Non-interactive elements that you can extend is good because you get the meaning without a role attribute. Time doesn’t do a lot, but times and dates in screen readers can be a real pain. Conveying the semantics is actually useful, even without interaction.
Peter: There is the argument that we can get components faster by extending existing things. Github said they would not use the component without the is= syntax.
Chaals: Lots of dislike of the is= syntax, but do we know why? It’s uncontroversial that we want an improvement, but do
we know what we want?
LJW: Having the syntax back-to-front is never going to make people love it.
AB: don’t care either way but don’t see anything better. If you have it as <my-butt is=”button”> it fails
backwards compatibility.
Rodney: does a single element suffice as a fallback. canvas, video, etc use their children.
AB: That’s extra work to do the same thing
Ben: How do you know if the thing is content or fallback?
Chaals: If there was a proposal for a better solution, would anyone still want the is= syntax? For example, would
GitHub be happy to use a better replacement for the time custom element?
AGREEMENT: We’re not concerned about this syntax, we just want the functionality.
SF: There isn’t an alternative proposed that will be implemented in the short or medium term. The superbrains say having is= won’t work, they say they want the functionality but don’t seem to be in a hurry to get there.
Peter: Domenic Denicola is trying to rebuild HTML in web components to see what has to be done for equivalent functionality.
SF: Doesn’t seem like it’s on the priority list. It seems that type extension itself is opposed.
Léonie: Have there been any suggestions on how to improve on the current situation?
Alice: You include a button inside the shadow DOM if you want to extend a button.
LJW: Elements are not implemented the same always
Orde: That’s where I was coming from with a set of elements that is= can work for…
Chaals: Which is currently HTML, SVG, and MathML, because we’ve sort of figured out how to make that work - but inconsistencies
Alice:Anne van Kesteren seems interested in doing it in script. But can’t be done in Firefox’ current rendering engine, so it is a
long-term idea at best. Another alternative is <button extended-by="fancy-button">
Peter: That doesn’t bring a lot more than extra letters in tags
LJW: Potential for confusion but doesn’t really change anything.
Alice: I liked is= for reading. It makes some kind of sense (and is reassuring that it is a button element)
James: Since the attribute is on any DOM element, when you extend a class you have that class. With this syntax, I am confused about how a link is extended. Is it worth limiting which elements can be extended?
Alice: That happens at creation, saying in the prototype what it extends. Don’t think I can use a button as a link. And you have to say multiple times what extends what.
Peter: nobody really likes it, but nobody can suggest anything better. The question then becomes about whether we accept the current situation as workable or whether we want to wait until a better solution comes along. Google is taking the pragmatic solution, everyone else is holding on; if Google ships it we’ll see what breaks.
Ben: The web is good at bikeshedding. Nothing would be done if we waited to get it right
LJW: There are other use cases like forms and templates
Alice: In the polymer team they use <form is="paper-form">, and do template stuff.
SF: What are the counter arguments?
CMN: Developer ergonomics…
PG: I think is= is the best we have now.
SF: What happens if we don’t get the syntax.
CMN: If we had the information about what happens and what existing elements do, we could probably polyfill.
Alice: If we had that we’d be sweet. If we find that another capability is required on something down the track, we can just add that into an element.
SF: Assuming this is going to be an interop problem for a while, where does that leave accessibility of components?
PG: On our shoulders
SF: So you have to do all the interaction, aria, and stuff
Orde: And launch 1000 "Web Components considered harmful" threads.
Hidde: If that happens you fall back to a button
SF: A lot of components actually seem to be about stylability - enabling people to style things more easily.
Orde: Why can’t you style native widgets better?
PG: The browser has to expose the things to you, e.g. through pseudo-classes. Safari, Chrome do a bunch, Mozilla a bit, I think MS Edge nothing at all.
SF: Interactive controls differ across browsers. Some use a platform button, so there aren’t internals that can be got at for styling. Was thinking about setting control area as a blank canvas and letting the developer style it up. That can work on some inputs, but not all…
LJW: Potential problem is that it is mired in browser refusal to implement, like is=
Chaals: It’s not trivial to get browser vendors to agree what to expose; typically security people disagreeing so that you can’t make buttons look like other things. Standard wonks sit down and break down elements into pseudo-classes and work out what to expose; we should stop using simpler elements like button and use examples like date-picker instead. If you use a popup on some platforms and spinning wheels on others, what should get styled? Should you be able to affect the interaction behaviour as well as the appearance? Those are the cases we probably need to write some prototypes and distil what we wanted it to do. The hard experiments are the ones we need to think about what we could do.
Hidde: it is a feature not bug that date pickers can be made looking very differently, so it is hard to imagine them all, and how to style them
SF: On the phone it looks cool but on desktop it is crap
Hidde: Can we get nicer datepickers and then we’re done?
Alice: Styling isn’t the right solution for something like that. What if you can select the pieces of it that are available.
Hidde: The browser knows where it is… we have convinced clients not to worry so much what inputs look like. And components will change that.
Rod: so if you extend a date input with the is=, what happens?
Alice: So a browser can say “no, you’re not replacing the element you wanted to”
Chaals: So the use case for this is assistive technologies not meshing nicely with terrible custom implementations, and so instead opting to show the accessible native elements - a personal blacklist for usability.
Ben: Are users going to care about this level of configurability?
Chaals: The users who really need it for accessibility really will, the rest won’t.
James: Are there multiple layers - datepickers differ on mobile/desktop. Can it adapt more to user’s goals? E.g. can I make a responsive decision on what component I have? Or multiple versions of components to show for different needs?
Peter: What do we do if people want to build a custom element from the ground up. Go read the Web Components Gold Standard? (Jan Miksovsky) It is interesting that accessibility isn’t an aim, it is a result of building a well-considered component.
LJW: Yes.