[Bug 19955] [IndexedDB] Add IDBObjectStore.openKeyCursor
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19955 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Joshua Bell jsb...@google.com --- Specified in https://github.com/w3c/IndexedDB/commit/0f168cc96e38441b9131124786992589fbdb0388 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 11350] [IndexedDB] ObjectStores should have a way to hint that they're evictable
https://www.w3.org/Bugs/Public/show_bug.cgi?id=11350 Joshua Bell jsb...@google.com changed: What|Removed |Added CC||jsb...@google.com Resolution|LATER |WONTFIX --- Comment #3 from Joshua Bell jsb...@google.com --- LATER - WONTFIX In discussions with implementers, this seems to be the wrong direction. See https://wiki.whatwg.org/wiki/Storage for some more recent thoughts. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 23332] Support Binary Keys
https://www.w3.org/Bugs/Public/show_bug.cgi?id=23332 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||ann...@annevk.nl, ||bent.mozi...@gmail.com Resolution|LATER |--- --- Comment #11 from Joshua Bell jsb...@google.com --- cc: bent, annevk I was chatting with bent and annevk yesterday and they indicated a preference for the approach of BufferSource (input)/ArrayBuffer (output), and no preserving of view type when comparing or retrieving values. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 22370] Inform script of corruption-induced data loss
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22370 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jsb...@google.com Resolution|LATER |--- --- Comment #3 from Joshua Bell jsb...@google.com --- As dgrogan@ noted, we shipped IDBVersionChangeEvent#dataLoss and IDBVersionChangeEvent#dataLossMessage in Chrome, and it's seeing use. Since they're not widely publicized entry points we're open to alternate suggestions. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 19955] [IndexedDB] Add IDBObjectStore.openKeyCursor
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19955 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|LATER |--- -- You are receiving this mail because: You are on the CC list for the bug.
[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|RESOLVED|REOPENED Resolution|LATER |--- --- Comment #15 from Joshua Bell jsb...@google.com --- I do want to attempt to fix this for the V2 of the spec. I'll attempt to survey the existing implementations first, and basically spec the consensus where possible. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 16595] Ability to get non-sequential records from various operations
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16595 Joshua Bell jsb...@google.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||jsb...@google.com Resolution|LATER |--- --- Comment #2 from Joshua Bell jsb...@google.com --- We're thinking of tackling this with a combination of two new entry points: IDBObjectStore/IDBIndex#getAll(keys [, count]) - implemented in FF, WIP in Chrome IDBKeySet - a set (*gasp*!) of keys. getAll() and existing methods that take a key-or-range would be extended to take key-or-range-or-set. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28549] New: [Shadow]: Add [TreatNullAs=EmptyString] to ShadowRoot.innerHTML
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28549 Bug ID: 28549 Summary: [Shadow]: Add [TreatNullAs=EmptyString] to ShadowRoot.innerHTML Product: WebAppsWG Version: unspecified Hardware: PC URL: https://w3c.github.io/webcomponents/spec/shadow/#the-s hadowroot-interface OS: Linux Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 This is how it's implemented in Blink, and it's consistent with Element.innerHTML: https://dvcs.w3.org/hg/innerhtml/raw-file/tip/index.html#extensions-to-the-element-interface -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28552] New: [Shadow]: Shadow DOM v1
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28552 Bug ID: 28552 Summary: [Shadow]: Shadow DOM v1 Product: WebAppsWG Version: unspecified Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: dglaz...@chromium.org QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14978 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28246] [Shadow]: Disable event capturing through a ShadowRoot
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28246 Dimitri Glazkov dglaz...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED CC||dglaz...@chromium.org Resolution|--- |DUPLICATE --- Comment #4 from Dimitri Glazkov dglaz...@chromium.org --- *** This bug has been marked as a duplicate of bug 26892 *** -- You are receiving this mail because: You are on the CC list for the bug.
Re: [clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks
On Thu, Apr 23, 2015 at 1:16 AM Hallvord Reiar Michaelsen Steen
hst...@mozilla.com wrote:
We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and
running into some tricky questions I'd like to discuss here.
Basically, on Windows IE and other apps that write HTML to the clipboard
use the CF_HTML format. This format is simply described as
headers (name:value meta data)
htmlhead/head
body
!--StartFragment--HTML!--EndFragment--
/body
/html
where the StartFragment / EndFragment comment tags are inserted by
implementations writing HTML to the clipboard to show where the actually
selected content starts and ends. Several very common implementations
(including I believe Microsoft Word's) will add tags like STYLE outside of
the StartFragment/EndFragment tags and add rules that may be significant
for rendering the content of the fragment correctly. Also noteworthy is
that the meta data may include a SourceURL property showing the URL of the
page you copied from.
So, because of the significance of the STYLE information and other stuff
outside Start/EndFragment, certain browsers return the full document
including the Start/EndFragment comment tags when a script does
getData('text/html'). This is obviously very useful when there's important
stuff outside these tags. It still means scripts have to do extra work to
find those comments and extract the content inside them to know what data a
user actually intended to paste. This also adds a risk that scripts will be
tested only on Windows and authored to require those comments and fail if
they aren't there on other platforms.
Chrome's behavior is to return the literal HTML data, but without the
metadata header when a page calls getData('text/html'). However, if Chrome
is executing the default action of paste, we attempt to parse out the
fragment and only paste the fragment (however, we incorrectly don't include
styles).
Should we, then, standardise returning the full document including
Start/EndFragment comments (basically requiring or encouraging other
platform implementations to start using those comments when serializing
HTML for the OS clipboard) - or should getData() return only what's inside
the Start/EndFragment tags? Are any other important platforms already using
CF_HTML conventions, or would their developers balk at being encouraged to
do so?
CF_HTML is not a format that any other app on any other platform would be
expecting, so you wouldn't be able to just start writing it to the
clipboard on Mac/Linux in place of the original HTML. So there's a bit of a
chicken and egg problem here.
I also can't say I love the CF_HTML format: the markup is a lot easier to
work with when the styles are inlined, etc. Plus pasting style blocks
means there might be collisions in style rules, etc.
On a related topic, I see SourceURL as useful (could be used to properly
attribute citations automatically and such) - it would be nice to
standardise DataTransfer.sourceURL or something like that, to be set when
available.
-Hallvord
(editor of https://w3c.github.io/clipboard-apis/ )
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=586587
You'd have to get all UAs to agree on a data property to use to transfer
this since I don't think using CF_HTML on other platforms is currently
workable.
Directory Upload Proposal
Hello WebApps Group, For the past few years sites have been enabling directory uploads by using the old FileSystem API [1] in Chrome and Opera. In the April 2014 face to face WebApps group meeting [2], there was a CfC to move the old specs into a WG Note and to continue working on the new FileSystem API [3] instead, effectively discontinuing work on the old FileSystem API. The new FileSystem API tries to satisfy a large number of use cases with an approach that is better than the old API. However, its broad scope and its dependencies on future capabilities (e.g. Observables) has slowed down the pace at which it is moving forward. Due to this, there is currently no interoperable way to enable directory uploads on the web. We have received lots of feedback from developers - including some working on Microsoft services such as OneDrive - that supporting directory upload is a high priority for them. To enable developers to build future interoperable solutions, we've drafted a proposal [4], with the helpful feedback of Mozilla and Google, that focuses strictly on providing the mechanisms necessary to enable directory uploads. The proposal uses a subset of the new FileSystem API so that it can be expanded in the future to enable more scenarios when the new FileSystem API is further along. To help understand the proposal (especially the APIs involved) I have written a polyfill [5] and demo page [6] that is built on top of Chrome's old FileSystem API. If there is sufficient interest, I would like to work on this within the scope of the WebApps working group. Thank you, Ali [1] Old FileSystem API: http://www.w3.org/TR/file-system-api/ [2] WebApps April '14 Meeting: http://www.w3.org/2014/04/10-webapps-minutes.html#item02 [3] New FileSystem API: http://w3c.github.io/filesystem-api/ [4] Proposal: http://internetexplorer.github.io/directory-upload/proposal.html [5] Polyfill: https://github.com/InternetExplorer/directory-upload/blob/gh-pages/polyfill.js [6] Demo: http://internetexplorer.github.io/directory-upload/index.html
[Bug 24861] [Shadow]: Add a way to detect when the list of nodes distributed to an insertion point mutates
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24861 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED CC||ann...@annevk.nl Resolution|--- |DUPLICATE --- Comment #5 from Anne ann...@annevk.nl --- *** This bug has been marked as a duplicate of bug 21149 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28440] [Shadow]: Layout Containment and Shadow Trees
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28440 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #1 from Anne ann...@annevk.nl --- This can be done in CSS and doesn't impact us much. But it's very cool! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28491] [Shadow]: [Meta] Unblock Mozilla's shipping of Shadow DOM
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28491 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |MOVED --- Comment #1 from Anne ann...@annevk.nl --- These are now moved to v1 blockers. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 27325] [Shadow]: Figure out how session history should work for iframes in shadow DOM
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27325 Bug 27325 depends on bug 20144, which changed state. Bug 20144 Summary: [Shadow]: Add closed flag to createShadowRoot https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug 28552] [Shadow]: Shadow DOM v1
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28552 Bug 28552 depends on bug 20144, which changed state. Bug 20144 Summary: [Shadow]: Add closed flag to createShadowRoot https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
Re: Exposing structured clone as an API?
On 23 April 2015 at 15:02, Ted Mielczarek t...@mozilla.com wrote:
Has anyone ever proposed exposing the structured clone algorithm directly as
an API?
If you didn't just do so, I will :)
1. https://twitter.com/TedMielczarek/status/591315580277391360
Looking at your jsfiddle, here's a way to turn that into something useful.
+Object.prototype.clone = Object.prototype.clone || function() {
- function clone(x) {
return new Promise(function (resolve, reject) {
window.addEventListener('message', function(e) {
resolve(e.data);
});
+window.postMessage(this, *);
-window.postMessage(x, *);
});
}
But are we are in the wrong place to have that discussion?
Re: Exposing structured clone as an API?
On Apr 23, 2015, at 3:27 PM, Martin Thomson martin.thom...@gmail.com wrote:
On 23 April 2015 at 15:02, Ted Mielczarek t...@mozilla.com wrote:
Has anyone ever proposed exposing the structured clone algorithm directly as
an API?
If you didn't just do so, I will :)
1. https://twitter.com/TedMielczarek/status/591315580277391360
Looking at your jsfiddle, here's a way to turn that into something useful.
+Object.prototype.clone = Object.prototype.clone || function() {
- function clone(x) {
return new Promise(function (resolve, reject) {
window.addEventListener('message', function(e) {
resolve(e.data);
});
+window.postMessage(this, *);
-window.postMessage(x, *);
});
}
But are we are in the wrong place to have that discussion?
Code nitpick: it probably should remove the event listener from within the
handler, or calling this function repeatedly will leak memory. Also it will get
slower every time.
Actually, now that I think about it, this isn’t usable at all if you are using
postMessage for anything else, since you could accidentally capture
non-cloning-related messages.
I guess these are potentially arguments to expose cloning directly.
Regards,
Maciej
Re: [clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks
On Thu, Apr 23, 2015 at 4:13 AM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and running into some tricky questions I'd like to discuss here. Basically, on Windows IE and other apps that write HTML to the clipboard use the CF_HTML format. This format is simply described as There's some related discussion in bug 137450[1], I wrote a patch for that quite a few years ago (that never landed). In the comments someone pointed out that Microsoft has documented CF_HTML[2] since then, which is nice. -Ted 1. https://bugzilla.mozilla.org/show_bug.cgi?id=137450#c33 2. https://msdn.microsoft.com/en-us/library/aa767917%28v=vs.85%29.aspx
Exposing structured clone as an API?
Has anyone ever proposed exposing the structured clone algorithm directly as an API? Katelyn Gadd was musing about fast deep copy in JS on Twitter, and I proposed a hack to use postMessage to do so[1], which works but it's a little roundabout. Since structured clone is a primitive that the web platform is built on it seems like a primitive that ought to be exposed. I know this exists in other languages (Python has copy.deepcopy[2]) and there's an npm deepcopy module[3] with lots of downloads so this is clearly something people use. -Ted 1. https://twitter.com/TedMielczarek/status/591315580277391360 2. https://docs.python.org/2/library/copy.html#copy.deepcopy 3. https://www.npmjs.com/package/deepcopy
Re: Exposing structured clone as an API?
On 23 April 2015 at 15:34, Elliott Sprehn espr...@chromium.org wrote: Have you benchmarked this? I think you're better off just writing your own clone library. Not really the point of my mail. Of course you would be better writing a real clone. It could probably even be synchronous, though it removes this (or a less bad version, see Maceij's comments) as a polyfill option.
[Bug 28353] [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. ol/li
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353 Anne ann...@annevk.nl changed: What|Removed |Added Status|NEW |RESOLVED CC||ann...@annevk.nl Resolution|--- |WORKSFORME --- Comment #1 from Anne ann...@annevk.nl --- This falls out of defining CSS in terms of the composed tree. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Exposing structured clone as an API?
The way many browsers implement this isn't going to be particularly fast.
It serializes the objects to a byte sequence so it can be transferred to
another thread or process and then inflates the objects on the other side.
Have you benchmarked this? I think you're better off just writing your own
clone library.
On Apr 23, 2015 12:30 PM, Martin Thomson martin.thom...@gmail.com wrote:
On 23 April 2015 at 15:02, Ted Mielczarek t...@mozilla.com wrote:
Has anyone ever proposed exposing the structured clone algorithm
directly as an API?
If you didn't just do so, I will :)
1. https://twitter.com/TedMielczarek/status/591315580277391360
Looking at your jsfiddle, here's a way to turn that into something useful.
+Object.prototype.clone = Object.prototype.clone || function() {
- function clone(x) {
return new Promise(function (resolve, reject) {
window.addEventListener('message', function(e) {
resolve(e.data);
});
+window.postMessage(this, *);
-window.postMessage(x, *);
});
}
But are we are in the wrong place to have that discussion?
[components] Isolated Imports and Foreign Custom Elements
Hi everyone, I wrote up a proposal (with input and advice from Ryosuke Niwa) on a possible way to extend Web Components to support fully isolated components: https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal https://github.com/w3c/webcomponents/wiki/Isolated-Imports-Proposal I welcome comments on whether this approach makes sense. I’d also like to discuss this during the proposals section of tomorrow’s F2F. I know it’s supposed to be focused on Shadow DOM, but I think this proposal is relevant context. I think this proposal, even if it is itself a post-v1 project, helps explain why closed mode is important and relevant. While closed mode doesn’t provide strong security isolation by default, its a building block that can be used to build full isolation, whereas open mode can’t be used that way. If we agree to have a closed mode eventually, then it’s probably sensible to add it for v1. We’d also want to decide sooner rather than later whether closed or open is the default (or whether there is no default and we require authors to choose one explicitly). Regards, Maciej
[Bug 28539] [Shadow]: Typos Spefifies and Speficies
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28539 Dimitri Glazkov dglaz...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED CC||dglaz...@chromium.org Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
Re: Exposing structured clone as an API?
On Thu, Apr 23, 2015 at 6:06 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 4/23/15 6:34 PM, Elliott Sprehn wrote: Have you benchmarked this? I think you're better off just writing your own clone library. That requires having a list of all objects browsers consider clonable and having ways of cloning them all, right? Maintaining such a library is likely to be a somewhat demanding undertaking as new clonable objects are added... -Boris Today it's not demanding, it's not even possible. e.g. how do you duplicate a FileList object? - Kyle
Re: Exposing structured clone as an API?
On 4/23/15 9:31 PM, Kyle Huey wrote: Today it's not demanding, it's not even possible. e.g. how do you duplicate a FileList object? Ah, there we go. I figured there was something that would fail the ways of cloning them all test in the platform today... ;) We should make it possible to manually clone FileList of course, but the larger point is that this is likely to continue being a problem. -Boris
[Bug 28353] [Shadow]: Use a parent/child relationship in the composed tree for some elements, i.e. ol/li
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28353 Koji Ishii kojii...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED CC||kojii...@gmail.com Resolution|WORKSFORME |--- --- Comment #2 from Koji Ishii kojii...@gmail.com --- Can tpu clarify what you meant? I just didn't understand. Should the example be valud, pr not? I prefer not, but it was controversial. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Directory Upload Proposal
On Thu, Apr 23, 2015 at 12:28 PM, Ali Alabbas a...@microsoft.com wrote: If there is sufficient interest, I would like to work on this within the scope of the WebApps working group. It seems somewhat better to just file a bug against the HTML Standard since this also affects the processing model of e.g. input.files. Which I think was the original proposal for how to address this... Just expose all the files in input.files and expose the relative paths, but I guess that might be a bit too synchronous... (Also, you want to use sequence not [] for listContents().) -- https://annevankesteren.nl/
Re: Exposing structured clone as an API?
On 4/23/15 6:34 PM, Elliott Sprehn wrote: Have you benchmarked this? I think you're better off just writing your own clone library. That requires having a list of all objects browsers consider clonable and having ways of cloning them all, right? Maintaining such a library is likely to be a somewhat demanding undertaking as new clonable objects are added... -Boris
Re: [components] Apple's consolidated feedback on Web Components
On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak m...@apple.com wrote: Hi everyone, In preparation for Fridays’ face-to-face, a number of us at Apple (including me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor I forgot to mention that Gavin Barraclough also contributed to this discussion. We also incorporated past feedback from others on the team. - Maciej
[components] Apple's consolidated feedback on Web Components
Hi everyone, In preparation for Fridays’ face-to-face, a number of us at Apple (including me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor) got together to collect our thoughts and feedback about the current state of Web Components. Before going into the changes we propose, we want to reiterate that we think the concept of Web Components is great, and we even like many of the specifics. We’re considering significant implementation effort, but we have some concerns. We think there is a set of targeted changes that would help web developers, and allow us to address a broader set of use cases. With that in mind, here are our key points of feedback, by spec. I. Shadow DOM A. Closed vs. Open. 1. Add a closed/open flag to createShadowRoot(). The Shadow DOM spec now has the notion of an encapsulation flag for closed mode. Yay! Unfortunately, there’s no way yet for a Web developer to pass this flag in. Open vs. closed has been much discussed, and while the default is contentious, we felt there was a rough consensus to at least expose both modes. We think this is critical for v1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 2. The behavior of closed mode should be actually defined. We hope this does not need much justification. We think this is critical for v1. https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144 3. We think closed mode should be the default. Alternately, we would be ok with a mandatory argument so developers must always explicitly choose open or closed. This has been much discussed, so we won’t give further rationale here, and can wait for the meeting Friday to debate. https://www.w3.org/Bugs/Public/show_bug.cgi?id=28445 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28445 B. Multiple Generations of Shadow DOM 1. We think this should be removed. Discussion can wait for debate of contentious bits, https://www.w3.org/Bugs/Public/show_bug.cgi? https://www.w3.org/Bugs/Public/show_bug.cgi?id=28446 2. We think that the Apple / Component Kitchen named slot proposal does a better job of addressing the main use cases for this. We think it is a superior replacement. https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0184.html https://lists.w3.org/Archives/Public/public-webapps/2015AprJun/0184.html https://www.w3.org/Bugs/Public/show_bug.cgi?id=28542 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28542 C. Imperative Distribution API 1. We think the imperative distribution API is still worth doing. There has been positive feedback from web developers on the concept and there isn’t an obvious reason against it. https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429 https://www.w3.org/Bugs/Public/show_bug.cgi?id=18429 D. Event Retargeting 1. We agree with making it optional (opt-in or opt-out). We don’t feel that strongly, but many web developers have asked for this. The default should likely match the default for open vs. closed (no retargeting by default if open by default). https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28444 E. Renaming 1. If any strongly incompatible changes are made, we suggest renaming createShadowRoot. This is to avoid compat problems with content written for Chrome’s shipping implementation. II. Custom Elements A. Insertion/Removal Callbacks 1. We think the current attached/detached callbacks should be removed. They don’t match core DOM concepts and insert/remove is a more natural bracket. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314 2. We think inserted/removed callbacks should be added, for alignment with DOM. https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866 https://www.w3.org/Bugs/Public/show_bug.cgi?id=24866 B. ES6 classes 1. Custom elements should support ES6 classes in a natural way - allowing use of the ES6 class constructor instead of a separate callback. We believe there is rough consensus on this point. https://www.w3.org/Bugs/Public/show_bug.cgi?id=28541 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28541 C. Upgrade 1. We don’t think upgrading should be supported. The tradeoffs of different options have been much-discussed. https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544 https://www.w3.org/Bugs/Public/show_bug.cgi?id=28544 2. We support synchronous constructors, or
=[xhr]
This is causing grepolis to lag significantly. Please fix it Charles T Perry
[clipboard] Dilemma: getData('text/html') and useful CF_HTML quirks
We're exploring text/html paste behaviours in Mozilla bug 586587 [1] and
running into some tricky questions I'd like to discuss here.
Basically, on Windows IE and other apps that write HTML to the clipboard
use the CF_HTML format. This format is simply described as
headers (name:value meta data)
htmlhead/head
body
!--StartFragment--HTML!--EndFragment--
/body
/html
where the StartFragment / EndFragment comment tags are inserted by
implementations writing HTML to the clipboard to show where the actually
selected content starts and ends. Several very common implementations
(including I believe Microsoft Word's) will add tags like STYLE outside of
the StartFragment/EndFragment tags and add rules that may be significant
for rendering the content of the fragment correctly. Also noteworthy is
that the meta data may include a SourceURL property showing the URL of the
page you copied from.
So, because of the significance of the STYLE information and other stuff
outside Start/EndFragment, certain browsers return the full document
including the Start/EndFragment comment tags when a script does
getData('text/html'). This is obviously very useful when there's important
stuff outside these tags. It still means scripts have to do extra work to
find those comments and extract the content inside them to know what data a
user actually intended to paste. This also adds a risk that scripts will be
tested only on Windows and authored to require those comments and fail if
they aren't there on other platforms.
Should we, then, standardise returning the full document including
Start/EndFragment comments (basically requiring or encouraging other
platform implementations to start using those comments when serializing
HTML for the OS clipboard) - or should getData() return only what's inside
the Start/EndFragment tags? Are any other important platforms already using
CF_HTML conventions, or would their developers balk at being encouraged to
do so?
On a related topic, I see SourceURL as useful (could be used to properly
attribute citations automatically and such) - it would be nice to
standardise DataTransfer.sourceURL or something like that, to be set when
available.
-Hallvord
(editor of https://w3c.github.io/clipboard-apis/ )
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=586587
Re: Exposing structured clone as an API?
On Thu, Apr 23, 2015 at 3:02 PM, Ted Mielczarek t...@mozilla.com wrote: Has anyone ever proposed exposing the structured clone algorithm directly as an API? There has been some talk about moving structured cloning into ECMAScript proper and exposing the primitives. But TC39 does not seem particularly receptive unless it comes with a way for someone to participate in the structured cloning algorithm with custom objects. But yeah, I think this should definitely be an API of sorts eventually. -- https://annevankesteren.nl/
Re: [components] Apple's consolidated feedback on Web Components
Thank you for writing this up, Maciej. Looking forward to the F2F. :DG On Wed, Apr 22, 2015 at 11:19 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 22, 2015, at 11:10 PM, Maciej Stachowiak m...@apple.com wrote: Hi everyone, In preparation for Fridays’ face-to-face, a number of us at Apple (including me, Ryosuke Niwa, Sam Weinig, and Ted O’Connor I forgot to mention that Gavin Barraclough also contributed to this discussion. We also incorporated past feedback from others on the team. - Maciej
