Re: querySelectorAll() -- selecting _immediate_ children of element
This has actually been discussed quite a bit on this list, in various
contexts - for example see
http://lists.w3.org/Archives/Public/public-webapps/2011OctDec/0277.html(except
that you have to substitute :scope for your proposed :this).
Cheers,
- Roland
On Mon, Jan 9, 2012 at 23:46, Marat Tanalin | tanalin.com
mtana...@yandex.ru wrote:
querySelector() and querySelectorAll() methods are exciting features, but
they do not allow select _immediate_ children of reference element.
To address this lack, we could use following syntax:
var divs = refElement.querySelectorAll(' DIV');
Here 'divs' variable contains list of DIV elements that are immediate
children (not just descendant elements) of reference element (refElement).
This syntax is extremely intuitive and BTW is supported in jQuery.
Other combinators (e.g. adjacent-sibling combinator) would have sense too,
for example:
var span = h1.querySelector('+ H2 SPAN');
'span' variable here contains DOM reference to SPAN elements inside H2
element which is next sibling of H1 element:
h1.../h1
h2... span.../span .../h2
But fundamental missing demanded feature is ability to select _child_
elements of reference element ( querySelectorAll(' DIV') ).
Since usecases are purely script-level, CSSWG has nothing to do with this
syntax. From selectors perspective, there is nothing new here: we have
reference element (in CSS, a selector is used in place of concrete
element), standard selector (DIV), and standard combinator between them.
An acceptable alternative to implied reference element would be using
':this' pseudoclass:
var divs = refElement.querySelectorAll(':this DIV');
var span = h1.querySelector(':this + H2 SPAN');
Furthermore, :this pseudoclass would give us additional possibilities such
as selecting descendant elements via selectors _all_ parts of which matches
to descendants of reference element.
For example, following code will select all links that are descendants of
_any_ paragraph (not necessarily descendants of reference element):
refElement.querySelectorAll('P A');
As opposed, this code:
refElement.querySelectorAll(':this P A');
would select links that are inside of paragraphs which _themselves_ are
descendants of the reference element.
Probably most DRY, usable, and flexible solution would be to allow both
syntaxes: implied reference element to use with combinators (where :this
would be just redundant), and explicit :this to use in conjunction with
descendant selectors (where it really gives additional useful possibilities
missing in current querySelector spec and implementations).
Thanks.
P.S. The proposal has been originally posted in public-script-coord (
http://lists.w3.org/Archives/Public/public-script-coord/2012JanMar/0078.html)
but it seems public-webapps is probably more appropriate place for this.
Worry on Enum type - binding seems inconsistently defined
Hello, the WebRTC WG is currently contemplating following the WebApps WG's advice on avoiding use of integers in APIs, and switching to enums whenever possible. However, one detail makes the spec at this time a bit hard to understand: In section 3.5, the following is said: Note In the ECMAScript binding, assignment of an invalid string value to anattribute http://dev.w3.org/2006/webapi/WebIDL/#dfn-attributeis ignored, while passing such a value as anoperation http://dev.w3.org/2006/webapi/WebIDL/#dfn-operationargument results in an exception being thrown. However, in the ECMAScript binding, section 4.2.18, it says: An ECMAScript value V is converted to an IDL enumeration type value as follows (where E is the enumeration): 1. Let S be the result of calling ToString(V). 2. If S is not one of E's enumeration values, then throw a TypeError. 3. Return the enumeration value of type E that is equal to S. I'm not sure it says the same thing; more clarity on the expected behaviour would be useful. (My personal opinion is that it's most useful if assigment throws an exception; silent failure is rarely the best option.) Although other bindings don't really matter so much, I would also think that it was a Good Thing if the spec gave advice saying that all bindings should detect value errors at assignment time, and signal errors appropriately for that language, rather than leaving the decision to binding designers. That's all my worry Harald
[Bug 15494] New: author request headers: Content-Transfer-Encoding
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15494 Summary: author request headers: Content-Transfer-Encoding Product: WebAppsWG Version: unspecified Platform: All URL: http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#t he-setrequestheader%28%29-method OS/Version: All Status: NEW Severity: normal Priority: P3 Component: XHR AssignedTo: ann...@opera.com ReportedBy: julian.resc...@gmx.de QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org The list of author request headers mentions Content-Transfer-Encoding. This is confusing as there is no such header field in HTTP (there is one in email, though). -- 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.
[Bug 15495] New: I need some way of recovering from longer but still temporary failures, without requiring a complete page refresh, and without requiring every all events of interest to be rebound,
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15495 Summary: I need some way of recovering from longer but still temporary failures, without requiring a complete page refresh, and without requiring every all events of interest to be rebound, or otherwise handled differently from any other event. This isn't an issue 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: Server-Sent Events (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.w3.org/TR/eventsource/ Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: I need some way of recovering from longer but still temporary failures, without requiring a complete page refresh, and without requiring every all events of interest to be rebound, or otherwise handled differently from any other event. This isn't an issue with the WebSocket and XMLHttpRequest API's, as those interfaces already require one to implement an event passing scheme on top, making it trivial to replace the underlying WebSocket or XMLHttpRequest. While such a scheme could also be implemented on top of EventSource, it seems silly to stackan different event source scheme on top of something called EventSource. Posted from: 70.64.129.37 User agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/535.2 (KHTML, like Gecko) Ubuntu/10.04 Chromium/15.0.874.106 Chrome/15.0.874.106 Safari/535.2 -- 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: Speech Recognition and Text-to-Speech Javascript API - seeking feedback for eventual standardization
Art, Per #2 Editor commitment(s): we confirm that Bjorn Bringert, Satish Sampath and Glen Shires volunteer as editors. If others would like to help, we welcome them. Per #4 Testing commitment(s): can you elaborate on what you would like to see at this point? Also, what is the next step? On Mon, Jan 9, 2012 at 8:12 AM, Olli Pettay olli.pet...@helsinki.fi wrote: On 01/09/2012 04:59 PM, Arthur Barstow wrote: Hi All, As I indicated in [1], WebApps already has a relatively large number of specs in progress and the group has agreed to add some new specs. As such, to review any new charter addition proposals, I think we need at least the following: 1. Relatively clear scope of the feature(s). (This information should be detailed enough for WG members with relevant IP to be able to make an IP assessment.) 2. Editor commitment(s) 3. Implementation commitments from at least two WG members Is this really requirement nowadays? Is there for example commitment to implement File System API? http://dev.w3.org/2009/dap/**file-system/file-dir-sys.htmlhttp://dev.w3.org/2009/dap/file-system/file-dir-sys.html But anyway, I'm interested to implement the speech API, and as far as I know, also other people involved with Mozilla have shown interest. 4. Testing commitment(s) Re the APIs in this thread - I think Glen's API proposal [2] adequately addresses #1 above and his previous responses imply support for #2 but it would be good for Glen, et al. to confirm. Re #3, other than Google, I don't believe any other implementor has voiced their support for WebApps adding these APIs. As such, I think we we need additional input on implementation support (e.g. Apple, Microsoft, Mozilla, Opera, etc.). It doesn't matter too much to me in which group the API will be developed (except that I'm against doing it in HTML WG). WebApps is reasonably good place (if there won't be any IP issues.) -Olli Re the markup question - WebAppsdoes have some precedence for defining markup (e.g. XBL2, Widget XML config). I don't have a strong opinion on whether or not WebApps should include the type of markup in the XG Report. I think the next step here is for WG members to submit comments on this question. In particular, proponents of including markup in WebApps' charter should respond to #1-4 above. -AB [1] http://lists.w3.org/Archives/**Public/public-webapps/** 2011OctDec/1474.htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/1474.html [2] http://lists.w3.org/Archives/**Public/public-webapps/** 2011OctDec/att-1696/speechapi.**htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html On 1/5/12 6:49 AM, ext Satish S wrote: 2) How does the draft incorporate with the existing input speech API[1]? It seems to me as if it'd be best to define both the attribute as the DOM APIs in a single specification, also because they share several events (yet don't seem to be interchangeable) and the attribute already has an implementation. The input speech API proposal was implemented as input x-webkit-speech in Chromium a while ago. A lot of the developer feedback we received was about finer grained control including a javascript API and letting the web application decide how to present the user interface rather than tying it to the input element. The HTML Speech Incubator Group's final report [1] includes a reco element which addresses both these concerns and provides automatic binding of speech recognition results to existing HTML elements. We are not sure if the WebApps WG is a good place to work on standardising such markup elements, hence did not include in the simplified Javascript API [2]. If there is sufficient interest and scope in the WebApps WG charter for the Javascript API and markup, we are happy to combine them both in the proposal. [1] http://www.w3.org/2005/**Incubator/htmlspeech/XGR-**htmlspeech/http://www.w3.org/2005/Incubator/htmlspeech/XGR-htmlspeech/ [2] http://lists.w3.org/Archives/**Public/public-webapps/** 2011OctDec/att-1696/speechapi.**htmlhttp://lists.w3.org/Archives/Public/public-webapps/2011OctDec/att-1696/speechapi.html Thanks, Peter [1] http://lists.w3.org/Archives/**Public/public-xg-htmlspeech/** 2011Feb/att-0020/api-draft.**htmlhttp://lists.w3.org/Archives/Public/public-xg-htmlspeech/2011Feb/att-0020/api-draft.html On Thu, Jan 5, 2012 at 07:15, Glen Shires gshi...@google.com mailto:gshi...@google.com wrote: As Dan Burnett wrote below: The HTML Speech Incubator Group [1] has recently wrapped up its work on use cases, requirements, and proposals for adding automatic speech recognition (ASR) and text-to-speech (TTS) capabilities to HTML. The work of the group is documented in the group's Final Report. [2] The members of the group intend this work to be input to one or more working groups, in W3C and/or other standards development organizations such as the IETF, as
[Bug 15134] Please explain what the proper behavior of getSelection on a display:none iframe is
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15134 Aryeh Gregor a...@aryeh.name changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #1 from Aryeh Gregor a...@aryeh.name 2012-01-10 20:15:11 UTC --- Sorry for the long time to respond -- I was on vacation for a while, then spent a while doing other things. The editing spec says Every browsing context has a selection. http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections The HTML spec says When an iframe element is first inserted into a document, the user agent must create a nested browsing context. http://www.whatwg.org/specs/web-apps/current-work/multipage/the-iframe-element.html#the-iframe-element Thus the spec implies that any iframe in a document has a selection. Testing, this is how IE9, Chrome 17 dev, and Opera Next 12.00 alpha behave. Firefox 12.0a1 returns null from getSelection() if the iframe is display: none. I don't see any advantage to Gecko's behavior, so I'll stick with the behavior of the majority of browsers -- display: none should make no difference. Reopen if you don't think the spec is clear enough. -- 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: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements
On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai o...@chromium.org wrote: There are strong use-cases for both. In an app like Google Docs you certainly want tab to act like indent. In a mail app, it's more of a toss-up. In something like the Google+ sharing widget, you certainly want it to maintain normal web tabbing behavior. Anecdotally, gmail has an internal lab to enable document-like tabbing behavior and it is crazy popular. People gush over it. Hmm, good point. Google Docs definitely wants tab to indent. We should make this configurable via execCommand: document.execCommand(TabBehavior, false, bitmask); I'm leery of global flags like that, because they mean that if you have two editors on the same page, they can interfere with each other unwittingly. useCss/styleWithCss is bad enough; I've seen author code that just sets useCss or styleWithCss before every single command in case something changed it in between. Could the author just intercept the keystroke and run document.execCommand(indent) themselves? It's not as convenient, I admit. Alternatively, perhaps the flag could be set per editing host somehow, and only function when that editing host has focus, although I'm not sure what API to use. The bitmask is because you might want a different set of behaviors: -Tabbing in lists -Tabbing in table cells -Tabbing blockquotes -Tab in none of the above insert a tab -Tab in none of the above insert X spaces (X is controlled by the CSS tab-size property?) Bitmasks are bad -- many JavaScript authors don't understand binary well, if at all. Also, what are use-cases where you'd want to toggle indentation in all these cases separately? More complexity without supporting use-cases is a bad idea -- browsers have enough trouble being interoperable as it stands, and more complexity just makes it harder.
Re: [FileAPI] Blob protocol version - is this needed?
Greetings Adrian, Sorry for the delay in responding to this email. Strictly speaking, we could remove the Blob Protocol Version (BLV) [1]. It isn't returned in getAllResponseHeaders. BLV 's purpose was in case the protocol changes, and to differentiate between versions. But the protocol is internally consumed within the UA. I can remove it. --Original Message-- The current spec defines the Blob Protocol Version [1]. Our current implementation doesn't require a protocol version and the way protocol handlers are defined in Internet Explorer does require this. I don't know if this is ever exposed in the web platform. The spec says that this should be returned from XHR in getAllResponseHeaders [2] but I don't think XHR actually returns this string there. Please can someone help point me to where this is required? If it isn't exposed anywhere I think we can remove this section. Thanks, Adrian [1] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolName [2] http://dev.w3.org/2006/webapi/FileAPI/#ProtocolExamples
Re: Pressing Enter in contenteditable: p or br or div?
On Sun, Jan 8, 2012 at 11:57 PM, Simon Pieters sim...@opera.com wrote: On Sat, 07 Jan 2012 03:57:33 +0100, Ojan Vafai o...@chromium.org wrote: Different apps have different needs and it's crappy for them to have to handle enter themselves just to get a different block type on enter. Something like document.execCommand(**DefaultBlock, false, tagName). What values are valid for tagName are open to discussion. At a minimum, I'd want to see div, p and br. What is the use case for br that div doesn't cover? Single br tag is shorter than pairs of div tags when serialized. I'm tempted to say that any block type should be allowed, I strongly disagree. Supporting any block type opens up for lots of bugs and weird cases. We should only support the types necessary to cover presented use cases. Yeah, supporting arbitrary block element will complicate a lot of things especially because people can add display: inline as a css rule or in inline style declarations. - Ryosuke
[Bug 15509] New: Define HTTP handling of data URLs (and maybe other URLs)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=15509 Summary: Define HTTP handling of data URLs (and maybe other URLs) Product: WebAppsWG Version: unspecified Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P2 Component: XHR AssignedTo: ann...@opera.com ReportedBy: ann...@opera.com QAContact: member-webapi-...@w3.org CC: m...@w3.org, public-webapps@w3.org User agents start to allow fetching of data URLs in the context of XMLHttpRequest. That has implications for status/statusText/getResponseHeader()/getAllResponseHeaders(). Those implications need to be defined. Ideally in the data URL standard just like they are for blob URLs, but otherwise maybe in XMLHttpRequest for now. Henri also suggested adding a note to those four members to point out this issue to implementors. -- 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: Pressing Enter in contenteditable: p or br or div?
On Fri, Jan 6, 2012 at 9:57 PM, Ojan Vafai o...@chromium.org wrote: I'm OK with this conclusion, but I still strongly prefer div to be the default single-line container name. Why? I don't like using div as a line separator at all, because it's also used as a block-level wrapper, while p is specifically meant to wrap lines and br is specifically meant to separate them. I wish that UAs never generated div to wrap lines to start with -- it means that authors can't insert div-wrapped editable content without the risk that it will be interpreted as a line wrapper instead of a block wrapper. Also, I'd really like the default single-line container name to be configurable in some way. Different apps have different needs and it's crappy for them to have to handle enter themselves just to get a different block type on enter. What's a use-case for wanting div or br rather than p? Something like document.execCommand(DefaultBlock, false, tagName). I really don't want more document-global flags. If such a switch is added, it should be per editing host. What values are valid for tagName are open to discussion. At a minimum, I'd want to see div, p and br. As one proof that this is valuable, the Closure editor supports these three with custom code and they are all used in different apps. That's not proof that they're valuable, just that people will use them if given the option. What are examples of apps that use div and br? Do you know why they use them? I'm tempted to say that any block type should be allowed, but I'd be OK with starting with the tree above. For example, I could see a use-case for li if you wanted an editable widget that only contained a single list. As Simon says, making the list element itself contenteditable will work for that use-case. Then hitting Enter will make an li no matter what. On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons?
Re: [editing] Feedback Link?
On Sun, Jan 8, 2012 at 2:28 PM, Doug Schepers schep...@w3.org wrote: In the status section of the HTML Editing APIs spec [1], you have detailed instructions for how people should provide feedback, but the links you provide are to the pubic-webapps archive and to your personal email, rather than a mailto link to the list. It might be handy provide an encoded mailto link to make it easier for people to start a discussion, like this: a href=mailto:public-webapps@w3.org?cc=a...@aryeh.namesubject=%5Bediting%5D%20;discussion on the HTML Editing APIs specification/a (a href=http://www.w3.org/Search/Mail/Public/search?type-index=public-webappsindex-type=tkeywords=[editing];public-webapps archive/a) Thanks for the suggestion! I've made the change: http://dvcs.w3.org/hg/editing/rev/d278ee615900 http://dvcs.w3.org/hg/editing/raw-file/tip/editing.html
Re: Pressing Enter in contenteditable: p or br or div?
On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons? p has default margins. That alone is enough for us not to adopt p as the default paragraph separator. Also, unfortunately, there are many legacy contents that rely on the fact webkit uses div as the paragraph separator so we need a global or per editing-host switch regardless. I almost want a global switch to toggle between legacy UA-specific behavior and new spec-compliant behavior. - Ryosuke
Colliding FileWriters
Hi All, We've been looking at implementing FileWriter and had a couple of questions. First of all, what happens if multiple pages create a FileWriter for the same FileEntry at the same time? Will both be able to write to the file at the same time and whoever writes lasts to a given byte wins? This is different from how file systems normally work since as long as file is open for writing that tends to prevent other processes from opening the same file. A second question is why is FileEntry.createWriter asynchronous? It doesn't actually do any IO and so it seems like it could return an answer synchronously. Is the intended way for this to work that FileEntry.createWriter acts as a choke point and ensures that only one active FileWriter for a given FileEntry exists at the same time. I.e. if one page creates a FileWriter for a FileEntry and starts writing to it, any other caller to FileEntry.createWriter will wait to fire it's callback until the first caller was done with its FileWriter. If that is the intended design I would have expected FileWriter to have an explicit .close() function though. Having to wait for GC to free a lock is always a bad idea. Would this also explain why FileEntry.getFile is asynchronous? I.e. it won't call it's callback until all current FileWriters have been closed? These questions both apply to what's the intended behavior spec-wise, as well as what does Google Chrome do in the current implementation. / Jonas
File modification
Modern operating systems have efficient mechanisms to send a signal when a watched file or directory is modified. File and FileEntry have a last modified date-- currently we must poll entries to see if the modification date changes. That works completely fine in practice, but it doesn't give us a chance to exploit the efficiency of some operating systems in notifying applications about file updates. So as a strawman: a File.onupdated event handler may be useful. -Charles
Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements
On Jan 10, 2012, at 12:30 PM, Aryeh Gregor a...@aryeh.name wrote: On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai o...@chromium.org wrote: There are strong use-cases for both. In an app like Google Docs you certainly want tab to act like indent. In a mail app, it's more of a toss-up. In something like the Google+ sharing widget, you certainly want it to maintain normal web tabbing behavior. Anecdotally, gmail has an internal lab to enable document-like tabbing behavior and it is crazy popular. People gush over it. Hmm, good point. Google Docs definitely wants tab to indent. Would users press Esc to get out of the tab lock? We should make this configurable via execCommand: document.execCommand(TabBehavior, false, bitmask); I'm leery of global flags like that, because they mean that if you have two editors on the same page, they can interfere with each other unwittingly. useCss/styleWithCss is bad enough; I've seen author code that just sets useCss or styleWithCss before every single command in case something changed it in between. Could the author just intercept the keystroke and run document.execCommand(indent) themselves? It's not as convenient, I admit. Alternatively, perhaps the flag could be set per editing host somehow, and only function when that editing host has focus, although I'm not sure what API to use. The bitmask is because you might want a different set of behaviors: -Tabbing in lists -Tabbing in table cells -Tabbing blockquotes -Tab in none of the above insert a tab -Tab in none of the above insert X spaces (X is controlled by the CSS tab-size property?) Bitmasks are bad -- many JavaScript authors don't understand binary well, if at all. Also, what are use-cases where you'd want to toggle indentation in all these cases separately? More complexity without supporting use-cases is a bad idea -- browsers have enough trouble being interoperable as it stands, and more complexity just makes it harder. I don't like these being called tab, but, the use cases for standard navigation mechanisms for lists and grids make some sense. -Charles
Re: File modification
On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard ch...@visc.us wrote: Modern operating systems have efficient mechanisms to send a signal when a watched file or directory is modified. File and FileEntry have a last modified date-- currently we must poll entries to see if the modification date changes. That works completely fine in practice, but it doesn't give us a chance to exploit the efficiency of some operating systems in notifying applications about file updates. So as a strawman: a File.onupdated event handler may be useful. It seems like it would be most useful if the File or FileEntry points to a file outside the sandbox defined by the FileSystem spec. Does any browser currently supply such a thing? Chrome currently implements this [with FileEntry] only for ChromeOS components that are implemented as extensions. Does any browser let you have a File outside the sandbox *and* update its modification time? If you're dealing only with FileEntries inside the sandbox, there are already more efficient ways to tell yourself that you've changed something.
Re: File modification
On Jan 10, 2012, at 1:53 PM, Eric U er...@google.com wrote: On Tue, Jan 10, 2012 at 1:29 PM, Charles Pritchard ch...@visc.us wrote: Modern operating systems have efficient mechanisms to send a signal when a watched file or directory is modified. File and FileEntry have a last modified date-- currently we must poll entries to see if the modification date changes. That works completely fine in practice, but it doesn't give us a chance to exploit the efficiency of some operating systems in notifying applications about file updates. So as a strawman: a File.onupdated event handler may be useful. It seems like it would be most useful if the File or FileEntry points to a file outside the sandbox defined by the FileSystem spec. Does any browser currently supply such a thing? Chrome currently implements this [with FileEntry] only for ChromeOS components that are implemented as extensions. Does any browser let you have a File outside the sandbox *and* update its modification time? If you're dealing only with FileEntries inside the sandbox, there are already more efficient ways to tell yourself that you've changed something. Far as I can tell, File is live, and it's supposed to be live from input type=file. For FileEntry-- I'd imagine we'll see cross-origin communication with the objects at some point. In those cases, onupdated would be simpler than an additional postMessage layer for update notifications.
Re: Pressing Enter in contenteditable: p or br or div?
On Jan 10, 2012, at 12:50 PM, Ryosuke Niwa rn...@webkit.org wrote: On Tue, Jan 10, 2012 at 12:46 PM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Jan 10, 2012 at 3:40 PM, Ryosuke Niwa rn...@webkit.org wrote: Single br tag is shorter than pairs of div tags when serialized. True, but only slightly, and the difference is even smaller if you use p instead of div. This isn't enough of a reason by itself to justify the extra complexity of another mode. Are there other reasons? p has default margins. That alone is enough for us not to adopt p as the default paragraph separator. Also, unfortunately, there are many legacy contents that rely on the fact webkit uses div as the paragraph separator so we need a global or per editing-host switch regardless. I almost want a global switch to toggle between legacy UA-specific behavior and new spec-compliant behavior. - Ryosuke I've got a similar issue with copy/paste of HTML. If a switch were around for contentEditable, I might route through it on copy events in the page to tidy up some of the raw HTML clipboard. -Charles
Re: Colliding FileWriters
On Tue, Jan 10, 2012 at 1:08 PM, Jonas Sicking jo...@sicking.cc wrote: Hi All, We've been looking at implementing FileWriter and had a couple of questions. First of all, what happens if multiple pages create a FileWriter for the same FileEntry at the same time? Will both be able to write to the file at the same time and whoever writes lasts to a given byte wins? This isn't currently specified, and that's a hole we should fill. By not having it in the spec, my assumption would be that last-wins would hold, but it would be good to clarify it if that's the behavior we want. It's especially important given that there's nothing like fflush(), which would help users know what last meant. Speaking of which, should we add a flushing mechanism? This is different from how file systems normally work since as long as file is open for writing that tends to prevent other processes from opening the same file. You're perhaps thinking of windows, where by default files are opened in exclusive mode? On other operating systems, and on windows when you specify FILE_SHARE_WRITE in dwShareMode in CreateFile, multiple writers can exist simultaneously. A second question is why is FileEntry.createWriter asynchronous? It doesn't actually do any IO and so it seems like it could return an answer synchronously. FileWriter has a synchronous length property, just as Blob does, so it needs to do IO at creation time to look it up. Is the intended way for this to work that FileEntry.createWriter acts as a choke point and ensures that only one active FileWriter for a given FileEntry exists at the same time. I.e. if one page creates a FileWriter for a FileEntry and starts writing to it, any other caller to FileEntry.createWriter will wait to fire it's callback until the first caller was done with its FileWriter. If that is the intended design I would have expected FileWriter to have an explicit .close() function though. Having to wait for GC to free a lock is always a bad idea. Agreed re: GC, but currently in Chromium there is no choke point, and one can create multiple writers, which can stomp on each others' writes if that's what the user requests. That being said, we don't really hold files open right now, except during a write call. In between writes, we close the file, so while collisions are possible, more likely one write will win entirely. But we are opening the files in shared mode. Would this also explain why FileEntry.getFile is asynchronous? I.e. it won't call it's callback until all current FileWriters have been closed? Nope. It's asynchronous because a File is a Blob, and has a synchronous length accessor, so we look up the length when we mint the File. Note that the length can go stale if you have multiple writers, as we want to keep it fast. These questions both apply to what's the intended behavior spec-wise, as well as what does Google Chrome do in the current implementation. I'm personally OK with the current Chrome implementation, which does no locking. If users want transactional behavior, there are better ways to get that via databases. But I'm open to discussion.
Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements
On Tue, Jan 10, 2012 at 12:30 PM, Aryeh Gregor a...@aryeh.name wrote:
On Fri, Jan 6, 2012 at 10:12 PM, Ojan Vafai o...@chromium.org wrote:
We should make this configurable via execCommand:
document.execCommand(TabBehavior, false, bitmask);
I'm leery of global flags like that, because they mean that if you
have two editors on the same page, they can interfere with each other
unwittingly. useCss/styleWithCss is bad enough; I've seen author code
that just sets useCss or styleWithCss before every single command in
case something changed it in between.
Could the author just intercept the keystroke and run
document.execCommand(indent) themselves? It's not as convenient, I
admit. Alternatively, perhaps the flag could be set per editing host
somehow, and only function when that editing host has focus, although
I'm not sure what API to use.
I agree the API is not the best. We should put execCommand, et. al. on
Element. That would solve the global flag thing for useCss/styleWithCss as
well. It's also more often what a website actually wants. They have a
toolbar associated with each editing host. They don't want a click on the
toolbar to modify content in a different editing host. This is a change we
should make regardless of what we decide for tabbing behavior IMO.
Calling indent doesn't actually match tabbing behavior (e.g. inserting a
tab/spaces or, in a table cell, going to the next cell), right? I guess
another way we could approach this is to add document.execCommand('Tab')
that does the text-editing tabbing behavior. I'd be OK with that (the
command name could probably be better).
The bitmask is because you might want a different set of behaviors:
-Tabbing in lists
-Tabbing in table cells
-Tabbing blockquotes
-Tab in none of the above insert a tab
-Tab in none of the above insert X spaces (X is controlled by the CSS
tab-size property?)
Bitmasks are bad -- many JavaScript authors don't understand binary
well, if at all. Also, what are use-cases where you'd want to toggle
indentation in all these cases separately? More complexity without
supporting use-cases is a bad idea -- browsers have enough trouble
being interoperable as it stands, and more complexity just makes it
harder.
The bitmask is not a great idea, but there are certainly editors that would
want tabbing in lists to work, but tab outside of lists to do the normal
web tabbing behavior. Maybe you're right that we should just have one
toggle though and if you want something more specific you do it in JS.
Historically, one of my biggest frustrations with contentEditable is that
you have to take it all or none. The lack of configurability is frustrating
as a developer. Maybe the solution is to come up with a lower level set of
editing primitives in place of contentEditable instead of trying to extend
it though.
Ojan
[xhr] responseType for sync requests in window context
Got some reports of broken C/C++ = JS compilers that relied on sync XHR to load resources into an ArrayBuffer (simulating fopen), e.g. Mandreel and Enscripten. https://bugzilla.mozilla.org/show_bug.cgi?id=716765 https://bugs.webkit.org/show_bug.cgi?id=72154#c43 Is there additional scoping of the restriction we should consider? Thoughts? Jarred
