Skip to content

Instantly share code, notes, and snippets.

What would you like to do?
The origin should be an ASCII URL, that is, non-ASCII characters
should be normalized down to ASCII.
LH: The UA should handle idna for us. I think this is a noop.
We are relying on urlmatch.js's normalization of :80 etc, not testing
that directly (because it makes the tests hard to run). We should
verify that all URLs are being normalized in all code paths.
LH: done:
Widgets are allowed in the code but not noted in the spec, need to be
readded. Takes a path and a preferred size, like {"widget": {"path":
"/widget.html", "width": 100, "height": 100}}. Height and width are
optional and are suggestions (the dashboard may not respect the
suggestion). (List of preferred sizes?)
LH: done:
To actually construct a URL from a manifest you need the full
installation object, which contains the origin; the manifest itself
does not contain the origin. They "key" is the origin
LH: yay!
urlmatch.js allows for username:password@, but that doesn't have any
meaning or place in this specification.
LH: unsure what to do. we could explicitly disable it, throw an error... thoughts?
"capabilities" are mentioned, but with no meaning. Should we have
something in the spec that has no meaning? It presupposes that it
will have a meaning, but since we havne't determined a meaning that
seems premature and like it's sneaking in a feature without clear
LH: yeah, I don't know what we should do about capabilities. it's a discussion
we should start on list, shouldn't block merge tho.
Icons are not clearly specified. Maybe we can take the specification
from <link rel="icon">?
LH: hmm
There's no maximum or preferred length on name and description. It's
not specified how it should be rendered; presumably all markup is
quoted (but e.g., <> is allowed) and whitespace is normalized (i.e.,
newlines become spaces).
LH: name? 512? desc? 4k?
Should locales have a whitelist of things that are allowed to be
overridden? Now it's a rough blacklist. IMHO only human-readable
things should be replaceable (possibly including the icons, which are
readable in a sense). Origin was originally kind of allowed for, but
does not seem valid any more. (This means, e.g., you must install the
English Wikipedia or the Spanish Wikipedia, you can't select language
after installation -- but that represents a real institutional divide
in Wikipedia anyway.)
LH in code, it's actually a whitelist right now. search for may_overlay in manifest.js
version: Presumably it's not even sortable in any sense? Also, not
user visible?
LH: totally and completely opaque to the repository. an unfortunate implementation
detail to mitigate problems caused by manifest updates requiring prompting. this may
change depending on the fates of capabilities.
We should probably point out that origin includes http/https and port.
LH: I don't mind adding language, you don't think 'origin' is widely understood?
I'm not sure what if anything Last-Modified on the manifest will
accomplish or do? Is that value stored in the installed record? Does
it provide a default for version if it is not otherwise specified?
LH: No. That sentence is a vestige. Do we even need to mention that
app devs may serve their files using standard headers in the appropriate way?
I don't think its necc.
We don't say how unknown keys are handled. I think they should be
ignored in all positions (e.g., should be
okay, just ignored). Also not just validation, but if they are
preserved when stored in the repo. This also implies that the
presence of any value cannot mean user confirmation, as a user agent
that didn't understand the key may have installed the app.
Confirmation should be stored separately, as a positive assertion.
The presence of any value (outside origin which we have encoded in
version 0, essentially) does not mean the user was fully notified and
consented to that value.
LH: I'm fine with allowing unknown keys. let's start a small discussion
on list? I can start it.
default_locale could be optional if the "locales" key is not in the manifest. In that case there's no localization possible anyway, so the "best" locale is always the "only" locale, be it "en" or "es" or whatever.
LH: I like this change too.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.