Re: [webcomponents]: When element is having a bad time
The linking stage would be a stage where all that happens is the registration of custom elements. No custom element code would execute, there is no need to dereference the parent prototype. All that happens is the loading of resources. ES6 modules are meant to handle dependencies, it's in their design. So instead of depending on a global custom element you hope has been loaded you can import a HTML module. Referencing an unbound global variable will throw a SyntaxError. ES6 modules will also have a linking stage. https://gist.github.com/wycats/51c96e3adcdb3a68cbc3 On Wed, Jul 31, 2013 at 5:50 PM, Dimitri Glazkov dglaz...@google.com wrote: On Wed, Jul 31, 2013 at 9:23 AM, Brian Di Palma off...@gmail.com wrote: Is it not possible to have a linking stage before a compile stage? Can you help me understand this idea? I don't quite get the definitions of linking and compile when applied to Web platform. Or to use ES6 modules so that elements must import the prototypes they inherit from or a SyntaxError is thrown? How do modules help here? Can you elaborate a bit? :DG
Re: HTML as application manifest format
Or you could perhaps use XML. A bit like, er, this:
http://www.w3.org/TR/widgets/
On 18 Jul 2013, at 14:57, Kornel Lesiński wrote:
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
PGP.sig
Description: This is a digitally signed message part
Re: HTML as application manifest format
Hi Kornel,
Although I have complete empathy about your criticisms regarding JSON, it is
actually quite fit for this purpose. Using HTML in the way you describe is
kinda problematic, in that it could include scripts and other resources:
basically, one would need to build a DOM to parse out the information - and
even if scripts where not run, or resources loaded, one would still then need
to make a special HTML just for this purpose (which would confuse people, as if
you use HTML you expect to be able to have access to features of the platform).
We are going to need a custom processor for the JSON format, but at least
parsing is already done for us (as it was with XML, though sadly it seems that
devs prefer JSON).
Thanks anyway for the suggestion and for taking time to think about the
problem! Hopefully you can continue to help us with the JSON manifest.
--
Marcos Caceres
On Thursday, 18 July 2013 at 14:57, Kornel Lesiński wrote:
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: HTML as application manifest format
On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote: Hi Kornel, Although I have complete empathy about your criticisms regarding JSON, it is actually quite fit for this purpose. Using HTML in the way you describe is kinda problematic, in that it could include scripts and other resources: basically, one would need to build a DOM to parse out the information - and even if scripts where not run, or resources loaded, one would still then need to make a special HTML just for this purpose (which would confuse people, as if you use HTML you expect to be able to have access to features of the platform). We are going to need a custom processor for the JSON format, but at least parsing is already done for us (as it was with XML, though sadly it seems that devs prefer JSON). FWIW, I tend to think that Kornel is hitting on something here. Whether we want it or not, HTML is the Web's serialization format. It's the one that helps us understand where hyperlinks are and how resources are interconnected. Having a manifest in that format sounds like a Good Thing. My take is that the concerns about building DOM and developers being confused are not super-critical. HTML Templates produce chunks of DOM that don't run scripts or load resources, and it's unlikely that constructing a DOM tree for the manifest will cause any serious performance concerns. Embrace the hyperlinks. They're the Web. :DG
Re: HTML as application manifest format
On Thu, Aug 1, 2013 at 9:24 AM, Dimitri Glazkov dglaz...@chromium.org wrote: On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres w...@marcosc.com wrote: Hi Kornel, Although I have complete empathy about your criticisms regarding JSON, it is actually quite fit for this purpose. Using HTML in the way you describe is kinda problematic, in that it could include scripts and other resources: basically, one would need to build a DOM to parse out the information - and even if scripts where not run, or resources loaded, one would still then need to make a special HTML just for this purpose (which would confuse people, as if you use HTML you expect to be able to have access to features of the platform). We are going to need a custom processor for the JSON format, but at least parsing is already done for us (as it was with XML, though sadly it seems that devs prefer JSON). FWIW, I tend to think that Kornel is hitting on something here. Whether we want it or not, HTML is the Web's serialization format. It's the one that helps us understand where hyperlinks are and how resources are interconnected. Having a manifest in that format sounds like a Good Thing. 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; 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*. 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. ~TJ
Re: [XHR] Event firing order. XMLHttpRequestUpload then XMLHttpRequest or reverse
On Tue, Jul 30, 2013 at 10:25 AM, Takeshi Yoshino tyosh...@google.com wrote: Change on 2010/09/13 http://dev.w3.org/cvsweb/2006/webapi/XMLHttpRequest-2/Overview.src.html.diff?r1=1.138;r2=1.139;f=h reversed the order of event firing for request error algorithm and send() method to XHRUpload-then-XHR. send() (only loadstart event) and abort() method are still specified to fire events in XHR-then-XHRUpload order. Is this intentional or we should make them consistent? We should make them consistent in some manner. Firing on the main object last makes sense to me. It also makes some amount of conceptual sense to do the reverse for when the fetching starts, but I feel less strongly about that. -- http://annevankesteren.nl/
[Bug 22856] New: Defaults for the IDBKeyRange static functions arguments should be defined in IDL
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22856 Bug ID: 22856 Summary: Defaults for the IDBKeyRange static functions arguments should be defined in IDL Classification: Unclassified Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Indexed Database API Assignee: dave.n...@w3.org Reporter: ms2...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org As follows: static IDBKeyRange only (any value); static IDBKeyRange lowerBound (any lower, optional boolean open = false); static IDBKeyRange upperBound (any upper, optional boolean open = false); static IDBKeyRange bound (any lower, any upper, optional boolean lowerOpen = false, optional boolean upperOpen = false); -- You are receiving this mail because: You are on the CC list for the bug.
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
[Bug 22856] Defaults for the IDBKeyRange static functions arguments should be defined in IDL
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22856 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jsb...@google.com Resolution|--- |FIXED --- Comment #1 from Joshua Bell jsb...@google.com --- Thanks. Fixed in https://dvcs.w3.org/hg/IndexedDB/rev/a659218b30e4 These were already defined clearly in the prose, so this is not a normative change to the spec. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 18242] Not clear what script that invoked the method means exactly in the case of e.g. a.setTimeout(b.postMessage, 0) // called from c
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242 Ian 'Hixie' Hickson i...@hixie.ch changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #29 from Ian 'Hixie' Hickson i...@hixie.ch --- Ok, here we go: http://html5.org/tools/web-apps-tracker?from=8113to=8114 Please reopen if it's not what you wanted! I think this cleans up everything we had open on this, right? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 18242] Not clear what script that invoked the method means exactly in the case of e.g. a.setTimeout(b.postMessage, 0) // called from c
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18242 Cameron McCormack c...@mcc.id.au changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #30 from Cameron McCormack c...@mcc.id.au --- (In reply to comment #29) Ok, here we go: http://html5.org/tools/web-apps-tracker?from=8113to=8114 Please reopen if it's not what you wanted! I think this cleans up everything we had open on this, right? Thanks. Reopening just to get your attention for this question: since you have this concept of unit of related similar-origin browsing contexts, how do I determine that so that I can find the right stack to push and pop from? I assume that incumbent script is something that is also related to the unit of related similar-origin browsing contexts now? -- You are receiving this mail because: You are on the CC list for the bug.
