-
Notifications
You must be signed in to change notification settings - Fork 162
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
Why does this spec replicate HTML features? #97
Comments
Chrome for Android is moving to support more of the above HTML elements as fallback and don't rely on a manifest. For example, this bug adds support for This one adds support for using HTML's rel="shortcut icon":
|
One concern is the parsing of the content attribute of the meta tag, which is not really standardized and very quirky in current implementations. |
Meta tags are easy to (ab)use as they are simple to add, so adding one for Chrome is not very invasive. I understand why they choose that, when it is not standardized. |
For instance with viewport, some browser vendors implemented ; as separator because they though it was working as such on Safari, but safari just ignores trailing "trash" |
The HTML spec or the manifest spec can define parsing rules for relevant
The HTML spec defines some basic values and defers to a a registry with links to specs for other Of course there's nothing stopping anybody from using any new unregistered name, but OTOH that doesn't stop manifest spec from using existing well-defined names.
|
I suggest, at very least, that the manifest spec should define as many properties as possible in terms of existing Regardless of whether the manifest spec will reinvent its own properties or refer to existing meta tags, somebody will have to define what happens when a page uses both manifest |
@pornel I agree. The spec should provide fallback for all things it overwrites explicitly (and makes sure that it falls back to HTML when stuff is missing). At the same time, it might also be important to make sure |
I'll also note that if we reuse the HTML meta names, as @pornel suggests, we save a lot of bikeshedding. |
With JSON we have the benefit that is can be easily created (more easy and slightly cleaner than HTML) which is good for online stores (like what Moz is attempting). Having worked on translation before, having all the worlds languages in the manifest is going to show down loading and parsing of the data, if not introduce corruptions once in a while due to wrong encoding etc. An online store etc could just generate another json given the user language and it ties nicely in with ServiceWorker. |
@kenchris Every dynamic web page by definition has ability to create HTML. As for "clean", I wonder whether draconian (and otherwise unspecified) JSON error handling will hold long-term. It's a prisoner's dilemma. It happened to HTML and RSS already: as the format gets more popular, inevitably there will be slightly syntactically broken files, and when any major consumer starts accepting these, everybody will have to. It starts happening to JSON already. Lack of good i18n in JSON is indeed a problem. HTTP language negotiation or JS-initiated ServiceWorkers are not easily discoverable by crawlers. |
I have to agree with @marcoscaceres and @pornel on this one, manifest files have felt very wrong since moz introduced theirs. Another benefit of using standard html tags is that a user agent can intelligently upgrade an "almost web-app" to a web-app. Makes bookmarking to homescreen much easier when there is 1 identification process. |
What about the desire people have for an external manifest file? (Why would they want to?) |
While it indeed is possible to implement pretty much all functionality offered by the manifest in HTML tags, I'd like to note a few benefits I see in the approach of using an external manifest. 1) External manifest files can be cached. Marcos' example lists five lines of and elements which replicate the behavior specified in the manifest. The manifest is 164 bytes long, the HTML approach 241 bytes. While the difference is negligible, all of the information is static to the website and does not change for page-to-page. We're talking about adding four or five more meta tags for being able to customize some of the aspects of Chrome for Android's add-to-homescreen feature, namely for being able to modify the title, setting a launch URL, and so on. The problem here is the naming. Do we introduce a name consistent to the current naming (mobile-web-app-capable), support Apple's scheme (apple-mobile-web-app-title) or go for Facebook's Open Graph (og:title)? Twitter has their own tag (twitter:title) for Twitter cards as well. In every case, we're talking about introducing yet another tag developers will have to send with each of their pages. More advanced web applications will have to send a ton of properties for Chrome, a ton of properties for Safari, perhaps yet another format for Mozilla or IE, meta information to be used on Twitter cards and more meta information to be used on Facebook and Google+ references. This strongly advocates the need for UA-sniffing, which unfortunately is something most large players are already forced to do. Externalizing this data solves the problem of having to send it with every page. Standardizing the properties within the manifest solves the problem of everyone doing their own thing by providing a canonical source of the information. 2) Values can be objects or arrays rather than just strings. This solves the problem of the awkward and highly inconsistent formats the values of tags are currently using, especially when the tag's value can contain several sub-values (icons, viewports, notification-bar settings). For example, say that the New York Times wants to reference their native applications in the various stores. Using tags, you would end up with something like:
Instead, you could refer to them in the manifest by specifing them in a simple map containing whatever meta data a vendor would like to be able to support:
It feels a bit more verbose due to the larger number of lines (but in fact has less bytes), but is easier to parse and extend. In regards to JSON's draconian error handling, and also on the subject of not having the ability to comment in manifests, I really think this is something we should just try to fix in JSON. I know all current parsers will reject this (aside of eval()), but the longer we wait with introducing it harder it will be to change it. It's out of scope for this discussion, however. @marcoscaceres Whilst these bugs exist on the Chromium bug tracker, they are suggestions and no decision has been made yet about how Chrome for Android will implement support for additional icons, titles and so on. |
Thanks @beverloo, these are good arguments.
gzip eliminates cost of markup overhead in both cases, but you're right that it could lead to duplication on subpages. How about reusing manifest-specific
This way you could reuse app metadata of your homepage for convenience and likely bandwidth saving thanks to caching, or if that is not appropriate for some reason, generate a dedicated file.
We're developing a standard here, so if we succeed authors will only need to set properties once for all browsers (we can set standard meta names without switching to another format).
Indeed, deeply nested arrays/properties are awkward in <link rel="alternate app" href="http://itunes.apple.com?id=…">
<link rel="alternate app" href="http://play.google.com?id=…">
<link rel="alternate app" href="http://store.blackberry.com?id=…"> For more complicated cases I suggested extending |
Is it not possible to have an external HTML fragment with lots of meta tags that's imported in, so it looks |
@beverloo Good point about the awkwardness of having nested values in a meta tag. But this issue exists with or without a w3c manifest file. Why not just fix meta tags? Something like: <meta name="application-stores">
<meta name="google-play" content="com.nytimes.android">
...
</meta> or if that breaks the world we invent a new tag that allows for this. |
@matthewp, we can't invent a new tag in the head. Any new tag in the head gets re-parented into the body, with any subsequent valid head-dwelling elements. |
@brucelawson breaking of Since there are no existing consumers of the hypothetical future manifest/meta-grouping element there is no backwards compatibility issue. Everybody who needs to parse it will be up to date with Pages that don't want to break |
I think this discussion needs to track back to a higher level point - what is an application manifest trying to achieve, and is that goal any different from
I think it's 2. So with that in mind, why don't we acknowledge that what we're talking about is a generic way of expressing metadata about a document (call it an application if you must), and we want to be able to express that metadata in a way that avoid existing pitfalls with meta tags. Specifically the features we want that we can't currently achieve with meta tags are:
So, possibly a new standard that allows for metadata to be loaded via a Most of all, I desperately don't want to have to define both meta tags and countless proprietary external manifests just because everyone sees this as a different problem. I say it's all the same problem. |
Yesterday, I tweeted that iOS 7.1 will support a However, I'm pretty sure devs will jump on this and start using it even before iOS 7.1 is released (case in point: https://twitter.com/mathiasvalentin/status/412897141237899265 and similar comments). That's partially because anything Another example: looking at @beverloo 's example of native app references for instance, I obviously see that JSON offers more flexibility, but at the same time, the 4 lines of So, I'm just throwing this out here. I have no strong feelings about what the "right" format should look like, and will be happy to evangelize whatever comes out of this discussion, but from a developer adoption point of view, |
I think Andreas is right here "I have no strong feelings about what the "right" format should look like, and will be happy to evangelize whatever comes out of this discussion, but from a developer adoption point of view, tags have a bigger chance of succeeding, I believe." (and not just because he's my boss). It feels like re-inventing a wheel. http://www.w3.org/TR/html-design-principles/#do-not-reinvent-the-wheel. Or, with a terse, perfect but brittle and unfamiliar syntax, like widgets' config.xml |
@beverloo wrote:
Yes, externalizing does DRY-up the HTML + brings the benefits of caching. But the problem of proprietary extensions don’t go away. It’s impossible to keep up with proprietary extensions (citing the explosion of members that FxOS keeps adding + seeing what happened with W3C widgets - see Cordova's extensions to config.xml) - and people don’t bring them for standardization, so we just expect them to happen. This is again another significant limitation with JSON - it has no means to support "distributed extensibility" and thus a good way to support proprietary extensions (neither does HTML, really - but at least it So, currently, the manifest spec just throws in the towel and recommends using simple vendor prefixes - I think that’s already indicative of the limitations with JSON. To be clear, I'm not dismissing JSON here - but we need to be realistic about what is going to happen and make sure we understand the implications for the platform in the long term. Also, I don't think adding error handling to JSON will happen in standards land (not for a while at least, as the JSON guys are still fighting with the TC39 guys over who actually owns JSON and there is no talk of JSON 2 yet) - it will likely happen in the way @pornel describes, where some vendor will just accidentally on purpose relax the rules to accommodate some large content provider or it will just be a bug that devs exploit on mass. |
@triblondon wrote:
The problem is that Let me show some of the magic - consider that in the case for icons, <!-- bookmark/address bar icon -->
<link rel="icon" href="favicon.ico" sizes="16x16 32x32">
<!-- these all look good on 1 to 1.5, covers 24-128px sizes gamut -->
<link rel="icon" href="low-rez-icons.ico" media="(max-device-pixel-ratio: 1.5)">
<!-- only for hi-dpi displays, more details - covers 24-256px sizes gamut for retina -->
<link rel="icon" href="hi-rez.ico" media="(min-device-pixel-ratio: 1.51)">
<link rel="icon" href="foo.webp" type="image/webp" sizes="512x512" media="(min-device-pixel-ratio: 3)">
<!-- only for super hi-dpi displays that support webp! and need big-ass icons -->
<link rel="icon" href="foo.webp" type="image/webp" sizes="512x512" media="(min-device-pixel-ratio: 3)">
<link rel="icon" href="foo.webp" type="image/webp" sizes="1024x1024" media="(min-device-pixel-ratio: 3)">
I think we even need to go up one more level than the one you suggest @triblondon. The problems we seem to be trying to solve are independent of JSON or HTML:
1 (OS integration) is mostly solved by HTML - this is mostly 2 (run outside browser) is basically "apple-mobile-web-app-capable" and its new buddy "minimum-ui" - we could just bite-the-bullet and standardize "mobile-web-app-capable" in HTML (and then work out what the hell to do when a link is clicked... navigation with no back button becomes fun ... see #95 :)). 3 is not supported by HTML out of the box. But could be done through a meta or via CSS 4 (start in fullscreen) is not supported by HTML - the only solution is to use the Fullscreen API (which gets messy). Could also be solved with a meta tag or CSS by extending @Viewport. 5 (proprietary extensions) is currently So, what we are weighing up here is whether we add 3 (orientation hinting) and 4 (fullscreen hinting) on startup as either JSON or HTML ... plus a somewhat crappy way for people to add proprietary functionality to the platform. The rest is just mostly redundant duplication for the sake of DRYing up HTML a bit + maybe saving a few bytes on caching (at the cost of an extra HTTP request, though it's deferred until after the document has loaded or till when needed - so it's not too bad). I hope this helps frame the problem a bit better - at least how I understand it. |
Forgot to mention the |
Hixie made some changes in HTML to better support internationalization of He also clarified the icon's size attribute at bit so to make it clear that sizes means "raw size" in pixels - so to better support high-dpi displays. |
Ok, I'm working on explicitly forcing UAs to fallback to HTML elements when things are missing from the manifest. And to always treat manifest members as their HTML counterparts. I will enforce this in the test suite. |
Emailed the TAG about the fall back strategy to get their opinion: http://lists.w3.org/Archives/Public/www-tag/2014Jan/0139.html |
Hey @marcoscaceres I read the TAG thread and didn't get a clear answer on how this will proceed.. Mind summarizing? |
We've removed name and icons from the manifest. There is now nothing in the manifest that overlaps with what HTML provides, so this problem goes away (for now, at least). |
Sweet! Thanks for taking charge on this. |
After discussions with @sicking, I've put name and icons back into the spec. The fallback model is:
In 2, it's RECOMMENDED devs and implementors choose "application-name" and It's personally not what I think is ideal (I preferred no name or icons in the manifest), but it's a fair compromise. And there may be some benefits to having name and icon in the manifest: centralization and manifest-based updates to the metadata, so devs can update their icons and the apps name (though we still need a security model for that, as if it happens automatically an app can change itself to look like another app... Which would be bad). At least now we can move forward onto more interesting problems. |
As long as we continue to have the HTML fallback, realistically few UAs are going to adopt the manifest in the short or mid term. |
@matthewp Lack of backwards compatibility doesn't seem like a good motivation to adopt a new technology. Manifest should be adopted because it's a better solution. |
what @pornel said. It should be ok, but it might mean that we don't end up with good support for |
I enumerated a few reasons why having name and icons in the manifest makes more sense than relying on the HTML file here: http://lists.w3.org/Archives/Public/www-tag/2014Feb/0039.html Once we see the manifest spec being successful, I think we should make the HTML spec specifically mark the application-name as deprecated and encourage authors to use the manifest instead. Not sure if the same makes sense for icons since the icons is also displayed in the URL-bar in most UAs. |
@marcoscaceres I think this issue must open again for these reasons:
And also I think register another app logic process as I propose this way to tell the browser that our app can be PWA (or just has CSR ability) <meta name="display" content="standalone">
<meta name="theme-color" content="#66ff55">
<link rel="home" href="/?utm_source=PWA&utm_medium=shortcut">
<link rel="main" href="/gui/main.html">
<script type="module" src="/gui/main.js" async></script> By above CSR standard propsal that indicate a Last but not least as lots of good face HTML specification never get standard like @apply in CSS, Editors must be brave to abandoned |
Elsewhere, @pornel wrote:
We already have
<meta>
/<link>
for most of the manifest:Can be written today, without reinventing the wheel, in a backwards-compatible way:
And unlike JSON, it supports comments, internationalization and doesn't invalidate entire file because of a single trailing comma :)
The text was updated successfully, but these errors were encountered: