My object is somewhat different. I think it's useful for the readability
use-case (and the other proposed solutions are mostly bad jokes), but it
doesn't strike me that this give you much default UI and doesn't plumb
through any new low-level capability.
In that vein, I wonder why it's not being
On Wed, Aug 24, 2011 at 8:36 AM, Scott Graham scot...@chromium.org wrote:
Hi,
I wanted to let everyone know that I propose to add a new feature
flag, JOYSTICK. http://webkit.org/b/66859
This flag will enable an API and events for accessing joysticks and
related devices. There's a prototype
On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton johnjbar...@johnjbarton.com
wrote:
From: Alex Russell slightly...@chromium.org
We observe that web developers are attempting to use DOM in both
structural
(semantic or component-oriented) and visual ways inside the same
document.
I would
On Wed, Jun 29, 2011 at 5:01 AM, Geoffrey Garen gga...@apple.com wrote:
On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote:
On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com
wrote:
Hi Dmitri.
Since this is an experimental API, here are the actual API names we
want to
On Mon, Jun 27, 2011 at 5:49 PM, Ojan Vafai o...@chromium.org wrote:
Can you give an example of a smooth UI that you'd need the more complex API
for? When I think of the existing mail and chat apps in iOS/Android that
I've use, input type=contacts could give just as smooth a UI as the
On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai o...@chromium.org wrote:
Is there a document that lists the use-cases for this API? I couldn't find
anything from a quick glance through the DAP working group's mailing list
archive. A list of use-cases would help evaluate whether this is the best
On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen gga...@apple.com wrote:
Some of us had a somewhat crazy idea to rewrite much of the editing code
(e.g. document.execCommand) in JavaScript.
Pros:
-Ensures that the APIs we expose to the web are at least good enough for our
own editing code
Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.
On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman micha...@google.com wrote:
In webcore, should we use the same impl on all platforms rather than use
cryptdll on windows
On Tue, Apr 13, 2010 at 11:39 PM, David Levin le...@google.com wrote:
On Tue, Apr 13, 2010 at 11:35 PM, Adam Barth aba...@webkit.org wrote:
Ah, sorry, I meant to the point where the library was integrated with
the various build systems, etc. Maybe that's already possible today.
I haven't
On Tue, Nov 17, 2009 at 3:00 PM, James Robinson jam...@google.com wrote:
On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi l...@mozilla.com wrote:
Good people of Webkit!
We'd all like for the web to be faster, and therefore I'd love your feedback
on my proposal — it would be great to see
On Wed, Aug 26, 2009 at 10:47 AM, Ojan Vafaio...@chromium.org wrote:
On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote:
Hi everyone,
Recently at Apple we've been considering our plans to implement new HTML
Lots of stuff on the web is best-effort, particularly when system
integration is the point. I'm not sure that saying the experience
will be different changes what semantics should be available to
authors in any way.
Regards
On Wed, Aug 26, 2009 at 3:25 PM, Peter Kastingpkast...@google.com wrote:
After a discussion this morning about the potential for parallel CSS
layout with Erik Aarvidson, he pointed out a group at Berkeley doing
research in this area:
http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/
The bits that jumped out to me were:
* the source is available [0]
The PDF handling stuff is related to a mimetype filter. The web server
sends a particular mime type along with each document, and if it's not
something that the browser knows how to deal with directly, it'll
interrogate all of its plugins to see if they want to handle it. When
plugins are
14 matches
Mail list logo
