18:47:10 <RRSAgent> RRSAgent has joined #openui
18:47:10 <RRSAgent> logging to https://www.w3.org/2021/01/07-openui-irc
18:47:18 <gregwhitworth> Zakim, start the meeting
18:47:18 <Zakim> RRSAgent, make logs Public
18:47:20 <Zakim> please title this meeting ("meeting: ..."), gregwhitworth
18:47:29 <gregwhitworth> meeting: Open UI Telecon
18:47:39 <gregwhitworth> chair: Una Kravets
18:50:19 <Eric> Eric has joined #openui
18:58:38 <una> una has joined #openui
18:59:42 <una> present+
19:01:41 <melanierichards> present+
19:01:51 <brodymckee> brodymckee has joined #openui
19:02:18 <andre_wiggins> andre_wiggins has joined #openui
19:02:31 <una> https://github.com/WICG/open-ui/blob/master/meetings/telecon/2021-01-07.md
19:04:26 <jan> jan has joined #openui
19:04:41 <boazsender> boazsender has joined #openui
19:04:44 <melanierichards> scribenick: melanierichards
19:04:49 <boazsender> present+
19:05:01 <melanierichards> una: first topic, issue #184. Naming conventions for proposed elements.
19:05:41 <melanierichards> 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?
19:05:55 <melanierichards> una: is in input- ? oui-? just "File" as the name?
19:06:40 <jan> q+
19:06:40 <melanierichards> 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?
19:06:54 <jan> Eric can go ahead first
19:07:41 <boazsender> q+
19:07:48 <melanierichards> 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
19:08:09 <boazsender> q-
19:09:15 <Francis_Storr> Francis_Storr has joined #openui
19:09:18 <melanierichards> 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
19:09:18 <melanierichards> to intro components because someone out there had already used the name. No hyphens: browser, hyphens: to the user.
19:09:45 <melanierichards> +1 from me on preserving that separation
19:09:54 <melanierichards> (me = melanierichards)
19:10:15 <melanierichards> una: I agree, it doesn't make sense to keep the hyphen. Breaks the pattern of why hyphens exist in WC.
19:10:42 <melanierichards> Nicole Sullivan: what do you do for polyfil when there's not support for native component?
19:11:21 <melanierichards> una: oui- version with polyfil, idea is that oui- gets dropped with native version, ideally the names are the same
19:11:33 <melanierichards> Nicole: feel like there could be gotchas
19:11:35 <boazsender> q+
19:11:49 <Eric> q+
19:12:11 <melanierichards> 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
19:12:43 <jan> q+
19:12:52 <melanierichards> 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
19:13:41 <melanierichards> 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
19:14:39 <melanierichards> 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
19:14:59 <melanierichards> boazsender: so Open UI are going to be a whole new set of components that I'll import along with HTML elements?
19:15:26 <melanierichards> una: well hopefully implemented natively. Using the platform of WC to make sure that these controls are extensible and styleable. Cowpath to standards process.
19:15:39 <melanierichards> boazsender: once standardized, they live alongside existing form controls in browsers?
19:15:53 <melanierichards> boazsender: and we don't think there's a web compat way in 15 years to have these things be  de-duped
19:16:30 <melanierichards> 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
19:16:43 <una> q- jan
19:16:53 <una> q- boazsender
19:17:08 <melanierichards> 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
19:18:17 <melanierichards> 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
19:18:17 <melanierichards> what's there better
19:18:31 <melanierichards> boazsender: have there been discussions around different "modes"?
19:18:52 <melanierichards> 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
19:19:25 <melanierichards> 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.
19:20:08 <boazsender> thanks ya'll for rehashing this with me, helps me understand the context behind the naming requirements
19:20:24 <melanierichards> 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
19:20:43 <melanierichards> una: I don't think necessarily children in a parent, not everything has children (color input, calendars, etc)
19:20:52 <melanierichards> Eric: I'm just thinking tab, tabpanel territory
19:21:07 <melanierichards> una: that would have structure but across the board I don't think parent/child always required
19:21:24 <melanierichards> una: can we resolve on naming? Are we ready to do that?
19:21:26 <boazsender> q+
19:21:32 <boazsender> q?
19:21:42 <Eric> q-
19:24:46 <melanierichards> 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
19:24:46 <melanierichards> 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
19:24:46 <melanierichards> 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.
19:25:21 <melanierichards> 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.
19:26:14 <melanierichards> 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.
19:26:40 <melanierichards> jan: personally I prefer "openui-", so that people know what to search for. If they search for "oui", who knows what they'll get
19:26:44 <melanierichards> brodymckee: I agree
19:27:20 <melanierichards> una: no strong opinions, but conventionally I want them to be shorter. In work in previous orgs, they're shorted as a convention
19:27:33 <melanierichards> jan: in an org, they know where it came from. I'm concerned about coming across on large scale
19:27:34 <melanierichards> q+
19:27:47 <melanierichards> una: what do you think of "wicg-"?
19:27:57 <melanierichards> jan: if they google for it, do they get to the same spot?
19:28:25 <melanierichards> una: Open UI within WICG
19:28:34 <melanierichards> jan: I don't think WICG is as self-evident
19:28:51 <melanierichards> jan: openui is more self explanatory, they know what to look for
19:29:22 <gregwhitworth> we technically already resolved on oui
19:29:27 <gregwhitworth> but can unresolve
19:29:34 <gregwhitworth> sorry, jumping between meeting calls here :/
19:29:38 <melanierichards> 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?
19:29:52 <melanierichards> boazsender: so Q about sequencing and input-gathering
19:30:03 <melanierichards> una: I do want to talk about this now because PRs coming in with different naming conventions
19:30:12 <brodymckee> q+
19:30:24 <melanierichards> una: we don't have to necessarily resolve on something, we can just resolve on dash to unblock PRs
19:30:58 <melanierichards> 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
19:31:21 <boazsender> q?
19:31:26 <boazsender> ack boazsender
19:31:43 <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
19:31:56 <una> melanierichards: I don't think we need to overindex on the prefix name
19:33:02 <melanierichards> 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".
19:33:49 <melanierichards> 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-
19:33:59 <melanierichards> una: yeah, internationalization changes context
19:34:13 <boazsender> +1 to openui-
19:34:21 <melanierichards> una: so while I was leaning oui-, openui- is just 3 more letters so not much more to type
19:34:46 <melanierichards> una: are we ready to try and resolve?
19:35:10 <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
19:35:41 <una> i.e. `<openui-superselect>` and `<superselect>`
19:36:14 <una> Resolved: use `openui-` naming for prototyping and web components, and the file name after the prefix alone for native implementation of the components
19:36:40 <una> https://github.com/WICG/open-ui/issues/198
19:36:41 <melanierichards> una: next one is issue #198
19:38:01 <boazsender> q?
19:38:30 <una> q- melanierichards
19:38:46 <una> q- brodymckee
19:38:49 <melanierichards> 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
19:38:49 <melanierichards> 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?
19:39:04 <melanierichards> una: do you feel there's a part of that we haven't covered in our convo today about usage and future usage?
19:39:31 <boazsender> q+
19:39:34 <Eric> q+
19:39:38 <melanierichards> 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.
19:40:45 <melanierichards> 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
19:41:02 <melanierichards> Nicole: agree, and agree with whoever said it'll be easier when we have a working example to play with
19:41:10 <Eric> q-
19:41:15 <boazsender> q-
19:41:16 <melanierichards> una: great, important thing to consider throughout this process
19:41:21 <melanierichards> una: any other topics?
19:41:29 <Francis_Storr> present+
19:41:38 <melanierichards> [none]
19:41:56 <melanierichards> una: please chat on the Discord group, open issues, label them agenda+. Thanks all for joining!
19:42:43 <melanierichards> rrsagent, make minutes
19:42:43 <RRSAgent> I have made the request to generate https://www.w3.org/2021/01/07-openui-minutes.html melanierichards
19:42:56 <melanierichards> zakim, please part
19:42:56 <Zakim> leaving.  As of this point the attendees have been una, melanierichards, boazsender, Francis_Storr
19:42:56 <Zakim> Zakim has left #openui
21:10:57 <innovati> innovati has joined #openui