Re: Intent to implement: HTML5 element

2016-12-23 Thread Tantek Çelik 
On Fri, Dec 23, 2016 at 4:02 PM, Martin Thomson  wrote:
> On Fri, Dec 23, 2016 at 6:20 PM, Boris Zbarsky  wrote:
>>> I mean, the attribute is probably a lost cause
>>
>> Why?  Is there significant usage, or at least wide implementation, of that
>> part of the API already?  The original intent said that only Chrome is
>> shipping this.
>
> Fair point.  I guess the question becomes whether Chrome compatibility
> is the reason we are doing this.

Yes this is the key question.

IF there is a webcompat issue now, THEN we have little choice but to
implement the API as is.

IF there is no webcompat issue, THEN
* We should NOT implement this "legacy" API, as us implementing in
addition to Chrome may be enough to create a compat issue (for
everyone else for this API design, and provide another point of
inconsistency for web developers). Let's avoid a platform wart if we
can.
* We should be prepared to propose fixes/updates to the API that use a
Promise per points from Joe, mt, bz, and then prototype/implement
accordingly.


Is there some other time pressure / use-case need to ship this feature
"soon" that hasn't been discussed in this thread so far?

Thanks,

Tantek
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-23 Thread Xidorn Quan 
On Fri, Dec 23, 2016, at 02:33 PM, Tim Nguyen wrote:
> Non-modal dialogs should just work fine in a chrome window (the dialog
> would just be like a centered absolute positioned div). As for modal
> dialogs (eg. dialogs that makes everything else inert), it would depend
> on
> whether the current top-layer implementation works within a chrome window
> and I don't think it is the case currently. So, I don't expect modal
> dialogs to work within the chrome window (at least not without some extra
> platform work). Xidorn might know better though.

I think top layer should work for chrome document. In the frame tree
(rendering tree), top layer elements are direct children of the viewport
frame (which is the root of frame tree in all kinds of documents). So I
don't expect much extra work (if any) for supporting modal dialogs in
chrome document on top of the support in web content.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-23 Thread Martin Thomson 
On Fri, Dec 23, 2016 at 6:20 PM, Boris Zbarsky  wrote:
>> I mean, the attribute is probably a lost cause
>
> Why?  Is there significant usage, or at least wide implementation, of that
> part of the API already?  The original intent said that only Chrome is
> shipping this.

Fair point.  I guess the question becomes whether Chrome compatibility
is the reason we are doing this.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-22 Thread Boris Zbarsky 

On 12/22/16 10:03 PM, Martin Thomson wrote:

On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky  wrote:

Note that I expect that this spec was written before Promise was a thing.
The setup where we return a value in an attribute of the element (!) is
pretty bizarre...


Is this irredeemable?


Probably not.


I mean, the attribute is probably a lost cause


Why?  Is there significant usage, or at least wide implementation, of 
that part of the API already?  The original intent said that only Chrome 
is shipping this.



but a void function can usually be safely transformed into a
Promise-bearing one.


Indeed.

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-22 Thread Martin Thomson 
On Fri, Dec 23, 2016 at 7:14 AM, Boris Zbarsky  wrote:
> Note that I expect that this spec was written before Promise was a thing.
> The setup where we return a value in an attribute of the element (!) is
> pretty bizarre...

Is this irredeemable?  I mean, the attribute is probably a lost cause,
but a void function can usually be safely transformed into a
Promise-bearing one.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-22 Thread Tim Nguyen 
Non-modal dialogs should just work fine in a chrome window (the dialog
would just be like a centered absolute positioned div). As for modal
dialogs (eg. dialogs that makes everything else inert), it would depend on
whether the current top-layer implementation works within a chrome window
and I don't think it is the case currently. So, I don't expect modal
dialogs to work within the chrome window (at least not without some extra
platform work). Xidorn might know better though.

As for how modal dialogs *should* behave in a chrome window, I would expect
it to be the same as for web content, i.e. it modal dialogs should make all
UI elements except the current dialog inert.

Tim


On Fri, Dec 23, 2016 at 12:33 AM, Justin Dolske  wrote:

> What's the expected experience if chrome code uses this feature? (In a
> chrome window, interaction with a content window isn't the thing I'm
> wondering about.)
>
> Justin
>
> On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen  wrote:
>
>> *Summary*:
>> The *HTML  element* represents a dialog box or other interactive
>> component, such as an inspector or window.
>> It will initially be implemented behind a pref.
>>
>> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>>
>> *Link to standard*: https://html.spec.whatwg.org/m
>> ultipage/forms.html#the-
>> dialog-element
>> 
>>
>> *Platform coverage*: All
>>
>> *Estimated or target release*: Firefox 54
>>
>> *Preference behind which this will be implemented*:
>> dom.dialog_element.enabled
>>
>> *DevTools bug*: None yet, although I'm not sure how we can make DevTools
>> more useful here ?
>>
>> *Do other browser engines implement this?*
>> Shipped: Chrome (since version 37)
>> Considering: Edge ( http://status.modern.ie/dialogelementformodals )
>>
>> *Tests*:
>> https://github.com/w3c/web-platform-tests/blob/master/
>> html/dom/interfaces.html#L1835
>> https://github.com/w3c/web-platform-tests/tree/master/
>> html/semantics/interactive-elements/the-dialog-element
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-22 Thread Justin Dolske 
What's the expected experience if chrome code uses this feature? (In a
chrome window, interaction with a content window isn't the thing I'm
wondering about.)

Justin

On Tue, Dec 20, 2016 at 3:56 PM, Tim Nguyen  wrote:

> *Summary*:
> The *HTML  element* represents a dialog box or other interactive
> component, such as an inspector or window.
> It will initially be implemented behind a pref.
>
> *Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>
> *Link to standard*: https://html.spec.whatwg.org/multipage/forms.html#the-
> dialog-element
>
> *Platform coverage*: All
>
> *Estimated or target release*: Firefox 54
>
> *Preference behind which this will be implemented*:
> dom.dialog_element.enabled
>
> *DevTools bug*: None yet, although I'm not sure how we can make DevTools
> more useful here ?
>
> *Do other browser engines implement this?*
> Shipped: Chrome (since version 37)
> Considering: Edge ( http://status.modern.ie/dialogelementformodals )
>
> *Tests*:
> https://github.com/w3c/web-platform-tests/blob/master/
> html/dom/interfaces.html#L1835
> https://github.com/w3c/web-platform-tests/tree/master/
> html/semantics/interactive-elements/the-dialog-element
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-22 Thread Boris Zbarsky 

On 12/21/16 4:13 PM, Xidorn Quan wrote:

This is a question for the spec. I guess it theoretically can return a
Promise, though I suspect that there might be some weird corner cases
which is hard to handle.


Note that I expect that this spec was written before Promise was a 
thing.  The setup where we return a value in an attribute of the element 
(!) is pretty bizarre...



Anyway, I don't think dev-platform is the right place for this kind of
spec issues. You can raise an issue to HTML spec to start the discussion
there.


Sure, but it bears on whether we want to ship the spec in its current state.

-Boris

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-21 Thread Xidorn Quan 
On Thu, Dec 22, 2016, at 05:41 AM, Joe Hildebrand wrote:
> > On Dec 20, 2016, at 6:25 PM, Xidorn Quan  wrote:
> > 
> >> So dialog.showModal() does not need to block script like other
> >> modal APIs?
> > 
> > 
> > Definitely not. I think this is designed to replace those blocking API.
> 
> Why doesn't showModal() return a Promise?

This is a question for the spec. I guess it theoretically can return a
Promise, though I suspect that there might be some weird corner cases
which is hard to handle.

Anyway, I don't think dev-platform is the right place for this kind of
spec issues. You can raise an issue to HTML spec to start the discussion
there.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-21 Thread Joe Hildebrand 

> On Dec 20, 2016, at 6:25 PM, Xidorn Quan  wrote:
> 
>> So dialog.showModal() does not need to block script like other
>> modal APIs?
> 
> 
> Definitely not. I think this is designed to replace those blocking API.


Why doesn't showModal() return a Promise?

-- 
Joe Hildebrand
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-20 Thread Xidorn Quan 
On Wed, Dec 21, 2016, at 12:23 PM, Ben Kelly wrote:

> On Tuesday, December 20, 2016, Xidorn Quan  wrote:

> > On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:

> >> Hi Tim, can you describe how the modality of dialog.showModal()
> >> works?
> >> Does a web page have the power to block the user from interacting

> >> with the entire browser (all windows)? Or is it just one window?

> >> or just one tab? or something else?

> >

> > It just blocks the same document it is in (not even the tab if the

> > document is in iframe). A modal  is just another normal HTML
> > element with some special rendering (and focusing) rules.

> 

> So dialog.showModal() does not need to block script like other
> modal APIs?


Definitely not. I think this is designed to replace those blocking API.


- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-20 Thread Xidorn Quan 
On Wed, Dec 21, 2016, at 11:21 AM, Tantek Çelik wrote:
> I'm also curious how interactions between dialog.showModal() and then
> controls inside of that going Fullscreen work (and then perhaps a
> dialog inside that fullscreen view, etc.) 

That's a... good question.

Per spec, it should just work. I mean, the document would enter
fullscreen, and dialog inside fullscreen view can be open as normal.

> Does "escape" key escape out of one layer of dialog/fullscreen? multiple? all?

I think, ideally "escape" key would exit fullscreen without touching any
modal dialog, whatever the opening order is. It is important for
security consideration, since otherwise the content may block user from
exiting fullscreen. I think implementor needs to take care of that (and
test should be added to verify this is guaranteed).

Another security concern is that this may allow websites to fool users
about what content is actually showing fullscreen. e.g. if I have
https://www.youtube.com/something; allowfullscreen>, when
Youtube enters fullscreen, Firefox shows a message stating that
youtube.com is in full screen, but with modal dialog, the parent
document can actually show something different on top of the iframe.

Probably this is already doable via making the iframe and its backdrop
pseudo transparent, so it may not be a new concern. Not sure how
important this issue is. I guess we should change the fullscreen warning
to always show the origin of the top browsing context rather than the
current fullscreen document.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-20 Thread Astley Chen 
A simple example if you are interested in how it works on Chrome.

http://codepen.io/astleychen/pen/Obqzrr 



—--
Best Regards,
Astley Chen | Mozilla Taiwan


On 21 Dec 2016, at 8:21 AM, Xidorn Quan  wrote:

On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:
> Hi Tim, can you describe how the modality of dialog.showModal() works?
> Does a web page have the power to block the user from interacting
> with the entire browser (all windows)? Or is it just one window?
> or just one tab? or something else?

It just blocks the same document it is in (not even the tab if the
document is in iframe). A modal  is just another normal HTML
element with some special rendering (and focusing) rules.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-20 Thread Tantek Çelik 
I'm also curious how interactions between dialog.showModal() and then
controls inside of that going Fullscreen work (and then perhaps a
dialog inside that fullscreen view, etc.) Does "escape" key escape out
of one layer of dialog/fullscreen? multiple? all?

Tantek

On Tue, Dec 20, 2016 at 4:12 PM, Mats Palmgren  wrote:
> Hi Tim, can you describe how the modality of dialog.showModal() works?
> Does a web page have the power to block the user from interacting
> with the entire browser (all windows)? Or is it just one window?
> or just one tab? or something else?
>
> Thanks,
> Mats
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: HTML5 element

2016-12-20 Thread Xidorn Quan 
On Wed, Dec 21, 2016, at 11:12 AM, Mats Palmgren wrote:
> Hi Tim, can you describe how the modality of dialog.showModal() works?
> Does a web page have the power to block the user from interacting
> with the entire browser (all windows)? Or is it just one window?
> or just one tab? or something else?

It just blocks the same document it is in (not even the tab if the
document is in iframe). A modal  is just another normal HTML
element with some special rendering (and focusing) rules.

- Xidorn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: HTML5 element

2016-12-20 Thread Tim Nguyen 
*Summary*:
The *HTML  element* represents a dialog box or other interactive
component, such as an inspector or window.
It will initially be implemented behind a pref.

*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=840640

*Link to standard*: https://html.spec.whatwg.org/multipage/forms.html#the-
dialog-element

*Platform coverage*: All

*Estimated or target release*: Firefox 54

*Preference behind which this will be implemented*:
dom.dialog_element.enabled

*DevTools bug*: None yet, although I'm not sure how we can make DevTools
more useful here ?

*Do other browser engines implement this?*
Shipped: Chrome (since version 37)
Considering: Edge ( http://status.modern.ie/dialogelementformodals )

*Tests*:
https://github.com/w3c/web-platform-tests/blob/master/
html/dom/interfaces.html#L1835
https://github.com/w3c/web-platform-tests/tree/master/
html/semantics/interactive-elements/the-dialog-element
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform