From 88f26c3143dd7b85adeaf9cb91b7cee7185d7c12 Mon Sep 17 00:00:00 2001 From: Anne van Kesteren Date: Wed, 2 Aug 2017 15:52:22 +0200 Subject: [PATCH] Point out how media.buffered/played/seekable are broken Hopefully this lessens the likelihood of the pattern being copied. Fixes https://www.w3.org/Bugs/Public/show_bug.cgi?id=22471. --- source | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/source b/source index a50a169dc14..0eae5147fac 100644 --- a/source +++ b/source @@ -33686,6 +33686,9 @@ interface HTMLMediaElement : HTMLElement { data-x="dom-media-buffered">buffered attribute at one time can end up being not included in the range(s) of objects returned by the same attribute at later times.

+

Returning a new object each time is a bad pattern for attribute getters and is + only enshrined here as it would be costly to change it. It is not to be copied to new APIs.

+ @@ -34555,6 +34558,9 @@ interface HTMLMediaElement : HTMLElement { increase of the current playback position during normal playback, if any, at the time the attribute is evaluated.

+

Returning a new object each time is a bad pattern for attribute getters and is + only enshrined here as it would be costly to change it. It is not to be copied to new APIs.

+

Each media element has a list of pending play promises, which must @@ -35208,6 +35214,9 @@ interface HTMLMediaElement : HTMLElement { sliding window on an infinite stream. This is the behavior seen with DVRs viewing live TV, for instance.

+

Returning a new object each time is a bad pattern for attribute getters and is + only enshrined here as it would be costly to change it. It is not to be copied to new APIs.

+

User agents should adopt a very liberal and optimistic view of what is seekable. User agents should also buffer recent content where possible to enable seeking to be fast.