Re: [whatwg] Forms dont submit when disabling submit button

[Kaustubh Atrawalkar]

Reopening discussion. Just curious about what can be exact behavior expected
in this case?
I have attached the sample use case.

- Kaustubh

On Tue, Sep 27, 2011 at 11:35 PM, Kaustubh Atrawalkar  wrote:

> A simple use case -
>
> 
> 
> 
> This does not submit the form in IE, Opera or Webkit but in firefox it does
> show alert. Considering generic behavior of HTML5 forms, until and unless
> submit button is active submit action should also be followed by onclick
> event on submit button. Just need to get what can be the exact behavior
> here?
> According to specs, (
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#submit-button-state)
> when button is activated, it should submit the form.
>
> --
> Kaustubh Atrawalkar
>

Re: [whatwg] HTMLForms: Implicit Submission with {display:none} button

[Kaustubh Atrawalkar]

On Mon, Sep 26, 2011 at 2:36 AM, Glenn Maynard  wrote:

> On Sun, Sep 25, 2011 at 1:02 PM, Ryosuke Niwa  wrote:
>
>>  The current Trident/WebKit behavior has a nice side-effect to (without
>> scripts) require a visible submit button to enable implicit form submission.
>>
>
> I don't find that nice.  As a user, it's very annoying when implicit form
> submission doesn't work for some obscure reason (like not having a submit
> control), forcing me to use the mouse instead of it behaving like any other
> form.  It makes the UI inconsistent and unpredictable.
>
> Also, the single-text-input-with-no-submit-button case doesn't follow the
> above.
>
> The "without scripts" is also a fatal caveat.  Users can't be expected to
> understand things like "you can press enter to submit the form if you see a
> browser-native submit button, but not if the button is actually scripted
> markup".
>
> In principle, *all* forms should allow implicit submit, unless the site
> explicitly doesn't want it (scripted autosave dialogs) or the UA doesn't
> support it.  That ship sailed years ago, but the visibility of the submit
> button shouldn't enter into it.
>
>
Should this be made to for all browser compliance and browser to allow
implicit submission irrespective of visibility of submit button? A web-dev
can always stop this by either disabling the submit button or through
script. Browser can give control back to onsubmit handler on enter key press
if there is enabled submit button.

Re: [whatwg] [fullscreen] cancelFullScreen()

[Anne van Kesteren]

On Thu, 13 Oct 2011 11:26:20 +0900, Chris Pearce   
wrote:

On 12/10/2011 10:35 p.m., Anne van Kesteren wrote:

Is cancelFullScreen() synchronous or should it queue a task?


Synchronous, so that Document.fullScreen immediately reflects the state  
change? Why would it need to be asynchronous?


Is the event dispatched synchronously as well then? I was thinking that  
maybe you want to trigger an animation here of some kind. Though I suppose  
that could be done synchronously as well.



If you invoke cancelFullScreen() on a Document of a parent or child  
browsing context from the browsing context in whose Document  
requestFullScreen() was invoked it should presumably still work, no?


The parent of a Document which is in full-screen will also be in  
full-screen mode. So if cancelFullScreen() is invoked in the parent  
Document, it should exit full-screen in the parent. I interpreted the  
spec to mean if one full-screen document cancels full-screen, all  
documents in the tree exit full-screen mode.


I too have been wondering if we should honour calls to  
cancelFullScreen() in a non-full-screen child Document of the Document  
which requested full-screen.


It seems to me that "being fullscreen" is a property of the top-level  
browsing context. All that is potentially associated with a document is  
the "fullscreen element". If you have a document A with two sub-documents  
B and C, it does not make much sense to me that if you go fullscreen from  
B, C would not report as "being fullscreen". I mean sure, there is no  
"fullscreen element" but it is definitely rendered fullscreen.




Presumably also if the Document has been navigated away from.


FWIW we're planing to exit full-screen when a full-screen document is  
navigated. Probably a good idea to spec this so it's consistently  
implemented.


Okay.


--
Anne van Kesteren
http://annevankesteren.nl/

Re: [whatwg] [fullscreen] cancelFullScreen()

[Chris Pearce]

On 12/10/2011 10:35 p.m., Anne van Kesteren wrote:

Is cancelFullScreen() synchronous or should it queue a task?


Synchronous, so that Document.fullScreen immediately reflects the state 
change? Why would it need to be asynchronous?


If you invoke cancelFullScreen() on a Document of a parent or child 
browsing context from the browsing context in whose Document 
requestFullScreen() was invoked it should presumably still work, no?


The parent of a Document which is in full-screen will also be in 
full-screen mode. So if cancelFullScreen() is invoked in the parent 
Document, it should exit full-screen in the parent. I interpreted the 
spec to mean if one full-screen document cancels full-screen, all 
documents in the tree exit full-screen mode.


I too have been wondering if we should honour calls to 
cancelFullScreen() in a non-full-screen child Document of the Document 
which requested full-screen.


Presumably also if the Document has been navigated away from. 


FWIW we're planing to exit full-screen when a full-screen document is 
navigated. Probably a good idea to spec this so it's consistently 
implemented.



Chris Pearce.

Re: [whatwg] [fullscreen] Drop requestFullScreenWithKeys()?

[Anne van Kesteren]

On Wed, 12 Oct 2011 22:18:04 +0900, Henri Sivonen  wrote:
On Wed, Oct 12, 2011 at 11:56 AM, Anne van Kesteren   
wrote:

Given the way Mac OS handles full screen applications I wonder whether
requestFullScreenWithKeys() is needed. A toolbar will always appear at  
the top if you locate your cursor there.


Does the user realize that? Can the user do that if a mouse lock API
is used also? Can a user without a pointing device do that?


Maybe an additional warning as suggested in
https://bugzilla.mozilla.org/show_bug.cgi?id=684625 is warranted as well.  
But given that and platform integration of fullscreen it seems unnecessary  
to make the API more complex.


I'm not sure how fullscreen should work on touch devices.


--
Anne van Kesteren
http://annevankesteren.nl/

[whatwg] Proposal: "Offline-Capable" Meta Tag and API Indicates Application's Ability to Function Without Network Connection

[Brian Blakely]

*The element:*


*Its purpose:*
Trigger a UA-native indication to the user that the current application's
primary and entire collection of features can be used without a network
connection.

*API:*
A simple API in the form of a document.offlineCapable boolean setter/getter
would allow an application to dynamically inform the user when the
application is in an offline-capable state.  For example, a nature
photography app may not be truly offline-capable until all of its graphic
assets have finished downloading.  As such, when the application has
detected its final image has loaded, it will execute document.offlineCapable
= true; and the user will be notified that they will no longer need WiFi to
continue usage.

*Exposition:*
This seems simple, almost superfluous, but it is of staggering importance.
 An "online only" stigma is of greatly growing impedance to the web
platform's reputation as a software platform, and it persists among the vast
majority of users.  The latest versions of all major browsers will support
features like DOM Storage and Application Cache very soon, but these
features are largely ambiguous, even amongst the technically savvy.

In addition to implementation of offline technologies, app authors are
currently individually responsible for informing their users that an app can
be used offline. This is not an adequate solution, and a universal
notification that is UA-native would be far more effective at enhancing
awareness.

Because mere utilization of appcache and localStorage do not always make an
application "offline capable", offering a manual flag to authors allows a UA
to complement, or override, its heuristic detections of this state.

The Web must become known as a full software platform, instead of just a
lite version of the "native" App Store experiences out there.  In order to
do so, its features must be more discoverable by users, and in a
standardized fashion.

Thanks,
-Bri

[whatwg] Including FLAC output in Audio Specs

[Charles Pritchard]

Currently, PNG and the Canvas tag set a solid precedent for including a 
lossless file format in media APIs. The PNG format, at its most basic, 
simply compresses a bitmap using deflate.


I'd like to see the same precedent followed in some of the new media 
APIs. FLAC provides a lossless audio format which can be used to package 
audio data from items like the MediaStream .record method.


How would we go about adding this into specifications?

I'll point out that many vendors support JPEG in addition to PNG, but 
that's not part of the specs, and it is a lossy format. It'd be nice to 
see something like Speex supported by vendors on audio APIs, but like 
JPEG, it's something that should remain a lesser priority to supporting 
a lossless format.


MediaStream record seems like it could accept a mime type, much as 
toBlob / toDataURL do on Canvas. That's one possible point of entry.


Does anyone have feedback on this issue? Is there any push-back out 
there on supporting FLAC as a baseline format for  input and 
output? Obviously, it is bandwidth heavy, as is PNG.



-Charles

Re: [whatwg] Same origin - Blob and FileSystem URLs

[Bronislav Klučka]

On 12.10.2011 16:32, Kyle Huey wrote:

2011/10/12 Bronislav Klučka


Hello
Certain parts of spesc are covering how to work with resources identified
by URL and same-origin issue (download attribute, canvas)
looking at same-origin algorithm
http://www.whatwg.org/specs/**web-apps/current-work/**
multipage/origin-0.html#same-**origin
I'm wondering about Blob URL and FileSystem API URL. Those are not
conventional URL but they are named as "URL" and one can work with them the
same as with regular URL. How does the same-origin policy apply to those
URLs?

Bronislav Klucka



Per spec, Blob URIs are same origin with the script that created them.  See
http://dev.w3.org/2006/webapi/FileAPI/#originOfBlob

- Kyle


May I assume that
http://www.w3.org/TR/file-system-api/#widl-Entry-toURL
is also the same-origin as the originator script origin?

Brona

Re: [whatwg] Same origin - Blob and FileSystem URLs

[Kyle Huey]

2011/10/12 Bronislav Klučka 

> Hello
> Certain parts of spesc are covering how to work with resources identified
> by URL and same-origin issue (download attribute, canvas)
> looking at same-origin algorithm
> http://www.whatwg.org/specs/**web-apps/current-work/**
> multipage/origin-0.html#same-**origin
> I'm wondering about Blob URL and FileSystem API URL. Those are not
> conventional URL but they are named as "URL" and one can work with them the
> same as with regular URL. How does the same-origin policy apply to those
> URLs?
>
> Bronislav Klucka
>
>
Per spec, Blob URIs are same origin with the script that created them.  See
http://dev.w3.org/2006/webapi/FileAPI/#originOfBlob

- Kyle

[whatwg] Same origin - Blob and FileSystem URLs

[Bronislav Klučka]

Hello
Certain parts of spesc are covering how to work with resources 
identified by URL and same-origin issue (download attribute, canvas)

looking at same-origin algorithm
http://www.whatwg.org/specs/web-apps/current-work/multipage/origin-0.html#same-origin
I'm wondering about Blob URL and FileSystem API URL. Those are not 
conventional URL but they are named as "URL" and one can work with them 
the same as with regular URL. How does the same-origin policy apply to 
those URLs?


Bronislav Klucka

Re: [whatwg] [fullscreen] Drop requestFullScreenWithKeys()?

[Henri Sivonen]

On Wed, Oct 12, 2011 at 11:56 AM, Anne van Kesteren  wrote:
> Given the way Mac OS handles full screen applications I wonder whether
> requestFullScreenWithKeys() is needed. A toolbar will always appear at the
> top if you locate your cursor there.

Does the user realize that? Can the user do that if a mouse lock API
is used also? Can a user without a pointing device do that?

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

[whatwg] [fullscreen] cancelFullScreen()

[Anne van Kesteren]

Is cancelFullScreen() synchronous or should it queue a task? If you invoke  
cancelFullScreen() on a Document of a parent or child browsing context  
from the browsing context in whose Document requestFullScreen() was  
invoked it should presumably still work, no?


Presumably also if the Document has been navigated away from. In what  
scenarios does the "for example the UA might require that only a Document  
that last triggered full-screen can cancel it" provision apply?



It is really quite confusing in the draft what "full screen" is associated  
with. A Document, a top-level browsing context, the user agent?



--
Anne van Kesteren
http://annevankesteren.nl/

[whatwg] [fullscreen] Tasks

[Anne van Kesteren]

Is the event dispatched in the same task that makes the element or  
document go full screen?



--
Anne van Kesteren
http://annevankesteren.nl/

[whatwg] [fullscreen] Drop requestFullScreenWithKeys()?

[Anne van Kesteren]

Given the way Mac OS handles full screen applications I wonder whether  
requestFullScreenWithKeys() is needed. A toolbar will always appear at the  
top if you locate your cursor there. I do not really know how this works  
on other desktop systems, but if more move in this direction,  
requestFullScreenWithKeys() seems unneeded.



--
Anne van Kesteren
http://annevankesteren.nl/