Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus

[Simon Pieters]

On Wed, 06 Mar 2013 18:55:27 +0100, Ian Hickson  wrote:


On Wed, 6 Mar 2013, Simon Pieters wrote:
On Mon, 14 Jan 2013 09:40:56 +0100, Henri Sivonen   
wrote:


> Would it be terrible to make attempts to mutate the 'is' attribute
> throw thereby teaching authors who actually try to mutate it that it's
> not mutable?

We already have several attributes that are immutable but don't throw or
anything when they're changed.

e.g. 

Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus

[Ian Hickson]

On Wed, 6 Mar 2013, Simon Pieters wrote:
> On Mon, 14 Jan 2013 09:40:56 +0100, Henri Sivonen  wrote:
> 
> > Would it be terrible to make attempts to mutate the 'is' attribute 
> > throw thereby teaching authors who actually try to mutate it that it's 
> > not mutable?
> 
> We already have several attributes that are immutable but don't throw or 
> anything when they're changed.
> 
> e.g. 

Re: [whatwg] We should not throw DOM Consistency and Infoset compatibility under the bus

[Simon Pieters]

On Mon, 14 Jan 2013 09:40:56 +0100, Henri Sivonen  wrote:


Would it be terrible to make attempts to mutate the 'is' attribute
throw thereby teaching authors who actually try to mutate it that it's
not mutable?


We already have several attributes that are immutable but don't throw or  
anything when they're changed.


e.g. 

Re: [whatwg] Adding a btoa overload that takes Uint8Array

[Mark Watson]

Whilst on the topic of base64, has anyone considered adding support for 
base64url ?

…Mark

On Mar 4, 2013, at 10:29 AM, Kenneth Russell wrote:

> On Mon, Mar 4, 2013 at 10:04 AM, Joshua Bell  wrote:
>> On Mon, Mar 4, 2013 at 9:09 AM, Boris Zbarsky  wrote:
>> 
>>> The problem I'm trying to solve is sending Unicode text to consumers who
>>> need base64-encoded input.  Right now the only "sane" way to do it (and I
>>> quote "sane" for obvious reasons) is something like the example at
>>> https://developer.mozilla.org/**en-US/docs/DOM/window.btoa#**
>>> Unicode_Strings
>>> 
>>> It seems like it would be better if the output of a TextEncoder could be
>>> passed directly to btoa.  But for that we need an overload of btoa that
>>> takes a Uint8Array.
>>> 
>> 
>> FYI, I believe the last iteration on this topic ended with this message:
>> 
>> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-June/036372.html
>> 
>> i.e. consensus that base64 should stay out of the Encoding API, but that it
>> would be nice to have some form of base64 / Typed Array conversion API. But
>> there were no concrete proposals beyond my strawman in that post.
>> 
>> So: agreed, have at it!
> 
> Yes, adding an overload of btoa taking Uint8Array sounds good.
> 

Re: [whatwg] Fetch: Origin header

[Anne van Kesteren]

On Wed, Mar 6, 2013 at 2:46 PM, Anne van Kesteren  wrote:
> So HTML's "potentially CORS-enabled fetch" is incompatible with 
> XMLHttpRequest.

Turns out the wonderful browsers are not implementing XMLHttpRequest!
So XMLHttpRequest could do the same as HTML's "potentially
CORS-enabled fetch" I think.

http://dump.testsuite.org/fetch/xhr.html

Unless PHP does not expose Origin under HTTP_ORIGIN in $_SERVER as one
would expect...


-- 
http://annevankesteren.nl/

[whatwg] Fetch: Origin header

[Anne van Kesteren]

It seems we have a bunch of different policies for setting the Origin header :-(

XMLHttpRequest always sets it to the given value.

HTML's "fetch" only sets it to a non-null value if a from parameter is passed.

HTML's "potentially CORS-enabled fetch" seems to never invoke "fetch"
with a from parameter except indirectly via CORS' cross-origin
request.

CORS' cross-origin request always sets Origin to a given value.

So HTML's "potentially CORS-enabled fetch" is incompatible with XMLHttpRequest.


I've been trying to reconcile this mess in a draft at
http://html5.org/temp/fetch.html but I really wonder at this point
what is required and what is not. It would be really annoying I think
if we really required quite that many different ways of doing the same
thing.


-- 
http://annevankesteren.nl/