Re: riks of the new clipboard operations API
On 9/5/11 10:49 PM, Paul Libbrecht wrote: Le 6 sept. 2011 à 00:51, Glenn Maynard a écrit : On Mon, Sep 5, 2011 at 11:41 AM, Paul Libbrecht p...@hoplahup.net mailto:p...@hoplahup.net wrote: Slowly, users start to see the disadvantages of a dirty web-page (e.g. flash advertisement 100% cpu) and I am confident they will not that some pages mingle with their copy ability or actually provide a service to do so. Sorry, I'm having trouble parsing this. My experience so far is that people are aggravated by pages that insert ads into copied text, but not quite enough to stop them from using a page. They grumble and delete the ad. That's the most annoying category of abuse, in my opinion: not bad enough to strongly discourage its use, causing it to spread, but bad enough to continuously annoy users. They will provide feedback and/or prefer sites that do not do that. The offer is diverse enough for this. That's what the paragraph above says. I agree that the API indeed brings in new possibilities of abuse and new utilities, they cannot be discerned except by an end user. You are are right we need to be aware of the risks. The tracker injection is, to my taste, relatively mild. Hidden anchors would be considerably worse. paul I'd love to hear your feedback but that's how I feel things and I think we just have to accept it: new technology, new risks, positive and negative. It's acceptable for new technologies to have negatives, of course; the positives need to balance the negatives. To be clear, I don't mean that this abuse is newly exposed by this API. It's an abuse that's been spreading lately, using hacks with existing APIs. I meant that it shows that people will broadly abuse anything that lets them fiddle with the clipboard; in other words, this isn't a theoretical problem. I'd hoped to see browsers adjust behavior so clipboard copying happens before anything else (before firing DOM events at all), making it more difficult for pages to fiddle with the selection before the copy occurs, but this API makes that approach useless; it officially blesses the entire category of messing-with-what-the-user-copies, so it'd never be fixable. That's frustrating. I've seen licensing contracts which require clipboard operations to be obfuscated. I think they are wrong-headed, but the licensing issue results in sites which need to obfuscate their source code through IFRAME and other such measures. Licensees working with such a contract -may- have an argument for staying away from various obfuscation methods, if they can claim that view-source, copy/paste and print, are disabled for typical web users. Media selectors make the disabling of print easy. An abuse-able, copy/paste mechanism works for the other issue. View-source is handled via xml entities / the ampersand in HTML/XML. The positive side of this, is that authors can provide their content using best standards: the content can be encoded in normal HTML, it can be read in all browsers, and the content can be read by assistive technologies. On the negative side, such sites will be frustrating for users trying to copy, print or otherwise use content in a fair manner. -Charles
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Mon, 5 Sep 2011, Tab Atkins Jr. wrote: On Sun, Sep 4, 2011 at 6:12 AM, Arthur Barstow art.bars...@nokia.com wrote: Some members of the group consider the D3E spec as the highest priority of our DOM-related specs and they have put considerable resources into that spec. Doug and Jacob will continue to lead that spec effort, and as I understand it, a CR for D3E is imminent. I expect the group to help progress that spec. At the same time, others members have put substantial resources into DOM Core (and closely related functionality such as DOM Range). Naturally, they want to preserve that investment and I support that work continuing. I would like to publicly register that I find the sentiment expressed in the above paragraphs (regarding the work editors have put into the spec) as deeply troubling. I must agree in the most strongest terms with Tab here. As editors we must be willing to throw away efforts when it becomes clear that they are not the best solution for the Web. Witness for example Web SQL Database, which I jettisoned as soon as it was clear that it did not enjoy broad support. Sunk cost is never a valid economic reason to persue a particular course (q.v. the sunk cost fallacy [1]). This applies equally well to technical development. The fact that we have a specification written or that we have personally invested in it must have no bearing whatsoever on our decisions regarding whether to continue. [1] http://en.wikipedia.org/wiki/Sunk_costs#Loss_aversion_and_the_sunk_cost_fallacy -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: Reference to the HTML specification
On 2011-09-06 01:02, Ian Hickson wrote: On Mon, 5 Sep 2011, Julian Reschke wrote: I do see that it's a problem when people use outdated specs; but maybe the problem is not the being dated, but how they are published. As far as I can tell, there's not nearly as much confusion on the IETF side of things, where Internet Drafts actually come with an Expiration Date. Not helpful, I was referring to Internet drafts. Things are even worse on the IETF side, with RFCs that have been long obsoleted by newer RFCs having no clear indication of such, RFCs having Yes, that's a problem. no canonical URL, RFCs claiming things that are completely bogus, etc. They do have a canonical URL (just not a good one). Plus, IDs expire, which makes things even worse, since it means you can't have stability _by design_ unless you're willing to commit to the text I think that's a feature. being fixed. Plus, when someone actually tries to publish regular updates, as I did with the WebSocket draft, people complain that it's being updated! No, the IETF situation is far worse. Because you were using the publication process in a way it's not designed for. Best regards, Julian
[Bug 11966] Catrope's feedback
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11966 Anne ann...@opera.com changed: What|Removed |Added Status|NEW |RESOLVED CC||ann...@opera.com Resolution||WORKSFORME --- Comment #1 from Anne ann...@opera.com 2011-09-06 07:45:46 UTC --- Aryeh already went through this list. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Mon, 05 Sep 2011 16:50:15 +0200, Glenn Maynard gl...@zewt.org wrote: Pretty much everything in this spec can be abused to cause nuisance. Personally, I'm less than thrilled to see an API giving sites more ability to mangle what I copy. With greater powers comes, as they say, greater responsibility. If you personally don't like the possibilities for nuisance this API enables, you have multiple options - use a browser that doesn't support these events, or a browser that lets you disable them (perhaps on a per-site basis), or a browser that supports extensions that let you disable them. I also think that a site that behaves in user-unfriendly ways will end up loosing users. If a site is arrogant enough to mess with what I copy unless to improve it, it deserves to loose users. -- Hallvord R. M. Steen, Core Tester, Opera Software http://www.opera.com http://my.opera.com/hallvors/
Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On 9/5/11 3:34 PM, ext Tab Atkins Jr. wrote: We should make these kinds of decisions *solely* on technical grounds. Well surely making decisions on technical grounds is important. However, it seems a bit simplistic to consider it the only factor. (I seem to recall some previous decisions were based, for example, on existing implementations and deployments.) -AB
RfC: LCWD of Web Storage; deadline September 27
A new LCWD of Web Storage was published: http://www.w3.org/TR/2011/WD-webstorage-20110901/ Please send all comments to public-webapps@w3.org by September 27.
RfC: LCWD of Web Workers; deadline September 27
A new LCWD of Web Workers was published: http://www.w3.org/TR/2011/WD-workers-20110901/ Please send all comments to public-webapps@w3.org by September 27.
Re: [widgets] CFC to republish Widget URI spec
All - we had a brief chat about this request in IRC [1]. Marcos wants to publish a new WD (last publication was a LCWD) and the tentative publication date for that WD is Sept 13. After there is working code for this spec, Marcos will resume/restart the scheme registration discussion. -AB [1] http://krijnhoetmer.nl/irc-logs/webapps/20110906 On 8/24/11 10:09 AM, ext Marcos Caceres wrote: Hi, I would like to republish the Widget URI scheme spec as a Working Draft. http://dev.w3.org/2006/waf/widget-uris/ Please consider this a 1 Week CFC - if you object, please let the group know. What's new: 0 . Added a bunch of examples. 1. Resolving URIs is now left to the host Document (i.e., HTML5's resolve URL algorithms). 2. Added straw-man for behaving like HTTP (inspired by FileAPI's blob://) 3. Generalized the dereferencing algorithm so non PC compliant runtimes can use it. I will continue doing a minor cleanup over the next week. Kind regards, Marcos
Re: Reference to the HTML specification
Hi Marcos Are you and Ian suggesting we eliminate the publication of WD versions on the way to Rec and just keep the editors draft in TR space? A major implication relates to IPR licensing obligations, which serve to protect implementers. These obligations are incurred relative to steps in the process, e.g. First public WD publication etc. Have you figured out how editors draft in TR space would work with the W3C patent policy (maybe not an issue if you are saying we have both published drafts as well as editors draft in TR space). The risk of not following the W3C process and not publishing FPWD is that there is no IPR protection for implementers of the editors draft and that members might drop from the WG before becoming obligated (e.g. there might be a time window risk here) , and in fact there may never be IPR protection if the editors draft never enters the W3C process. Maybe IPR is no longer an issue for implementers in this area of work, but I'd be surprised, given its ongoing importance elsewhere. Without a process, it is not very clear who exactly has agreed to what with the editors draft. At a minimum we need clarity for readers that an editors draft is a draft and may include changes by an editor that are either mistaken, do not have WG agreement, or might be reverted for other reasons. We should review why W3C has a process - I believe in addition to IPR it includes a means to obtain consensus and make sure everyone is heard. Will this continue if we were to change along the lines you suggest? An alternative (and maybe this is what is under consideration) is to publish the editors draft in TR space in addition to the W3C process drafts (FPWD, WD, LC, CR etc) and make for clarity regarding the relationship and status. In this case we might also consider focus on the editors draft with perhaps a different mechanism for linking to snapshots for W3C states (e.g. use CVS/Subversion etc snapshots and link from the editors draft via a process status page). regards, Frederick Frederick Hirsch Nokia On Sep 3, 2011, at 4:14 PM, ext Marcos Caceres wrote: On Saturday, 3 September 2011 at 20:54, Ian Hickson wrote: On Mon, 29 Aug 2011, Philippe Le Hegaret wrote: But, the WHATWG HTML links to the editor's drafts and does not link to the TR one. While documents on the REC-track should link to other documents on the REC tracks, this doesn't apply to editor's draft, which have no special status anyway. So, you can link to both versions in the editor's draft if you prefer. Well, the editor's drafts have one special status: they're the most correct drafts, unlike the TR/ drafts, which are often obsolete as soon as they're published (in the case of the HTML spec, they're obsolete _before_ they're published, since the publication process takes several days). So it's not entirely true that they have no special status. I agree with Ian. The W3C process is really harmful in not giving Editor's Drafts special status in the process. Ideally, Working Groups should be able to choose if their specs are frozen or live documents on TR. I've made this proposal several times to the W3C (pointing out how harmful this has been, particularly when other consortia or implementers use W3C status as an indicator of stability), and I'm hoping we can all have a fruitful discussion about this during TPAC. Can we please arrange a formal forum for this discussion and debate during TPAC? I've said this a number of times, but I am getting to the point where I no longer want to put anything on TR because I've seen how harmful that can be (if I end up writing another spec at the W3C, I will not choose to publish it on TR without HTML5-like BIG RED WARNING and only to meet the IPR requirements… and continue to only link to editor's drafts). Kind regards, Marcos
Re: Reference to the HTML specification
On Tuesday, September 6, 2011 at 4:56 PM, frederick.hir...@nokia.com wrote: Hi Marcos Are you and Ian suggesting we eliminate the publication of WD versions on the way to Rec and just keep the editors draft in TR space? Yes A major implication relates to IPR licensing obligations, which serve to protect implementers. These obligations are incurred relative to steps in the process, e.g. First public WD publication etc. Have you figured out how editors draft in TR space would work with the W3C patent policy (maybe not an issue if you are saying we have both published drafts as well as editors draft in TR space). Yes, just file those some where out of the way for the lawyers (not one else cares, or should care)… e.g., link to the them deep down in the appendix, where they can do no harm. The risk of not following the W3C process and not publishing FPWD is that there is no IPR protection for implementers of the editors draft and that members might drop from the WG before becoming obligated (e.g. there might be a time window risk here) , and in fact there may never be IPR protection if the editors draft never enters the W3C process. Maybe IPR is no longer an issue for implementers in this area of work, but I'd be surprised, given its ongoing importance elsewhere. By all means, publish the special agreed-to versions that represent a consensus by the working group (e.g., LCWD)… but shove them somewhere where they are not indexed by search engines and with a big red note saying You are reading the lawyer's version: go here for the real version. Without a process, it is not very clear who exactly has agreed to what with the editors draft. At a minimum we need clarity for readers that an editors draft is a draft and may include changes by an editor that are either mistaken, do not have WG agreement, or might be reverted for other reasons. It would be up the group to decide what model they use: consensus driven or benevolent dictator or whatever works best. We should review why W3C has a process - I believe in addition to IPR it includes a means to obtain consensus and make sure everyone is heard. Will this continue if we were to change along the lines you suggest? Absolutely. Nothing needs to change: I don't see why it would… it would probably work better because people would not sit around waiting for specs to reach some magical status (oh, it's still a working draft… I'll wait till last call before looking at it). An alternative (and maybe this is what is under consideration) is to publish the editors draft in TR space in addition to the W3C process drafts (FPWD, WD, LC, CR etc) and make for clarity regarding the relationship and status. Exactly! :) In this case we might also consider focus on the editors draft with perhaps a different mechanism for linking to snapshots for W3C states (e.g. use CVS/Subversion etc snapshots and link from the editors draft via a process status page). Yes, something like that. regards, Frederick Frederick Hirsch Nokia On Sep 3, 2011, at 4:14 PM, ext Marcos Caceres wrote: On Saturday, 3 September 2011 at 20:54, Ian Hickson wrote: On Mon, 29 Aug 2011, Philippe Le Hegaret wrote: But, the WHATWG HTML links to the editor's drafts and does not link to the TR one. While documents on the REC-track should link to other documents on the REC tracks, this doesn't apply to editor's draft, which have no special status anyway. So, you can link to both versions in the editor's draft if you prefer. Well, the editor's drafts have one special status: they're the most correct drafts, unlike the TR/ drafts, which are often obsolete as soon as they're published (in the case of the HTML spec, they're obsolete _before_ they're published, since the publication process takes several days). So it's not entirely true that they have no special status. I agree with Ian. The W3C process is really harmful in not giving Editor's Drafts special status in the process. Ideally, Working Groups should be able to choose if their specs are frozen or live documents on TR. I've made this proposal several times to the W3C (pointing out how harmful this has been, particularly when other consortia or implementers use W3C status as an indicator of stability), and I'm hoping we can all have a fruitful discussion about this during TPAC. Can we please arrange a formal forum for this discussion and debate during TPAC? I've said this a number of times, but I am getting to the point where I no longer want to put anything on TR because I've seen how harmful that can be (if I end up writing another spec at the W3C, I will not choose to publish it on TR without HTML5-like BIG RED WARNING and only to meet the IPR requirements… and continue to only link to editor's
Re: Reference to the HTML specification
* Julian Reschke wrote: I do see that it's a problem when people use outdated specs; but maybe the problem is not the being dated, but how they are published. As far as I can tell, there's not nearly as much confusion on the IETF side of things, where Internet Drafts actually come with an Expiration Date. Publication and document status procedures are meant to support working towards a goal, like to publish the XMLHttpRequest proposal as a Recom- mendation. But there is no expectation that the XMLHttpRequest proposal will be published as a Recommendation within some reasonable timeframe. There is nothing surprising about people getting confused by this. You wouldn't find much support within the IETF to make a XMLHttpRequest Working Group chartered with nothing but to fiddle with some draft over the course of five years with no timline or expectation to produce RFCs or test suites or anything else, so you can't really compare the two. -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
Re: [DOM] Name
On 9/4/11 6:39 AM, Anne van Kesteren wrote: On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow art.bars...@nokia.com wrote: The CfC to publish a new WD of DOM Core was blocked by this RfC. I will proceed with a request to publish a new WD of DOM Core in TR/. The name DOM Core will be used for the upcoming WD. If anyone wants to propose a name change, please start a *new* thread. Given that the specification replaces most of DOM2 and DOM3 I suggest we name it DOM4, including for the upcoming WD (or alternatively a WD we publish a couple of weeks later). This is an editorial issue, and Anne is the editor. It should be his perogative to name the spec he's put so much work into. Editing specs is hard work; let's not create needless headaches for the editors. Everyone has had a chance to make their suggestions, now let's just let Anne publish his spec under whatever name he chooses. Its just a name! David
Re: [DOM] Name
On 9/6/11 9:18 AM, David Flanagan wrote: On 9/4/11 6:39 AM, Anne van Kesteren wrote: On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstow art.bars...@nokia.com wrote: The CfC to publish a new WD of DOM Core was blocked by this RfC. I will proceed with a request to publish a new WD of DOM Core in TR/. The name DOM Core will be used for the upcoming WD. If anyone wants to propose a name change, please start a *new* thread. Given that the specification replaces most of DOM2 and DOM3 I suggest we name it DOM4, including for the upcoming WD (or alternatively a WD we publish a couple of weeks later). This is an editorial issue, and Anne is the editor. It should be his perogative to name the spec he's put so much work into. Editing specs is hard work; let's not create needless headaches for the editors. Everyone has had a chance to make their suggestions, now let's just let Anne publish his spec under whatever name he chooses. Its just a name! I'm not standing in his way, but I can at least point-out that the DOM* name has lead to additional work in other specs, such as the web messaging specs. It seems like an optimization, to me, as I outlined in my prior e-mail. If it needs to be officially stated (I'm not a w3c member): I'm fine with Anne naming his specification DOM Core Level 4, or whatever variant of DOM he is looking to publish under. -Charles
Re: [DOM] Name
On 9/5/11 2:38 PM, Adam Barth wrote: On Mon, Sep 5, 2011 at 2:33 PM, Charles Pritchardch...@jumis.com wrote: On Sep 5, 2011, at 12:06 PM, Adam Barthw...@adambarth.com wrote: On Sun, Sep 4, 2011 at 2:08 PM, Charles Pritchardch...@jumis.com wrote: On 9/4/11 6:39 AM, Anne van Kesteren wrote: On Sun, 04 Sep 2011 15:12:45 +0200, Arthur Barstowart.bars...@nokia.com wrote: The CfC to publish a new WD of DOM Core was blocked by this RfC. I will proceed with a request to publish a new WD of DOM Core in TR/. The name DOM Core will be used for the upcoming WD. If anyone wants to propose a name change, please start a *new* thread. Given that the specification replaces most of DOM2 and DOM3 I suggest we name it DOM4, including for the upcoming WD (or alternatively a WD we publish a couple of weeks later). I propose calling it Web Core. WC1 (Web Core version 1). WebCore is one of the major implementation components of WebKit. Calling this spec Web Core might be confusing for folks who work on WebKit. It would be somewhat like calling a spec Presto. :) Or calling a browser Chrome. :) Web Core does implement web core, doesn't it? Yes, but it also implements HTML5, which isn't part of Web Core. HTML5 includes DOMCore in its dependencies. http://www.whatwg.org/specs/web-apps/current-work/multipage/infrastructure.html#dependencies From the DOMCore goals: moving features from HTML5 that ought to be part of the DOM platform here, while preventing a dependency on HTML5. DOMCore specifies the EventTarget, from which Node, Element and Document inherit, as well as the Event class, from which even non-node classes, such as web messaging, inherit. And the DOMException enumeration. The web core sub-directory contains modules (such as workers) which include DOMCore as the root of their dependency chain. The naming seems appropriate to me. All that said, I'll re-assert: I'm fine with Anne taking the name of DOMCore in the direction of his choosing. I still believe that Web Core as a name and semantic has more utility than DOM4, both in the authoring of specifications and the implementation of various specs which build upon EventTarget and/or Event as their root interface. -Charles
[DOMCore] Web messaging references
There are various specifications that include terminology warnings as part of their reference to DOMCore. Can we reduce the cost of including DOMCore references in basic APIs, by adding some kind of supporting text to the DOMCORE specification's extensibility section? Example: http://dev.w3.org/html5/postmsg/ The term DOM is used to refer to the API set made available to scripts in Web applications, and does not necessarily imply the existence of an actual Document object or of any other Node objects as defined in the DOM Core specifications. [DOMCORE] If it's not appropriate to include in the DOMCORE spec, where could/should that repeated terminology be hosted? Should editors use the excerpt I've copied from postmsg as boilerplate on other specifications for which implementation of DOMCore sections 5 - 11 is irrelevant? -Charles
Re: Reference to the HTML specification
On 9/5/11 12:11 PM, Marcos Caceres wrote: Hi Julian, On Monday, 5 September 2011 at 20:54, Julian Reschke wrote: On 2011-09-05 16:13, Marcos Caceres wrote: ... Most don't, in my experience. Specially those from other consortia. They love cling the dated specs and then pretend they are somehow more stable then the Editor's Draft. It's simply nonsense, but the W3C Process document seems to codify this. bleeding edge quite often. It's a game of who can have the latest and greatest first and the best. Not always so. Other industries believe that having a stable reference point will cut down their interop issues (specially for environments where it's difficult to update software). I know, how ridiculous and illogical is that?! ... Well, dated and immutable specs *indeed* are more stable. If you need stability as in what it says today it will say tomorrow as well then dated snapshots are the right thing to use. It's like slapping a 1.0 on a piece of software. It says nothing about its stability: just that someone slapped 1.0 on it. There are only a few milestones that matter in the spec process: FPWD, LC, and PR - but links to those IRP-relevant snapshots could be hidden away where only the lawyers, or really interested parties, could find them. For what it's worth, attorneys have been patching long before computers were introduced. Many practices receive continuous updates of actual pieces of paper which are carefully pasted into the reference library. Lets get a public version repository on the official w3c website. They pulled off incorporating bugzilla, surely they can pull off incorporating git. It's quite easy. -Charles
RE: [DOM3Events] CR
On Sun, 04 Sep 2011 17:47:45 +0200, Doug Schepers schep...@w3.org wrote: On 9/4/11 9:41 AM, Anne van Kesteren wrote: I do not think that is appropriate given that unlike all our other specifications it does not use Web IDL DOM3 Events does provide Web IDL definitions for the interfaces [1]; it simply doesn't make them normative, because Web IDL is not yet stable. Should the Web IDL spec reach a stable state in time, we can make the Web IDL definitions normative. All our specifications use Web IDL normatively. I do not see why DOM Level 3 Events has to be special here. and we still have not settled how to deal with exceptions on the web platform. DOM3 Events doesn't change anything about this. Should a later spec (such as DOM 4 / DOM Core) change how exceptions are handled, and if implementers agree with that change, we can simply issue an erratum for that in DOM3 Events, and publish an updated draft. This is a minor and common issue... that later specifications supersede previous ones. The File API specification has a warning in the specification about this changing. I think at a minimum that should be stated. These were just two issues that came to mind though, I still have outstanding Last Call comments, as do other people. All of the Last Call issues formally raised in our Tracker have been addressed as indicated in our Disposition of Comments [1]. If there are outstanding issues, then they're likely threads on www-dom that got lost in the shuffle. Kindly, can you be more explicit and enumerate the outstanding issues you're awaiting responses for? Thanks! [1] http://dev.w3.org/2006/webapi/DOM-Level-3-Events/dc.html
Re: Reference to the HTML specification
On Tue, Sep 6, 2011 at 11:32 AM, Charles Pritchard ch...@jumis.com wrote: Lets get a public version repository on the official w3c website. They pulled off incorporating bugzilla, surely they can pull off incorporating git. It's quite easy. We have them. dev.w3.org is the older CSS repository (still used by many groups, such as the CSSWG). dvcs.w3.org is the newer Hg repository. Both repos are public. ~TJ
Re: Reference to the HTML specification
On Tue, 6 Sep 2011, frederick.hir...@nokia.com wrote: Are you and Ian suggesting we eliminate the publication of WD versions on the way to Rec and just keep the editors draft in TR space? Yes (or eliminate the TR/ space entirely and keep the specs elsewhere). A major implication relates to IPR licensing obligations, which serve to protect implementers. These obligations are incurred relative to steps in the process, e.g. First public WD publication etc. Have you figured out how editors draft in TR space would work with the W3C patent policy (maybe not an issue if you are saying we have both published drafts as well as editors draft in TR space). Well ideally the IPR policy would be updated, but in the meantime, I have been suggesting publishing snapshots of the specs on an annual basis with clearly marked headings like Annual Patent Policy Snapshot for Web Storage Specification - 2011 and with text clearly indicating that the document is not intended for implementation reference but is merely a snapshot to be used as a reference for the patent licenses granted via the W3C patent policy. Thus we would still get the IPR protection, but people wouldn't be confused by reading obsolete drafts. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Public repositories, was: Re: Reference to the HTML specification
On 9/6/11 12:30 PM, Tab Atkins Jr. wrote: On Tue, Sep 6, 2011 at 11:32 AM, Charles Pritchardch...@jumis.com wrote: Lets get a public version repository on the official w3c website. They pulled off incorporating bugzilla, surely they can pull off incorporating git. It's quite easy. We have them. dev.w3.org is the older CSS repository (still used by many groups, such as the CSSWG). dvcs.w3.org is the newer Hg repository. Both repos are public. Oh, thanks! I like how domcore is handled here, now that I understand the process better. Repository: https://dvcs.w3.org/hg/domcore Generated files (W3C (c) members, WHATWG (c) editors): http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html http://dvcs.w3.org/hg/domcore/raw-file/tip/dom-core.html Actual file for editing / diff patches: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.src.html Now that I know, that's what I'll do. Will html5 be moving to the newer repository style? David that repo answers your earlier question about the DOM Core Free Editor's Draft. http://lists.w3.org/Archives/Public/www-dom/2011JulSep/0065.html Both drafts are generated from the same source file, so it's likely they'll stay in sync :-) -Charles
Re: [Clipboard API] Copy to clipboard
Why do you need to create an element? Just call execCommand('copy') and
setData('text/html', 'blah') in your copy handler.
Daniel
On Mon, Sep 5, 2011 at 03:57, João Eiras jo...@opera.com wrote:
On Mon, 05 Sep 2011 12:47:28 +0200, Hallvord R. M. Steen
hallv...@opera.com wrote:
On Mon, 05 Sep 2011 02:14:10 +0200, João Eiras joao.ei...@gmail.com
wrote:
Hi !
The spec for setData [1] states that this method when calling from a
cut/copy event sets new data on the clipboard. Unfortunately, this is
insufficient to implement the typical copy to clipboard button
It is indeed. However, you already have things like
document.execCommand('copy') for that.
So lets say I have one of features which let me copy to the clipboard a
snippet of html to embed a video for instance, to paste somewhere.
A script needs to create an element, put the contents inside, wrap a
selection around it, call execCommand('copy'), remove the element and shift
focus back to the button.
Seems a bit overkill. Are you really sure it can't be made simpler ? The
feature is there already, theoretically.
Re: HTMLElement.register--giving components tag names
On Sat, Sep 3, 2011 at 8:20 PM, Ian Hickson i...@hixie.ch wrote: On Sat, 3 Sep 2011, Dominic Cooney wrote: I think the XBL approach is far superior here -- have authors use existing elements, and use XBL to augment them. For example, if you want the user to select a country from a map, you can use a select with a list of countries in option elements in the markup, but then use CSS/XBL to bind that select to a component that instead makes the select look like a map, with all the interactivity that implies. That sounds appealing, but it looks really hard to implement from where we right now. I don't think it's hard is a good reason to adopt an inferior solution, Likewise, intimating that something is better because it's hard is a distraction. especially given that this is something that will dramatically impact the Web for decades to come. The more complex the thing, the more we're saddled with. XBL(2) is more complex than the proposed model. It likewise needs to be justified all the more. XBL already has multiple implementations in various forms. I certainly agree that we should adjust XBL2 to take into account lessons we have learnt over the past five years, such as dropping namespaces and merging it into HTML instead of forcing an XML language on authors, but taking a significantly less capable solution simply because XBL is difficult seems like a very poor trade-off. It *may* be capable of handling the use-cases in question, but that case hasn't been made, and from where I sit, it's not easy or trivial to do by inspection. Regards
[Bug 13373] Privacy: Limit SharedWorker connections to same top-level domain
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13373 Travis Leithead [MSFT] tra...@microsoft.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | --- Comment #5 from Travis Leithead [MSFT] tra...@microsoft.com 2011-09-06 22:05:53 UTC --- I would be satifised with some text that provides an out for User Agents that wish to add additional [optional] privacy restrictions on top of the generic SharedWorker connection algorithm. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Re: [Clipboard API] Copy to clipboard
Maybe execCommand('copy') isn't enabled outside editable region in some UAs?
- Ryosuke
On Tue, Sep 6, 2011 at 2:18 PM, Daniel Cheng dch...@chromium.org wrote:
Why do you need to create an element? Just call execCommand('copy') and
setData('text/html', 'blah') in your copy handler.
Daniel
On Mon, Sep 5, 2011 at 03:57, João Eiras jo...@opera.com wrote:
On Mon, 05 Sep 2011 12:47:28 +0200, Hallvord R. M. Steen
hallv...@opera.com wrote:
On Mon, 05 Sep 2011 02:14:10 +0200, João Eiras joao.ei...@gmail.com
wrote:
Hi !
The spec for setData [1] states that this method when calling from a
cut/copy event sets new data on the clipboard. Unfortunately, this is
insufficient to implement the typical copy to clipboard button
It is indeed. However, you already have things like
document.execCommand('copy') for that.
So lets say I have one of features which let me copy to the clipboard a
snippet of html to embed a video for instance, to paste somewhere.
A script needs to create an element, put the contents inside, wrap a
selection around it, call execCommand('copy'), remove the element and shift
focus back to the button.
Seems a bit overkill. Are you really sure it can't be made simpler ? The
feature is there already, theoretically.
Re: Fwd: Re: CfC: new WD of Clipboard API and Events; deadline April 5
On Tue, Sep 6, 2011 at 7:25 AM, Hallvord R. M. Steen hallv...@opera.comwrote: With greater powers comes, as they say, greater responsibility. If you personally don't like the possibilities for nuisance this API enables, you have multiple options - use a browser that doesn't support these events, or a browser that lets you disable them (perhaps on a per-site basis), or a browser that supports extensions that let you disable them. These aren't solutions that help average users. I also think that a site that behaves in user-unfriendly ways will end up loosing users. If a site is arrogant enough to mess with what I copy unless to improve it, it deserves to loose users. It'd be great if that were the case, but in my experience this is the level of annoyance that will irritate users, but not enough to make many of them stop using a site. -- Glenn Maynard
Re: HTMLElement.register--giving components tag names
On 7/09/11 7:20 AM, Alex Russell wrote: On Sat, Sep 3, 2011 at 8:20 PM, Ian Hicksoni...@hixie.ch wrote: On Sat, 3 Sep 2011, Dominic Cooney wrote: I think the XBL approach is far superior here -- have authors use existing elements, and use XBL to augment them. For example, if you want the user to select a country from a map, you can use aselect with a list of countries inoption elements in the markup, but then use CSS/XBL to bind thatselect to a component that instead makes theselect look like a map, with all the interactivity that implies. That sounds appealing, but it looks really hard to implement from where we right now. I don't think it's hard is a good reason to adopt an inferior solution, Likewise, intimating that something is better because it's hard is a distraction. especially given that this is something that will dramatically impact the Web for decades to come. The more complex the thing, the more we're saddled with. XBL(2) is more complex than the proposed model. It likewise needs to be justified all the more. I agree that XBL2 may have been too ambitious for it's time. I would say that the simplest thing that would be useful would be: a) provide a bare-bones shadow DOM b) implement something like the NodeWatcher proposal - http://www.w3.org/2008/webapps/wiki/MutationReplacement#NodeWatch_.28A_Microsoft_Proposal.29 These features are independently useful and would facilitate Javascript library solutions similar to both HTMLElement.register and XBL2. Then step back and see what the Javascript guys do with it. The next step might write itself. Sean
