[whatwg] whatwg Digest, Vol 103, Issue 51

Tue Oct 30 05:20:12 PDT 2012

SZs
--------------------------
Sent using BlackBerry

----- Original Message -----
From: whatwg-request at lists.whatwg.org [mailto:whatwg-request at lists.whatwg.org]
Sent: Tuesday, October 30, 2012 06:39 AM
To: whatwg at lists.whatwg.org <whatwg at lists.whatwg.org>
Subject: whatwg Digest, Vol 103, Issue 51

Send whatwg mailing list submissions to
	whatwg at 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 at lists.whatwg.org

You can reach the person managing the list at
	whatwg-owner at 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 at gmail.com>
To: WHAT-WG list <whatwg at whatwg.org>
Subject: [whatwg] Proposal for window.DocumentType.prototype.toString
Message-ID:
	<CAGFhi3_rQeLW9TDAZMndiXggpARQEtN7zQUqYySjZ6PbP1Fb_Q at 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 at MIT.EDU>
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Proposal for
	window.DocumentType.prototype.toString
Message-ID: <508F2AB9.6000408 at 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 at chromium.org>
To: Boris Zbarsky <bzbarsky at mit.edu>
Cc: whatwg <whatwg at lists.whatwg.org>
Subject: Re: [whatwg] Proposal for
	window.DocumentType.prototype.toString
Message-ID:
	<CANMdWTt7ZLxPLnmYUqOzV_WQH0RGm1N038ynk7O2S7SrkznAnQ at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Mon, Oct 29, 2012 at 6:17 PM, Boris Zbarsky <bzbarsky at 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 at hixie.ch>
To: WHAT-WG list <whatwg at whatwg.org>
Subject: Re: [whatwg] Proposal for
	window.DocumentType.prototype.toString
Message-ID: <Pine.LNX.4.64.1210300200370.5442 at 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 at 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 at peda.net>
To: whatwg at lists.whatwg.org
Subject: Re: [whatwg] Real-time thread support for workers
Message-ID: <508F9C54.1090506 at 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 at antplc.com>
To: <whatwg at whatwg.org>
Subject: Re: [whatwg] Proposal for
	window.DocumentType.prototype.toString
Message-ID: <gemini.mcpbdc009c2rk01s1.stewart.brodie at antplc.com>
Content-Type: text/plain; charset="windows-1252"

Johan Sundstr?m <oyasumi at 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 at gmail.com>
To: Ian Hickson <ian at hixie.ch>
Cc: whatwg at whatwg.org, Glenn Maynard <glenn at zewt.org>,	David Bruant
	<bruant.d at gmail.com>, Jonas Sicking <jonas at sicking.cc>,	Janusz Majnert
	<jmajnert at gmail.com>
Subject: Re: [whatwg] Real-time thread support for workers
Message-ID:
	<CAJhzemV5BsQCBfCbpSbLaOvg8M=CJVx96eriGus8nFLSC8je8w at mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

On Sat, Oct 27, 2012 at 3:14 AM, Ian Hickson <ian at 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 at 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.