Re: [whatwg] DOM Feature Mod: Add metering / parallelism & throttling options to AddEventListenerOptions

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

Re: [whatwg]

Le 27/02/2015 17:27, David Håsäther a écrit : On Fri, Feb 27, 2015 at 4:37 PM, David Bruant 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 on what he said.

Re: [whatwg]

Le 27/02/2015 16:24, Anne van Kesteren a écrit : On Fri, Feb 27, 2015 at 4:15 PM, David Bruant 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 in the original message (load

Re: [whatwg]

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 do

Re: [whatwg]

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 ne

Re: [whatwg]

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 &

Re: [whatwg]

Hi Anne, Le 27/02/2015 08:57, Anne van Kesteren a écrit : I got feedback that isolating ads from your page through 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 it r

Re: [whatwg] Move contentEditable/isContentEditable from HTMLElement to Element?

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

Re: [whatwg] HTTP status code from JavaScript

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 fig

Re: [whatwg] HTTP status code from JavaScript

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

Re: [whatwg] HTTP status code from JavaScript

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 from

Re: [whatwg] HTTP status code from JavaScript

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

Re: [whatwg] hidden attribute useless with display: flex?

Le 30/04/2014 23:32, Ian Hickson a écrit : What I'm trying to do is just that an element have display:flex and to hide it with the hidden attribute when I don't need the element to be shown. I guess my only option is changing style.display? Just add "[hidden] { display: none }" to your style she

Re: [whatwg] hidden attribute useless with display: flex?

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: 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 instead. That

Re: [whatwg] hidden attribute useless with display: flex?

force"`? 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

[whatwg] hidden attribute useless with display: flex?

Hi, // CSS: div{ display: flex; } // HTML: 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 combine it with displ

Re: [whatwg] iframes, more sandbox

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 s. We have which is pretty fantastic right now. I'd like to see some possibilities in both directions (more

Re: [whatwg] NodeList.forEach/map/filter still doesn't work

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); } NodeList.pr

Re: [whatwg] Proposal: HTTP Headers + sessionStorage stored session-ID

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 someone

Re: [whatwg] Canvas in workers

Le 16/10/2013 01:26, Robert O'Callahan a écrit : On Wed, Oct 16, 2013 at 11:55 AM, David Bruant <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 comp

Re: [whatwg] Canvas in workers

Le 16/10/2013 00:12, Robert O'Callahan a écrit : On Wed, Oct 16, 2013 at 10:19 AM, Justin Novosad > 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 to your work

Re: [whatwg] Canvas in workers

Le 14/10/2013 01:27, Robert O'Callahan a écrit : On Sun, Oct 13, 2013 at 6:07 PM, David Bruant <mailto:bruan...@gmail.com>> wrote: Le 13/10/2013 23:33, Robert O'Callahan a écrit : bool commit(); Boolean as return value for success

Re: [whatwg] Canvas in workers

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

Re: [whatwg] Canvas in workers

Le 13/10/2013 18:12, Glenn Maynard a écrit : On Sun, Oct 13, 2013 at 11:01 AM, David Bruant 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 operation (tell me if I&#

Re: [whatwg] Canvas in workers

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 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 transferred

Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)

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 s. Any objections? Who is ready to implement this? There seems to be general support for this amongst the Mozilla DOM peers, so I f

Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)

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

Re: [whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)

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 solve

[whatwg] Disabling document.domain setting on iframe@sandbox (especially with allow-same-origin)

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

Re: [whatwg] Media aware JS loading

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 questi

Re: [whatwg] API to delay the document load event (continued)

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

Re: [whatwg] API to delay the document load event

feature, where it should live, etc.) Whether to support "independent scripts" or not influences what the API should look like. On Mon, Apr 29, 2013 at 7:44 AM, David Bruant <mailto:bruan...@gmail.com>> wrote: What about starting with an API à la html@loading and if devs

Re: [whatwg] Deferred Javascript parsing

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 allow

Re: [whatwg] API to delay the document load event

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/

Re: [whatwg] API to delay the document load event

Le 29/04/2013 01:08, Glenn Maynard a écrit : On Sun, Apr 28, 2013 at 5:39 PM, David Bruant <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 sup

Re: [whatwg] API to delay the document load event

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 suppor

Re: [whatwg] API to delay the document load event

Le 28/04/2013 23:08, Glenn Maynard a écrit : On Sun, Apr 28, 2013 at 1:00 PM, David Bruant <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

Re: [whatwg] API to delay the document load event

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

Re: [whatwg] API to delay the document load event

Le 28/04/2013 19:47, Glenn Maynard a écrit : On Sun, Apr 28, 2013 at 12:28 PM, David Bruant <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 n

Re: [whatwg] API to delay the document load event

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 f

Re: [whatwg] API to delay the document load event

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

Re: [whatwg] Forcing orientation in content

Le 18/04/2013 01:03, Charles McCathie Nevile a écrit : Hi, On Thu, 18 Apr 2013 01:52:47 +0300, David Bruant 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 support. I

[whatwg] Forcing orientation in content

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 support. I would need to lock the screen in landscape mode. I've been searching and StackOverflow suggested this is not possible [1][2][3][4]. Th

Re: [whatwg] Add an attribute for opting out of synchronous CSSOM access

Le 05/04/2013 15:07, Henri Sivonen a écrit : Please add an attribute to 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 guess t

Re: [whatwg] Sending large structured data between threads without compromising responsiveness (was asynchronous JSON.parse)

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 gua

Re: [whatwg] asynchronous JSON.parse

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

Re: [whatwg] asynchronous JSON.parse

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

Re: [whatwg] asynchronous JSON.parse

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

Re: [whatwg] asynchronous JSON.parse

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 recepti

Re: [whatwg] asynchronous JSON.parse

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

Re: [whatwg] Cross-origin iframe and @sandbox=allow-same-origin

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 w

[whatwg] Cross-origin iframe and @sandbox=allow-same-origin

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

Re: [whatwg] [URL] DOM API Feedback

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 sugges

Re: [whatwg] [URL] DOM API Feedback

Le 19/11/2012 00:17, Anne van Kesteren a écrit : On Sun, Nov 18, 2012 at 11:34 PM, David Bruant 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 interoperability. It cannot

Re: [whatwg] [URL] DOM API Feedback

Hi, 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 interoperability. David

Re: [whatwg] Declarative web worker creation and communication?

Le 03/11/2012 02:29, Fred Andrews a écrit : > 1. Declarative web worker creation. > > Feedback and suggestions for appropriate markup to declare web workers > would be appreciated. > > The use case is a document with JS disabled or restricted so that it can not > create web workers, yet still wants

[whatwg] Details on window.open

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 interop

Re: [whatwg] Wasn't there going to be a strict spec?

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 s

Re: [whatwg] Real-time thread support for workers

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 <mailto:bruan...@gmail.com>> wrote: * The last source is your own content competing with itself for CPU. *snip* One question I have is whether different

Re: [whatwg] Real-time thread support for workers

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 of

Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification

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 of

Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification

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 draf

Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification

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 draf

Re: [whatwg] Administrivia: Update on the relationship between the WHATWG HTML living standard and the W3C HTML5 specification

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 cla

Re: [whatwg] Feedback on Meta referrer

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 of? That's not what's currently specified. Like many other browser features, this feature lets web sites detect that the browser is speculatively prefetching resourc

Re: [whatwg] Bug in defineProperty

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 prototype.

Re: [whatwg] Feedback on Meta referrer

Le 31/12/2011 19:46, Adam Barth a écrit : > On Sat, Dec 31, 2011 at 10:30 AM, David Bruant 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&#

Re: [whatwg] Feedback on Meta referrer

Le 31/12/2011 19:11, Adam Barth a écrit : > On Sat, Dec 31, 2011 at 9:44 AM, David Bruant 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 >&g

[whatwg] Feedback on Meta referrer

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 foll

Re: [whatwg] Unforgeable document property

[with correct public-script-coord address] Le 23/09/2011 11:54, David Bruant a écrit : Hi, I have noticed on a recent commit [1] that the "document" property of the window object is now defined as [[Unforgeable]] (and still readonly). As per WebIDL, it makes the property non-config

[whatwg] Unforgeable document property

Hi, I have noticed on a recent commit [1] that the "document" property of the window object is now defined as [[Unforgeable]] (and still readonly). As per WebIDL, it makes the property non-configurable (in ECMAScript 5 terms). Consequently, it will make impossible to wrap the object document

Re: [whatwg] Multiple globals and direct/indirect eval

[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 )] --- Hi,

Re: [whatwg] Cryptographically strong random numbers

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 d

[whatwg] About the internal structured cloning algorithm

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 st

Re: [whatwg] WebWorkers and images

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 t

Re: [whatwg] WebWorkers and images

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 "

Re: [whatwg] HTML6 Doctype

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 s

[whatwg] HTML6 Doctype

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 r

Re: [whatwg] HTML5 Drag-and-Drop Specification: dragenter

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 ima

[whatwg] Thoughts and feedback on HTML5 drag and drop API

Hi, After having a bug while trying to implement a browser-based chess game using the native Drag&Drop 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 : http://html5doctor.c

[whatwg] [WebSRT] the outline use case

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 (http://wiki.whatwg.org/wiki/Use_

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (ATTN IE TEAM - TRAVIS LEITHEAD)

Le 28/04/2010 00:03, Garrett Smith a écrit : On Mon, Apr 26, 2010 at 10:04 AM, David Flanagan wrote: Erik Arvidsson wrote: [snip] Rather that trying to make DOM collections feel like arrays, how about just giving them a toArray() method? This makes it clear

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

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 t

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection (JZ and David Bruant)

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

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

Le 26/04/2010 10:33, Garrett Smith a écrit : On Mon, Apr 26, 2010 at 9:49 AM, Erik Arvidsson wrote: On Sun, Apr 25, 2010 at 01:07, David Bruant wrote: 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

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

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

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

// 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 = document.getElements

Re: [whatwg] Adding ECMAScript 5 array extras to HTMLCollection

Le 24/04/2010 22:50, J Z a écrit : On Fri, Apr 23, 2010 at 10:30 PM, David Bruant mailto:bru...@enseirb-matmeca.fr>> wrote: Hi, In the HTML5 "status of this document" section, one can read : "This specification is intended to replace (be the new version of)

[whatwg] Adding ECMAScript 5 array extras to HTMLCollection

Hi, In the HTML5 "status of this document" section, one can read : "This specification is intended to replace (be the new version of) what was previously the [...] DOM2 HTML specifications." This spec can be found here : http://www.w3.org/TR/DOM-Level-2-HTML/ It defines ECMAScript language Bi

Re: [whatwg] Lists and legal documents

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

[whatwg] Comment about "6.11.8 Navigating to a fragment identifier"

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 -

Re: [whatwg] Switching to an unversioned development model

Le 09/01/2010 05:24, Philip Jägenstedt a écrit : On Sat, 09 Jan 2010 11:12:29 +0100, Ian Hickson 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 matches what

Re: [whatwg] Output of web applications

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

[whatwg] A more detailed NavigatorID interface

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 implementati

Re: [whatwg] providing a DOM API to workers without a thread-safe DOM implementation

Le 09/12/2009 14:53, Jonas Sicking a écrit : On Wed, Dec 9, 2009 at 10:55 AM, Ian Hickson 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

[whatwg] providing a DOM API to workers without a thread-safe DOM implementation

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

Re: [whatwg] [WebWorkers] Advocation to provide the DOM API to the workers

> 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

Re: [whatwg] [Web workers] An attribute describing the "best" number of worker to invoke in a delegation use case

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 WebWor

[whatwg] [WebWorkers] Maximum number of workers (was "About the delegation example")

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." > Ia

[whatwg] [HTML5] A content in elements for ASCII art

Tab Atkins Jr. a écrit : > On Tue, Nov 24, 2009 at 11:50 PM, David Bruant > wrote: > >> => However, for this point, I am confused. It's true that currently, >> elements are not intended to have a content, but ASCII art, as >> images, is probably the best (

  1   2   >