On Wed, 04 Dec 2013 08:18:31 +0100, Marcos Caceres <w...@marcosc.com> wrote:
On Wednesday, December 4, 2013 at 4:16 PM, Jonas Sicking wrote:
> I’m not saying we shouldn’t allow it - just sayin’ its kinda crappy >
because it encourages bad development practices (leading to single
> page apps, etc.).
For simple apps I don't see anything wrong with single-page.
I'd rather spend time on making multi-page experiences good so that
authors don't avoid it, than try to force it.
[...]
Sorry, I should have clarified this a bit more. This isn’t about single
page vs multipage apps (of course there will be apps that are single
page!) - it’s about the expectation by browser vendors that apps would
be developed as single page and what we are seeing in the data about
single page apps: When looking at apps that declare
“*-mobile-web-app-capable”, which are supposed to be single page apps by
design, we found that very few apps are actually built as single page.
[...]
Having said that, there are issues also with navigating installed web
apps. The phonegap guys have a wealth of experience to share here,
though they are proponents of single page apps to overcome limitations
in the Web platform (e.g., avoiding the flash of white when loading
another web page when navigating). Anyway, we can deal with those issues
later - but just want to be clear about what we’ve seen in the dataset
we’ve been looking at in WebMob and what the forthcoming issues are
going to be if this goes mainstream.
Looking forward to you publishing that data. Is there a simple pointer for
those of us who haven't been following webmob closely so we can start from
somewhere better than "all of webmob"?
> > <meta name=manifest content="{ ... }>,
> > <link rel=manifest content="{ ... }">,
>
I think developers will object to the above. If src-n was an
abomination to some, then I can’t imagine the above being well received.
I think the src-n dislike came from the fact that it tried to use
something that has always been a dictionary with a limited and defined
set of keys and tried to use it as an array with an unbounded key set.
Yes, from an implementation perspective yes. But in the RICG, from web
developer perspective, it was more about the strange use of the
attribute.
Indeed.
That's very different from what we are doing here which is sticking a
very large value into an attribute.
Personally my vote goes to using <link rel=manifest> for external
manifests, and <meta name=manifest> for internal manifests. That has a
nice symmetry and reuses existing elements in a proper way.
And you can put line breaks inside attributes. They don't show up in
the attribute value but that seems ok here.
And you don't have to escape quotes as long as you use apostrophes as
to delimit the attribute value. I.e. the following is just fine.
<meta name=manifest content='{
"a": 1,
"b": "foopy"
}'>
I really don’t like this - specially messy with the single quote/double
quote thing which is one screws it up is a huge pain in the as to debug.
Structured content really feels like it should be in an element.
Yes, but I wonder how big a real problem that is. I happen to use a
bare-bones version of vi that doesn't balance parentheses, quotes, etc,
but I believe that shows I am a very strange person. As far as I know,
debugging this kind of error semi-automatically is actually pretty
trivial, and common.
> > or something else. Like you said, I think it's a conversation we
> > need to have with the HTML people.
>
> I’ll investigate a bit more. I’ve added a bug here:
> https://github.com/w3c/manifest/issues/91
>
> I’ll just note that having <link rel=manifest> and <script type> >
manifest would kinda suck… if we can just have:
>
> * <script type=“application/manifest+json” >
src=“manifest.json”></script>
> * <script type=“application/manifest+json”>{}</script> that would be
> great.
>
> That would be great. Reading the HTML spec, I think we can.
I prefer link/meta as the above is pretty verbose and a lot to
remember. And using <link> to link to external manifests just make so
much sense.
But I'll defer to you on this.
I’ll bounce it to HTMLs people and see what they say.
From an authoring perspective I don't think the verbosity is a big issue,
and the two options *seem* about equivalent in cognitive load - switching
elements is odd but people are clearly used to doing it for style, and
setting a type attribute in a script element compared to using link/meta
is the same thing.
Which makes the big question about taste in syntax (unless there is some
real implementation or web-compat issue). So I expect it to be the hardest
one of all to solve :)
cheers
--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
cha...@yandex-team.ru Find more at http://yandex.com
