Re: Fall back strategy for manifest

Hi Marcos,

>> On 28/01/2014 12:13 , Marcos Caceres wrote:
>> > So, I agree that the HTML should come first - and this works nicely
>> > for things like the application-name. What I'm still not 100% on is
>> > what I should do with things like icons... if one set of icons is
>> > declared in the HTML, should I bother looking for the icons in the
>> > manifest at all (i.e., should I union them)?
>>
>> I think it makes sense to union them. Say you have data in your manifest
>> describing a dozen different icons for different contexts. It would be
>> really strange if by just overriding one in HTML you suddenly lost all
>> the others.

I think that a union is totally fine and doable.

> I don't know... thinking out loud here... but now it seems even more
> pointless to replicate the stuff that is already in HTML, that is
> `icons` and `name`, in the manifest format.

As a developer I like keeping my metadata in one place, it makes it
easy for me to go and change things later and it makes it easier to
use tools. Also I can have my server return a different manifest.json
depending on ip, language or for some other reason.

Also I can add a default .wellknown/manifest.json to my web site and
override the icons in those of my the existing web apps that I have a
more specific icon for.

> As shown in [1], the stuff in the manifest is already a poor analogue
> of the equivalent HTML elements (e.g., no `media` attribute equivalent
> for <link rel=icon>s,

It can also be a disadvantage :-) say if people start defining
different icons for portrait and landscape (or given the ambient light
which I believe is being proposed as a media query), ie. differences
the target platform seldom cares about

If we wanted to, we could also add a media: to the manifest for icons.
But I don't think you would want to do that for name, etc.

> and no `lang` attribute equivalent for <meta> name=application-name>).

I would probably find another way to translate my whole app that just
the title anyway, so I am not sure how useful and used that is. I
would very much like to avoid making the download of my .html file
slower by including say 100 translations; yes, I remember this is one
of the problem we had in the GNOME project with its .desktop format
:-(

> And now consider that you have to include the metadata in the HTML
> anyway to have it work in legacy and non-supporting browsers - which
> means that there is no point in putting name and icons in the manifest
> at all:

You don't have to, but you can choose to if supporting legacy browser
matters to do. To some it does, to some it doesn't.

Personally, as a developer I reach for perfection when creating my
apps (very much like https://delightedapp.com/blog/pursue-perfection)
and as I already know that web apps are not good enough on most
platforms, I will only target the very best (ie. evergreen browsers),
as I don't want to release a bad product and hurt my reputation. When
that works very well, I might broaden my target.

> because HTML always wins over the stuff in the manifest (or
> you'd end up with a somewhat confusing mish-mash of the two in case
> they get merged together). The only time the stuff in the manifest
> would be used would be:

CSS also allows you to override what you define, the one closest to
the target wins, unless you set !priority. Maybe  you want a way to be
able to say that in the manifest as well; just use what is in the
manifest.

> 1. The developer doesn't want to provide this metadata to UAs which
> don't support the manifest (that seems bad for the Web! particularly
> when HTML already provides fairly well supported and fully
> standardized equivalents).

Think about it this way: How is that worse than using CSS regions (or
something else very hard to polyfill)? (to take a contemporary topic).
So developers shouldn't use CSS regions (and noone should implement
it) because it won't work in all browser and thus it will be bad for
the web? With that thinking we probably wouldn't have had AJAX, WebGL
etc :-)

> 2. The developer is creating a packaged app (but a different spec
> could specify name and icons specifically for packaged apps, which
> would actually make a little sense, though again the metadata could
> just be scraped from whatever the "index.html" is).

It would be very nice if that would work the same way.

Kenneth

Received on Tuesday, 28 January 2014 21:30:21 UTC