Skip to content

Instantly share code, notes, and snippets.

@bkardell
Last active September 8, 2020 15:27
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save bkardell/6cc0ece2be9339c4d775c9314d549f44 to your computer and use it in GitHub Desktop.
Save bkardell/6cc0ece2be9339c4d775c9314d549f44 to your computer and use it in GitHub Desktop.

Who we are: Igalia are active participants in ECMA, W3C and WHATWG and are very significant contributors on all of the browser engines and Web Platform Tests, as well as some downstream browsers. We are also the maintainers of 2 of the official WebKit ports for Linux: WebKitGtk+ is the engine Epiphany (now named as Web) is built on top of, and its the browser shipped by default in various linux Desktop distros; we are also the creators of WPE, a WebKit port optimized for embedded devices.

Position comments:

There are a number of ways to frame a question. "Should the web have maps?" seems like such an easy one: The obvious answer is yes.

However, by itself this is not a very useful answer: The web does have maps. Some of the earliest popular uses of <img> were for geographical maps. That's purely declarative, and it's in HTML. But most of us would agree that that's not what we mean.

As has been pointed out, the web actually even has a element. Indeed, here too some of the earliest popular uses were for geographical maps.

The web also has canvases upon which you can create maps, and SVGs with which you can create maps - even interactive ones. And indeed, today, on the web we have all sorts of rich geographical maps built with complex libraries which coordinate asynchronously with various kinds of complex servers, some of which even work offline, to give us... more.

Clearly, none of these are what we meant with reagard to the original question. What we do mean to ask requires more clarity in order to comment.

However, this is challenging for some very pragmatic reasons.

Some of the most difficult challenges ultimately surround prioritization: Each step from idea to discussion to spec writing and test writing, to finally development and shepherding something through shipping in a browser requires the prioritization of some level of investment from what are ultimately finite budgets (including those of simple attention to understand and discuss). The bigger the scope of problems and depth of solutions we're suggesting (decisions built on other decisions), the more of all of that we are asking for.

Instead, if we back away from the problem a step, we can ask the more basic question of "is the status quo good?", I would assume that we can fairly easily agree that the answer is "no". While the web contains many maps today there are challenges from all directions. For authors, they have to make a lot of choices and decisions. They are learning to to write everything about a map in the sense of hooking into largely proprietary systems. Over time, these systems are more subject to change, and they aren't easily mapped to another system. They can also disappear altogether. Secondary systems, including perhaps simply a future version of ourselves can't understand them easily. None of those is particularly great for anyone. For users, performance can be an issue: Today's maps require really lot of JavaScript, and generally that's running on the main thread. Can any work be passed off to a worker or the GPU?

All of these are, at least to some extent, definitely improvable.

Igalia believes that, yes, some declarative element that would be "about" maps is an interesting thing to discuss and strive for. But we also recognizes that this is a very difficult problem to unwind. We believe that breaking down this problem into smaller and achievable goals would be a good strategy in supporting the general vision. As the use cases document shows, many of the same challenges for the mapping community are equally felt by those making games, doing ecommerce, genealogy, technical documents, creating graphical editors, and so on. The solutions in these areas contain a lot of similarities and the status quo isn't good for any of them either.

There are already a few concrete things which are already well defined which would improve the status quo in some way and that could be useful and interesting for other areas/business. Offscreen canvas, for example, would allow canvas based images to take advantage of additional cores off the main thread. That's pretty important for making a nice map interface if you use a canvas. Igalia has been leading this work in WebKit.

We believe there are clear use cases for features like pan and zoom, and opportunities for significant patterns and features in the larger platform that could make all of these use cases comparatively trivial to what they are today. Comparisons to relationships to audio and video elements, for example, are interesting in their decoupling of the provider and format better.

At Igalia, our model allows organizations to help take some of this exceptionally difficult prioritization factor off the table by allowing additional sources of investment. Many advances in the recent web platform have come through this model, CSS Grid being a single great example, funded by Bloomberg Tech. In the case of maps, we believe that breaking down the problem into steps forward, such that many areas of the larger web platform commons are able to help prioritize and reap the benefits from is very likely to have good success. In the very least, it will dramatically improve the status quo, and if we are careful, we move a step closer to larger aims.

In short, we believe that specifically mapping related elements are interesting, but it is difficult to allocate the time necessary to bring them about in the short term or in a single step. However, we are are very interested in hearing and discussing the many ideas in this workshop and helping to find the sweet spots which include pragmatic and potentially transformative ideas which are easier to prioritize, and we're looking forward to seeing how we can help.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment