Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu csh...@gmail.com wrote: But it appears to me we have to introduce another pair of coders, say BinaryDecoder/BinaryEncoder, in addition to TextDecoder/TextEncode since the signatures of the decode/encode functions are different. So TextDecoder is bytes to string and TextEncoder is string to bytes. If we always represent the base64-variant as a sequence of bytes the signature seems fine. If you want to get a string out of those bytes again you could utf-8 decode it for instance. I'd be interested in knowing what the level of interest is outside of Google for this feature. -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
Because I implemented MS-Office files manipulation in my browser-side XForms implementation, such TextDecoder and TextEncoder are very interesting. Alain Couthures agenceXML http://www.agencexml.com/xsltforms De : Anne van Kesteren Envoyé : mercredi 7 août 2013 06:28 À : Chang Shu Cc : WHATWG On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu csh...@gmail.com wrote: But it appears to me we have to introduce another pair of coders, say BinaryDecoder/BinaryEncoder, in addition to TextDecoder/TextEncode since the signatures of the decode/encode functions are different. So TextDecoder is bytes to string and TextEncoder is string to bytes. If we always represent the base64-variant as a sequence of bytes the signature seems fine. If you want to get a string out of those bytes again you could utf-8 decode it for instance. I'd be interested in knowing what the level of interest is outside of Google for this feature. -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Wed, Aug 7, 2013 at 11:55 AM, Alain Couthures alain.couthu...@agencexml.com wrote: Because I implemented MS-Office files manipulation in my browser-side XForms implementation, such TextDecoder and TextEncoder are very interesting. To be clear, they are part of http://encoding.spec.whatwg.org/ and implemented in various browsers already. I meant the base64 feature in particular (and maybe API-only true latin1). -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
Well, base64 support is also already required in XForms Specifications for encoding/decoding functions to be called by authors whenever they want and also used in custom multipart/related submission. -Alain De : Anne van Kesteren Envoyé : mercredi 7 août 2013 07:02 À : Alain Couthures Cc : Chang Shu; WHATWG On Wed, Aug 7, 2013 at 11:55 AM, Alain Couthures alain.couthu...@agencexml.com wrote: Because I implemented MS-Office files manipulation in my browser-side XForms implementation, such TextDecoder and TextEncoder are very interesting. To be clear, they are part of http://encoding.spec.whatwg.org/ and implemented in various browsers already. I meant the base64 feature in particular (and maybe API-only true latin1). -- http://annevankesteren.nl/
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On 8/7/2013 5:28 AM, Anne van Kesteren wrote: On Tue, Aug 6, 2013 at 9:48 PM, Chang Shu csh...@gmail.com wrote: But it appears to me we have to introduce another pair of coders, say BinaryDecoder/BinaryEncoder, in addition to TextDecoder/TextEncode since the signatures of the decode/encode functions are different. So TextDecoder is bytes to string and TextEncoder is string to bytes. If we always represent the base64-variant as a sequence of bytes the signature seems fine. If you want to get a string out of those bytes again you could utf-8 decode it for instance. I'd be interested in knowing what the level of interest is outside of Google for this feature. There are enough places in my code where being able to decode/encode base64 from a typed array is a necessary step that I added helper functions to do this locally, particularly when I am about to shove it through charset conversion as well. Eliminating a copy step would be useful, although I don't think I'm pushing enough data through this functions to make a noticeable performance difference. -- Beware of bugs in the above code; I have only proved it correct, not tried it. -- Donald E. Knuth E
Re: [whatwg] Should video controls generate click events?
On Tue, Aug 6, 2013 at 11:30 PM, Ian Hickson i...@hixie.ch wrote:
On Thu, 27 Jun 2013, Philip Jägenstedt wrote:
In a discussion about a click to play/pause feature for Opera on
Android, the issue of click event handlers came up.[1] The problem is
that pages can do things like this:
v.onclick = function() {
if (v.paused) {
v.play();
} else {
v.pause();
}
// no preventDefault()
}
I created a demo [2] and it is indeed the case that this makes video
controls unusable in both Presto and Chromium based browsers. Simon
Pieters has brought this up before, but the spec wasn't changed at that
point.[3]
While my demo may be on the hypothetical side, we do want users to be
able to bring up the native controls via a context menu and be able to
use them regardless of what the page does in its event handlers. So, I
request that the spec be explicit that interacting with the video
controls does not cause the normal script-visible events to be fired.
[1] https://codereview.chromium.org/17391015
[2] http://people.opera.com/~philipj/click.html
[3] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2011-June/031916.html
(search for As with the post Simon cites above)
I've made the spec say this is a valid (and recommended) implemenation
strategy.
The change http://html5.org/r/8134 looks good to me, thanks!
I filed a bug for Blink in
https://code.google.com/p/chromium/issues/detail?id=269454
--
Philip Jägenstedt
Re: [whatwg] XML data islands related question
On Tue, 6 Aug 2013, Jukka K. Korpela wrote: 2013-08-06 17:45, Ian Hickson wrote: If such an application needs some bulk of text data, it can be included e.g. in script type=text/plain.../script but not in a separate plain text file (included into the application distribution, along with other files) referred to via script src=.../script. This is a frustrating restriction and makes it more difficult to maintain and customize application. If an external plain text file could be used, the data content could be separately managed (requiring knowledge only about the format used). I'm not sure what you mean by application distribution. Why can't a text/plain file by included the same way an image/png file is included? It can be included as a file, but it cannot be used. I can't read it. That is the point. I can use an img element referring to an image file, but I cannot refer to a simple plain text file (or an XML file) in an HTML document in a manner that lets me process its content in scripting. I can only include it via iframe or object, but that's different from accessing its content. I don't understand why XHR doesn't work for you. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Window and WindowProxy
On Tue, 6 Aug 2013, Boris Zbarsky wrote: There are two somewhat-orthogonal concerns here: 1) Where do the security checks live? 2) Where do the indexed properties live? Oh, interesting. I hadn't considered moving the indexed properties, only moving the security checks. We could indeed move the indexed properties to WindowProxy, while leaving the security checks (which apply to non-indexed properties only) on Window. This would still address my concern, which is that if we move the security checks to WindowProxy, and then break the invariant whereby you can't actually get to a cross-origin Window directly, you would suddenly have a security hole. Would it address your concerns? (I'm not sure I 100% understand what those are yet, i.e. why you want this moved.) The difficulty with moving just the indexed properties are that length would now be on a different object than what it describes. Also, it would complicate the WindowProxy magic -- now, instead of it just being a proxy, it would be a proxy except for certain properties. Can you elaborate on what the problem is with the current approach? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] asynchronous JSON.parse and sending large structured data between threads without compromising responsiveness
On Tue, 6 Aug 2013, Boris Zbarsky wrote:
On 8/6/13 5:58 PM, Ian Hickson wrote:
Parsing is easy to do on a separate worker, because it has no
dependencies -- you can do it all in isolation.
Sadly, that may not be the [case].
Actual JS implementations have various thread-local data that objects
depend on (starting with interned property names), such that it's not
actually possible to create an object on one thread and use it on
another in many of them.
Yeah, the final step of parsing a JSON string might require sync access to
the target thread.
For instance, how would you serialize something as simple as the
following?
{
name: The One,
hp: 1000,
achievements: [achiever, overachiever, extreme overachiever]
// Length of the list is unpredictable
}
Why serialise it? If you want to post this across a MessagePort to a
worker, or back from a worker, why not just post it?
var a = { ... }; // from above
port.postMessage(a);
This in practice does some sort of serialization in UAs.
Indeed. My question was why do it manually.
why not just do this in C++?
Let's start with because writing C++ code without memory errors is
harder than writing JS code without memory errors?
I don't understand why you would constrain yourself to using Web APIs
in JavaScript to write a browser.
Simplicity of implementation? Sandboxing of the code? Eating your own
dogfood?
I guess that's a design choice.
But fundamentally, the needs of programmers writing Web browsers aren't
valid use cases for adding features to the Web platform. There's no need
for internal APIs to be interoperable.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] BinaryEncoding for Typed Arrays using window.btoa and window.atob
On Wed, Aug 7, 2013 at 4:21 PM, Chang Shu csh...@gmail.com wrote: If we plan to enhance the Encoding spec, I personally prefer a new pair of BinaryDecoder/BinaryEncoder, which will be less confusing than reusing TextDecoder/TextEncoder. I disagree with the idea of adding a new method for something that behaves exactly like something we already have, just to give it a different name. (It may not be too late to rename those functions, if nobody has implemented them yet, but I'm not convinced it's much of a problem.) -- Glenn Maynard
Re: [whatwg] Sandboxed IFrames and downloads.
On Sat, 2 Feb 2013, Mike West wrote: It's currently possible to force a download by serving a file with a Content-Disposition: attachment; filename=... header. Notably, this mechanism can be used to download a file with minimal user interaction by including the resource to be downloaded in an IFrame. This holds even for sandboxed IFrames, as demonstrated by http://lcamtuf.coredump.cx/sandboxed.html (clicking that link will download a file, fair warning). Note that this is an implementation choice. A browser could display an inline user interface (e.g. a button in the page, similar to network error pages) or floating user interface (e.g. a dialog, infobar, or download bar) offering the file for download, rather than forcing the download. It seems consistent with the general thought behind the `sandbox` attribute that it should control downloads as well as the bits it already locks down. I'd propose adjusting the spec to include a sandboxed downloads flag, which, when present, would block all downloads from inside the frame (or, perhaps only require user confirmation?). This restriction could be lifted via an 'allow-downloads' keyword, if present in the sandbox attribute's token list. I don't really understand why even without a sandbox attribute, a page should be allowed to force a download. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] HTML: A DOM attribute that returns the language of a node
On Aug 2, 2013, at 6:10 AM, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 2013-08-02 2:43, Ryosuke Niwa wrote: Are you saying that for HTML contenteditable-based editors that want to support drag-and-drop editing, they need to be able to annotate the outgoing HTML fragment with the effective language so that when it's embedded somewhere, the right fonts get used? Yes, but not just for drag and drop. This would mean that the editor would have to guess the language from the text or ask the user to specify it. This is not as unrealistic as it may first seem. Microsoft Word does such things, sometimes getting things right, often messing things up. It typically detects change of language too late, and often infers language from keyboard settings, making it rather impossible to use a multilingual keyboard easily. But regarding the effect of language markup on fonts, the effect is limited to situations where the font is not specified in a style sheet. This is a rather uncommon scenario these days; authors are more than eager to set fonts. Do you have actual statistics to support this point? As far as I checked, neither baidu.com nor yahoo.com.tw seems to explicitly specify a Chinese font. Also, I have just recently experienced the font type change on Gmail when I was conversing with a native Chinese speaker. Her mail client used Chinese fonts before Japanese fonts whereas mine had Japanese fonts before Chinese fonts. It is true that they might specify a font list where none of the fonts supports some characters that might be entered, and then a fallback font would be used. However, using “annotations” (presumably, lang attributes, along with extra span elements when needed) does not sound like a feasible approach to this. Whether it’s feasible or not, that’s what we have been doing due to the Han unification. If we could, we’ll undo the Han unification and use different glyphs for each character but we can’t do that at this point in time. - R. Niwa
Re: [whatwg] Window and WindowProxy
On 8/7/13 5:18 PM, Ian Hickson wrote: We could indeed move the indexed properties to WindowProxy, while leaving the security checks (which apply to non-indexed properties only) on Window. This would still address my concern, which is that if we move the security checks to WindowProxy, and then break the invariant whereby you can't actually get to a cross-origin Window directly If we break that invariant, fwiw, then I suspect we have much bigger problems. Would it address your concerns? I think it would be a step up from where we are right now... (I'm not sure I 100% understand what those are yet, i.e. why you want this moved.) Because the current spec effectively calls for the global to be a proxy-like object (or some sort of object that's not describable in ES spec terms at all, of course, but the idea of ES proxies is to be able to describe anything remotely sane). That's not actually compatible with ES because of how var needs to behave in global scope. So it seems to me that any implementor trying to implement this spec will go to their favorite ES implementation and discover that the spec cannot be implemented as written and must instead be mapped to some other conceptual model. After thinking about it for a bit, the only obvious way to avoid having proxy-like behavior on the Window is to put it all on WindowProxy, which _already_ has proxy-like behavior no matter what. At which point, I think we should spec it that way, for two reasons: 1) It reduces the burden on implementors trying to understand this part of the spec and map it to what ES will let them do. 2) It reduces the likelihood that some modification to ES or the Window/WindowProxy specs will in fact make things unimplementable altogether in the future. The difficulty with moving just the indexed properties are that length would now be on a different object than what it describes. I don't think that's a problem, honestly. length on a Window returns the number of child windows. An indexed access on a WindowProxy returns the corresponding child of its current Window. It seems fairly straightforward... Also, it would complicate the WindowProxy magic -- now, instead of it just being a proxy, it would be a proxy except for certain properties. Indeed. Of course WindowProxy is already not just a proxy: it doesn't transparently proxy enumeration or getOwnPropertyNames, for example. That's just not very clearly specified... Again, I think we should just clearly define the behavior of WindowProxy using the ES MOP primitives. Can you elaborate on what the problem is with the current approach? Does the above help? -Boris
Re: [whatwg] XML data islands related question
2013-08-08 0:08, Ian Hickson wrote: On Tue, 6 Aug 2013, Jukka K. Korpela wrote: 2013-08-06 17:45, Ian Hickson wrote: If such an application needs some bulk of text data, it can be included e.g. in script type=text/plain.../script but not in a separate plain text file (included into the application distribution, along with other files) referred to via script src=.../script. This is a frustrating restriction and makes it more difficult to maintain and customize application. If an external plain text file could be used, the data content could be separately managed (requiring knowledge only about the format used). I'm not sure what you mean by application distribution. Why can't a text/plain file by included the same way an image/png file is included? It can be included as a file, but it cannot be used. I can't read it. That is the point. I can use an img element referring to an image file, but I cannot refer to a simple plain text file (or an XML file) in an HTML document in a manner that lets me process its content in scripting. I can only include it via iframe or object, but that's different from accessing its content. I don't understand why XHR doesn't work for you. Because there is no server to talk to when you’re a truly local HTML5 application. Yucca
