Skip ⬇

Maps for HTML Community Group

Facilitator: Peter Rushforth

Slides

Previous: WebID, a federated SignIn API All breakouts Next: The Responsible use of GeoSpatial Data

Skip ⬇

Skip ⬇

Transcript

Peter, take it away.

Okay, yeah, thank you very much, Doug.

My name's Peter Rushforth and I'm a Co-Chair of the Maps for HTML Community Group.

And we are interested in standardizing maps for the Web.

And so I'll give a brief overview of the community group activities and objectives.

And then we'll go into a a brief summary of the recent workshop that we held on maps, well, on standardizing maps for the Web.

We invited basically the worldwide mapping community to participate and contribute opinions and ideas towards the objective of standardizing maps.

So our community group is dedicated to, focused on standardizing client-side mapping widgets to support maps in browsers.

We want to leverage existing client-server protocols that are basically standardized in GIS content management systems.

And we would like to standardize a media type, at least one media type, for maps in HTML as an extension to HTML.

We want to add mapping roles in ARIA and controls for client-side widgets together with APIs.

We have developed an open source prototype and we're definitely not, we're trying to avoid reinventing the wheel, specifically, leveraging existing best practices and models.

So we would like to, we have begun documenting use cases and requirements in a comprehensive manner.

And we want to establish what could be a benefit of standardizing maps in the browser from both the accessibility and internationalization perspectives.

And we want to test the interoperability of the use cases across the browser platform.

Next slide, please.

So the objective is not to create something altogether new that works in the browser, but to leverage existing GIS standards.

Many GIS standards are oriented towards server-side technologies and leveraging server-side technologies.

And we wanna use the patterns that have been established in leveraging those server-side technologies to develop client-side widgets that are built for purpose.

So we're seeking collaboration from, for example, the OGC community and GIS developers.

We're seeking collaboration from existing implementers.

So we need coordination to develop client-side protocols and APIs with the browser community Can I add here for those who aren't mapping folks, the OGC is the Open Geospatial Consortium which has a lot of mostly server-side web standards, or not web standards, maps standards, sorry.

So the project is coordinated by Natural Resources Canada, where I work and we have active participants, we are an active participant in the OGC and we have a long history of cartography and digital map making and digital map standards.

And we are seeking contributions from global participants, including other governments.

Next slide, please.

So the key thing is to integrate common and standard GIS practices and standards, to build on the patterns developed by the popular web mapping frameworks and to intersect our standards with existing web standards such as HTML, CSS and SVG and JavaScript.

So we wanna integrate common GIS standards.

So layers are a common abstraction across almost all map platforms.

And especially within GIS, interoperability is sort of defined by map layer operations.

So coordinate reference systems and projections are obviously a concern in GIS and we wanna provide standardized fit-for-purpose depiction of the earth surface in appropriate projections.

So what we've done in our current proposal is to define a limited, registered domain of coordinate system definitions and values that is similar to how link relations are managed in web browsers, so by registration.

Currently we support the common and popular Web Mercator, WGS 84, the Canadian Lambert Conformal Conic and Polar Stereographic projections.

Others are possible.

So scale and zoom are important criteria.

And zoom is, in particular, a characteristic that is developed or was developed by, basically, OpenStreetMap and Google Maps, pioneered by them, as a way of caching tiles on the server side at specific scales.

And so this is a well-developed pattern in web maps that we want to leverage.

Next slide, please.

Oops, sorry, go ahead.

So images and imagery are standard content types in web maps and in our custom element approach, in our specification approach, images can represent the whole map at once that is based on the OGC's WMS service.

That's a pattern that has stood the test of time.

Tiles are a common web mapping abstraction that improves the perceived performance of WMS and, definitely, improves performance of static tile caches and that's represented as a standard by the OGC Web Map Tile Service.

We support the simple features model from Open Geospatial Consortium which is, perhaps, the most successful standard from the OGC that encodes geographic features and properties in the geospatial environment and it's represented by many popular standard formats.

Next slide, please.

I just wanna note just so people understand, tiles are a way of selecting specific areas to pull images down from and so you tile them across a screen, but it's located in particular geographic coordinates.

And features are things like a restaurant or a road or any other feature of a map like that.

Right, thanks.

So GIS, the W3C and OGC communities came together to define what are best practices for the Web.

And that's another sort of document that is a key input to the objective of standardizing maps for the Web.

Thank you, next slide.

So we wanna leverage the patterns that have been developed through popular web mapping frameworks, specifically, OpenLayers, Leaflet, OpenStreetMap and, of course, the standard, but proprietary behavior of Google Maps and so on.

We're using those in our use cases and requirements as exemplars of what needs to be standardized.

Next slide, please.

So yeah, we wanna intersect our efforts with Web standards.

Obviously, we want to make these facilities fit with the existing standards of the Web, including HTML, so to provide a customized element set for maps and spatial information through new controls and APIs.

So of course, vector tiles are well implemented already by W3C standards, such as SVG and CSS.

So moving on to our workshop report, that's okay.

We can move on.

Moving on to our workshop report.

We're still writing the report.

This slide deck is basically the outline of that report and we will be publishing it off our W3C URL for the workshop website.

So the current report it'll summarize the current state of web maps and the potential for a web-platform native viewer.

It'll summarize what we heard from workshop participants who supported, who are interested in web map accessibility and internationalization and, also, the need for a standardized map component from the perspective of government data providers who serve open data over the web.

Next slide, please.

So the current state of web maps section of the or theme from the workshop.

I gave a presentation, my basic theme in life is to standardize maps in HTML.

We're very interested in getting the browser engines to help with rendering maps because its rendering is a very profoundly important task on the Web and browsers are architecturally in the right spot to do it.

Amelia Bellamy-Royds gave a presentation about the ongoing development of the use cases and requirements for web maps, which takes into account the wide diversity of web mapping frameworks that currently exist.

Dan Little of the OSG GeoMoose Project gave a presentation about the GeoMoose Project which has existed for coming up on 20 years now.

And it has gone through three iterations of web client-side technology.

Basically, has very many lessons learned in over the course of its history that relate to standardizing maps.

Satoru Takagi of KTI Corporation is a W3C member and has put forward a set of standards based on SVG and supporting Quad-Tree vector tiling allowing rapid display of server-side content in an adaptive fashion that is sort of already a standard in Japan, for sure.

And Terrence Eden gave a presentation on the importance of doing user research for standardization.

So there were conflicting opinions on the need for maps as a native feature of the browser.

On the one hand, web maps need to be standardized to be easier to create and mash-up.

But on the other, people said that there's no need to ask browsers to support maps because they already do via HTML, CSS, SVG and JavaScript.

And, yet, users do like declarative Web maps.

So finally...

In terms of the use cases and requirements, we need to survey developers opinions and I'll touch on that a little bit more later on.

The security map model for browsers could be updated to support layering, specifically, in the SVG map and MapML case.

And a single map should be, a web map should be decoupled to the extent possible from data sources.

The layers of a map should be indirectly coupled to a data source.

Next slide.

Yeah, just to clarify that, that means that you should be able to have a map that has a base map from, for example, one map server and then maybe layers or features or other things on the map from other maps.

Sort of a decentralized model of serving up maps.

Good clarification.

So the prospects, the discussion about a web map viewer for the platform.

So I gave a presentation on the Maps for HTML Community Group's work on the polyfill, specification in polyfill for MapML.

Bocoup gave their review of the MapML proposal and they endorsed the use cases and requirements.

They're not as impressed so far with the MapML polyfill, but we're working on them.

And Brian Kardell of Igalia gave a presentation that encourages us to be cautious about asking for stuff from the web platform, because it costs a lot, it's risky and it's a long-term prospect, but encouraged us to engage them for help and that's much appreciated.

Andreas Hocevar, one of the core developers of the OpenLayers Library, gave a presentation on improved rendering using OffscreenCanvas.

And he felt that an HTML standard for web maps might be a good starting point for future map development.

Brandon Liu of ProtoMaps and OpenStreetMap indicated that internationalization is...

Text rendering is the domain of the browser.

It's one of the main responsibilities of an ethical web and maps are, if nothing else, a rendering challenge.

And leaving the rendering of web map texts up to all of the different libraries is inappropriate architecturally.

So I guess he was plus one on the idea of maps in the browser.

Ivan Sanchez Ortega of the Leaflet, contributor to Leaflet, was a minus one on web maps in the browser, because he felt that they could be eventually co-opted to not work very well because they would work well on one browser's site versus in ways that could be problematic for web developers.

So next slide, please.

So from the government side of the house, we heard Danielle Dupuy of the USGS describe how database driven configuration and styles of web maps helped scientists create maps without having to code.

And although I can't say that map trace in MapML is intended to be a code free, it's intended to simplify the experience of creating maps, creating and mashing up maps.

Thijs Brentjens of Geonovum gave a presentation on the need for Fuzzy geolocation and the importance of privacy related to geolocation with the potential for developing intermediary services that were privacy preserving.

And he's very interested in collaborations on that front.

Sajeevan G gave a presentation on the Web GIS application for the Indian Prime Minister's Rural Road Programme.

We had a panel which convened.

Sebastian Durand and Cameron Wilson from the Canadian Geospatial Data infrastructure and Federal Geospatial Platform.

Don Sullivan from NASA who had worked on the early WMS specifications and Emilio Lopez Romero from the National Centre for Geographic Information of Spain.

And I guess the general sense is that standardized map components would be a benefit for users of open government data, because it would allow a broader base of users to access government information.

Next slide, please.

So we also had a large number, a large percentage of our workshop was dedicated to accessibility, which was wonderful.

We had a lot of different perspectives on accessibility.

A quarter to a third of the presentation material was accessibility related.

So, obviously, accessibility is a key feature that points to the need for standardization of maps.

So, it actually falls down into two different types of accessibility.

The first is location-based accessibility.

Basically, this is using maps as a way of distributing information about the accessibility of a feature.

Let's say, does a restaurant have a- (audio garbling) Excuse me?

Sorry, go ahead.

Does a restaurant have, is it wheelchair accessible?

Is it friendly to guide dogs?

Does it have an accessible bathroom?

Is there accessible parking?

This is metadata that can be sent out, disseminated through maps.

There's also consideration for indoor maps, things like facilities management or navigating around airports or convention centers or buildings.

So these are two big use cases for maps in sort of the physical space.

And then there's what W3C would more traditionally understand or deal with, which is the accessibility of the map interfaces themselves.

So are the actual controls accessible?

Can somebody who is blind, for example, use the map?

So in the location-based accessibility Sebastian Felix Zappe gave an excellent sort of metadata approach to physical accessibility data.

So there's an open source repository of accessibility information, it's crowd-generated, crowd-sourced.

And if that metadata is included in a map somebody who needs that metadata can actually access that seamlessly.

Indoor maps, Claudia Loitsch and Julian Striegl gave a presentation on some graduate-level work that's happening on trying to standardize the indoor map.

So we have the different kinds of maps, of course, you have, well, there's many different kinds of maps.

But there's navigation maps and sort of geographic maps and then there's interior maps and both of those things are interesting.

As far as the accessible map interfaces, Nic Chan and Robert Linder gave a review of some UI patterns in accessible map widgets.

Brandon Biggs from Smith-Kettlewell gave sort of a demo and an explanation of nonvisual and cross-sensory maps.

Basically, maps that use earcons or audio icons to indicate through 3D spatial rendering what features are around you.

Usually, you can actually sort of navigate using sound that's not speech.

And then Nicolo Carpignoli and Joshue O Connor from W3C gave an excellent presentation on map annotations and sort of use case and requirements there.

And there's a lot of things that annotations bring to maps.

A lot of these features can be understood as maps.

All of these slides and videos, by the way, for the workshop are accessible on our website and you can go there and watch them on YouTube.

Watch the videos on YouTube, look at the chat logs, et cetera and I encourage you to do that.

So we had two different panels on accessibility.

The first panel was Web Maps for Cognitive Accessibility and that was David Fazio, John Kirkwood and John Rochford.

And they talked about some attentional-based concerns for people with cognitive disabilities.

And then there was another panel, Creating an accessible Web map Widgets with Brandon Biggs, Tony Stockman, Nicholas Giudice and myself and all the rest of the panelists are themselves blind.

And they had some really interesting discussions of these audio maps and also tactile maps using, for example, the vibration API so that it feels like you can actually explore maps with your finger.

And as you run your finger over a feature, it can give a little vibration which feels like it simulates texture and so they're doing some pioneering work there.

And we discussed what other features might be needed from web standards in order to enable some of these use cases.

Although, using a web audio API and the vibration API gets us a long way there.

So here are some takeaways.

From the location-based accessibility, we need a generalized way to express structured data about points of interest, aka features.

So again, is this location wheelchair accessible?

Where is the accessible entrance?

Is it guide-dog-friendly Is the restroom accessible?

Where is its dedicated, accessible parking?

But there's a lot of non-accessibility use cases there.

Things like allergy info for a restaurant or business hours or menu, et cetera.

So how do we, without overloading the DOM, how do we provide a lot of information for a lot of different features on maps?

Maps are very large and very rich and there's any number of pieces of information that you might wanna get about a particular location.

So having some way of standardizing that metadata access would be useful.

And we also need standard ways to describe indoor maps for navigation.

There was a recent proposal from Apple to the OGC about this very thing and we'll see where that goes.

Regarding accessible map interfaces, there were a few reviews of existing map interfaces and they need a lot of improvement.

Most of them are not very accessible.

So that's something we're working on in our own, in the polyfill that we're making, the web component that we're making.

Accessible map annotation could help with information retrieval, navigation and comparing and monitoring info.

There are many possible improvements for the Web through sonification, earcons and vibro-tactile audio maps.

And finally, there are a lot of cognitive challenges, not just mobility and sensory, but also wayfinding and not being intrusive to a user while also being mindful of their need to be contextualized within the task that they're performing.

So again, there'll be more about this in our workshop report and go to the next slide.

All right, so, Peter.

Thanks, Doug.

So yeah, basically the community needs you to get involved if you want.

So that some of the things that are ongoing activities that people could help with are reviewing the use cases and requirements and contributing ideas to linked issues.

They're all linked to each use case and requirement is linked to a GitHub issue for discussion and we can pull requests as appropriate.

There is also the Web-Map-Custom-Element polyfill that implements the map markup language specification and you could deploy that.

You could test it for us and provide feedback on GitHub Issues as well.

If you represent an organization, there's undoubtedly someone who deals with maps in your organization.

So you could let them know about Maps for HTML and get your organization's use cases and requirements represented in our UCR.

And you could join the community group.

I mean even if you don't want to spend more time on this, if you support it you could join, because the more visibility the better in terms of browser prioritization and by simply joining you've contributed.

So finally there is, as I mentioned during the workshop, there is the Mozilla Developer Network, developer needs assessment survey that takes into account web developer's needs for standards and that is live now through the end of the week.

And the link is here in the slides and we'll provide that in the chat, maybe, if Doug wouldn't mind doing that.

And that's a very important document to contribute to and, if you do, please mention maps.

So, our workshop is accessible on the web and all the slides and videos and transcripts and so on are linked there.

And there are discussion forum items for each presentation or panel that if you watch a video of a talk and you think of a comment, well, you can make that comment on the linked discourse item, topic I mean.

And mapsforhtml.org is the project website.

It links to various resources associated to the community group.

And we have the W3C Community Group homepage.

A public mailing list that you don't have to be a member of the community group to subscribe to.

We have specs and issue trackers that you can avail yourself of.

Next slide, please.

So we had at the workshop, this is slightly out of order, but we had a panel of open source for web mapping experts including Andreas Hocevar, Simon Pieters, Will Mortenson and Daniel Morissette.

And the topics were how can FOSS4G or the OSGeo developers help with standardization in the browser?

How can they increase OSGeo participation or community participation and the future relationship between browsers and web mapping libraries.

Next slide, please.

So the takeaways were that, initially, we should contribute to use cases and requirements.

Stakeholders and developers for browser features are needed, like from now on, basically.

Geo people should get involved in guiding the evolution of browsers and we can do that by interacting more.

So we can look into ways that support not just maps in the browser, but non-geospatial maps and, furthermore, also primitives, so-called primitives, that can help non-map use cases.

And code sprints are a good way to collaborate and share ideas and OSGeo, FOSS4G have them every year.

And if maps do become implemented in the browser, mapping libraries will be able to focus on more interesting features, so progressive enhancement of maps.

Next slide, please.

I think that's it.

That's good.

So going back to the contact info here.

So now comes the community discussion part of the agenda, I guess.

So is there any questions or comments or discussion topics that people would like to bring up?

'Cause I know Doug and I can talk for a good hour, but it's probably important to invite others to share their ideas.

So, again, apologies.

Actually, I'm gonna take the slide back to the MDN, oops, to the MDN slide.

So unfortunately, neither of us at the moment have access to IRC, so if anybody has any questions, please just go ahead and unmute yourself and go ahead and ask your questions or comments.

Well, while we're waiting in case anybody has questions or comments and being shy, I personally am very interested in, oh, I hear somebody has unmuted.

That was me.

Oh, okay.

I personally am very interested in sort of as a first step to getting maps on the web, maybe making ARIA roles.

I was very surprised to realize that there is no role specific to a map in ARIA or not a single role regarding maps and maps are a very distinct kind of data visualization that are different from say a bar chart or other things.

There's a lot of other characteristics about maps and they're a known challenge, for example, for blind people.

People who use assistive technology.

So I find that there aren't, there isn't existing of roles, properties and states for maps.

And so that's one thing that we're gonna work on coming out of this.

And another thing, (phone ringing) sorry for the noise.

A lot of spam these days.

Another thing that we- (phone ringing) Excuse me.

Hello, so another thing that we have learned from the workshop is that there is this need for metadata and that we do wanna try to address that and that goes beyond accessibility.

And then the third thing that interests me is there's a lot of possible intersection with other use cases besides maps.

Things like tiles could be useful, for example, for medical imaging or looking at other images.

Very large images, you might wanna have them tile.

So having tiling is not exclusive to maps.

We could try to make some sort of standard for doing a tile layout of content.

And then there's also things like controls like zoom and pan.

These are things and tiling, by the way, is also interesting for XR.

So augmented reality and virtual reality.

So tiles, zooming and panning are features that those things share.

So it's possible we could make some sort of common controls that all of those things could use in a semantic way and that could actually get us further along the path to supporting maps as a first-class citizen.

Annotations are another thing.

A lot of features can be described, basically, by annotations.

And so how are all these things, how can we put together these primitives such that we can end up with something that is a first-class citizen?

So that's something that interests me.

Peter, I know, wants, thinks, Peter, I don't wanna mischaracterize you, but I think you think that maps are a sufficiently low-level feature that, yes, the primitives are nice but you really wanna focus specifically on the map use case and make sure that things don't get lost.

Is that correct?

Yeah, well, I mean I think that, I think that maps are already a shared primitive, in the sense that while they may be elements, okay already, but they are already shared.

You know Amelia in her use cases review, she showed a web map or a client-side image map that comes from the Canadian weather service.

And it has icons on it, on the image that are generated every hour or what have you and each icon has an area that links to the forecast for that location.

But image maps are not limited to, of course, map MAMS.

They were originally created to aid site navigation because people were sick of boring links and texts and they wanted to have fancy graphics in their websites.

So client-side image maps were introduced to make it easy for people to create a beautiful website that allowed navigation using links drawn on top of any old graphic.

So client-side image maps have been a shared primitive for 20 plus years.

More than 20 years now.

And even today, the modern web mapping frameworks, in particular the open source ones, are used to render not just maps, but imagery of all kinds.

And so there is sort of a shared primitive nature to maps already.

Doug, one thing I'm curious about is what types of roles would one think of seeing in an area map?

So that, yeah, so just could you go into a bit of detail that you imagine what might be?

Yeah, sure.

And again, if anybody has any comments or questions feel free to chime in.

But I, initially, the three things that occurred to me the most obviously were a map, just map, a role of map.

Letting somebody know that this is a navigation thing or whatever the map is for, but oftentimes it's about navigation.

And in fact, there could be properties that say what type of map it is.

Is this a navigation map, et cetera?

What tasks could you be expected to perform with this map?

So there'll be a map role.

And then the other two obvious things are map tile and map feature, right?

Or not, sorry, not map tile, I apologize.

Map layer and map feature.

And layers can encode lots of, they don't have to actually be, like they don't have to have geometry.

They can simply be data layers that add supplementary information to things.

So you might want to use them as a sort of a filtering mechanism.

And I'm not completely certain, I haven't worked out everything that this would be.

I just really started looking at it, but it seems to me, those are the three things that we wanna have maps and then as to sub roles, that would be map feature and map layer.

And then I actually, I had a thought based on something you were saying, which was the idea of the map.

I was actually rereading last night, I was reading the map definition, the specification, HTML specification for image maps.

Yeah.

In the MDN docs and I really got to wondering are those still being used?

I know, Peter, you like the idea of sort of overloading the map element to include what we think of as maps, rather than just image maps.

And there's a lot of skepticism about that.

But I also, I have to wonder if maps, if image maps are still being used on the web today given all the other technologies that we have to do things including SVG and other technologies and CSS, even having like shapes in CSS.

I wonder if people are still making image maps.

Certainly, there are still image maps that exist from the '90s and even 2000s.

But I wonder if in the past decade people have stopped using maps.

And therefore, if it might not be appropriate to overload the map with some additional semantics, not that we necessarily need to, but it did occur to me that it might not be too challenging to do that because we might not be, we simply might not be using the map element much anymore.

Well I mean, Simon Petiers is in the audience, so he has a leg up on elements statistics.

But I think what I would say is that the map, the client-side image map is a neglected element.

Like, I don't think it's being properly maintained.

I mean, and not through lack of interest.

I think Simon has raised issues on it, as well as, myself and others.

But I think part of the challenge of maintaining it is that there isn't a community speaking up for it for one thing.

And so there are client-side image maps out there historically, but they're in use.

I mean that weather map site that Amelia demonstrated it's in common use.

And I guess one of the things I would say about it is that it's accessible, right?

It's because it's in theory, at least it might have cross-browser bugs but it's got roles for the links and so on that are on the map that are labeled for accessibility technology, I believe.

Yeah, I guess the last thing that I would wanna say about this whole enterprise is that, first off, I think it's an interesting idea to make maps primitive.

We've actually talked about this.

This is actually one of the proposals that went into HTML5 very early on, not this particular proposal, but just the notion of maps as a primitive in HTML.

But it wasn't really pursued much, but it was definitely early feedback.

I really like the idea of making maps and all the associated primitives sort of first-class citizens.

But the other thing that I'll say about it is that I do think that we can learn a lot by existing map applications that exist on the Web.

And I see that you've brought those principles into this.

You've looked at OpenStreetMap and OpenLayers and all these GIS standards.

And you have thought about this in making your proposal.

And this needs, are some cow paths that could be paved, right?

This isn't starting completely from scratch.

This is based on wisdom that has been gleaned over the past, I guess I mean, there've been maps on the Web since there's been a web pretty much.

So over the past, what 30 years almost?

Pretty close.

Of development and, especially, in the past decade, right?

They've especially gotten much more mature and much stronger in the past 10 to 15 years.

So I think there's a lot that we could learn there.

And I like how you have integrated that.

I think that there's a lot of cow paths that could be paved in standardization.

For sure, I mean we need the guidance of the web platform community to help us make the connections that should be made, as opposed to the connections that we may or may not be making correctly.

Like, for example, with client-side image maps is it better to evolve the design of an existing element?

Or is it wiser to start with a new, start a new element and leave the old to the old?

You know, and those are questions that we need help answering, I guess.

Yeah, I think that just to be clean it should be just, personally, I think it should be clean to be clean, it should be designed as its own thing.

But there may come a point at which we co-opt an existing map element.

But I think that just for tidiness, we should start, of course, with its own thing.

But that's my personal opinion.

I'm interested in what others have to say.

Can I react?

Absolutely, please.

Yeah, so yeah, since you mentioned how old maps on the Web are, do you remember the Xerox PARC server?

If you were there at the very start of the Web, then you might have seen that one.

I've come across it, yeah.

It doesn't exist anymore, unfortunately.

About the image maps, that made me think of something.

I don't know how many image maps are still used.

I know what I do.

I put maps on my pages.

Then I overlay HTML on top of it with a CSS absolute positioning to create clickable regions.

That's my favorite method at the moment.

You may have seen currently on the TPAC pages even I put a fake map on the hallway conversation page there was this idea from Alexandra, because we don't have actual physical location but usually we have a map on our pages.

Right.

That shows where the breakout rooms are.

We decided to create a breakout room map there.

So yeah, it's a fake map.

While doing that, I had a consideration that I'd like to ask here.

So making a map inside your webpage, for me that means being able to style it.

I want the colors to match the surrounding page.

The forms to match the size of the text, et cetera.

So are there considerations about possibilities for applying the CSS, inheriting the CSS from the page into the map in some way, has that been considered?

Yes, it's very much a desired outcome of the project, actually.

I mean when organizations make maps, you know sometimes there are very, very expensive resources applied to creating the cartography in that map.

And they don't want you messing with their cartography.

They don't want you changing their styles.

I think that's one use case.

But for a map, for a layer that's put on a map that has content local to the domain, to the HTML document of the domain of the HTML document, I believe it should be possible to style map content using CSS.

Now for things like tiles, for image tiles and so on what styling could you do?

Probably, not a lot.

But for things like features, there's a huge amount of styling.

It's not just styling, but rendering of text along vectors and relative to vectors.

And it's a huge domain, I mean there are many different vocabularies of style language that have been developed to accomplish these cartographic tasks.

And I believe that the influence like, in fact, people have tried to use CSS to fork CSS in order to achieve a styling language that is familiar to web map developers.

And I believe they got it backwards.

I think they should've tried to merge maps with the Web so that they could influence the actual CSS without working it to help map cartography and to support map cartography.

So, the short answer is, yes, we definitely see the need to integrate CSS into map styling.

We remain open to how to accomplish that, Bert.

Yeah, Bert, we'd love to hear more about your thoughts about it.

The first thought that comes to my mind for what it's worth is, yes as Peter mentioned, there are features which are usually like specific areas, designated like if there's a restaurant, it might be the outline of the restaurant or a park or whatever and so those things could be styled, perhaps.

And the other thing that occurs to me is...

And the images, I mean, if you have image tiles there's not much styling you can do to them short of using transforms or animations or filters.

But if they're vector tiles, then you start getting addressable features that you can actually say I want anything that has the class streets to be styled this way.

Anything that has a class building to be, and I want everything else to maybe display none or whatever you wanna do, right?

Like you, or add some opacity to it.

So when you're talking about vector tiles the possibilities for styling become a lot more interesting and possible, frankly.

Yeah, well, just to emphasize that, there was a demo on our Web-Map-Custom-Element page of styling vector, MapML vector tiles using CSS.

It's a fake styling because the notion behind MapML vector data is that it is like coordinates like KML, basically.

So in DOM nodes, which is at odds with SVG, but anyhow, for what it's worth, we felt that having markup, the possibility of marking up vector data using spans and anchors and so on is a very important use case for, in particular, to support styling.

So for example, in that vector tile information there are polygons of the world countries.

And those, when you break things up into tiles, in order to maintain the polygonness of them you have to introduce fake vectors or non-real tile boundaries.

And so what we did in that experiment was to introduce spans around the particular vertices that were introduced by the tile boundaries.

And then a class equals no line on those spans, so that it allowed CSS selectors to target polygons that should be rendered, polygon boundaries that should be rendered and render them in a particular color and style and to target tile boundaries and hide them, not draw them.

So there's sort of a core use case for CSS in MapML.

And I think there's also another thing, I won't get into too deeply, but just around shadow DOM and what's being portrayed in the shadow DOM versus what's being portrayed in the regular DOM in styling that.

I think that we're about out of time.

I think that's us.

Hmm.

Too bad, I was just getting warmed up.

So I waited too long before jumping in, evidently, because we're out of time but I wanted to answer at least the question about how many pages are you seeing the map element?

Sure, please, The answer to that is 1.5% of pages.

1.5%?

Yeah.

Oh, that's significant.

Yes, and I think the problem with reusing the map element isn't so much how much or little it is used, it's more of a- Semantics.

Possibility of risk for a browser, if you make changes to an existing element.

you run the risk of breaking existing webpages that are using that feature.

Absolutely, absolutely.

And with 1.5% that's actually a significant use.

Yeah.

So, Thank you, Simon.

Thanks for chiming in on that.

Are there any other, I mean, I guess we have to go, but is there anything really quickly that anybody has a question or comment about?

I just had one comment mostly to say that I like this idea a lot.

And, honestly, I had forgotten the HTML map element existed before I found out about this project probably a month or two ago now and I had completely forgot it existed.

It's probably been more than 10 years since I used it.

So there's obvious the compatibility issues to address but I like the idea of reusing it or adding to it if that were possible.

I'm sorry, I didn't catch your name.

My name is Joshua.

Hi, Joshua.

Hi, five.

I mean that's what we do when we extend HTML, largely, is add attributes to existing elements.

So, I mean I take the injunction to not break existing webpages, of course, seriously 'cause you know you can't, basically.

But at the same time, you don't wanna create confusion in the HTML language over entry points for new features without justification.

So, I guess I like the math element for a number of reasons, but one of them is the fallback, the fallback possibilities, right?

Because whenever you introduce new elements, you have to come up with a story for fallback.

So for example, the picture element was introduced into HTML and it wraps the existing image elements so that if the browser doesn't recognize the picture element it just serves the image element in its original form.

So we have to come up with some sort of declarative fallback story and the image and area elements, the image map and area elements seem to provide that.

Although, maybe it's not perfect.

And also, I mean, it hasn't been maintained in the sense that it doesn't support responsive design.

So you cannot have a media query that adjusts the area coordinates to select an image that's based on the device context and then selects or adjust or transforms the area coordinates appropriately to that.

So it's been, it's been neglected from a responsive design perspective and maybe that's why it's not as well used as it could be today.

Like it might be more popular if it actually had responsive design built into it.

So, I mean I think there are reasons above and beyond the potential of adding geospatial semantics to it that argue for it.

But we're out of time, definitely.

What organization are you with?

Are you asking me?

I am, sorry.

I'm just an individual developer.

Okay, that's cool.

Well, we'd love to have you join us in the community group.

I will be doing that.

Wonderful.

Great.

Thanks everyone.

Thank you very much.

Simon, thank you.

We will make these slides available.

Peter, can you make them world readable or make a copy of them to distribute, the slides?

Yep.

Thank you.

Thank you, all.

Thanks very much for your participation today and welcome.

Thanks, y'all.