l5_audio_video/device-specificconsiderations/device-specificconsiderations.html
On Aug 22, 2014, at 10:17 AM, Hubert Figuière wrote:
> On 21/08/14 01:29 PM, Wesley Johnston wrote:
>> Summary: We've had some complaints at times about videos autoplaying on
>> mobile device
> In general, I'm in favour of not autoplaying at all on mobile devices.
I think I was just trying to address the spec's statement of overriding when
not desired. I don't want to punish sites that are reading that and trying to
be good citizens. For instance, elements are actually a good solutio
Summary: We've had some complaints at times about videos autoplaying on mobile
devices when sites request autoplay. We should be more mindful of users and try
to avoid using data if they don't want it. Sites should be doing this for us,
but we've encountered pages where that is not the case. I'm
ge/Color
Am Montag, 4. August 2014 20:39:34 UTC+2 schrieb Wesley Johnston:
> I have never seen this! Seems like something we could use. i.e. we would
> still need a logo designed to be shown against the site color.
There is link[rel=icon] with sizes attribute (support for multiple size
Intent to implement/ship: Support for
msApplication-TileImage/Color
On Sun, 03 Aug 2014 14:37:40 -0700, Florian Bender wrote:
> Am Freitag, 1. August 2014 18:11:23 UTC+2 schrieb Wesley Johnston:
>> Link to standard: There is no public standard in place for these
>> meta-tags an
Summary: In Firefox 33 we shipped support for msApplication-TileImage/Color
meta tags in pages. These are meant to be shown on our homescreen in place of
thumbnails when they are available. See
http://digdug2k.wordpress.com/2014/07/30/better-tiles-in-fennec/ for a
screenshot. These allow the si
> When you say "intent to implement" what is it you're planning on
> implementing?
For the initial drop here, we've implemented a way for web apps (or sites if we
decide to enable this for them, but after talking here and with the team, I
think restricting this to WebApps is a good idea), to fi
Android also ships a parser that we wrote for Reader mode:
http://mxr.mozilla.org/mozilla-central/source/mobile/android/chrome/content/JSDOMParser.js
We've talked about extending it to also do phone number/address detection as
well, but haven't tried (reader mode doesn't need to modify the origi
> 1.2.2. TeX is very friendly to manual writing, being concise and
> close to natural notation, with limited overhead (some backslashes and
> curly braces), while MathML is as tedious to handwrite as any other
> XML-based format. An example is worked out at
> http://en.wikipedia.org/wiki/MathML#Exa
ound
On 4/25/13 4:47 PM, Wesley Johnston wrote:
> Requesting one set of tests on one platform is a 6-10 hour turnaround for me.
That's surprising. https://tbpl.mozilla.org/?tree=Try&rev=9d1daf69061d
was a midday -b do -p all -u all with a 3 hour 40 minute end-to-end.
Or did you mean,
Requesting one set of tests on one platform is a 6-10 hour turnaround for me.
- Original Message -
From: "Neil"
To: dev-platform@lists.mozilla.org
Sent: Thursday, April 25, 2013 4:36:02 PM
Subject: Re: Some data on mozilla-inbound
Justin Lebar wrote:
>Note that we don't have enough capa
On Android at least, we don't seem to have this same mutually exclusive
gesture/touches problem. We receive touches in our Native UI layer, send them
to Gecko, and use Native gesture detectors at the same time. That code is in a
bit of flux at the moment as we're merging our Asynchronous Pan-Zoo
12 matches
Mail list logo
