[charter] What is the plan for Streams API?
On 7/30/15 8:46 AM, Arthur Barstow wrote: http://w3c.github.io/charter-html/group-charter.html The WebApps + HTML WG draft charter says the following about WebApps' Streams API: [[ Streams API https://w3c.github.io/streams-api/ An API for representing a stream of data in web applications. ]] I believe the previously agreed plan of record for this spec was to create an API on top of https://streams.spec.whatwg.org/. Is that still something this group wants to do, and if so, who can commit to actually doing the work, in particular: editing, implementation, and test suite? If we no longer have committed resources for doing the above tasks then this spec should be removed from the draft charter. -Thanks, AB
CSS cascading order and Shadow DOM
Hi, I proposed some changes to the cascade order in the CSS Scoping spec on www-style[1] a while back. I've had positive feedback from Google, but I thought I'd notify WebApps, as some Web Components people might not be on www-style. I've sent a github pull request for adding the proposal[2] to w3c/webcomponents. [1] https://lists.w3.org/Archives/Public/www-style/2015Jun/0303.html [2] https://github.com/rune-opera/webcomponents/blob/rune/shadow-cascade-order-20150804/proposals/Shadow-DOM-Cascade-Order.md -- Rune Lillesveen
Re: Is polyfilling future web APIs a good idea?
On Tue, Aug 4, 2015 at 8:22 PM, Glen Huang curvedm...@gmail.com wrote: There's actually a lot of questions in here, so let me take them one at a time... On second thought, what's the difference between prollyfills and libraries A major difference is that it's hard to translate libraries into standards regardless of the approach they use. We just don't do it. We have libraries like jQuery that are as successful as we can ever reasonably expect anything to get - it's inarguable that jQuery is used more than any single browser, for example - and yet we didn't just standardize jQuery. What's more, we wouldn't for lots of technical and political reasons. jQuery wasn't made with becoming a standard in mind and it didn't propose things in same standards sense before hand or early -- a lot of the approach/style matter too (see below). Aspects of it could have been - jQuery has individuals representing in standards committees (me, for example) and prollyfills give us a way to do this - ecma, for example, produces a lot of prollyfills as they go and actually get use and feedback before it's way too late. exposed web APIs in a functional style (e.g., node1._replaceWith(node2) vs replaceWith(node2, node1)? Or in a wrapper style like jquery does? Prefixing APIs doesn't seem to be that different from using custom APIs? It could be, but the further you get from the actual way it will be used, the more we will debate on what will happen if you change its surface. A prollyfill is as close as we can approximate to the real proposal without shooting ourselves in the foot. It lets developers and standards people work together, answer questions about uptake and confusion, identify use cases and edgecases, etc. You might say the prefixing approach resembles native APIs more closely, but when changing your code to use native APIs, modifying one character or several doesn't really make much difference (they are the same if you find replace), as long as you have to modify the code. Definitely not as simple if you change the whole pattern - asking someone to grep an entire codebase is a bigger ask than a nice simple pattern that lets you just say something like: // Hey, our prollyfill matches native, now it's a polyfill! HTMLElement.prototype.foo = HTMLElement.prototype._foo; -- Brian Kardell :: @briankardell :: hitchjs.com
[clipboard] document.execCommand and clipboard actions
Hi,
so I hit a bit of an issue: I've written some parts of the clipboard spec
with the assumption that it will be invoked from a
document.execCommand('copy'/'cut'/'paste') call (although 'paste' would
require some extra permission work which no UA but IE has attempted so far).
Meanwhile, the editing task force has gathered feedback on developing
editor features from implementors and drawn the conclusion that the current
stuff including contentEditable=true and document.execCommand() is
unsalvageable. So their aim is to deprecate and remove execCommand(). If it
were to be removed, I obviously can't expect it to be used for clipboard
actions. On the other hand, my expectation that I can build stuff on top of
execCommand() makes life more complicated for them when they aim to
deprecate it.. Some discussion ensues:
https://github.com/w3c/editing/issues/61
https://lists.w3.org/Archives/Public/public-editing-tf/2015Aug/0001.html
I'm not sure how to proceed. Now, the old stuff isn't good enough, let's
have a clean slate and do new and shiny things is an approach that hasn't
worked very well so far when writing specs for the web. This time might of
course be different. (Personally I doubt it though. I'm not even sure if
they developers who told them the old stuff is something we don't want to
touch, let's forget about contentEditable=true had given this enough
thought..)
It's also true that the current approach in the clipboard spec - especially
for writing stuff to the clipboard - is a bit hackish. Perhaps I (unlike
the Editing task force) have been *too* deferential to the existing
implementations, including stuff like onbefore* events that no browser so
far did a good job implementing. (Nope, not even IE although it was
invented there). I can see why Johannes Wilm suggests making a new API
instead..
If we came up with a completely new write to clipboard API - for example
something like
if(window.clipboard){
var items = new DataTransferItems(); // ignore that we can't currently
construct this..
items.add('text/plain', 'Hello world');
items.add('text/html', 'pHello world/p');
items.imageFromElement('image/jpeg', document.images[0]);
window.clipboard.write(items).then(function(){
alert('Copied all parts to clipboard!');
});
}
Would implementors want to support that?
- Hallvord
Re: Is polyfilling future web APIs a good idea?
On second thought, what's the difference between prollyfills and libraries exposed web APIs in a functional style (e.g., node1._replaceWith(node2) vs replaceWith(node2, node1)? Or in a wrapper style like jquery does? Prefixing APIs doesn't seem to be that different from using custom APIs? You might say the prefixing approach resembles native APIs more closely, but when changing your code to use native APIs, modifying one character or several doesn't really make much difference (they are the same if you find replace), as long as you have to modify the code.
Re: CSS cascading order and Shadow DOM
Thanks. I merged the pull request, https://github.com/w3c/webcomponents/pull/292. Now the proposal is at https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Shadow-DOM-Cascade-Order.md On Tue, Aug 4, 2015 at 11:41 PM Rune Lillesveen r...@opera.com wrote: Hi, I proposed some changes to the cascade order in the CSS Scoping spec on www-style[1] a while back. I've had positive feedback from Google, but I thought I'd notify WebApps, as some Web Components people might not be on www-style. I've sent a github pull request for adding the proposal[2] to w3c/webcomponents. [1] https://lists.w3.org/Archives/Public/www-style/2015Jun/0303.html [2] https://github.com/rune-opera/webcomponents/blob/rune/shadow-cascade-order-20150804/proposals/Shadow-DOM-Cascade-Order.md -- Rune Lillesveen
Re: PSA: publish WD of WebIDL Level 1
On Thu, Jul 30, 2015 at 7:29 AM, Arthur Barstow art.bars...@gmail.com wrote: Hi All, This is heads-up re the intent to publish a Working Draft of WebIDL Level 1 (on or around August 4) using Yves' document as the basis and a new shortname of WebIDL-1: https://ylafon.github.io/webidl/publications/fpwd-20150730.html There is an open question about what should happen with TR/WebIDL/ (which now is the 2012 Candidate Recommendation). One option is to serve it as WebIDL-1. Another option is to replace it with the latest version of Cameron's Editor's Draft. A third option is to make it some type of landing page the user can use to load the various versions. Feedback on these options is welcome and the default (if there are no non-resolvable issues) is to go with option #2 (Yves' preference). The CSSWG always points the non-leveled url to the latest spec. (#2, if I'm counting your options correctly) ~TJ
