We have fix the problem: the encoding file was not in the correct path before,
so "macintosh" had not been registered in function registrar(standardName,
standardName). We locate the encoding file to the right place and it works now.
I am sorry it's my fault, some careless. And thank you very m
You could aid discoverability -- and programming -- by providing a set of
enumerated constants on the XHR constructor, much like the Node constructor
provides for NodeTypes.
Another option would be to throw an exception when setting responseType to an
unsupported value.
Geoff
On Oct 25, 2010,
True, it's not as simple as checking for the existence of an attribute, but
it could throw an exception. It seems like having both asBlob and
asArrayBuffer also creates the possibility of bad combinations of settings
which could get confusing, especially if more types are added in the future.
Chri
How do you address the discoverability issue that I raised? asBlob and
asArrayBuffer have the benefit of being detectable at runtime. but, a
settable responseType does not support detection of supported values.
-Darin
On Mon, Oct 25, 2010 at 2:54 PM, Chris Rogers wrote:
> passing "undefined
passing "undefined" as the 4th and 5th arguments seems pretty clunky to me.
Since, we already have an "asBlob" attribute, then "asArrayBuffer" like
Darin suggests seems like it might be better. However, then we can get into
cases where both "asBlob" and "asArrayBuffer" are set, and this problem
w
25.10.2010, в 12:34, Chris Marrin написал(а):
>> request.open("GET", "data.xml", true, "Text");
>> request.open("GET", "data.xml", true, "XML");
>> request.open("GET", "data.xml", true, "Bytes");
>
> I'd sure like to try to avoid an explosion in the API. I like Geoff's
> suggestion of specifyin
On Mon, Oct 25, 2010 at 12:34 PM, Chris Marrin wrote:
>
> On Oct 25, 2010, at 12:22 PM, Darin Fisher wrote:
>
> The solution for .responseBlob was to add an .asBlob attribute that would
> need to be set to true before calling .send(). We could do the same for
> .responseArrayBuffer.
>
> -Darin
>
On Oct 25, 2010, at 12:22 PM, Darin Fisher wrote:
> The solution for .responseBlob was to add an .asBlob attribute that would
> need to be set to true before calling .send(). We could do the same for
> .responseArrayBuffer.
>
> -Darin
>
>
> On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen
The solution for .responseBlob was to add an .asBlob attribute that would
need to be set to true before calling .send(). We could do the same for
.responseArrayBuffer.
-Darin
On Mon, Oct 25, 2010 at 12:17 PM, Geoffrey Garen wrote:
> Hi Chris.
>
> I like the efficiency of this approach. And I
Hi Chris.
I like the efficiency of this approach. And I agree with your premise that a
developer will probably only want one type of data (raw, text, or XML) per
request, and not more than one.
My biggest concern with this idea is that there's nothing obvious about the API
pattern of three pro
24.10.2010, в 23:48, 江南小白 написал(а):
> addToTextEncodingNameMap() is called in registerExtendedEncodingNames() in
> TextCodecICU.cpp:
> registrar("macroman", "macintosh");
This is something we have in webkit.org trunk, do you have any local
modifications to these files?
ICU has an
11 matches
Mail list logo
