those discussions somewhat separate, because stuff
> added to serve one purpose rarely is a good fit for the other. (I have a
> long list of things that I dislike because they are used for multiple
> purposes and serve neither function well ... starting with the source
> address of an IP packet .. but I digress.)
The discussion hasn't changed--splitting threads just tends to fragment the
discussion.
--
Glenn Maynard
rbitrary IP and port. It should
only be possible to send packets to an IP which has handshaked a port via
ICE. Obviously, this needs to be confirmed by an expert in these protocols.
*If* that's accurate, does that remove the masking requirement? 16 bytes
per packet is significant overhead to pay if it's not needed.
--
Glenn Maynard
does seem to perform this check. ICE's "basic connectivity check"
(RFC5245 sec2.2) is a STUN packet each peer sends to the other. That packet
contains a 96-bit transaction ID (RFC5389 sec6) which is echoed back in the
other peer's STUN response. I could be misinterpreting the protocol.
--
Glenn Maynard
t; > though, these are all well-invented wheels...)
>
> Yep.
>
> Adam
>
Actually, I was wrong about padding: it's a CBC thing, CTR doesn't need it.
With CTR, the length of the ciphertext determines the length of the
plaintext directly.
--
Glenn Maynard
and IPsec, but if so I don't know what they are.
> Then the MAC would fail because we're using encrypt-then-mac.
That works if the MAC includes the entire packet, including not just C (the
encrypted data) but also the packet headers (the sequence number).
--
Glenn Maynard
he nonce to match arbitrary sequence numbers. For
example, if the nonce is 5 and the sequence number is 10, an attacker could
repeat the packet's contents by creating a new sequence number (say, 500),
and then fabricating a nonce N where 500^N = 5^10, resulting in the same
counter value.
--
Glenn Maynard
ounter-value << 16 | offset-in-packet". The particulars of the
AES-128-CTR algorithm should be defined--the NIST reference only defines AES
itself, not the CTR mode. It also needs to specify a padding method, eg.
PKCS7 or ANSI X.923, to pad to AES's block size of 16 bytes. (Again,
though, these are all well-invented wheels...)
--
Glenn Maynard
ing no mechanism exists to negotiate nonce changes for
long-lived connections.
[2] 48 bits matches DTLS. This is big enough to avoid problems with
long-lived connections, but not so big as to waste space in the
packet.
--
Glenn Maynard
a more complete compression interface. That doesn't solve it
nicely right now, since there's not yet an API to get a Blob from Canvas
(there's only toDataURL), but that'd be a separate problem (and is needed
anyway, eventually). I don't have a strong feeling for whether that
(uploads).
Using PNG even for uncompressed data does sound better than BMP.
Alpha channel, 16bpp color, color management, etc. can all still
apply.
--
Glenn Maynard
x27;s reply)
Canvas users would also want to be able to load a pasted image without
redundant compression and decompression steps.
--
Glenn Maynard
html(onreadystatechange
>> fired)
>>
>
> In IE9 RC1, both those tests fired the "onreadystatechange: loaded" alert.
> Isn't that expected behavior? What led you to believe it was broken?
>
My IE9 VM is out of date, apparently. I'm guessing they removed this and
then restored it. I'll check for an update--thanks for checking this.
--
Glenn Maynard
not in the document. (onerror is,
though, which I think is a spec violation.)
http://zewt.org/~glenn/test-script-preload-onreadystatechange/standards-mode.html(onreadystatechange
not fired)
http://zewt.org/~glenn/test-script-preload-onreadystatechange/quirks-mode.html(onreadystatechange
fired)
--
Glenn Maynard
It seems like IE9 only fires onreadystatechange on scripts which aren't in
the document when in quirks mode. If the HTML5 doctype is present, it'll
still load scripts before inserting them into the document, but
onreadystatechange doesn't seem to be fired. Can someone confirm?
--
Glenn Maynard
On Wed, Mar 2, 2011 at 1:21 PM, Nicholas Zakas wrote:
> After chatting a bit with Boris, it seems important for implementation that
> a
le directory is deeply nested all by itself--it looks like
the typical location for this data would be something like:
C:\Documents and Settings\Glenn\Local Settings\Application
Data\Google\Chrome\User Data\Default\Storage
That's past 100 characters already.
--
Glenn Maynard
f you're to run
the above prompt from a timeout, you need to know that *before* you call
prompt(), since you don't want a timeout if the async API is supported.
The pattern in new APIs like IDB and FileAPI is to have separate sync and
async interfaces, not overloaded behavior, eg:
promptAsync(message, default, callback);
Better off just leaving this crusty old API in the legacy bin, though.
--
Glenn Maynard
it the way I
did: as a list of specific changes to the spec, which nobody has
attempted to do for the other proposals. This approach avoids
changing the "prepare a script" steps at all; I think the other
proposals would need non-obvious changes there.
--
Glenn Maynard
events. (Fetching scripts without them being in any document breaks
this, which is a serious problem with the other proposals.)
- Once a node has had its "already started" flag set, the "prepare a
script" steps never run on it again, even if the node is cloned.
Clearing the "pending-execution" flag follows this, preventing an
already-prepared script from being executed twice when cloned.
- For feature detection:
typeof(document.createElement("script").noexecute) == "boolean".
--
Glenn Maynard
t a more
>> detailed recap.
>>
>
> I don't think I do. Proposal 3 sounded fine to me last I saw it.
>
Including execute() being synchronous, raising SyntaxError exceptions for
parse errors, and uncaught exceptions from the script being propagated up
through execute() to its caller?
--
Glenn Maynard
On Tue, Feb 22, 2011 at 9:24 PM, Boris Zbarsky wrote:
> On 2/22/11 8:54 PM, Glenn Maynard wrote:
>
>> 3. My (and Nicholas's previous) proposal: Script elements are fetched when
>> inserted into the DOM[1]. An event is dispatched when the script has been
>> fetched
oesn't become a requirement.
[2] The proposal suggested "onpreload", but there's no actual need for the
"script fetched" event to be tied to preloading. I think "onfetch" makes
more sense.
--
Glenn Maynard
rting from bytes to floating-point and back to bytes anyway.
That's just introducing a lot of new ways to get things wrong.
--
Glenn Maynard
pturing them. To do that, you'd
have to insert the node into the DOM, but inserting it into the DOM
implies the script will be executed. This is a major break in event
behavior. (It's worse than with images, since with images you can
just put them in a hidden container in the document.)
--
Glenn Maynard
specific use
cases), but that was another rationale. I think it was also intended to
avoid encoding 8-bit data in a UTF-16 string.
--
Glenn Maynard
eed to be able to deal with this for images, that
bridge is already crossed...
--
Glenn Maynard
for copyright notices and so on, which this doesn't
cover.
--
Glenn Maynard
he above would be
rendered as "and so onetc." I guess a :before { content: " " } would
work well enough.)
--
Glenn Maynard
hough;
stripping the comments for distribution is a simple workaround, if not
exactly ideal.
--
Glenn Maynard
the case for
readyState seems more compelling (though I need to review the feature
detection question in more depth). Also, again, your example code
doesn't work the way it looks like it's intended to, since
successCallback will be called before the loaded scripts have actually
been executed.
--
Glenn Maynard
the only
case; for example, pasting 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 in HTML and not the Unicode
character even if editors handled it better.
--
Glenn Maynard
ble from regular spaces.
--
Glenn Maynard
entropy much more robustly than
the old hacks of mixing in interrupt timing and mouse movement, eliminating
the old problem of filling the entropy buffer from a first-time cold boot.)
--
Glenn Maynard
king 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
er tricks, 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
ithout
worrying about it returning low-entropy randomness.
I think it makes more sense 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
CSS animation. The canvas
> > tag. Etc. We don't say because it hasn't been done yet therefore we
> > can't try or can't spec it.
>
> We do when 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
sing, but I also don't know why anyone would want to
set preload to false.
Between the readyState proposal and the current preload proposal (with no
execute method), I prefer readyState. 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
On Sun, Feb 13, 2011 at 6:44 PM, Kyle Simpson wrote:
> I've compiled a WHATWG Wiki page detailing both Nicholas' most recent (and
> simplified) proposal (v2.1), as well as mine:
>
> http://wiki.whatwg.org/wiki/Script_Execution_Order_Control
>
> In essence, the two are somewhat converging, though
On Fri, Feb 11, 2011 at 7:31 PM, Glenn Maynard 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 demonstr
ample, since the indentation was, I think, mangled
during the paste into the document.
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 feature
checking (in a simpler way).
--
Glenn Maynard
On Fri, Feb 11, 2011 at 3:24 PM, Ian Hickson 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 work
o implement deferred exec for
> awhile.
>
Note that I didn't mean to propose changing existing event semantics; I
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
by the specs (and used as consistently as
is reasonable), or not used at all and those specs should be changed.
--
Glenn Maynard
function exists to check support.
Otherwise, you have to make a dummy call to check 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
On Wed, Feb 9, 2011 at 10:06 AM, Kyle Simpson wrote:
> readyState
There's one other fundamental limitation of the readyState approach which I
forgot about: it's impossible to defer execution of inline scripts. It
inherently only works for external scripts.
ces, since it seemed like most of the
debate was tangental--the main relevant point seems to be guaranteeing
browsers retain the freedom to parse scripts at whatever point they want
(during load, after load, during idle time, or upon execution), which I
think everyone is strongly agreed on.
--
Glenn Maynard
comments), and (putting aside the --> token conflict,
which will go away if the timestamp separator is changed) can
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 Wed, Feb 9, 2011 at 2:46 AM, Glenn Maynard wrote:
> - Just for comparison:
#x27;t always tell in advance. Prefetching 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
I'm losing track in the noise of what the fundamental disagreements are--if
there even are any. I think the original proposal is a very good place to
start:
- Add a "noexecute" attribute to SCRIPT, which instructs the browser to
retrieve the script without executing it. noexecute implies async.
p browsers, as web apps
become larger and more complex--but it's still essentially the same
optimization.)
--
Glenn Maynard
ry. (It could also cause
other problems, eg. allowing webpages to flush a user's kernel's entropy
buffer and causing separate pages to compete for entropy data.)
--
Glenn Maynard
er without causing recursion, but you'll receive the 4ms clamping
unnecessarily. It might be possible 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
If the two differ, there should be a separate method
to do just that, including any browser-specific heuristics and so on. That
way, scripts can get the best possible text representation available, rather
than the most precisely-defined one, when that's what they want.
--
Glenn Maynard
allations 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
On Mon, Jan 31, 2011 at 7:12 PM, Ian Hickson wrote:
> On Mon, 31 Jan 2011, Glenn Maynard wrote:
> > On Mon, Jan 31, 2011 at 6:46 PM, Ian Hickson wrote:
> >
> > > > That's far too generic for servers to default to mapping *.manifest
> > > > to tex
icrosoft's mistake is using such a generic name--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 8:34 AM, Simon Pieters wrote:
> On Mon, 31 Jan 2011 14:26:49 +0100, Glenn Maynard wrote:
>
> On Mon, Jan 31, 2011 at 7:17 AM, Simon Pieters wrote:
>>
>> See http://lists.w3.org/Archives/Public/public-html/2009Jun/0395.html
>>>
>>
generic of a name to
> > me, though). This way, web server developers could add 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
or
> 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
, it should probably
always capitalize "JOHN'S", regardless of how selection works on the
platform.
It's also worth pointing out that, at least in Firefox in Windows, there are
different modes of word selection. If I double-click and drag to select
text over "John's", the apostrophe is excluded, where it's included with
keyboard navigation.
--
Glenn Maynard
d to your other
post about 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
ultiple Ranges per Selection?
>
For what it's worth, the only thing I've noticed this used for is hijacking
copy events and adding ads to copied text (by appending a hidden div to the
selection), which is infuriating. Unfortunately, methods of doing this
without ranges do exist; this jus
On Mon, Jan 24, 2011 at 6:54 PM, Tab Atkins Jr. wrote:
> On Mon, Jan 24, 2011 at 3:45 PM, Glenn Maynard 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 to
s
its own contrast. I've used the same thing in game UIs rendered on top of a
moving background. Tangental, but I figured I'd point it out.
--
Glenn Maynard
o the
two conversations don't swap places.
I mention this because it comes to mind as something well-authored,
well-rendered subtitles need to get right, 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
n I load English text in Firefox and force SJIS: everything
is rendered in MS 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
really want two lines,
> they should use two cues. In practice, 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
tag.
--
Glenn Maynard
I 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 Maynard
ata to stop autoloading. That's a minor hack,
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
ou can request that it be limited (preload=buffer) or
unlimited (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
is requirement
would be after the new playback position is clamped to seekable, not
before.)
That guarantees that:
video.seekMode = "fast";
function f() {
video.currentTime = 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
quot; button should use "accurate".
Even in the primary use case of a seek bar, it's not always wanted.
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
rs fast
(and less precise) methods over slow, accurate ones. The browser is
free to ignore it, even heuristically (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
der.readAsBinaryString(blob);
}
video.src = createObjectURL(b);
--
Glenn Maynard
sted time than what the
> inexact seek would provide?
The above would also answer your question: seeking would be unaffected
by the current play cursor.
--
Glenn Maynard
7;s no way for whoever's reading
the stream to block. For example, if you're reading a 1 GB video on a
phone 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
On Thu, Jan 20, 2011 at 1:16 PM, Zachary Ozer wrote:
> On Thu, Jan 20, 2011 at 4:19 AM, Glenn Maynard wrote:
>> I think that pausing shouldn't affect read-ahead buffering behavior. I'd
>> suggest another preload value, preload=buffer, sitting between "metadata&q
(especially important if you have lots of videos
on the same page), allows selecting whether 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
g that most of the time all people care about is
"read ahead a little" vs. "read ahead a lot", and publishers shouldn't need
to figure out the right buffer size to use for the former (and very likely
getting it wrong).
--
Glenn Maynard
annoying than loading a browser session and
having a video start playing somewhere. This is probably a significant use
case for the "tab visibility" proposal.
--
Glenn Maynard
ouldn't be
implemented because not doing so makes the browser look better to the user,
at least on first impression I'm not so sure. I think that's only true if
it's impossible to implement capped prebuffering reliably, but I don't think
anyone's made that argument.
--
Glenn Maynard
en it suggested that any difficulty of
doing this is due to HTTP. If you think it is, it'd be helpful to explain
further.
--
Glenn Maynard
On Tue, Jan 18, 2011 at 5:00 PM, Boris Zbarsky 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
On Tue, Jan 18, 2011 at 8:40 AM, Boris Zbarsky 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, eit
> being loaded into the application.
>
Note that this doesn't actually seem to include the amount of time to
buffer; bufferTimeMax appears to be for live streaming only (eg.
videoconferencing and webcams) to control sync, not static videos like
YouTube.
--
Glenn Maynard
cases, the actual available
>
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 the bandwidth to stream the video or you
don't; the length of the video doesn't enter into it.
--
Glenn Maynard
On Mon, Jan 17, 2011 at 4:34 PM, Ryosuke Niwa wrote:
> On Mon, Jan 17, 2011 at 1:25 PM, Glenn Maynard wrote:
>
>> On Mon, Jan 17, 2011 at 4:15 PM, Boris Zbarsky wrote:
>>
>> > If nothing else, I'm thinking things like "I would like to buffer up
>> th
, cache is
cleared, etc. It sounds more like a FileAPI use case than a buffering
parameters one.
--
Glenn Maynard
Message" attribute on the specific
object to be transferred makes more sense.
--
Glenn Maynard
r one
> 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
; it, and then frees the 10MB allocation it just made. It takes about 5ms per
> loop iteration to run on my system (fairly high-end laptop that was new in
> July 2010). The time is split about 50-50 between the allocation and the
> memcpy.
It might be possible 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
yloads.
And there's trouble there: there's no way for the worker thread to
receive a "got your message, ready for the next one" message, unless
it returns to caller to allow those events to be delivered.
This seems like another important class of use cases for the
"synchronously handling events" thread on webapps.
--
Glenn Maynard
ng (you
can't blit images to the canvas that way, since you don't have the
Canvas interface), but it may be enough for your case.
--
Glenn Maynard
application, perhaps requiring
one-time 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
ly useful for files with infrequent keyframes.
--
Glenn Maynard
"nobody's using them 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 Maynard
hould be removed, 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
On Sun, Jan 9, 2011 at 4:10 PM, Bjartur Thorlacius wrote:
> On 1/9/11, Glenn Maynard 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 the
401 - 500 of 534 matches
Mail list logo
