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/
