Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?
On 9 December 2013 09:33:47 Yoav Weiss y...@yoav.ws wrote:
IMO, it might be better not to define an explicit way to inline the
manifest, and let authors simply use data URIs to do that, if they see such
a need.
e.g. link rel=manifest href=data:application/manifest+json,{ ... }
If this becomes a common authoring pattern, an explicit mechanism might be
a good fit. Otherwise, there may not be a need.
My suggestion is to define manifest in terms of meta and link elements
whenever possible (e.g. manifest name duplicates meta application-name
defined in HTML and there are other overlapping meta tags and link relations).
This will reduce spec duplication/overlap/conflicts and at the same time
provide basic inline manifest equivalent and gradual migration path for
pages that currently use meta tags (if author decides that their meta tags
take too much space they can migrate the tags to an external manifest).
Here's bug for this: https://github.com/w3c/manifest/issues/97
--
regards, Kornel
Re: Browser search API
On Mon, 02 Dec 2013 11:42:30 -, Mounir Lamouri mou...@lamouri.fr
wrote:
Hi,
I am not sure that telling the webpage what the user is currently trying
to search is a great idea. However, if a webpage wants its own find in
page UI I guess a simple solution would be to do something similar to
the Forms Validation UI: a 'findinpage' event could be fired on the
document when the user initiates a find in page and the page would be
able to call .preventDefault() on the event in order to show its own UI.
It could look like:
window.document.addEventListener('findinpage', function(e) {
e.preventDefault();
var find = createFindInPageUI();
find.focus();
});
Would that work with OS X's Find Pasteboard?
In OS X I can press Cmd+E in any application to choose selected text as
the search keyword and Cmd+G in any other application to search for that
text. This allows me to search pages in browser without ever invoking
find in page explicitly in the browser.
I suggest having non-cancellable event that merely informs the page what
user is searching for. The event could be populated from any UI, e.g.
typical find-in-page dialog/toolbar, from search pasteboard or voice
command.
Then pages like Google Docs could do:
window.document.addEventListener('find', function(event) {
editedDocument.showPagesContaining(event.findInPageQueryAsRegEx);
});
I'm not sure if there needs to be a way for the page to respond when it's
ready — it might be enough if browsers just react to dynamic DOM changes.
Otherwise I'm afraid that sites will start hijacking browser's
find-in-page UI to provide their enhanced version that doesn't match
platform's conventions and lacks functionality.
--
regards, Kornel
Re: HTML as application manifest format
On Thu, 01 Aug 2013 17:57:20 +0100, Tab Atkins Jr. jackalm...@gmail.com wrote: HTML is the Web's serialization format *for HTML, and other text-like things*. As Kornel's example shows, HTML is *not* well suited to holding key/value pairs or the like; The ugly part is current lack of support for nested groups of metatags, but HTML is pretty good at nesting in general, so this can be fixed easily (I've proposed metagroup and permission in passing). OTOH JSON is by design set in stone, so you can't relax parsing even to fix the merge-conflict-inducing trailing comma, you can't add language attribute to values, you can't add proper comments. Here's a very interesting post about hacking JSON format, motivated by pains of using JSON for configuration: http://fadefade.com/json-comments.html Comments are irrelevant for data serialization/exchange when JSON is spit by software (and this is where JSON shines), but become a necessity in files that humans have to carefully maintain. When files are written by hand (and config files most often are) people can abuse the syntax. The comment hack proposed in aforementioned article makes JSON-with-comments incompatible with ES5 JSON and turns underspecified quirk and implementation detail into de-facto standard. JSON left out comments deliberately to avoid deteriorating by having a hacky extension point, and now a hacky extension point has been found... you have to hack them in via ugly meta values, and you don't get any of the benefit of the rest of HTML, because meta/link *is all you're doing*. Actually, if I could define app's metadata and web components all in one file that would be awesome: link rel=import manifest href=/ (and for added awesomeness I'd make that file my homepage, so I can have self-contained 1-request web app, and subpages that get the manifest and components from the page that is most likely to be cached). This is quite different from Templates, because those are actually leveraging HTML, and so using HTML as the delivery format as well just reduces impedance mismatch. I don't think that applies here. JSON is the way the web does key/value transmission. JSON is fantastic for bare key/value transmission (uncommented, unlocalized automatic data dump), but manifest is not just a basic key/value transmission. Locales tree-patching-dictionary in the spec shows that manifest already has impedance mismatch with JSON data model. -- regards, Kornel
Re: HTML as application manifest format
On 1 August 2013 12:44:19 Scott Wilson scott.bradley.wil...@gmail.com wrote: Or you could perhaps use XML. A bit like, er, this: http://www.w3.org/TR/widgets/ Hehe ;) I'm trying to address two things: 1. it's been shown ever and over again that developers on the wild web are really bad at working with strict syntax. HTML, XHTML that won't parse with right mime type, even RSS ended up as a soup. Strict manifest will inevitably face the same tension - either single misplaced JSON comma or XML quote will break the app (and frustrate developers) or browsers and other clients will eventually give up again and accept almost-JSON soup that works. HTML already got past that and deals with real-world mess. Let's not tempt JSON5 :) 2. Pave the cow paths. We already define web apps using meta tags, including bunch of Apple's tags for web apps (added to home screen kind). Meta is a well-understood existing mechanism that works. Everybody building web apps creates and references HTML pages with metatags all the time. Another very important aspect of it is that it lowers the learning curve a lot. You learn how to add one meta (that's the charset, should be mandatory for every dev). You then learn few more metas for favicons, google, viewport, mobile Safari. You copypaste them. *Then* you learn how to create common file, and you do it based on whatever you have working already. Very easy and gradual. OTOH new format, with new names, new structure, no comments in JSON case, new and annoyingly pedantic syntax and separate file from day 1 is jumping on the deep end. It's trivial for us, experienced developers in this forum, to write JSON manifest, but beginners on the web start with copypaste and very little knowledge (and that's good! That's a low barrier to entry) so reusing their skills and letting them learn in small increments will help them a lot. Also look into the future - if Web Components with link rel=import take off you'll have lots of pages importing HTML of jQuery of components. HTML import might become natural and logical way of extending pages, and JSON may remain the odd exception. -- regards, Kornel
Re: URLs into IndexedDB databases
On Mon, 15 Jul 2013 09:57:30 +0100, Jonas Sicking jo...@sicking.cc wrote: indexeddb:origin/persistence/database/objectStore/index/key/keypath Each piece above would have to be encoded such that it contains only valid, non-'/', URL characters. For things like database name and objectStore name this is easy by simply %-encoding characters. For the key this is significantly messier. We have to encode things like Dates and numbers, as well as Arrays. There's no shortage of ways of doing this, but there's no particularly clean way to do it either I think. That makes sense and I think key encoding is solvable with some microsyntax (I'll refrain from bikeshedding it here :) But what these URLs will be used for? Probably not for simple values that are smaller than the URL itself (what can you do with a URL that points to an integer?) So maybe the key use-case will be linking to Blobs in indexedb (e.g. images, full documents) and then it would suffice if only those Blobs had permanent URLs (e.g. window.URL.createObjectURL would be permanent for stored blobs). A third problem here is that it seems unfortunate to generate a new URL scheme for each storage format we have. I don't see a problem with that. If they have different addressing scheme, they logically should have different URL scheme. localdata: just pushes scheme name to the path. -- regards, Kornel
HTML as application manifest format
I'd like to propose using HTML as basis of manifest format, similar in
spirit to Web Components imports, e.g.
link rel=manifest import href=/my-app-definition.html
and then my-app-definition.html could contain link, meta or other
elements.
Rationale:
* while JSON is wonderful for automatic serialization, it's an annoying
format when maintained by hand (and manifest seems static and simple
enough to be maintained by hand).
- JSON syntax is pedantic about trailing comma. Authors have to be
careful when adding new element to end of a list.
- JSON does not support comments. Manifest is a central place of an
application, so may end up being modified by many team members, and it's
useful to comment why certain properties are the way they are, warn which
changes will cause breakage (again…), etc.
* We already have link rel=icon sizes, meta name=description, meta
name=application-name that can be reused. Authors already know these
and it may be easier to define and understand how meta and manifest
properties interact.
* We already have lang hreflang attributes, so there's no need to invent
locales dictionaries.
* It can be inlined naturally, saving a RTT.
* It can be mixed with Web Components allowing applications to define
everything in one place if they wish to.
* Simple websites can reuse homepage as their manifest file: link
rel=manifest href=/
Here's HTMLized example from the spec:
http://www.w3.org/2012/sysapps/manifest/#example-manifest
html lang=en manifest=/cache.manifest
meta name=name content=The Example App
meta name=description content=Exciting Open Web development action!
meta lang=es name=description content=¡Acción abierta emocionante
del desarrollo del Web!
meta name=launch-path content=/
meta name=version content=1.0
link rel=icon sizes=16 href=/img/icon_16.png
link rel=icon sizes=48 href=/img/icon_48.png
link rel=icon sizes=128 href=/img/icon_128.png
meta name=author content=Foo Corp.
link rel=author href=http://example.org/dev;
link rel=author hreflang=es href=https://example.org/dev/es-ES;
style
@viewport {
min-width: 300px;
max-width: 600px;
}
/style
meta name=required-features content=touch geolocation webgl
meta name=permissions:contacts:description content=Required for
auto-completion in the share screen
meta name=permissions:contacts:access content=read
meta name=fullscreen content=true
meta name=release_notes:1.0 content=Bugs fixed. New exciting effects.
Ready for an official release!
meta name=release_notes:0.5 content=First alpha version with still
some bugs but already fun!
When writing this I was surprised how well existing functionality fits
(and thus how much NIH can be avoided).
The only bit that didn't seem natural fit was meta for permissions, so
maybe a better element needs to be invented for it:
permission for=contacts access=read
meta name=description content=Required for…
meta name=description lang=pl content=Wymagane do…
/permission
or perhaps made generic:
metagroup name=permissions
metagroup name=contacts
meta name=access content=read
meta name=description content=Required for…
meta name=description lang=pl content=Wymagane do…
/metagroup
/metagroup
--
regards, Kornel
Re: [Server-Sent Events] Network connection clarification
On Tue, 10 Jul 2012 20:57:23 +0100, Ian Hickson i...@hixie.ch wrote: The idea is to let the script handle network troubles, so that authors are in full control of how much load their servers get when they are having trouble. The alternative is that UAs will DOS networks without the networks having a way to gracefully reduce it. I share the concern about DoSing. However, I'm afraid that the most common implementation (aside from complete lack of error recovery) will be a simple as 30-second retry interval and that won't be very DoS-safe. UAs can do better than that. For example the spec could require UAs to have randomized retry interval and exponential backoff on failure. Is there anything more that authors could do client-side to avoid DoSing? It'll be easier to get handful of UAs to implement robust recovery by default than to expect each and every author to do that. I'm not sure whether online/offline events are quick and reliable enough to speed up reconnection after network failure on client side, but most UAs could observe network on system level and avoid waiting too long time after temporary network signal loss. I doubt many authors will implement recovery as sophisticated as that. There's retry directive in the SSE protocol, so authors have some control already (server under load can send retry: 9 or site-specific control message and close the connection). If that's not enough, then I think it'd be better to give authors more control of UAs auto-reconnect features, rather than expect all authors to better than UAs with their implementation from scratch. SSE is mostly a convenience API (advanced authors can use streaming XHR or WebSockets to achieve the same result the hard way), so lack of convenience in error recovery feels like an omission in this API. -- regards, Kornel Lesiński
Re: [Server-Sent Events] Infinite reconnection clarification
On Tue, 12 Jun 2012 14:08:14 +0100, Glenn Maynard gl...@zewt.org wrote: What's the rationale behind the spec saying not to reconnect at all? If the API makes each app individually handle reconnects, then not only does it push more work on web developers, it'll create two problems: apps that attempt reconnects too rapidly, and ones that--as Odin points out--don't reconnect at all because the developer didn't know he had to. Indeed, I was under impression that SSE keeps connection persistent and does not require any error handling logic from authors. I wrongly assumed that SSE enters permanent failed state only when recovery seems is impossible, e.g. 404 error or DNS error due to an authoritative NXDOMAIN response, and not when the error is caused merely by temporary lack of Internet connectivity. Since SSE already recovers from unexpectedly closed connections, I think it should be safe for authors to assume it will always reconnect when possible. IMHO the spec should require UAs to reconnect whenever possible. Having fire and forget API is a very attractive option. Writing and testing error recovery code, activated only in rare cases, is not fun and won't work for the web. Pusher is a popular service that provides what SSE was supposed to do, but over Web Sockets, and their library reconnects automatically: http://pusher.com/docs/client_api_guide/client_connect#connection-states I think that's a good model to follow. -- regards, Kornel Lesiński
[webcomponents] Use x:: instead of x-?
x-bikeshed
Would it be possible to use :: instead of the x- prefix in custom
element names? i.e. allow any name as long as it contains :: somewhere:
foo::bar
or
button is=foo::bar
1. The :: is used for pseudo-elements in CSS, and for namespaces in C++,
both of which seem somewhat related.
2. x- is (subjectively) ugly, and has been used for experimental
extensions elsewhere. IMHO it's a bit of an eye-sore in the otherwise
elegant design.
3. document.createElement('::foo') works. foo:: parses (unfortunately
::foo doesn't).
Use of :: would naturally allow some namespacing of reusable components:
jqueryui::widget
/jqueryui::widget
(not True Namespaces in the XML sense, but IMHO that's also a good thing).
If I understand correctly, serialisation of :: in XML isn't a problem,
as XML documents could use the is= attribute instead.
--
regards, Kornel Lesiński
