permissions for different devices or a Geolocation API
could have different level of accuracies. See [1] for more details.
WDYT?
[1]
https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview
-- Mounir
--
Dave Raggett d...@w3.org http://www.w3.org
started in SysApps but was transferred to WebApps.
--
Dave Raggett d...@w3.org http://www.w3.org/People/Raggett
that browsers varied in their treatment of them, and that
browsers frequently don't behave in the way that people expect with
common word processing software.
--
Dave Raggett d...@w3.org http://www.w3.org/People/Raggett
that we choose to set up to progress
this work further.
--
Dave Raggett d...@w3.org http://www.w3.org/People/Raggett
On 15/11/11 20:46, Paul Kinlan wrote:
This is the way that I have implemented it in test apps. It is the
handler app that will show the progress information. I have not had a
case yet where the client app needs or is concerned about the progress
of the action that is being handled, other
On 12/11/11 11:42, Giuseppe Pascale wrote:
* The UI web page should be able to handle devices appearing and
disappearing at random times and be notified of such via events. Is this
possible?
I'm wondering if tḧis is actually needed. If you handle the picker
natively, I think also this aspect
On 24/07/11 16:18, Aryeh Gregor wrote:
On Fri, Jul 22, 2011 at 6:58 PM, Jonas Sicking jo...@sicking.cc wrote:
We should have much richer events to aid with rich text editing. Using
mutation notifications for this is will not create a good experience
for the page author.
Agreed. I'd be really
On 22/07/11 02:26, Adam Klein wrote:
This is only complex because you're coalescing the mutations, right?
In Rafael's original proposal, each mutation would result in a single
immutable mutation record, so the semantics would be to deliver (by
appending to a queue associated with each observer)
On 22/07/11 16:54, Boris Zbarsky wrote:
I don't need software that uses mutation events. I need software that
triggers editing operations, so I can them actually measure what DOM
mutations are performed in the course of these editing operations.
How about:
* The many blogging tools with
On 20/07/11 18:23, Boris Zbarsky wrote:
It's pretty common to have situations where lots (10-20) of properties
are set in inline style, especially in cases where the inline style is
being changed via CSS2Properties from script (think animations and the
like, where the objects being animated
Thanks Jonas for the proposal. For changes to attributes and changes to
the value of text nodes, it should be possible to applications to
request to see the before/after values. You note that style attributes
may be long as an argument against permitting applications to see the
before value.
On 20/07/11 00:56, Jonas Sicking wrote:
On Tue, Jul 19, 2011 at 4:18 PM, Ryosuke Niwarn...@webkit.org wrote:
For editing purposes, it's also crucial to know from/to where nodes are
removed/inserted. It seems like adding an offset trivially solves this
problem without much overhead.
I'm not
On 20/07/11 16:32, Boris Zbarsky wrote:
On 7/20/11 4:26 AM, Dave Raggett wrote:
You note that style attributes may be long as an argument against
permitting applications to see the
before value.
The problem is not the length per se. The problem is that the value
is not stored anywhere
On 20/07/11 17:05, Ryosuke Niwa wrote:
On Wed, Jul 20, 2011 at 8:43 AM, Dave Raggett d...@w3.org
mailto:d...@w3.org wrote:
Perhaps we need to distinguish auto generated attributes from
those that are set by markup or scripts. Could you please clarify
for me the difference between
On 04/07/11 21:43, Olli Pettay wrote:
On 07/04/2011 09:01 PM, Dave Raggett wrote:
On 04/07/11 17:57, Olli Pettay wrote:
Mutation listener could easily
implement old/new value handling itself, especially if it knows which
attributes it is interested in.
How exactly would the listener know
On 03/07/11 04:52, Boris Zbarsky wrote:
On 7/2/11 2:27 PM, Dave Raggett wrote:
n.b. the current mutation events work nicely for the document editing
use cases.
Only if you have full control over the set of all registered
listeners. If you do not, you're SOL, because current mutation events
On 01/07/11 20:13, Boris Zbarsky wrote:
Similarly, I've found it important to
be able to distinguish between nodes that are being removed from a
document tree and nodes that are being moved within the document tree,
Interesting, given that Gecko's DOM implementation does NOT make such
a
On 02/07/11 15:07, Boris Zbarsky wrote:
On 7/2/11 6:28 AM, Dave Raggett wrote:
My use case involves multiple people simultaneously editing the same
document. The mutations due to user actions are batched and serialized
as JSON. If you know that a given node was moved then you can avoid
On 02/07/11 17:51, Ryosuke Niwa wrote:
Maybe we'll have a boolean that indicates whether an observer wants a
full-list or not when the observer is attached?
That would do the trick nicely!
--
Dave Raggettd...@w3.org http://www.w3.org/People/Raggett
Olli Pettay
Tue, 28 Jun 2011 04:32:14 -0700
These are *not* DOM-Event listeners. No DOM Events are created, there
are no capture phases or bubbling phases. Instead you register a
listener on the node you are interested in being notified about, and
will get a call after a mutation takes
On 30/06/11 22:42, Ryosuke Niwa wrote:
On Thu, Jun 30, 2011 at 1:15 PM, David Flanagan dflana...@mozilla.com
mailto:dflana...@mozilla.com wrote:
avoid the need to maintain a list of pending callbacks.
Yeah, this is one reason I like Rafael's proposal of having a list of
mutations. In
In the webinos project [1] we are using installed vs hosted web apps.
On 23/06/11 15:58, Karl Dubost wrote:
I do not want to start a name bikeshedding.
The name doesn't bother me so far, but I have seen that comment again and again.
On Thu, 23 Jun 2011 14:06:24 GMT
In Bruce Lawson’s
:
Model-Based UI XG Final Report
http://www.w3.org/2005/Incubator/model-based-ui/XGR-mbui-20100504/
There is also a proposed WG to continue work done by the above XG:
(DRAFT) Model-Based UI Working Group Charter
http://www.w3.org/2011/01/mbui-wg-charter
-AB
--
Dave
23 matches
Mail list logo
