Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?
On 9 December 2013 09:33:47 Yoav Weiss 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. 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 and 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
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
Processing of newlines and HTML in description member
The spec isn't explicit about what formatting the description can contain. The assumption is probably that it's plain text, but it may be worth being very explicit about it (e.g. that LF is a visible line break and HTML tags and entities have no special meaning and are to be displayed literally). In RSS 2.0 this hasn't been clearly specified and titles and descriptions ended up being an ugly hybrid of plaintext and HTML that requires consumers to "sanitize" those strings and sometimes results in malformed content. -- regards, Kornel
Re: HTML as application manifest format
On Thu, 01 Aug 2013 17:57:20 +0100, Tab Atkins Jr. 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 and 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 values, and you don't get any of the benefit of the rest of HTML, because / *is all you're doing*. Actually, if I could define app's metadata and web components all in one file that would be awesome: (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 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 copy&paste 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 copy&paste 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 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
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.
and then my-app-definition.html could contain , 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 , , name="application-name"> that can be reused. Authors already know these
and it may be easier to define and understand how 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: rel=manifest href=/>
Here's HTMLized example from the spec:
http://www.w3.org/2012/sysapps/manifest/#example-manifest
http://example.org/dev";>
https://example.org/dev/es-ES";>
@viewport {
min-width: 300px;
max-width: 600px;
}
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 for permissions, so
maybe a better element needs to be invented for it:
or perhaps made generic:
--
regards, Kornel
Re: URLs into IndexedDB databases
On Mon, 15 Jul 2013 09:57:30 +0100, Jonas Sicking wrote: indexeddb:// 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
Re: [Server-Sent Events] Network connection clarification
On Tue, 10 Jul 2012 20:57:23 +0100, Ian Hickson 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 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-?
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:
or
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. parses (unfortunately
<::foo> doesn't).
Use of "::" would naturally allow some namespacing of reusable components:
(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
