Re: [clipboard] Add RTF to the mandatory data types list?
Right now, the default action for copy/cut also populates text/plain on the clipboard if you're copying HTML (I don't think the spec explicitly mentions this, but I'm pretty sure this is how most browsers behave). Given the current discussion, it seems expected that the browser will automatically convert between RTF and HTML. If a user copies markup, the browser should add RTF. If the user pastes RTF, the browser should convert it back into HTML. Implementing this conversion has one major problem: RTF parsing is complicated. The spec is several hundred pages long. Every browser is going to have to add rich text parser that's almost completely unrelated to the web when it already has a perfectly good parser for HTML. In the past, RTF support would have helped text that wanted to include inline images, but there has been progress on solving this without depending on RTF: http://lists.w3.org/Archives/Public/public-webapps/2014JanMar/0103.html On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: 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? I'm curious about the answer to this as well. I haven't seen any examples raised outside of TextEdit. While TextEdit is widely deployed, is it actually widely used as a rich text editor? I know I just use it as the occasional scratch pad. If there aren't any good examples, I don't think it makes sense to make RTF a mandatory data type. If there are, I still think it'd make more sense to push those editors towards supporting HTML rather than trying to make browsers support RTF. Daniel On Tue, Aug 19, 2014 at 8:17 PM, Karl Dubost k...@la-grange.net wrote: 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/
Re: IndieUI Teleconference Agenda; 20 August at 21:00Z for 60 minutes
apols -andy 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/ andy andyhe...@axelrod.plus.com -- __ Andy Heath http://axelafa.com
Re: Screen Orientation Feedback
Alternatively we could have a unit quaternion representation instead of screenAlpha/screenBeta/screenGamma. Given that webapps tend to convert the euler angle representation to something that is easier to compose anyway. As already mentioned by Rich the angle representations currently differ somewhat between browsers: Safari uses different ranges for beta, gamma and there are some issues with Firefox which does not seem to report the correct angles for some orientations. Unit quaternions are less ambiguous since each rotation can be represented by either unit quaternion q or -q. Tim On Wed, Aug 13, 2014 at 10:52 PM, Jonas Sicking jo...@sicking.cc wrote: On Wed, Aug 13, 2014 at 1:38 AM, Rich Tibbett ri...@opera.com wrote: Do you have any thoughts on providing screen-adjusted devicemotion event data also (i.e. acceleration, accelerationIncludingGravity, rotationRate) It's not something I've thought about, but yeah, it sounds like that would make sense. / Jonas
Encapsulating CSS in Shadow DOM
I am hoping it will be possible to have root em like font size based values, but based on the shadow root (or host) when using shadow dom. Like 10hem (host em) or something like that. That would make it a lot easier to make scalable widgets/components where only one or a few css properties would have to be changed when scaling the content in different contexts. I have described this in more detail here: http://stackoverflow.com/questions/24953647/font-size-css-values-based-on-shadow-dom-root
[Bug 26615] New: Is topLevelViewport needed?
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26615 Bug ID: 26615 Summary: Is topLevelViewport needed? Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: Fullscreen Assignee: ann...@annevk.nl Reporter: phil...@opera.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org http://fullscreen.spec.whatwg.org/#dom-element-requestfullscreen Can pending's top-level browsing context's document's viewport change after the async return? I don't think so, and in order to fix 26601 the pending variable would have to be kept across the async boundaries, so one might just as well use that directly. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Encapsulating CSS in Shadow DOM
Hmm. I thought that's part of the purpose of Web Component, i.e. to encapsulate CSS and JS? Is it not so? On Wed, Aug 20, 2014 at 1:42 AM, Henrik Haugberg henrik.haugb...@gmail.com wrote: I am hoping it will be possible to have root em like font size based values, but based on the shadow root (or host) when using shadow dom. Like 10hem (host em) or something like that. That would make it a lot easier to make scalable widgets/components where only one or a few css properties would have to be changed when scaling the content in different contexts. I have described this in more detail here: http://stackoverflow.com/questions/24953647/font-size-css-values-based-on-shadow-dom-root
Re: Encapsulating CSS in Shadow DOM
n/m ... the request is more specific than the email subject... the JS solution to the problem is certainly less appealing than a CSS only solution.. .will be watching this :) On Wed, Aug 20, 2014 at 9:20 AM, Marc Fawzi marc.fa...@gmail.com wrote: Hmm. I thought that's part of the purpose of Web Component, i.e. to encapsulate CSS and JS? Is it not so? On Wed, Aug 20, 2014 at 1:42 AM, Henrik Haugberg henrik.haugb...@gmail.com wrote: I am hoping it will be possible to have root em like font size based values, but based on the shadow root (or host) when using shadow dom. Like 10hem (host em) or something like that. That would make it a lot easier to make scalable widgets/components where only one or a few css properties would have to be changed when scaling the content in different contexts. I have described this in more detail here: http://stackoverflow.com/questions/24953647/font-size-css-values-based-on-shadow-dom-root
Re: [clipboard] Add RTF to the mandatory data types list?
On Aug 20, 2014 4:19 AM, Daniel Cheng dch...@chromium.org wrote: On Tue, Aug 19, 2014 at 3:36 AM, Hallvord R. M. Steen hst...@mozilla.com wrote: 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? I'm curious about the answer to this as well. I haven't seen any examples raised outside of TextEdit. While TextEdit is widely deployed, is it actually widely used as a rich text editor? I know I just use it as the occasional scratch pad. If there aren't any good examples, I don't think it makes sense to make RTF a mandatory data type. If there are, I still think it'd make more sense to push those editors towards supporting HTML rather than trying to make browsers support RTF. Another likely scratch pad editor that only supports RTF is Windows WordPad. A real and [surprisingly still] popular editor that only accepts RTF pastes -- at least as of its fairly recent X5 version (now on version X7) -- is WordPerfect. I learned this in the past few years while building a very [ *very*] premium product for a legal research/workflow solutions company. When I created the rich copy functionality [using Flash], we were required to support plain text, HTML, and RTF for the clipboard injection as WordPerfect X5 couldn't consume the HTML clipboard segment when pasting but could consume RTF. Not sure if that has changed in X6 or X7 as I no longer work for that employer.
Minutes IndieUI Teleconference 20 August 2014
http://www.w3.org/2014/08/20-indie-ui-minutes.html
RE: [streams-api] Seeking status of the Streams API spec
Hi HTML WG, The streams API is progressing quite nicely, and is *very* close to being settled. At this point much of what remains is polishing the spec; the text is quite raw at the moment, with much of the trickier bits (e.g. transform streams) relegated to the reference implementation as we tweak the algorithms and add more to the test suite before porting them back into the spec proper. The spec work is happening at https://github.com/whatwg/streams; see also https://whatwg.github.io/streams/ (temporary URL) which contains more of the explanatory text and examples, and will eventually contain the algorithms currently prototyped at the former URL. There is a slight chance that some parts of the API may become a bit simpler over the next week. In particular I am investigating: (1) combining the async-notify + sync-read/write into async-read/write; and (2) possibilities for a design that makes readable and writable streams two sides of the same pipe, to simplify their construction APIs. However, neither of these is looking terribly fruitful or worthwhile right now, and in either case I have set myself a hard deadline of finishing that investigation and any related changes by next Friday before I leave for some travel. In terms of what's happening and what's coming: Chrome is prototyping an implementation at [1] (see also [2]). At [3], Takeshi has begun work on a simple extension for bring your own buffer binary streams that interoperate with the more generic streams that compose the bulk of the work done so far, which is looking lovely. The TCP/UDP sockets spec [4] has been based on this streams design for some time, and is seeing implementation interest at Mozilla in addition to very successful engagement from the editor of that spec in figuring out how to integrate streams there. For concrete timeline: one of my Q3 goals as a Google employee is to publish a polished version of the stream spec + polyfill + test suite. This might be slightly optimistic but still seems doable. I also know that Takeshi's team is hoping to have a prototype implementation in Blink somewhere near that timeframe as well, and is currently investigating fetch integration [5]. In any case, hope this is helpful and if you have any questions, feel free to reach out, either on the public-webapps or whatwg mailing lists, or (preferably) on our GitHub issue tracker. We really enjoyed the collaboration on TCP/UDP sockets and would be happy to do similar for Media Source Extensions. Best, -Domenic [1]: https://code.google.com/p/chromium/issues/detail?id=393911 [2]: https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/streams/ReadableStream.h [3]: https://github.com/whatwg/streams/pull/173 [4]: https://github.com/sysapps/tcp-udp-sockets [5]: http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0285.html -Original Message- From: Arthur Barstow [mailto:art.bars...@gmail.com] Sent: Monday, August 18, 2014 14:28 To: Takeshi Yoshino; Feras Moussa; Domenic Denicola Cc: public-webapps; team-html-cha...@w3.org Subject: [streams-api] Seeking status of the Streams API spec Hi All, The HTML WG would like to know the status of the Streams API and if the February plan from Feras (see below) is still the plan-of-action. Please provide an update. Paul - the last status I saw was the following e-mail from Domenic on June 27 http://lists.w3.org/Archives/Public/public-sysapps/2014Jun/0014.html. -Thanks, AB Original Message Subject:RE: Update on Streams API Status Date: Mon, 18 Aug 2014 17:57:05 + From: Paul Cotton paul.cot...@microsoft.com To: Arthur Barstow (art.bars...@gmail.com) art.bars...@gmail.com, Charles McCathie Nevile (cha...@yandex-team.ru) cha...@yandex-team.ru CC: team-html-cha...@w3.org team-html-cha...@w3.org I am preparing a Media TF agenda and we still have a TF Action [1] open concerning coordination with WebApps WG on the Streams API. Can you point me to a more recent status report on the work on the Streams API spec(s) than the one below from Feb 2014? Was the plan in this update actually implemented? /paulc [1] https://www.w3.org/html/wg/media/track/actions/59 Paul Cotton, Microsoft Canada 17 Eleanor Drive, Ottawa, Ontario K2E 6A3 Tel: (425) 705-9596 Fax: (425) 936-7329 -Original Message- From: Arthur Barstow [mailto:art.bars...@nokia.com] Sent: Friday, February 07, 2014 7:58 AM To: public-html-ad...@w3.org Subject: Fwd: Update on Streams API Status Since the Media Source Extensions spec includes a normative reference for WebApps' Streams API, please see the following status and plans information from the spec's Editors. If you have any comments, please send them to mailto:public-webapps@w3.org. Original Message Subject:Update on Streams API Status Resent-Date:Fri, 7 Feb 2014 04:31:48 + Resent-From:public-webapps@w3.org Date:
