Re: [clipboard] Add RTF to the mandatory data types list?
Hallvord -- That behavior is really all I wanted, i.e. don't let the browser discard/ignore valid RTF clipboard data. I would also echo Paul's thoughts: this sounds good but is there any OS/browser-level sanitization process necessary? I would be curious to hear from Ben if Microsoft already has such things in place for IE. Sincerely, James Greene On Mon, Apr 20, 2015 at 3:26 PM, Paul Libbrecht p...@hoplahup.net wrote: On 20/04/15 22:11, Hallvord Reiar Michaelsen Steen wrote: Would it be a possible compromise to let a script describe data as RTF, and then put said data on the clipboard with the OS's correct RTF data type labelling? And vice versa, if the script asks for RTF give it any RTF contents from the clipboard as raw (binary) data? Products and environments that desperately need clipboard RTF support could then implement their own parsers and converters in JS and write/read RTF - the rest of us avoid some browser bloat.. Is this level of support reasonable? Is there any security consideration that we should be aware of here? (e.g. embedded content) If not, then I think there's no issue accepting this way. If yes, then I guess there should be some sanitization process happening since otherwise untrusted web-pages could insert in the clipboard RTF-content that would reference external stuff that would be fetched when pasted in. paul
Web Storage Rec errata?
Hi, Is there a plan to publish an errata to sync the Web Storage Rec [1] with the latest? I counted 8 commits cherry picked into the Editor's Draft since Rec [2]. If no errata publication is planned, I'd expect the Rec to clearly indicate its status. Thanks, -Anssi [1] http://www.w3.org/TR/webstorage/ [2] http://dev.w3.org/cvsweb/html5/webstorage/Overview.html
[Bug 28522] New: [Shadow] Cascading for trees of no-inner/outer and no-younger/older relationship
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28522 Bug ID: 28522 Summary: [Shadow] Cascading for trees of no-inner/outer and no-younger/older relationship Product: WebAppsWG Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: kojii...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org This issue should land on CSS Scoping spec, but I think it's better to discuss here and have some level of common understanding before we go www-style, because complex tree of trees is too much for most members at www-style. If this doesn't look right, please close and I'll go www-style. The Shadow Cascading of CSS Scoping spec[1] defines: * Outer wins if inner/outer * Younger wins if younger/older But Takashi and I are finding a few cases where trees have more complex relationships. We should define how cascading occurs in such cases, which wins, or prohibit. Case 1: Re-distributions By using multiple and nesting together, re-distribution can cause such relationship. Example: http://jsbin.com/wabigi div div SR-OLDER div content SR-NEST-OF-OLDER style ::content * {color:red} content SR-YOUNGER style ::content * {color:green} shadow Case 2: :host and shadow-piercing descendant combinator The combination of :host and shadow-piercing descendant combinator can select descendants of younger/older trees. [1] http://dev.w3.org/csswg/css-scoping/#cascading -- You are receiving this mail because: You are on the CC list for the bug.
Re: [clipboard] Feature detect Clipboard API support?
(Aside: I was testing the queryCommandEnabled()/onbefore* idea with this script: https://gist.github.com/hallvors/59a90f2e3816cb57f044 ) On Tue, Apr 21, 2015 at 7:29 AM, James M. Greene james.m.gre...@gmail.com wrote: Patrick Kettner offered up another idea for this as well on a related Modernizr issue [1]: Given the following 1. we must not change the user's clipboard 2. we must use a synthetic event 3. synthetic event be able to actually work (clipboard poisoning, etc) is there any chance that a synthetic clipboard copy/paste could throw a unique err[or] that we could try/catch around and sniff for? If we did that, authors could not use synthetic clipboard events for anything - right? I'm assuming that authors are going to find use cases for it - for example a cloud clipboard implementation may want to fire actual paste events so that data from the cloud is processed like data from the local clipboard. -Hallvord
Re: [admin] Registration for April 24 2015 Web Components f2f meeting; deadline April 10
On 2/24/15 3:37 PM, Arthur Barstow wrote: The registration page for the April 24 Web Components f2f meeting at Google's Mount View CA office is now open: https://www.w3.org/2002/09/wbs/42538/webcomponents-042015/ The meeting/agenda page is: https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting. The meeting page now includes Building and Room data as well as directions: https://www.w3.org/wiki/Webapps/WebComponentsApril2015Meeting#Meeting_Logistics Thanks Chris!
Proposal for changes to manage Shadow DOM content distribution
Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting where we came up with changes to the way shadow DOM distributes nodes to better fit real world use cases. After studying various real world use of web component APIs as well as exiting GUI frameworks, we noticed that selector based node distribution as currently spec'ed doesn't address common use cases and the extra flexibility CSS selectors offers isn't needed in practice. Instead, we propose named insertion slots that could be filled with the contents in the original DOM as well as contents in subclasses. Because the proposal uses the same slot filling mechanism for content distributions and inheritance transclusions, it eliminates the need for multiple shadow roots. Please take a look at our proposal at 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 [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
Re: JSON imports?
I just checked the html living standard, all it says about prefetch is The prefetch keyword indicates that preemptively fetching and caching the specified resource is likely to be beneficial This is pretty vague, and I sense the caching mechanism used by one vendor is not guaranteed to be the same for another. script type=application/json src=foo.json/script This is very easy to understand how it works, and much succinct comparing to prefetch and then refetch the same url (all you want is to load the json file asap, but you need to spread the logic in two places). Why not support it directly? The only downside I can see is that it should probably honor CORS headers, thus making it work a bit differently than a vanilla script, but that's something should be easy to grasp too. On Apr 19, 2015, at 5:15 PM, Elliott Sprehn espr...@chromium.org wrote: I'd hope with prefetch that we'd keep the data around in the memory cache waiting for the request. On Apr 18, 2015 7:07 AM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: Didn't know about this trick. Thanks. But I guess you have to make sure the file being prefetched must have a long cache time set in the http header? Otherwise when it's fetched, the file is going to be downloaded again? What if you don't have control over the json file's http header? On Apr 18, 2015, at 10:12 AM, Elliott Sprehn espr...@chromium.org mailto:espr...@chromium.org wrote: link rel=prefetch does that for you. On Apr 17, 2015 7:08 PM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: One benefit is that browsers can start downloading it asap, instead of waiting util the fetch code is executed (which could itself be in a separate file). On Apr 18, 2015, at 8:41 AM, Elliott Sprehn espr...@chromium.org mailto:espr...@chromium.org wrote: On Fri, Apr 17, 2015 at 6:33 AM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: Basic feature like this shouldn't rely on a custom solution. However, it does mean that if browsers implement this, it's easily polyfillable. What does this get you over fetch() ? Imports run scripts and enforce ordering an deduplication. Importing JSON doesn't really make much sense. On Apr 17, 2015, at 9:23 PM, Wilson Page wilsonp...@me.com mailto:wilsonp...@me.com wrote: Sounds like something you could write yourself with a custom-elements. Yay extensible web :) On Fri, Apr 17, 2015 at 1:32 PM, Matthew Robb matthewwr...@gmail.com mailto:matthewwr...@gmail.com wrote: I like the idea of this. It reminds me of polymer's core-ajax component. On Apr 16, 2015 11:39 PM, Glen Huang curvedm...@gmail.com mailto:curvedm...@gmail.com wrote: Inspired by HTML imports, can we add JSON imports too? ```html script type=application/json src=foo.json id=foo/script script type=application/json id=bar { foo: bar } /script ``` ```js document.getElementById(foo).json // or whatever document.getElementById(bar).json ```
Re: Proposal for changes to manage Shadow DOM content distribution
On Tue, Apr 21, 2015 at 9:43 PM, Daniel Freedman dfre...@google.com wrote: Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick date-range-combo-box example that would take two date inputs (start date and end date) and distribute them through the example date-combo-box, but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the date-combo-box content elements, but date-combo-box only takes inputs with slot inputElement. How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 Maybe there could be something like a simple routing scheme for these cases? https://gist.github.com/dglazkov/7d6acd4c205a58054a7c :DG
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting where we came up with changes to the way shadow DOM distributes nodes to better fit real world use cases. After studying various real world use of web component APIs as well as exiting GUI frameworks, we noticed that selector based node distribution as currently spec'ed doesn't address common use cases and the extra flexibility CSS selectors offers isn't needed in practice. Instead, we propose named insertion slots that could be filled with the contents in the original DOM as well as contents in subclasses. Because the proposal uses the same slot filling mechanism for content distributions and inheritance transclusions, it eliminates the need for multiple shadow roots. Please take a look at our proposal at https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html I just wanted to note that a month or two I tried to assume nothing and come up with a bare essentials concept which involved named slots. Is there a proposed a way to project from an attribute value into content or from attribute to attribute..? In other words, if I had x-foo blah=hello . Can I map blah into a slot or identify an attribute value in my template *as* a slot?
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 21, 2015, at 10:17 PM, Brian Kardell bkard...@gmail.com wrote: On Apr 21, 2015 8:22 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting where we came up with changes to the way shadow DOM distributes nodes to better fit real world use cases. After studying various real world use of web component APIs as well as exiting GUI frameworks, we noticed that selector based node distribution as currently spec'ed doesn't address common use cases and the extra flexibility CSS selectors offers isn't needed in practice. Instead, we propose named insertion slots that could be filled with the contents in the original DOM as well as contents in subclasses. Because the proposal uses the same slot filling mechanism for content distributions and inheritance transclusions, it eliminates the need for multiple shadow roots. Please take a look at our proposal at 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 [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html I just wanted to note that a month or two I tried to assume nothing and come up with a bare essentials concept which involved named slots. Is there a proposed a way to project from an attribute value into content or from attribute to attribute..? In other words, if I had x-foo blah=hello . Can I map blah into a slot or identify an attribute value in my template *as* a slot? Not at the moment but I could imagine that such a feature could be easily added. e.g. x-foo blah=hello !-- implementation -- template element=x-foo content attrslot=blah /template - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 21, 2015, at 9:43 PM, Daniel Freedman dfre...@google.com wrote: Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick date-range-combo-box example that would take two date inputs (start date and end date) and distribute them through the example date-combo-box, but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the date-combo-box content elements, but date-combo-box only takes inputs with slot inputElement. How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 https://gist.github.com/azakus/676590eb4d5b07b94428 !-- instance -- date-range-combo-box input type=date content-slot=start!-- (1) -- input type=date content-slot=end!-- (2) -- /date-range-combo-box !— implementation of date-range-combo-box -- template shadow date-combo-box!-- (3) -- !-- How can input[content-slot=start] end up in the content slot=inputElement in the date-combo-box ? -- content slot=start/content /date-combo-box date-combo-box!-- (4) -- content slot=end/content /date-combo-box /shadow /template Am I right in assuming that you want to re-distribute (1) into (3)'s and (2) into (4)'s inputElements? If so, I'd imagine one possible syntax is as follows: template shadow date-combo-box!-- (3) -- content slot=start content-slot=inputElement/content /date-combo-box date-combo-box!-- (4) -- content slot=end content-slot=inputElement/content /date-combo-box /shadow /template Here, the content elements are both creating slots and fulfilling slots. - R. Niwa On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com mailto:rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting where we came up with changes to the way shadow DOM distributes nodes to better fit real world use cases. After studying various real world use of web component APIs as well as exiting GUI frameworks, we noticed that selector based node distribution as currently spec'ed doesn't address common use cases and the extra flexibility CSS selectors offers isn't needed in practice. Instead, we propose named insertion slots that could be filled with the contents in the original DOM as well as contents in subclasses. Because the proposal uses the same slot filling mechanism for content distributions and inheritance transclusions, it eliminates the need for multiple shadow roots. Please take a look at our proposal at 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 [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
Re: Proposal for changes to manage Shadow DOM content distribution
On Apr 21, 2015, at 10:23 PM, Justin Fagnani justinfagn...@google.com wrote: I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? At the conceptual level, they're equivalent. However, we didn't find the extra flexibility of using CSS selectors compelling as we mentioned in our proposal [1]. [1] See points 3 and 4 in https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution#some-issues-with-the-current-shadow-dom-spec - R. Niwa
Re: Proposal for changes to manage Shadow DOM content distribution
Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick date-range-combo-box example that would take two date inputs (start date and end date) and distribute them through the example date-combo-box, but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the date-combo-box content elements, but date-combo-box only takes inputs with slot inputElement. How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 Thanks! On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting where we came up with changes to the way shadow DOM distributes nodes to better fit real world use cases. After studying various real world use of web component APIs as well as exiting GUI frameworks, we noticed that selector based node distribution as currently spec'ed doesn't address common use cases and the extra flexibility CSS selectors offers isn't needed in practice. Instead, we propose named insertion slots that could be filled with the contents in the original DOM as well as contents in subclasses. Because the proposal uses the same slot filling mechanism for content distributions and inheritance transclusions, it eliminates the need for multiple shadow roots. Please take a look at our proposal at https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
Re: Proposal for changes to manage Shadow DOM content distribution
I do want the ability to redirect distributed nodes into a holes in the base template, so that part is welcome to me. However, my first reaction to the slot idea is that forcing users to add the content-slot attribute on children significantly impairs the DOM API surface area of custom elements. For the single-level distribution case, how is this different from content select=[content-slot=name] except that content select can distribute based on features of the children that might already exist, like tag names or an attribute? Cheers, Justin On Tue, Apr 21, 2015 at 9:57 PM, Ryosuke Niwa rn...@apple.com wrote: On Apr 21, 2015, at 9:43 PM, Daniel Freedman dfre...@google.com wrote: Hi Ryosuke, I want to start by thanking you, Ted, and Jan for taking the time to make this proposal. I read through the proposal, and had a quick question about how redistribution should work with this slot concept. I created a quick date-range-combo-box example that would take two date inputs (start date and end date) and distribute them through the example date-combo-box, but I found myself stuck. I can't name the two date inputs with the same slot or they will end up in only one of the date-combo-box content elements, but date-combo-box only takes inputs with slot inputElement. How should this work? I drafted a quick gist to illustrate this: https://gist.github.com/azakus/676590eb4d5b07b94428 !-- instance -- date-range-combo-box input type=date content-slot=start!-- (1) -- input type=date content-slot=end!-- (2) -- /date-range-combo-box !— implementation of date-range-combo-box -- template shadow date-combo-box!-- (3) -- !-- How can input[content-slot=start] end up in the content slot=inputElement in the date-combo-box ? -- content slot=start/content /date-combo-box date-combo-box!-- (4) -- content slot=end/content /date-combo-box /shadow /template Am I right in assuming that you want to re-distribute (1) into (3)'s and (2) into (4)'s inputElements? If so, I'd imagine one possible syntax is as follows: template shadow date-combo-box!-- (3) -- content slot=start content-slot=inputElement/content /date-combo-box date-combo-box!-- (4) -- content slot=end content-slot=inputElement/content /date-combo-box /shadow /template Here, the content elements are both creating slots and fulfilling slots. - R. Niwa On Tue, Apr 21, 2015 at 8:19 PM, Ryosuke Niwa rn...@apple.com wrote: Hi all, Following WebApps discussion last year [1] and earlier this year [2] about template transclusions and inheritance in shadow DOM, Jan Miksovsky at Component Kitchen, Ted O'Connor and I (Ryosuke Niwa) at Apple had a meeting where we came up with changes to the way shadow DOM distributes nodes to better fit real world use cases. After studying various real world use of web component APIs as well as exiting GUI frameworks, we noticed that selector based node distribution as currently spec'ed doesn't address common use cases and the extra flexibility CSS selectors offers isn't needed in practice. Instead, we propose named insertion slots that could be filled with the contents in the original DOM as well as contents in subclasses. Because the proposal uses the same slot filling mechanism for content distributions and inheritance transclusions, it eliminates the need for multiple shadow roots. Please take a look at our proposal at https://github.com/w3c/webcomponents/wiki/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution [1] https://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0151.html [2] https://lists.w3.org/Archives/Public/public-webapps/2015JanMar/0611.html
Re: [clipboard] Feature detect Clipboard API support?
If we did that, authors could not use synthetic clipboard events for anything - right? I'm assuming that authors are going to find use cases for it - for example a cloud clipboard implementation may want to fire actual paste events so that data from the cloud is processed like data from the local clipboard. -Hallvord Yep thats a very valid point I wouldn't want to stop people being able to trigger synthetic events, not sure of an alternative.
Re: XMLHttpRequest and timing of upload events
On Mon, Apr 20, 2015 at 2:00 PM, Hallvord Reiar Michaelsen Steen hst...@mozilla.com wrote: On Tue, May 20, 2014 at 2:55 PM, Anne van Kesteren ann...@annevk.nl wrote: Because redirects are atomic, we cannot dispatch loadend events and such on the XMLHttpRequestUpload class. Does this change mean we can no longer send 'loadend' on the upload object? How is a script supposed to know when the upload phase is finished, then? Isn't this a functionality we should try to keep - or am I just misunderstanding what you meant here..? I meant that we cannot dispatch it between redirects, only for the final request, and then we do it (just) once, when the response headers are in. -- https://annevankesteren.nl/