Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Capability: JS independence #32

Open
AmeliaBR opened this issue May 25, 2019 · 3 comments
Open

Capability: JS independence #32

AmeliaBR opened this issue May 25, 2019 · 3 comments
Labels
discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion

Comments

@AmeliaBR
Copy link
Member

AmeliaBR commented May 25, 2019

This issue is for discussion of the map viewer capability (potential requirement) “Display a basic map without JavaScript”.


From the 2015 use cases report's list of limitations of current tools:

Reliance on script
All of the above Web map techniques depend on JavaScript, and so Web maps, considered as a feature of the Web, require a scripted environment to even exist. JavaScript on the Web embodies the 'code-on-demand' optional constraint of the Web. Thus a feature such as Web maps depends on an optional feature of the Web itself. When the option is not available or fails, the Web itself fails, or does not possess this feature. The fact that a sophisticated, not to say important, feature such as Web maps can be enabled by virtue of an optional feature of the Web is however, a testament to the magical qualities of the Web. Nevertheless, dependence on this facet of the Web has lead to a situation where there are no inherent map semantics in HTML, or on the Web.

Turning this around, a capability of a web map viewer is its ability to provide at least basic function when JS is disabled or fails for other reasons.

@AmeliaBR AmeliaBR added discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion and removed status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft labels May 25, 2019
@prushforth
Copy link
Member

I was browsing Zach Leatherman's twitter today, and I was reminded of a site that provides a reasonable map experience even with script disabled. It must have taken some excellent server side scripting, but nonetheless is very impressive and worth noting here. https://www.fixmystreet.com/report/1576145?lat=52.479435&lon=-1.889648&zoom=2

@nchan0154
Copy link
Contributor

This is definitely the best map experience we've seen so far when it comes to having JS disabled!

To summarize their technique, each map tile is served as an image. When JS is disabled, the pan and zoom buttons are actually link elements that change the URL of the page. The page URL takes the lat, long and zoom parameters much like some of the map widgets we've seen so far. A good example of progressive enhancement in action.

@prushforth
Copy link
Member

I think this section of the document could recognize that

<img usemap="#themap" ...><map name="themap"><area ...></map>

is a JavaScript-less map already supported natively by browsers, albeit without spatial semantics.

In this example, <img> and <area> are (abstract) "layers".

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: capability a specific capability or feature: should it be included? what details? should it be a requirement? section: map viewer Capabilities & use cases for declarative map viewer widgets status: editor's draft there's a draft section in the report that corresponds to this discussion
Projects
None yet
Development

No branches or pull requests

3 participants