https://www.w3.org/Bugs/Public/show_bug.cgi?id=15059
Summary: Hi this the first test of my html5.
Product: WebAppsWG
Version: unspecified
Platform: Other
URL: http://www.whatwg.org/specs/web-apps/current-work/#top
OS/Version: other
On Sun, 04 Dec 2011 21:38:53 +0100, Bjoern Hoehrmann derhoe...@gmx.net
wrote:
I did not reverse-engineer the current proposal, but my impression is it
would handle text and json differently with respect to the Unicode
signature. I do not think that would be particularily desirable if true.
On Fri, 02 Dec 2011 14:00:26 +0100, Anne van Kesteren ann...@opera.com
wrote:
I tied it to UTF-8 to further the fight on encoding proliferation and
encourage developers to always use that encoding.
FYI, I also tied it to ECMAScript's definition of JSON, which has some
restrictions in place
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15059
Art Barstow art.bars...@nokia.com changed:
What|Removed |Added
Status|NEW |RESOLVED
What do you mean by treat content that clearly is UTF-32 as
UTF-16-encoded? Do you mean interpreting it as a sequence of unsigned
shorts? That would be a direct violation of the semantics of UTF-32, would
it not?
I'm not advocating the use of UTF-32 for interchange, but it does have the
advantage
* Glenn Adams wrote:
What do you mean by treat content that clearly is UTF-32 as
UTF-16-encoded? Do you mean interpreting it as a sequence of unsigned
shorts? That would be a direct violation of the semantics of UTF-32, would
it not?
Consider you have
...
Content-Type:
As discussed mutation observers would be best defined in the DOM. The DOM
is discussed on www-...@w3.org:
http://lists.w3.org/Archives/Public/www-dom/ (I bcc'd public-webapps just
in case anyone missed this.)
I think I now defined the last hook needed for mutation observers,
replace all.
The spec for resource sharing never discusses a status code for a
failed. It just says, 'terminate'.
To me, this suggests that, if there is no other OPTIONS processing
going on, the net result will be a NOT FOUND.
For that matter, it occurs to me, even if the entire preflight is a
success, the
On Mon, 05 Dec 2011 16:42:54 +0100, Benson Margulies
bimargul...@gmail.com wrote:
The spec for resource sharing never discusses a status code for a
failed. It just says, 'terminate'.
To me, this suggests that, if there is no other OPTIONS processing
going on, the net result will be a NOT
The spec for resource sharing never discusses a status code for a
failed. It just says, 'terminate'.
To me, this suggests that, if there is no other OPTIONS processing
going on, the net result will be a NOT FOUND.
For that matter, it occurs to me, even if the entire preflight is a
success,
On Mon, 05 Dec 2011 16:57:17 +0100, Benson Margulies
bimargul...@gmail.com wrote:
That's on the client side, isn't it?. I'm worried about the resource
side. On the resource side, what HTTP status code should be coming
back from server to client for a preflight when the server has no
other
In the example you give, there is consistency between the content metadata
(charset param) and the content itself (as determined by sniffing). So why
would both the metadata and content be ignored?
If there were an inconsistency (but there isn't) then [1] would apply, in
which case the metadata
On Sun, 4 Dec 2011, Bjoern Hoehrmann wrote:
The fight here is for standards.
The fight, if you want to characterise it as such, is for
interoperability, not standards. Standards are just a tool we use today
for that purpose.
For these purposes, we can ignore UTF-32. It's poorly implemented
On Mon, Dec 5, 2011 at 11:12 AM, Glenn Adams gl...@skynav.com wrote:
In the example you give, there is consistency between the content metadata
(charset param) and the content itself (as determined by sniffing). So why
would both the metadata and content be ignored?
Because in the real
On Mon, Dec 5, 2011 at 1:00 PM, Glenn Adams gl...@skynav.com wrote:
[2] http://www.w3.org/TR/charmod/#C030
No, it wouldn't. That doesn't say that UTF-32 must be recognized.
You misread me. I am not saying or supporting that UTF-32 must be
recognized. I am saying that MIS-recognizing
Let me choose my words more carefully.
A browser may recognize UTF-32 (e.g., in a sniffer) without supporting it
(either internally or for transcoding into a different internal encoding).
If the browser supports UTF-32, then step (2) of [1] applies.
[1]
On Mon, 5 Dec 2011, Glenn Adams wrote:
I see the problem now. It seems that the table in step (4) should be
changed to interpret an initial FF FE as UTF-16BE only if the following
two bytes are not 00.
The current text is intentional. UTF-32 is explicitly not supported by the
HTML
On Mon, Dec 5, 2011 at 3:15 PM, Glenn Adams gl...@skynav.com wrote:
But, if the browser does not support UTF-32, then the table in step (4) of
[1] is supposed to apply, which would interpret the initial two bytes FF FE
as UTF-16LE according to the current language of [1], and further, return a
The problem as I see it is that the current spec text for charset detection
effectively *requires* a browser that does not support UTF-32 to
explicitly ignore content metadata that may be correct (if it specifies
UTF-32 as charset param), and further, to explicitly mis-label such content
as
On Mon, 5 Dec 2011, Glenn Adams wrote:
The problem as I see it is that the current spec text for charset
detection effectively *requires* a browser that does not support
UTF-32 to explicitly ignore content metadata that may be correct (if it
specifies UTF-32 as charset param), and further,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=10623
Cameron McCormack c...@mcc.id.au changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Greetings all,
As you maybe all aware, I've been working with developers of
CKEditor, TinyMCE, and Google Docs along with developers from WebKit,
Mozilla, and Opera on new UndoManager and DOM Transaction
specificationhttp://rniwa.com/editing/undomanager.html for
the last several months. And it's
22 matches
Mail list logo
