Re: [whatwg] Canonical Image and Color
On Tue, Aug 26, 2014 at 10:36 AM, Domenic Denicola wrote: > +Marcos because he is really good at that kind of investigative work, and > might have some idea what FFOS is doing for numeric badges. We don't do anything yet. But we'd like to. I definitely feel like having a badge is a separate API from notifications. For example a badge could show how many unread emails are in the inbox of a webmail client, but you woudn't want to create a notification for every one of them. / Jonas / Jonas
Re: [whatwg] Need clarification on menu builder algorithm for contextmenu attribute
On Tue, 26 Aug 2014, Sanjoy Pal wrote: > > I feel the following statement for the third bullet of step 2, > > "if the child is a menu element with no label attribute, Append a > separator to the menu, then run the menu builder steps using this child > menu element for the same menu, then append another separator to the > menu." > > is contradicting the statement of step 3 > > "Remove any submenu with no label, or whose label is the empty string, > in the menu or any submenus." > > My understanding from the first statement is that the any child menu > (submenu) with no label attribute should be flattened. But the > subsequent statement implies removal of whole submenu. It's important not to confuse a child element with an actual submenu in the constructed menu. (This is similar to the difference between a "section" and a .) There are two concepts here. Elements, including and , are your regular DOM element node. Pop-up menus, on the other hand, are lists of zero or more menu items, and menu items are commands, separators, and recursively other pop-up menus. When you have a child element with no label attribute, no submenu is created. The child menu items are inserted directly into the parent menu. So when it comes to the second statement quoted above, there's no submenu to remove. The second statement above could get triggered for something like (an empty label). I've tweaked the wording a bit to try to make this clearer. In particular I've made the terminology less ambiguous. HTH, -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canonical Image and Color
From: whatwg on behalf of Mike > I really believe that the notification api is a related topic but can exist > as a separate api used in page icon. I think it’s a good idea not to bind > them together. I think there are potentially three distinct APIs: 1. Icons 2. Notifications 3. Numeric badge 1 is clearly solved by already. Proposing new solutions is pointless since by the time browsers implement those they might as well implement/fix their handling. 2 already exists The question I see you raising is whether 3 should be tied to 2 or separate. I believe in most native platforms they are tied together, but I agree that they could be separate. More investigative work would be needed to really explore the problem space. +Marcos because he is really good at that kind of investigative work, and might have some idea what FFOS is doing for numeric badges.
Re: [whatwg] Canonical Image and Color
Mathias, Anne I really believe that the notification api is a related topic but can exist as a separate api used in page icon. I think it’s a good idea not to bind them together. Mike Tomshinsky tomshin...@yandex-team.ru On 26 авг. 2014 г., at 10:50, Anne van Kesteren wrote: > 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 haven't really put > much thought into how exactly we should go about it though, API-wise. > > > -- > http://annevankesteren.nl/
Re: [whatwg] Canonical Image and Color
Tab, You’re right if we take as given that: 1. FF and Chrome will finally fix the bug with handling different size attributes (hopefully they will) 2.standard aspect ratio will be 1:1 (although maybe it can be different) 3.the layout of hi-res favicon will differ from a standard (16x16/32x32) favicon. Compare those: https://dl.dropboxusercontent.com/u/1830800/temp/icons.jpg Generally seems like it could work. But on other hand the battle for high-res icons has been won by Apple’s Touch Icons. Almost sure that more websites have a touch icon than an icon with a size attribute exceeding 128px. Around 20% has an apple icon from top-1. What do you think could be the fallback scenario (in case there is no proper icon)? Generated by browser? In a case someone wanna see grabbed touch icons for top-1000 website: https://yadi.sk/d/CZgnIW6UZxpTg When I see it my sense of beauty says no to any API;) Mike Tomshinsky tomshin...@yandex-team.ru On 26 авг. 2014 г., at 10:42, Tab Atkins Jr. wrote: > On Tue, Aug 26, 2014 at 4:21 PM, Anne van Kesteren wrote: >> 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 >>>- Firefox OS icon (detached case) >>>- SpeedDial API by Opera (as an extension) >> >> There's also , which is the way to do this. > > Particularly when used with the sizes='' attribute, which lets you > provide small favicons *and* large icons suitable for use in tiles > like this. > > ~TJ
Re: [whatwg] Preloading and deferred loading of scripts and other resources
[[stuck in the mod queue.. attempt #5, apologies for dupes if you get them]] Ian, thanks for writing this up. The first thing that strikes me about this entire topic is its scope, and I'm wondering if we should take a step back and (a) extract some lower level primitives, (b) leave the rest to libraries and web developers to experiment with, and (c) if (b) leads to some good patterns, then codify them at a later date... Instead of trying to tackle all of this at once. In particular, it seems like we might be coupling two topics: (1) a flexible declarative mechanism to fetch arbitrary resources (2) some set of mechanisms to express dependencies, execution order, etc. If we do our job right with (1), I think (2) can (should?) be deferred to developers and library writers. Specifically, for (1): - We need a way to initiate arbitrary downloads that doc + preload parsers will understand and can process - We need a way to communicate type, prioritization, MQ, and other custom fetch information for each download - We need a way to listen on download progress of these resources to build custom processing logic - By default there is no UA processing on the response, this mechanism simply fetches bytes This is the direction I was proposing earlier [1] with rel=preload -- see [2], for a concrete example. I really like your proposal for "as="... Concretely it could look something like this: The combination of all of the above allows me to fetch any content-type, specify custom priorities and headers (or use a default set via 'as'), apply MQ's, etc. Given all that, assuming I can extract a Promise/Fetch object (or some such) out of it, I can then track the download progress and apply any arbitrary logic for how and when it should be processed. For example: - I can execute a script immediately by waiting for the download to finish and inject the script tag referencing same URL - I can setup a callback that waits for any other arbitrary resource to finish before I execute it... - I can defer execution until a particular action occurs. - I can prefetch arbitrary resources for later use - ... (note: the script example is completely arbitrary.. the entire point is that this mechanism is independent of content-type) In other words, it seems like you could build most (all?) of the doc'ed use cases in client-land... I can implement needs, loadPolicty, addDependency on my own. Which, in my books, is a much better outcome anyway because it will allow more and much more rapid experimentation. --- [1] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-August/297383.html [2] https://docs.google.com/presentation/d/1Q-7keKXwP2UeZ2zTN9Ue2ASIdIZPqxnEvnDsPSLTwcQ/present#slide=id.g377330538_0345 [3] http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2014-August/297437.html [4] https://docs.google.com/presentation/d/1Q-7keKXwP2UeZ2zTN9Ue2ASIdIZPqxnEvnDsPSLTwcQ/present#slide=id.g120f70e9a_025
Re: [whatwg] Preloading and deferred loading of scripts and other resources
Ian Hickson writes:
> Here's how [the proposal] would handle the use cases listed above.
>
> > [Use-case G:] A website knows there's a piece of Javascript code
> > that the user might need if they click on a part of the page. The
> > developer would like to have the user download it, but not at the
> > expense of other resources.
>
>load-policy="when-needed precache low-priority">
> // button-reaction.js defines react()
>
>onclick="document.scripts.reaction.load().then(
> function() { react(); })"> Part of the Page
What does low-priority add in case G? How does that differ from case H,
where "when-needed precache" is sufficient to avoid delaying other
things from loading?
> > [Use-case H:] A website is prefetching photos in a photo album and
> > would like to make sure these images are lower priority than images
> > the user is actually viewing.
>
>
>
>
>
>
>
> As they come into view, they'll become needed automatically. When they
> are not needed, they get precached if that wouldn't get in the way of
> other things getting loaded.
Thanks.
Smylers
--
http://twitter.com/Smylers2
Re: [whatwg] Notification's click event should be cancelable
On 08/26/2014 12:53 PM, Jonas Sicking wrote: On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren wrote: 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 workers. I'm not convinced that even with SW, the proper design is to tell websites to always funnel click notifications through a SW. Alternatively we don't use events here at all. Instead we could use a .clicked property which returns a promise. This is a typical "one shot" notification where Promises are better suited than DOM Events. Unless you want the cancellability. However I don't actually think that firing events on multiple EventTargets is that complex. It can be complex if we have several processes firing those events. Some process might be really slow and the parent process would need to wait for all the child processes to reply before doing some default handling (like focus the initiator tab). -Olli / Jonas
Re: [whatwg] Notification's click event should be cancelable
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 with SW, the proper design is to tell > websites to always funnel click notifications through a SW. That's the standing proposal. Do you think we should fire them both in service workers and on Notification objects? > Alternatively we don't use events here at all. Instead we could use a > .clicked property which returns a promise. This is a typical "one > shot" notification where Promises are better suited than DOM Events. Seems somewhat sensible. Same for closed, error, etc? Not sure how we'd reconcile that with the existing design. > However I don't actually think that firing events on multiple > EventTargets is that complex. -- http://annevankesteren.nl/
Re: [whatwg] Notification's click event should be cancelable
On Tue, Aug 26, 2014 at 2:18 AM, Anne van Kesteren wrote: > 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 workers. I'm not convinced that even with SW, the proper design is to tell websites to always funnel click notifications through a SW. Alternatively we don't use events here at all. Instead we could use a .clicked property which returns a promise. This is a typical "one shot" notification where Promises are better suited than DOM Events. However I don't actually think that firing events on multiple EventTargets is that complex. / Jonas
Re: [whatwg] Notification's click event should be cancelable
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 workers. >> We could >> make a division between notification records and notification objects. >> And we could even go as far as only offer notification records for >> notifications associated with a service worker. > > I don't really understand this. The proposal for service workers is that all events go to the service worker and not to the notification. As such I thought we could maybe make a distinction between notifications associated with a service worker and without one. For those notifications asssociated with a service worker, all we need to expose from the notification is a record of its various properties, but that does not need to support event handling. For notifications without a service worker (the model we have cross-browser today) we could continue to support it as an event target, but perhaps not support the whole multiple Notification objects per notification model as at that point you should probably start using service workers anyway. -- http://annevankesteren.nl/
Re: [whatwg] Notification's click event should be cancelable
On Tue, Aug 26, 2014 at 12:15 AM, Anne van Kesteren wrote: > 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. I don't see a problem with firing events on all Notification instances, and only changing focus if none of the events were cancelled. After all, we do something very similar when firing events on a Node. Then too multiple EventTargets have their event handlers called, and only if none of the event handlers, on any of the EventTargets, cancel the event do we take the default action. Granted, in those cases we use the same Event instance, and it's part of a single event dispatch. But that difference is pretty small from the webpage point of view. The main difference is that .defaultPrevented reflect cancellation, but worst come to worst we could make that work here too. > We could > make a division between notification records and notification objects. > And we could even go as far as only offer notification records for > notifications associated with a service worker. I don't really understand this. / Jonas
Re: [whatwg] Notification's click event should be cancelable
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 division between notification records and notification objects. And we could even go as far as only offer notification records for notifications associated with a service worker. So you have notifications that work per today and are only exposed to Window. And then you have notifications associated with a service worker. For the latter the events will go towards the service worker and everyone (same-origin) can get a hold of a notification record for them using Notification.get(). From a service worker, new Notification() will do the right thing, from anywhere else you need to associate it with one explicitly. (It could be even better if we had mixins, then only notification objects not associated with a service worker would have the event stuff. There's no need for that for notifications associated with a service worker or notification records.) -- http://annevankesteren.nl/
