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

Use case: Progressive Enhancement #95

Open
prushforth opened this issue Jul 4, 2019 · 3 comments
Open

Use case: Progressive Enhancement #95

prushforth opened this issue Jul 4, 2019 · 3 comments
Labels
discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft

Comments

@prushforth
Copy link
Member

prushforth commented Jul 4, 2019

This should be an explicit use case, and we need to figure out where the line between native and JavaScript behaviour should lie. For discussion here, hopefully.

@AmeliaBR AmeliaBR added discussion: use case a possible use case: should it be included? what should it say? 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 labels Jul 5, 2019
@AmeliaBR
Copy link
Member

AmeliaBR commented Jul 5, 2019

Related to #32.

I'm not sure whether this makes sense as a separate use case, or if it should be integrated into every use case, in the same way that "accessibility" isn't a use case, it's a requirement for other use cases being met.

@prushforth
Copy link
Member Author

prushforth commented Jul 5, 2019

Fair. I was just thinking about sophisticated cartographic / spatial techniques that might be desirable, but would be such that they would be best left to scripting. And if you make that decision, you need to probably think about what API you would need to achieve the technique. For example, rendering vector tiles is unlikely to be taken on directly by browser engines (in the short term at least), but can certainly be done by script on canvas. So you would need to design an API to support that, which is not so much about JS independence (per #32) as it is about what should be left to script (today's maps are 100% left to script or, as we've recently discovered, sophisticated server-side programming that is not really in scope for standardization).

Relatedly, you need to think about fallback, not just for when script fails to load, but even before that, for the situation where an older (future) browser doesn't support maps and layers at all, but may support JavaScript, how could you get that browser to give you a decent web map (using JavaScript, probably) and not break on the new markup.

@AmeliaBR
Copy link
Member

AmeliaBR commented Jul 5, 2019

Relatedly, you need to think about fallback, not just for when script fails to load, but even before that, for the situation where an older (future) browser doesn't support maps and layers at all,

Ok, well that's something that we can describe as a specific authoring use case: make it easy to write code that incorporates fallbacks (regardless of why those fallbacks are necessary). Like how <video> allowed you to include a flash object as child content, but any browser that recognizes <video> knows just to ignore the fallback content.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
discussion: use case a possible use case: should it be included? what should it say? status: suggestion this issue discusses a suggested addition to the report, that is not yet in the draft
Projects
None yet
Development

No branches or pull requests

2 participants