[Bug 26595] [Shadow]: A shadow host will receive an event, which must be *stopped*, if a node in a older shadow tree is distributed into a shadow insertion point in the younger tree
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26595 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #1 from Hayato Ito hay...@chromium.org --- I've fixed in https://github.com/w3c/webcomponents/commit/15a5f294f4bb2f2cbd00e610e791ec9dc73527d0 -- You are receiving this mail because: You are on the CC list for the bug.
Re: [clipboard] Add RTF to the mandatory data types list?
Does anyone else have input for/against this? Conceptually, I guess RTF sort of covers the same use cases as HTML. That doesn't necessarily mean we should not add it. I don't have input as such, but I have a few questions: Is there any widely used software that writes RTF data to the system clipboard but *not* HTML? If there's RTF on the clipboard and you try pasting into a rich text editing element, does any browser convert RTF to HTML to preserve the formatting? Did anyone ever write a complete RTF parser in JavaScript? If you could read raw RTF data off the clipboard, how would you process it? How likely do you think it is that those who write web editors will go through the efforts and add code to handle RTF paste? -Hallvord
Re: Proposal for a credential management API.
On Mon, Aug 18, 2014 at 7:07 PM, Hill, Brad bh...@paypal.com wrote: I think the broader goals Jonas has articulated probably belong in their own group, perhaps chartered along with some of what comes out of the upcoming Web Crypto Next Steps workshop. I'm certainly interested in seeing what comes out of that workshop, and I'm equally curious about FIDO in general. Ideally, then, without being too optimistic, I'd like to see passwords replaced entirely by better technology rather than continuing to kludge upon them. They're still a fundamentally broken technology in many important respects even with better management tools. What's a timeframe in which you might reasonably expect that to happen? I suspect it's not months or next year. We're having a hard enough time getting folks onto SSL, which is a much more basic requirement. I, personally, don't honestly expect passwords to be widely replaced in the near future, especially given how central they are to identity on today's web. Given the investment in password-based authentication systems, and the lethargic pace at which things like this tend to move, I think the use cases spelled out in my proposal remain quite relevant to today's web, and tomorrow's web. Hopefully they're less relevant to web 3.0, but that's a ways off. :) Also, we should be careful in decomposing our targets here. Federation is a different layer than replacing passwords or password management. There are already a number of standards in that area which could be given native support in a browser without having to re-invent the wheel. (e.g. SAML2, WS-Federation, OpenID Connect / OAuth2, etc.) I agree with this division. However, I'm hopeful that the strawman I've proposed is flexible enough to support a number of potential forms of credentials. It currently defines local and federated credentials broadly, and vaguely. In spirit, at least, it's following Mozilla's position paper's call for a box implementations can go in, and is extensible by design. -- Mike West mk...@google.com Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91 Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Geschäftsführer: Graham Law, Christine Elizabeth Flores (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)
[imports] Spec. polishing
I've heard complains about the readability of the current import draft, and I think the best way to improve it, if we all take some time and point out the parts that could benefit from some polishing. Instead of filing a dozen of tiny bugs, I just went through the spec. again and took some notes. Some of these nits are just personal opinion, so I don't expect all of them to be addressed but I guess it helps if I mention them. I'm not a native English speaker so I have not tried fixing grammar mistakes. - import referrer section does not reflect the fact that there can be more referrer for an import (the referrer - one of the referrers) - for master document might be easier defined as the one and only root node of the import graph - what's up with the defaultView these days? is it shared? is it null? is it decided? - imported documents don't have a browsing context - isn't it more precise that it's using the master documents browsing context? - import dependent is used before defined - import parent/ancestor : I would define parent first and then extend it to ancestor. also worth mentioning that the import link list are the sub imports list for clarification - it's extremly hard to see that script execution order is really defined, even when I know how it is defined... figuring it out from the current spec without any prior knowledge is... challanging to say the least. I think a detailed walk through on the graph would be a HUGE help. By that I mean explicitly defining the execution order for the example, and also maybe illustrating at some stages, what is blocking what. - missing link to 'simple event' Gabor
IndieUI Teleconference Agenda; 20 August at 21:00Z for 60 minutes
I'm cross-posting this IndieUI agenda As part of IndieUI's continuing open invitation continuing our conversation about working jointly. Allow me to invite you to the next Indie-UI teleconference as detailed below. Please feel free to join us on this call, or any following call. What: IndieUI Task Force Teleconference When: Wednesday 20 August 2:00 PMSan Francisco -- U.S. Pacific (Daylight) Time (PDT: UTC -7) 4:00 PMAustin -- U.S. Central (Daylight) Time (CDT: UTC -5) 5:00 PMBoston -- U.S. Eastern (Daylight) Time (EDT: UTC -4) 10:00 PMLondon -- British (Summer) Time (BST: UTC +1) 11:00 PMParis -- Central European Time (CET: UTC +2) 5:00 AMBeijing -- China Standard Time (Thursday, 21 August CST: UTC +8) 6:00 AMTokyo -- Japan Standard Time (Thursday, 21 August JST: UTC +9) 7:00 AMMelbourne -- Australian Eastern (Standard) Time (Thursday 21 August AEST: UTC +10) Where: W3C Teleconference--See Below * Time of day conversions Please verify the correct time of this meeting in your time zone using the Fixed Time Clock at: http://timeanddate.com/worldclock/fixedtime.html?msg=IndieUI+Teleconferenceiso=20140820T1700p1=43ah=1 ** Preliminary Agenda for IndieUI Task Force Teleconference 6 August 2014 Meeting: IndieUI Task Force Teleconference Chair: Janina_Sajka agenda+ preview agenda with items from two minutes agenda+ TPAC 2014 http://www.w3.org/2014/11/TPAC/ agenda+ Editor's Report agenda+ Open Items with Web Apps' Editing TF [See below] agenda+ Testing Conversation; Polyfills agenda+ User Context Issues Actions https://www.w3.org/WAI/IndieUI/track/products/3 agenda+ Events Issues Actions https://www.w3.org/WAI/IndieUI/track/products/2 agenda+ Other Business agenda+ Be Done Resource: IndieUI Minutes http://www.w3.org/2014/08/06-indie-ui-minutes.html Resource: Web Apps Editing TF Explainer: http://w3c.github.io/editing-explainer/commands-explainer.html Resource: For Reference Home Page: http://www.w3.org/WAI/IndieUI/ Email Archive: http://lists.w3.org/Archives/Public/public-indie-ui/ Resource: Teleconference Logistics Dial the Zakim bridge using either SIP or the PSTN. PSTN: +1.617.761.6200 (This is a U.S. number). SIP: za...@voip.w3.org You should be prompted for a pass code, This is 46343# (INDIE#) Alternatively, bypass the Zakim prompts and SIP directly into our teleconference. SIP: 0046...@voip.w3.org Instructions for connecting using SIP: http://www.w3.org/2006/tools/wiki/Zakim-SIP Place for users to contribute additional VoIP tips. http://www.w3.org/2006/tools/wiki/Zakim-SIP-tips IRC: server: irc.w3.org, channel: #indie-ui. During the conference you can manage your participation with Zakim commands as follows: 61# to mute yourself 60# to unMute yourself 41# to raise your hand (enter speaking queue) 40# to lower your hand (exit speaking queue) The system acknowledges these commands with a rapid, three-tone confirmation. Mobile phone users especially should use the mute function if they don't have a mute function in their phone. But the hand-raising function is a good idea for anyone not using IRC. * IRC access An IRC channel will be available. The server is irc.w3.org, The port number is 6665 (Note this is not the normal default) and The channel is #indie-ui. * Some helpful Scribing and Participation Tips http://www.w3.org/WAI/PF/wiki/Teleconference_cheat_sheet For more on the IRC setup and the robots we use for agenda and speaker queuing and for posting the log to the web, see: - For RRSAgent, that captures and posts the log with special attention to action items: http://www.w3.org/2002/03/RRSAgent - For Zakim, the IRC interface to the bridge manager, that will maintain speaker and agenda queues: http://www.w3.org/2001/12/zakim-irc-bot - For a Web gateway to IRC you can use if your network administrators forbid IRC, see: http://www.w3.org/2001/01/cgi-irc - For more on W3C use of IRC see: http://www.w3.org/Project/IRC/ -- Janina Sajka, Phone: +1.443.300.2200 sip:jan...@asterisk.rednote.net Email: jan...@rednote.net The Linux Foundation Chair, Open Accessibility: http://a11y.org The World Wide Web Consortium (W3C), Web Accessibility Initiative (WAI) Chair, Protocols Formats http://www.w3.org/wai/pf IndieUI http://www.w3.org/WAI/IndieUI/
Re: [clipboard] Add RTF to the mandatory data types list?
On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: Does anyone else have input for/against this? Conceptually, I guess RTF sort of covers the same use cases as HTML. That doesn't necessarily mean we should not add it. I don't have input as such, but I have a few questions: Is there any widely used software that writes RTF data to the system clipboard but *not* HTML? If there's RTF on the clipboard and you try pasting into a rich text editing element, does any browser convert RTF to HTML to preserve the formatting? Chrome Mac should (though I've never tested this functionality). I think the code for this was inherited from Camino, so Firefox may have this as well. It's not common--it's only implemented on Mac because there's some platform support already for parsing RTF into a NSAttributedString and then dumping the result as HTML. Did anyone ever write a complete RTF parser in JavaScript? If you could read raw RTF data off the clipboard, how would you process it? How likely do you think it is that those who write web editors will go through the efforts and add code to handle RTF paste? -Hallvord
RE: [clipboard] Add RTF to the mandatory data types list?
On Tue, Aug 19, 2014 at 10:08 AM, Daniel Cheng dch...@chromium.org wrote: On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: Does anyone else have input for/against this? Conceptually, I guess RTF sort of covers the same use cases as HTML. That doesn't necessarily mean we should not add it. I don't have input as such, but I have a few questions: Is there any widely used software that writes RTF data to the system clipboard but *not* HTML? If there's RTF on the clipboard and you try pasting into a rich text editing element, does any browser convert RTF to HTML to preserve the formatting? Chrome Mac should (though I've never tested this functionality). I think the code for this was inherited from Camino, so Firefox may have this as well. It's not common--it's only implemented on Mac because there's some platform support already for parsing RTF into a NSAttributedString and then dumping the result as HTML. Internet Explorer puts RTF on the clipboard during copy (as well as HTML, text, etc), so yes we should allow developers to access it.
RE: [clipboard] Add RTF to the mandatory data types list?
From: Ben Peters On Tue, Aug 19, 2014 at 10:08 AM, Daniel Cheng dch...@chromium.org wrote: On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: Does anyone else have input for/against this? Conceptually, I guess RTF sort of covers the same use cases as HTML. That doesn't necessarily mean we should not add it. I don't have input as such, but I have a few questions: Is there any widely used software that writes RTF data to the system clipboard but *not* HTML? If there's RTF on the clipboard and you try pasting into a rich text editing element, does any browser convert RTF to HTML to preserve the formatting? Chrome Mac should (though I've never tested this functionality). I think the code for this was inherited from Camino, so Firefox may have this as well. It's not common--it's only implemented on Mac because there's some platform support already for parsing RTF into a NSAttributedString and then dumping the result as HTML. Internet Explorer puts RTF on the clipboard during copy (as well as HTML, text, etc), so yes we should allow developers to access it. Actually IE also supports converting RTF on the clipboard to HTML when pasted.
Re: [clipboard] Add RTF to the mandatory data types list?
Le 19 août 2014 à 19:36, Hallvord R. M. Steen hst...@mozilla.com a écrit : If there's RTF on the clipboard and you try pasting into a rich text editing element, does any browser convert RTF to HTML to preserve the formatting? On MacOSX Test 1: Copy styled text with a link in a Web page (grey and pink text, black background, Big size) into an RTF editor (TextEdit). * Safari - TextEdit: color, size, position and links preserved * Firefox - TextEdit: only size and links are preserved Test 2: Copy styled text from an RTF editor to content editable form http://codepen.io/matt-west/full/gtruC * TextEdit - Safari: Everything is preserved * TextEdit - Firefox: Nothing is preserved, just the text. Checking by inspecting the DOM content in the form in Safari: p style=margin: 0px 0px 10px; font-size: 34px; line-height: normal; font-family: Times; color: rgb(225, 44, 155);foobar/p -- Karl Dubost http://www.la-grange.net/karl/
