Hixie,
FYI, comments back from (nameless) IESG designated expert on the
multipart/x-mixed-replace media type description in the HTML spec.
--Mike
- Forwarded message from Amanda Baber via RT iana-m...@iana.org -
Subject: [IANA #598700] Registration for multipart/x-mixed-replace media
Hixie,
Comments from IANA review of the application/xhtml+xml mime type. (Note
that I never got an actual response back -- only this and a previous
reminder, so forwarding this to you as-is instead.)
--Mike
- Forwarded message from Amanda Baber via RT iana-m...@iana.org -
Subject:
Hixie,
Comments from IANA on text/cache-manifest. (This is the last one for now.)
--Mike
- Forwarded message from Amanda Baber via RT iana-m...@iana.org -
Subject: [IANA #598702] Registration for text/cache-manifest media type
From: Amanda Baber via RT iana-m...@iana.org
To:
On Wed, Oct 17, 2012 at 7:23 PM, Ian Hickson i...@hixie.ch wrote:
I haven't added this, because contenteditable= is only truly useful with
scripting enabled, and it's basically one line of script to support
shunting the current value into a hidden input.
For me, it's also useful even just as
Any WebKit folks want to weigh in on this one? Ian, what do you think from
a spec perspective?
On Tue, Oct 9, 2012 at 4:59 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 10/9/12 9:45 AM, Bobby Holley wrote:
I'd like to change Gecko to implement the alternate behavior - that is
to say, making
The dialog.showModal() function defines steps for setting focus [1].
However, if the dialog does not contain any elements with the autofocus
attribute, then step 9 says to abort the steps and not set focus. It seems
problematic if the dialog is modal and does not have focus. How would a
keyboard
To answer these questions, you need to reverse engineer the behavior
of various user agents, compare them, and then pick a consensus
behavior that ideally is both interoperable between user agents and
compatible with existing content.
I'm happy to change WebKit to such a consensus behavior, but I
On Mon, 22 Oct 2012, Scott González wrote:
The dialog.showModal() function defines steps for setting focus.
However, if the dialog does not contain any elements with the autofocus
attribute, then step 9 says to abort the steps and not set focus. It
seems problematic if the dialog is modal
On 10/22/12 1:38 PM, Adam Barth wrote:
To answer these questions, you need to reverse engineer the behavior
of various user agents, compare them
Bobby did that already, in the first mail in this thread. See
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0014.html
in case
On Mon, 10 Sep 2012, Dean Jackson wrote:
I propose adding a new method to HTMLCanvasElement:
interface HTMLCanvasElement : HTMLElement {
boolean supportsContext(DOMString contextId, any... arguments);
};
supportsContext takes the same parameters as getContext, and simply
returns
On Mon, Oct 22, 2012 at 6:36 PM, Ian Hickson i...@hixie.ch wrote:
If you really want to protect users from the behavior of pages, you'd
really need to make creating the context cheap. For example, don't
switch to a high-power GPU until the page actually draws something,
and--since many
On Fri, Oct 19, 2012 at 3:43 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 19 Oct 2012, Elliott Sprehn wrote:
I was working on a bug recently where authors had complained about
WebKit's behavior where clicking a scrollbar unfocuses the
activeElement. What's particularly quirky is that the
On Sat, Oct 20, 2012 at 4:55 PM, Ian Hickson i...@hixie.ch wrote:
On Sat, 20 Oct 2012, Aryeh Gregor wrote:
On Thu, Oct 18, 2012 at 1:23 AM, Ian Hickson i...@hixie.ch wrote:
Incidentally, it seems to use a WebKit-specific plaintext-only value.
Should we spec that? Aryeh? It's filed as:
On Mon, 22 Oct 2012, Glenn Maynard wrote:
On Mon, Oct 22, 2012 at 6:36 PM, Ian Hickson i...@hixie.ch wrote:
If you really want to protect users from the behavior of pages,
you'd really need to make creating the context cheap. For example,
don't switch to a high-power GPU until the
14 matches
Mail list logo
