Summary: This specification extends HTMLMediaElement to allow JavaScript to
generate media streams for playback. Allowing JavaScript to
generate streams facilitates a variety of use cases like adaptive
streaming and time shifting live streams.
Bug: mediasource (778617)
On Tuesday, May 6, 2014 7:30:42 PM UTC-4, Ehsan Akhgari wrote:
> On 2014-05-06, 6:41 PM, Jonas Sicking wrote:
>
> >> That's why if we just expose different features on the object returned by
> >> getContext("webgl") depending on client hardware details, we will create a
> >> compatibility mess, un
On 2014-05-06, 9:46 PM, Robert O'Callahan wrote:
On Wed, May 7, 2014 at 12:31 PM, Kip Gilbert wrote:
As of May 7, 2014 I intend to turn css sticky positioning on by default
for desktop (already enabled on B2G). It has been developed behind the
layout.css.sticky.enabled preference.
This featur
On Wed, May 7, 2014 at 12:31 PM, Kip Gilbert wrote:
> As of May 7, 2014 I intend to turn css sticky positioning on by default
> for desktop (already enabled on B2G). It has been developed behind the
> layout.css.sticky.enabled preference.
>
> This feature has been enabled for some time on mobile,
On 5/6/14, 5:40 PM, Fitzgerald, Nick wrote:
On 5/6/14, 5:31 PM, Jonas Sicking wrote:
Are these warnings ever useful enough that this is worth it?
Personally, I think not. Bill seemed to really like them. *shrug*
This was why I thought it might be easier to just make it optional.
IIUC, Eddy'
On 5/6/14, 5:31 PM, Jonas Sicking wrote:
Are these warnings ever useful enough that this is worth it?
Personally, I think not. Bill seemed to really like them. *shrug*
This was why I thought it might be easier to just make it optional.
___
dev-platfo
As of May 7, 2014 I intend to turn css sticky positioning on by default
for desktop (already enabled on B2G). It has been developed behind the
layout.css.sticky.enabled preference.
This feature has been enabled for some time on mobile, has already
shipped in Safari (-webkit prefixed), and can
On Tue, May 6, 2014 at 4:13 PM, Fitzgerald, Nick
wrote:
> Perhaps a more extensible solution would be the option to turn the extra
> warnings on/off for different test suites.
Are these warnings ever useful enough that this is worth it?
/ Jonas
___
dev
The crux of the issue here seems to be whether we want WebGL to be more
like OpenGL or more like the web. Each approach carries an impedence
mismatch with a large class of content. So it kind of boils down to whether
we're more trying to lure OpenGL developers to the web or lure web
developers to 3
On 2014-05-06, 6:41 PM, Jonas Sicking wrote:
That's why if we just expose different features on the object returned by
getContext("webgl") depending on client hardware details, we will create a
compatibility mess, unlike other Web APIs.
The main probably that you have is that you haven't design
2014-05-06 18:41 GMT-04:00 Jonas Sicking :
> I disagree with several points of this email.
>
> On Tue, May 6, 2014 at 2:18 PM, Benoit Jacob
> wrote:
> > So, thinking more about this, here's what I think is the deeper concern
> > here.
> >
> > If we make a feature available, we have to expect that
On 5/6/14, 3:29 PM, Bill McCloskey wrote:
- Original Message -
From: "Chris Peterson"
To: dev-platform@lists.mozilla.org
Sent: Tuesday, May 6, 2014 3:11:40 PM
Subject: Re: Disabling strict warnings as errors in xpcshell
btw, I believe the JS team now uses the term "extra warnings" to
d
I disagree with several points of this email.
On Tue, May 6, 2014 at 2:18 PM, Benoit Jacob wrote:
> So, thinking more about this, here's what I think is the deeper concern
> here.
>
> If we make a feature available, we have to expect that people will write
> code assuming support for it. We can't
- Original Message -
> From: "Chris Peterson"
> To: dev-platform@lists.mozilla.org
> Sent: Tuesday, May 6, 2014 3:11:40 PM
> Subject: Re: Disabling strict warnings as errors in xpcshell
>
> btw, I believe the JS team now uses the term "extra warnings" to
> differentiate SpiderMonkey's non
On 5/6/14, 1:49 PM, Eddy Bruel wrote:
Strict warnings as errors has been a continuous source of pain for the
devtools team. Substantial areas of our code area currently not strict
warning free.
The reason this leads to problems is that the way the werror flag is
propagated makes no sense: it is
So, thinking more about this, here's what I think is the deeper concern
here.
If we make a feature available, we have to expect that people will write
code assuming support for it. We can't honestly believe that all Web
developers write careful feature checks for all the features they depend on.
The most annoying thing for me (other than seemingly arbitrary changes
causing whole suites to fail despite correct functionality) is that it
breaks duck typing and causes code like:
if (obj.quacks) {
...
}
to fail tests. So in these cases, we are forced to write code something
like:
Strict warnings as errors has been a continuous source of pain for the
devtools team. Substantial areas of our code area currently not strict
warning free.
The reason this leads to problems is that the way the werror flag is
propagated makes no sense: it is a context wide flag, which individua
On Tue, May 6, 2014 at 10:20 AM, Ian Hickson wrote:
> On Tue, 6 May 2014, Robert O'Callahan wrote:
> > On Tue, May 6, 2014 at 5:57 PM, Ian Hickson wrote:
> > >
> > > Just so we're clear, I really don't care what the name is, nor do I
> > > have any objection to people having private conversation
On Tuesday 2014-05-06 10:15 -0700, Ralph Giles wrote:
> It looks like doing so would violate to webgl1 spec. "An attempt to use
> any features of an extension without first calling getExtension to
> enable it must generate an appropriate GL error and must not make use of
> the feature." https://www
On 2014-05-06, 1:21 PM, Benoit Jacob wrote:
2014-05-06 13:07 GMT-04:00 Boris Zbarsky :
On 5/6/14, 12:53 PM, Benoit Jacob wrote:
Ah, I see the confusion now. So the first reason why what you're
suggesting
wouldn't work for WebGL is that WebGL extension my add functionality
without changing any
2014-05-06 13:15 GMT-04:00 Ralph Giles :
> On 2014-05-06 9:53 AM, Benoit Jacob wrote:
>
> > By default, WebGL does not allow FLOAT to be passed for
> > the type parameter of the texImage2D method. The OES_texture_float
> > extension make that allowed.
>
> I have trouble seeing how this could break
2014-05-06 13:07 GMT-04:00 Boris Zbarsky :
> On 5/6/14, 12:53 PM, Benoit Jacob wrote:
>
>> Ah, I see the confusion now. So the first reason why what you're
>> suggesting
>> wouldn't work for WebGL is that WebGL extension my add functionality
>> without changing any IDL at all.
>>
>
> Sure, but we'
On Tue, 6 May 2014, Robert O'Callahan wrote:
> On Tue, May 6, 2014 at 5:57 PM, Ian Hickson wrote:
> >
> > Just so we're clear, I really don't care what the name is, nor do I
> > have any objection to people having private conversations or whatnot.
> > My point is just that there has not been a c
On 2014-05-06 9:53 AM, Benoit Jacob wrote:
> By default, WebGL does not allow FLOAT to be passed for
> the type parameter of the texImage2D method. The OES_texture_float
> extension make that allowed.
I have trouble seeing how this could break current implementations. If a
page somehow looks for
On 5/6/14, 12:53 PM, Benoit Jacob wrote:
Ah, I see the confusion now. So the first reason why what you're suggesting
wouldn't work for WebGL is that WebGL extension my add functionality
without changing any IDL at all.
Sure, but we're not talking about arbitrary WebGL extensions. We're
talkin
2014-05-06 12:53 GMT-04:00 Benoit Jacob :
>
>
>
> 2014-05-06 12:32 GMT-04:00 Boris Zbarsky :
>
> On 5/6/14, 12:25 PM, Benoit Jacob wrote:
>>
>>> To what extent does what I wrote in my previous email, regarding
>>> interactions between different extensions, answer your question?
>>>
>>
>> I'm not s
2014-05-06 12:32 GMT-04:00 Boris Zbarsky :
> On 5/6/14, 12:25 PM, Benoit Jacob wrote:
>
>> To what extent does what I wrote in my previous email, regarding
>> interactions between different extensions, answer your question?
>>
>
> I'm not sure it answers it at all.
>
>
> With the example approach
On 5/6/14, 12:25 PM, Benoit Jacob wrote:
To what extent does what I wrote in my previous email, regarding
interactions between different extensions, answer your question?
I'm not sure it answers it at all.
With the example approach you suggested above, one would have to specify
extensions sep
2014-05-06 12:11 GMT-04:00 Boris Zbarsky :
> On 5/6/14, 12:03 PM, Benoit Jacob wrote:
>
>> Indeed, the alternative to doing WebGL2
>> is to expose the same functionality as a collection of WebGL 1 extensions
>>
>
> I think Anne's question, if I understood it right, is why this requires a
> new con
On 5/6/14, 12:03 PM, Benoit Jacob wrote:
Indeed, the alternative to doing WebGL2
is to expose the same functionality as a collection of WebGL 1 extensions
I think Anne's question, if I understood it right, is why this requires
a new context ID.
I assume the argument is that if you ask for th
2014-05-06 11:04 GMT-04:00 Anne van Kesteren :
> On Tue, May 6, 2014 at 3:57 PM, Thomas Zimmermann
> wrote:
> > I think Khronos made a bad experience with backwards compatible APIs
> > during OpenGL's history. They maintained a compatible API for OpenGL for
> > ~15 years until it was huge and cru
On Tue, May 6, 2014 at 3:57 PM, Thomas Zimmermann
wrote:
> I think Khronos made a bad experience with backwards compatible APIs
> during OpenGL's history. They maintained a compatible API for OpenGL for
> ~15 years until it was huge and crufty. Mode switches are their solution
> to the problem.
Y
Hi
>>
>> [1] «WebGL 2 is backwards compatible with WebGL 1: existing content will
>> run in WebGL 2 without modification. To access the new behavior provided
>> in this specification, the content explicitly requests a new context»
>
> It seems I missed something.
>
> However, I cannot find where
On Tue, May 6, 2014 at 2:00 PM, Gabriele Svelto wrote:
> On 06/05/2014 14:43, Anne van Kesteren wrote:
>> I suppose longer term we can map the older version to the newer
>> versions somehow, but that's still an awfully big API surface area to
>> maintain.
>
> The wording of the spec seems to imply
On 06/05/2014 14:43, Anne van Kesteren wrote:
> I suppose longer term we can map the older version to the newer
> versions somehow, but that's still an awfully big API surface area to
> maintain.
The wording of the spec seems to imply that besides the context creation
the API is a superset of WebG
On Mon, May 5, 2014 at 11:07 PM, Dan Glastonbury
wrote:
> /Link to standard/: https://www.khronos.org/registry/webgl/specs/latest/2.0/
This looks really sad. For each new version of OpenGL, are we going to
have a new version of the API we end up having to support forever? How
exactly does Khronos
On Tue, May 6, 2014 at 5:57 PM, Ian Hickson wrote:
> Just so we're clear, I really don't care what the name is, nor do I have
> any objection to people having private conversations or whatnot. My point
> is just that there has not been a conversation in the WHATWG list about
> this which has resu
Hi,
I've been packaging an XR app for OSX since the begining of times (XR1.8)
and while there has always been glitches and adjustments, I've always been
able to upgrade (I use C++ XPCOM components and I build outside the mozilla
tree).
I am trying to update from 14 to 29 and while the compilation
39 matches
Mail list logo
