Re: [whatwg] Parsing processing instructions in HTML syntax: 10.2.4.44 Bogus comment state
On Wed, Mar 3, 2010 at 10:55 AM, Brett Zamir bret...@yahoo.com wrote: On 3/2/2010 6:54 PM, Ian Hickson wrote: On Tue, 2 Mar 2010, Elliotte Rusty Harold wrote: Briefly it seems that? causes the parser to go into Bogus comment state, which is fair enough. (I wouldn't really recommend that anyone use processing instructions in HTML syntax anyway.) However the parser comes out of that state at the first. Because processing instructions can contain and terminate only at the two character sequence ? this could cause PI processing to terminate early and leave a lot more error handling and a confused parser state in the text yet to come. In HTML4, PIs ended at the first, not at ?. ?target data is the syntax of PIs when the SGML options used by HTML4 are applied. In any case, the parser in HTML5 is based on what browsers do, which is also to terminate at the first. It's unlikely that we can change that, given backwards-compatibility needs. Are there really a lot of folks out there depending on old HTML4-style processing instructions not being broken? Yes, e.g. a load of pages like http://www.forex.com.cn/html/2008-01/821561.htm (to pick one example at random) say: ?xml:namespace prefix = o ns = urn:schemas-microsoft-com:office:office / and don't have the string ? anywhere. -- Philip Taylor exc...@gmail.com
[whatwg] Feature proposal - add method to CanvasRenderingContext2D
Hi, the subject says it all. Details follows. Description add overload of (or add similarly called) method createImageData to interface CanvasRenderingContext2D which would take two arguments: - encodedImageBinaryData - dataMimeType which are rather self explanatory. Reason The reason is to be able to supply output of the future File API standard (http://www.w3.org/TR/FileAPI/) into canvas. Use case Usually there is a lot of image processing during image upload. This processing takes place at the server and it can consume a lot of system resources. The method I propose would enable basic client side image processing by loading image to canvas tag. Then the modified image could be sent to server instead of the original one. This would save a lot of server's resources and sometimes even a lot of bandwidth. Another possibilities There are already solutions for this use case, but they are based on technologies like Flash or Silverlight. With this proposal, no plugin would be needed. -- František Řezáč Prague, Czech Republic
Re: [whatwg] Feature proposal - add method to CanvasRenderingContext2D
On Wed, Mar 3, 2010 at 1:08 PM, František Řezáč
frantisek.re...@calavera.info wrote:
Description
add overload of (or add similarly called) method createImageData to
interface CanvasRenderingContext2D which would take two arguments:
- encodedImageBinaryData
- dataMimeType
which are rather self explanatory.
Reason
The reason is to be able to supply output of the future File API
standard (http://www.w3.org/TR/FileAPI/) into canvas.
The canvas API already lets you do:
var img = new Image();
img.onload = function() {
ctx.drawImage(img, 0, 0);
// do processing on the canvas
};
img.src = 'data:image/png;base64,...'; // get this string from
readAsDataURL etc
Is that sufficient for your use case?
--
Philip Taylor
exc...@gmail.com
Re: [whatwg] Feature proposal - add method to CanvasRenderingContext2D
Yes, it works. I failed to spot that it's possible to put data url to
Image.src, sorry.
On Wed, Mar 3, 2010 at 3:33 PM, Philip Taylor excors+wha...@gmail.com wrote:
On Wed, Mar 3, 2010 at 1:08 PM, František Řezáč
frantisek.re...@calavera.info wrote:
Description
add overload of (or add similarly called) method createImageData to
interface CanvasRenderingContext2D which would take two arguments:
- encodedImageBinaryData
- dataMimeType
which are rather self explanatory.
Reason
The reason is to be able to supply output of the future File API
standard (http://www.w3.org/TR/FileAPI/) into canvas.
The canvas API already lets you do:
var img = new Image();
img.onload = function() {
ctx.drawImage(img, 0, 0);
// do processing on the canvas
};
img.src = 'data:image/png;base64,...'; // get this string from
readAsDataURL etc
Is that sufficient for your use case?
--
Philip Taylor
exc...@gmail.com
--
František Řezáč
Prague, Czech Republic
--
Mobile - personal: +420776161038
Mobile - work: +420725817361
Email - personal:
frantisek.re...@calavera.info
Email - work:
frantisek.re...@profinit.cz
Jabber IM (GTalk):
frantisek.re...@calavera.info
Skype: calavera.info
www: http://calavera.info
---
Ekonomové jsou politruci kapitalismu.
[whatwg] [html5] Attaching option elements to select elements in different documents
The algorithm in the HTML5 specification for attaching an option element to a select element is incomplete, because it doesn't describe how to handle the case where the option element does not belong to the same document as the select element. It seems that HTMLOptionElement objects are immune to WRONG_DOCUMENT_ERR exceptions on any tree modifications. Thus the HTML5 specification also needs to note that it is overriding the rules from DOM Core about what may be attached to what. I've written some proposed changes further below. As far as I can tell, this affects: HTMLSelectElement.add(), HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(), Node.insertBefore(). My tests show that this isn't even confined to the cases where the new parent node is an HTML select element - any cross-document attachment of option elements operates as though the same-document check has been bypassed. In fact, the behaviour I'm seeing looks very much like an implicit adoptNode() call has occurred. I'm basing that suspicion on a comparison of the (equally inconsistent) behaviour of adoptNode() in different browsers[*] I'm testing this from ECMAScript in my test page which is at: http://www.metahusky.net/~stewart/css/html-options/ In all browsers, if the insertion of the option succeeds, then the inserted option element compares strictly equal to the option in the receiving select element. i.e. the option tree has not been cloned. In some browsers, the [[Prototype]] of the HTMLOptionElement is reset to be HTMLOptionElement.prototype of the receiving document's script context; in others, it does not get changed. However, in all browsers, all the nodes in the option's subtree are affected similarly (i.e. if the option's [[Prototype]] changes, so does the text node's) In some browsers, you can only insert the option element if the option element is not currently attached to anything else. In some browsers, the option isn't inserted at the right index into the receiving select, but I think that must just be a different bug. I propose the following changes to the specification: Change 1: Renumber existing step 7 to step 8 and insert a new step 7 in http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#htmloptionscollection 7. If _element_ does not belong to the same document as _parent_, then act as if the DOM Core adoptNode() method was invoked on the _parent_ node's ownerDocument with _element_ as the parameter. [Aside: whilst in the vicinity, shouldn't step 3 be using node rather than element i.e. If _before_ is a *node*, but that *node* ...? Otherwise, I could legitimately insert it before any text node anywhere in the document. Should it require that _before_ has to be an option or optgroup?] Change 2: Append some text to section 2.2.1 (Conformance Requirements - Dependencies) to indicate the change to DOM Core, and include a link to the text added by change 3: Some requirements in this specification are a wilful violation of constraints imposed by the DOM Core specification [DOMCORE]: * attaching _option_ elements to different documents is permitted Change 3: append explanatory text, linked from change 2's text to: http://www.whatwg.org/specs/web-apps/current-work/multipage/the-button-element.html#the-option-element If any attempt is made to attach an _option_ element to a node in a Document other than the Document of the _option_ element, then the user agent must not throw a _WRONG_DOCUMENT_ERR_ exception. If the tree change would otherwise succeed, then the user agent must behave as if a call to the DOM Core adoptNode() method has been made so that the Document of the _option_ element is updated. This affects the DOM Core appendChild(), insertBefore() and replaceChild() methods. Actually, all of these changes might have to say _option_ or _optgroup_. [*] Opera 10.10, Chrome 5.0.307.11 beta, Firefox 3.5.8, and our own ANT Galio 3.1.0 -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
Was your testing done with option elements created with document.createElement(option) or new Option? I ask because I seem to recall the behavior being different for at least some types of elements. -- Darin
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
Darin Adler da...@apple.com wrote: Was your testing done with option elements created with document.createElement(option) or new Option? I ask because I seem to recall the behavior being different for at least some types of elements. That's a good idea - I forgot to test that. I've updated my test so that it tries both. The behaviour seems to be the same, regardless of how the option is created. -- Stewart Brodie Team Leader - ANT Galio Browser ANT Software Limited
Re: [whatwg] [html5] Attaching option elements to select elements in different documents
On 3/3/10 12:11 PM, Stewart Brodie wrote: As far as I can tell, this affects: HTMLSelectElement.add(), HTMLOptionsCollection.add(), Node.appendChild(), Node.replaceChild(), Node.insertBefore(). Is it option-specific, though? Last I checked, various browsers implicitly adopted on append/insert/replace, period. -Boris
Re: [whatwg] oninput for contentEditable
WebKit would like to implement this in the (very) near future. Before proceeding, we'd like to hear from other browser vendors that you're roughly on board with this direction of adding beforeinput and input events. Here are the changes I can think of that would result from this: 1) Fire input event for contentEditable areas as well as for text-entry form controls. 2) For every case where we'd fire input, add a new beforeinput event that fires before the DOM has been modified. 3) Add a new InputEvent interface with an action attribute to use for input and beforeinput events. 4) For events with an inserttext action attribute, also provide a data attribute that specifies the text being inserted. For other actions, data is the empty string. 5) input events may be batched as long as they have the same action. In the case of inserttext actions, the data attribute is the accumulation of text being inserted. One strange side effect here is that there may be multiple beforeinput events per input event fire, although it's not unlike having multiple keydown events before a single keyup. The list of actions still needs to be enumerated, but some obvious ones are inserttext, undo, redo, copy, paste, cut and drop. I also think we should get rid of the textInput event in deference to this more useful event, but that's a discussion we can have on www-dom once this is resolved. As far as I know, only WebKit currently implements textInput. Ojan On Tue, Jul 14, 2009 at 6:02 PM, Ian Hickson i...@hixie.ch wrote: On Tue, 23 Jun 2009, Ojan Vafai wrote: Currently, textareas and text inputs support the oninput event that fires on all user-initiated modifications to their content. We should add this event to contentEditable elements as well and add an action property the specifies what action the user took that caused the input event. I haven't yet added this. I think we should probably address the various problems with contenteditable all at once, to make sure the solution is coherent overall. I'm watching what happens with the mutation event changes and tracking proposals for various other changes to contentEditable. It may be that we need to defer these changes to after HTML5 reaches last call, though, and have them in a future version next year some time. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] WebSocket bufferedAmount includes overhead or not.
Hi, I noticed that WebSocket spec updated to not inlcude framing overhead in bufferedAmount. http://lists.whatwg.org/pipermail/commit-watchers-whatwg.org/2010/003971.html I tried to implement it in WebKit, but found it make hard to implement correctly. https://bugs.webkit.org/show_bug.cgi?id=35571 It's easy after WebSocket is closed (just add length of message), but while it's open, we'll manage buffer including frame bytes and underlying socket will write arbitrary length of the buffer (may not be on frame boundary) To get bufferdAmount correctly without framing overhead, we need to parse the buffer again. It's not light operation and it's challenge to make it effective. I think including frame overhead is much easier. Could you revert it? -- Fumitoshi Ukai
Re: [whatwg] oninput for contentEditable
On 3/3/10 9:31 PM, Daniel Danilatos wrote: Worth noting, the events should convey the user intent - so, e.g. not just delete chars 5 - 8 but forward word delete, which is chars 5 - 8. So I have to ask... Why are events _before_ the edit needed? If we add these, then you have to define what happens when those event handlers modify the state of the DOM in arbitrary ways, including carrying out operations that spin the event loop, operations that make the edit that's about to happen nonsensical, and so forth. It's a huge chunk of spec and implementation complexity. So I'd like to see some very compelling use cases to even consider it. -Boris
