* Rick Waldron wrote:
>Of course, but we'd also eat scraps from the trash if that was the only
>edible food left on earth. document.createElement() is and has always been
>"the wrong way"—the numbers shown in those graphs are grossly skewed by a
>complete lack of any real alternative.
>
>If I want
https://www.w3.org/Bugs/Public/show_bug.cgi?id=21725
Bug ID: 21725
Summary: Specify id for Step 1 of the Web Workers Processing
Model
Classification: Unclassified
Product: WebAppsWG
Version: unspecified
Hardware: PC
On Apr 16, 2013, at 4:08 PM, Daniel Buchner wrote:
> "Deferring just the script features of would help with the timing
> and probably allow a better long term solution to be designed."
>
> If the callbacks are not mutable or become inert after registration (as I
> believe was the case), how w
*"Deferring just the script features of would help with the
timing and probably allow a better long term solution to be designed."*
If the callbacks are not mutable or become inert after registration (as I
believe was the case), how would a developer do this --> *"Imperative code
could presumably
On Apr 16, 2013, at 3:13 PM, Dimitri Glazkov wrote:
> On Tue, Apr 16, 2013 at 3:07 PM, Daniel Buchner wrote:
>> One thing I've heard from many of our in-house developers, is that they
>> prefer the imperative syntax, with one caveat: we provide an easy way to
>> allow components import/require/r
I think there were several f2f conversations around that. I can't
remember if we had an email thread around this.
It used to be called "created", but the timing at which the callback
is called makes the name misleading. For example, when parsing, by the
time the callback is invoked, the custom ele
On Tue, Apr 16, 2013 at 5:33 PM, Dimitri Glazkov wrote:
> On Mon, Apr 15, 2013 at 6:59 AM, Anne van Kesteren
> wrote:
> >
> > I think we should go for one interface per element here. "abstract
> > classes" not being constructable seems fine. Node/CharacterData are
> > similar to that. This would
On Tue, Apr 16, 2013 at 3:07 PM, Daniel Buchner wrote:
> One thing I've heard from many of our in-house developers, is that they
> prefer the imperative syntax, with one caveat: we provide an easy way to
> allow components import/require/rely-upon other components. This could
> obviously be done u
One thing I've heard from many of our in-house developers, is that they
prefer the imperative syntax, with one caveat: we provide an easy way to
allow components import/require/rely-upon other components. This could
obviously be done using ES6 Modules, but is there anything we can do to
address tha
On Tue, Apr 16, 2013 at 3:00 PM, Daniel Buchner wrote:
> "I am going to offer a cop-out option: maybe we simply don't offer
> imperative syntax as part of the spec?"
>
> Why would we do this if the imperative syntax is "solid", "nicely
> compatible", and relatively uncontentious? Did you mean to s
*"I am going to offer a cop-out option: maybe we simply don't offer
imperative syntax as part of the spec?"
*
Why would we do this if the imperative syntax is "solid", "nicely
compatible", and relatively uncontentious? Did you mean to say declarative?
Daniel J. Buchner
Product Manager, Developer E
Wow. What a thread. I look away for a day, and this magic beanstalk is all
the way to the clouds.
I am happy to see that all newcomers are now up to speed. I am heartened to
recognize the same WTFs and grumbling that we went through along the path.
I feel your pain -- I've been there myself. As Hi
On Mon, Apr 15, 2013 at 6:59 AM, Anne van Kesteren wrote:
>
> I think we should go for one interface per element here. "abstract
> classes" not being constructable seems fine. Node/CharacterData are
> similar to that. This would mean HTMLH1Element, ..., of which
> compatibility impact has not been
On 4/16/13 11:59 AM, Anne van Kesteren wrote:
I guess arguably that's how we define fetching in general (ignoring
redirects) but it does mean you have to wait for the response (to see
if it's a redirect or 401/407) before you can dispatch loadend on
.upload which is contrary to what we decided a
On Mon, Apr 15, 2013 at 11:05 PM, Dominic Cooney wrote:
> On Thu, Apr 11, 2013 at 5:53 AM, Erik Arvidsson wrote:
>>
>> For the record I'm opposed to what you are proposoing. I don't like that
>> you lose the symmetry between innerHTML and outerHTML.
>
>
> Sorry for replying to such a cold thread.
I request a URL using POST that redirects using 307 to some other URL.
This will result in the request entity body being transmitted twice.
It seems however user agents only fire progress events as if only one
fetch happened. Is that how we want to define this?
I guess arguably that's how we defin
I wonder if there may be a "cultural" difference involved in our different
points of view. As a C++ developer I think your point of view makes a lot
of sense. As a JavaScript developer I find it puzzling. Given a JS object
I can override its value getter and add new properties operating on the
ob
On Tue, Apr 16, 2013 at 4:57 AM, Anne van Kesteren wrote:
> As Ian pointed out (see WHATWG IRC reference above) you don't always
> want to parse synchronously as the base URL might change at a later
> stage.
For images, that's what you want--if the base URL changes after you assign
.src, the ol
On Tue, Apr 16, 2013 at 2:48 AM, Glenn Maynard wrote:
> The solution I propose is the same as it's always been. Have a synchronous
> algorithm, eg. "parse and capture the URL", which is invoked at the time
> (eg.) .src is set. This 1: invokes the URL spec's parser; 2: if the result
> is a blob U
> I suspect that the MathML community would be eager to help define
> what needs to get stripped out of MathML to maintain security.
> However, speaking for myself, I do not know what kinds of things
> are considered dangerous. For example, MathML has markup that lets
> a math expression act as a
20 matches
Mail list logo
