Intent to Ship : HTML5 element (Nightly Only)

[Sean Feng]

Intent to Ship (Nightly Only) : Dialog Element
​
Hi All,
​
In bug 1645046 , I 
intend to turn html5  element on by default in Nightly. It has 
been developed behind the dom.dialog_element.enabled preference.

​
Meta Tracking Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
​
This is Nightly only because two things needs adjustment in our 
implementation.

​
1. The inert element isn't supported (bug 921504 - 
https://bugzilla.mozilla.org/show_bug.cgi?id=921504).


 - For modal dialog, elements that are not part the dialog should be 
mark as inert, so these elements gain the inert-ness and can't be 
focused. Since we don't have inert supported yet, users could use tab to 
move focus out of the dialog, which is not expected.


 - Next Step: The implementation of inert element is going to be 
started soon (I think), and we can also discuss to support the 
inert-ness without the supporting of inert element

​
2. We currently use a temporary solution for the layout of modal dialog. 
(bug 1637310 - https://bugzilla.mozilla.org/show_bug.cgi?id=1637310).


  - Currently the spec defines modal dialog as an absolute element, 
along with some weird calculation requirement to make the element 
centered. This modal dialog layout felt like a hack to us, so we didn't 
follow it, and instead, we used a temporary solution 
(https://bugzilla.mozilla.org/show_bug.cgi?id=1642364) to make the modal 
dialog as a centered fixed element.


  - Next Step: The CCSWG agreed to switch modal dialog to be a centered 
fixed element 
(https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-642130060), 
which is the same as the temporary solution we applied in bug 1642364. 
So the temporary solution may become a permanent solution after things 
have been finalized in spec.

​
*Status in other browsers*
Chrome has it enabled by default since Release 37 
https://www.chromestatus.com/feature/5770237022568448


*web-platform-tests*: 
https://github.com/web-platform-tests/wpt/tree/master/html/semantics/interactive-elements/the-dialog-element, 
We have them all enabled and passing except for those layout and inert 
related ones.


*Spec* - https://html.spec.whatwg.org/multipage/#the-dialog-element

This feature was previously discussed in 
https://groups.google.com/d/msg/mozilla.dev.platform/vTPGW1aJq24/JnEnoH3BEAAJ


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

Re: Intent to Ship : HTML5 element (Nightly Only)

[Sean Feng]

Yeah, agreed.

I just filed https://github.com/whatwg/html/issues/5678 for moving the
focus back to what had focused before when the dialog is dismissed.

On Wed, Jun 24, 2020 at 4:19 PM James Teh  wrote:

> While this doesn't need to block shipping in Nightly, I think we should
> consider advocating for the focus behaviour to be changed (and changing it
> in Firefox if we can get it into the spec) before we ship to release.
>
> The currently specified behaviour (and what both Firefox and Chrome
> implement) is to focus the first focusable element in the dialog. However,
> there are a few major problems with this, including:
> 1. This means a tabindex="-1" element could get focus, which is focusable
> but not in the tab order. That's particularly strange if this gets focus in
> preference to something which *does* participate in the tab order.
> 2. The first focusable element could be a long way down the page; e.g. a
> dialog with a lot of preamble text and a form field or button after that
> text. That is particularly problematic for screen reader users because that
> will direct their reading cursor to the focused control, so they will
> potentially not realise they're missing content above it. It might even
> cause the page to scroll visually.
>
> What I (and others in the accessibility community) am proposing is that
> the dialog element itself should get focus, unless something within the
> dialog has autofocus set, in which case we should focus that. There's a
> spec issue for this, but it stalled:
> https://github.com/whatwg/html/issues/1929
>
> Another concern is that when the dialog is dismissed, focus gets thrown
> back to the document. Instead, I think it should be returned to the element
> which had focus before the dialog was shown, which is the recommended
> pattern for good accessibility of dialogs. I don't think there is a spec
> issue for this yet.
>
> Jamie
>
> On Thu, Jun 25, 2020 at 6:04 AM Sean Feng  wrote:
>
>> Intent to Ship (Nightly Only) : Dialog Element
>> ​
>> Hi All,
>> ​
>> In bug 1645046 <https://bugzilla.mozilla.org/show_bug.cgi?id=1645046>, I
>> intend to turn html5  element on by default in Nightly. It has
>> been developed behind the dom.dialog_element.enabled preference.
>> ​
>> Meta Tracking Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=840640
>> ​
>> This is Nightly only because two things needs adjustment in our
>> implementation.
>> ​
>> 1. The inert element isn't supported (bug 921504 -
>> https://bugzilla.mozilla.org/show_bug.cgi?id=921504).
>>
>>   - For modal dialog, elements that are not part the dialog should be
>> mark as inert, so these elements gain the inert-ness and can't be
>> focused. Since we don't have inert supported yet, users could use tab to
>> move focus out of the dialog, which is not expected.
>>
>>   - Next Step: The implementation of inert element is going to be
>> started soon (I think), and we can also discuss to support the
>> inert-ness without the supporting of inert element
>> ​
>> 2. We currently use a temporary solution for the layout of modal dialog.
>> (bug 1637310 - https://bugzilla.mozilla.org/show_bug.cgi?id=1637310).
>>
>>- Currently the spec defines modal dialog as an absolute element,
>> along with some weird calculation requirement to make the element
>> centered. This modal dialog layout felt like a hack to us, so we didn't
>> follow it, and instead, we used a temporary solution
>> (https://bugzilla.mozilla.org/show_bug.cgi?id=1642364) to make the modal
>> dialog as a centered fixed element.
>>
>>- Next Step: The CCSWG agreed to switch modal dialog to be a centered
>> fixed element
>> (https://github.com/w3c/csswg-drafts/issues/4645#issuecomment-642130060),
>>
>> which is the same as the temporary solution we applied in bug 1642364.
>> So the temporary solution may become a permanent solution after things
>> have been finalized in spec.
>> ​
>> *Status in other browsers*
>> Chrome has it enabled by default since Release 37
>> https://www.chromestatus.com/feature/5770237022568448
>>
>> *web-platform-tests*:
>>
>> https://github.com/web-platform-tests/wpt/tree/master/html/semantics/interactive-elements/the-dialog-element,
>>
>> We have them all enabled and passing except for those layout and inert
>> related ones.
>>
>> *Spec* - https://html.spec.whatwg.org/multipage/#the-dialog-element
>>
>> This feature was previously discussed in
>>
>> https://groups.google.com/d/msg/mozilla.dev.platform/vTPGW1aJq24/JnEnoH3BEAAJ
>>
>> ___
>> 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

Intent to ship: PerformancePaintTiming API

[Sean Feng]

/Summary: /PerformancePaintTiming API allows developers to measure the 
paint timing metric for their websites during pageload.



/Bug/: 1518999

/Standard/: https://w3c.github.io/paint-timing/. There are two timing 
entries defined in spec (`first-paint`(optional) and 
`first-contentful-paint`). We'll only be shipping `first-contentful-paint`.


/Platform coverage/: All Platforms

/Preference/: N/A

/DevTools bug/: N/A

/Other browsers/: Chrome has it shipped since version 60 (Chrome ships 
both `first-paint` and `first-contentful-paint`). Safari also has it 
implemented https://bugs.webkit.org/show_bug.cgi?id=78011 
(`first-contentful-paint` only), however I am not sure if it's still 
behind the experimental flag.


/web-platform-tests/: 
https://github.com/web-platform-tests/wpt/tree/master/paint-timing/fcp-only


Thanks,

Sean

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

Intent to Prototype: PerformanceEventTiming API

[Sean Feng]

Summary: PerformanceEventTiming API provides web page authors with
insights into the latency of certain events triggered by user
interactions. This is prerequisite for Web Vital.

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

Standard: https://wicg.github.io/event-timing/#sec-performance-event-timing

Platform coverage: All Platforms

Preference: dom.enable_event_timing

DevTools bug: N/A

Other browsers:
  - Chrome: Enabled by default since 85.
  - Safari: Not implemented

web-platform-tests: 
https://github.com/web-platform-tests/wpt/tree/master/event-timing

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

Intent to ship: PerformanceEventTiming API

[Sean Feng]

As of Firefox 89, I intend to turn PerformanceEventTiming API on by default on 
all channels. It has been developed behind the `dom.enable_event_timing` 
preference. Chrome has it enabled by default since 85. 

Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1701029

This feature was previously discussed in this "Intent to prototype" thread: 
https://groups.google.com/g/mozilla.dev.platform/c/No44oD66MuU/m/nt342mAfBQAJ.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform