Le 28/11/2017 à 00:48, Jonathan Zuckerman a écrit :
You’re probably aware there are libraries that offer functionality of this
sort (debounce and throttle in underscore/lodash is the one I’m most
familiar with) and the web community seems content to add a small
dependency when such functionality
Le 27/02/2015 15:54, David Bruant a écrit :
Does the spec mandates the order of resource loading between parent
and iframe?
If so, is it also the case for sandboxed iframes?
If not, then browsers have enough liberty today to prioritize parent's
resource loading over iframe without the need
Le 27/02/2015 17:27, David Håsäther a écrit :
On Fri, Feb 27, 2015 at 4:37 PM, David Bruant bruan...@gmail.com wrote:
You said that you got feedback from someone asking for this.
What is the behavior they currently implement?
Since I'm one of the people Anne talked to, I can expand a bit
Le 27/02/2015 15:23, Boris Zbarsky a écrit :
On 2/27/15 4:43 AM, David Bruant wrote:
It is my belief that providing the sandbox attribute should be a strong
enough indicator that the iframe could be fully run in parallel (not
just loaded async'ly).
Iframes are already loaded async, obviously
Le 27/02/2015 15:58, Boris Zbarsky a écrit :
On 2/27/15 9:54 AM, David Bruant wrote:
I jumped a bit to conclusions quickly, but I think the point remains. If
the iframe is loaded in parallel (different thread, different process,
anything that isn't blocking the parent), then its loading doesn't
Le 27/02/2015 16:24, Anne van Kesteren a écrit :
On Fri, Feb 27, 2015 at 4:15 PM, David Bruant bruan...@gmail.com wrote:
To achieve this priorization, currently, authors would use a bit of JS to
delay adding the iframe to the document. It seems like it solves all the
issues listed
Hi Anne,
Le 27/02/2015 08:57, Anne van Kesteren a écrit :
I got feedback that isolating ads from your page through iframe is
desirable, but that the impact on browser load UI, the load event, and
fast back, are very much not desirable.
It's the first time I read the term fast back? What does
Le 13/05/2014 18:21, Ian Hickson a écrit :
On Tue, 13 May 2014, Dirk Schulze wrote:
contentEditable can be fairly useful in SVG as well. It partly works for
inline SVG content in web browsers today.
The question is, should SVGElement add support for
contentEditable/isContentEditable and add it
Le 26/05/2014 01:52, Michael Heuberger a écrit :
Serving different content based on different URLs (and status)
actually does make a lot of sense when you want your user to see the
proper content within the first HTTP round-trip (which saves
bandwidth). If you always serve generic content and
Hi Michael,
Le 25/05/2014 07:10, Michael Heuberger a écrit :
Look at Angular, their templates reside on the client side. For
production, a grunt task can compress all files into one single, huge JS
file that is served to the client, then for any subsequent pages no more
resources are loaded
Le 25/05/2014 14:04, Michael Heuberger a écrit :
Bonjour David
On 25/05/14 23:33, David Bruant wrote:
Hi Michael,
Le 25/05/2014 07:10, Michael Heuberger a écrit :
Look at Angular, their templates reside on the client side. For
production, a grunt task can compress all files into one single
Le 23/05/2014 10:04, Michael Heuberger a écrit :
- Display a beautiful 404 page and hide parts of the navigation
- Reveal navigation history to give users a better usability experience
during 404s
- And many more …
I agree with those entirely but couldn’t they also be achieved by including the
`?
This might break existing website which would use the force value, but
since it had no special meaning currently and there is no good reason to
use this value, I'd say the odds are very low.
Any implementor interested?
David
Le 29/04/2014 23:32, David Bruant a écrit :
Hi,
// CSS:
div
Le 30/04/2014 13:01, Anne van Kesteren a écrit :
Le 29/04/2014 23:32, David Bruant a écrit :
Hi,
// CSS:
div{
display: flex;
}
// HTML:
div hidden/div
Per spec, the div should be shown right? I imagine there is no way back on
that?
We could change the specification to use display-box
Hi,
// CSS:
div{
display: flex;
}
// HTML:
div hidden/div
Per spec, the div should be shown right? I imagine there is no way back
on that?
Does it mean hidden only works when the default (UA stylesheet) display
value is kept? Does it mean hidden is completely useless when trying to
Hi Chris,
Le 06/02/2014 16:54, Chris Coyier a écrit :
Hey folks. Long time listener, first time caller.
Thanks for participating :-)
I'm hoping for more a little bit more control over iframes. We have
iframe sandbox which is pretty fantastic right now. I'd like to see some
possibilities in
Le 04/01/2014 16:10, Kornel Lesiński a écrit :
I don't think anybody cares for NodeList.forEach/map/filter/etc to be
real Array functions, so I'd love to see even a simplest fix like:
NodeList.prototype.map = function(...whatever) {
return Array.from(this).map(...whatever);
}
Hi Kyle,
Le 30/10/2013 22:54, Kyle Simpson a écrit :
Thoughts?
Kyle wrote:
BUT we cannot, currently, have that sessionStorage-stored session-ID
automatically transmitted with each normal page request.
This means that the initial page-response from the server, even in the
case where
Le 16/10/2013 01:26, Robert O'Callahan a écrit :
On Wed, Oct 16, 2013 at 11:55 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
If the main thread is blocked, the app drops frames anyway, no?
Not necessarily. We can allow workers to present frames to the
compositor
Le 16/10/2013 00:12, Robert O'Callahan a écrit :
On Wed, Oct 16, 2013 at 10:19 AM, Justin Novosad ju...@google.com
mailto:ju...@google.com wrote:
rAF doesn't work in a worker, but that is easy to work around. You can
have a rAF handler on the main thread that propagates the signal
Le 13/10/2013 06:12, Kyle Huey a écrit :
I talked at length with Robert O'Callahan about what the DOM API for
supporting canvas in web workers should look like and we came up with the
following modifications to the spec.
1. Rename CanvasProxy to WorkerCanvas and only allow it to be
Le 13/10/2013 18:12, Glenn Maynard a écrit :
On Sun, Oct 13, 2013 at 11:01 AM, David Bruant bruan...@gmail.com
wrote:
bool commit();
Boolean as return value for success? :-s
A promise instead maybe? throw instead of false at least?
In any case, it looks like commit could be a long
Le 13/10/2013 23:33, Robert O'Callahan a écrit :
bool commit();
Boolean as return value for success? :-s
A promise instead maybe? throw instead of false at least?
In any case, it looks like commit could be a long operation (tell
me if I'm wrong here. Do you have
Le 14/10/2013 01:27, Robert O'Callahan a écrit :
On Sun, Oct 13, 2013 at 6:07 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 13/10/2013 23:33, Robert O'Callahan a écrit :
bool commit();
Boolean as return value for success? :-s
Le 21/08/2013 22:20, Boris Zbarsky a écrit :
On 8/8/13 5:35 PM, Ian Hickson wrote:
I'm certainly open to the idea of making document.domain not work in
sandboxed iframes. Any objections? Who is ready to implement this?
There seems to be general support for this amongst the Mozilla DOM
peers,
Le 03/08/2013 03:03, Boris Zbarsky a écrit :
On 8/2/13 6:44 PM, David Bruant wrote:
And apparently @sandbox doesn't help here if there is allow-same-origin.
So here is an idea: make the document.domain setter throw inside an
iframe@sandbox, *regardless* of allow-same-origin. That solves
Le 03/08/2013 16:02, Boris Zbarsky a écrit :
On 8/3/13 9:48 AM, David Bruant wrote:
a.example.org can sandbox the iframe to b.example.org and process
isolation becomes possible again
Yes, agreed. This might be a good idea. It just has nothing to do
with protecting one from attacks
Hi,
Moving a part on an es-discuss discussion [1]
Boris Zbarsky wrote:
Hixie is suggesting process-isolating iframes that are not same-origin
to start with and can't be made same-origin via document.domain
Quite a noble purpose.
Note that is condition applies to sandboxed iframes (except for
Le 16/05/2013 15:22, Yoav Weiss a écrit :
Arguably, the biggest problem in responsive Web design today is the fact
that many resource loading mechanisms are media query agnostic, and
download resources upfront regardless of whether they will be used or not.
One of the biggest resources in
Le 06/05/2013 21:35, James Burke a écrit :
In my experience as a JS library provider (first with dojo and more
recently with requirejs), JS scripts heavily favor binding to
DOMContentLoaded over document load to do work. DOMContentLoaded is
also what jQuery's ready() uses, which I expect is what
, Apr 29, 2013 at 7:44 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
What about starting with an API à la html@loading and if devs
complain it's too hard when there are independent scripts, then
add a mechanism like delayLoadEvent/stopDelayingLoadEvent? (I
Le 29/04/2013 01:08, Glenn Maynard a écrit :
On Sun, Apr 28, 2013 at 5:39 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 29/04/2013 00:14, Robert O'Callahan a écrit :
We don't want to require people to do everything in Caja just
to support
Le 29/04/2013 14:44, David Bruant a écrit :
I'm no Caja expert, but this light-Caja might be as simple as picking
a few Caja libraries and wiring them a bit differently. I'll ask the
Caja mailing-list.
Which I did and the answers are very interesting:
https://groups.google.com/d/msg/google
Le 29/04/2013 22:21, Benjamin Stürmer a écrit :
I have been reading about a technique described here (
http://googlecode.blogspot.de/2009/09/gmail-for-mobile-html5-series-reducing.html)
for deferring the parsing of scripts until they are actually required. This
can be a useful technique for
Le 24/04/2013 13:51, Robert O'Callahan a écrit :
Context: https://bugzilla.mozilla.org/show_bug.cgi?id=863499
Use-cases:
1) User-agents provide thumbnails of Web pages (e.g. desktop Firefox,
FirefoxOS and Safari do this). We want to avoid taking a thumbnail while
the application is incompletely
Le 24/04/2013 15:24, Bjoern Hoehrmann a écrit :
(...) there may be all sorts of things hooked to happen right after
the load event, and you do not want to delay them for some browser
thumbnail feature. If web pages should have the ability to say I
would like to inform you when the right time
Le 28/04/2013 19:47, Glenn Maynard a écrit :
On Sun, Apr 28, 2013 at 12:28 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Also, I don't see how nested calls to delayLoadEvent help any of
your 2 use cases.
Because multiple pieces of code on the page may need
Le 24/04/2013 15:24, Bjoern Hoehrmann a écrit :
If web pages should have the ability to say I would like to inform
you when the right time for snapshots has come ... okay, now I'm
ready, then there should be an explicit API for that.
In the Firefox bug, roc suggested [1]:
let the app specify
Le 28/04/2013 23:08, Glenn Maynard a écrit :
On Sun, Apr 28, 2013 at 1:00 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Each widget needs some way to express that it's ready, but doesn't
necessarily need to express it to the document directly. A widget
Le 29/04/2013 00:14, Robert O'Callahan a écrit :
We don't want to require people to do everything in Caja just to
support composition of independent scripts.
There are certainly more lightweight solutions than Caja to achieve the
same thing.
AFAICT we generally try to design Web APIs to
Le 18/04/2013 01:03, Charles McCathie Nevile a écrit :
Hi,
On Thu, 18 Apr 2013 01:52:47 +0300, David Bruant bruan...@gmail.com
wrote:
Hi,
Currently working on a web project where tablet support (iPad
especially) is important, I'm facing a need which apparently the
platform doesn't
Le 05/04/2013 15:07, Henri Sivonen a écrit :
Please add an attribute to link that:
* opts an external style sheet out of synchronous CSSOM access
Sorry if my suggestion is naive, but why about an attribute to opt out
of CSSOM entirely? As you suggested in the www-style thread [1] I would
Le 10/03/2013 21:17, David Rajchenbach-Teller a écrit :
On 3/9/13 1:14 AM, Glenn Maynard wrote:
I don't think making a call asynchronous is really going to help much,
at least for serialization. You'd have to make a copy of the data
synchronously, before returning to the caller, in order to
Le 08/03/2013 22:16, David Rajchenbach-Teller a écrit :
On 3/8/13 5:35 PM, David Bruant wrote:
2. serialize JSON (hopefully asynchronously) to a Transferable (or
several Transferables).
Why not collect the data in a Transferable like an ArrayBuffer directly?
It skips the additional
Le 08/03/2013 02:01, Glenn Maynard a écrit :
If you're dealing with lots of data, you should be loading or creating
the data in the worker in the first place, not creating it in the UI
thread and then shuffling it off to a worker.
Exactly. That would be the proper way to handle a big amount of
Le 07/03/2013 23:18, David Rajchenbach-Teller a écrit :
(Note: New on this list, please be gentle if I'm debating an
inappropriate issue in an inappropriate place.)
Actually, communicating large JSON objects between threads may cause
performance issues. I do not have the means to measure
Le 08/03/2013 13:34, David Rajchenbach-Teller a écrit :
I fully agree that any asynchronous JSON [de]serialization should be
stream-based, not string-based.
Now, if the main heavy duty work is dealing with the large object, this
can certainly be kept on a worker thread. I suspect, however, that
Le 08/03/2013 15:29, David Rajchenbach-Teller a écrit :
On 3/8/13 1:59 PM, David Bruant wrote:
Consider, for instance, a browser implemented as a web application,
FirefoxOS-style. The data that needs to be collected to save its current
state is held in the DOM. For performance and consistency
Hi,
The current description of the allow-same-origin sandbox token in the
spec is:
The allow-same-origin keyword allows the content to be treated as
being from the same origin instead of forcing it into a unique origin;
This is a very scary wording. Understood naively, I understand I could
Le 25/02/2013 19:10, Ian Hickson a écrit :
On Mon, 25 Feb 2013, David Bruant wrote:
As a more general question: does iframe@sandbox=allow-same-origin make a
page and a cross-origin iframe further connected than they are currently
without the keyword?
The only difference is that without
Le 19/11/2012 14:38, Boris Zbarsky a écrit :
On 11/19/12 2:36 AM, David Bruant wrote:
An ES6 proxy could do the trick here.
But then it's not a Map at all, right? It's a proxy for maybe a Map,
maybe something else. In what sense would it be a Map at that point?
I initially suggested either
Le 19/11/2012 00:17, Anne van Kesteren a écrit :
On Sun, Nov 18, 2012 at 11:34 PM, David Bruant bruan...@gmail.com wrote:
I feel the URLQuery object could be a regular object. Or maybe an ES6 Map.
If not an ES6 Map, maybe its API could be mapped exactly to ES6 Map. It
would increase
Hi,
I've been searching on the web for complete documentation about
window.open and I have some unanswered questions.
1) what are the rules for popup blockers? Is every call to window.open
blocked in modern browsers or are there exceptions?
2) About the third argument, is there a somewhat
Le 10/08/2012 20:06, Erik Reppen a écrit :
Sorry if this double-posted but I think I forgot to CC the list.
Browser vendor politics I can understand but if we're going to talk about
what history shows about people like myself suggesting features we can't
actually support I'd like to see some
Le 09/08/2012 02:20, Jussi Kalliokoski a écrit :
Hello there!
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.
There are 3 sources
Le 09/08/2012 09:59, Jussi Kalliokoski a écrit :
Hello David,
Hi Jussi,
On Thu, Aug 9, 2012 at 3:54 PM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
* The last source is your own content competing with itself for CPU.
*snip*
One question I have is whether
Le 25/07/2012 13:45, Bronislav Klučka a écrit :
On 20.7.2012 14:38, Steve Faulkner wrote:
Hi Hixie,
I believe you have made some spurious claims, one of them being;
The WHATWG effort is focused on developing the
canonical description of HTML and related technologies
The
Le 25/07/2012 15:32, Bronislav Klučka a écrit :
And my last remark: I hope major browser vendors will chose to follow
the same path, the same implementation of tasks, but not all major
vendors are part of WHATWG (as far as I know), and if some choose to
follow W3C and some different WHATWG
Le 25/07/2012 15:32, Bronislav Klučka a écrit :
And my last remark: I hope major browser vendors will chose to follow
the same path, the same implementation of tasks, but not all major
vendors are part of WHATWG (as far as I know), and if some choose to
follow W3C and some different WHATWG
Le 25/07/2012 16:36, Bronislav Klučka a écrit :
On 25.7.2012 16:04, David Bruant wrote:
Le 25/07/2012 15:32, Bronislav Klučka a écrit :
And my last remark: I hope major browser vendors will chose to
follow the same path, the same implementation of tasks, but not all
major vendors are part
Le 26/01/2012 10:35, Boris Zbarsky a écrit :
On 1/26/12 9:12 AM, Adam Barth wrote:
Should the speculative parser have knowledge ofmeta name=referrer?
That's not what's currently specified. Like many other browser
features, this feature lets web sites detect that the browser is
speculatively
Le 24/01/2012 01:35, Ian Hickson a écrit :
On Thu, 4 Aug 2011, Evgeny Burzak wrote:
It seems there is a bug in function Object.defineProperty.
When property was defined with enumerable descriptor = false, I can
anyway get it in iterator if was defined prop with the same name in
object
Hi,
My feedback regards the current version of the wiki page [1].
I'm curious about why a Referer header is always sent. Specifically for
never, an empty string is sent. Why not just not send the header at
all? That's what is specified for @rel=noreferrer [2] for instance:
If a user agent
Le 31/12/2011 19:11, Adam Barth a écrit :
On Sat, Dec 31, 2011 at 9:44 AM, David Bruant bruan...@gmail.com wrote:
Hi,
My feedback regards the current version of the wiki page [1].
I'm curious about why a Referer header is always sent. Specifically for
never, an empty string is sent. Why
Le 31/12/2011 19:46, Adam Barth a écrit :
On Sat, Dec 31, 2011 at 10:30 AM, David Bruant bruan...@gmail.com wrote:
I think there could be a use case for same-origin+fragment-less URL
which allows for internal tracking but not external tracking.
Yeah, that makes sense. I'm not sure whether we
[Adding WhatWG and public-script-coord (WebIDL) to the discussion.
Discussion is ongoing :
- Start of thread :
https://mail.mozilla.org/pipermail/es-discuss/2011-March/012915.html
- Strawman by Dave Herman:
http://wiki.ecmascript.org/doku.php?id=strawman:multiple_globals )]
---
Le 05/02/2011 01:42, Adam Barth a écrit :
Several folks have asked for a cryptographically strong random number
generator in WebKit. Our first approach was to make Math.random
cryptographically strong, but that approach has two major
disadvantages:
1) It's difficult for a web page to detect
I have two distinct things to say about this algorithm.
First of all, at Step 5 :
If input is an Array object or an Object object, then, for each
enumerable property in input, add a corresponding property to output
having the same name, and having a value created from invoking the
internal
Le 07/01/2011 12:24, Berend-Jan Wever a écrit :
Hey all,
I read that giving WebWorkers access to the DOM is apparently a bad idea:
http://forums.whatwg.org/viewtopic.php?t=4437
However, the page does not mention why. I'd like to know :)
When you say the DOM, it could mean two things :
- the
Le 07/01/2011 14:40, Berend-Jan Wever a écrit :
Thanks guys, that makes sense (unfortunately).
So, would it be possible:
1) To give WebWorkers access to the DOM API so they can create their own
elements such as img, canvas, etc...?
As I mentionned, Ian Hickson's response also covers provoding
Hi,
Note after 10.1.1 The DOCTYPE :
DOCTYPEs are required for legacy reasons. When omitted, browsers tend
to use a different rendering mode that is incompatible with some
specifications. Including the DOCTYPE in a document ensures that the
browser makes a best-effort attempt at following the
Le 25/08/2010 01:15, Ian Hickson a écrit :
On Wed, 25 Aug 2010, David Bruant wrote:
Note after 10.1.1 The DOCTYPE :
DOCTYPEs are required for legacy reasons. When omitted, browsers tend
to use a different rendering mode that is incompatible with some
specifications. Including the DOCTYPE
Le 17/08/2010 02:04, Jason Gross a écrit :
Is it possible to get more specificity than just the type of the
object being dragged? For example, if I have red images and blue
images, and a red target and a blue target, and I want to be able to
drop red images only on the red target, and blue
Hi,
After having a bug while trying to implement a browser-based chess game
using the native DragDrop API, I have decided to investigate a bit on
this API, examples and opinions.
There is already a very good explanation of the current state of the API
and how to use it here :
Hi,
In the case where the video is changing quickly (and espescially the
colors behind the subtitles), having a constant contrast helps the
reader. This can be achieved by adding a background to the text. There
are couple of examples of this in the use case page
Le 28/04/2010 00:03, Garrett Smith a écrit :
On Mon, Apr 26, 2010 at 10:04 AM, David Flanagan
da...@davidflanagan.com wrote:
Erik Arvidsson wrote:
[snip]
Rather that trying to make DOM collections feel like arrays, how about just
giving them a toArray()
Le 26/04/2010 11:25, Frank Migacz a écrit :
What is the implication of denying dynamic changes to the
HTMLCollection in a CORS environment? In some variant of Comet
(or asynchronous UA polling), how can the UA implement change if it is
regularly processing inside locked control blocks?
I am
Le 27/04/2010 03:54, Geoffrey Sneddon a écrit :
On 26/04/10 19:50, And Clover wrote:
David Flanagan wrote:
Rather that trying to make DOM collections feel like arrays, how about
just giving them a toArray() method?
I like that, as a practical and explicit (JavaScript-specific) binding.
In
Le 26/04/2010 10:33, Garrett Smith a écrit :
On Mon, Apr 26, 2010 at 9:49 AM, Erik Arvidssona...@chromium.org wrote:
On Sun, Apr 25, 2010 at 01:07, David Bruantbru...@enseirb-matmeca.fr wrote:
Le 25/04/2010 00:39, J Z a écrit :
I have thought a lot about weirdnesses that
// turning live collection into static array fixes this
Array.slice(document.getElementsByTagName('div')).forEach(function(el) {
el.parentNode.removeChild(el);
});
Where supported, though top level generics such as Array.slice are not
standard, so:
var divList =
Le 25/04/2010 00:39, J Z a écrit :
I have thought a lot about weirdnesses that people could think
about like trying to assign a value to the HTMLCollection
(divs[14] = myOtherDiv), but once again, it wouldn't be more
allowed than it currently is (I have no idea of what happens
Le 05/02/2010 07:21, Anne van Kesteren a écrit :
Legal documents often use various indicators for list items. E.g.
a. ...
b. ...
c. ...
or
1. ...
2. ...
3. ...
or
I. ...
II. ...
III. ...
or
A. ...
B. ...
C. ...
etc.
These indicators are part of the content and
Le 09/01/2010 05:24, Philip Jägenstedt a écrit :
On Sat, 09 Jan 2010 11:12:29 +0100, Ian Hickson i...@hixie.ch wrote:
Just a quick update:
On Fri, 11 Dec 2009, Ian Hickson wrote:
Since the W3C is still focused on getting HTML5 to last call, I'll
maintain a WHATWG copy of the HTML spec that
Hi,
My comments refer to what is after the the indicated part of the
document definition
(http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html#the-indicated-part-of-the-document)
- There is a reference to the RFC3023 that may require a link to the
reference section
-
Le 08/01/2010 06:13, Nikita Popov a écrit :
I think everyone who uses PHP, JavaScript, a.s.o. knows, that at some
point the user makes something wrong and you want to throw an error
(Your email's not valid (MX-Record not set.)) or an information
(You have logged in successfully.).
Know I do
Hi,
The 6.8.1 Client identification starts with an explanation dealing
with browser-specific bugs and limitation (browser-specific features
are missing, aren't they ?) that Web authors are forced to work around.
A very interesting project dealing with these browsers specific
implementations
On Mon, 7 Dec 2009, David Bruant wrote:
Plus, since browsers don't have thread-safe DOM implementations, we
actually can't expose the DOM in workers. Maybe one day. :-)
I'm sorry for the misunderstanding. I shouldn't have said the DOM API.
To be as accurate as I can be I want
Le 09/12/2009 14:53, Jonas Sicking a écrit :
On Wed, Dec 9, 2009 at 10:55 AM, Ian Hicksoni...@hixie.ch wrote:
On Wed, 9 Dec 2009, David Bruant wrote:
Ian wrote:
Since browsers don't have thread-safe DOM implementations, that's
basically a non-starter. It doesn't matter
David Bruant :
In the delegation example, the number of workers chosen is an arbitrary
10. But, in a single-core processor, having only one worker will result
in more or less the same running time, because at the end, each worker
runs on the only core.
Ian Hickson :
That depends
Ian Hickson a écrit :
On Wed, 11 Nov 2009, David Bruant wrote:
This is a new proposal taking into account the feedback I recieved to
the [WebWorkers] About the delegation example message.
In the delegation example of the WebWorker spec, we can see this line :
var num_workers = 10;
My
The reason WebWorkers don't have access to the DOM is concurrency. For
example, to loop through a list of children I need to first read the
number of childrens, then have a for loop which starts at 0 and ends
at length-1. If you have two threads that can access the DOM
concurrently, then one
Hi,
I recently learnt to use the white-space css rule
(http://www.w3.org/TR/CSS2/text.html#white-space-prop) and wondered if
the pre element was finally not just a presentational element since
its behavior can be emulated on other elements with a css rule.
On the CSS2 link I provide we can read
David Bruant a écrit :
Hi,
I recently learnt to use the white-space css rule
(http://www.w3.org/TR/CSS2/text.html#white-space-prop) and wondered if
the pre element was finally not just a presentational element since
its behavior can be emulated on other elements with a css rule
Tab Atkins Jr. a écrit :
On Tue, Nov 24, 2009 at 11:07 PM, David Bruant
bru...@enseirb-matmeca.fr wrote:
Writing the following is semantically sufficient and handles the
presentation as expected :
code style=white-space:pre;
#include stdlib.h
int main(){
return EXIT_SUCCESS
Boris Zbarsky a écrit :
On 11/11/09 10:19 PM, David Bruant wrote:
This attribute have the following properties :
- It's only dependant on the hardware, the operating system and the
WebWorker implementation (thus, it is not dynamically computed by the
user agent at each call and two calls
Boris Zbarsky a écrit :
On 11/12/09 12:49 PM, David Bruant wrote:
= You're perfectly right. I reformulate the definition of running
conditions (appearing in condition 2 and 3) as :
same memory available, same number of process running concurrently, no
other worker running working on the same
Boris Zbarsky a écrit :
On 11/12/09 3:40 PM, David Bruant wrote:
I reformulate this way the conditions 2 and 3:
- In blank conditions (no other processes/thread running on the CPU,
enough memory to allocate the workers), running the same algorithm (an
easy delegation algorithm) has
Hi,
I was waiting for Firefox to stop freezing on the HTML5 spec page (it
freezes about one minute each time I visit the one-page version) and I
tried to think of a way to design this page in a way that wouldn't
freeze my browser.
One good way I have found would be to cut the whole page into
Hi,
This is a new proposal taking into account the feedback I recieved to
the [WebWorkers] About the delegation example message.
In the delegation example of the WebWorker spec, we can see this line :
var num_workers = 10;
My concern is about the arbitrarity of the 10.
Regarding the hardware,
Hi,
First of all, there is a typo error in this example. The main HTML page
is a copy/paste of the first example (Worker example: One-core
computation).
My point here is to ask for a new attribute for the navigator object
that could describe the best number of workers in a delegation use case.
100 matches
Mail list logo
