On Wed, May 2, 2012 at 2:07 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 02 May 2012 13:46:27 -0700, Jonas Sicking jo...@sicking.cc wrote:
I certainly agree that it would be better to move the definition of
when to throw exceptions into the prose for each function and
attribute, but
On Wed, May 2, 2012 at 4:57 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I would think that disabling cut/copy/paste would apply to main menus too,
not just context menus. Most people I know who use menus for this (which is
precious few, btw, for the most part people I know seem to use keyboard
On Thu, May 3, 2012 at 12:44 AM, Ojan Vafai o...@chromium.org wrote:
As I've said before, I don't think command/value should be restricted to
contentEditable beforeInput/input events. I don't see any downside to making
command, value and text all available for all three cases. It simplifies
On Thu, 03 May 2012 07:56:49 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Wed, May 2, 2012 at 2:07 PM, Anne van Kesteren ann...@opera.com
wrote:
On Wed, 02 May 2012 13:46:27 -0700, Jonas Sicking jo...@sicking.cc
wrote:
I certainly agree that it would be better to move the definition of
Hi All,
The issue of bug 14404 came up at the WebApps face-to-face today. I
believe it's now the only remaining non-editorial bug. Since we've
tried to fix this bug a couple of times in the spec already, but it
still remains confusing/ambigious, I wanted to re-iterate what I
believe we had
On Thursday, 3 May 2012 at 09:00, Simon Pieters wrote:
On Thu, 03 May 2012 07:56:49 +0200, Jonas Sicking jo...@sicking.cc
(mailto:jo...@sicking.cc) wrote:
On Wed, May 2, 2012 at 2:07 PM, Anne van Kesteren ann...@opera.com
(mailto:ann...@opera.com)
wrote:
On Wed, 02 May 2012
Boris Zbarsky bzbar...@mit.edu skreiv Wed, 02 May 2012 20:10:24 +0200
With my used-to-maintain-a-rich-text-component hat on, I would have
preferred a property to an event as an author.
Ah, nice. In that case, my vote is certainly for a mechanism like that!
I suggest spec'ing something like
On Thu, 03 May 2012 01:34:12 -0700, Marcos Caceres w...@marcosc.com wrote:
I strongly agree, but this is not Respec's fault. It's just a
particular(ly bad) editorial style adopted by some people. There is
nothing in Respec that prevents an editor from defining the algorithms
properly and
snip
Weird, because you posted
this:
https://docs.google.com/document/d/1atsxnstVybfovkX_f6xf2P25i1NT0ilCihJuPDwYWEU/edit?hl=en_US
here: https://bugzilla.mozilla.org/show_bug.cgi?id=604039#c40
Just to be clear, I'm not trying to be aggressive or confrontational, but I
just reread my message
On Thu, 31 Mar 2011, Michael Nordman wrote:
1. Allow cross-origin HTTPS resources to be included in manifest files.
This much is actually done already in chromium impl as described on the
whatwg list.
I believe this is now done.
2. Allow a syntax to associate a page with an application
Editors, All,
During WebApps' May 2 Testing topic [1], I mentioned the A Method for
Writing Testable Conformance Requirements document [2] by Dom and
Marcos. It describes a method for writing, marking-up, and analyzing
conformance requirements in technical specifications that could
On Thursday, 3 May 2012 at 19:28, Arthur Barstow wrote:
Editors, All,
During WebApps' May 2 Testing topic [1], I mentioned the A Method for
Writing Testable Conformance Requirements document [2] by Dom and
Marcos. It describes a method for writing, marking-up, and analyzing
Marcos,
I think it would be great to update the document. While in the Webapps F2F
there were some good ideas also floated on supplemental metadata systems (e.g.
as used in WHATWG for HTML5) that don't require editors to do anything, IMO we
should also consider tooling that helps editors add
On Thu, May 3, 2012 at 1:30 AM, Jonas Sicking jo...@sicking.cc wrote:
Hi All,
The issue of bug 14404 came up at the WebApps face-to-face today. I
believe it's now the only remaining non-editorial bug. Since we've
tried to fix this bug a couple of times in the spec already, but it
still
say the single event gamepagechanged, where the event object has a
property describing the complete state of the gamepad
That seems fine to me. One caveat is that XInput on Windows (for
example) is a polling-only API anyway, so it might not be reasonable
to expect better data in the event,
This is how I've understood it as well, and I'm very OK with it :)
Getting it clear in like that would be a win.
--
Sent from my N9, excuse the top posting
On 03.05.12 01:32 Jonas Sicking wrote:
Hi All,
The issue of bug 14404 came up at the WebApps face-to-face today. I
believe it's now
On Tue, 1 May 2012, Jonas Sicking wrote:
However I think that's only a realistic option if the HTML editor is
willing to add such a parser mode to the HTML spec.
The HTML editor isn't a relevant concern here. If a spec editor won't get
out of the way and spec what the implementors want to
Here are some piecemeal thoughts on the subject of gamepads and the
gamepad spec. I havn't closely followed earlier discussions (and there
don't seem to have been any in a while), so much of this may have been
covered before.
- It should be possible to tell what's changed, not just the current
On Tue, 1 May 2012, Dimitri Glazkov wrote:
Custom tags vs. is attribute
- is attribute is awkward, overly verbose
- custom tags introduce local semantics
- perhaps start with something as simple as reserving x- prefix on
HTML tags for local semantics.
Whether it's
x-colour-picker
19 matches
Mail list logo
