W3C home > Mailing lists > Public > public-maps4html@w3.org > October 2016

Progressive Web Maps [via Maps For HTML Community Group]

From: W3C Community Development Team <team-community-process@w3.org>
Date: Sun, 2 Oct 2016 19:09:29 +0000
To: public-maps4html@w3.org
Message-ID: <2efcbfe8800d87f5244f5e05f9d0c240@www.w3.org>
Progressive Enhancement is at the heart of the Web. The Maps for HTML Community
Group is making PE work for maps.
Progressive Enhancement
Progressive enhancement is a well-established practice. The core idea behind it
is layering: markup delivers the essential content, with behaviour built into
the browser; stylesheets provide adaptability to individuals and devices, and
script delivers the finally enhanced experience if all goes well.
The layering principles behind progressive enhancement have spawned the notion
of a Progressive Web App, in which certain features of mobile apps are layered
on top of the essential user experience, to those browsers which support the
advanced features. Notably, script can be used to progressively enhance the
network itself, and provide an offline experience if necessary.
Similarly, progressive enhancement can also apply to the Web author experience.
HTML authors don’t start out as CSS gurus, nor as fully-fledged framework
programmers. We usually begin either as kids with a grade school homework
assignment on how to create a Web page, or as curious adults who accidentally
right-click on the View Source menu. Either way, the experience of going from
being a Web user to a Web author can be seen in the light of progressive
enhancement: understanding what HTML elements do and how to use them, followed
by understanding how they can be laid out and perhaps, if you become a
programmer, enabling more sophisticated interactions with scripting.




Progressive Web Maps
So, how does all this relate to Web maps? On today’s Web, there is a major
disconnect between the map experience that most or all of us are familiar with
and the sketchy foothold that the Web platform offers to maps as a concept. The
disconnect lies in the fact that there is no progression between Web platform
maps and how maps are implemented today.



The question is how to bridge the gap? How can the platform afford HTML authors
of all experiences and abilities the opportunity to create a modern Web map
experience that is progressive?
In the past, such a question had an all-or-nothing answer. Either you use
advanced features of the platform (scripting, WebGL, canvas, etc.), or you get
nothing. Such an approach is not progressive; it is more like (graceful)
degradation. In order to be relevant today, a solution must be progressive
andresponsive.
Today’s answer is provided by evolving modern Web standards in the form of
Custom Elements, which give us the opportunity to extend the Web platform.









 
 
 
 
 
 
 
 


Here it is. You might like to load that page in different browsers or devices,
or reload having disabled JavaScript, to get the idea of how it progresses and
responds. It is a work in progress, so no promises are made.
There are many detailed considerations to PE of the map element, and the Maps
for HTML community seeks feedback with this post about what is best for web
maps. Web Incubator Community feedback would be greatly appreciated.

The Web, Extended
There are two main design options for Custom Elements: extending the semantics
of existing standard elements by with attributes and/or permitted content
(a.k.a. customized built-in element e.g. Drink me! ) or defining entirely new
elements (a.k.a. autonomous elements e.g. Eat me! ). Although the barrier to
doing the latter might seem lower at first glance, there is a school of thought
which suggests that the former approach provides better value to the Web
platform and progressive enhancement is its name.
The advice of the Custom Elements spec is:

The simplest and most robust method to create custom elements that are usable
and accessible is to implement custom elements as type extensions. This method
provides a custom element with built in semantics and interaction behaviours
that developers can use as a foundation.
If we, the Maps for HTML Community Group are successful, we will eventually have
built, or caused to be built, a large set of Web sites which use our custom
element(s), and it’s API. Ideally at that stage, browsers will agree that it
makes sense for them to implement our element natively. If our element is
‘autonomous’, a new element (without the hyphen) will have to be minted and
marketed, and all that portion of the Web which uses our element would have to
be re-written to take advantage of the new reach. I suppose you might consider
that a problem of success, but it also represents a barrier to adoption.
A more viable solution will be to extend the behaviour of the HTML map element
as demonstrated above. Not only can the new functionality be layered
appropriately for progressive enhancement, but at worst, HTML authors will have
to remove the is=”web-map” attribute from their markup to gain a
“native” implementation; all selectors and code not based on the “is”
attribute should continue to work. That’s the theory, at least; there is a lot
of work to do to see this prollyfill through to completion.

Further Progress
If creating a declarative Web map was the only goal, we would be essentially
done now, because there are many such Custom Elements today. But a declarative
Web map is only a starting point for progressive enhancement. Although the
beauty and sophistication of today’s Web maps can’t be accomplished without
a lot of scripting magic, those maps really are beautiful and sophisticated. The
Web platform could provide a standard script API which enables enhancement from
a common declarative starting point, and just as importantly, allows HTML (map)
authors to progress from beginners to experts.
Arguably, the central innovation of the Web platform is indirection through
hypertext using URLs. This allows user agents to be coded in a
domain-independent fashion, applicable across the Web. It is also this aspect
which underpins the type extension map element: maps and map content rely on
URLs and media type semantics. The map type extension element also relieson this
Web superpower. This allows authors to easily include content from different map
providers “interoperably”.
That’s where community comes in.
The Maps for HTML Community Group warmly invites the authors of google-map,
here-map, leaflet-map, Leaflet.js, openlayers-map, OpenLayers.js, mapbox-map,
carto-map, apple-map, etc., and yourself to join us to show your support, or
even contribute 😍.
Thanks to •?((¯°·._.• вкαя∂εℓℓ for reviewing an early draft of
this post.



----------

This post sent on Maps For HTML Community Group



'Progressive Web Maps'

https://www.w3.org/community/maps4html/2016/10/02/progressive-web-maps/



Learn more about the Maps For HTML Community Group: 

https://www.w3.org/community/maps4html
Received on Sunday, 2 October 2016 19:09:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:23:45 UTC