[Bug 13792] Remove all notes about sharing the connection. It can't work since what's received may depend on the request. It's also not reasonable to buffer every event in case they have to be dispa

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13792

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||WONTFIX

--- Comment #1 from Ian 'Hixie' Hickson  2011-09-01 00:08:05 UTC 
---
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: The connections are only shared if HTTP semantics say that they're
shareable. If two EventSource objects to the same underlying URL are made in
identical circumstances at roughly the same time, I see no reason why a browser
should be disallowed from sharing the connection.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

[Bug 13984] New: Need a way to object detect binary support before connecting

[bugzilla]

http://www.w3.org/Bugs/Public/show_bug.cgi?id=13984

   Summary: Need a way to object detect binary support before
connecting
   Product: WebAppsWG
   Version: unspecified
  Platform: PC
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: WebSocket API (editor: Ian Hickson)
AssignedTo: i...@hixie.ch
ReportedBy: w3@martintribe.org
 QAContact: member-webapi-...@w3.org
CC: m...@w3.org, public-webapps@w3.org


The API needs to define a way for Javascript to object detect whether the
WebSocket API supports sending and receiving of binary data and this needs to
be exposed prior to initiating a connection (e.g. because sub-protocol and
extension settings may depend on whether binary data can be sent or not).

Chrome 14 and 15 and Firefox 6/7 support the new protocol and other updates to
the new API but don't actually support binary data sending/receiving yet.

Until the object is instantiated, the WebSocket objects looks the same for the
old API as for the new API.

I tried the following hack:

var wstest = new WebSocket('ws://localhost:57111');
if (typeof(wstest.binaryType) !== "undefined") {
...  // binary
} else {
...  // text only
}
wstest.close();
wstest = null;

However, that is insufficient for a few reasons:

- the spec allows for the UA to initiate a connection immediately in the
background (e.g. Chrome does this) which means an async error is trigger by
failure to connect.

- the spec is not crystal clear about what the behavior of binaryType is in the
case where binary data is not in fact supported. For example, in Chrome 14 and
15 binaryType is visible and set to "blob" by default and can be set to
"arraybuffer". However, binary data is not in fact supported.

- it's just plain hideous.

My suggestions:

- In addition to the readyState constants (CLOSED, CLOSING, etc), the
uninstantiated WebSocket object should also have the following constants: BLOB
and ARRAYBUFFER which are equal to "blob" and "arraybuffer" respectively. These
should only appear in the WebSocket object if those data types are actually
supported for sending and receiving. This is backwards compatible with the
current definition (i.e. you can do ws.binaryType = "blob"; or ws.binaryType =
WebSocket.BLOB);

- The spec should clarify that the binaryType field should only appear if
binary data is in fact supported (or alternately, it is there but should be
empty and throw an error if an attempt is made to set it).

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.

Re: HTMLElement.register--giving components tag names

[Sergey Ilinsky]

Referencing a note dated 2003 may not sound strong any more - web-based
applications (or to be more specific - their UI) have evolved significantly
since the date. Today limiting developers to an extremely low level markup
API, such as SVG or HTML only leads to huge, hardly manageable JavaScript UI
code in any more or less complex solution.

The need in custom markup that facilitates higher level UI technologies
abstractions is here. (Meaning - has been here. Since, say 2003)

As for searching engines "not capable of indexing applications" - this is in
no way a concern, I bet neither GMail, nor AdSense apps etc. have been
successfully indexed so far. Exposing data or electronic documents is
something else.

Sergey/

On 31 August 2011 09:00, Anne van Kesteren  wrote:

> On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney 
> wrote:
>
>> Thanks for reading this far! These proposals aren't formal or
>> detailed. I would love to get feedback as I try to nail down some
>> specifics.
>>
>
> The basic problem with this is that you get proprietary markup going over
> the wire:
>
> http://ln.hixie.ch/?start=**1064828134&count=1
>
> Having said that, I am not sure what the "correct" alternative would be.
> XBL (as Ian envisioned it anyway) was meant to enhance non-proprietary
> markup, not to let authors create novel constructs. Now you cannot stop
> authors from exploring novel constructs of course, but whether we should
> explicitly endorse it is another matter.
>
>
> --
> Anne van Kesteren
> http://annevankesteren.nl/
>
>

Re: HTMLElement.register--giving components tag names

[Dominic Cooney]

On Wed, Aug 31, 2011 at 1:38 PM, Erik Arvidsson  wrote:
> On Tue, Aug 30, 2011 at 22:33, Dominic Cooney  wrote:
>
>> You will notice that this says nothing about how prototypes are wired
>> up. It should. Maybe the argument to extend should have an optional
>> second field, proto, that specifies the new methods/getters/setters
>> that ContactPicker's prototype should introduce.
>>
>> This is not a general subtyping mechanism! It is only designed for
>> setting up subtypes of HTMLElement for use with register. When
>> ECMAScript and the DOM bindings are sufficiently aligned,
>> HTMLElement.register can be opened up to accept constructors defined
>> using ordinary ECMAScript mechanisms for subtyping DOM interfaces.
>> Scripts can continue to use extend (it is pretty succinct) or
>> constructors set up their own way.
>
> Providing a prototype is important.

So here’s a refinement. I will add this to the wiki:

interface ExtensibleElement {
  object extend(ElementRegisterOptions options) raises (DOMException);
}
HTMLElement implements ExtensibleElement;
…

[Callback]
interface ExtensionElementInitializer {
  void init(HTMLElement element);  // should this have a return value,
to allow replacement?
}

dictionary ElementRegisterOptions {
  ExtensionElementInitializer init;
  object? proto;  // ECMAScript-ism?
}

Author: If options.proto is specified,
HTMLElement.prototype.isPrototypeOf(options.proto) should be true, and
options.proto should not be a platform object, nor have a platform
object on the prototype chain.

UA: If options.proto is specified, and
HTMLElement.prototype.isPrototypeOf(options.proto) is false, or
options.proto is a platform object, or options.proto has a platform
object on the prototype chain, register may throw a TYPE_ERROR.

If options.proto is not specified, the resulting constructor’s
prototype property will be HTMLElement.prototype or
HTMLElement.prototype.isPrototypeOf(<>) will be
true. This object might have been synthesized by the UA.

UA: When the constructor is invoked, (same conditions on the proto as
before) the constructor may throw a TYPE_ERROR.

> For example I can imagine UI toolkits providing their own "base class"
> that all the custom elements extend.

That is most straightforward when you have

FancyWidgetBase : HTMLElement
FancyButton : FancyWidgetBase

It does not work so well when you want FancyButton to be a
HTMLButtonElement. Then you need a factory of FancyWidgetBases that
hook one up to HTMLButtonElement, HTMLDivElement, etc.

> Also, it seems essential to allow extending other things than just 
> HTMLElement.

Wearing my author hat, that sounds appealing. Browser internals may do
things like switch on an element’s tag name. It would need to start
consulting the table of extensions when it did that in order to
realize that x-fancy-button is a button element.

Re: xdash name prefixes (was Re: Component Model Update)

[Roland Steiner]

On Wed, Aug 31, 2011 at 12:57 PM, Dominic Cooney wrote:

> I think for convenience registration probably should be carried around
> with the component, because:
>
> 1. It is convenient for the author using the component.
>
> 2. If the component library reuses its own abstractions, it probably
> expects them to have a specific element name. Putting registration in
> the hands of the author using the component jeopardizes that.
>

That is actually a good point.


Something declarative like module imports and exports, with scoped
> renaming, for registered tag names would be nice. This avoids these
> two problems, and is pretty convenient (particularly if import * gets
> you all of the exports by default.)
>

Wouldn't that be effectively namespaces by another name/mechanism? Also,
there's probably a limit to how far renaming can avoid clashes, e.g., if a
sub-components can also be utilized by a page's author.

In any case, until modules become a reality I think teaching component
authors to use "pseudo-namespaces" (e.g., "x-rogersoft-button" vs.
"x-delilahsoft-button") for stuff that might clash is not unreasonable.


Cheers,

- Roland

Re: HTMLElement.register--giving components tag names

[Erik Arvidsson]

On Tue, Aug 30, 2011 at 22:33, Dominic Cooney  wrote:

> You will notice that this says nothing about how prototypes are wired
> up. It should. Maybe the argument to extend should have an optional
> second field, proto, that specifies the new methods/getters/setters
> that ContactPicker's prototype should introduce.
>
> This is not a general subtyping mechanism! It is only designed for
> setting up subtypes of HTMLElement for use with register. When
> ECMAScript and the DOM bindings are sufficiently aligned,
> HTMLElement.register can be opened up to accept constructors defined
> using ordinary ECMAScript mechanisms for subtyping DOM interfaces.
> Scripts can continue to use extend (it is pretty succinct) or
> constructors set up their own way.

Providing a prototype is important.

For example I can imagine UI toolkits providing their own "base class"
that all the custom elements extend.

Also, it seems essential to allow extending other things than just HTMLElement.

-- 
erik

Re: [XHR2] Blobs, names and FormData

[Charles Pritchard]

On 8/31/2011 10:57 AM, Jonas Sicking wrote:

On Wed, Aug 31, 2011 at 10:19 AM, Glenn Maynard  wrote:

On Wed, Aug 31, 2011 at 12:48 PM, Jonas Sicking  wrote:

Simple case:
var callback = function(blob) { xhr.send(blob); };
formData.toBlob(callback, 'multipart/form-data');

Several services require signed messages in the http header, the
scripting
environment needs access to the blob data in order to sign the message
body.

Neither multipart/form-data nor application/x-www-form-urlencoded
encoding is not slow, so there should be no need to make this an
asynchronous callback.

Sorry if this doesn't make sense as I havn't been following this closely
enough, but if the form contains a file, this will cause the file to be read
from disk immediately, creating the encoded blob in memory, right?  If it
may trigger I/O, it should be async, regardless of how expensive the
operation performed on the resulting data might be.

(It may be possible for implementations to create a Blob class that
generates the encoded form-data on demand, as async reads happen later on.
But, even if that's possible for form-data, it won't necessarily be for
other possible types passed to toBlob, eg. x-www-form-urlencoded.)

File attachments aren't submitted as part of
application/x-www-form-urlencoded encoding during form submission, so
I don't see why we should here. For multipart/form-data I think we
should always return a Blob which means that we wouldn't need to
actually read any contained blobs during encoding.


A Blob is not necessarily a file attachment, it could simply be a large 
string.

x-www-form-urlencoded would not serialize the mime type nor file name.

Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Tue, Aug 30, 2011 at 10:33 PM, Dominic Cooney  wrote:
> "Components" (see
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of
> what I mean) need to present an API to script. For example, a
> "contacts" component might want to expose a refresh() method that
> pulls new contacts from the server. Components also need to hook up
> internal behavior implemented in script; a split pane might need to
> hook up a mouse listener on its splitter before it can really behave
> like a split pane.
>
> In script widget libraries today (YUI, Closure, etc.) this is easy
> when the widget has been created from script: when the author calls
> the constructor/factory method/whatever the widget can create DOM,
> hook up event listeners, set up the prototype chain however it wants,
> etc.
>
> However things get really murky when authors start to use markup,
> because then the parser is creating elements that are at best only
> minimally functional until they're "enhanced." So today widget
> implementations need to handle enhancing an existing element;
> frameworks need to detect these unenhanced elements and invoke
> something to enhance them; and authors needs to debug this unholy mess
> when an unenhanced element escapes and their page breaks.
>
> Wouldn't it be nice if the browser made this problem go away?
>
> I think HTML itself shows us how life could be better: Consider the
> HTML video element. It looks like a "subtype" of HTML element, with
> all of the methods and attributes a HTML element has (via the
> prototype chain), and adds methods and attributes specific for doing
> video. When you do document.createElement('video') you get back an
> object that is ready to use. There's no step to "enhance" it. When you
> do p.innerHTML = "", you get a video
> player. There's no flash of unstyled content. If you clone it and
> insert the copy into the DOM again, all of the playback controls are
> still wired up and responsive.
>
> I'm proposing we add something that lets script extend the set of tag
> names, so there is less of a bright line between elements defined in
> the HTML spec and elements defined in script. Something like:
>
> HTMLElement.register('x-contacts', ContactPicker);
>
> The first argument is an element name. The second is a constructor
> function, whose prototype property points to an object which
> introduces the API for contacts (eg a refresh method) and is wired up
> to HTMLElement.prototype.
>
> When the parser encounters , it creates an object by
> calling the ContactPicker function as a constructor. The constructor
> can wire up any internal state it wants, like creating DOM and
> attaching event listeners. When a script later retrieves the element,
> say with document.querySelector('x-contacts'), the object created
> earlier with ContactPicker is what it gets back. Since the constructor
> is run as the parser is creating the element, there's no time when the
> unenhanced element is available to script.
>
> My proposal pretty much ends here: The component itself is just
> implemented with script, DOM and CSS. There are no special hooks for
> participating in layout (just use DOM and CSS) or form submission
> (just create form controls using DOM) or security (same origin policy
> still applies) or networking (just use WebSockets or XHR) or anything
> else. There is no magic, other than teaching the browser about the new
> tag name.
>
> I'm suggesting that all registered tag names have to start with x-.
> This is to give component authors a place to build without worrying
> about conflicting with future HTML specs; the HTML spec won't define
> elements with names starting with x-. (Component authors may chose x-
> names that conflict with each other, though.) People working on the
> HTML spec can study what kinds of components are popular in the wild
> and consolidate the best ideas into new HTML elements. Page authors
> can decide if and when to move their pages from their bespoke x-
> components to the HTML alternatives, which should be better.
>
> Pages that have to work in older browsers can use fallback content.
> (This is exactly what the HTML spec advises authors to do with the
> video element, incidentally.) In newer browsers the component script
> can remove or hide the fallback content.
>
> There's the question of what to do when there is a call to
> HTMLElement.register('x-contacts', …) at some point after an x-contact
> element has been parsed. We have to do something that makes sense for
> async scripts. I think the solution is to replace the element, and the
> recent discussion on this list about renameNode is interesting and
> relevant.
>
> One practical issue with this proposal is that creating a subtype of
> HTMLElement in script (ie defining the ContactPicker function in the
> above example) is hard/impossible. A couple of the problems are:
>
> - Defining a subtypes in JavaScript is hard to begin with: You need to
> create a function, and maybe set its object pr

Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Tue, Aug 30, 2011 at 10:33 PM, Dominic Cooney  wrote:
> "Components" (see
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases for examples of
> what I mean) need to present an API to script. For example, a
> "contacts" component might want to expose a refresh() method that
> pulls new contacts from the server. Components also need to hook up
> internal behavior implemented in script; a split pane might need to
> hook up a mouse listener on its splitter before it can really behave
> like a split pane.
>
> In script widget libraries today (YUI, Closure, etc.) this is easy
> when the widget has been created from script: when the author calls
> the constructor/factory method/whatever the widget can create DOM,
> hook up event listeners, set up the prototype chain however it wants,
> etc.
>
> However things get really murky when authors start to use markup,
> because then the parser is creating elements that are at best only
> minimally functional until they're "enhanced." So today widget
> implementations need to handle enhancing an existing element;
> frameworks need to detect these unenhanced elements and invoke
> something to enhance them; and authors needs to debug this unholy mess
> when an unenhanced element escapes and their page breaks.
>
> Wouldn't it be nice if the browser made this problem go away?
>
> I think HTML itself shows us how life could be better: Consider the
> HTML video element. It looks like a "subtype" of HTML element, with
> all of the methods and attributes a HTML element has (via the
> prototype chain), and adds methods and attributes specific for doing
> video. When you do document.createElement('video') you get back an
> object that is ready to use. There's no step to "enhance" it. When you
> do p.innerHTML = "", you get a video
> player. There's no flash of unstyled content. If you clone it and
> insert the copy into the DOM again, all of the playback controls are
> still wired up and responsive.
>
> I'm proposing we add something that lets script extend the set of tag
> names, so there is less of a bright line between elements defined in
> the HTML spec and elements defined in script. Something like:
>
> HTMLElement.register('x-contacts', ContactPicker);
>
> The first argument is an element name. The second is a constructor
> function, whose prototype property points to an object which
> introduces the API for contacts (eg a refresh method) and is wired up
> to HTMLElement.prototype.
>
> When the parser encounters , it creates an object by
> calling the ContactPicker function as a constructor. The constructor
> can wire up any internal state it wants, like creating DOM and
> attaching event listeners. When a script later retrieves the element,
> say with document.querySelector('x-contacts'), the object created
> earlier with ContactPicker is what it gets back. Since the constructor
> is run as the parser is creating the element, there's no time when the
> unenhanced element is available to script.
>
> My proposal pretty much ends here: The component itself is just
> implemented with script, DOM and CSS. There are no special hooks for
> participating in layout (just use DOM and CSS) or form submission
> (just create form controls using DOM) or security (same origin policy
> still applies) or networking (just use WebSockets or XHR) or anything
> else. There is no magic, other than teaching the browser about the new
> tag name.
>
> I'm suggesting that all registered tag names have to start with x-.
> This is to give component authors a place to build without worrying
> about conflicting with future HTML specs; the HTML spec won't define
> elements with names starting with x-. (Component authors may chose x-
> names that conflict with each other, though.) People working on the
> HTML spec can study what kinds of components are popular in the wild
> and consolidate the best ideas into new HTML elements. Page authors
> can decide if and when to move their pages from their bespoke x-
> components to the HTML alternatives, which should be better.
>
> Pages that have to work in older browsers can use fallback content.
> (This is exactly what the HTML spec advises authors to do with the
> video element, incidentally.) In newer browsers the component script
> can remove or hide the fallback content.
>
> There's the question of what to do when there is a call to
> HTMLElement.register('x-contacts', …) at some point after an x-contact
> element has been parsed. We have to do something that makes sense for
> async scripts. I think the solution is to replace the element, and the
> recent discussion on this list about renameNode is interesting and
> relevant.
>
> One practical issue with this proposal is that creating a subtype of
> HTMLElement in script (ie defining the ContactPicker function in the
> above example) is hard/impossible. A couple of the problems are:
>
> - Defining a subtypes in JavaScript is hard to begin with: You need to
> create a function, and maybe set its object pr

Re: xdash name prefixes (was Re: Component Model Update)

[Dominic Cooney]

I think for convenience registration probably should be carried around
with the component, because:

1. It is convenient for the author using the component.

2. If the component library reuses its own abstractions, it probably
expects them to have a specific element name. Putting registration in
the hands of the author using the component jeopardizes that.

However I don’t think the imperative API is right, or at least not
enough, for these reasons: (assuming you accept that registration
happens in the component library—the death before inconvenience
premise):

1. The imperative registration API is *not* OK for confined
components, because if you run script out of the library in your
context to do the registration, you are hosed.

2. There’s no way for the author to manage conflicts or namespace pollution.

Something declarative like module imports and exports, with scoped
renaming, for registered tag names would be nice. This avoids these
two problems, and is pretty convenient (particularly if import * gets
you all of the exports by default.)

Dominic

On Wed, Aug 31, 2011 at 10:54 AM, Roland Steiner
 wrote:
> On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth  wrote:
>>
>> Doesn't it seem more likely that the third-party will do the
>> registration in whatever script you include that implements the Like
>> button, or whatever?
>
> That's just a matter of convention, no? I don't think it's unreasonable to
> frame it as "in order to use a component you need to load its source and
> register a suitable element name for it.".
> OTOH, there's nothing to prevent a package from doing the registering in one
> go. But if such a package then really leads to a clash, I'd prefer to first
> ask the authors to sort it out.
>
> Cheers,
> - Roland

Re: Mouse Lock

[Glenn Maynard]

On Mon, Aug 29, 2011 at 2:29 AM, Vincent Scheib  wrote:

> I believe first developers seek a specifiable solution that will provide a
> consistent application experience on all platforms and API implementations.
>

Yes, the "raw input" method provides this.  (I don't like calling it that,
since it's not necessarily anything of the sort and it suggests that it's
lower level than it is, but I don't have another name off-hand to
distinguish these.)

 Finally, I believe that it is worthwhile to consider adding some rawer form
> of the input data if possible in a v2 implementation and or spec.
>

The "raw input" implementation requires a different interface.  What you
suggest would require implementing and supporting two completely different
approaches to delta input.  This seems shortsighted.

>
Movement values will stop when the cursor hits a screen edge.
>

This defeats the purpose.

I'm deferring consideration for higher resolution mice data and sampling
> frequency to a future version of this specification. This was discussed some
> in "Provide mouse deltas without hiding the cursor, alternatively provide a
> bounding rectangle for mouse". But a summary of my position is that:
> - Specification is difficult and may not be possible.
> - Implementation is more complex and doesn't seem justified yet.
>

As I pointed out before, both specification and implementation is simpler; a
laundry list of complexities go away.

- Graceful addition of more 'raw' data and higher sampling frequencies is
> possible. I'm not saying "We shouldn't implement raw data", but I am saying
> we should defer it.
>

I don't believe "graceful addition" is possible; an entirely separate
interface, using a separate event, would be necessary.  As a result, if this
approach is implemented, it'd be much less likely that the other would ever
happen.  Half-solutions have a tendency to prevent the creation of a full
solution, even when it's claimed beforehand that it's only being "deferred".

This was vaguely suggested in that no one made a clear proposal of what
> separate events would look like. click, down, and up events are needed. The
> current events use the MouseEvent type. I believe that for the same reason
> mousedown includes more context than just "the mouse button was pressed"
> that the mouse lock equivalent would too. Thus, the mouse lock version of
> click, down, and up events should contain .movementX/Y data.
>

This doesn't make sense to me.  Movement is unrelated to clicks.  There's no
need to have special "locked versions" for these events; there's no movement
data associated with a click.  If they had "movement" attributes, they would
always be zero.


If you want a concrete proposal, I'd start with something like this:

> When a delta input device is moved, fire an event named "mousedelta",
which bubbles and is cancelable, and uses the MouseDeltaEvent interface, at
the Window object.  The deltaX attribute must be set to the horizontal
distance moved, with positive values indicating motion to the right.  The
deltaY attribute must be set to the vertical distance moved, with positive
values indicating motion downwards. A delta value of 400 must indicate a
movement of one inch.
>
> interface MouseDeltaEvent : Event {
>   readonly attribute float deltaX;
>   readonly attribute float deltaY;
> };

The value of 400 DPI is suggested because, according to [1], that's the most
common resolution for mice.  Implementations scale values to that resolution
if necessary.  The interface uses floats, to support arbitrary-resolution
input.

[1] http://msdn.microsoft.com/en-us/library/ee418864%28v=vs.85%29.aspx

-- 
Glenn Maynard

RE: HTTP, websockets, and redirects

[Brian Raymor]

Hi Art,

I've updated the bug. Microsoft is fine with this new validation requirement. 
In the absence of other comments, I suggest that we update the draft and move 
on to Last Call.

...Brian


> -Original Message-
> From: Arthur Barstow [mailto:art.bars...@nokia.com]
> Sent: Monday, August 29, 2011 9:30 AM
> To: Brian Raymor
> Cc: ext Adam Barth; Gabriel Montenegro; Thomas Roessler; Salvatore Loreto;
> public-ietf-...@w3.org; WebApps WG; François Daoust; Eric Rescorla; Harald
> Alvestrand; Tobias Gondrom
> Subject: Re: HTTP, websockets, and redirects
> 
> Hi Brian, All - I just checked Bugzilla and besides the two editorial type 
> bugs
> (12510 and 13700), bug 13777 was filed against the Web Sockets API on
> August 15:
> 
>http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777
> 
> Currently, there have been no followup comments on 13777 and I think it
> should be addressed before the LC is published.
> 
> -Art Barstow
> 
> 
> On 8/25/11 2:31 PM, ext Brian Raymor wrote:
> >> On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow<
> art.bars...@nokia.com>   wrote:
> >>> Hi All,
> >>>
> >>> Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and
> >>> I would characterize them both as editorial [Bugs]. As such, the
> >>> redirect issue Thomas originally reported in this thread (see
> >>> [Head]) appears to be the only substantive issue blocking WSAPI Last
> Call.
> > As Art notes, the remaining bugs for the WebSocket API [WSAPI] can be
> characterized as editorial bugs.
> >
> > Microsoft has no objections to the requirement to fail non-101 responses
> such as redirects. If there are no further concerns in the working group
> related to this issue, then the current WebSocket API looks feature
> complete. I recommend that we publish a Last Call working draft and define a
> timetable to reach Candidate Recommendation.
> >
> >>> If anyone wants to continue discussing this redirect issue for
> >>> WSAPI, I recommend using e-mail (additionally, it may be useful to
> >>> also create a new bug in Bugzilla).
> >>>
> >>> As I understand it, the HyBi WG plans to freeze the Web Socket
> >>> Protocol spec "real soon now" (~August 19?).
> >>>
> >>> -Art Barstow
> >>>
> >>> [WSAPI] http://dev.w3.org/html5/websockets/
> >>> [Head]
> >>> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.h
> >>> t
> >>> ml
> >>> [Bugs]
> >>>
> http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advanced&shor
> >>> t _de
> >>>
> sc_type=allwordssubstr&short_desc=&product=WebAppsWG&component=
> We
> >>>
> bSocket+API+%28editor%3A+Ian+Hickson%29&longdesc_type=allwordssubs
> tr
> >>> bSocket+API+&
> >>>
> longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whit
> >>> e
> >>> boar
> >>>
> d_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&ke
> yw
> >>> o r
> >>>
> ds=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&em
> ailt
> >>>
> ype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=any
> e
> >>> x
> >>>
> act&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtyp
> e=
> >>> d
> >>> oit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-
> >>> 0=noop&value0-0-0=
> >>>
> >>>
> >>> On 7/27/11 8:12 PM, ext Adam Barth wrote:
>  On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro
>  wrote:
> > Thanks Adam,
> >
> > By discussed on some  mailing list, do you mean a *W3C* mailing list?
>  A quick search turned up this message:
> 
>  "But I'm totally fine with punting on this for the future and just
>  disallowing redirects on an API level for now."
> 
>  http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-
> March/031079.
>  html
> 
>  I started that thread at Greg Wilkins' recommendation:
> 
>  "This is essentially an API issue for the browser websocket object."
> 
>  http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html
> 
> > Also, allowing the users to handle these explicitly implies that
> > the API does
> >>> not mandate dropping the connection. Currently, the API does not
> >>> have this flexibility, nor does it allow other uses of non-101
> >>> codes, like for authentication. I understand the potential risks
> >>> with redirects in browsers, and I thought at one moment we were
> >>> going to augment the security considerations with your help for
> >>> additional guidance. If websec has already worked on similar
> >>> language in some draft that we could reuse that would be great, or,
> similarly, if we could work with you on that text.
>  We can always add support for explicitly following redirects in the
>  future.  If we were to automatically follow them today, we'd never
>  be able to remove that behavior by default.
> 
>  Adam
> 
> 
> >> -Original Message-
> >> From: Adam Barth [mailto:w...@adambarth.com]
> >> Sent: Sunday, July 24, 2011 13:35
> >> To: Thomas Roessler
> >> Cc: public-ietf-.

Re: [XHR2] Blobs, names and FormData

[Jonas Sicking]

On Wed, Aug 31, 2011 at 10:19 AM, Glenn Maynard  wrote:
> On Wed, Aug 31, 2011 at 12:48 PM, Jonas Sicking  wrote:
>>
>> > Simple case:
>> > var callback = function(blob) { xhr.send(blob); };
>> > formData.toBlob(callback, 'multipart/form-data');
>> >
>> > Several services require signed messages in the http header, the
>> > scripting
>> > environment needs access to the blob data in order to sign the message
>> > body.
>>
>> Neither multipart/form-data nor application/x-www-form-urlencoded
>> encoding is not slow, so there should be no need to make this an
>> asynchronous callback.
>
> Sorry if this doesn't make sense as I havn't been following this closely
> enough, but if the form contains a file, this will cause the file to be read
> from disk immediately, creating the encoded blob in memory, right?  If it
> may trigger I/O, it should be async, regardless of how expensive the
> operation performed on the resulting data might be.
>
> (It may be possible for implementations to create a Blob class that
> generates the encoded form-data on demand, as async reads happen later on.
> But, even if that's possible for form-data, it won't necessarily be for
> other possible types passed to toBlob, eg. x-www-form-urlencoded.)

File attachments aren't submitted as part of
application/x-www-form-urlencoded encoding during form submission, so
I don't see why we should here. For multipart/form-data I think we
should always return a Blob which means that we wouldn't need to
actually read any contained blobs during encoding.

/ Jonas

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Jonas Sicking]

On Wed, Aug 31, 2011 at 10:02 AM, Anne van Kesteren  wrote:
> On Wed, 31 Aug 2011 18:52:34 +0200, Jonas Sicking  wrote:
>>
>> Is this explicitly mentioned in the spec? Otherwise how will anyone be
>> able to take advantage of this fact?
>
> I guess we could explicitly mention it somewhere. On the other hand,
> everything has references and back-references and so far it seems to work
> fine for implementors (e.g. the new Event() feature is being picked up by
> implementors and so far the only question I got about it was about Web IDL
> dictionaries).
>
> Overall though I think it is somewhat distracting to put a 40 page
> specification in contrast with a 1000 page specification. This specification
> is very small and you can easily read/scan/search it through.

Indeed, the DOM-Core spec is quite graspable in its current state.

/ Jonas

Re: xdash name prefixes (was Re: Component Model Update)

[Roland Steiner]

On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth  wrote:

> Doesn't it seem more likely that the third-party will do the
> registration in whatever script you include that implements the Like
> button, or whatever?


That's just a matter of convention, no? I don't think it's unreasonable to
frame it as "in order to use a component you need to load its source and
register a suitable element name for it.".

OTOH, there's nothing to prevent a package from doing the registering in one
go. But if such a package then really leads to a clash, I'd prefer to first
ask the authors to sort it out.


Cheers,

- Roland

Re: Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

On Wed, Aug 31, 2011 at 10:29 AM, Dimitri Glazkov  wrote:
> I will write up the exact algorithm in a wiki shortly.

Here it is: http://wiki.whatwg.org/wiki/Component_Model_Progressive_Enhancement

:DG<

Custom tags over wire, was Re: HTMLElement.register--giving components tag names

[Dimitri Glazkov]

Splitting off to its own thread, because this deserves a good discussion.

On Wed, Aug 31, 2011 at 12:00 AM, Anne van Kesteren  wrote:
> On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney 
> wrote:
>>
>> Thanks for reading this far! These proposals aren't formal or
>> detailed. I would love to get feedback as I try to nail down some
>> specifics.
>
> The basic problem with this is that you get proprietary markup going over
> the wire:
>
> http://ln.hixie.ch/?start=1064828134&count=1

FWIW, I am in total agreement with this post. If the author requires a
UA to have a proprietary parser that has its own, separate means of
producing a valid DOM tree, you are so screwed.

>
> Having said that, I am not sure what the "correct" alternative would be. XBL
> (as Ian envisioned it anyway) was meant to enhance non-proprietary markup,
> not to let authors create novel constructs. Now you cannot stop authors from
> exploring novel constructs of course, but whether we should explicitly
> endorse it is another matter.

Yes, indeed. We are at the crossroads. The Web needs element behavior
attachment (http://wiki.whatwg.org/wiki/Behavior_Attachment) and the
ability to define new types elements, yet we are really afraid of
following through with that. But... are these fears rational? Let's
examine the them in detail.


Fear 1: Fallback bogeyman cometh.

 is no worse than  in every mechanical sense. In the absence of
definition for "x-accordion" (or Component Model plumbing), both mean
the same thing, both can be styled in the same way. One is
HTMLUnknownElement, the other is HTMLDivElement, and their API surface
is identical. So... no fallback problems.


Fear 2: Custom tags are confusing.

The  clearly identifies the type of the behavior expected
from the element, and conveys element behavior attachment nicely. On
the other hand,  implies decorator behavior
attachement, e.g. that removing the class value (and thus turning it
back into a vanilla ) is perfectly ok, which by the way, is
probably _not_ what the author of the Accordion component expects "in
real life". I mean, you can _make_ the author expect that, but that
seems like cruel and unusual punishment.

In other words -- it's quite the opposite. Custom tags are more
_clear_. In fact, they are as close as _saying_what_you_mean_ as it
gets.


Fear 3: Custom tags have no meaning.

Well, friends -- this train had left the station a long time ago. Alex
Russell joked once that you already totally can add custom tags in
HTML -- as long as you're Hixie. As HTML spec grows new tags, their
meaning is only captured in a written document that's meaningless to
the UAs that were built a priori. If anything, the Component Model
provides an explicit path _learn_ about the need for new elements in
the spec. Just grep the Web for "Weee!!

Becomes:

Weee!!

As soon as:
1) the definition of "x-awesome-button" is registered and;
2) the element is in the DOM tree.

I will write up the exact algorithm in a wiki shortly.

I hope this addressed our worst fears and some. I thereby declare that
we should stop being afraid and liberate ourselves from the burden of
custom tag anxiety. Long live custom tags!

:DG<

Re: [XHR2] Blobs, names and FormData

[Charles Pritchard]

On 8/31/2011 10:19 AM, Glenn Maynard wrote:

On Wed, Aug 31, 2011 at 12:48 PM, Jonas Sicking  wrote:

> Simple case:
> var callback = function(blob) { xhr.send(blob); };
> formData.toBlob(callback, 'multipart/form-data');
>
> Several services require signed messages in the http header, the
scripting
> environment needs access to the blob data in order to sign the
message body.

Neither multipart/form-data nor application/x-www-form-urlencoded
encoding is not slow, so there should be no need to make this an
asynchronous callback.


Sorry if this doesn't make sense as I havn't been following this 
closely enough, but if the form contains a file, this will cause the 
file to be read from disk immediately, creating the encoded blob in 
memory, right?  If it may trigger I/O, it should be async, regardless 
of how expensive the operation performed on the resulting data might be.


(It may be possible for implementations to create a Blob class that 
generates the encoded form-data on demand, as async reads happen later 
on.  But, even if that's possible for form-data, it won't necessarily 
be for other possible types passed to toBlob, eg. x-www-form-urlencoded.)


That sounds correct. Yes, a very large blob file, x-www-form-urlencoded 
would have to be
read through to determine the output blob size. I agree, that 
specialized Blob classes could cut-down/delay

memory copies.

CfC: obsolescence text for DOM 2 View Recommendation; deadline September 7

[Arthur Barstow]

In [1], Anne proposed some text be added to the top of the DOM 2 View 
REC [2] to signal the 'document' and 'defaultView' attributes are now 
defined in HTML5 and this Recommendation is now effectively obsolete. We 
discussed some updates to the proposed text in IRC [3] and we now 
propose the following text be added to this REC:


[[
Note: This paragraph is informative. This document is currently not 
maintained. The concepts this document defines are obsolete. The 
'document' and 'defaultView' attributes are defined in the HTML5 
specification with simplified semantics. The Web Applications WG 
encourages implementation of these concepts as defined by HTML5.

]]

If you have any comments, please send them by September 7.

-AB

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0454.html
[2] http://www.w3.org/TR/DOM-Level-2-Views/
[3] http://krijnhoetmer.nl/irc-logs/webapps/20110831

Re: [XHR2] Blobs, names and FormData

[Glenn Maynard]

On Wed, Aug 31, 2011 at 12:48 PM, Jonas Sicking  wrote:

> > Simple case:
> > var callback = function(blob) { xhr.send(blob); };
> > formData.toBlob(callback, 'multipart/form-data');
> >
> > Several services require signed messages in the http header, the
> scripting
> > environment needs access to the blob data in order to sign the message
> body.
>
> Neither multipart/form-data nor application/x-www-form-urlencoded
> encoding is not slow, so there should be no need to make this an
> asynchronous callback.
>

Sorry if this doesn't make sense as I havn't been following this closely
enough, but if the form contains a file, this will cause the file to be read
from disk immediately, creating the encoded blob in memory, right?  If it
may trigger I/O, it should be async, regardless of how expensive the
operation performed on the resulting data might be.

(It may be possible for implementations to create a Blob class that
generates the encoded form-data on demand, as async reads happen later on.
But, even if that's possible for form-data, it won't necessarily be for
other possible types passed to toBlob, eg. x-www-form-urlencoded.)

-- 
Glenn Maynard

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Anne van Kesteren]

On Wed, 31 Aug 2011 18:52:34 +0200, Jonas Sicking  wrote:

Is this explicitly mentioned in the spec? Otherwise how will anyone be
able to take advantage of this fact?


I guess we could explicitly mention it somewhere. On the other hand,  
everything has references and back-references and so far it seems to work  
fine for implementors (e.g. the new Event() feature is being picked up by  
implementors and so far the only question I got about it was about Web IDL  
dictionaries).


Overall though I think it is somewhat distracting to put a 40 page  
specification in contrast with a 1000 page specification. This  
specification is very small and you can easily read/scan/search it through.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Jonas Sicking]

On Wed, Aug 31, 2011 at 8:25 AM, Anne van Kesteren  wrote:
> I think defining all of these in one specification is fine. Currently the
> specification is only 37 pages when printed. That will certainly grow once
> we add ranges, examples, and more introductory text, but will also still be
> well below the larger specifications. (Jonas' concern is already addressed
> in the specification with notes that reference the other relevant places in
> case a feature (so far only some constructor methods on Document) is defined
> across sections.)

Is this explicitly mentioned in the spec? Otherwise how will anyone be
able to take advantage of this fact?

/ Jonas

Re: [XHR2] Blobs, names and FormData

[Jonas Sicking]

On Wed, Aug 31, 2011 at 12:07 AM, Charles Pritchard  wrote:
> On 8/30/2011 7:11 PM, Jonas Sicking wrote:
>>
>> On Tue, Aug 30, 2011 at 5:59 PM, Charles Pritchard
>>  wrote:
>>>
>>> On 8/30/11 5:52 PM, Jonas Sicking wrote:

 On Tue, Aug 30, 2011 at 3:26 PM, Charles Pritchard
  wrote:

> On 8/24/2011 11:56 PM, Charles Pritchard wrote:
>
>> On 8/24/11 11:36 PM, Jonas Sicking wrote:
>>
>>> On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchard
>>>  wrote:
>>>
>> Prpoposed:
>>
>> FormData output with the x-www-form-urlencoded mime type:
>> formData.toUrlEncodedBlob(xhr.send)
>>
>>
 [Supplemental] FormData
 void toMultipartBlob(in callback)
 void toUrlEncodedBlob(in callback)

> ...
>
>> xhr.send(formData) would be the same as:
>> formData.toMultipartBlob(function(blob) { xhr.send(blob); });
>>
>>
> Google's Picasa, and various other web apis accept multipart/related
> input.
> Given that we don't want a method for each output type supported, I
> think
> a
> generic method would better serve authors.
>
> [Supplemental] FormData
>  void toBlob(in FileCallback, in optional DOMString type, in any...
> args);
>
> The default type for FormData would be multipart/form-data.
> Vendors would be encouraged to support these, in addition:
> application/x-www-form-urlencoded
> multipart/related
>
 What is multipart/related? Is that something supported by browsers? It
 doesn't appear supported by gecko, and it's certainly not supported
 for form submission in Gecko.


>>> No, it's not supported by browser forms.
>>>
>>> I'm trying to extend the FormData object, because it's a handy object for
>>> building up POST types used with XHR.
>>> Since FormData supports Blob append, it'd be nice to support the various
>>> services that use types other than multipart/form-data.
>>>
>>> Currently, FormData is all or nothing... so when interfacing with various
>>> web services, I have to go back to re-creating the mime message from
>>> scratch. Not a big deal, but it's frustrating to recreate the FormData
>>> interface over-and over again.
>>>
>>> This could be easy, with an extended FormData:
>>>
>>> http://code.google.com/apis/picasaweb/docs/2.0/developers_guide_protocol.html#PostPhotos
>>>
>>> var n = new FormData(); n.append(blob)...; n.toBlob(function(message) {
>>> xhr.send(message); });
>>
>> It would make sense to me to add a getAsBlob function to FormData. We
>> could also add support for other types of encodings than
>> "multipart/form-data", either by using separate functions, or by using
>> arguments to functions.
>>
>> However in all cases it seems much simpler to simply use return values
>> rather than callbacks.
>>
>
> Encoding of a large blob might be a slow process, relative to the normal
> event loop.
>
> multipart/form-data is a good place to start.
>
> Simple case:
> var callback = function(blob) { xhr.send(blob); };
> formData.toBlob(callback, 'multipart/form-data');
>
> Several services require signed messages in the http header, the scripting
> environment needs access to the blob data in order to sign the message body.

Neither multipart/form-data nor application/x-www-form-urlencoded
encoding is not slow, so there should be no need to make this an
asynchronous callback.

/ Jonas

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

[Anne van Kesteren]

On Thu, 11 Aug 2011 12:28:56 +0200, Arthur Barstow   
wrote:
Before we publish a new WD of Anne's DOM spec, I would like comments on  
how the DOM specs should be organized. In particular: a) whether you  
prefer the status quo (currently that is DOM Core plus D3E) or if you  
want various additional features of DOM e.g. Traversal, Mutation Events,  
etc. to be specified in separate specs; and b) why. Additionally, if you  
prefer features be spec'ed separately, please indicate your willingness  
and availability to contribute as an editor vis-à-vis the editor  
requirements above.


If you look at the DOM model I think what turns out to be most closely  
tied are nodes and ranges. On top of that you have the modification model  
which spans both. Events and nodes are cross-dependent too. Traversal  
could be done separately, but is so small (and has no other dependencies)  
that it is not worth it. Given this scope I think we should call it DOM4.


I think defining all of these in one specification is fine. Currently the  
specification is only 37 pages when printed. That will certainly grow once  
we add ranges, examples, and more introductory text, but will also still  
be well below the larger specifications. (Jonas' concern is already  
addressed in the specification with notes that reference the other  
relevant places in case a feature (so far only some constructor methods on  
Document) is defined across sections.)


I also think it is a good idea as these features have cross-dependencies  
that are easier spotted and worked out when developed as a single coherent  
document.



Everything else that builds on top of this abstract model (such as parsing  
and serialization methods, UI events, etc.) can be developed separately.  
And probably should be as they have a lot of other dependencies that are  
not needed for the abstract model.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: Rescinding the DOM 2 View Recommendation?

[Arthur Barstow]

On 8/13/11 6:19 AM, ext Anne van Kesteren wrote:
On Thu, 11 Aug 2011 00:02:56 +0200, Doug Schepers  
wrote:
After discussion with PLH and Ian Jacobs, and I don't think it's 
necessary for us to go through the additional overhead of rescinding 
the DOM 2 View specification.


Instead, PLH and I support Anne's original proposal to simply update 
the status section of the spec to point people to the HTML5 spec.  We 
could add wording like:


[[
Updated definitions of the 'document' and 'defaultView' attributes 
are now defined by the HTML5 specification.  Other concepts in this 
specification may not be necessary for implementation in general user 
agents such as Web browsers.

]]

I don't object to rescinding it, I simply prefer the option with the 
least process necessary.


This works for me and is actually what we decided back in 2009 as 
Working Group and back then Ian Jacobs said it was okay


http://lists.w3.org/Archives/Public/public-webapps/2009OctDec/0454.html

so I am glad this is acceptable again. Lets do it.


Doug - do you know of any RECs that contain such text (that we can review)?

Anne, Ms2ger - would you please propose some text we can review?

-Thanks, AB

Re: [File API] Blob.slice()

[Anne van Kesteren]

On Wed, 31 Aug 2011 06:17:17 +0200, Arun Ranganathan   
wrote:

On 8/14/11 5:42 AM, Anne van Kesteren wrote:
Why does the slice() method use [TreatUndefinedAs=EmptyString]? Can it  
not just use the normal default handling? Also, if you do indeed want  
to use that saying "If the contentType parameter is undefined, let  
relativeContentType be set to the empty string." in the text is  
redundant and ought to be removed.


Default handling doesn't treat undefined as the empty string AFAICT.


Indeed. Why is the default handling not acceptable? TreatUndefinedAs seems  
more for legacy APIs, not new ones.




The redundancy is instructive.


Redundancy with the IDL is avoided in all specifications I know of. I  
think it should be here too.



The slice() method definition does not state what happens when the  
contentType parameter is neither the empty string nor a valid media  
type.


I'm not sure we need to mention this.  Developers can do things with  
this argument that could cause their Blob objects to be handled weirdly  
by downstream APIs (e.g. "foo-baz/bas").  I'm really not sure what  
exactly we can say here; I can put in a warning or note.


You need to say what user agents have to do when developers set it to  
"trala la" or some such. "foo/bar" is still a valid media type, "foo=bar"  
is not.



The definition of the slice() method is also very confusing with  
several MUST statements. I think it would be better if it were defined  
as a single algorithm in line with how we normally define methods.


It's defined as a single algorithm:

http://dev.w3.org/2006/webapi/FileAPI/#dfn-slice

and cribs from ECMAScript's definition of slice.  It's the only host  
object with a slice.


It still looks like several independent algorithms to me. There should be  
one that includes processing of the arguments.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [File API] FileList

[Anne van Kesteren]

On Wed, 31 Aug 2011 06:12:06 +0200, Arun Ranganathan   
wrote:

On 8/14/11 5:36 AM, Anne van Kesteren wrote:
I think FileList should talk less about selected files and more about  
being a collection or list of File objects. That way it can be reused  
in the future without people tripping over its current narrow  
definition.


It is a collection of File objects, but they must be user selected.   
HTMLInputElement and DataTransfer don't make a sufficient virtue of user  
selection, so I feel it useful to keep it a part of FileList.


Why must they be user selected? I do not think that will necessarily be  
true over time. And it also seems to put some kind of artificial  
constraint on UI that should not be there.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [File API] dependencies

[Anne van Kesteren]

On Wed, 31 Aug 2011 06:20:58 +0200, Arun Ranganathan   
wrote:

Done.


Thanks!

I noticed a few small things:

 * HTML5 should be without space
 * Progress Events is pointing to a dated version rather than the latest;  
Charles is also no longer an editor; 1.0 can be dropped



--
Anne van Kesteren
http://annevankesteren.nl/

[File API] Dereferencing Model for Blob URIs

[Anne van Kesteren]

This model should be rephrased a bit to make it more clear what the  
requirements are. E.g. I think if you use POST it should not be a MAY but  
a MUST that 500 is returned.


Also what are the security errors you can get a 500 for? Are they not  
handled by 403? I think handling them with 403 is counter to how they are  
handled elsewhere though. Usually any kind of error is handled as a  
generic network error. I think it might be better to simply use 200 if the  
method was GET and 500 for everything else. You should probably also state  
what needs to happen with user/password arguments and maybe add a note  
that request headers are ignored. Furthermore, it has a note of sorts that  
you can expect a Content-Type header in the response, but it should be  
more detailed about what getAllResponseHeaders() will return. I.e. give a  
more complete definition of the response.



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [File API] opaque string

[Anne van Kesteren]

On Wed, 31 Aug 2011 06:22:05 +0200, Arun Ranganathan   
wrote:

On 8/14/11 6:00 AM, Anne van Kesteren wrote:

Why can you not use characters legally allowed in IRIs?


You can; they have to be escaped.


Yeah sure, every URI is an IRI, but that is not what I am asking.


The bit on UUID should be turned into a note if it is non-normative  
instead of saying it is non-normative.


Done (with an Appendix).


Cool!


I also noticed that "Use Cases for a New Scheme" is actually only listing  
requirements, not use cases. Maybe it should be renamed?



--
Anne van Kesteren
http://annevankesteren.nl/

Re: [XHR2] Blobs, names and FormData

[Charles Pritchard]

On 8/30/2011 7:11 PM, Jonas Sicking wrote:

On Tue, Aug 30, 2011 at 5:59 PM, Charles Pritchard  wrote:

On 8/30/11 5:52 PM, Jonas Sicking wrote:

On Tue, Aug 30, 2011 at 3:26 PM, Charles Pritchard
  wrote:


On 8/24/2011 11:56 PM, Charles Pritchard wrote:


On 8/24/11 11:36 PM, Jonas Sicking wrote:


On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchard
  wrote:


Prpoposed:

FormData output with the x-www-form-urlencoded mime type:
formData.toUrlEncodedBlob(xhr.send)



[Supplemental] FormData
void toMultipartBlob(in callback)
void toUrlEncodedBlob(in callback)


...


xhr.send(formData) would be the same as:
formData.toMultipartBlob(function(blob) { xhr.send(blob); });



Google's Picasa, and various other web apis accept multipart/related
input.
Given that we don't want a method for each output type supported, I think
a
generic method would better serve authors.

[Supplemental] FormData
  void toBlob(in FileCallback, in optional DOMString type, in any...
args);

The default type for FormData would be multipart/form-data.
Vendors would be encouraged to support these, in addition:
application/x-www-form-urlencoded
multipart/related


What is multipart/related? Is that something supported by browsers? It
doesn't appear supported by gecko, and it's certainly not supported
for form submission in Gecko.



No, it's not supported by browser forms.

I'm trying to extend the FormData object, because it's a handy object for
building up POST types used with XHR.
Since FormData supports Blob append, it'd be nice to support the various
services that use types other than multipart/form-data.

Currently, FormData is all or nothing... so when interfacing with various
web services, I have to go back to re-creating the mime message from
scratch. Not a big deal, but it's frustrating to recreate the FormData
interface over-and over again.

This could be easy, with an extended FormData:
http://code.google.com/apis/picasaweb/docs/2.0/developers_guide_protocol.html#PostPhotos

var n = new FormData(); n.append(blob)...; n.toBlob(function(message) {
xhr.send(message); });

It would make sense to me to add a getAsBlob function to FormData. We
could also add support for other types of encodings than
"multipart/form-data", either by using separate functions, or by using
arguments to functions.

However in all cases it seems much simpler to simply use return values
rather than callbacks.



Encoding of a large blob might be a slow process, relative to the normal 
event loop.


multipart/form-data is a good place to start.

Simple case:
var callback = function(blob) { xhr.send(blob); };
formData.toBlob(callback, 'multipart/form-data');

Several services require signed messages in the http header, the 
scripting environment needs access to the blob data in order to sign the 
message body.

Re: HTMLElement.register--giving components tag names

[Anne van Kesteren]

On Wed, 31 Aug 2011 07:33:16 +0200, Dominic Cooney   
wrote:

Thanks for reading this far! These proposals aren't formal or
detailed. I would love to get feedback as I try to nail down some
specifics.


The basic problem with this is that you get proprietary markup going over  
the wire:


http://ln.hixie.ch/?start=1064828134&count=1

Having said that, I am not sure what the "correct" alternative would be.  
XBL (as Ian envisioned it anyway) was meant to enhance non-proprietary  
markup, not to let authors create novel constructs. Now you cannot stop  
authors from exploring novel constructs of course, but whether we should  
explicitly endorse it is another matter.



--
Anne van Kesteren
http://annevankesteren.nl/