[Bug 16534] New: give me a demo on php pleaseeeeeeeeeeeeeeeee!
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16534 Summary: give me a demo on php please! 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: WebSocket API (editor: Ian Hickson) AssignedTo: i...@hixie.ch ReportedBy: contribu...@whatwg.org QAContact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Specification: http://dev.w3.org/html5/websockets/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: give me a demo on php please! Posted from: 180.168.167.219 User agent: Mozilla/5.0 (Windows NT 6.2; rv:11.0) Gecko/20100101 Firefox/11.0 -- Configure bugmail: https://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: Where should UA insert text when the focus is changed in a keypress event handler?
Ryosuke Niwa rn...@webkit.org skreiv Tue, 20 Mar 2012 18:54:11 +0100 We're trying to figure out inside which element the editing operation must be done when a keypress event handler changes the focused element / selection for https://bugs.webkit.org/show_bug.cgi?id=81661. Should it be done at wherever focus is after keypress event is dispatched? Or whatever keypress event's target was? FWIW, Opera does #1 - inserts character in the newly focused input. I recall bugs where typing bank account numbers/pin codes and such on pages where a script changed focus automatically failing, so I believe that compatibility problems has shaped our implementation. This doesn't mean we'll never change it again, but it does mean we will thread carefully.. According to a fellow WebKit contributor, WebKit and Internet Explorer use the current focused element whereas Firefox uses the event target. This statement is a bit confusing because I have a few tests here where Chrome uses the event target.. :-o so it's WebKit and Gecko versus Trident and Presto in terms of behaviour. data:text/html,input autofocus onkeypress=i2.focus()input id=i2 Typing a character inserts the character in the first input even though focus is changing. -- Hallvord R. M. Steen Core tester, Opera Software
Re: StreamBuilder threshold
On Thu, Feb 23, 2012 at 12:58 PM, Feras Moussa fer...@microsoft.com wrote:
This isn't clear from the spec (And I've made a note to clarify it) but
URLs for
streams should be one time use URLs (once used it should be automatically
revoked).
Is it always possible to define that in a sane way?
For example, what if you write
var url = createObjectURL(stream);
element.innerHTML = video src=' + url + '/videovideo src=' + url
+ '/video;
or
var url = createObjectURL(stream);
document.getElementsByTagName(style)[0].textContent =
body, div { background:url( + url + ); };
Basically I don't think the exact moment a URL is used is a well-defined
concept in our current specs.
Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others? [Matthew 5:43-47]
Re: [FileAPI] createObjectURL isReusable proposal
On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch wrote: Anything's possible, but I think the pain here would far outweigh the benefits. There would be some really hard questions to answer, too (e.g. what would innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). We could define that it returns an empty src attribute, which would break the copy/paste example. That's the same behavior you'd get with someone revoking the URL upon load anyway. That's what I want to do when assigning a MediaStream to a media element's src DOM attribute. https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html It seems to me to be the least bad option. Having DOM state that's not reflected in the serialized DOM (or copied by cloneNode()) is not good, but it's not new either. Form elements, canvases, and media elements already have similar issues. Rob -- “You have heard that it was said, ‘Love your neighbor and hate your enemy.’ But I tell you, love your enemies and pray for those who persecute you, that you may be children of your Father in heaven. ... If you love those who love you, what reward will you get? Are not even the tax collectors doing that? And if you greet only your own people, what are you doing more than others? [Matthew 5:43-47]
Re: [FileAPI] createObjectURL isReusable proposal
On 27.3.2012 11:43, Robert O'Callahan wrote: On Tue, Feb 14, 2012 at 5:56 PM, Jonas Sicking jo...@sicking.cc wrote: On Thu, Feb 2, 2012 at 4:40 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: Anything's possible, but I think the pain here would far outweigh the benefits. There would be some really hard questions to answer, too (e.g. what would innerHTML return? If you copied such an image from a contentEditable section and pasted it lower down the same section, would it still have the image?). We could define that it returns an empty src attribute, which would break the copy/paste example. That's the same behavior you'd get with someone revoking the URL upon load anyway. That's what I want to do when assigning a MediaStream to a media element's src DOM attribute. https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html It seems to me to be the least bad option. Having DOM state that's not reflected in the serialized DOM (or copied by cloneNode()) is not good, but it's not new either. Form elements, canvases, and media elements already have similar issues. Which does not mean, that it does not matter... And the issue is different here, because all canvases behave the same, all forms behave the same, but here some images copies would produce actual image (http://) some would not (blob://). It would be much better to actually copy the Blob URL in src attribute and let it be dereferenced (it would either be succesfull or not, but it's based on programmer's design) Brona
[Bug 16534] give me a demo on php pleaseeeeeeeeeeeeeeeee!
https://www.w3.org/Bugs/Public/show_bug.cgi?id=16534 Art Barstow art.bars...@nokia.com changed: What|Removed |Added Status|NEW |RESOLVED CC||art.bars...@nokia.com Resolution||INVALID -- Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
Reminder: RfC: LCWD of Web Workers; deadline April 3
Original Message Subject:RfC: LCWD of Web Workers; deadline April 3 Resent-Date:Tue, 13 Mar 2012 14:34:30 + Resent-From:public-webapps@w3.org Date: Tue, 13 Mar 2012 10:33:38 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org This is a Request for Commentsfor the March 13 version of the Last Call Working Draft of Web Workers: http://www.w3.org/TR/2012/WD-workers-20120313/ The comment deadline is April 3 and all comments should be sent to the public-webapps@w3.org list.
Reminder: RfC: LCWD of Web Workers; deadline April 3
Original Message Subject:RfC: LCWD of Web Workers; deadline April 3 Resent-Date:Tue, 13 Mar 2012 14:34:30 + Resent-From:public-webapps@w3.org Date: Tue, 13 Mar 2012 10:33:38 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org This is a Request for Commentsfor the March 13 version of the Last Call Working Draft of Web Workers: http://www.w3.org/TR/2012/WD-workers-20120313/ The comment deadline is April 3 and all comments should be sent to the public-webapps@w3.org list.
[no subject]
l cannot access google apps business, l try to check my domain but not responding and it bring out all these Can't connect to server:[Exception... "Not enough arguments [nsIXMLHttpRequest.send]" nsresult: "0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)" location: "JS frame :: https://www.google.com/a/cpanel/resources/js/signup_bin.js :: _checkDomain :: line 33" data: no]plesae help l want to sign up for google collaboration for business
[xhr] statusText is underdefined
The spec says: Return the HTTP status text. But the HTTP status text is a sequence of bytes, while the return value for statusText is a DOMString. The conversion from one to the other needs to be defined. -Boris
Re: HELP
Wrong list. But for the sake of web crawlers: send may require an argument in some implementations. Use null. Such as: xhr.send(null); And for other readers, this message I'm replying to may be spam. Intelligent noise. -Charles On Mar 27, 2012, at 1:15 AM, joseph godwin cgodwin4...@yahoo.com wrote: l cannot access google apps business, l try to check my domain but not responding and it bring out all these Can't connect to server: [Exception... Not enough arguments [nsIXMLHttpRequest.send] nsresult: 0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS) location: JS frame :: https://www.google.com/a/cpanel/resources/js/signup_bin.js :: _checkDomain :: line 33 data: no] plesae help l want to sign up for google collaboration for business
Re: [xhr] statusText is underdefined
Is this really a problem? HTTP defines the form and encoding of the status text, and WebIDL/ES defines the form and encoding of DOMString. Adding an explicit conversion definition seems redundant and overspecified. I would argue the same for all other cases in the spec where it calls out an explicit (and unnecessary) conversion. On Tue, Mar 27, 2012 at 3:23 PM, Boris Zbarsky bzbar...@mit.edu wrote: The spec says: Return the HTTP status text. But the HTTP status text is a sequence of bytes, while the return value for statusText is a DOMString. The conversion from one to the other needs to be defined. -Boris
Re: [xhr] statusText is underdefined
On 3/27/12 2:46 PM, Glenn Adams wrote: Is this really a problem? Yes. We've run into bug reports in the past of sites sending some pretty random bytes in the HTTP status text, then reading .statusText from script. If we want interop here, we need to define the conversion. HTTP defines the form and encoding of the status text Except it doesn't, last I checked. Has that changed? -Boris
Re: [xhr] statusText is underdefined
On 3/27/12 3:35 PM, Glenn Adams wrote: The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. I believe that does not actually match server reality, unfortunately... -Boris
Re: [xhr] statusText is underdefined
On Tue, Mar 27, 2012 at 4:17 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/27/12 2:46 PM, Glenn Adams wrote: Is this really a problem? Yes. We've run into bug reports in the past of sites sending some pretty random bytes in the HTTP status text, then reading .statusText from script. If we want interop here, we need to define the conversion. HTTP defines the form and encoding of the status text Except it doesn't, last I checked. Has that changed? RFC2616 states (on pages : Fielding, et al. Standards Track [Page 39] Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF Fielding, et al. Standards Track [Page 40] Reason-Phrase = *TEXT, excluding CR, LF Fielding, et al. Standards Track [Page 15] The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. TEXT = any OCTET except CTLs, but including LWS This makes it pretty clear that Reason Phrase must use ISO-8859-1 (Latin1) unless it uses the encoded-word extension from RFC2047. If the latter is used, then a charset must be designated. Given this, I don't see any spec bug (though there may be implementation bugs in case the client side does not correctly implement the above HTTP requirements).
Re: [xhr] statusText is underdefined
On 3/27/12 3:36 PM, Boris Zbarsky wrote: On 3/27/12 3:35 PM, Glenn Adams wrote: The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. I believe that does not actually match server reality, unfortunately... And one more thing. Even the text you quoted does not define what happens if the rules from RFC 2047 are followed incorrectly (e.g. declaring a UTF-8 encoding but then having byte sequences that are not valid UTF-8 in the data). The behavior needs to actually be defined here for all values of the status text, whichever spec that happens in. -Boris
Re: [xhr] statusText is underdefined
On Tue, Mar 27, 2012 at 4:38 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 3/27/12 3:36 PM, Boris Zbarsky wrote: On 3/27/12 3:35 PM, Glenn Adams wrote: The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT MAY contain characters from character sets other than ISO- 8859-1 [22] only when encoded according to the rules of RFC 2047 [14]. I believe that does not actually match server reality, unfortunately... And one more thing. Even the text you quoted does not define what happens if the rules from RFC 2047 are followed incorrectly (e.g. declaring a UTF-8 encoding but then having byte sequences that are not valid UTF-8 in the data). The behavior needs to actually be defined here for all values of the status text, whichever spec that happens in. Since there are so may places in XHR, HTML5, etc., that interact with HTTP semantics, it would be better to define this in one place for all uses, and not attempt to redefine at every place where conversion to DOMString occurs. DRY.
Re: [xhr] statusText is underdefined
On 3/27/12 4:00 PM, Glenn Adams wrote: Since there are so may places in XHR, HTML5, etc., that interact with HTTP semantics, it would be better to define this in one place for all uses Sounds good to me. It just needs to be defined (and the definition linked to from the statusText definition, of course). -Boris
File API oneTimeOnly is too poorly defined
I didn't realize this was actually added to the spec: The optional options dictionary argument contains a key, oneTimeOnly that defaults to false. If set to true, then the first time the Blob URI is dereferenced, user agents MUST automatically revoke that Blob URI without needing a call to revokeObjectURL() on the Blob URI. What does dereferenced mean? Where is it defined? What happens if two XHR calls open() a blob URL one after the other (causing fetches to be queued for it in separate task queues, whose order of execution is undefined)? What happens if two completely unrelated APIs queue tasks in different task queues (causing the same problem, but in a way that can't be worked around within any one spec)? This feature is dangerously weakly defined. It should be removed from the spec until it can be defined properly (or at least marked not ready for implementations), or we may end up with interop failures that could be hard to fix later. Again, I'm pretty sure the sanest way to approach this feature is for any API supporting it to grab a reference to the underlying resource, and revoke the URL, as soon as the string enters that API (eg. xhr.open() is called, or img.src is assigned). That ensures it's always deterministically--and synchronously--clear who will actually successfully receive the object, regardless of later complications like separate task queues across APIs. It doesn't answer all questions (eg. the issues mentioned at http://lists.w3.org/Archives/Public/public-webapps/2012JanMar/1265.html), and the actual dereferencing action would need to be specified for every supported API (this would need work to make it easy to do), but it's a lot closer than what's in there now. -- Glenn Maynard
[Bug 8406] Stricter Specifications on Mouse Events Specifically primary, auxillary, and secondary default actions
https://www.w3.org/Bugs/Public/show_bug.cgi?id=8406 Sirisian warcraftthre...@sbcglobal.net changed: What|Removed |Added Status|VERIFIED|REOPENED Resolution|FIXED | --- Comment #16 from Sirisian warcraftthre...@sbcglobal.net 2012-03-28 00:44:52 UTC --- Someone brought up some confusion in the buttons member for MouseEvent. This is regarding the behavior of MouseEvent with multiple devices. Not sure if it's possible, but could you explicitly state that the MouseEvent buttons property represents the binary ORed result of all mouse device buttons. As an example if a person have both a laptop trackpad and a USB mouse if they hold both primary mouse buttons and release one the bit for the primary mouse button will still be set. -- Configure bugmail: https://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: Feedback requested for UndoManager and DOM Transaction
Hi, I've moved my draft to W3C repository at http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html At this point, I'd like the editing community group to be in charge of this proposal. - Ryosuke On Mon, Dec 5, 2011 at 11:44 PM, Ryosuke Niwa rn...@webkit.org wrote: Greetings all, As you maybe all aware, I've been working with developers of CKEditor, TinyMCE, and Google Docs along with developers from WebKit, Mozilla, and Opera on new UndoManager and DOM Transaction specificationhttp://rniwa.com/editing/undomanager.html for the last several months. And it's about time I ask for feedback from broader audience! Why? Because *undo and redo are broken on the Web today*. Whenever Web apps try to add a custom editing operation without using execCommand or do a fix up after browser executes a user editing action, user agents get confused by DOM mutations made by the apps and won't be able to undo or redo user editing actions and execCommand. This forces Web apps to re-implement undo and redo themselves, and in fact, *many rich text editors store innerHTML of* *a contenteditable element* as a string in their internal undo transaction history (a.k.a undo stack). There is also no way for Web apps to add new undo items and populate undo and redo menus on user agent's native UI. In addition, if an editor app has a widget with input/textarea, then the undo stack of the editor gets confused when the widget goes away because the undo transaction history exists only per document. In order to solve above and numerous other problems, we've come to a conclusion that we need to *add UndoManager and DOM Transaction*. *UndoManager* is an interface for managing *undo transaction history*. It exists on a document and an element with the undoscope content attribute. The main purpose of UndoManager is to communicate the list of undoable items with the user agent so that the user agent can provide a native UI (e.g. populating menu items with them). A *DOM transaction* is a sequence of DOM mutations that can be applied, unapplied, or reapplied. There are two types of DOM transactions: - *Automatic DOM transaction* - Only the logic to make the initial DOM changes is supplied by the author, and the user agent takes care of undo an redo. It is *compatible with user editing actions and editing commands*, and allows Web apps to easily do custom editing operations or fix up DOM after user editing actions. - *Manual DOM transaction* - Web apps specify logics to apply, unapply, and reapply the transaction and *takes the full control of undo and redo*. This transaction is useful for apps such as collaborative editor or canvas drawing apps that need to implement custom logic for undo and redo. You can see more concrete definitions of UndoManager and Transaction at: https://rniwa.com/editing/undomanager.html and see a list of uses cases at http://wiki.whatwg.org/wiki/UndoManager_Problem_Descriptions. I consider the current proposal to be ready for implementation feedback, and as such, I plan to prototype it in WebKit and give my own feedback as well. I sincerely request for your feedback on the proposal, and I will answer any question(s) you may have about the proposal. Best regards, Ryosuke Niwa Software Engineer Google Inc.
