On Wed, 03 Aug 2011 00:02:58 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
By this definition, it's ambiguous what needs to happen to the
documentElement's undoScope attribute, since it doesn't have an element
ancestor. I think we should just clarify that in that case, the value
is true,
You should define the IDL attribute in terms of HTML reflect:
http://whatwg.org/C#reflect And change it to be a boolean rather than a
DOMString. That would make it consistent with other boolean attributes,
such as input readonly. Then the requirements for adding and removing
the attribute
On 02/08/2011, at 11:50 PM, Ian Hickson wrote:
On Wed, 27 Jul 2011, Cameron Heavon-Jones wrote:
The mapping of tel and email inputs to a contacts list is
functional, not systematic. Might this be extended for some other
inputs: date(*), url, search etc?
This functionality may be
Use case:
A form author expects user to enter some kind of code (e.g. driver id
number, bank transfer code, product serial for warranty etc.) that is
accompanied with a barcode on paper. The end user finds it hard to
manually type the code.
Possible solution:
The form could hint the user agent
On Wed, 03 Aug 2011 16:52:03 +0200, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
What do you think?
Implementing this seems rather complicated for such a niche use. It also
seems better to let sites handle this by themselves so these physical
codes can evolve more easily.
--
Thanks for the feedback! Will fix in the next version.
On Wed, Aug 3, 2011 at 12:21 AM, Anne van Kesteren ann...@opera.com wrote:
You should define the IDL attribute in terms of HTML reflect:
http://whatwg.org/C#reflect And change it to be a boolean rather than a
DOMString. That would make
On top of that, the vast majority of these readers just translate it back to
text. It's just another input device, as barcodes are fixed (and sometimes
standardized) fonts.
See also: http://en.wikipedia.org/wiki/Barcode
--Original Message--
From: Anne van Kesteren
Sender:
On Wed, Aug 3, 2011 at 8:50 AM, Randy ra...@prowebdesign.nl wrote:
On top of that, the vast majority of these readers just translate it back to
text. It's just another input device, as barcodes are fixed (and sometimes
standardized) fonts.
True, so this is perhaps closer to an IME hint, as
On Wed, Aug 3, 2011 at 8:21 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 16:52:03 +0200, Mikko Rantalainen
mikko.rantalai...@peda.net wrote:
What do you think?
Implementing this seems rather complicated for such a niche use. It also
seems better to let sites handle this
Hixie just WONTFIXed two bugs that I thought might be of interest:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12220
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12296
Basically, HTML defines some algorithms for parsing integers, floats,
etc., which are used in converting DOM to IDL
Mike Smith has been kind enough to add a component to the W3C Bugzilla
for the editing spec, in the WebApps WG product. From now on I'll use
it for tracking feedback so I can be organized about things that I
can't fix right away. The link to file a bug is:
On Tue, Aug 2, 2011 at 2:43 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Tue, Aug 2, 2011 at 2:32 PM, Eric U er...@google.com wrote:
Could you add an example of the user typing e.g. h
... e ... l ... l ... o, via an app that's doing the DOM
modifications, using managed transactions, such that
On 11-08-03 2:55 AM, Anne van Kesteren wrote:
On Wed, 03 Aug 2011 00:02:58 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
By this definition, it's ambiguous what needs to happen to the
documentElement's undoScope attribute, since it doesn't have an
element ancestor. I think we should just
On Wed, 03 Aug 2011 22:42:25 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
You mean contentEditable and undoScope? That would prohibit the use
case of a web application which is not using contentEditable taking
advantage of UndoManager...
I meant merging document.undoManager and
On Wed, Aug 3, 2011 at 2:18 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 22:42:25 +0200, Ehsan Akhgari eh...@mozilla.com
wrote:
You mean contentEditable and undoScope? That would prohibit the use case
of a web application which is not using contentEditable taking
On Wed, 03 Aug 2011 23:30:59 +0200, Ryosuke Niwa rn...@webkit.org wrote:
I meant those to be identical. I should probably clarify that.
If they are identical I think it is even more clear we should remove the
one on Document as it's redundant :-)
--
Anne van Kesteren
On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Aug 2011 23:30:59 +0200, Ryosuke Niwa rn...@webkit.org wrote:
I meant those to be identical. I should probably clarify that.
If they are identical I think it is even more clear we should remove the
one on
On Wed, 03 Aug 2011 23:40:27 +0200, Ryosuke Niwa rn...@webkit.org wrote:
On Wed, Aug 3, 2011 at 2:36 PM, Anne van Kesteren ann...@opera.com
wrote:
If they are identical I think it is even more clear we should remove the
one on Document as it's redundant :-)
Mn... but I think it's more
On Wed, 03 Aug 2011 16:26:41 +0100, Tab Atkins Jr. jackalm...@gmail.com
wrote:
What do you think?
Implementing this seems rather complicated for such a niche use. It also
seems better to let sites handle this by themselves so these physical
codes can evolve more easily.
It actually
On Tue, Aug 2, 2011 at 4:55 PM, Ian Hickson i...@hixie.ch wrote:
On Tue, 2 Aug 2011, Michael Nordman wrote:
If you actively want to seek out old manifests, sure, but what's the
use case for doing that? It would be like trying to actively evict
things from HTTP caches.
You should
20 matches
Mail list logo
