Re: [webappsec + webapps] CORS to PR plans

[Arthur Barstow]

On 8/5/13 7:48 PM, ext Brad Hill wrote:
I'd like to issue this as a formal Call for Consensus at this point. 
 If you have any objections to CORS advancing to Proposed 
Recommendation, please reply to public-webapp...@w3.org 
.  Affirmative response are also 
encouraged, and silence will be taken as assent.


The proposed draft is available at:

http://webappsec-test.info/~bhill2/pub/CORS/index.html 



This CfC will end and be ratified by the WebAppSec WG on Tuesday, 
August 13, 2013.


Brad - what is the status of the `implementation report` you mentioned 
earlier:


On Tue, Jul 16, 2013 at 12:47 PM, Brad Hill > wrote:


If these changes are acceptable to the WGs, I believe the only
remaining steps are to prepare an implementation report and update
the test suite to cover the 204 and 308 status codes.   I'll let
us discuss these for a bit here before beginning a formal call for
consensus.



I don't understand what is meant in the draft PR by "There is no 
preliminary implementation report.".


-Thanks, Art

Re: [webappsec + webapps] CORS to PR plans

[Anne van Kesteren]

On Tue, Aug 6, 2013 at 12:48 AM, Brad Hill  wrote:
> I'd like to issue this as a formal Call for Consensus at this point.  If you
> have any objections to CORS advancing to Proposed Recommendation, please
> reply to public-webapp...@w3.org.  Affirmative response are also encouraged,
> and silence will be taken as assent.
>
> The proposed draft is available at:
>
> http://webappsec-test.info/~bhill2/pub/CORS/index.html
>
> This CfC will end and be ratified by the WebAppSec WG on Tuesday, August 13,
> 2013.

I don't understand why you ignored my technical feedback given prior
in this thread.


-- 
http://annevankesteren.nl/

Re: HTML as application manifest format

[Stian Soiland-Reyes]

You could in fact even embed JSON in HTML, like JSON-LD suggests:

http://json-ld.org/spec/latest/json-ld/#embedding-json-ld-in-html-documents


On 4 August 2013 22:23, Melvin Carvalho  wrote:
>
>
>
> On 1 August 2013 18:57, Tab Atkins Jr.  wrote:
>>
>> On Thu, Aug 1, 2013 at 9:24 AM, Dimitri Glazkov 
>> wrote:
>> > On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres  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
>>  values, and you don't get any of the benefit of the rest of
>> HTML, because / *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.
>
>
> It's rather easy these days to embed key value pairs in HTML.  10s if not
> 100s of millions of sites do it using rdfa, schema.org, open graph protocol
> etc.
>
> The markup need not be ugly
>
> Often it's as simple of adding a "rel" attribute in a tag (the key), and
> then the value is put inside the tag.
>
>
>>
>>
>> ~TJ
>>
>



-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester
http://soiland-reyes.com/stian/work/ http://orcid.org/-0001-9842-9718

Re: HTML as application manifest format

[Charles McCathie Nevile]

On Thu, 01 Aug 2013 20:24:40 +0400, Dimitri Glazkov  
 wrote:



On Thu, Aug 1, 2013 at 6:17 AM, Marcos Caceres  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.


Hmm. JSON seems to be Mozilla's serialisation format, and is also used in  
Blink for a bunch of stuff. That said, people have already commented on  
its drawbacks:
  - unless you think in data structures or pad it with whitespace  
everywhere it is hard for humans to read
  - it's incredibly strict and I don't know of any concrete suggestion  
that would change that

  - there is no standard mechanism for comments
  - nor localisation

But for vast numbers of developers

 

Is really *really* easy. It gets harder when you want to nest things - you  
can have


 

but we all know that you really need one of

 
 
 

or something similar that does complicate the use of meta.

As Scott notes, there are in fact a lot of people using the existing  
widget manifest stuff apparently without tearing their hair out - as well  
as his list there are Sencha, Blackberry, and other reasonably well-known  
examples. As Marcos has pointed out elsewhere, it is feasible to relax the  
XML parsing to work like HTML (Opera Presto does this for XML in general,  
and has been able to since well before they were working on widgets),  
which removes the most obvious source of terrible errors.


Adding a third way to encode the same semantics isn't obviously the right  
thing to do, but I think the idea is worth exploring.



My take is that the concerns about building DOM and developers being
confused are not super-critical.


Yeah, I suspect that isn't as big an issue as it seems.


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.


On the other side, if a page defines an application, and the metadata lets  
you take that application and run it off the page, that seems like a  
useful thing. From that perspective, the preformance impact of a few meta  
elements on a running application seems trivial. Browsers will generally  
be running the app (so for them the separate file is an optimisation,  
albeit a minimal one), while things like app stores that just parse the  
metadata are likely to ignore scripts etc.


Another problem arises if someone tries to use script to adapt the  
metadata eg for localisation, and a processor doesn't apply the script -  
but that's a case of defining use cases, requirements, and specifying what  
implementations need to do with the information they get.


For serious use cases I am pretty sceptical of meta elements. On the other  
hand I also think JSON is horrible, but there are plenty of developers who  
love it and want to use it for everything.


Frankly I'm far more interested in looking at the approaches people are  
using and trying to overcome the repetitive NotInventedHere, or at least  
get the *same* semantics instead of *roughly the same* as we currently  
have. I think achieving even that limited goal would be a far greater  
service to developers and therefore to their users than the meagre  
benefits that have been offered by the slight differences we have managed  
to build into each system so far.


cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: HTML as application manifest format

[Kornel Lesiński]

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

Processing of newlines and HTML in description member

[Kornel Lesiński]

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

[IndexedDB] Feature detection pattern for array key support

[Kyaw Tun]

Some browsers does not support array key. I use indexedDB.cmp([1, 2], [1,
2]). It works by getting error on not supported bowser. Is there a clear
hack to detect it?

Thanks,
Kyaw