On Fri, Feb 27, 2015 at 4:15 PM, David Bruant wrote:
> To achieve this priorization, currently, authors would use a bit of JS to
> delay adding the iframe to the document. It seems like it solves all the
> issues listed in the original message (load UI, load event, "fast back").
Delay until what
On Fri, Feb 27, 2015 at 3:59 PM, David Bruant wrote:
> The request is to being able to
> provide different priority orders to different iframes (some containing "not
> important" content like ads, others containing important content) while what
> I'm suggesting treats all iframes the same way.
Ye
I got feedback that isolating ads from your page through is
desirable, but that the impact on browser load UI, the load event, and
"fast back", are very much not desirable.
It seems there should be some way to indicate that the should
function, but is not a critical part of the page. Perhaps thi
On Tue, Feb 24, 2015 at 6:32 PM, Brendan Long wrote:
> The ability to control HTTP/2 stream priorities
The tentative plan is to expose these on a promise subclass fetch()
will return at some point in the future, once we figure out what the
API should look like. (That's also where we plan to put f
On Tue, Feb 24, 2015 at 9:20 AM, Ryosuke Niwa wrote:
> However, there is nothing that forces child elements not to "dirty" their
> parents' size again once scripts are involved.
One idea that has been floating around is that if you opt into
isolation (whereby children cannot affect you), you can
On Tue, Feb 24, 2015 at 2:40 AM, Dean Jackson wrote:
> The idea was to allow the resize event on elements. I don't really care what
> the solution is, so maybe someone here can come up with a better idea (size
> observers?). And of course there are a lot of details to be worked out.
It seems th
On Wed, Jan 14, 2015 at 2:58 PM, Janusz Majnert wrote:
> From quickly skimming the linked spec it looks like the same functionality
> (minus sending objects) is already available with the use of WebStorage:
> https://html.spec.whatwg.org/multipage/webstorage.html#the-storage-event
That only handl
Andrea just landed the last patch for the BroadcastChannel API:
https://bugzilla.mozilla.org/show_bug.cgi?id=966439
https://html.spec.whatwg.org/multipage/comms.html#broadcasting-to-other-browsing-contexts
Assuming everything sticks it'll start appearing in Firefox Nightly
soon. We thought w
On Mon, Jan 12, 2015 at 1:15 PM, Glen Huang wrote:
> So yeah, replaceWith looks pretty good.
Thanks:
https://github.com/whatwg/dom/commit/b7563aaf0864c8d104d18c36a9eda036c5205131
--
https://annevankesteren.nl/
On Mon, Jan 12, 2015 at 12:03 PM, Glen Huang wrote:
> Or, the current algorithm of replace could be reversed, which should
> eliminate such confusion.
I think as James said that would leave the confusion. And given the
precedent in libraries, replaceWith() seems good.
--
https://annevankester
On Sat, Jan 10, 2015 at 2:14 PM, James M. Greene
wrote:
> jQuery is famous (and sometimes infamous, depending on who you talk to) for
> its API brevity and yet we still chose longer names for these scenarios:
> `replaceWith` and `replaceAll` (even including "All" in the latter to
> clarify that it
On Sat, Jan 10, 2015 at 8:26 AM, Glen Huang wrote:
> Do you think it would be worthwhile to change to a name that states the
> intention a bit clearer?
The general preference is brevity over precision. And since methods
operate on the object they are invoked upon I think the name is clear
enough
On Mon, Jan 5, 2015 at 11:17 PM, Nicholas C. Zakas
wrote:
> So my question is: is the spec incorrect in that it should reflect reality?
> Or are browsers incorrect and we should be hounding them to fix this
> behavior?
It depends on compatibility. It seems the Chrome team planned on
measuring tha
On Tue, Dec 9, 2014 at 6:29 AM, Yusuke wrote:
> if form has value of type="file", I expect multipart.
> and also if form have value of type="text" only, I expect urlencoded.
That is not how works. defaults to urlencoded and you
can opt into multipart through an attribute. FormData is just a
rep
On Sat, Dec 6, 2014 at 9:33 PM, block.rxckin.be...@gmail.com
wrote:
> but I wanna send string key/values in x-www-form-urlencoded format.
Use URLSearchParams instead. FormData and ...-urlencoded are a bad
match due to Blob.
> because it's more standard way for web.
The wire formats are equally
On Tue, Dec 2, 2014 at 6:04 PM, Boris Zbarsky wrote:
> Actually, sandboxing iframes of your own site is one of the main sandbox use
> cases: it allows limited user upload of content without creating security
> holes, in theory.
No it is not, only if you use it in combination with srcdoc you are
s
On Fri, Nov 28, 2014 at 2:42 PM, Sam Ruby wrote:
> First, what does "static" mean in this context?
Defined by IDL.
> Are these methods implemented by any current browser?
Don't think so, they're relatively new. (And perhaps should be
replaced with something like new URLHost(); I haven't really
On Mon, Nov 17, 2014 at 1:34 AM, Biju wrote:
> If an iframe have "controls" attribute it should be behave/displayed
> like a MDI child window.
Why would we replace one form of bad UI with an equivalent other?
can be used.
--
https://annevankesteren.nl/
On Fri, Nov 7, 2014 at 7:38 PM, Roger Hågensen wrote:
> A worthy goal would be to help developers de-clutter websites from all those
> share icons we see today, so if this could be steered towards that it would
> be great.
That is what the proposal is doing. The share button would be part of
the
On Fri, Nov 7, 2014 at 6:35 PM, L. David Baron wrote:
> I also think it should be (B), since the meaning of the coordinates
> in the imagemap shouldn't change as a result of CSS styling of the
> image.
Note that as Daniel pointed out it for legacy reasons already does.
and CSS height/width are t
On Tue, Nov 4, 2014 at 4:50 PM, David Singer wrote:
> really? Safari, Chrome and Opera all return what to me is eminently sensible
>
> stuff://www.app.com/a/b/banana
It does seem like they allow for some different behavior here, indeed!
We still need to special case schemes as e.g. "x" against
On Tue, Nov 4, 2014 at 4:24 PM, David Singer wrote:
> at the moment I am more interested in understanding what the best behavior
> might be than majority voting
I don't think there is disagreement about what better behavior might
be in this case, if we skip over the details for the moment. Howev
On Tue, Nov 4, 2014 at 3:55 PM, David Singer wrote:
> I am pretty puzzled why the base URL composed with
> the URL results not in
>
> stuff://www.app.com/a/b/banana
>
> but
>
> stuff:///banana
>
> Is this a bug or feature of the spec., or a bug in this implementation?
Either of those results w
On Tue, Nov 4, 2014 at 3:34 PM, cowwoc wrote:
> I'm relatively new to this mailing list. How do proposals make their way to
> action items here?
I recommend studying https://wiki.whatwg.org/wiki/FAQ
In this particular case Ian will get back to you.
--
https://annevankesteren.nl/
On Tue, Nov 4, 2014 at 3:28 PM, Sam Ruby wrote:
> To help foster discussion, I've made an alternate version of the live URL
> parser page, one that enables setting of the base URL:
>
> http://intertwingly.net/projects/pegurl/liveview2.html#foobar://test/x
>
> Of course, if there are any bugs in th
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.
What we've been looking at instead is solving a smaller use
On Mon, Nov 3, 2014 at 4:19 PM, David Singer wrote:
> The readability is much better (I am not a fan of the current trend of
> writing specifications in pseudo-basic, which makes life easier for
> implementers and terrible for anyone else, including authors), and I also
> think that an approach
On Sat, Nov 1, 2014 at 1:29 PM, Sam Ruby wrote:
> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04
I don't know how it should change. I just said that it doesn't say
that you cannot invent new hierarchical URIs (to use IETF terms). As
long as the IETF keeps building on top of RFC
On Sat, Nov 1, 2014 at 12:38 PM, Sam Ruby wrote:
> On 11/1/14 5:29 AM, Anne van Kesteren wrote:
>> It doesn't say that. (We should perhaps try to find some way to make
>> "{scheme}://" syntax work for schemes that are not problematic (e.g.
>> javascri
On Sat, Nov 1, 2014 at 1:01 AM, Sam Ruby wrote:
> Meanwhile, The IETF is actively working on a update:
>
> https://tools.ietf.org/html/draft-ietf-appsawg-uri-scheme-reg-04
>
> They are meeting F2F in a little over a week. URIs in general, and this
> proposal in specific will be discussed, and for
On Thu, Oct 30, 2014 at 12:06 PM, Sam Ruby wrote:
> Here is a screen capture of the live DOM URL viewer:
>
> http://i.imgur.com/kbsTDQ7.png
>
> Here are the test results for Chrome on Windows:
>
> http://intertwingly.net/tmp/81cd494abd36509f0d46010b0c4d4ff9
>
> It appears that Chrome implements th
On Wed, Oct 29, 2014 at 11:24 PM, Sam Ruby wrote:
> http://intertwingly.net/projects/pegurl/urltest-results/d674c14cbe
>
> I'll note that galimatias doesn't produce a parse error in this case (and,
> in fact, the state machine specified by the current URL Standard goes down a
> completely differen
On Wed, Oct 29, 2014 at 1:26 PM, Sam Ruby wrote:
> Here is another example (though it contains multiple parse errors):
>
> http://intertwingly.net/projects/pegurl/urltest-results/f3382f1412
>
> The error being reported is that the host contains consecutive dot
> characters (i.e., the 'label' betwe
On Wed, Oct 29, 2014 at 12:12 PM, Sam Ruby wrote:
> 1) Is the following expected to produce a parse error:
>
> http://intertwingly.net/projects/pegurl/urltest-results/4b60e32190 ?
>
> My reading of https://url.spec.whatwg.org/#relative-path-state is that step
> 3.1 indicates a parse error even tho
On Tue, Oct 28, 2014 at 2:29 PM, Daniel Trebbien wrote:
> The issue that I am referring to is the behavior of
> Range.createContextualFragment() when the context node is not an SVG
> element, but some other SVG element such as an SVG or element.
If you change the range's start node to e.g. the
On Tue, Oct 28, 2014 at 1:35 PM, Daniel Trebbien wrote:
> Issues related to Range.createContextualFragment() in SVG contexts are
> starting to come up in bug reports:
> - https://bugzilla.mozilla.org/show_bug.cgi?id=1087715
> - https://code.google.com/p/chromium/issues/detail?id=426400
>
> Should
On Mon, Oct 20, 2014 at 7:42 PM, Ashley Gullen wrote:
> I'd like to suggest a use case whereby it would be useful if a blob import
> can load relative URLs as if they are relative to the importing HTML
> document.
You could include a .
A note on discussion forums: although there's a plan of sor
Thanks Glenn.
On Sun, Oct 19, 2014 at 7:35 PM, Glenn Maynard wrote:
> - People asking "why would this page need encryption?", which is always the
> wrong question. (The right question is "why does this page need to not have
> encryption?")
> - People don't want to jump the hoops to get a certifi
On Sat, Oct 18, 2014 at 7:14 PM, Roger Hågensen wrote:
> This precludes that a site has a certificate, and depite someone like
> StartSSL giving them out free, sites and forums still do not use HTTPS.
We recently started doing this for whatwg.org. It was not a big deal
(though quite a bit of work
On Thu, Oct 16, 2014 at 2:22 PM, Ben Maurer wrote:
> It reduces the number of systems which are exposed
> to the password.
You mean after the password arrives at the server? Because for
transfer we should advocate TLS.
--
https://annevankesteren.nl/
On Tue, Oct 14, 2014 at 6:08 PM, David Graham
wrote:
> Interesting—thanks for the clarification. I've updated the example from this
>
> fetch('/users.html').then(function(response) {
> document.body.innerHTML = response.body
> })
>
> to this
>
> fetch('/users.html')
> .then
On Thu, Oct 9, 2014 at 9:12 PM, Chad Austin wrote:
> Before designing a browser API, a few questions must be answered:
>
> 1) Should the priority API support legacy HTTP and SPDY?
> 2) Should the priority API support future protocols beyond HTTP 2?
> 3) How likely is it future protocols will suppo
On Tue, Oct 14, 2014 at 11:38 AM, Sam Ruby wrote:
> I'll look further into why the results provided by Opera and
> https://rubygems.org/gems/addressable don't appear to match RFC 3491.
Note that Opera Presto attempted implementing some form of IDNA2008
which is not backwards compatible. If you're
On Tue, Oct 14, 2014 at 12:21 PM, Sam Ruby wrote:
> Here's my original statement:
>
> "The expected results are an object that returns the original href, but
> empty values for all other properties. I don't see this behavior in the
> spec: https://url.spec.whatwg.org/#url-parsing";
Yes and as I
On Tue, Oct 14, 2014 at 1:15 AM, David Graham
wrote:
> We’re developing a polyfill for the new Fetch API at GitHub:
>
>https://github.com/github/fetch
>
> The spec was fairly easy to follow, but I’d love any feedback on places the
> implementation could be improved. Fetch is probably the most
On Tue, Oct 14, 2014 at 11:38 AM, Sam Ruby wrote:
> At the present time, all I can say is that the https://url.spec.whatwg.org/,
> https://github.com/w3c/web-platform-tests/blob/master/url/, and
> https://github.com/annevk/url are inconsistent.
I recommend not looking at annevk/url.
> To illust
On Tue, Oct 14, 2014 at 10:37 AM, Sam Ruby wrote:
> Given all of the above, would you suggest changing the spec or the expected
> test results?
You said "The expected results are an object that returns the original
href, but empty values for all other properties. I don't see this
behavior in the
On Tue, Oct 14, 2014 at 1:05 AM, Sam Ruby wrote:
> 1) rows where the notes merely say "href" are cases where parse errors are
> thrown and failure is returned. The expected results are an object that
> returns the original href, but empty values for all other properties. I
> don't see this behav
On Tue, Oct 14, 2014 at 1:02 AM, Jonas Sicking wrote:
> We'd definitely need to treat the header as a content-set header from
> a CORS perspective. Otherwise we'd have problems not just with pages
> behind firewalls, but also websites that use cookies for
> authentication. I.e. most websites.
I t
On Sun, Oct 12, 2014 at 3:01 PM, Sam Ruby wrote:
> Can you explain in JavaScript terms what the difference is between return
> failure and terminate?
If you simply terminate new URL("http://test:test/";) would no longer
throw. (The reason is that the parse algorithm is overloaded. One
version par
Per XMLHttpRequest User-Agent has been off limits for script. Should
we keep it that way for fetch()? Would it be harmful to allow it to be
omitted?
https://github.com/slightlyoff/ServiceWorker/issues/399
A possible attack I can think of would be an firewall situation that
uses the User-Agent hea
On Sat, Oct 11, 2014 at 7:24 PM, Sam Ruby wrote:
> On 10/10/2014 08:19 PM, Sam Ruby wrote:
>> 2) https://url.spec.whatwg.org/#concept-basic-url-parser
>> I'm interpreting "terminate this algorithm" and "return failure" to
>> mean the same thing, and I'm interpreting "parse error" as "set
>
On Wed, Oct 8, 2014 at 7:31 PM, Jonas Sicking wrote:
> Interesting. Though if we don't need an event for .close() being
> called, I suspect we won't need one for a notification being replace.
> It seems somewhat rare that either of these things would provide
> significant use to the app if the not
On Wed, Oct 8, 2014 at 7:03 PM, Tab Atkins Jr. wrote:
> You keep ignoring the past "turns out we like using async errors for
> 'soft failures' of this kind, and have done it lots of times, and
> nobody seems to complain" argument.
A user saying no to notifications is not an error. You ask the use
On Wed, Oct 8, 2014 at 6:07 PM, Domenic Denicola
wrote:
> What I find interesting here is the claim that people find try/catch annoying
> or distasteful.
I don't think you should need try/catch for a common failure case.
That is all. So yes, agreed with Tobie et al.
--
https://annevankesteren
On Tue, Oct 7, 2014 at 7:33 PM, Jonas Sicking wrote:
> I don't know of a use-case for that. And given that I think we should
> define that non-persistent notifications go away after a timeout, I
> think this is the common scenario.
>
> The reason I think we should use timeouts is that this matches
On Mon, Oct 6, 2014 at 9:06 PM, Jonas Sicking wrote:
> I think we should define that non-persistent notifications disappear
> after a timeout. And define that on mobile platforms with
> "notification centers", that these notifications are *not* added
> there, but rather is just displayed on screen
On Wed, Oct 8, 2014 at 9:51 AM, Tab Atkins Jr. wrote:
> The question is whether it's not natural to assume that *if the promise
> fulfills*, that means they got permission. This allows them to do things
> like using Promise.all() to join multiple permission requests together and
> get a nice combi
On Tue, Oct 7, 2014 at 8:33 PM, Tab Atkins Jr. wrote:
> On Sun, Oct 5, 2014 at 7:41 AM, Anne van Kesteren wrote:
>> On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
>> wrote:
>>> So we should make a choice, as to whether we want developers to assume they
>>&g
On Tue, Oct 7, 2014 at 4:13 PM, Mathias Bynens wrote:
> There’s also ``:
> https://wiki.whatwg.org/wiki/Meta_referrer
Obsoleted by my second link. Will update the wiki.
--
https://annevankesteren.nl/
On Mon, Oct 6, 2014 at 9:11 PM, Jonas Sicking wrote:
> Though based on Andrew's latest comments, I don't know that anyone
> strongly feels that we need to keep the event?
If you create a non-persistent notification, would you not want to
know when the user agent closed it (only relevant if the us
On Tue, Oct 7, 2014 at 1:58 PM, Peter Lepeska wrote:
> Some web site developers use redirects to strip out referrer headers from
> requests issued from users clicking links on their site. This causes a
> blocking round trip and so has a really big impact on web performance.
>
> Can we give develop
On Mon, Oct 6, 2014 at 6:54 PM, Sam Ruby wrote:
> On 10/06/2014 12:42 PM, Anne van Kesteren wrote:
>> On Mon, Oct 6, 2014 at 3:13 AM, Sam Ruby wrote:
>>> http://intertwingly.net/stories/2014/10/05/urltest-results/24f081633d
>>
>> This does not match what I fin
On Mon, Oct 6, 2014 at 3:13 AM, Sam Ruby wrote:
> http://intertwingly.net/stories/2014/10/05/urltest-results/24f081633d
This does not match what I find in browsers. (I did not look through
the list exhaustively, see below, but since this was the first one...)
I also found out today that
https:/
On Wed, Oct 1, 2014 at 1:09 PM, Anne van Kesteren wrote:
> Per
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/0100.html
> and other emails in that thread it seems like the show event can be
> removed from notifications altogether. I will remove it.
Done.
On Sat, Oct 4, 2014 at 4:59 AM, Jonas Sicking wrote:
> While JS running in the page can't tell a difference, the
> user certainly can so it can still be perceived as a breaking change.
Yeah, we'll need to see if new Notification() can be changed enough or
whether we need three types of notificati
On Sat, Oct 4, 2014 at 4:42 AM, Jonas Sicking wrote:
> I agree. One of the big shortcomings of the current spec is that it
> leaves UI too undefined. This is particularly problematic given that
> notifications is all about using UI to get certain types of user
> attention.
I'm willing to try maki
On Thu, Oct 2, 2014 at 10:13 PM, Domenic Denicola
wrote:
> So we should make a choice, as to whether we want developers to assume they
> will always get permission (in which case it should reject upon permission
> not being granted), or whether we want developers to ask the API whether they
> w
On Thu, Oct 2, 2014 at 3:12 AM, Dan Poltawski wrote:
> The most basic case of autocompleting on the same site is the one
> which is most problematic for us.
>
> A traditional username/password to login to the site with autocomplete
> enabled and functioning as expected - but then after the user ha
On Wed, Oct 1, 2014 at 8:30 PM, David Dorwin wrote:
> I would specify that DOMException with the name "NotSupportedError" be
> thrown. User agent implementations could provide more information in the
> message. (There might be other "non-exceptional" failures that would use
> different exception n
On Wed, Oct 1, 2014 at 9:19 PM, Dan Poltawski wrote:
> To outline the situation in broad terms:
> * We have shared secrets on the page which we protect against shoulder
> surfing by using the password element with autocomplete="off"
> * The password managers are now all auto-filling these fields w
On Wed, Oct 1, 2014 at 3:21 PM, Tab Atkins Jr. wrote:
> And I wouldn't expect someone loading a FontFace synchronously to use
> try/catch to deal with loading errors, either, because that's super
> obnoxious. Failure, though, is a standard rejection reason - it maps
> to the use of "onerror" even
On Wed, Oct 1, 2014 at 3:14 PM, Tab Atkins Jr. wrote:
> Wait, what? Anytime you request something, not getting it is
> exceptional. Not sure how you can make an argument otherwise.
I would not expect a synchronous version of this method (were it to
exist) to have to use try/catch for anything o
On Wed, Oct 1, 2014 at 2:56 PM, Peter Beverloo wrote:
> One argument I came across for overloading requestPermission is the
> following:
> Promise.all([ Notification.requestPermission(),
> swRegistration.push.requestPermission() ]).then(...);
>
> Might be worth considering, it's relatively che
On Fri, Sep 26, 2014 at 4:36 PM, Peter Beverloo wrote:
> * Life-time of existing notifications.
>
> Chrome currently treats Web Notifications as "persistent" ones. When the
> page goes away, the notification stays. Interaction with the notification is
> not going to trigger anything anymore. While
On Thu, Sep 25, 2014 at 9:52 PM, Anne van Kesteren wrote:
> Is there any platform that requires the show event? Implementers from
> Gecko don't see a need for it. We could remove it without harm as far
> as I can tell.
Per http://lists.w3.org/Archives/Public/public-whatwg-archiv
On Fri, Sep 26, 2014 at 7:59 PM, Daniel Trebbien wrote:
> http://www.w3.org/TR/wai-aria/appendices#html_dtd
DTDs have nothing to do with what you're seeing here. They're best ignored.
> One issue is that the ARIA semantics for "implied rows" are not defined.
I'm not sure I understand why ARIA
On Fri, Sep 26, 2014 at 1:42 AM, Tab Atkins Jr. wrote:
> None of Twitter, Hangouts, or IRCCloud cares a whit if you close their
> notifications; they still record stuff as unread until you actually
> visit the app. I can't recall any other app I've ever used treating a
> notification closing as a
On Fri, Sep 26, 2014 at 3:31 PM, Jonas Sicking wrote:
> On Fri, Sep 26, 2014 at 6:23 AM, Anne van Kesteren wrote:
>> On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking wrote:
>>> promise = createPersistentNotification(...);
>>> promise.then(notificationWasSho
On Fri, Sep 26, 2014 at 12:48 AM, Jonas Sicking wrote:
> Or, should persistent notifications not use a constructor at all?
> What's the purpose of having a reference to a Notification object if
> no events will ever fire on it? Maybe we should have a function like
>
> promise = createPersistentNot
Is there any platform that requires the show event? Implementers from
Gecko don't see a need for it. We could remove it without harm as far
as I can tell.
--
https://annevankesteren.nl/
On Thu, Sep 25, 2014 at 12:25 PM, Jake Archibald wrote:
> Totally agree, I didn't realise this was possible in the original proposal.
> The option that makes it a persistent notification should retarget all
> events to the serviceworker. If the serviceworker is invalid, I guess we
> throw?
Yup.
On Thu, Sep 25, 2014 at 2:28 AM, Jonas Sicking wrote:
> On Wed, Sep 24, 2014 at 4:28 AM, Anne van Kesteren wrote:
>> Strawman: We classify existing notifications as non-persistent
>> notifications. Only notifications associated with a service worker are
>> persistent.
>
On Wed, Sep 24, 2014 at 2:21 AM, Jonas Sicking wrote:
> * We should consider the case of persistent notifications separate
> from notifications that automatically close when a page goes away.
Strawman: We classify existing notifications as non-persistent
notifications. Only notifications associat
Peter and Jake made a proposal for notifications and service workers,
but I believe Jonas wanted something without events. I'll outline the
proposal from Peter and Jake below. Hopefully we can then discuss on
how to move this forward.
We add "serviceWorker" to Notification and NotificationOptions.
On Sat, Sep 6, 2014 at 7:15 PM, Robert Bindar wrote:
> That's what I meant. I filed an issue on the github page for that
> https://github.com/whatwg/notifications/issues/24.
Thanks. As I mentioned earlier I'm not sure when exactly I'll get
around this. If something is urgent please let me know pr
On Sat, Aug 30, 2014 at 2:46 AM, bindar wrote:
> I have read the spec again and I could not see any information regarding the
> actions a replacing notification should trigger. Firefox OS for instance
> triggers these actions every time.
Do you mean the Notifications API? As with most standards
On Wed, Aug 27, 2014 at 9:42 PM, Marcos Caceres wrote:
> There are also some notifications that don't make sense as badges: for
> instance, iTunes shows me a notification every time a new track starts
> playing, but doesn't get added as a badge.
Hmm yeah. Should probably be a distinct API then.
On Tue, Aug 26, 2014 at 11:53 AM, Jonas Sicking wrote:
> On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren wrote:
>> It's a somewhat complex design compared to what we probably need long
>> term, if long term is service workers.
>
> I'm not convinced that even w
On Tue, Aug 26, 2014 at 11:06 AM, Jonas Sicking wrote:
> I don't see a problem with firing events on all Notification
> instances, and only changing focus if none of the events were
> cancelled.
It's a somewhat complex design compared to what we probably need long
term, if long term is service wo
On Mon, Aug 25, 2014 at 6:42 PM, Jonas Sicking wrote:
> I definitely think we need the ability for code running in Windows
> (i.e. code that handles UI) to be able to enumerate any notifications
> created by the website.
Fair, but maybe those "copy objects" should not get events. We could
make a
On Tue, Aug 26, 2014 at 8:46 AM, Mathias Bynens wrote:
> Sure, but what about the “notification counter” use case that Mike outlined?
We should investigate that as a feature of the notifications API I
think. Someone suggested that last week:
https://github.com/whatwg/notifications/issues/23 I hav
On Mon, Aug 25, 2014 at 8:59 PM, Mike wrote:
> 2) There is already a couple of standards or quasi-standads:
> - favicons (most promising seems to be the increasing of their size and
> svg support)
> - apple-touch-icon used by Apple and Android
> - msapplication-TileImage used by MS
>
On Sun, Aug 24, 2014 at 11:18 AM, Olli Pettay wrote:
> Given the very odd Notification API, where the same user input may end up
> being
> represented by several click events in the browser...
> (I think we need to change that somehow, if possible)
> ...cancelling any of the events should cancel t
On Fri, Aug 15, 2014 at 2:38 PM, Olli Pettay wrote:
> in order to prevent whatever default action Notification's click event has
> (for example focus the tab which initiated the Notification), the click
> event
> should be cancelable so that .preventDefault() can be called.
>
> Some background
> h
On Fri, Aug 22, 2014 at 7:15 PM, Brian Kardell wrote:
> I still think that calling it bodyStream actually helps understanding
> all you need and it's short/portable...
>
> response.bodyStream.asJSON()
>
> seems to at least give the hint that it is a stream that is consumed
> without getting too cr
On Fri, Aug 22, 2014 at 10:32 AM, Jake Archibald wrote:
> On 22 August 2014 07:20, Anne van Kesteren wrote:
>> That works for me too. I agree that developers will likely learn what
>> is going on here quickly enough. And that if anything should have long
>> names, it would
On Fri, Aug 22, 2014 at 12:27 AM, James Graham wrote:
> I think that adding an extra verb to the names to describe a consistent
> feature of the API is a mistake; it seems important when designing the
> API because it's a choice that you have to make, but for the user it's
> just part of how the A
On Thu, Aug 21, 2014 at 11:02 AM, Jake Archibald wrote:
> * The as* methods should be directly on the response, and named consumeAs*,
> so response.consumeAsJSON()
Would it be really bad to have these names four characters longer to
indicate they are about the body of the response? Then we'd have
On Wed, Aug 20, 2014 at 5:09 PM, Marcos Caceres wrote:
> And of course Object.observe would work really nicely, but I've been told a
> bunch of times by various people that we can't use Object.observe on DOM APIs
> (this *really* sucks).
Not by default, but we can make it work as I said. We wou
101 - 200 of 1841 matches
Mail list logo
