search

Maps4HTML / MapML-Specification

Map Markup Language is hypertext for Web maps, like HTML is hypertext for Web pages https://maps4html.org/MapML-Specification/spec/
Other
55 stars 12 forks source link

Naming convention for proposed elements #151

Closed Malvoz closed 2 years ago

Malvoz commented 3 years ago

We can probably learn from/align with https://github.com/WICG/open-ui/issues/184 about (re-)naming elements.

That issue is kind of hinting at not creating new (e.g.) <input type="zoom"> elements but instead (perhaps) <inputzoom>. On that note, I know that people in the workshop reacted specifically to MapML's use of input, so did @zcorpan in https://github.com/Maps4HTML/MapML/issues/70:

◦ input: this doesn't seem to be a widget that expects user input; suggest minting a new element name.

If anyone has feedback/thoughts on improving element names I suppose we can discuss that here (and let https://github.com/Maps4HTML/MapML/issues/70 focus on its initial issue of making MapML an extension to HTML).

Edit: also https://w3ctag.github.io/design-principles/#name-thoughtfully

prushforth commented 3 years ago

I don't mind inputs, personally, and I would like to see what others in the HTML design community have to say about the issue. I prefer to follow existing design patterns, such as that defined by input for user variables (the user does generate the events that give rise to the value, so there's a discussion to be had about that).

By the time this gets actioned, there well may be new existing design patterns that have been implemented that don't follow input type="foo", so I would go along with that crowd, if that discussion does uncover a pattern that is acceptable to the HTML design community, we should be willing to consider it for sure as it makes one less aspect to have to 'sell'.

That said, and not directly linked to this issue, I think that we should consider trying to eliminate <input type="zoom"> and replace it with <input type="location" axis="zoom">, leveraging the fact that location representations are zoom-specific, or at least sensitive, and thus by integrating "zoom" as an 'axis' of the TCRS concept, we could eliminate a request to code up yet another input type.

Eventually I hope to introduce an actual map-based <form> with <input type="location" ...tbd...> that will request user input via input device(s) to trace points lines and polygons as required. So that's one reason to stick with <input type="location">, and a reason to tag <input type="location" axis="zoom"> onto the proposal -> reduce the code footprint (perhaps).