Re: Custom Elements: is=
I agree with Anne. A stopgap could hinder cross browser development significantly (with regards to backwards compatibility browser needs of clients). Does it gain enough for us to justify one? I am just joining the conversation now so please correct me if I missed something on 'is'. As far as naming goes, an 'extends' attribute with a prototype path seems to be the most intuitive for me. Using element names in the naming conventions to define inheritance is limiting. Eventually we would want to be able to support extending other custom elements (whether this happens in v1 or v2). Custom elements can have long names. For the most part I have seen elements with 2-3 hyphenated words but it is possible to have elements that are like 'crazy-long-awesome-button-thing' so extending this without an attribute reference might look like 'crazy-long-awesome-button-thing-my-fabulous-button' where 'my-fabulous-button' is the new element namespace. Although this is a problem with 'is' or 'extends' as well, it is more intuitive to have some attribute reference to denote a change rather than a a long concatenated element name. On a side note, developers suck at naming generally speaking. On Mon, Jun 15, 2015 at 5:07 AM, Léonie Watson lwat...@paciellogroup.com wrote: From: Bruce Lawson [mailto:bru...@opera.com] Sent: 15 June 2015 09:46 On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote: it makes more sense to work on stylability of standard elements. I'd like to keep the is= construct (or better name) in the knowledge that it's a stopgap for v1, and put our energies we're currently expending debating this into styling standard elements - which is currently being considered http://dev.w3.org/csswg/css-forms/ Will leaving is= (or whatever we call it) in situ create backward compatibility problems later on if/when it changes? That aside, concentrating efforts on styling native HTML elements makes a lot of sense. Léonie -- Léonie Watson - Senior accessibility engineer @LeonieWatson @PacielloGroup PacielloGroup.com -- *Erik Isaksen * *Google Developer Expert HTML5 https://developers.google.com/experts/people/erik-isaksen* *The Web Platform Podcast http://thewebplatform.libsyn.com/ Show Host* *ReadTheSource.io http://ReadTheSource.io Co-Host* *nevra...@gmail.com nevra...@gmail.com* *@eisaksen https://twitter.com/eisaksen * *The Web Platform Podcast Links* Twitter - https://twitter.com/thewebplatform Google Plus - https://plus.google.com/u/0/106965203807974584370 Stream/Web -http://thewebplatform.libsyn.com/ Facebook - https://www.facebook.com/thewebplatform iTunes - https://itunes.apple.com/us/podcast/the-web-platform-podcast/id899384794?mt=2 Stitcher - http://www.stitcher.com/podcast/the-web-platform-podcast YouTube (not all episodes available) - https://www.youtube.com/channel/UCjz3j22CyBpy6Qk5SL6UwcQ RSS - http://thewebplatform.libsyn.com/rss Github - https://github.com/thewebplatform *Read The Source: Open Source Companion Live Screencast* Twitter - http://hangouts.readthesource.io/ Google Plus - https://plus.google.com/105627089988168968277/ Youtube - https://www.youtube.com/channel/UCVqD-Rd1nMmvbvf-AvQvgZw Github - https://github.com/readthesource RSS - http://hangouts.readthesource.io/index.xml
Re: Custom Elements: is=
On Mon, Jun 15, 2015 at 10:45 AM, Bruce Lawson bru...@opera.com wrote: On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote: it makes more sense to work on stylability of standard elements. I'd like to keep the is= construct (or better name) in the knowledge that it's a stopgap for v1, and put our energies we're currently expending debating this into styling standard elements - which is currently being considered http://dev.w3.org/csswg/css-forms/ Why should we standardize a stopgap? -- https://annevankesteren.nl/
Re: Custom Elements: is=
On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote: it makes more sense to work on stylability of standard elements. I'd like to keep the is= construct (or better name) in the knowledge that it's a stopgap for v1, and put our energies we're currently expending debating this into styling standard elements - which is currently being considered http://dev.w3.org/csswg/css-forms/ b
RE: Custom Elements: is=
From: Bruce Lawson [mailto:bru...@opera.com] Sent: 15 June 2015 09:46 On 14 June 2015 at 01:41, Patrick H. Lauke re...@splintered.co.uk wrote: it makes more sense to work on stylability of standard elements. I'd like to keep the is= construct (or better name) in the knowledge that it's a stopgap for v1, and put our energies we're currently expending debating this into styling standard elements - which is currently being considered http://dev.w3.org/csswg/css-forms/ Will leaving is= (or whatever we call it) in situ create backward compatibility problems later on if/when it changes? That aside, concentrating efforts on styling native HTML elements makes a lot of sense. Léonie -- Léonie Watson - Senior accessibility engineer @LeonieWatson @PacielloGroup PacielloGroup.com
Re: [service_worker] Notification constructor
On Tue, Jun 16, 2015 at 12:28 AM, Conrad Irwin conrad.ir...@gmail.com wrote: I've been implementing some things with service workers, and it's a little bit frustrating to have to use self.registration.showNotification(hi!) instead of the more normal: new Notification(hi!) Is there a technical reason that service workers can't call the Notification constructor as usual? I recommend reading through this thread: https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Sep/thread.html#msg60 https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/thread.html#msg9 It would be nice for two reasons: 1. I could use the same wrapper library in-page and in-worker, If you already have a wrapper library, you could wrap both. 2. I'd be able to call .close() on the returned Notification. There is nothing that prevents that. Though currently you'd need to get hold of the Notification object through the getNotifications() method. Perhaps we should also resolve the promise returned by showNotification() with a Notification object. You might want to file an issue against the specification for that. -- https://annevankesteren.nl/
DOMError - DOMException
Per previous discussions [1][2] highlighted in spec issues, we'd like to remove DOMError from the platform in favor of using DOMException. Sanity check: web-compat allowing, should we just swap DOMException in any place DOMError is currently used? I've done this (among other unvetted things) in the Indexed DB v2 ED [3][4], which exposes `error` attributes, which would now be DOMExceptions. A Blink CL [5] passes our tests which only inspected name/message properties. No idea yet if this is web compatible, but it seems likely other than some test code. Any IDL concerns about DOMException attributes? Are there expectations that specs would have e.g. subclasses or typedefs of DOMException? I assume no and no, but maybe others had a different vision? [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=23367 [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=21740 [3] https://github.com/w3c/IndexedDB/issues/16 [4] https://github.com/w3c/IndexedDB/commit/42fb5845b9974b95bb0c2c446f893863ec83da2f [5] https://codereview.chromium.org/1182233003/
Re: PSA: Web Components vs Extract Widget patent
We have made a comparison between the Components model and the patent here: https://gist.github.com/Ayms/bf6a9f121e1ebd93cf22 From the end-2011 Components Model we have added some properties/thoughts/proposals from the patent and our past projects. Each time we read something about the components subject that's obviously related to the patent, and will end-up filling all of the claims of the patent, for example server side rendering (that we discovered while writing this gist reading the 'Custom Elements: is=' thread), which we called in the gist Virtualization and virtual rendering is part of the claims of the patent, that would be funny to hear that this was existing before. So it's useless to continue writing to describe the evidence, the gists will be surely more useful for further uses, because, unfortunately, it seems like we are not on the way to reach an agreement since six months today, we did not get any answer/feedback since the (unexpected and curious) public disclosure of this, so we will do what we have to do and probably go to litigation. -- Check the 10 M passwords list: http://peersm.com/findmyass Anti-spies and private torrents, dynamic blocklist: http://torrent-live.org Peersm : http://www.peersm.com torrent-live: https://github.com/Ayms/torrent-live node-Tor : https://www.github.com/Ayms/node-Tor GitHub : https://www.github.com/Ayms
[service_worker] Notification constructor
Hey All, Apologies if this isn't the right place to ask about the service worker spec. I've been implementing some things with service workers, and it's a little bit frustrating to have to use self.registration.showNotification(hi!) instead of the more normal: new Notification(hi!) Is there a technical reason that service workers can't call the Notification constructor as usual? It would be nice for two reasons: 1. I could use the same wrapper library in-page and in-worker, 2. I'd be able to call .close() on the returned Notification. Thanks, Conrad
Re: [Clipboard] Web API for clipboard changes.
Thank you for your interest Arthur. I have drafted up a more detailed implementation doc and shared it with you and Hallvord. Please feel free to take a look and comment. Kelvin On Thu, Jun 11, 2015 at 3:57 AM Arthur Barstow art.bars...@gmail.com wrote: On 6/2/15 4:05 PM, Kelvin Poon wrote: Hi public-webapps We are exploring a new web API for content to be notified of clipboard changes and would like to discuss it here. The problem For certain classes of web apps, it is necessary to determine when new clipboard contents have been set, e.g. in order to fetch and display them, to update context menus, or synchronize the content with another application or device. The problem is that the web standard currently provides no explicit notifications when new content is copied from another application to the clipboard. As a result, these web apps typically re-fetch the clipboard every time they regain focus, and only act on the contents if they have changed since last time (e.g. passing it to a remote system, updating context menu, etc). This polling mechanism is generally inefficient, especially when the clipboard contains a large image file. We currently have interest from Citrix and Chrome Remote Experience teams in improving Chrome's clipboard support. The proposal Google propose to update the W3C Clipboard API and events specification http://www.w3.org/TR/clipboard-apis/with an onClipboardChangedevent on the document object. The user agent should only signal the event if 1. a frame re-gains focus AND 2. the clipboard has changed since it last had focus. In addition, the user agent should not signal clipboard change events while a frame has focus. This will relieve the web app from the burden of filtering out notifications in response to clipboard changes generated by the app itself. We think this new API will avoid fetching large clipboard content repeatedly and unnecessarily for clipboard changes. Does the community think this API would be useful? Hallvord, All - do you have any feedback for Kevlin? We can go into more details and work on a detailed design together if the community is interested. Kelvin, if there is a resource that includes details, please let us know. (I suppose another option is a Pull Request but it might make sense to first wait for some feedback from the group.) -Thanks, ArtB
[Bug 17681] [IndexedDB] Operations that raise multiple exceptions types should define order
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17681 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |MOVED --- Comment #16 from Joshua Bell jsb...@google.com --- Tracked as https://github.com/w3c/IndexedDB/issues/11 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 20257] IDBCursor should walk on secondary ordering of index value
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20257 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |MOVED --- Comment #14 from Joshua Bell jsb...@google.com --- Now tracked as: https://github.com/w3c/IndexedDB/issues/14 One issue noted in that bug: What does this mean for nextunique and (more complicated) prevunique (but please put comments on that issue instead) -- You are receiving this mail because: You are on the CC list for the bug.
