Re: [whatwg] Device proximity and light events

[Doug Turner]

Hey Ian,

The Sensor API Specification in the W3 is going to own them.

- Original Message -
From: "Ian Hickson" 
To: wha...@whatwg.org
Sent: Wednesday, July 11, 2012 3:27:17 PM
Subject: Re: [whatwg] Device proximity and light events

On Fri, 4 May 2012, Doug Turner wrote:
>
> I have added two new events to Firefox which allow web apps to detect 
> light and proximity changes.
> 
> http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/ 
> http://dougturner.wordpress.com/2012/03/26/device-light-sensor/

I spoke to Doug about this on IRC and for now I'm not going to spec this 
in the HTML spec. It would probably be good for these events to be 
combined with the Geo and device orientation events and all specced 
together, but I'll leave that up to whoever specs them. :-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] seamless iframes and event propagation

[Ojan Vafai]

On Wed, Jul 11, 2012 at 3:38 AM, Chaals McCathieNevile wrote:

> On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai  wrote:
>
>> Use-case 1: A global key event handler for keyboard shortcuts. Without
>> propagating the events, you need to add a key handler to each seamless
>> iframe's root in order for these keyboard handlers to work when the
>> iframe has focus.
>>
>
> Using javascript for keyboard shortcuts is not a good idea in the first
> place. People will keep doing it instead of something more scalable to the
> web like improving their accesskey implementations, but we should not be
> encouraging it, by making it easier to do the wrong thing instead of
> somethign useful.
>

In practice, this is a very common thing to do. Making seamless iframes not
work for this thing people are already doing seems backwards to me. We
should address the problems with why doing this in JS is problematic
directly.

(The problem is that javascript key handlers generally do not
> internationalise well, are awful across a wide range of devices, and are
> almost guaranteed to fail future devices).


How does accesskey improve on this?

 Use-case 2: A dragging UI. Without event propagation, if you don't add
>> handlers to the iframe's root, you would just stop dragging when the
>> mouse is over seamless iframes. In addition, the coordinates of the mouse
>> event should be changed to the parent document's coordinate space when it
>> is refired on the iframe, otherwise your code needs to know when it's
>> over an iframe.
>>
>
> Isn't this why we introduced native drag and drop to HTML?
>

This isn't about drag-dropping. It's about dragging within a web page (e.g.
a dialog). Again, there's a ton of code out there that does this. Making it
all retrofit to understand seamless seems like a non-starter to me. So, in
practice, any site that uses code like this and starts using seamless
iframes will have a crappy user experience.


> cheers
>
> Chaals
>
>  We should fire two events. One inside the iframe and one on the iframe
>> element itself (in the parent document). Any pointers to DOM nodes in the
>> event would need to be nulled out in the event fired in the parent
>> document if the seamless iframe is cross-domain and non-CORS accessible.
>>
>> This makes seamless iframes more seamless. Most existing keyboard
>> shortcut and dragging JS code would magically keep working without needing
>> to know anything about seamless.
>>
>> Use-case 3: Making an email client that wants the content of the email
>> isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
>> the editable area sizes to the emails size). In this case, you don't want
>> to inherit the CSS for the mail client into the email's content.
>> Similarly, you may not want your global keyboard handlers to run when
>> typing in the editable area.
>>
>> Similar to Adam's allow-seamless proposal, I'd like to see seamless have
>> the ability to tweak which bits of the frame act seamlessly. Adam's
>> proposal has inherit-styles. We could also add propagates-events to
>> allow-seamless. Both of those would be off by default. For seamless, we
>> could have no-inherit-styles and no-propagate-events in order to disable
>> either behavior, also off by default.
>>
>> Ojan
>>
>> On Sat, May 26, 2012 at 5:16 PM, Adam Barth  wrote:
>>
>>  Hi whatwg,
>>>
>>> I've added a proposal to the wiki
>>> >
>>> about letting a document
>>> indicate that it is willing to be displayed seamlessly with a
>>> cross-origin parent.  This proposal is a refinement of the approach
>>> previously discussed in this thread:
>>> >> iframe-td33677754.html
>>> >.
>>>
>>> Let me know if you have any feedback.
>>>
>>> Thanks!
>>> Adam
>>>
>>>
>
> --
> Chaals - standards declaimer
>

Re: [whatwg] Device proximity and light events

[Ian Hickson]

On Fri, 4 May 2012, Doug Turner wrote:
>
> I have added two new events to Firefox which allow web apps to detect 
> light and proximity changes.
> 
> http://dougturner.wordpress.com/2012/03/22/device-proximity-sensor/ 
> http://dougturner.wordpress.com/2012/03/26/device-light-sensor/

I spoke to Doug about this on IRC and for now I'm not going to spec this 
in the HTML spec. It would probably be good for these events to be 
combined with the Geo and device orientation events and all specced 
together, but I'll leave that up to whoever specs them. :-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Can we make checkboxes readonly?

[Ian Hickson]

On Wed, 11 Jul 2012, Markus Ernst wrote:
> Am 11.07.2012 00:59 schrieb Ian Hickson:
> > On Fri, 4 May 2012, Tab Atkins Jr. wrote:
> > > On Wed, May 2, 2012 at 3:57 PM, Ian Hickson  wrote:
> > > > On Wed, 6 Apr 2011, Tab Atkins Jr. wrote:
> > > > > An app may dynamically set inputs or groups of inputs to readonly
> > > > > based on app state.  When you submit, though, it's impossible to
> > > > > tell (without hacks) whether a checkbox was checked-but-disabled or
> > > > > just unchecked. Handling the form data is *much* easier if you just
> > > > > get all the data, regardless of whether, as a UI convenience, your
> > > > > app temporarily set some of the inputs to readonly.
> > > > 
> > > > That's a use case for submitting disabled check boxes, not for 
> > > > read-only checkboxes, IMHO. (The same could be said for disabled 
> > > > text controls.)
> > > 
> > > That's more-or-less what @readonly does - the input becomes 
> > > "disabled" but still submits.
> > 
> > That's part of what it does, but not the main thing it does. It's 
> > mainly a UI affordance, which doesn't apply to check boxes.
> 
> Given that there are valid use cases for submitting values of elements 
> that have a disabled resp. readonly behaviour in the UI: Would it do any 
> _harm_ to allow @readonly to checkboxes and radio buttons? I assume this 
> would be easy and possible without breaking existing content. Submitting 
> disabled elements, OTOH, looks to me like an impossible change, as it 
> would likely break existing content.

Just making readonly="" on checkboxes be a synonym for disabled="" (but 
with different submission behaviour) would be an abuse of the attribute, 
IMHO, since readonly="" doesn't mean disabled, it means read-only, which 
is a concept that only applies to text fields. The only reason we'd want 
to use readonly="" rather than make up some new feature is if it had good 
graceful degradation, but it doesn't (it wouldn't be disabled in old UAs). 

If we want to make it possible to submit disabled controls, we should just 
provide that feature explicitly, e.g. an attribute on  that causes 
disabled controls to be submitted. But with form submission slowly being 
replaced by JavaScript-mediated in-place "AJAX" UI, and given that the 
server typically already has the disabled data since it sent it to the 
user and the user isn't allowed to change it, and given that servers can't 
trust the client not to have changed the data so has to check it anyway, 
and given that it's possible to work around this issue already using 
type=hidden without much difficulty, I don't really see much of a 
compelling reason to add this feature at this time.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Can we make checkboxes readonly?

[Markus Ernst]

Am 11.07.2012 00:59 schrieb Ian Hickson:

On Fri, 4 May 2012, Tab Atkins Jr. wrote:

On Wed, May 2, 2012 at 3:57 PM, Ian Hickson  wrote:

On Wed, 6 Apr 2011, Tab Atkins Jr. wrote:

An app may dynamically set inputs or groups of inputs to readonly
based on app state.  When you submit, though, it's impossible to
tell (without hacks) whether a checkbox was checked-but-disabled or
just unchecked. Handling the form data is *much* easier if you just
get all the data, regardless of whether, as a UI convenience, your
app temporarily set some of the inputs to readonly.


That's a use case for submitting disabled check boxes, not for
read-only checkboxes, IMHO. (The same could be said for disabled text
controls.)


That's more-or-less what @readonly does - the input becomes "disabled"
but still submits.


That's part of what it does, but not the main thing it does. It's mainly a
UI affordance, which doesn't apply to check boxes.


Given that there are valid use cases for submitting values of elements 
that have a disabled resp. readonly behaviour in the UI: Would it do any 
_harm_ to allow @readonly to checkboxes and radio buttons? I assume this 
would be easy and possible without breaking existing content. Submitting 
disabled elements, OTOH, looks to me like an impossible change, as it 
would likely break existing content.

Re: [whatwg] seamless iframes and event propagation

[Chaals McCathieNevile]

On Tue, 10 Jul 2012 01:26:13 +0200, Ojan Vafai  wrote:


I'd like to see us add event propagation into the parent document for
seamless iframes, e.g. key and mouse events inside a seamless iframe  
should be refired on the iframe element.


The first two of these use cases make no sense to me (which might just be  
because I am not very bright, or missing something...)



Use-case 1: A global key event handler for keyboard shortcuts. Without
propagating the events, you need to add a key handler to each seamless
iframe's root in order for these keyboard handlers to work when the  
iframe has focus.


Using javascript for keyboard shortcuts is not a good idea in the first
place. People will keep doing it instead of something more scalable to the
web like improving their accesskey implementations, but we should not be
encouraging it, by making it easier to do the wrong thing instead of
somethign useful.

(The problem is that javascript key handlers generally do not
internationalise well, are awful across a wide range of devices, and are
almost guaranteed to fail future devices).


Use-case 2: A dragging UI. Without event propagation, if you don't add
handlers to the iframe's root, you would just stop dragging when the  
mouse is over seamless iframes. In addition, the coordinates of the mouse

event should be changed to the parent document's coordinate space when it
is refired on the iframe, otherwise your code needs to know when it's  
over an iframe.


Isn't this why we introduced native drag and drop to HTML?

cheers

Chaals


We should fire two events. One inside the iframe and one on the iframe
element itself (in the parent document). Any pointers to DOM nodes in the
event would need to be nulled out in the event fired in the parent  
document if the seamless iframe is cross-domain and non-CORS accessible.


This makes seamless iframes more seamless. Most existing keyboard  
shortcut and dragging JS code would magically keep working without  
needing to know anything about seamless.


Use-case 3: Making an email client that wants the content of the email
isolated from the client's UI, but doesn't want a nested scrollbar (i.e.
the editable area sizes to the emails size). In this case, you don't want
to inherit the CSS for the mail client into the email's content.  
Similarly, you may not want your global keyboard handlers to run when

typing in the editable area.

Similar to Adam's allow-seamless proposal, I'd like to see seamless have
the ability to tweak which bits of the frame act seamlessly. Adam's
proposal has inherit-styles. We could also add propagates-events to
allow-seamless. Both of those would be off by default. For seamless, we
could have no-inherit-styles and no-propagate-events in order to disable
either behavior, also off by default.

Ojan

On Sat, May 26, 2012 at 5:16 PM, Adam Barth  wrote:


Hi whatwg,

I've added a proposal to the wiki
 about letting a document
indicate that it is willing to be displayed seamlessly with a
cross-origin parent.  This proposal is a refinement of the approach
previously discussed in this thread:
.

Let me know if you have any feedback.

Thanks!
Adam




--
Chaals - standards declaimer