Re: ACTION-23 - Draft a proposal to drop online events from HTML5

On 27 Aug 2012, at 13:30, Andrew Betts wrote:

> On 26 August 2012 15:00, Jo Rabin <> wrote: 
> PROPOSED RESOLUTION: Coremob reverses its position on dropping online from HTML5 so there's no need to communicate a request for it to be dropped.
> We could go further and request a caveat or hint be inserted in HTML5 about "failing early". Andrew, would you like to draft some specific text for that as a PROPOSED RESOLUTION?
> Do we need a resolution to change position on this?  I don't think a resolution was adopted to create the position in the first place, it was just suggested that we go away and think about it.

Strictly I guess not, but we've had a discussion, and need to come to a conclusion. Taking a resolution helps to establish a position, and draw a line under topics.

> The current implementation is confusing because creates an unhelpful affordance.  It would actually be considerably improved by reversing the semantics, so in terms of the property, rather than navigator.onLine, we have navigator.offLine, which is false when online or in unknown state, and true when offline.  That would make it much clearer for developers who will naturally tend to trust the positive assertion implied by the value being true.  The corresponding state-change events might be better renamed as offlineStart and offlineEnd rather than offline and online for the same reason.
> And these changes would also be backwards compatible.  However, it really depends how much enthusiasm there is for twiddling with semantics to make behaviour clearer without functionally achieving anything.  A non-normative guideline on use of the existing implementation may be easier to achieve, if a bit of a cop out :-)
> Happy to draft a resolution - are there any rules for doing so?

Keep it clean? :-) It depends on where we go with this, if the group decides it would like to request the HTML5 group to do something then a resolution would be a good thing. For my own part I'm mainly interested in some example or what specifically you're suggesting here "Instead, itís better to use it to fail early and quickly when the device has a high confidence of no network connection." 


Received on Monday, 27 August 2012 13:03:23 UTC