It has been a pleasure working with you Art. Your expertise, leadership
and diplomacy will be missed. I wish you the best for your future
endeavours!
-- Mounir
On Sat, 30 Jan 2016, at 12:29, Jungkee Song wrote:
> Thank you Art! It has been a great experience and joy working with you.
> Your calm
On Thu, 15 Oct 2015, at 20:07, Binyamin wrote:
> בע"ה
>
>
> How about gradients in "background_color" (linear-gradient,
> radial-gradient, repeating-linear-gradient, repeating-radial-gradient)?
> Anything delays such spec/implementation?
The goal is to be able to paint something on the screen
min [mailto:7rai...@inbox.lv]
> Sent: Thursday, October 15, 2015 15:08
> To: public-webapps@w3.org
> Cc: Mounir Lamouri <mou...@lamouri.fr>
> Subject: [manifest] Manifest "splash_screens" with animated "any" size
> SVG
>
> בע"ה
>
> Hi,
>
&
Hi Binyamin,
Thank you for your question.
I think this behaviour should be left to the implementation there is a
lot of UI decisions here that can't be spec'd. For example, Chrome would
likely pick a 32x32 image when it needs a 16x16 one but might not do the
other way around. Some UA might avoid
iring missing 40x40
> size image.
>
>
> Binyamin
>
>
> On Tue, Oct 13, 2015 at 11:51 AM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
>
> > Hi Binyamin,
> >
> > Thank you for your question.
> >
> > I think this behaviour should b
On Wed, 6 May 2015, at 19:07, Doug Turner wrote:
On May 6, 2015, at 11:00 AM, Jonas Sicking jo...@sicking.cc wrote:
FWIW, the permission API as it currently stands is pretty trivial to
implement. So I don't see a reason to delay until 2017 or even Q3
2015.
If the spec is ready to
(bcc: public-webapps@)
Hi,
I would like to standardize the Apple's proprietary autocapitalize
attribute. This attribute is widely used and it would probably benefit
the platform to have a broader support for it. The implementation cost
should be fairly low while it can be very beneficial for the
Thank you for the report.
Internationalization is clearly one of the major next milestones for the
Manifest. As long as it only contains simple properties like name or
icons, i18n is a minor problem because often these properties are
fairly stable across locales - at least, even if we are aware
(I realise that my reply went to public-webapps instead of whatwg, not
sure why. I will blame my email client :))
On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:
Wouldn't be worth experimenting first with a list of predefined share
endpoints (that you anyway might want to have) and see
On Tue, 4 Nov 2014, at 03:42, Anne van Kesteren wrote:
A couple of us at Mozilla have been trying to figure out how to revive
activities/intents for the web. Both work relatively well in closed
environments such as Firefox OS and Android, but seem harder to deploy
in a generic way on the web.
Can we at least publish a new WD so people stop referring to the old
TR/?
-- Mounir
On Wed, 1 Oct 2014, at 20:36, Arthur Barstow wrote:
On 9/25/14 9:26 AM, Mounir Lamouri wrote:
On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote:
On 9/25/14 6:36 AM, Anne van Kesteren wrote
On Thu, 25 Sep 2014, at 23:26, Mounir Lamouri wrote:
On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote:
On 9/25/14 6:36 AM, Anne van Kesteren wrote:
It effectively comes down to the fact that the specification describes
something, but Chrome implements it in another way per how I
On Tue, 16 Sep 2014, at 08:28, Jonas Sicking wrote:
I think it's likely to result in many implementation bugs if we rely
on this being defined buried inside an algorithm rather than at least
mentioned at the definition of the property.
I think it's good feedback. I could probably make this
On Tue, 16 Sep 2014, at 06:50, Frederick Hirsch wrote:
[cross posted to DAP]
I’d like to point out that work such as this would be allowed under the
W3C Device APIs WG charter [1] if this is of interest (not being sure of
current plans):
Arthur, would that work be aligned with the WebApps
On Fri, 12 Sep 2014, at 08:52, Jonas Sicking wrote:
Sorry, my first comment is a naming bikeshed issue. Feel free to
ignore as it's coming in late, but I hadn't thought of it until just
now.
I remember a wise person who once said never count on me to bikeshed
names. I think he was named Jonas
On Fri, 5 Sep 2014, at 03:23, Edward O'Connor wrote:
We should be avoiding adding features to the platform that have to
resort to explicit permissioning. Instead of adding features which
require prompting for permission, we should be designing features—like
drag drop or input type=file—that
On Thu, 4 Sep 2014, at 01:33, Kostiainen, Anssi wrote:
Given there's good discussion going on at the Paris meeting right now [4]
and the topic is on the agenda, I’m expecting more input from the meeting
participants on how to proceed.
Could you share here the outcome of that discussion if not
the one you wrote
above:
permissions.has({ name: 'bluetooth', devices: 'fitbit' });
because I understand what the call is trying to do. In addition, as you
pointed, it gives a lot of flexibility.
On Wed, 3 Sep 2014, at 05:45, Boris Zbarsky wrote:
On 9/2/14, 9:51 AM, Mounir Lamouri wrote
TL;DR:
Permissions API would be a single entry point for a web page to check if
using API /foo/ would prompt, succeed or fail.
You can find the chromium.org design document in [1].
# Use case #
The APIs on the platform are lacking a way to check whether the user has
granted them. Except the
+ri...@opera.com
On Wed, 6 Aug 2014, at 07:14, Jonas Sicking wrote:
Hi All,
I think the current interaction between the screen orientation and
device orientation specs is really unfortunate.
Any time that you use the device orientation in order to render
something on screen, you have to
On Fri, 25 Jul 2014, at 14:34, Bruno Racineux wrote:
Just took a peak at the latest spec [1], since Chrome Canary breaks my
code
made for the previous spec
and I have to update to a dual screen.orientation object|string context
(It
was previously a string).
Good to see the new 'natural'
On Tue, 24 Jun 2014, at 10:45, Glenn Adams wrote:
On Mon, Jun 23, 2014 at 3:05 PM, Marcos mar...@marcosc.com wrote:
Even if we were able to take the V1 bits to Rec (a lot of which is now
obsolete), the V2 stuff is already widely supported and heavily relied on
by browser vendors. IMO, it's
On Sat, 31 May 2014, at 10:40, Jeffrey Walton wrote:
I have a question about Use Cases for Installable WebApps located at
https://w3c-webmob.github.io/installable-webapps/.
Under section Add to Homescreen, the document states:
... giving developers the choice to tightly integrate their
On Wed, 28 May 2014, at 8:59, Jonas Sicking wrote:
On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres w...@marcosc.com wrote:
On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@sicking.cc) wrote:
On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote:
The only way that gmail would allow
On Thu, 1 May 2014, at 21:38, Arthur Barstow wrote:
On 4/30/14 1:19 PM, Mounir Lamouri wrote:
On Thu, 1 May 2014, at 1:50, EDUARDO FULLEA CARRERA wrote:
On 30 abr 2014 at 16:52:49, Arthur Barstow wrote:
On 4/30/14 10:44 AM, Arthur Barstow wrote:
I'll work with Mike/Robin to create a new
On Thu, 10 Apr 2014, at 0:01, Arthur Barstow wrote:
Perhaps it would be good then to file a bug for the Screen Orientation
spec and/or to add a related note to the ED. WDYT?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25310
-- Mounir
On Tue, 8 Apr 2014, at 9:08, Bruno Racineux wrote:
On https://www.w3.org/Bugs/Public/show_bug.cgi?id=25088 :
You cannot fire on window without also having the window.orientation
property (with its own issues*). That would break existing code relying
on
the webkit api (expecting to read a
On Tue, 8 Apr 2014, at 8:37, Ian Hickson wrote:
On Mon, 7 Apr 2014, Marcos Caceres wrote:
On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote:
On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. wrote:
Agreed. The exact target isn't very important here, and so being
Hi,
I have just updated the specification WD, solving most of the
outstanding issues:
https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html (it
is hot off the press, be gentle with typos and nits)
There are now only two outstanding bugs now:
Hi,
I would love to gather the opinion of public-webapps on a discussion
Hixie and I had for two different APIs recently: if an array |foo| can
change, should the change event be fired on its parent or the window
(its grandparent)? The two cases we discussed with Hixie were
navigator.languages
On Fri, 21 Mar 2014, at 2:28, Michael van Ouwerkerk wrote:
In WebIDL we can now use parameterized Promise types:
http://heycam.github.io/webidl/#idl-promise
My suggestion is that we make some minor changes in the Push API spec to
take advantage of this. It reads much better and the prose can
On Fri, 14 Mar 2014, at 6:44, Kenneth Rohde Christiansen wrote:
I am cc'ing Wonsuk and Christophe as Tizen is currently implementing (and
shipping?) the API as well; it's even unprefixed.
We are also supporting the current API in Crosswalk, but I am OK with the
change as most of our current
On Fri, 14 Mar 2014, at 16:09, Jonas Sicking wrote:
However it does mean that we need to also have a way to define that
orientation should be completely unlocked. This is needed since the
manifest spec allows overriding the default unlocked orientation. I.e.
it should be possible to use the
On Fri, 14 Mar 2014, at 19:07, Lars Knudsen wrote:
What happened to the initiative done to take a holistic view on all
orientation related specs and make them seem like they come from the same
entity (Device Motion, Media Queries, Orientation Lock, ...)?
Device Motion is about the device angle
, 2014 at 7:01 AM, Marcos Caceres w...@marcosc.com wrote:
On March 14, 2014 at 9:58:59 AM, Mounir Lamouri (mou...@lamouri.fr) wrote:
On Fri, 14 Mar 2014, at 16:09, Jonas Sicking wrote:
However it does mean that we need to also have a way to define that
orientation should be completely
On Thu, 13 Mar 2014, at 22:45, SULLIVAN, BRYAN L wrote:
One of the other changes in progress is to include service workers on the
design of the API. I don't know if that replaces system messages in total
but the necessary changes will be considered when a new draft is
submitted.
System
://www.w3.org/Bugs/Public/show_bug.cgi?id=24698
On Wed, 06 Nov 2013 11:27:08,Mounir Lamouri wrote:
Indeed, if I remember correctly, window.orientation=0 is the natural
orientation and then, the value is the angle between the current
orientation and the natural one in the range ] -180 ; 180
Hi,
I would like to change the Screen Orientation API to make the locking
steps a bit simpler. Currently, the API tries to be flexible and allow
locking to any combination of values like portrait, landscape,
portrait-primary but also [ portrait, landscape-primary ], [
portrait-primary,
FYI. For those not used to Blink's process, that doesn't mean the
feature is planning to ship yet but Google is working on this. The API
we are aiming for is a bit different from what the specification
currently describes as mentioned in the original message.
Cheers,
-- Mounir
- Original
Hi,
Arthur pointed out that the Screen Orientation API WD was not updated
since a long time. However, the ED got a few updates so we would like to
refresh the WD to have a better reflection of the current state of the
implementation.
You can find the current specification at:
On Sat, 8 Feb 2014, at 12:19, James Greene wrote:
There are certain situations where sync XHRs are, in fact, required...
unless we make other accommodations. For example, in the Clipboard API,
developers are allowed to inject into the clipboard as a semi-trusted
event
during the event
On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote:
Would any potential implementer consider supporting a HTTP based solution
to loading manifests?
It seems quite premature to discuss a HTTP based solution to advertise a
manifest. Even if it happens to be something developers ask for, we
On Wed, Dec 4, 2013, at 10:03, Marcos Caceres wrote:
From the research we’ve done, none of the proprietary solutions currently
do this. I’ve added this as a feature request [1] so we can see how much
interest there is.
I think it is exaggerated to say that pages rely on the user seeing the
On Mon, Dec 9, 2013, at 20:33, Yoav Weiss wrote:
IMO, it might be better not to define an explicit way to inline the
manifest, and let authors simply use data URIs to do that, if they see
such
a need.
e.g. link rel=manifest href=data:application/manifest+json,{ ... }
If this becomes a
On Thu, Dec 5, 2013, at 6:06, Jonas Sicking wrote:
On Dec 4, 2013 6:20 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
meta name=manifest content='{
a: 1,
b: foopy
}'
Are manifests really short enough for this kind of thing?
For single-page apps I would imagine it will be quite
On Thu, Dec 5, 2013, at 2:08, Mitar wrote:
But I agree, that requires some more changes. For example, currently
it is not really possible to style how found elements are highlighted.
And it is not possible for page to say to UA to retry searching
because the document has modified. I believe
On Wed, Dec 4, 2013, at 10:17, Marcos Caceres wrote:
On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:
Yes. In-apge Search is something that might also be useful within an app -
especially if you can find out it is happening and respond to it
intelligently if the
On Tue, Dec 3, 2013, at 6:48, Mitar wrote:
And there are real use cases. For example, go to some long document in
Google Docs and invoke browser search by going through menu (Edit -
Find or something similar). You will see that it does not work except
for the current document page. It does not
On Tue, Dec 3, 2013, at 16:13, Jonas Sicking wrote:
So I could see apps wanting to lock to that orientation (like you
pointed out, we found at least one example in Firefox OS).
However I don't understand the use case of locking to 90/180/270
degrees off of the normal orientation?
Simply
On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
My impression has been that the vast majority of apps only need a
single orientation that is independent of media-query results. If
that's the case, then I think the above is too complicated. I.e. if
that is the common case, then we should
On Tue, Dec 3, 2013, at 23:32, John Mellor wrote:
I definitely agree with that. Though, we should allow both syntaxes
(array and string).
If we want a more complex system later, we could move to that. For the
moment, I think we should keep it simple.
It seems an even simpler option
Hi,
I am not sure that telling the webpage what the user is currently trying
to search is a great idea. However, if a webpage wants its own find in
page UI I guess a simple solution would be to do something similar to
the Forms Validation UI: a 'findinpage' event could be fired on the
document
On Mon, Dec 2, 2013, at 23:27, Boris Zbarsky wrote:
On 12/2/13 6:42 AM, Mounir Lamouri wrote:
a 'findinpage' event could be fired on the
document when the user initiates a find in page and the page would be
able to call .preventDefault() on the event in order to show its own UI.
I assume
On Thu, Nov 28, 2013, at 9:32, Jonathan Bond-Caron wrote:
On Wed Nov 27 09:20 AM, Mounir Lamouri wrote:
On Wed, Nov 27, 2013, at 23:59, Jonathan Bond-Caron wrote:
On Tue Nov 26 04:02 PM, Marcos Caceres wrote:
Over the last few weeks, a few of us folks in the Web Mob IG have
been
On Wed, Nov 27, 2013, at 23:46, John Mellor wrote:
How should the Screen Orientation API handle cases where the web page's
window has the opposite orientation to the device's screen? Examples
where
this can occur include:
- Split screen tablet (like Win 8 Metro)
- Non-maximized window on
On Wed, Nov 27, 2013, at 8:02, Marcos Caceres wrote:
Over the last few weeks, a few of us folks in the Web Mob IG have been
investigating the use cases and requirements for bookmarking web apps to
home screen. The output of that research is this living document:
If Screen Orientation angle and Device Orientation have the same top for
the device, it should be easy to make an angle relative to the top of
screen instead of the top of the device. I would not recommend changing
Device Orientation API.
--
Mounir
On Wed, Nov 27, 2013, at 7:41, Kenneth Rohde
On Wed, Nov 27, 2013, at 23:59, Jonathan Bond-Caron wrote:
On Tue Nov 26 04:02 PM, Marcos Caceres wrote:
Over the last few weeks, a few of us folks in the Web Mob IG have been
investigating the use cases and requirements for bookmarking web apps to
home
screen. The output of that research
Hi,
I got some requests from different organizations to add the ability to
lock to the 'current' orientation in the Screen Orientation API.
From Javascript, that would allow writing
window.screen.lockOrientation('current');
instead of
window.screen.lockOrientation(window.screen.orientation);
Hi,
The Screen Orientation API defines an angle relationship between
portrait-primary and landscape-primary. The reason for that is that
developers would know which orientation is at 90 degrees from the
current orientation, which one is at 180 degrees, etc. However, by
forcing the two primary
On Wed, Nov 27, 2013, at 2:52, Marcos Caceres wrote:
IMHO, it would be confusing to have an app that when you launch it the
first time locks one way... but when you launch it the next time, locks
another way.
In the 300 apps we've been cataloguing for orientation [1], there is not
a single
On Wed, Nov 27, 2013, at 3:49, Kenneth Rohde Christiansen wrote:
a) Will this be a delta from the current orientation? or relative to
the default device orientation? I guess the former makes the most
sense.
Orientation angle compared to the native device orientation.
b) What should happen if
On Tue, Nov 5, 2013, at 22:35, Anne van Kesteren wrote:
On Tue, Nov 5, 2013 at 11:23 AM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
They are somewheat different things. The former is basically a way to get
accelerometer info (useful for games etc) and the latter is
On Wed, Nov 6, 2013, at 11:17, Jonas Sicking wrote:
Last I looked the property was useless because window.orientation=0
meant different things on different devices. I.e. on some devices it
meant landscape mode and others it meant portrait mode.
Indeed, if I remember correctly,
On 15/07/13 23:26, Kinuko Yasuda wrote:
OTOH one limitation I could think of in not having JS object is it'll
disallow a possible future API expansion for sending a 'Directory'
object to another app by postMessage. (It's another popular request we
get in Chrome)
Isn't a Directory object just
Hi,
I am not a big fan of the Directory approach of this proposal. It puts
the API between a high level, object oriented API and a low level API.
It is unfortunately not really high level because you have to use the
Directory for most operations and the File objects can't be subject to
any
On 24/06/13 12:24, Robin Berjon wrote:
* When Mozilla made this restriction (I don't know if it's still in
place) for its apps, developers complained.
Having multiple sub-domains is more complex than creating a directory
for a developer. Also, sometimes, it is not possible, depending on your
On 15/04/13 12:50, Anne van Kesteren wrote:
So I guess the current solution is fine as longs as either
* No JS libraries will want to implement APIs that uses locks, or
* Such libraries are ok with not using the built-in Future API and
instead re-implementing the Future API themselves.
The
Hi,
Anant stepped down as an editor of Web Application Manifest Format and
Management APIs specification [1] but Mozilla is still interested in
this specification so I will replace Anant as an editor.
However, given the feedback we got on this specification [2], we are
merging it with the
Hi,
I've just pushed a new editor draft [1] with some cosmetic/editorial
changes and a new feature: lockOrientation() can now be called with a
sequenceDOMString to lock the screen to different orientations (for
example, portrait-primary and landscape-primary).
Any feedback is welcome!
Note that
On 10/30/2012 10:22 AM, Charles McCathieNevile wrote:
Hi,
I mentioned this and it's somethign we are working on.
Basic idea: site provides list of resources that it uses and can be
cached for general improvements on the whole site. (We're seeing
load-time improvement from 50% - 300% in
Hi,
With some people at Mozilla, we've been working on an API similar to Web
Intents in some points but distant enough to be a counter-proposal. We
believe that the API is now in a good enough shape to be officially sent
in those mailing lists and discussed.
You can have an overview of the API
On 05/31/2012 03:28 PM, Tobie Langel wrote:
I'm probably missing something here, but notifications don't seem to be
going through a system- / browser-wide notification panel from which the
user can decide whether or not to navigate to an application. In other
words, it looks like we're
On 05/29/2012 06:13 PM, SULLIVAN, BRYAN L wrote:
* I wonder if it is really useful to have clients requesting a specific
Push service. I totally understand why a user would request to use his
preferred Push service but that is part of the UA. I would tend to think
we should not add that
On 05/26/2012 05:06 AM, SULLIVAN, BRYAN L wrote:
* As far as I understand it, |requestRemotePermission| and
|checkRemotePermission| could be one single method which could be named
something like |getPushServiceUrl|. The only difference between those
two methods is the permission asking part
On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote:
Thanks to the inestimable help of the W3C staff I am now plugged into the
mercurial mainline and have uploaded the first stab at the Push API
http://dvcs.w3.org/hg/push/raw-file/default/index.html
I incorporated Mozilla's client API ideas in
On 4/27/12 3:07 PM, Arthur Barstow wrote:
Hi All,
Yesterday the Director announced WebApps' new charter [Charter] was
approved so thanks to all that helped with the chartering effort.
I added all of the new specs to our [PubStatus] page and made a couple
of tweaks to the group's [WorkMode]
On 02/15/2012 10:09 AM, Vincent Scheib wrote:
Mounir, I ran into the same confusion regarding how does the API expose
locking?. May I suggest that you explicitly state in the abstract that
the API is pending?
I just updated the draft so the locking part is now part of it.
Cheers,
--
Mounir
On 02/15/2012 04:29 AM, Tobie Langel wrote:
In the Screen Orientation API draft, I don't see any references to
locking. Is this by design?
It's in the abstract:
The Screen Orientation API's goal is to provide an interface for web
applications to be able to read the screen orientation
On 01/30/2012 12:43 PM, Kenneth Rohde Christiansen wrote:
Hi there,
Orientation lock is already part of the CSS Device Adaption spec as part
of the viewport meta tag, though this is only going to be optional and
should be ignored for normal web browsing due to the effect on usability
(think
On 01/30/2012 03:57 PM, Kenneth Rohde Christiansen wrote:
Also, I do not think the specifications should restrain the conditions
in which the screen orientation lock can happen. At least not at the
It doesn't have to do that, but it could point out that UAs might want
to restrict
On 01/30/2012 02:26 PM, Charles McCathieNevile wrote:
OK, since I was planning to have the charter up today, let's have a
quick call for consensus on this. Please reply by end of business
Wednesday if you support or object to this - silence will be taken as
not explicitly supporting it, and
82 matches
Mail list logo
