Meeting minutes
<una> https://
una: first topic, issue #184. Naming conventions for proposed elements.
una: idea is getting agreement on how we propose new element names. Right now there's input type="file", talk about openu- prefix, but when they get into the *browser*...what does that naming look like?
una: is in input- ? oui-? just "File" as the name?
una: some concerns brought up, dashes could connote Web Components. Could be a problem if we're really trying to create native components. There was also wicg- as a proposal. Convo is: to dash or not to dash? And what should prefix look like?
<jan> Eric can go ahead first
Eric: I see the dash as a really nice namespacing affordance, and I see the concerns around is this a WC or not. But on the other hand, it speaks to what we're trying to do, a browser capability with extensibility. So that's kind of like WC, don't see it as a barrier to adoption
jan: sounds like two convos. What should we call prototype components, and what would we propose as names for standard components? For the second, I don't think hyphen is an option. Hyphens were to create an obvious distinction between browser components and user-land components. Anything with a hyphen will break someone. That's why the distinction is there. Convo in v1 spec, platform didn't want to be in position of not being able
to intro components because someone out there had already used the name. No hyphens: browser, hyphens: to the user.
+1 from me on preserving that separation
(me = melanierichards)
una: I agree, it doesn't make sense to keep the hyphen. Breaks the pattern of why hyphens exist in WC.
Nicole Sullivan: what do you do for polyfil when there's not support for native component?
una: oui- version with polyfil, idea is that oui- gets dropped with native version, ideally the names are the same
Nicole: feel like there could be gotchas
una: ...you can still have a component called block quote and it won't conflict with HTML block quote, because it's a different thing. Gotchas, probably going to be generic nature of the naming. But IDK if will really be a problem
Nicole: imagine FF supports a select element first, and it takes Cr longer. Web dev needs to have things work in both cases...also FWIW I agree w/ no dashes...I'm just trying to figure out what web devs do when supported natively in one browser and not another
boazsender: want clarity on plan for landing these in browsers. Input type has a generic way of doing this. How is this file element we're speccing going to interact with input type="file"? That would help me understand intent and goals
una: to give context, went back and forth about extending existing components. Can we use pseudo els? Result was, that was not enough, existing are blocked in a very specific way and aren't really extensible. So to not be boxed in so to speak, have to create new elements. Select dropdown is a great example, can't break what's there but need to extend
boazsender: so Open UI are going to be a whole new set of components that I'll import along with HTML elements?
una: well hopefully implemented natively. Using the platform of WC to make sure that these controls are extensible and styleable. Cowpath to standards process.
boazsender: once standardized, they live alongside existing form controls in browsers?
boazsender: and we don't think there's a web compat way in 15 years to have these things be de-duped
Nicole: in 15 years hopefully won't be an issue, browsers will support. Once you have cross-browser support, only need to polyfil for browsers that aren't actively supported anymore...well now I'm talking myself out of it
boazsender: it would be nice if we could ship the new behavior of file as input type file, but we can't because there's behaviors that depend on what's existing
Nicole: a lot of what breaks, looking at lots of sites, there's a lot of sites using styles on existing components that can't possibly work. They would've had to zero out the styles for it ever to work. So a lot of styling doing nothing at all. So if we made these changes, that would turn on a lot of CSS that currently has no effect. And it's not a small part of the web. It's frustrating, because I think most people want to make
what's there better
boazsender: have there been discussions around different "modes"?
una: yeah, it creates more issues I think. You're styling for a mode instead of just using an element or not. So that creates complexity and fragments the web
Nicole: kind of already exists...property to apply that makes a lot of styles work. Not all, some. But the trouble is people haven't used that but have used styles.
<boazsender> thanks ya'll for rehashing this with me, helps me understand the context behind the naming requirements
Eric: ghost of IE compat flags...the idea of components that have required child components. So we're adopting a select option model where child elements can't be presented outside context of their parent, but have no explicit association other than the docs
una: I don't think necessarily children in a parent, not everything has children (color input, calendars, etc)
Eric: I'm just thinking tab, tabpanel territory
una: that would have structure but across the board I don't think parent/child always required
una: can we resolve on naming? Are we ready to do that?
jan: responding to Nicole's Q. I'm taking that to say, let's say we have oui-superselect. At the point of intro to platform, we're just going to call it superselect and remove oui-. At that point it can't be polyfilled with custom element because it doesn't have the hyphen. How is someone going to polyfil when only some browsers have supported? There's a couple degrees of freedom. The custom elements API is not the only way to
polyfil. Polyfil that does querySelectorAll, looks for elements "unknown" to the browser. You could have code that finds instances of superselect and does something with them, maybe convert to oui-superselect. So there are other techniques other than custom els API. Important that people not try and polyfil standard els until they're shipping in browsers. oui- is great for polyfilling because no chance of conflict. Where people get
in trouble is speculating how the browsers will implement the standard and now it's different from the polyfil. And now browsers wonder what to do about rolling about because might break people.
jan: so a lot to be worked out w/ polyfil strategy. These convos are more productive when we have a specific decision we're facing. We're ready to try and move superselect into the platform...then we can work out the polyfil strategy.
una: yeah, good point. If 5 years still using oui- version, maybe polyfil can convert it into the version browser using. To that point, I think we really need the naming conventions. Sounds like we're circling around oui- for custom, and then dropping oui- for the native component.
jan: personally I prefer "openui-", so that people know what to search for. If they search for "oui", who knows what they'll get
brodymckee: I agree
una: no strong opinions, but conventionally I want them to be shorter. In work in previous orgs, they're shorted as a convention
jan: in an org, they know where it came from. I'm concerned about coming across on large scale
una: what do you think of "wicg-"?
jan: if they google for it, do they get to the same spot?
una: Open UI within WICG
jan: I don't think WICG is as self-evident
jan: openui is more self explanatory, they know what to look for
<gregwhitworth> we technically already resolved on oui
<gregwhitworth> but can unresolve
<gregwhitworth> sorry, jumping between meeting calls here :/
boazsender: do we think we need to know how we're going to eventually standardize the elements? What input have we gotten from web standards community and do we feel like there's more convo we want to have there?
boazsender: so Q about sequencing and input-gathering
una: I do want to talk about this now because PRs coming in with different naming conventions
una: we don't have to necessarily resolve on something, we can just resolve on dash to unblock PRs
boazsender: yeah maybe resolution could be naming convention on prototypes, and directional, here's what we're thinking about now and we'll get feedback down the line. Working on process for this group right now
<una> melanierichards: I understand wanting to bake context into prefix, but I don't think people will be lost with `oui`, then people will search the component name and find the docs
<una> melanierichards: I don't think we need to overindex on the prefix name
brodymckee: I'm the kind of dev that names button over btn, prefer verbosity and it gets compiles at EOD. So I do prefer more before verbose w/ context. But I also see the point about it being ok to search for full component name. Less sold on "WICG".
Nicole: I think oui- would work better if it weren't a word in French. Harder to Google. "Open" is a pretty short word, I would have a tendency towards openui-
una: yeah, internationalization changes context
<boazsender> +1 to openui-
una: so while I was leaning oui-, openui- is just 3 more letters so not much more to type
una: are we ready to try and resolve?
<una> Proposed Resolution: use `openui-` naming for prototyping and web components, and the file name after the prefix alone for native implementation of the components
<una> i.e. `<openui-superselect>` and `<superselect>`
Resolution: use `openui-` naming for prototyping and web components, and the file name after the prefix alone for native implementation of the components
<una> https://
una: next one is issue #198
Nicole: to some degree we have been talking about this, didn't name it well, was really trying to say, how are people going to use this, how is it going to be accessible in both browser and fallback version. How is usable regardless of JS paradigm people use? Examples I included, how do we make it so that we can use descriptive element names in the browser but still have a way of falling back to something that will work when older
browsers see the same code? In particular, accessibility is what I highlighted. Want to make sure screen readers running into stuff can make sense of it. Tabs are a list, how do we at least make sure older browsers are getting list semantics?
una: do you feel there's a part of that we haven't covered in our convo today about usage and future usage?
Nicole: I do think there's a partial support case is a thing we know we need to think about, I'm not sure we got to an answer on how to deal with it. But I'm ok with us taking it away and spending more time with it offline.
una: I think we can continue this thread, Jan had a really thoughtful response to what polyfilling could look like as things roll out across browsers. I'm curious if there will be any issues. I think that will be issues if oui- doesn't perfectly match what the browser is doing. So maybe some unknowns
Nicole: agree, and agree with whoever said it'll be easier when we have a working example to play with
una: great, important thing to consider throughout this process
una: any other topics?
[none]
una: please chat on the Discord group, open issues, label them agenda+. Thanks all for joining!