- From: Ha Le <hle@rim.com>
- Date: Tue, 30 Oct 2012 12:20:12 +0000
- To: "whatwg@lists.whatwg.org" <whatwg@lists.whatwg.org>
- Cc: DSI DBA Notifications <dsi-dba-notifications@rim.com>
SZs -------------------------- Sent using BlackBerry ----- Original Message ----- From: whatwg-request@lists.whatwg.org [mailto:whatwg-request@lists.whatwg.org] Sent: Tuesday, October 30, 2012 06:39 AM To: whatwg@lists.whatwg.org <whatwg@lists.whatwg.org> Subject: whatwg Digest, Vol 103, Issue 51 Send whatwg mailing list submissions to whatwg@lists.whatwg.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org or, via email, send a message with subject or body 'help' to whatwg-request@lists.whatwg.org You can reach the person managing the list at whatwg-owner@lists.whatwg.org When replying, please edit your Subject line so it is more specific than "Re: Contents of whatwg digest..." When replying to digest messages, please please PLEASE update the subject line so it isn't the digest subject line. Today's Topics: 1. Proposal for window.DocumentType.prototype.toString (Johan Sundstr?m) 2. Re: Proposal for window.DocumentType.prototype.toString (Boris Zbarsky) 3. Re: Proposal for window.DocumentType.prototype.toString (Ojan Vafai) 4. Re: Proposal for window.DocumentType.prototype.toString (Ian Hickson) 5. Re: Real-time thread support for workers (Mikko Rantalainen) 6. Re: Proposal for window.DocumentType.prototype.toString (Stewart Brodie) 7. Re: Real-time thread support for workers (Jussi Kalliokoski) ---------------------------------------------------------------------- Message: 1 Date: Mon, 29 Oct 2012 17:58:45 -0700 From: Johan Sundstr?m <oyasumi@gmail.com> To: WHAT-WG list <whatwg@whatwg.org> Subject: [whatwg] Proposal for window.DocumentType.prototype.toString Message-ID: <CAGFhi3_rQeLW9TDAZMndiXggpARQEtN7zQUqYySjZ6PbP1Fb_Q@mail.gmail.com> Content-Type: text/plain; charset=windows-1252 Hi everybody! Serializing a complete HTML document DOM to a string is surprisingly hard in javascript. As a fairly seasoned javascript hacker I figured this might do it: document.doctype + document.documentElement.outerHTML It doesn't. No browser has a useful window.DocumentType.prototype that returns either the original document's <!DOCTYPE ...> before parsing ? or a semantically equivalent post-parsing one. Google Chrome shows one in its devtools, but seems not to export some way of getting at it to programmers. My proposal is we specify this more useful behaviour for javascript-running browsers, so it does become as simple as above. A rough sketch of how a polyfill might implement the latter window.DocumentType.prototype.toString: https://gist.github.com/3977584 Even as a polyfill, the above is rather limited, though: I believe only Firefox implements "internalSubset" today, and probably only in XML contexts. The most useful implementation would IMO be a native one that reproducing the doctype, as it was formatted in the source document. Thoughts? -- / Johan Sundstr?m, http://ecmanaut.blogspot.com/ ------------------------------ Message: 2 Date: Mon, 29 Oct 2012 21:17:45 -0400 From: Boris Zbarsky <bzbarsky@MIT.EDU> To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Proposal for window.DocumentType.prototype.toString Message-ID: <508F2AB9.6000408@mit.edu> Content-Type: text/plain; charset=windows-1252; format=flowed On 10/29/12 8:58 PM, Johan Sundstr?m wrote: > Serializing a complete HTML document DOM to a string is surprisingly > hard in javascript. I thought there were plans to put innerHTML on Document. Did that go nowhere? > As a fairly seasoned javascript hacker I figured > this might do it: > > document.doctype + document.documentElement.outerHTML This seems lossy in many cases (most obviously: when the HTML uses conditional comments, though there are also various XHTML-specific issues). > The most useful implementation would IMO be a native one > that reproducing the doctype, as it was formatted in the source > document. That might be worth doing independent of the serialization issue. -Boris ------------------------------ Message: 3 Date: Mon, 29 Oct 2012 18:34:24 -0700 From: Ojan Vafai <ojan@chromium.org> To: Boris Zbarsky <bzbarsky@mit.edu> Cc: whatwg <whatwg@lists.whatwg.org> Subject: Re: [whatwg] Proposal for window.DocumentType.prototype.toString Message-ID: <CANMdWTt7ZLxPLnmYUqOzV_WQH0RGm1N038ynk7O2S7SrkznAnQ@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Mon, Oct 29, 2012 at 6:17 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > On 10/29/12 8:58 PM, Johan Sundstr?m wrote: > >> Serializing a complete HTML document DOM to a string is surprisingly >> hard in javascript. >> > > I thought there were plans to put innerHTML on Document. Did that go > nowhere? There were plans to put in on DocumentFragment. But IIRC no other browser vendors voiced an interest and Hixie was opposed because he thought it would encourage people to do more string-based DOM building. The WebKit patch for this floundered as a result. I still think it's a good idea. ------------------------------ Message: 4 Date: Tue, 30 Oct 2012 02:10:58 +0000 (UTC) From: Ian Hickson <ian@hixie.ch> To: WHAT-WG list <whatwg@whatwg.org> Subject: Re: [whatwg] Proposal for window.DocumentType.prototype.toString Message-ID: <Pine.LNX.4.64.1210300200370.5442@ps20323.dreamhostps.com> Content-Type: text/plain; charset="utf-8" On Mon, 29 Oct 2012, Johan Sundstr?rote: > > Serializing a complete HTML document DOM to a string is surprisingly > hard in javascript. As a fairly seasoned javascript hacker I figured > this might do it: > > document.doctype + document.documentElement.outerHTML > > It doesn't. No browser has a useful window.DocumentType.prototype that > returns either the original document's <!DOCTYPE ...> before parsing ? > or a semantically equivalent post-parsing one. If you know the document is always going to be in the no-quirks mode, then you can just stick "<!DOCTYPE HTML>" at the start. If you need to be able to tell what the mode is but are ok with ignoring the "limited quirks" mode, then you can use document.compatMode to pick whether to use that string or none, as in: (document.compatMode == 'CSS1Compat' ? '<!DOCTYPE HTML>' : '') + document.documentElement.outerHTML That will drop any comment nodes around the root element, in case that matters. If you want to get the actual DOCTYPE strings, you can make a simple serialisation function for doctype nodes that uses the three attributes on that object to string together the full thing (much as you do in the polyfill you mentioned). > I believe only Firefox implements "internalSubset" today Since the "internal subset" has no meaning in text/html, that's ok if your goal is just to be semantically equivalent. > The most useful implementation would IMO be a native one that > reproducing the doctype, as it was formatted in the source document. What's your use case, exactly? On Mon, 29 Oct 2012, Boris Zbarsky wrote: > > I thought there were plans to put innerHTML on Document. Did that go > nowhere? Lack of implementor interest killed it a while ago. On Mon, 29 Oct 2012, Ojan Vafai wrote: > On Mon, Oct 29, 2012 at 6:17 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: > > > > I thought there were plans to put innerHTML on Document. Did that go > > nowhere? > > There were plans to put in on DocumentFragment. That was a different plan, but yes, there have also been proposals to do that. This was in the context of templates; a better solution to which has since been worked on in public-webapps. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' ------------------------------ Message: 5 Date: Tue, 30 Oct 2012 11:22:28 +0200 From: Mikko Rantalainen <mikko.rantalainen@peda.net> To: whatwg@lists.whatwg.org Subject: Re: [whatwg] Real-time thread support for workers Message-ID: <508F9C54.1090506@peda.net> Content-Type: text/plain; charset=ISO-8859-1 Ian Hickson, 2012-10-27 03:14 (Europe/Helsinki): > On Thu, 9 Aug 2012, Jussi Kalliokoski wrote: >> >> On W3C AudioWG we're currently discussing the possibility of having web >> workers that run in a priority/RT thread. This would be highly useful >> for example to keep audio from glitching even under high CPU stress. >> >> Thoughts? Is there a big blocker for this that I'm not thinking about or >> has it just not been discussed yet? (I tried to search for it, but >> didn't find anything) > > I think it's impractical to give Web authors this kind of control. User > agents should be able to increase the priority of threads, or notice a > thread is being used for audio and start limiting its per-slice CPU but > increasing the frequency of its slices, but that should be up to the UA, > we can't possibly let Web authors control this, IMHO. Would it be possible to allow web site to request high priority / RT on the expense of getting explicitly limited time slice? For example, API could be something like setMaxLatency(latency) where latency is desired maximum latency in ns. The return value could be maximum time slice in ns. If the worker (repeatedly) went over it maximum time slice, the UA should then revoke the high priority / RT scheduling from said worker and post some kind of event to worker to let it know about the issue. This would prevent any RT worker from hogging the CPU 100% but any well written worker code could be run with very low latency. Notice that the worker can only request desired latency and UA will then tell how much CPU time the worker is allowed to use each slice. The UA should simply return zero if the requested latency is too low to implement. (In this case, the worker would logically always overrun its time sclice and would be re-scheduled back to normal latency.) -- Mikko ------------------------------ Message: 6 Date: Tue, 30 Oct 2012 10:20:00 +0000 From: Stewart Brodie <stewart.brodie@antplc.com> To: <whatwg@whatwg.org> Subject: Re: [whatwg] Proposal for window.DocumentType.prototype.toString Message-ID: <gemini.mcpbdc009c2rk01s1.stewart.brodie@antplc.com> Content-Type: text/plain; charset="windows-1252" Johan Sundstr?m <oyasumi@gmail.com> wrote: > Hi everybody! > > Serializing a complete HTML document DOM to a string is surprisingly > hard in javascript. Does XMLSerializer().serializeToString(document) not meet your requirement? -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited ------------------------------ Message: 7 Date: Tue, 30 Oct 2012 12:39:22 +0200 From: Jussi Kalliokoski <jussi.kalliokoski@gmail.com> To: Ian Hickson <ian@hixie.ch> Cc: whatwg@whatwg.org, Glenn Maynard <glenn@zewt.org>, David Bruant <bruant.d@gmail.com>, Jonas Sicking <jonas@sicking.cc>, Janusz Majnert <jmajnert@gmail.com> Subject: Re: [whatwg] Real-time thread support for workers Message-ID: <CAJhzemV5BsQCBfCbpSbLaOvg8M=CJVx96eriGus8nFLSC8je8w@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 On Sat, Oct 27, 2012 at 3:14 AM, Ian Hickson <ian@hixie.ch> wrote: > On Thu, 9 Aug 2012, Jussi Kalliokoski wrote: > > > > On W3C AudioWG we're currently discussing the possibility of having web > > workers that run in a priority/RT thread. This would be highly useful > > for example to keep audio from glitching even under high CPU stress. > > > > Thoughts? Is there a big blocker for this that I'm not thinking about or > > has it just not been discussed yet? (I tried to search for it, but > > didn't find anything) > > I think it's impractical to give Web authors this kind of control. User > agents should be able to increase the priority of threads, or notice a > thread is being used for audio and start limiting its per-slice CPU but > increasing the frequency of its slices, but that should be up to the UA, > we can't possibly let Web authors control this, IMHO. > You're right, I agree. I think the user agent should stay on top of the situation and monitor the CPU usage and adjust the priority accordingly. However, I think the feasible options for getting the benefits of high priority when needed are either a) that we treat the priority the developer asks a request rather than a command, or b) the user agent detects the intent (in the case of audio I think it'd be fairly simple right now) and decides a suitable priority while adjusting it if necessary. To me, b) seems like the best approach to take, although both approaches have the advantage that they don't guarantee anything and are thus more amendable. > On Thu, 9 Aug 2012, Jussi Kalliokoski wrote: > > > > Yes, this is something I'm worried about as well. But prior work in > > native applications suggests that high priority threads are hardly ever > > abused like that. > > Native apps and Web apps aren't comparable. Native apps that the user has > decided to install also don't arbitrarily reformat the user's disk or > install key loggers, but I hope you agree that we couldn't let Web authors > do those things. > > The difference between native apps and Web apps is that users implicitly > trust native app authors, and therefore are (supposed to be) careful about > what software they install. However, on the Web, users do not have to be > (anywhere near as) careful, and so they follow arbitrary links. Trusted > sites get hijacked by hostile code, users get phished to hostile sites, > trolls point users on social networks at hostile sites. Yet, when all is > working as intended (i.e. modulo security bugs), the user is not at risk > of their machine being taken down. > > If we allow sites to use 100% CPU on a realtime thread, then this changes, > because untrusted hostile sites actually _can_ cause harm. > Very true, it can indeed be used to cause harm, and we should not allow that. I ignored this because I was thinking about attack vectors as a bidirectional thing (someone loses, someone gains), and I couldn't think of a way the attacker would benefit from freezing random users' computing devices. But this approach admittedly doesn't work that well on the web. > The way the Web platform normally gets around this is by having the Web > author describe to the UA what the author wants, declaratively, and then > having the UA take care of it without running author code. This allows the > UA to make sure it can't be abused, while still having good performance or > security or whatnot. In the case of Web audio, the way to get sub-80ms > latency would be say "when this happens (a click, a collision), do this > (a change in the music, a sound effect)". This is non-trivial to specify, > but wouldn't run the risk of hostile sites harming the user. Indeed it is non-trivial to specify, and while the Web Audio API attempts to do this, it can't possibly cover all use cases without custom processing in place, the spec is already huge and only addresses a limited set of use cases efficiently. When the use case requires the developer to do custom processing, it shouldn't cause the developer to lose all the advantage from having the rest of the audio graph in a real time thread. Currently it does, because the JS processing runs in a non-RT thread, and the results would be too unpredictable if the RT audio thread waited for the non-RT JS thread, so the current approach is to instead buffer up the input for JS, send it in for processing and apply it for the next round, which means that adding a custom processing node to the graph introduces the latency of at least the buffer size of that custom processing node. Cheers, Jussi ------------------------------ _______________________________________________ whatwg mailing list whatwg@lists.whatwg.org http://lists.whatwg.org/listinfo.cgi/whatwg-whatwg.org End of whatwg Digest, Vol 103, Issue 51 *************************************** --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.
Received on Tuesday, 30 October 2012 12:20:55 UTC