Hi
Am 16.07.2015 um 00:47 schrieb Jeff Gilbert:
> On Tue, Jul 14, 2015 at 7:55 AM, Thomas Zimmermann
> mailto:tzimmerm...@mozilla.com>> wrote:
>
> The discussion has a number of good points in favor of using 'a',
> but I
> missed convincing arguments in favor of not using 'a'. Are ther
On Wed, Jul 15, 2015 at 12:42 PM, Jan-Ivar Bruaroey wrote:
> This means it will throw TypeError on set of: MediaSource objects, Blob
> objects, and File objects, for now.
For what it's worth, I think implementing Blob/File support would be
quite trivial. Just make
elem.srcObject = blob;
interna
Hello,
(mostly for people of DOM and CSS)
tl;dr: A list of unprefixed properties where the prefixed version has been
dropped.
Context:
A feature has 4 states (or at least my impression):
1. No support
2. prefixed only support (MozFoo and -moz-bar)
3. prefixed and unprefixed support (MozFoo, F
On 7/15/15 3:42 PM, Jan-Ivar Bruaroey wrote:
This means it will support get/set of: MediaStream objects.
This means it will throw TypeError on set of: MediaSource objects, Blob
objects, and File objects, for now.
Jan-Ivar,
Do you happen to know whether other UAs support this unprefixed and if
On 7/15/15 9:28 PM, jyaven...@mozilla.com wrote:
I need to complete bug 886194 then (that add MSE supports).
Yes, or at least rename the subject slightly. ;)
PS: We have the same first name in different language. awesome.
Hey, that's rare for us!
.: Jan-Ivar :.
___
On Thursday, July 16, 2015 at 5:42:39 AM UTC+10, Jan-Ivar Bruaroey wrote:
> Hi,
>
> We intend to un-prefix HTMLMediaElement.srcObject (it currently exists
> as HTMLMediaElement.mozSrcObject), even though it only supports a subset
> of the types mandated in the spec. [1]
>
> This means it will s
On 07/15/2015 10:42 PM, Jan-Ivar Bruaroey wrote:
Hi,
We intend to un-prefix HTMLMediaElement.srcObject (it currently exists as
HTMLMediaElement.mozSrcObject), even though it only supports a subset of the
types mandated in the spec. [1]
It is a bit unfortunate to expose the property without su
Hooray!
Rob
--
lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf
toD
selthor stor edna siewaoeodm or v sstvr esBa kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea
lurpr
.a war hsrer holsa rodvted,t nenh hneireseoouo
On Thu, Jul 16, 2015 at 4:54 AM, Martin Thomson wrote:
> On Wed, Jul 15, 2015 at 4:12 AM, wrote:
> > some people believe that web applications should be "installable"
>
> I don't subscribe to that theory. The web is comprised of pages, not
> apps. (I mostly agree with Alex, but not regarding
On 7/15/2015 5:47 PM, Andrew Sutherland wrote:
Would it be crazy for us to resort to a poll on these things?
A poll will not be useful for informing this decision.
--BDS
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mo
On 07/16/2015 01:47 AM, Jeff Gilbert wrote:
On Tue, Jul 14, 2015 at 7:55 AM, Thomas Zimmermann
wrote:
The discussion has a number of good points in favor of using 'a', but I
missed convincing arguments in favor of not using 'a'. Are there any? I
don't consider "I don't get what 'a' is good for
For the e10s talos regressions see
https://bugzilla.mozilla.org/show_bug.cgi?id=1174776 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1184277. We've already
diagnose one source of the regression to be a difference with GC/CC
behavior when running e10s talos.
On Fri, Jul 10, 2015 at 5:44 PM, Vla
On Tue, Jul 14, 2015 at 7:55 AM, Thomas Zimmermann
wrote:
> The discussion has a number of good points in favor of using 'a', but I
> missed convincing arguments in favor of not using 'a'. Are there any? I
> don't consider "I don't get what 'a' is good for" a convincing argument.
>
On the other
Would it be crazy for us to resort to a poll on these things? I propose
abusing the mozillans.org "skills" field in profiles.
For example, I have created the following sets of skills on
mozillians.org by question, and which should autocomplete if you go to
the edit page for your profile at
https:
On Wed, Jul 15, 2015 at 2:26 PM, Gregory Szorc wrote:
> The public source code for Firefox has existed for 17+ years (since ~April
> 1998). We can only assume it will be around for another 10+ years.
>
> I believe you have to take the long view on the cost benefit analysis and
> realize that a lo
The public source code for Firefox has existed for 17+ years (since ~April
1998). We can only assume it will be around for another 10+ years.
I believe you have to take the long view on the cost benefit analysis and
realize that a lot of pain in the short term (e.g. switching styles
entirely) will
On Tue, Jul 14, 2015 at 9:17 PM, Nicholas Nethercote wrote:
> On Tue, Jul 14, 2015 at 8:06 PM, Bobby Holley
> wrote:
> > I'm not wild about this idea.
>
> It's such a boil-the-ocean solution I honestly thought bsmedberg was
> joking at first...
>
Well consistency is a major concern, so as long
Hi all
We intend to implement the referrer policy delivery method via attribute as
specified in the referrer policy spec (editor's draft [1]) to allow per
element referrer policies for , , , and tags. The
attribute is enabled via the pref network.http.enablePerElementReferrer and
will be initiall
Hi,
We intend to un-prefix HTMLMediaElement.srcObject (it currently exists
as HTMLMediaElement.mozSrcObject), even though it only supports a subset
of the types mandated in the spec. [1]
This means it will support get/set of: MediaStream objects.
This means it will throw TypeError on set of:
The Web API documentation community meeting, with representatives from
the technical evangelism and the API development teams, will take place
on Thursday at 8 AM Pacific Time (see http://bit.ly/1GghwBR for your
time zone).
Typical meetings include news about recent API development progress and
fu
On Wed, Jul 15, 2015 at 4:12 AM, wrote:
> some people believe that web applications should be "installable"
I don't subscribe to that theory. The web is comprised of pages, not
apps. (I mostly agree with Alex, but not regarding the perceived need
for "app discoverability"; I hear Google has a
On Wed, Jul 15, 2015 at 1:12 PM, wrote:
> Do we even agree on the above?
I agree with some of it... But, I don't really see the point of trying
to merge web and native (other than turning the browser into the OS).
And I really don't see the point of trying to play by native's rules
when doing so
Yes, please!
On 2015-07-14 3:22 PM, nsm.nik...@gmail.com wrote:
Hello,
Target release: Firefox 42
Implementation and shipping bug:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=1114554
Specification: https://notifications.spec.whatwg.org/#service-worker-api
This is a follow up to the N
On Wednesday, July 15, 2015 at 3:34:42 PM UTC+10, Anne van Kesteren wrote:
> On Wed, Jul 15, 2015 at 12:00 AM, wrote:
> > * It's not clear what problems manifest solves
>
> This is by far the biggest problem. I think we ended up with manifests
> because packages have manifests and iOS/Android u
On 15 July 2015 at 10:42, Jonas Sicking wrote:
> I also think that "display-mode" and "orientation" (and maybe
> "theme_color") properties seem to make much less sense given the
> current model of manifests. That seems like information that we'd want
> to apply during normal browsing too, which m
On 15 July 2015 at 10:42, Jonas Sicking wrote:
> But it'd be *really* nice to get rid of features that are there
> specifically to migrate users away from the web and to native Android
> and iOS apps. If google/apple wants to implement that then that's fine
> with me, it's their browsers. I just
On Tue, Jul 14, 2015 at 3:00 PM, wrote:
>
> Some of the things raised:
>
> * It's not clear what problems manifest solves: do we really want to
> replicate "native app" installation behavior on the Web? We don't have a good
> history of making this work in various products.
> * Extra HTTP req
On 14 July 2015 at 23:00, wrote:
> A few people have reached out to me with concerns about implementing web
> manifest in Gecko and have asked me to restart this thread (given that no
> one objected the first time around). There are concerns about the utility
> of Web manifests, the overall visio
On Wed, Jul 15, 2015 at 8:15 AM, wrote:
> 1. Enhance browser tiles: many sites have nice logos/icons, and they have an
> application-name. I want to show the application-name and icon or logo them
> in tiles in the new tab page.
This seems possible using + .
> 2. Page previews suck today: t
29 matches
Mail list logo
