On Tue, May 12, 2009 at 4:16 AM, Adam Barth wrote:
> On Thu, May 7, 2009 at 3:24 AM, Kristof Zelechovski
> wrote:
> > If toStaticHTML prunes everything it is not sure of, the danger of a
> known
> > language construct suddenly introducing active content is negligible. I
> am
> > sure HTML5 spec
On Mon, May 25, 2009 at 7:18 PM, Philip Jägenstedt wrote:
> On Thu, 21 May 2009 06:35:39 +0200, Biju wrote:
>
> I dont see a way to do frame advance feature for a paused VIDEO.
>>
>> Is there a way to achieve that ?
>> As well as frame backward also.
>>
>> Thanks
>> Biju
>>
>
> If you pause the
On Tue, May 26, 2009 at 11:25 AM, Robert O'Callahan wrote:
> I don't think there is a standard way to expose the frame rate. We might
> even want something more general than the frame rate, since conceivably you
> could have a video format where the interval between frames i
On Tue, May 26, 2009 at 8:04 PM, Philip Jägenstedt wrote:
> On Tue, 26 May 2009 01:26:38 +0200, Robert O'Callahan <
> rob...@ocallahan.org> wrote:
>
> On Tue, May 26, 2009 at 11:25 AM, Robert O'Callahan > >wrote:
>>
>> I don't think there i
On Mon, Jun 1, 2009 at 3:47 PM, Boris Zbarsky wrote:
> Oliver Hunt wrote:
>
>> Worse yet, the current setup means that a script that tries
>>> createImageData, fill in the pixels, and then paint it to the
>>> canvas, needs to fill different numbers of pixels depending on the
>>> output de
On Mon, Jun 1, 2009 at 7:13 PM, Maciej Stachowiak wrote:
>
> On May 31, 2009, at 9:08 PM, Robert O'Callahan wrote:
>
> Here are a couple of relevant threads:
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2007-May/011284.html
>
> http://lists.whatwg.org/htdig.
On Mon, Jun 8, 2009 at 7:15 AM, Ian Hickson wrote:
> Every codec has the same problem; the difference is that companies like
> Apple have already taken on the patent risk with MPEG-LA licensed codecs
> and are not willing to double their exposure. (Other companies like Google
> apparently _are_ w
On Mon, Jun 8, 2009 at 12:24 PM, Chris DiBona wrote:
> Reprehensible? Mozilla (and all the rest) supports those same "open
> web" features through its plugin architecture.
People don't usually think of Flash as part of the "open Web" (except for
certain Adobe evangelists).
Why don't you make a
On Mon, Jun 8, 2009 at 12:42 PM, Chris DiBona wrote:
> I'm perfectly calm, what people need to realize is that this issue is
> actually not about submarined patents (more like aircraft carrier
> patents) or tricky corner cases for the lgpl., but that the internet
> users prefer more quality in th
On Thu, Jun 11, 2009 at 5:24 AM, Drew Wilson wrote:
> That's a great approach. Is the pool of OS threads per-domain, or per
> browser instance (i.e. can a domain DoS the workers of other domains by
> firing off several infinite-loop workers)? Seems like having a per-domain
> thread pool is an ide
On Sat, Jun 13, 2009 at 6:39 AM, Ian Hickson wrote:
> The long and short of this is that if we solve this problem today, the
> solution will be abused as much as the current API, and we'll have to
> introduce yet another solution when high-res backing stores are common. So
> instead I'm hoping th
On Sat, Jun 13, 2009 at 6:57 PM, Ian Hickson wrote:
> There's no practical difference as far as I can tell between hoping that
> we can reuse the API, and then finding we can't, and introducing a second
> API for high-res screens; and just giving up now and saying that it's a
> low-res API, and t
On Tue, Jun 23, 2009 at 8:15 AM, Aryeh Gregor
> wrote:
> I believe that's the major rationale for not permitting cross-origin
> restrictions on existing media types. The only way this could work is
> if *all* browsers agreed to implement it all at once, and it would
> still seriously annoy a lot
On Wed, Jul 1, 2009 at 7:15 AM, Peter Kasting wrote:
> As a contributor to multiple browsers, I think it's important to note the
> distinctions between cases like Acid3 (where IIRC all tests were supposed to
> test specs that had been published with no dispute for 5 years), much of
> HTML5 (where
On Tue, Jun 30, 2009 at 4:50 PM, Ian Hickson wrote:
> - has off-the-shelf decoder hardware chips available
>
I don't think this should be a requirement.
As written, this requirement primarily means "need to be able to build
devices today that play back with minimal power consumption". Obviousl
On Sat, Jul 4, 2009 at 5:38 AM, Boris Zbarsky wrote:
> The above is actually supported in current nightly builds of Firefox if you
> set the "html5.enable" preference to true so that you're using the new
> parser. I can provide screenshots on request if desired. ;)
>
Yeah, Adam's example rende
On Mon, Jul 6, 2009 at 8:51 AM, Ian Hickson wrote:
> For that to happen there has to be
> some demand for Theora support, though, which the spec's can't generate.
>
Specs do generate demand --- by creating author expectation that a feature
will be supported, by adding a well-known brand, and bec
On Mon, Jul 6, 2009 at 11:00 AM, Maciej Stachowiak wrote:
> A spec for Theora through a formal standards process might more effectively
> focus latent demand than a mention in the HTML spec.
>
You may be right, but that is an orthogonal issue.
Rob
--
"He was pierced for our transgressions, he
When script creates an audio element using the "new Audio" constructor, the
'autobuffer' attribute should be automatically set on that element.
Presumably scripts will only create audio elements that they actually intend
to play.
Rob
--
"He was pierced for our transgressions, he was crushed for o
On Mon, Jul 6, 2009 at 12:36 PM, Adam Shannon wrote:
> What about slower, public, or WIFI connections that can't support 5 people
> going to yahoo.com and having audio of interviews load? Yahoo would think
> that everyone would want to listen to at least the first ~15-30 seconds.
>
What about th
On Mon, Jul 6, 2009 at 1:01 PM, Adam Shannon wrote:
> On Sun, Jul 5, 2009 at 7:58 PM, Robert O'Callahan wrote:
>
>> I think we expect "new Audio" to be used for scripted playing of sounds,
>> not to create in-page audio elements.
>>
>
> If that i
On Mon, Jul 6, 2009 at 1:44 PM, Ian Hickson wrote:
> On Mon, 6 Jul 2009, Robert O'Callahan wrote:
> > Specs do generate demand --- by creating author expectation that a
> > feature will be supported, by adding a well-known brand, and because
> > test suites get created
On Tue, Jul 7, 2009 at 2:09 AM, wrote:
> SVG Filters are a relatively easy spec, where the most important parts can
> be implemented in a matter of hours.
Speaking as an implementor of SVG filters, I don't believe you :-).
Am I the only one seeing any benefit for this or does anybody else thin
On Tue, Jul 7, 2009 at 9:21 AM, wrote:
> On Tue, Jul 7, 2009 at 2:09 AM, hansschmuc...@gmail.com> wrote:
> > SVG Filters are a relatively easy spec, where the most important parts
> can be implemented in a matter of hours.
> On Jul 6, 2009 10:54pm, Robert O'Callahan wr
sharing code with
> the SVG filters) is not even something a spec is supposed to dictate,
> you can share as much code as you want as long as the result is what
> the spec says.
Yes, but the specs can make code sharing painful or even infeasible if they
diverge, even accidentally.
On
On Tue, Jul 7, 2009 at 11:37 AM, Hans Schmucker wrote:
> I should really add one point. The Canvas spec, above all, is
> predictable. You pretty much know exactly what you'll get when you
> perform certain actions.
Like arcTo?
> Relying directly on SVG filters makes things
> harder to understa
On Tue, Jul 7, 2009 at 12:38 PM, Hans Schmucker wrote:
> I simply think that when using SVG filters, we are much more likely to
> add a lot of these "border-cases" where browsers behave subtly
> different. We already have that problem with SVG in general and it's
> really holding SVG back.
Whate
2009/7/10 Ian Fette (イアンフェッティ)
> To me, this seems like a great test if "canPlayType" actually works in
> practice. In the perfect world, it would be great to do
> getElementById('video'), createElement, and
> then canPlayType('video/whatever','theora').
> If this simple use case doesn't work, I
On Fri, Jul 10, 2009 at 2:46 PM, Gregory Maxwell wrote:
> On Thu, Jul 9, 2009 at 10:35 PM, Robert O'Callahan
> wrote:
> > var v = document.getElementById("video");
> > if (v.canPlayType && v.canPlayType("video/ogg; codecs=vorbis,theora")) {
&g
On Fri, Jul 10, 2009 at 3:04 PM, Maciej Stachowiak wrote:
> Robert's code is a bit buggy; canPlayType returns a string, not a boolean,
> so it will always appear to say yes.
You're being polite, my code was not "a bit buggy", it was completely
broken.
I've actually made this mistake several ti
On Fri, Jul 10, 2009 at 4:40 PM, Ralph Giles wrote:
> To recap (off the top of my head): it's hard to say if you can play
> something because that requires either a validator, or actually
> playing it, So in addition to 'yes' and 'no', a 'maybe' was added, to
> say "I've heard of the media type a
On Sat, Jul 11, 2009 at 5:23 AM, Aryeh Gregor
> wrote:
> Maybe you'd try testing all the video types you support, and
> if one is "maybe" while another is "probably" you'd go with
> "probably"?
Right. Or you might have plugin-based fallback you can use if you get
"maybe". Other authors with no
On Sat, Jul 11, 2009 at 9:37 AM, Philip Jagenstedt wrote:
> the point is simply that calling canPlayType without out a codecs list or
> with specific codecs, you can learn exactly what is supported and not out of
> the container formats and codecs you are interested in, without the need for
> the
On Sat, Jul 11, 2009 at 9:38 PM, Philip Jägenstedt wrote:
> Well I disagree of course, because having canPlayType("video/ogg") mean
> anything else than "can I demux Ogg streams" is pointless.
>
So you want "canPlayType" to mean one thing when provided a type without
codecs, and another thing whe
On Sat, Jul 11, 2009 at 11:51 PM, Philip Jägenstedt wrote:
> Yes, I'm saying that when codecs are provided true means "probably" and
> otherwise it means "maybe", because the distinction is pointless.
>
IIRC some browsers using system media frameworks don't know what codecs they
support, so they
On Sun, Jul 12, 2009 at 3:44 AM, Philip Jägenstedt wrote:
> On Sat, 11 Jul 2009 14:38:02 +0200, Robert O'Callahan <
> rob...@ocallahan.org> wrote:
>
> On Sat, Jul 11, 2009 at 11:51 PM, Philip Jägenstedt > >wrote:
>>
>> Yes, I'm saying that when
On Sun, Jul 12, 2009 at 10:34 AM, Philip Jägenstedt wrote:
> Not that I except this discussion to go anywhere, but out of curiosity I
> checked how Firefox/Safari/Chrome actually implement canPlayType:
>
> http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support
>
> Firefox is conservativ
On Mon, Jul 13, 2009 at 10:00 AM, Robert O'Callahan wrote:
> It's not hard to implement this right, these issues reflect sloppy
> development more than a fundamental problem IMHO.
>
That sounded mean, I apologize. What I want to say is that sometimes, a
pattern of bugs indic
On Mon, Jul 13, 2009 at 11:14 AM, David Gerard wrote:
> Should clarified wording be written up for the spec?
>
The wording's fine.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
heale
On Tue, Jul 14, 2009 at 9:46 PM, Boris Zbarsky wrote:
> For the current model, note that all the text says is "should not show this
> content to the user". While this is not defined anywhere, it doesn't seem
> to indicate that the content's DOM should not exist, for example. In Gecko,
> at leas
On Tue, Jul 14, 2009 at 10:34 PM, Jonas Sicking wrote:
> We can do what's described above for videos and audios too (i.e. walk
> parent chain etc).
>
We can hack something in, but what about dynamic DOM changes? IFRAME loads?
etc
Rob
--
"He was pierced for our transgressions, he was crushed fo
On Tue, Jul 14, 2009 at 10:42 PM, Robert O'Callahan wrote:
> On Tue, Jul 14, 2009 at 10:34 PM, Jonas Sicking wrote:
>
>> We can do what's described above for videos and audios too (i.e. walk
>> parent chain etc).
>>
>
> We can hack something in, but what
On Wed, Jul 15, 2009 at 12:56 AM, Philip Jägenstedt wrote:
> While implementing canPlayType I've found that Firefox/Safari/Chrome (and
> now Opera) all have different error handling in parsing the MIME types. RFC
> 2045[1] gives the BNF form, but it appears that no browser gives much weight
> to t
On Thu, Jul 16, 2009 at 10:25 PM, Jonas Sicking wrote:
> Note that "hardware limitations" isn't as simple as "can play". For
> example a portable player device uses 90% CPU to play things certainly
> work, but possibly for an unacceptable short time before battery runs
> out.
>
We're talking abo
On Thu, Jul 16, 2009 at 11:26 PM, David Gerard wrote:
> * who supports Vorbis as a baseline codec for ?
Mozilla does, obviously.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace was upon him, and by his wounds we are
healed
On Mon, Jul 20, 2009 at 4:46 PM, David Wilson wrote:
> It's easy to see how some naively implemented JS audio widget could
> fetch 200mb over an expensive 3G connection, simply by navigating to
> some site in a background tab (say, by creating an array of elements
> to represent their playlist -
On Mon, Jul 20, 2009 at 5:06 PM, Nils Dagsson Moskopp <
nils-dagsson-mosk...@dieweltistgarnichtso.net> wrote:
> I second that motion, not only as owner of a smartphone, but also as
> someone with webspace that has a volume cap. Automagic audio element
> buffering could deter web authors from dynam
On Wed, Jul 22, 2009 at 1:36 AM, Patrick Mueller wrote:
> I've just started playing a bit with audio. One thing I noticed with both
> FF 3.5 and WebKit nightlies is that usage of the "loop" attribute set to
> true does not provide seamless looping. ie, there is a significant pause
> between when
On Tue, Jul 28, 2009 at 6:50 AM, Michael Davidson wrote:
> As mentioned in earlier discussions about persistent workers,
> permissioning UI is a major issue.
>
Indeed, the most difficult issue here is security and the permissions UI,
which you haven't addressed at all.
Currently, when you close
Why not just allow unlimited buffering, but also provide an API to query how
much data is currently buffered (approximate only, so it would be OK to just
return the size of data buffered in user space)?
Then applications that care and can adapt can do so. But most applications
will not need to. Th
On Wed, Jul 29, 2009 at 4:47 PM, Michael Davidson wrote:
> I agree 100%. I'm only trying to argue that from a user perspective,
> access that we currently have acceptable UI for, e.g. camera hardware,
> is about as scary as agreeing to let a web app run in the background.
> The consequences of a
What happened to my idea for browsers to have a special window containing
tabs for "background apps", which save screen real estate by just showing an
icon and title (and a URL or domain?) and no actual tab content? You might
modify the UI so that quitting the normal browser leaves this window open
On Thu, Jul 30, 2009 at 10:15 AM, Tab Atkins Jr. wrote:
> On Wed, Jul 29, 2009 at 5:05 PM, Robert O'Callahan
> wrote:
> > What happened to my idea for browsers to have a special window containing
> > tabs for "background apps", which save screen real estate by jus
On Thu, Jul 30, 2009 at 10:30 AM, Michael Kozakewich <
mkozakew...@icosidodecahedron.com> wrote:
>
> How many applications do we expect any one user to have open? I would
> imagine one would do fine on the Taskbar or in the Notification Area, like
> other programs, but a manager would be good if a
On Thu, Jul 30, 2009 at 11:09 AM, Maciej Stachowiak wrote:
> On Jul 29, 2009, at 3:05 PM, Robert O'Callahan wrote:
>
> What happened to my idea for browsers to have a special window containing
>> tabs for "background apps", which save screen real estate by just sho
On Fri, Jul 31, 2009 at 1:34 PM, Alex Henrie wrote:
> RFC 3986, which is referenced in the Web addresses specification, states
> "In some cases, extra whitespace (spaces, line-breaks, tabs, etc.) may have
> to be added to break a long URI across lines. The whitespace should be
> ignored when the
On Sat, Aug 1, 2009 at 12:20 AM, David Wilson wrote:
> I still don't understand the 'why' of this, whereas the 'why not'
> seems clear.
Because for the 99% use case of "new Audio()" --- scripts loading sounds,
and then playing them in response to events --- it's what you want. And if
authors fo
On Tue, Aug 4, 2009 at 5:34 AM, Daniel Gredler wrote:
> I know Anne VK (Opera) and ROC (Mozilla) appear to read this list... any
> comments, guys? Should I just file bugs? Any Safari / Chrome / IE guys out
> there with comments?
I know very little about these issues. Jonas Sicking reads this lis
On Mon, Aug 17, 2009 at 8:04 PM, Max Romantschuk wrote:
> Silvia Pfeiffer wrote:
>
>> Precision is influenced more strongly by the temporal
>> resolution of the decoding pipeline rather than the polling resolution
>> for currentTime. I doubt the previous implementations of "start" and
>> "end" ga
On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow wrote:
> First of all, I was wondering why all user prompts are specified as "must
> release the storage mutex" (
> http://dev.w3.org/html5/spec/Overview.html#user-prompts). Should this
> really say "must" instead of "may"? IIRC (I couldn't find th
On Sat, Aug 22, 2009 at 10:22 PM, Jeremy Orlow wrote:
> On Sat, Aug 22, 2009 at 5:54 AM, Robert O'Callahan
> wrote:
>
>> On Wed, Aug 19, 2009 at 11:26 AM, Jeremy Orlow wrote:
>>
>>> First of all, I was wondering why all user prompts are specified as
On Sat, Aug 22, 2009 at 7:37 AM, Silvia Pfeiffer
wrote:
> Xiph has spent a long time on developing libraries that make seeking
> simple for Ogg Theora/Vorbis and Firefox has the advantage of using
> these libraries.
In fact we had to write this support ourselves.
Rob
--
"He was pierced for our
On Tue, Aug 25, 2009 at 11:51 AM, Jeremy Orlow wrote:
> To me, getStorageUpdates seems to imply that updates have already happened
> and we're working with an old version of the data. I think many developers
> will be quite shocked that getStorageUpdates _enables_ others to update
> storage. In
On Wed, Aug 26, 2009 at 2:54 PM, Jeremy Orlow wrote:
> Is there any data (or any way to collect the data) on how much of the web
> IE and Chrome's current behavior has broken? Given that there hasn't been
> panic in the streets, I'm assuming approximately 0%?
>
We previously had a lengthy discu
On Mon, Aug 31, 2009 at 1:55 AM, Philip Jägenstedt wrote:
> I get the impression this has all been discussed before.
>
It has.
> Still, it seems unlikely that any browser will ever be able to switch to
> anything but a 1:1 CSS pixel:device pixel ratio, as that would break all
> existing pages a
On Mon, Aug 31, 2009 at 11:06 PM, Anne van Kesteren wrote:
> Once we get huge screens and lots of processing power people can just blow
> up the canvas grid and then scale it down with CSS. Works just as well and
> makes the data more portable.
I think we can do better than that. It's fine to us
On Wed, Sep 2, 2009 at 11:31 AM, Jeremy Orlow wrote:
> Does the silence mean that no one has any intention of implementing this?
>
I'm silent because I'm not currently working on this stuff so I can't say
what our plans are. But I'll be upset if I find out our plans are to break
the single-threa
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt wrote:
>
> On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
>
>> Yeah, that seems likely, since none of you implemented the higher-DPI
>> ImageData in your first versions. :-(
>>
>
> WebKit's implementation has always worked with high dpi backing stores a
On Fri, Sep 4, 2009 at 9:44 PM, Jeremy Orlow wrote:
> I think it's pretty clear that the spec, as is, is not possible to
> implement without making it trivial for a single website to lock up all of
> your event loops
>
I don't think that's clear at all, yet.
It's clearly *hard* to implement
On Sat, Sep 5, 2009 at 10:22 AM, Chris Jones wrote:
> And if the intention is to make scripts appear to run atomically, then I
> think there are better ways to specify that than storage mutex.
>
That sounds good, how?
My problem with storage mutex boils down to the fact that by the letter of
>
On Sat, Sep 5, 2009 at 6:39 PM, Marius Gundersen wrote:
> I've been playing around with the canvas element, making a 3D engine. It
> works, but is incredibly slow. Part of the reason is probably that the
> browser renders the canvas everytime I draw something to it. In a 3D engine,
> as well as a
On Sun, Sep 6, 2009 at 4:55 AM, Chris Jones wrote:
> I mean prevent the UA from affecting a script's execution. The cases I've
> thought of so far where we will probably have to break storage-mutex
> semantics are
>
> * clear private data
>
* close tab
> * quit UA
>
I think these could appea
On Sun, Sep 6, 2009 at 10:00 AM, Chris Jones wrote:
> Robert O'Callahan wrote:
>
>> In HTML5 we generally take the approach that if a UA is unable to satisfy
>> spec semantics due to resource limits or other problems in the environment,
>> then it's OK to de
On Tue, Sep 8, 2009 at 3:56 AM, Aryeh Gregor
> wrote:
> Browser vendors cannot sacrifice compatibility for long-term goals,
> because their users will rebel.
We can sacrifice *some* compatibility for *some* long-term goals. We do it
all the time, even Microsoft. It's all about tradeoffs.
In th
On Tue, Sep 8, 2009 at 7:00 PM, Aaron Boodman wrote:
> On Fri, Sep 4, 2009 at 12:02 AM, Chris Jones wrote:
> > I propose adding the functions
> >
> > window.localStorage.beginTransaction()
> > window.localStorage.commitTransaction()
> > or
> > window.beginTransaction()
> > window.commitTransa
On Tue, Sep 8, 2009 at 8:38 PM, Jeremy Orlow wrote:
> To be clear, Chrome is not going to implement the storage mutex with
> respect to cookies, but we are going to implement it for LocalStorage.
> Because of this, we can handle the localStorage mutex on a per-origin basis
> (which I'm implement
On Tue, Sep 8, 2009 at 8:45 PM, Jeremy Orlow wrote:
> You'd have to implement it via a mutex. An optimized implementation could
> wait until the first operation that can't be un-done before acquiring it,
> and do everything optimistically until then. This is the same situation as
> WebDatabase
On Tue, Sep 8, 2009 at 9:38 PM, Aaron Boodman wrote:
> On Tue, Sep 8, 2009 at 2:02 AM, Robert O'Callahan
> wrote:
> > Looking back over previous threads on the storage mutex, I can't seem to
> > remember or find the reason that implementing the storage mutex for
&
On Wed, Sep 9, 2009 at 6:53 AM, Aaron Boodman wrote:
> Attempts to address this by doing per-origin locks wind up with
> deadlocks being possible.
>
>
I think we can fix this.
Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities;
the punishment that brought us peace
On Wed, Sep 9, 2009 at 12:54 PM, Maciej Stachowiak wrote:
> Yet another possibility is to keep a per-domain mutex, also offer a
> transactional API, and accept that careless authors may indefinitely lock up
> the UI for all pages in their domain (up to the slow script execution limit)
> if they c
On Thu, Sep 10, 2009 at 6:37 AM, Darin Fisher wrote:
> Yes, exactly. Sorry for not making this clear. I believe implicit locking
> for LocalStorage (and the implicit unlocking) is going to yield something
> very confusing and hard to implement well. The potential for dead locks
> when you fail
On Thu, Sep 10, 2009 at 1:33 PM, Jeremy Orlow wrote:
> In general this seems like a pretty interesting idea. It definitely would
> be nice to completely abstract away all concepts of concurrency from web
> developers, but some of our solutions thus far (message passing, async
> interfaces, etc)
On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman wrote:
> If this feature existed, we likely would have used it for offline Gmail to
> coordinate which instance of the app (page with gmail in it) should be
> responsible for sync'ing the local database with the mail service. In the
> absence of a f
On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher wrote:
> What concerns me are the cases where synchronous events (e.g., resizing an
> iframe) can cause script to execute in another domain. As spec'd, there is
> a potential dead lock with the storage mutex. We must carefully unlock in
> situations
On Thu, Sep 10, 2009 at 4:11 PM, Darin Fisher wrote:
> On Wed, Sep 9, 2009 at 9:07 PM, Robert O'Callahan wrote:
>
>> On Thu, Sep 10, 2009 at 3:53 PM, Darin Fisher wrote:
>>
>>> What concerns me are the cases where synchronous events (e.g., resizing
>>>
On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher wrote:
> Imagine if you script a plugin inside the transaction, and before
> returning, the plugin scripts another window,
>
I'm curious, how common is that anyway? Can we just tell plugins not to do
that, and abort any plugin that tries?
Rob
--
"
On Thu, Sep 10, 2009 at 4:57 PM, Darin Fisher wrote:
> On Wed, Sep 9, 2009 at 9:43 PM, Robert O'Callahan wrote:
>
>> On Thu, Sep 10, 2009 at 4:37 PM, Darin Fisher wrote:
>>
>>> Imagine if you script a plugin inside the transaction, and before
>>> ret
If you call cloneNode on a media element, the state of the resulting media
element seems unspecified. Should it be playing the same media resource at
the same current time as the original?
Similar questions arise when you clone form elements; is the state that's
not visible in the DOM cloned?
Who
On Thu, Sep 10, 2009 at 7:41 PM, Maciej Stachowiak wrote:
> On Sep 9, 2009, at 10:26 PM, Robert O'Callahan wrote:
>
> If you call cloneNode on a media element, the state of the resulting media
>> element seems unspecified. Should it be playing the same media resource at
>
On Thu, Sep 10, 2009 at 8:13 PM, Jonas Sicking wrote:
> My assumption was always the opposite. For example for
> elements we clone the 'value' API attribute, as well as the internal
> has-changed-value bit (used for form field restore when going back to
> a page).
>
Looks like Opera and Webkit
On Thu, Sep 10, 2009 at 10:46 AM, Darin Fisher wrote:
> On Wed, Sep 9, 2009 at 3:37 PM, Maciej Stachowiak wrote:
>
>> I'm really hesitant to expose explicit locking to the Web platform.
>> Mutexes are incredibly hard to program with correctly, and we will surely
>> end up with stuck locks, race
On Fri, Sep 11, 2009 at 9:52 AM, Darin Fisher wrote:
> I think there are good applications for setting a long-lived lock. We can
> try to make it hard for people to create those locks, but then the end
> result will be suboptimal. They'll still find a way to build them.
>
One use case is selec
On Mon, Sep 14, 2009 at 9:50 AM, Ian Hickson wrote:
> In HTML5's development, compatibility is a stronger argument than
> aesthetics. Therefore the path stays.
>
This is a very minor issue and I'm fine with adding this to Gecko,
personally, except that first I really would like to see some speci
On Mon, Sep 14, 2009 at 1:12 PM, Ian Hickson wrote:
> Here are some bug reports that I believe are caused by this issue:
>
>
> http://forums.linksysbycisco.com/linksys/board/message?board.id=Wireless_Routers&message.id=135649
>
> http://www.dslreports.com/forum/r21297706-Re-Tweak-Test-Need-help-t
On Mon, Sep 14, 2009 at 7:43 PM, Ian Hickson wrote:
> I agree that sometimes antialiasing leads to seams, though; the solution
> to that isn't to disable antialiasing, though (that would just replace one
> problem with another), the solution is to provide new features that allow
> you to create c
On Thu, Sep 17, 2009 at 9:56 AM, Jeremy Orlow wrote:
> 1) Create a LocalStorage like API that can only be accessed in an async way
> via pages (kind of like WebDatabase).
>
> 2) Remove any
> atomicity/consistency guarantees from synchronous LocalStorage access within
> pages (like IE8 currently d
On Thu, Sep 17, 2009 at 11:17 AM, Jeremy Orlow wrote:
> The use cases all revolve around having a backend in a worker that handles
> offline and/or caching. It could either feed its data to the page via
> messages or shared memory. The former requires at least worker-only and the
> latter requi
On Thu, Sep 17, 2009 at 8:32 PM, Ian Hickson wrote:
> LESSONS LEARNT
>
> If we ever define a new API that needs a lock of some kind, the way to do
> it is to use a callback, so that the UA can wait for the lock
> asynchronously, and then run the callback once it has it. (This is what
> the Web Da
On Fri, Sep 25, 2009 at 5:52 AM, Darin Fisher wrote:
> No, no... my point is that to the application developer, those "explicit"
> points will appear quite implicit and mysterious. This is why I called
> out third-party JS libraries. One day, a function that you are using
> might transition to
I think "feathered" isn't a good term. It's vary rarely used in graphics in
my experience. "aliasClipping" isn't a good term either, since there's no
clipping going on typically.
I would just have boolean property named "antialias".
Rob
--
"He was pierced for our transgressions, he was crushed f
201 - 300 of 747 matches
Mail list logo
