On Wed, 14 Dec 2011 08:36:44 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
John Jensen here at Mozilla has been doing some web crawling trying to
find what barewords are used in on* attributes.
Awesome!
What I have so far as a result is a list of about 1.7 million barewords
used across
On 12/14/11 3:01 AM, Simon Pieters wrote:
What I have so far as a result is a list of about 1.7 million
barewords used across several tens of thousands of pages.
Do you have a more accurate figure for the number of pages?
57,444 unique urls, all taken from the top 21,000 domains is all the
On Wed, 14 Dec 2011 09:15:12 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/14/11 3:01 AM, Simon Pieters wrote:
What I have so far as a result is a list of about 1.7 million
barewords used across several tens of thousands of pages.
Do you have a more accurate figure for the number of
This is great! Thanks for doing this. Can we also get stats. on new Node
methods like append, remove, etc...?
- Ryosuke
On Tue, Dec 13, 2011 at 11:36 PM, Boris Zbarsky bzbar...@mit.edu wrote:
John Jensen here at Mozilla has been doing some web crawling trying to
find what barewords are used
http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0183.html is the
latest version as far as I know.
- Ryosuke
On Wed, Dec 14, 2011 at 12:57 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 12/14/11 3:54 AM, Ryosuke Niwa wrote:
This is great! Thanks for doing this. Can we also get stats. on
On 12/14/11 3:54 AM, Ryosuke Niwa wrote:
This is great! Thanks for doing this. Can we also get stats. on new Node
methods like append, remove, etc...?
There seem to be no hits on append in the data I have so far.
remove is used on a bunch of pages on fdc.soufun.com but nowhere else
in this
On Wed, 14 Dec 2011 03:54:25 +0100, Jonas Sicking jo...@sicking.cc wrote:
I agree we should remove it from spec!
I think we'd be fine with removing it from the Firefox implementation.
Same goes for Opera!
--
Anne van Kesteren
http://annevankesteren.nl/
On Wed, 14 Dec 2011 08:36:44 +0100, Boris Zbarsky bzbar...@mit.edu wrote:
Assuming it is (very likely), where's a good place to stick a 7MB
compressed file?
Email it to www-arch...@w3.org.
--
Anne van Kesteren
http://annevankesteren.nl/
On Wed, 14 Dec 2011 10:06:55 +0100, Ryosuke Niwa rn...@webkit.org wrote:
http://lists.w3.org/Archives/Public/www-dom/2011OctDec/0183.html is the
latest version as far as I know.
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-methods
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
adria...@microsoft.com wrote:
At TPAC [1,2] I described our proposal for adding an isReusable flag to
createObjectURL. A common pattern we have seen is the need for a blob URL
for a single use (for example, loading into an img element) and then
On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman adria...@microsoft.com
wrote:
At TPAC [1,2] I described our proposal for adding an isReusable flag to
createObjectURL. A common pattern we have seen is the need for a
On Wednesday, December 14, 2011 at 1:03 AM, Adrian Bateman wrote:
The current spec requires the opaque string in Blob URLs to be at least
36 characters in length [1]. Our implementation doesn't currently use a
UUID and the length of the string is shorter than 36 characters. While
I have no
On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman adria...@microsoft.com wrote:
At TPAC [1,2] I described our proposal for adding an isReusable flag to
createObjectURL. A common pattern we have seen is the need for a blob URL
for a single use (for example, loading into an img element) and then
On Wednesday, December 14, 2011 3:38 AM, Marcos Caceres wrote:
On Wednesday, December 14, 2011 at 1:03 AM, Adrian Bateman wrote:
The current spec requires the opaque string in Blob URLs to be at least
36 characters in length [1]. Our implementation doesn't currently use a
UUID and the
On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote:
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
adria...@microsoft.com wrote:
This means that you can do something like:
imgElement.src = URL.createObjectURL(blob,false)
and not worry about having to call
On Wed, Dec 14, 2011 at 11:31 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Tue, Dec 13, 2011 at 4:52 PM, Adrian Bateman adria...@microsoft.com
wrote:
At TPAC [1,2] I described our proposal for adding an isReusable flag to
createObjectURL. A common pattern we have seen is the need for a
On Wednesday, December 14, 2011 2:26 AM, Jonas Sicking wrote:
On Wed, Dec 14, 2011 at 1:42 AM, Anne van Kesteren ann...@opera.com
wrote:
On Wed, 14 Dec 2011 01:52:04 +0100, Adrian Bateman
adria...@microsoft.com wrote:
This means that you can do something like:
imgElement.src =
On Wed, Dec 14, 2011 at 11:27 AM, Adrian Bateman adria...@microsoft.comwrote:
On Wednesday, December 14, 2011 1:43 AM, Anne van Kesteren wrote:
imgElement.src = blob
3. It's not very obvious what the lifetime of the blob should be if it goes
out of scope after this happens.
This, at
On Wednesday, December 14, 2011 at 2:15 PM, Arthur Barstow wrote:
Anne and Ms2ger would like to publish a new WD of DOM4 and this is a
Call for Consensus to do so.
The latest ED of this doc follows (it doesn't yet reflect a W3C Status
section):
oops, wrong explain, instead see
http://www.w3.org/2008/xmlsec/Drafts/xmldsig-core-11/explain.html 6.1, 6.2*,
6.3.1, 6.4.2 (e.g. move away from SHA-1)
regards, Frederick
Frederick Hirsch
Nokia
On Dec 14, 2011, at 2:00 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
Art
I think switching
So what about option #2 below? -AB
On 12/14/11 2:00 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
Art
I think switching the dependency to XML Signature 1.0 is a bad idea, noting
that 1.1 has fixed errors, and addressed security vulnerabilities, including
updates to algorithms (other than
I'm suggesting we let the XMLSec PAG conclude before taking that step (or
another possibility), but obviously that depends on the PAG timeline going
forward.
regards, Frederick
Frederick Hirsch
Nokia
On Dec 14, 2011, at 2:08 PM, Arthur Barstow wrote:
So what about option #2 below? -AB
On Tuesday, December 13, 2011 at 9:14 PM, Philippe Le Hegaret wrote:
On Tue, 2011-12-13 at 13:14 -0500, Arthur Barstow wrote:
An other one was for the Director to decide to move the document forward
anyway because W-DigSig doesn't depend on ECC.
Thomas, any suggestion?
I personally
We've only recently uploaded the draft for the Streams API and shared it with
the Working Group [1], which also has the new location.
There is a conversation currently taking place in the media capture WG [2]
discussing how to better align Stream and MediaStream. I think it's an
interesting
this seems logical, in that any outcome for ECC (ranging from continued
inclusion to removal) would have no impact on widget signature given this lack
of specific dependency.
regards, Frederick
Frederick Hirsch
Nokia
On Dec 14, 2011, at 2:12 PM, ext Marcos Caceres wrote:
On Tuesday,
On Wed, 14 Dec 2011 20:17:01 +0100, Feras Moussa fer...@microsoft.com
wrote:
We've only recently uploaded the draft for the Streams API and shared it
with the Working Group [1], which also has the new location.
There is a conversation currently taking place in the media capture WG
[2]
On 11/29/2011 07:58 AM, Ryosuke Niwa wrote:
Hi all,
I've been looking into the command element
http://dev.w3.org/html5/spec/Overview.html#the-command-element and how
a toolbar might be built
http://dev.w3.org/html5/spec/Overview.html#building-menus-and-toolbars by
them in the last several
This certainly WFM.
TLR, PLH - what needs to be done to make this happen?
-AB
On 12/14/11 2:21 PM, Hirsch Frederick (Nokia-CIC/Boston) wrote:
this seems logical, in that any outcome for ECC (ranging from continued
inclusion to removal) would have no impact on widget signature given this
On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote:
We can certainly talk through some of these issues, though the amount of
work we'd need to do doesn't go down. Our proposal is a small change to
the lifetime management of the Blob URL and was relatively simple (for
us) to
On Wed, 14 Dec 2011, Adrian Bateman wrote:
On Wednesday, December 14, 2011 10:46 AM, Glenn Maynard wrote:
We can certainly talk through some of these issues, though the amount of
work we'd need to do doesn't go down. Our proposal is a small change to
the lifetime management of the Blob URL
Hi all,
as the PAG chair of this XMLSEC PAG, let me tell you that support from the
industry in sorting this out was low so far. What I heard through the
grapevine was more or less: We know, but we can't tell you.
For the moment, W3C is asking for cost estimates to figure out what most of
On 12/14/11 3:15 AM, Boris Zbarsky wrote:
Yeah, understood. Working on getting that description.
Ok. It's just a simple spider that starts with the list at
http://code.google.com/p/httparchive/source/browse/trunk/lists/All.txt
and for each of those urls loads the url itself and then follows
On Wed, Dec 14, 2011 at 4:27 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 14 Dec 2011 03:54:25 +0100, Jonas Sicking jo...@sicking.cc
wrote:
I agree we should remove it from spec!
I think we'd be fine with removing it from the Firefox implementation.
Same goes for Opera!
Jonas
On Wednesday, 14 December 2011 at 21:06, Rigo Wenning wrote:
Hi all,
as the PAG chair of this XMLSEC PAG, let me tell you that support from the
industry in sorting this out was low so far. What I heard through the
grapevine was more or less: We know, but we can't tell you.
For the
On 12/14/11 5:41 PM, Jonas Sicking wrote:
This doesn't really tell us weather access to expandos on the
element/form is strictly needed or not, right?
Yes. The data I have does nothing to address that question
-Boris
On Tue, Dec 13, 2011 at 11:36 PM, Boris Zbarsky bzbar...@mit.edu wrote:
John Jensen here at Mozilla has been doing some web crawling trying to find
what barewords are used in on* attributes.
What I have so far as a result is a list of about 1.7 million barewords used
across several tens of
On Wed, 14 Dec 2011, Adrian Bateman wrote:
[...] the first dereference of the URL revokes it.
This means that you can do something like:
imgElement.src = URL.createObjectURL(blob,false)
and not worry about having to call URL.revokeObjectURL to release the
Blob.
I think it's dangerous
On Wed, Dec 14, 2011 at 7:40 PM, Ian Hickson i...@hixie.ch wrote:
I think the better solution is to have implementations make keeping object
URLs defined be very cheap, so that nobody needs to ever release them.
The problem isn't the cost of the URL mapping, it's the cost of keeping the
On Wed, 14 Dec 2011, Glenn Maynard wrote:
The problem isn't the cost of the URL mapping, it's the cost of keeping
the backing Blob around. If you drag around Google Maps for a long
time, and it used object URLs to load its tile images, it'd be very bad
if the browser had to keep every
On 12/14/2011 4:55 PM, Ian Hickson wrote:
On Wed, 14 Dec 2011, Glenn Maynard wrote:
The problem isn't the cost of the URL mapping, it's the cost of keeping
the backing Blob around. If you drag around Google Maps for a long
time, and it used object URLs to load its tile images, it'd be very bad
On Wed, 14 Dec 2011, Jonas Sicking wrote:
On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 14 Dec 2011, Glenn Maynard wrote:
The problem isn't the cost of the URL mapping, it's the cost of
keeping the backing Blob around. If you drag around Google Maps for
a
On 12/14/2011 5:10 PM, Ian Hickson wrote:
On Wed, 14 Dec 2011, Jonas Sicking wrote:
On Wed, Dec 14, 2011 at 4:55 PM, Ian Hicksoni...@hixie.ch wrote:
On Wed, 14 Dec 2011, Glenn Maynard wrote:
The problem isn't the cost of the URL mapping, it's the cost of
keeping the backing Blob around. If
On Wed, Dec 14, 2011 at 4:55 PM, Ian Hickson i...@hixie.ch wrote:
On Wed, 14 Dec 2011, Glenn Maynard wrote:
The problem isn't the cost of the URL mapping, it's the cost of keeping
the backing Blob around. If you drag around Google Maps for a long
time, and it used object URLs to load its
On 12/14/11 7:55 PM, Ian Hickson wrote:
Browsers do keep them around for the lifetime of the page, in their HTTP
cache.
Browsers limit the size of the HTTP cache and evict as needed.
-Boris
44 matches
Mail list logo
