. (The same would be needed for things like
deflating/inflating data: can't slice it and don't know the final
size.) But, the async reads and compression themselves do make a lot
of sense.
--
Glenn Maynard
to that case.
This would mean sending events to every window when previews are
displayed, right? That sounds like a performance pit--open a preview
display (which should be very quick) and windows with
previews-considered-visible behavior all start working at the same
time.
--
Glenn Maynard
of a driver, of course, to translate the device to a
higher-level interface for accessing it. It's not possible to create
a single API to encompass them all.
--
Glenn Maynard
be permitted to run the
compression synchronously. There should also be a way to abort
compression, since any asynchronous operation should be cancellable.
(An event-based interface like FileReader's is probably more
appropriate.)
--
Glenn Maynard
synchronous counterparts. But,
please keep the async case in mind. Seeing async compression
dismissed out-of-hand in
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2010-January/024691.html
was a bit worrisome.
--
Glenn Maynard
this to be specced and
implemented would be a loss, though; it's too important. It would
also be partially redundant if Canvas access in worker threads ever
happens.
--
Glenn Maynard
and spec work. People should use XHR2 if
they want a greater level of control than simple form submission. I
think it's typically more than ten lines of code to make it work
(server-side API support is often needed, too), but it seems better
than starting to duplicate APIs.
--
Glenn Maynard
is tell people
not to use full-page zoom. Many users probably see a blurry image and
don't know why, since there's no way to detect full-page zoom in most
browsers to even hint the user about the problem.
--
Glenn Maynard
, but
fragmenting browser behavior so badly is a general, user-visible
problem.
--
Glenn Maynard
creation to throw an exception if our worker threads
are being queued.
--
Glenn Maynard
on everyone.
--
Glenn Maynard
on the system. I'd be concerned about
a generic, loosely-defined lowmemory event with entirely unrelated
meanings encouraging developers to respond to it in ways that only
happen to make sense on the platform they're testing on.
--
Glenn Maynard
to
reasonably decide what to do, they'll have a single, universal
response which will be correct in some cases and probably incorrect in
many others. (Or, they'll have to try to infer what it means based on
the browser and platform, which seems to defeat the purpose of
speccing it.)
--
Glenn Maynard
be paged back out quickly, so it's probably not that
simple in practice.)
--
Glenn Maynard
that
could be deallocated as needed. I think this was only supported in
Win16 (the GMEM_DISCARDABLE flag to GlobalAlloc); I mention it only
for reference.
--
Glenn Maynard
and to support features like seek to next comment.
--
Glenn Maynard
about security when that is already broken by other means
at higher levels ?
Flash is insecure, so HTML5 should be too? Seriously?
--
Glenn Maynard
.
--
Glenn Maynard
of HTML or
Javascript. This won't change without a reasonable security
mechanism--but asking the user every time a script changes is not an
answer.
--
Glenn Maynard
security model can be built around requiring the user
to understand the technical issues behind the security.
--
Glenn Maynard
hasn't been compromised. But, yes, you only have to do that once with
auto-updating systems, not on every update.
--
Glenn Maynard
they don't prevent is a compromised server.
Or various kinds of cross-site script injection (which you may or may not
consider as a compromised server).
I suppose this is analogous to buffer overflows in native code.
--
Glenn Maynard
a lot. By
comparison, *no* informed user would want to give every website
unrestricted local file access; hijackable elevated file permissions
is an inherently critical security failure.
--
Glenn Maynard
it.
That's fine.
--
Glenn Maynard
to buy extra or more powerful servers to
handle this.
--
Glenn Maynard
it.
--
Glenn Maynard
is *enough* for sensitive APIs like that--that, I think,
is the open question.
--
Glenn Maynard
account system.
--
Glenn Maynard
with this text? Googling
the message body only finds this thread and another snipped quote, not
the original message.
--
Glenn Maynard
the basic web workers API in place is much higher
priority. But, I hope this will be revisited seriously at an
appropriate time, and not dismissed as not useful. Image manipulation
is one of the most obvious candidates for threading.
--
Glenn Maynard
, doing this
sort of work in a thread can be a huge win: keeping the UI
consistently responsive.
I've seen it in practice: select an image in an image box, start
typing in another form field, and my typing freezes for half a second
while an invisible canvas operation runs.
--
Glenn Maynard
, crazy--but a serial API isn't
unreasonable at all.)
The particular mechanisms to handle this should be up to the browser,
of course, but I firmly believe it's the browser's job.
--
Glenn Maynard
is something you want, consistently, on every page you visit. You
don't want every webpage to have a different, inconsistent IME, to have to
configure IMEs on each page, etc. OS's without a needed IME installed are
an issue, but implementing it in each webpage isn't the right fix.
--
Glenn Maynard
On Sun, Jan 9, 2011 at 4:10 PM, Bjartur Thorlacius svartma...@gmail.com wrote:
On 1/9/11, Glenn Maynard gl...@zewt.org wrote:
File access control is currently, very clearly and very deliberately,
handled by the browser: web pages can only access files the user gives
to the page by selecting
, web pages should be
able to access any local file that the OS user account the script is
running as has access to, and that users should control what files
they want web pages to access by modifying the operating system's
ACL's to grant and revoke access to web pages.
--
Glenn Maynard
in webpages right now. That's
shortsighted, and can only lead to an API that will fall apart in a
couple years.
(Being able to seek to the next frame is by itself obviously useful,
even outside of editing applications, to allow users to single-step
videos as you can in any native video player.)
--
Glenn
for files with infrequent keyframes.
--
Glenn Maynard
user permission at some point to do so. Storing a reference
in an IndexedDB would allow that. But from what I recall, that's not
currently meant to be allowed.
--
Glenn Maynard
to the canvas that way, since you don't have the
Canvas interface), but it may be enough for your case.
--
Glenn Maynard
.
This seems like another important class of use cases for the
synchronously handling events thread on webapps.
--
Glenn Maynard
to optimize the allocation further, but even
2.5ms is worth optimizing out. If you're trying to maintain 60 FPS
(16.6ms per frame), that's 15% of your total available time (ignoring
concurrency).
--
Glenn Maynard
in inactive ones). That's not something the spec seems to allow right now,
but I think it would be beneficial to users in terms of preventing inactive
windows from accidentally hogging the CPU.
This isn't allowed by Optionally, wait a further user-agent defined
length of time?
--
Glenn Maynard
on the specific
object to be transferred makes more sense.
--
Glenn Maynard
like a FileAPI use case than a buffering
parameters one.
--
Glenn Maynard
On Mon, Jan 17, 2011 at 4:34 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jan 17, 2011 at 1:25 PM, Glenn Maynard gl...@zewt.org wrote:
On Mon, Jan 17, 2011 at 4:15 PM, Boris Zbarsky bzbar...@mit.edu wrote:
If nothing else, I'm thinking things like I would like to buffer up
this
3
confused--how is the required buffer size a function of the length of
the video? Once the buffer is large enough to smooth out network
fluctuations, either you have the bandwidth to stream the video or you
don't; the length of the video doesn't enter into it.
--
Glenn Maynard
to
buffer; bufferTimeMax appears to be for live streaming only (eg.
videoconferencing and webcams) to control sync, not static videos like
YouTube.
--
Glenn Maynard
On Tue, Jan 18, 2011 at 8:40 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/18/11 6:09 AM, Glenn Maynard wrote:
I'm confused--how is the required buffer size a function of the length of
the video? Once the buffer is large enough to smooth out network
fluctuations, either you have
On Tue, Jan 18, 2011 at 5:00 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/18/11 4:37 PM, Glenn Maynard wrote:
If you don't have enough bandwidth, then the necessary buffer size is
effectively the entire video[1]
No, it's really not. Your footnote is, of course, correct.
If my
to HTTP. If you think it is, it'd be helpful to explain
further.
--
Glenn Maynard
prebuffering reliably, but I don't think
anyone's made that argument.
--
Glenn Maynard
.
--
Glenn Maynard
the initially-paused state is
metadata or none (depending on how much bandwidth you want to save), and
uses Zachary's preload-only-when-paused only after the video has been played
at least once and then paused again (eg. because the user noticed it was
underrunning).
--
Glenn Maynard
On Thu, Jan 20, 2011 at 1:16 PM, Zachary Ozer z...@longtailvideo.com wrote:
On Thu, Jan 20, 2011 at 4:19 AM, Glenn Maynard gl...@zewt.org wrote:
I think that pausing shouldn't affect read-ahead buffering behavior. I'd
suggest another preload value, preload=buffer, sitting between metadata
with 256 MB of memory, it needs to stop buffering when it's out
of memory until some data has been played and thrown away, as it would
when streaming from the network normally. That requiests an API more
complex than simply writing to a file.
--
Glenn Maynard
the
inexact seek would provide?
The above would also answer your question: seeking would be unaffected
by the current play cursor.
--
Glenn Maynard
);
}
video.src = createObjectURL(b);
--
Glenn Maynard
(eg. always do fast seeking on
videos with keyframes less than 1-second apart).
(I have a feeling all these seek modes are getting ahead of things and
possibly overdesign, though I agree the seek mode should be an enum
and not a boolean, for future expansion.)
--
Glenn Maynard
.
The consequences of using fast as the default, when people forget to
explicitly specify accurate, seem worse than the other way around.
I recommend accurate as the default.
--
Glenn Maynard
= 10;
setTimeout(f, 5000);
}
f();
will always seek to the same position, and never choose different
positions due to a too-clever seek algorithm allowing more precise
seeking as more data is buffered.
--
Glenn Maynard
(preload=auto), but the exact buffer size is always up to
the browser. The actual size should be abstract and not exposed to
scripts; in practice it's probably not even a single number but a
high- and low-watermark.
--
Glenn Maynard
,
and would need to watch out for browsers that don't autoload on
preload=auto, but it's probably good enough for the above cases. It'd only
work if runtime changes to preload are applied, which would also be needed
for scripts to implement preload=auto only when paused.
--
Glenn Maynard
scripts should have some control over this.
Toggling between preload=metadata and preload=auto is one possible API to do
that. Granted, browser-supplied controls should also be able to implement
this behavior, which suggests an attribute to allow it. I'm not sure how to
get both cleanly.
--
Glenn
, I don't know how well that would
fare, though. What other solutions are there?
I don't know if explicit line breaks are needed, but an obvious option is a
br/ tag.
--
Glenn Maynard
PGothic. That's probably just what Japanese users
want for English text mixed in with Japanese text, too--but it's
generally not what English users want with the reverse.
--
Glenn Maynard
, and I'm curious if there's a
reliable way to do this currently with WebVTT. If this isn't handled, some
scenes just fall apart.
--
Glenn Maynard
. Tangental, but I figured I'd point it out.
--
Glenn Maynard
On Mon, Jan 24, 2011 at 6:54 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Mon, Jan 24, 2011 at 3:45 PM, Glenn Maynard gl...@zewt.org wrote:
As an aside: the font stroke (the outline around each letter) in the
above
clip helps readability substantially. A solid font color always tends
; this just makes it easier...
--
Glenn Maynard
captioning, is that it's impossible to put anything between the
video and the controls, so your captions will draw *on top of* browser
controls.
--
Glenn Maynard
.
--
Glenn Maynard
for
opinion from other implementors.
There are other meaningful ways to respond to these events; for example, to
pull its container to the top of the draw order if it's a floating window.
I should be able to capture mousedown on the container to do this,
regardless of content.
--
Glenn Maynard
this into their
default configurations.
The spec's text/cache-manifest registration suggests manifest.
That's far too generic for servers to default to mapping *.manifest to
text/cache-manifest. For example, Windows uses *.manifest for SxS assembly
manifests.
--
Glenn Maynard
On Mon, Jan 31, 2011 at 8:34 AM, Simon Pieters sim...@opera.com wrote:
On Mon, 31 Jan 2011 14:26:49 +0100, Glenn Maynard gl...@zewt.org wrote:
On Mon, Jan 31, 2011 at 7:17 AM, Simon Pieters sim...@opera.com wrote:
See http://lists.w3.org/Archives/Public/public-html/2009Jun/0395.html
I
--but these files shouldn't
make the same mistake and lay claim to *.manifest as if it's the only type
of manifest that exists. File extensions will never be without collisions,
but an effort should at least be made...
--
Glenn Maynard
On Mon, Jan 31, 2011 at 7:12 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 31 Jan 2011, Glenn Maynard wrote:
On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson i...@hixie.ch wrote:
That's far too generic for servers to default to mapping *.manifest
to text/cache-manifest. For example
when troubleshooting--but the main point
was just that it's a name likely to collide.)
I've changed the suggested extension to .appcache.
That seems fine. Thanks.
--
Glenn Maynard
to avoid this while still preventing
0ms looping timers from busy looping, but the spec prohibits that. (I could
give an example of how this would happen, but I don't think it's important
enough to go into further for now.)
--
Glenn Maynard
problems, eg. allowing webpages to flush a user's kernel's entropy
buffer and causing separate pages to compete for entropy data.)
--
Glenn Maynard
, as web apps
become larger and more complex--but it's still essentially the same
optimization.)
--
Glenn Maynard
for loading scripts. Maybe none of the use
cases apply to workers.
--
Glenn Maynard
is a hint, where
script preloading shouldn't be; loaders must be able to know whether they
can load-without-executing or not.
--
Glenn Maynard
On Wed, Feb 9, 2011 at 2:46 AM, Glenn Maynard gl...@zewt.org wrote:
- Just for comparison: script src=path.js noexecute
onload=this.execute() seems roughly equivalent to script async, and
like async, falls back on immediate loading if noexecute isn't supported.
script defer could
be used without adding any new escapes. All of the other suggestions would
also need to be escaped more frequently: // happens in URLs, and # and ;
occur in plain language.
--
Glenn Maynard
on.
--
Glenn Maynard
be
applied to inline scripts.
I don't have a strong opinion of whether this is important, since big
scripts are usually external, but it seemed worth mentioning.
--
Glenn Maynard
support. It also means
you only need to check support in one way--since you'll need to check
whether the function exists anyway.
--
Glenn Maynard
as consistently as
is reasonable), or not used at all and those specs should be changed.
--
Glenn Maynard
simply forgot that script events already had an onload event that means
something entirely different than the one described by Progress Events. The
finished loading from the network event would need to have a different
name.
--
Glenn Maynard
On Fri, Feb 11, 2011 at 3:24 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 29 Dec 2010, Glenn Maynard wrote:
I hit this problem in a UI I worked on. It rendered into a canvas the
size of the window, which can be zoomed and scrolled around. At 100%
full page zoom this works well. At 120
a simplified version. It also explicitly catches
exceptions from execute() and calls errorCallback, and demonstrates feature
checking (in a simpler way).
--
Glenn Maynard
On Fri, Feb 11, 2011 at 7:31 PM, Glenn Maynard gl...@zewt.org wrote:
I think the example code can be simplified a lot to demonstrate the API
more clearly. I've attached a simplified version. It also explicitly
catches exceptions from execute() and calls errorCallback, and demonstrates
immediately when it's inserted
into the document, if the script is cached. I'm pretty sure that's a bug.
Whether due to a bugfix or simply being masked due to changes in cache
behavior, it doesn't seem to happen in FF4.
--
Glenn Maynard
. The execute method was the critical
difference between the two proposals; removing it essentially changed his
proposal into a minor variation of yours.
--
Glenn Maynard
one or more browser vendors say we will not implement this,
which is what happened here.
And having every *thread* running in a separate process wouldn't exactly be
a sane model, anyway, and that's what this would actually require.
--
Glenn Maynard
to imply /dev/urandom's behavior: always return
data, even if the entropy pool is low. If there's a need for randomness
with that stronger guarantee of entropy, that seems like it would want an
asynchronous API in order to wait for entropy (akin to /dev/random).
--
Glenn Maynard
, like reading
/proc/sys/kernel/random/entropy_avail. That at least suggests it's
sufficient for securely generating keys, without more complex APIs like
exposing the amount of entropy that was available.
--
Glenn Maynard
an async version of this API--you don't want to
write to the array asynchronously, while other code is running--but nothing
unreasonable.)
--
Glenn Maynard
from regular spaces.
--
Glenn Maynard
a caption into an email to an editor, or a
version control diff email, and so on. Because of these sorts of
cases, I'd continue to use nbsp; in HTML and not the Unicode
character even if editors handled it better.
--
Glenn Maynard
1 - 100 of 497 matches
Mail list logo
