How to get browser developer participation in this initiative

[prushforth]

We are on our second full iteration of (something like) this process, give or take the WHATWG involvement. It may be worthwhile adding them to this pass.

Another idea that has come up in the recent discussions about process is an early TAG review. Maybe we should include that in our current efforts.

Maybe we should pay them to contribute, that might be the shortest path to success.

[AmeliaBR]

I definitely think a TAG review makes sense at some point. I'm still working on my own review of the current draft specs, so I wouldn't want to ask for external opinions until after I've presented that to the group. But certainly, when this requirements doc is mostly complete, that would be a good point to ask if there's anything we've missed or misinterpreted. (Another reason to try to get this done before TPAC!)

Regarding the WHATWG “How to propose a new feature” link, I think that does nicely summarize what I've been trying to do with this project — including the fact that I'm intentionally avoiding talking about MapML and the HTML map element spec proposal in this document (“Solution time is later!") and instead focus on the problems to be solved (use cases) and evidence of existing solutions.

We could follow step (3) in that list: “Get more people involved. Open a new issue in whatwg/html on GitHub that describes the use cases and their requirements.” Of course, given the scope of this project, we wouldn't be putting all the information into one issue thread, but it could be a cross-reference to this repo & we could periodically post updates. What do you think?

The sticking point still remains step (7): “Get multi-implementer interest in the solution. This means a commitment from two or more browser engines to implement and ship your feature.” But working on higher visibility and involvement will helpfully make that more likely.

As for paying professional browser devs from an independent agency like Igalia: that's wonderful if you can find the funding, but we still need a spec with wide support that will be accepted when we file an intent to implement (Chromium) or otherwise convince the relevant product owners who will be reviewing & merging the code.

[prushforth]

I definitely think a TAG review makes sense at some point.

I emailed the TAG list to let them know we would be filing your work for 'early' review before TPAC. I also asked one or more of them to join our face to face at TPAC.

I'm intentionally avoiding talking about MapML and the HTML map element spec proposal in this document (“Solution time is later!")

I support that approach, and we have as mentioned gone through a full iteration of this process with the involvement of the geospatial standards community to arrive at what we feel addresses our needs, give or take, and we have tried to hew as close to Web architecture, principles and standards culture {HTML) as our group was able. We welcome a collaborative approach at solution time, and we hope that what we have delivered so far measures up. On the other hand, if there are more fit solutions, let's have them and work on them together with the Web community, despite that they are slow getting to the table. Maybe they didn't realize how important maps in fact are!

As for paying professional browser devs from an independent agency like Igalia: that's wonderful if you can find the funding, but we still need a spec with wide support

Maybe I'm being a bit cocky here and getting ahead of the game. But implementer interest will certainly make funder interest a more real possibility/deliverable.

[prushforth]

What do you think?

Worth a shot, as long as we don't bury them in notifications, as you say.

[prushforth]

'Been thinking on this a bit. Last year at TPAC, received indirect word from people connected to Chrome that developing custom elements was The Way to go. The TAG has provided some advice on this topic, so we can and will follow that.

But it occurs to me that asking communities such as ours to develop custom elements and then waiting to see what is popular, and THEN implementing that is not really in line with reality.

There is no way to take one of the example mapping libraries and build it into browsers. These libraries were developed in response to lack of support by browsers for maps. They codify this lack of support in ways that are similar to using HTML tables for layout. They work, but its not ideal. All of them have gained a lot of traction, some more than others. But they are implemented by authors far and wide, illustrating just the kind of crawl footprint that browser architects are asking us to demonstrate, except now by competing at the same level for authors.

Let's say we do just that: develop a solution and market it far and wide, successfully competing with entrenched competitors like Google and Apple maps (I know, right). Anyway, let's just say we do.

At that point, we're supposed to say to browser community, "Hey look at this fully formed network of maps, its so successful, you should add it to the Web Platform."

But what happened was, although we had asked for their participation in design before building this successful network, they declined saying it wasn't a priority because there were no prior uses of the proposed technology. And while they might not agree with the design choices made by the community, the network is so big now, there's no chance of changing it.

So I think its more than just an opportunity for browsers to advise us, its a chance to make some decisions about the design of a future feature without having it forced on you by circumstances.

Does this resonate at all? I am thinking of discussions at TPAC 2019...

[Malvoz]

We could follow step (3) in that list: “Get more people involved. Open a new issue in whatwg/html on GitHub that describes the use cases and their requirements.”

Out of curiosity, would you rather open a whatwg issue before or after TPAC? I can imagine it depends on the state of the use cases and requirements spec.

[prushforth]

would you rather open a whatwg issue before or after TPAC?

I would like to request an 'early TAG review' once Amelia's document is ready, hopefully, but not necessarily before TPAC. Once we hear back from the TAG, I believe we'll have a better idea of next steps, but as I understand it we will eventually have to establish an issue with WHATWG. I had personally hoped for participation from browser teams before getting to that point, as I would like us to base our issue around some technical solution consensus, and we're not quite there yet.

[AmeliaBR]

Yes, I was suggesting to hold off on asking for a review until the Use Cases report was complete (full draft, not necessarily final publication).

And yes, the main reason I wanted to focus so much on existing implementations in this report was for just the reasons Peter mentioned — to demonstrate there is already widespread JS-based adoption of these core capabilities, even if the existing tools don't use a web component design.

In addition to presenting the project at TPAC, I do think there is a discussion worth having about what are the best routes to proposing new HTML features. There was certainly a lot of reaction to the <std-toast> proposal with general agreement from folks outside of Google that that wasn't the best way to standardize a new feature.

If you're able to put together a short summary of the process obstacles you've encountered, Peter, that might fit in well with a plenary-day discussion on web components and paving cowpaths and so on. Next step would be to reach out to people who'd be likely to lead that discussion, let them know you'd be available to be a case study of sorts.