Re: Mouse Lock
But do you agree with me that post ballistics, accelerated and low resolution is exactly what you don't want for most use cases? Why should it not be possible to specify the units I described in my last mail: http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0978.html. That email describes computing distance traveled of input device presuming DPI, sampling rate, and a sample's delta data. DPI is unknown (unless I'm not finding it in APIs e.g. around http://msdn.microsoft.com/en-us/library/ms645589.aspx). I believe first developers seek a specifiable solution that will provide a consistent application experience on all platforms and API implementations. I further believe that post ballistics data will satisfy most developers and users; I have asked some e.g. Unity developers about their implementations and needs, and checked source of other games (e.g. SDL library). Finally, I believe that it is worthwhile to consider adding some rawer form of the input data if possible in a v2 implementation and or spec. Option A: as currently drafted: reuse existing mouse events, make minimal modification to MouseEvent to include movementX/Y valid regardles of mouse lock state, mouseover mouseout will never be fired under mouse lock. pro 2. movementX/Y available even when mouse is not locked. Purely a convenience, apps could compute similar data by tracking the last position of a mouse event and computing deltas (resetting last position on a mouseover event). Purely a convenience is incorrect. Once the mouse cursor reaches the edge of the screen, you can no longer detect motion in that direction by examining the cursor position. That's why you either need to warp the mouse or use raw input events. (Remember, mousemove events are still sent when the mouse is outside of the window, if the user is dragging.) Sorry, some confusion here. This topic Modify MouseEvent, or a new type returned by new mouse events? presumes the hide cursor and warp method, as do all other sections in my recent summary except section Provide mouse deltas without hiding the cursor, alternatively provide a bounding rectangle for mouse. This section is trying to lay out the pros/cons of where to put movement data. The Option A is to provide movementX/Y when locked and unlocked. When locked, the cursor disappears and movement data is provided without limit. When unlocked the mouse events continue to contain that data member and values are provided with best effort. The system cursor exists and mouse events are not available when the cursor is not over the window (unless the mouse is captured). Movement values will stop when the cursor hits a screen edge. The movement members then become only a convenience because javascript code can compute the same values by storing last known positions of screenX/Y and tracking motion with mousemove mouseover. MouseEvent to include movementX/Y valid regardles of mouse lock state I don't think it's possible to both 1: use the same units as the cursor (screen pixels) and 2: get this information when the cursor is visible. If you use the raw APIs (eg. WM_INPUT) Correct, the proposal is NOT to use raw APIs as described above. You forgot a con with this approach: There's no way of exposing functionality of high-res mice. You can only detect mouse motion when it's far enough to cause the (unseen) cursor to move a pixel, because you're reporting motion in terms of cursor movement, rather than the higher-resolution data provided by the device. You're also forced to receive mouse acceleration and I believe axis locking (improve pointer precision in Windows), which may not always be wanted for first-person games. (You also can't expose the ability of modern mice to report at higher rates, eg. 1khz, for the same reason; I'm personally ambivalent about this since I don't have any use cases for it, but others may.) I'm deferring consideration for higher resolution mice data and sampling frequency to a future version of this specification. This was discussed some in Provide mouse deltas without hiding the cursor, alternatively provide a bounding rectangle for mouse. But a summary of my position is that: - Specification is difficult and may not be possible. - Implementation is more complex and doesn't seem justified yet. - Graceful addition of more 'raw' data and higher sampling frequencies is possible. I'm not saying We shouldn't implement raw data, but I am saying we should defer it. I'm happy to review any prototype patches to the chromium/webkit projects that answer these issues. New mouse events created with unique names for click, down, up, move, e.g. mouselockclick, mouselockdown, mouselockup, mouselockmove. I'm confused: was this suggested? I suggested a single event fired for delta movement, eg. mousedelta, but of course there wouldn't be separate events for clicks, too; clicks are orthogonal to motion. (I'm confused that you dismissed
Re: CfC: publish LCWD of Web Storage; deadline August 17
Given no objections to this CfC and no subsequent bug activity, I will work towards a LC publication on September 1 with a 3-week review period. On 8/10/11 7:33 AM, ext Arthur Barstow wrote: Given Hixie's recent set of bug fixes, the Web Storage spec now has zero bugs. As such, it appears this spec is ready to proceed on the Recommendation track and this is a Call for Consensus to publish a new LCWD of this spec using the following ED as the basis: http://dev.w3.org/html5/webstorage/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is August 17. Please send all comments to: public-webapps@w3.org -ArtB
Re: CfC: publish LCWD of Web Workers; deadline August 17
Bug 13772 was filed after the CfC started and since it appears to be an editorial bug, I will work towards a LC publication on September 1 with a 3-week review period. Bug 13373 had some discussion after the CfC ended. However, it is currently resolved as WONTFIX and as such will not block the LC publication. On 8/10/11 7:35 AM, ext Arthur Barstow wrote: Given Hixie's recent set of bug fixes, the Web Workers spec now has zero bugs. As such, it appears this spec is ready to proceed on the Recommendation track and this is a Call for Consensus to publish a new LCWD of this spec using the following ED as the basis: http://dev.w3.org/html5/workers/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is August 17. Please send all comments to: public-webapps@w3.org -ArtB
Re: CfC: publish LCWD of Server-sent Events spec; deadline August 17
Since this CfC was started, 6 new bugs have been filed against this spec [1]. As such, an LC will not be published until these bugs are addressed. [1] http://www.w3.org/Bugs/Public/buglist.cgi?product=WebAppsWGcomponent=Server-Sent%20Events%20%28editor%3A%20Ian%20Hickson%29resolution=--- On 8/10/11 10:24 AM, ext Arthur Barstow wrote: Given Hixie's recent set of bug fixes, the Server-sent Events spec now has zero bugs. As such, it appears this spec is ready to proceed on the Recommendation track and this is a Call for Consensus to publish a new LCWD of this spec using the following ED as the basis: http://dev.w3.org/html5/eventsource/ This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] Positive response to this CfC is preferred and encouraged and silence will be assumed to mean agreement with the proposal. The deadline for comments is August 17. Please send all comments to: public-webapps@w3.org -ArtB
Reminder: RfC: LCWD of Progress Events; deadline September 1
On 8/9/11 1:34 PM, ext Arthur Barstow wrote: On August 9, WebApps published LCWD #2 of the Progress Events spec: http://www.w3.org/TR/2011/WD-progress-events-20110809/ The comment deadline is September 1. Please send all comments to: public-webapps@w3.org -AB
Re: [whatwg] window.cipher HTML crypto API draft spec
Hi, all. I proposed *Web Crypto API community group* in http://www.w3.org/community/groups/proposed/ If you're interested in this issue, please join us and let's discuss together. I thinks there are various oppotunites around WebCrypto API[1] or DOMCryptAPI[2] etc. [1] http://html5.creation.net/webcrypto-api/ [2] https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest Channy - http://www.linkedin.com/in/channy * Biomedical Knowledge Engineering Laboratory http://bike.snu.ac.kr * Daum Developers Network Affiliates http://dna.daum.net 2011년 5월 25일 오전 6:13, Jungshik Shin (신정식, 申政湜) jungs...@google.com님의 말: Thank you for the reply, David. It's my mistake to send it without subscribing to the list. To avoid further splitting the thread, I'm including below my original email here for others to see (and to be archived). BTW, while doing so, I'm adding a pointer to a chromium bug with some more background on PKI and digital signing (in Korea and elsewhere) : http://crbug.com/73226 (David has already found it and added a comment there :-)). Jungshik 2011/5/24 Ian Fette (イアンフェッティ) ife...@google.com I personally find this to be a very interesting and potentially useful proposals. One of the problems that we / the web face is a legal requirement faced by many Asian banks (esp. Korea) to digitally sign all transactions. To meet this requirement, they use ActiveX controls, as the platform doesn't really give them the primitives they need. This seems like it should give them what they need, but I would be very interested in knowing whether there's more that would be needed or whether this would actually suffice. The situation in Korea got a bit better recently in the sense that some banks (or government agencies) now have a Firefox extension (with an xpcom plugin), an npapi plugin, a Safari extension (on Mac OS only), and a Java applet in addition to ActiveX controls (I can do online banking on Linux and Mac ! :-)) . Obviously, this 'proliferation' of browser plugins is far from ideal and it'd be great if there's a standard set of API to do what these 'browser plugins' do. It would be good if we can figure out whether this is sufficient for e.g. Korean banking requirements, and if not, what else would be necessary. Does anyone have contacts with the relevant industry groups? Earlier in the thread, JeffH mentioned the following. The first two threads in his list are relevant to on-line banking/e-commerce/government service access in Korea and elsewhere. While that's sorta interesting, there's various use cases that've been mentioned in various places that the above proposed API doesn't necessarily address.. Web Sigining in Action http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0898.html Re: Web Sigining in Action http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0953.html JS crypto? (and ensuing thread) http://lists.w3.org/Archives/Public/public-webapps/2010AprJun/0605.html Re: Hash functions (and ensuing thread) http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/1041.html It looks like what David proposed seems to be a good start, but I'm afraid it's not sufficient yet to replace various browser-plugins/add-ons used for digital sigining and certificate management (as is done in Korea). For instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm copying to him) has the following proposal. http://html5.creation.net/webcrypto-api/ It covers the generation of cert request, cert import, smart card event handling (apparently, in China, smartcards are widely used for on-line banking) in addition to signing text. 'keygen' (codified in html5) appears to cover some of needs for cert request and cert issuance, but does not go all the way (to be useful). I also wonder what David's proposal has to do with another Mozilla effort in the area : https://wiki.mozilla.org/Labs/Secret Jungshik 2011/5/24 David Dahl dd...@mozilla.com - Original Message - From: Jungshik Shin (신정식, 申政湜) jungs...@google.com To: Ian Fette ife...@google.com Cc: David Dahl dd...@mozilla.com, WHATWG Proposals wha...@lists.whatwg.org, cha...@gmail.com Sent: Tuesday, May 24, 2011 2:36:01 PM Subject: Re: [whatwg] window.cipher HTML crypto API draft spec Great insight into the situation in Korea, thanks! It looks like what David proposed seems to be a good start, but I'm afraid it's not sufficient yet to replace various browser-plugins/add-ons used for digital sigining and certificate management (as is done in Korea). For instance, Channy Yun (who's the leader of Mozilla Koran user group: I'm copying to him) has the following proposal. http://html5.creation.net/webcrypto-api/ Thank you for the link. I need to read all of these ideas and specs. It covers the generation of cert request, cert import, smart card event handling (apparently, in China, smartcards are
Re: HTTP, websockets, and redirects
Hi Brian, All - I just checked Bugzilla and besides the two editorial type bugs (12510 and 13700), bug 13777 was filed against the Web Sockets API on August 15: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13777 Currently, there have been no followup comments on 13777 and I think it should be addressed before the LC is published. -Art Barstow On 8/25/11 2:31 PM, ext Brian Raymor wrote: On Wed, Aug 10, 2011 at 9:01 AM, Arthur Barstow art.bars...@nokia.com wrote: Hi All, Bugzilla now reports only 2 bugs for the Web Socket API [WSAPI] and I would characterize them both as editorial [Bugs]. As such, the redirect issue Thomas originally reported in this thread (see [Head]) appears to be the only substantive issue blocking WSAPI Last Call. As Art notes, the remaining bugs for the WebSocket API [WSAPI] can be characterized as editorial bugs. Microsoft has no objections to the requirement to fail non-101 responses such as redirects. If there are no further concerns in the working group related to this issue, then the current WebSocket API looks feature complete. I recommend that we publish a Last Call working draft and define a timetable to reach Candidate Recommendation. If anyone wants to continue discussing this redirect issue for WSAPI, I recommend using e-mail (additionally, it may be useful to also create a new bug in Bugzilla). As I understand it, the HyBi WG plans to freeze the Web Socket Protocol spec real soon now (~August 19?). -Art Barstow [WSAPI] http://dev.w3.org/html5/websockets/ [Head] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0474.ht ml [Bugs] http://www.w3.org/Bugs/Public/buglist.cgi?query_format=advancedshort _de sc_type=allwordssubstrshort_desc=product=WebAppsWGcomponent=We bSocket+API+%28editor%3A+Ian+Hickson%29longdesc_type=allwordssubstr longdesc=bug_file_loc_type=allwordssubstrbug_file_loc=status_white boar d_type=allwordssubstrstatus_whiteboard=keywords_type=allwordskeywo r ds=bug_status=NEWbug_status=ASSIGNEDbug_status=REOPENEDemailt ype1=substringemail1=emailtype2=substringemail2=bug_id_type=anyex actbug_id=votes=chfieldfrom=chfieldto=Nowchfieldvalue=cmdtype=d oitorder=Reuse+same+sort+as+last+timefield0-0-0=nooptype0-0- 0=noopvalue0-0-0= On 7/27/11 8:12 PM, ext Adam Barth wrote: On Mon, Jul 25, 2011 at 3:52 PM, Gabriel Montenegro gabriel.montene...@microsoft.comwrote: Thanks Adam, By discussed on some mailing list, do you mean a *W3C* mailing list? A quick search turned up this message: But I'm totally fine with punting on this for the future and just disallowing redirects on an API level for now. http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-March/031079. html I started that thread at Greg Wilkins' recommendation: This is essentially an API issue for the browser websocket object. http://www.ietf.org/mail-archive/web/hybi/current/msg06954.html Also, allowing the users to handle these explicitly implies that the API does not mandate dropping the connection. Currently, the API does not have this flexibility, nor does it allow other uses of non-101 codes, like for authentication. I understand the potential risks with redirects in browsers, and I thought at one moment we were going to augment the security considerations with your help for additional guidance. If websec has already worked on similar language in some draft that we could reuse that would be great, or, similarly, if we could work with you on that text. We can always add support for explicitly following redirects in the future. If we were to automatically follow them today, we'd never be able to remove that behavior by default. Adam -Original Message- From: Adam Barth [mailto:w...@adambarth.com] Sent: Sunday, July 24, 2011 13:35 To: Thomas Roessler Cc: public-ietf-...@w3.org; WebApps WG; Salvatore Loreto; Gabriel Montenegro; Art Barstow; François Daoust; Eric Rescorla; Harald Alvestrand; Tobias Gondrom Subject: Re: HTTP, websockets, and redirects This issue was discussed on some mailing list a while back (I forget which). The consensus seemed to be that redirects are the source of a large number of security vulnerabilities in HTTP and we'd like users of the WebSocket API to handle them explicitly. I'm not sure I understand your question regarding WebRTC, but the general answer to that class of questions is that WebRTC relies, in large part, on ICE to be secure against cross-protocol and voicehammer attacks. Adam On Sun, Jul 24, 2011 at 6:52 AM, Thomas Roesslert...@w3.orgwrote: The hybi WG is concerned about the following clause in the websocket API spec: When the user agent validates the server's response during the establish a WebSocket connection algorithm, if the status code received from the server is not 101 (e.g. it is a redirect), the user agent must fail the websocket connection. http://dev.w3.org/html5/websockets/ Discussion with the WG chairs: - this looks like a conservative attempt to lock down
Re: [selectors-api] Return an Array instead of a static NodeList
On Thu, Aug 25, 2011 at 7:17 PM, Jonas Sicking jo...@sicking.cc wrote: .push and .pop are generic and work on anything that looks like an Array. However they don't work on NodeList because NodeList isn't mutable. . . . None of these are *mutable* functions. Oh, right. I misunderstood you. Yes, obviously we wouldn't expose things like .push or .pop on NodeList, since they wouldn't make sense. But we should expose things like .forEach, etc. Any reason not to?
[Bug 13949] New: Fantastic geocities.com reference in the section on Cross-directory attacks!
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13949 Summary: Fantastic geocities.com reference in the section on Cross-directory attacks! Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#top OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Storage (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: i...@hixie.ch, m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/webstorage/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: Fantastic geocities.com reference in the section on Cross-directory attacks! Posted from: 170.171.1.5 User agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.8) Gecko/20100722 Firefox/3.6.8 -- 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: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]
On Fri, Aug 26, 2011 at 12:48 AM, Jonas Sicking jo...@sicking.cc wrote: The point is that if it's just a chapter in a larger spec, how do I know that there isn't other important information in the larger spec that I have to read in order to get a understanding of the full feature. The same applies if it's a standalone spec. Microdata is an example of a spec with so many dependencies on HTML5 that having it in its own spec is kind of silly: http://dev.w3.org/html5/md/Overview.html#dependencies A lot of features just aren't orthogonal. DOM mutation events are a great example of something that's tightly coupled to DOM operations, such that everything DOM-related needs to account for them, and it makes little sense to have them in a separate spec from DOM Core. Things like Traversal and Range could be in separate specs, but they're related enough and short enough that having them in Core also makes sense to me, and I think we should just go with whatever the editor finds most convenient. If they delay LC or we want them to progress faster for patent policy reasons, that's a separate story. I do think the HTML5 spec is ridiculously large and could use with being split up into several mostly independent chunks. A spec shouldn't be so large that you don't want to close the tab because it takes too long to reopen. But it also shouldn't be so small that you have to keep a dozen different tabs open to figure out anything nontrivial. CSS3 specs are far too small. I think DOM Core is currently in a reasonable middle ground where it's still fair to add more material to it if it's relevant, just not an excessive amount more. I'm not talking about authors, I'm talking about browser vendors. As someone looking to implement a spec, I'm very interested in knowing which parts of the spec has consensus and which ones doesn't. This is a separate issue. New features and old features have to go in the same drafts regardless, for sanity's sake. If we want to mark them up clearly, we have to do this whether they're in a big spec or a small spec.
Re: Request for participation in W3C widgets standard
Hi Ronny - to formally participate in the Web Applications WG, your company must first join the W3C and information about that process can be found in [1]. Re W3C widgets, I consider the v1 specs functionally complete with the exception of the Widget Update specs. See [2] for the status of the group's widget specs. The WG does have a Widgets Embedding spec in its charter. There hasn't been any formal work done on that spec although there is a wiki to gather links to related resources [3]. -Art Barstow [1] http://www.w3.org/Consortium/membership [2] http://www.w3.org/2008/webapps/wiki/PubStatus#Widget_Specifications [3] http://www.w3.org/2008/webapps/wiki/WidgetEmbedding On 8/25/11 4:37 PM, ext Ronny A Pena wrote: Hello W3C, My company is looking to become an active participant in the W3C widgets standard. We are a portal software company and we have a widget standard that is similar to this standard and OpenSocial Gadgets. We would like to participate as allowed by W3C in the requirements definition and standard definition. Also, We would love to be listed a user agent that is looking to support this standard in our 5.0 release. Please let me know what the process is for active participation. Regards, -- *Ronny A Pena */Senior Solution Architect /Backbase / Customer Experience Solutions T / 917-566-5222 E / ro...@backbase.com mailto:ro...@backbase.com W / www.backbase.com http://www.backbase.com 349 5th Ave, New York, NY 10016 Click here to register for our Webinar Series http://www.backbase.com/webinars/
[Bug 13951] New: Should be able to treat an image with caption as a unit
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13951 Summary: Should be able to treat an image with caption as a unit Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org In Word or whatever, you can give captions to images, and drag around the whole image-with-caption, resize it together with the image, etc. I'm thinking that special-casing figure and figcaption makes a lot of sense here. This is a future project, though. -- 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.
[Bug 13952] New: Specify selection change events
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13952 Summary: Specify selection change events Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DOM Range AssignedTo: dave.n...@w3.org ReportedBy: a...@aryeh.name QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org There are some events already here, but AFAIK not specced: selectstart, things like that? This needs to be researched. Ryosuke suggested that we should add properties to the events that tell you what sort of user action prompted the selection change, if any. Presumably those should be based on the Selection.modify keywords. -- 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.
[Bug 13953] New: Investigate the user-modify CSS property
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13953 Summary: Investigate the user-modify CSS property Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Gecko and WebKit both have user-modify CSS properties -- -moz-user-modify and -webkit-user-modify. I need to investigate these and see if they make sense to spec in some form. There are apparently extra values too, including write-only in Gecko and read-write-plaintext-only in WebKit. -- 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.
[Bug 13954] New: Define DOM mutation operations that automatically check for editability
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13954 Summary: Define DOM mutation operations that automatically check for editability Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Currently I do lots of DOM operations where I first check whether the nodes are editable/editing hosts/etc. This should be moved to some kind of wrapper, so that all DOM mutations in the spec are invoking some subroutine that does the checks. I'll still need to do editability checks elsewhere, but this will make them more idiot-proof. -- 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.
[Bug 13955] New: Add more notes!
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13955 Summary: Add more notes! Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org Some things in comments should really be moved to notes, too. -- 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.
[Bug 13956] New: Port tests to a form usable by browsers
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13956 Summary: Port tests to a form usable by browsers Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org -- 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.
[Bug 13957] New: Remove special handling for WebKit class on blockquote
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13957 Summary: Remove special handling for WebKit class on blockquote Product: WebAppsWG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: HTML Editing APIs AssignedTo: a...@aryeh.name ReportedBy: a...@aryeh.name QAContact: sideshowbarker+html-editing-...@gmail.com CC: m...@w3.org, public-webapps@w3.org The definition of simple indentation element allows it to have a class, for compat with WebKit's automatically-added webkit-indent-blockquote class. Now that WebKit no longer produces that class, we should scrap the special case. -- 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.
Some way to change an element's name would be useful
In editing, it's common to want to change an element's name. For instance, document.execCommand(formatblock, false, h1) will change the current line's wrapper to an h1. Unbolding b id=foo should produce span id=foo. My editing spec defines an algorithm for this http://aryeh.name/spec/editing/editing.html#set-the-tag-name which is used in a bunch of places. The thing is, one requirement for editing is that you want to preserve the user's selection. Real-world use-case: some editors want to produce strong instead of b for bold. One way to do this is to let the browser create b tags via the bold command, then iterate through them all and change them to strong. But this will involve removing the b element from the DOM, and if the selection was inside it, it will now be collapsed outside it. There's no way for the author to avoid this except manually saving and restoring the selection with fixups. And that won't work either for ranges other than the selection. We can't actually change the tag name of the node in place, because then it will have to implement a different interface in general. But we could have a setTagName() method that creates a new Element with the given tag name, moves the children, copies the attributes, puts it in the right place, fixes up the Ranges, then returns the newly-created Element. Does this seem reasonable to anyone, or is it too confusing that the object will be different?
Re: Some way to change an element's name would be useful
On Aug 29, 2011, at 20:57 , Aryeh Gregor wrote: We can't actually change the tag name of the node in place, because then it will have to implement a different interface in general. But we could have a setTagName() method that creates a new Element with the given tag name, moves the children, copies the attributes, puts it in the right place, fixes up the Ranges, then returns the newly-created Element. Does this seem reasonable to anyone, or is it too confusing that the object will be different? I've often had a need for this, and I agree that it would be useful. It certainly is confusing that it returns a different object but maybe we can alleviate that problem somewhat with a different method? Not to bikeshed, but setTagName() sounds like you're setting a property of a given object, which makes the object change confusing. Perhaps something like renameElement() would be clearer? Or getRenamedElement()? For completeness, I'm guessing that namespaces would be supported as well? Element renameElement(DOMString newName); Element renameElement(DOMString newNS, DOMString newName); -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Some way to change an element's name would be useful
On 8/29/11 3:33 PM, Robin Berjon wrote: For completeness, I'm guessing that namespaces would be supported as well? Element renameElement(DOMString newName); Element renameElement(DOMString newNS, DOMString newName); Shades of http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode -Boris
Re: Some way to change an element's name would be useful
On Mon, Aug 29, 2011 at 3:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: Shades of http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode That has some good catches I hadn't thought of -- it preserves event handlers and custom JS attributes too.
Re: Some way to change an element's name would be useful
On Mon, Aug 29, 2011 at 4:29 PM, Aryeh Gregor a...@aryeh.name wrote: On Mon, Aug 29, 2011 at 3:40 PM, Boris Zbarsky bzbar...@mit.edu wrote: Shades of http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode That has some good catches I hadn't thought of -- it preserves event handlers and custom JS attributes too. The behavior of sometimes working in-place and sometimes replacing the element is very evil, though. It should always replace the element. -- Glenn Maynard
Re: Some way to change an element's name would be useful
On Aug 29, 2011, at 21:40 , Boris Zbarsky wrote: On 8/29/11 3:33 PM, Robin Berjon wrote: For completeness, I'm guessing that namespaces would be supported as well? Element renameElement(DOMString newName); Element renameElement(DOMString newNS, DOMString newName); Shades of http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode Yeah, but my recollection is that renameNode() is in the list of DOM things that are so hopelessly fuzzy that you probably don't want to touch them if you plan on being interoperable. Rereading the description after not having touched it in years certainly reinforces that feeling. -- Robin Berjon - http://berjon.com/ - @robinberjon
Re: Some way to change an element's name would be useful
On 8/29/11 4:53 PM, Robin Berjon wrote: On Aug 29, 2011, at 21:40 , Boris Zbarsky wrote: On 8/29/11 3:33 PM, Robin Berjon wrote: For completeness, I'm guessing that namespaces would be supported as well? Element renameElement(DOMString newName); Element renameElement(DOMString newNS, DOMString newName); Shades of http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode Yeah, but my recollection is that renameNode() is in the list of DOM things that are so hopelessly fuzzy that you probably don't want to touch them if you plan on being interoperable. Rereading the description after not having touched it in years certainly reinforces that feeling. Sure. I wasn't exactly endorsing it; just pointing to previous attempts to spec such a thing in case they would be useful. -Boris
Re: Some way to change an element's name would be useful
Document.renameNode seems cool. Aside from the awkward user data event, it matches perfectly the needs of the Component Model (updated to reference it here: http://wiki.whatwg.org/wiki/Component_Model#Performance). I am curious why no one had implemented this. We should dust it off, add a normal event to it, and set it sail. :DG On Mon, Aug 29, 2011 at 2:07 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 8/29/11 4:53 PM, Robin Berjon wrote: On Aug 29, 2011, at 21:40 , Boris Zbarsky wrote: On 8/29/11 3:33 PM, Robin Berjon wrote: For completeness, I'm guessing that namespaces would be supported as well? Element renameElement(DOMString newName); Element renameElement(DOMString newNS, DOMString newName); Shades of http://www.w3.org/TR/DOM-Level-3-Core/core.html#Document3-renameNode Yeah, but my recollection is that renameNode() is in the list of DOM things that are so hopelessly fuzzy that you probably don't want to touch them if you plan on being interoperable. Rereading the description after not having touched it in years certainly reinforces that feeling. Sure. I wasn't exactly endorsing it; just pointing to previous attempts to spec such a thing in case they would be useful. -Boris
Re: Reference to the HTML specification
On Tue, 2011-08-16 at 23:59 +0200, Anne van Kesteren wrote: On Thu, 04 Aug 2011 17:47:53 +0200, Philippe Le Hegaret p...@w3.org wrote: Several documents in the WebApps Working Group are linking to HTML, more specifically to the WHATWG HTML specification. An example of those is Progress Events. This is done for no reason than political as far as I can tell. They used to link to both, but that changed because I changed publishing tools. Now you want us to link solely to the W3C version I thought of a problem. The dependency chain for WHATWG HTML becomes WHATWG HTML - XMLHttpRequest - W3C HTML. That makes little sense I think. Can we change it back to linking to both the W3C and WHATWG version? 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. Philippe
[Bug 13967] New: Webkit implementation does not use the second argument 'targetOrigin',
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13967 Summary: Webkit implementation does not use the second argument 'targetOrigin', Product: WebAppsWG Version: unspecified Platform: Other URL: http://www.whatwg.org/specs/web-apps/current-work/#int roduction-15 OS/Version: other Status: NEW Severity: normal Priority: P3 Component: Web Messaging (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://www.whatwg.org/specs/web-apps/current-work/complete/web-messaging.html Multipage: http://www.whatwg.org/C#introduction-15 Complete: http://www.whatwg.org/c#introduction-15 Comment: Webkit implementation does not use the second argument 'targetOrigin', Posted from: 24.6.123.36 User agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/535.2 (KHTML, like Gecko) Chrome/15.0.862.0 Safari/535.2 -- 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: [selectors-api] Return an Array instead of a static NodeList
On 30/08/11 4:40 AM, Aryeh Gregor wrote: Oh, right. I misunderstood you. Yes, obviously we wouldn't expose things like .push or .pop on NodeList, since they wouldn't make sense. But we should expose things like .forEach, etc. Any reason not to? I should point out that on platform array objects (i.e., the JS objects you get from IDL T[] types, and not JS Array objects) can be designated as read only but they always have Array.prototype in their prototype chain. push/pop/etc. will just fail or do nothing, depending on whether the caller is in strict mode.
