Pierre-Antoine LaFayette wrote:
So in HTML a user can have:
img src=moz-icon://unknown?size=16 alt=File:/
If opened in Firefox, the browser will provide an icon for the filetype. I
think this is a useful scheme that other browsers could benefit from. There
is a chrome://fileicon/path scheme
On Tue, Jan 26, 2010 at 1:01 PM, Lachlan Hunt lachlan.h...@lachy.id.au wrote:
Pierre-Antoine LaFayette wrote:
So in HTML a user can have:
img src=moz-icon://unknown?size=16 alt=File:/
If opened in Firefox, the browser will provide an icon for the filetype. I
think this is a useful scheme
Yes, I wish to expose the platform and possibly Browser theme specific icons
to web content with the Icon URI scheme. The idea is to allow the Icon URI
scheme to be used anywhere an image is specifiable by a data URI in HTML and
JavaScript. This will allow web content to emulate the look and feel
Web Applications Working Group,
The XQuery working group have asked me to submit the following comments
on their behalf, in review of Indexed Database API (Editor's Draft 26
January 2010):
1) This document does not seem to have any overlap with the XQuery
specifications themselves.
2) The
On Sun, Jan 24, 2010 at 8:04 AM, Juan Lanus juan.la...@gmail.com wrote:
** Locking
What's wrong with file locking?
Rob O'Callahan answered that:
One problem is that mandatory locking is not supported on Mac or most Linux
installs.
Quite right Bob. But still the lock is the way to go. At
These are notes that we collected both from reviewing the spec (editor's draft
up to Jan 24th) and from a prototype implementation that we are working on. I
didn't realize we had this many notes, otherwise I would have been sending
intermediate notes early. Will do so next round.
1. Keys and
On Jan 26, 2010, at 7:08 AM, Pierre-Antoine LaFayette wrote:
Yes, I wish to expose the platform and possibly Browser theme specific icons
to web content with the Icon URI scheme. The idea is to allow the Icon URI
scheme to be used anywhere an image is specifiable by a data URI in HTML and
Hi Pablo,
Great work and excellent feedback. I will take a little bit of time to
digest and respond.
Nikunj
On Jan 26, 2010, at 12:47 PM, Pablo Castro wrote:
These are notes that we collected both from reviewing the spec
(editor's draft up to Jan 24th) and from a prototype implementation
Based on the last round of feedback [1], I've updated the proposal for
Selector-based mutation events (which I keep calling fast mutation events
for some reason...). Doug, I'm sure you're hard at work on a better acronym...
In this edition, I expanded the background sections and enumerated many
(Are these comments going into someone's queue somewhere, or should I be
concerned there was no further response? I ask because I'd kind of like to
start checking .idl files into WebKit. :-)
On Fri, Jan 22, 2010 at 9:53 AM, Jeremy Orlow jor...@chromium.org wrote:
In general, sounds good to
On Wed, Jan 27, 2010 at 5:38 AM, Juan Lanus juan.la...@gmail.com wrote:
Quite right Bob. But still the lock is the way to go. At least as of today.
HTML5 might be mainstream for the next 10 years, starting rather soon.
In the meanwhile OSs will also evolve, in a way that we can't tell
now.
Hi Jeremy,
I have edited the spec to use IDB as the prefix of every interface it
defines.
Nikunj
On Jan 26, 2010, at 6:38 PM, Jeremy Orlow wrote:
(Are these comments going into someone's queue somewhere, or should
I be concerned there was no further response? I ask because I'd
kind of
Folks,
Thanks to the much feedback from various developers, the WebTiming
specs has undergone some
major revision. Timing info has now been extended to page elements and a
couple more interesting timing
data points are added. The draft is up on
http://dev.w3.org/2006/webapi/WebTiming/
13 matches
Mail list logo
