Re: Mutation events replacement

On Wed, Jun 29, 2011 at 9:11 PM, Jonas Sicking wrote: > Heh. It's like spec people has to deal with the same complexities as > implementors has had for years. Revenge at last!! :) Yeah, as specs get more detailed, writing them is kind of like writing a mini-implementation. Except spec authors g

Re: Mutation events replacement

On Tue, Jul 5, 2011 at 2:23 PM, Boris Zbarsky wrote: > That's a pretty fuzzy concept when > http://wiki.ecmascript.org/doku.php?id=harmony:generators are involved, say. Yes, granted, there will be corner-cases. I don't know enough about ES5 (let alone Harmony) to have an informed opinion on how

Re: Test suites and RFC2119

On Mon, Jul 4, 2011 at 5:47 AM, Rich Tibbett wrote: > We currently define tests in test suites for SHOULD requirements. A problem > occurs when those tests are used to gauge the overall compliance of an > implementation to the full test suite. An implementation could theoretically > be 100% compli

Re: Mutation events replacement

On Wed, Jul 6, 2011 at 1:14 AM, James Robinson wrote: >  No browser updates the rendering after invoking every single task, but I'm > pretty sure that no modern browser updates the rendering at any other time. Testcase: http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1063 I can conf

Re: [WebIDL] Exceptions

On Wed, Jul 6, 2011 at 7:06 AM, Anne van Kesteren wrote: > So with Web IDL going to Last Call does this mean that the exception model > outlined in http://www.w3.org/Bugs/Public/show_bug.cgi?id=10623#c8 is the > way forward? I.e. we introduce new exception interfaces in DOM Core for all > the diff

Re: [WebIDL] Exceptions

On Wed, Jul 6, 2011 at 9:46 PM, Brendan Eich wrote: > Gecko is buggy if it is using the dynamic scope. Please file that bug and cc: > me. Gecko says the exception is an instanceof the DOMException object that corresponds to *any* window. So e instanceof window1.DOMException and also e instanceo

Re: [WebIDL] Exceptions

On Thu, Jul 7, 2011 at 2:28 PM, Jonas Sicking wrote: > It's a pain since it forces us to try to coordinate codes across > multiple specifications, working groups and standards organizations. > So far this has failed resulting in multiple specifications defining > their own exception types with ove

Re: [WebIDL] Exceptions

On Thu, Jul 7, 2011 at 3:47 PM, Ian Hickson wrote: > Anything that allows us to _not_ coordinate is an epic disaster, IMHO. > > We absolutely should be coordinating. How else can we ensure the platform > is a consistent platform? > > This is a feature, not a bug. Maybe, but I still think the .cod

Re: [WebIDL] Exceptions

On Fri, Jul 8, 2011 at 3:56 PM, Ian Hickson wrote: > If the proposal is to make all exceptions have a "name" property (or > whatever we call it) whether in ES, in DOM, or anywhere else, and to have > everyone pick consistent exception names, then I'm fine with that. If we > do do that then I'd sti

Re: Test suites and RFC2119

On Sun, Jul 10, 2011 at 3:59 PM, Charles McCathieNevile wrote: > Privacy and security restrictions leap to mind. There are things that really > are "should" requirements because there are valid use cases for not applying > them, and no reason to break those cases by making the requirement a "must"

Re: Test suites and RFC2119

On Sun, Jul 10, 2011 at 5:04 PM, Charles McCathieNevile wrote: > Not quite. I'm saying that there are cases where violoating the requirement > is reasonable, so test results shouldn't determine simple conformance. > > On the other hand, where these are things that in *most* cases we want > interop

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 1:43 AM, David Flanagan wrote: > Finally, I still think it is worth thinking about trying to model the > distinction between removing nodes from the document tree and moving them > (atomically) within the tree. I'll chip in that I think this is useful. It makes things som

Re: Mutation events replacement

On Wed, Jul 20, 2011 at 3:11 PM, Ryosuke Niwa wrote: > But internally, a node movement is a removal then an insertion.  There's > always possibility that a node gets removed then inserted again after > mutation observers are invoked.  Also, what happens if a function removed a > bunch of nodes and

Re: Mutation events replacement

On Thu, Jul 21, 2011 at 4:21 PM, Boris Zbarsky wrote: > I'd really like numbers.  Having looked at the Gecko editor code in the > past, I don't share your assurance that this is how it works > > That said, if you point to a workload, I (or anyone else; it's open source!) > can probably generat

Re: Mutation events replacement

On Fri, Jul 22, 2011 at 11:54 AM, Boris Zbarsky wrote: > Actually, you can pretty easily do it in the other order (move the text into > the , and then put the in the DOM), and may want to so as to minimize > the number of changes the the live DOM; that's something that's often > recommended as a

More use-cases for mutation events replacement

When discussing mutation events use-cases, mostly so far people have been talking about editors. However, I think mutation event replacements would have a much more general appeal if they were easily usable in certain cases with little performance impact. Specifically, one use-case I've run into

Re: [From-Origin] on "theft"

On Sat, Jul 23, 2011 at 10:04 AM, Glenn Adams wrote: > I would suggest not using the word "theft", even if placed in quotes. Call > it bandwidth "leeching" or something like that. It certainly is by no means > "theft" by any reasonable definition. "Theft" is a broad term that can informally encom

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

On Thu, Jul 21, 2011 at 1:02 PM, Adrian Bateman wrote: > For platform features that directly affect web developers' pages that might > sometimes be true. However, compression is also optional in HTTP and it > doesn't appear to have caused problems or made some sites work and others > not based on

Re: [websockets] Making optional extensions mandatory in the API (was RE: Getting WebSockets API to Last Call)

On Mon, Jul 25, 2011 at 4:58 PM, Adrian Bateman wrote: > First, I don't think that's the same thing at all. Why not? > Second, the IETF HyBi working > group has asked members of this working group for Last Call feedback. If you > think the protocol has the wrong mix of required/optional features

Re: More use-cases for mutation events replacement

On Mon, Jul 25, 2011 at 11:12 PM, Sean Hogan wrote: > I assume you are referring to the NodeWatch proposal from Microsoft. > > 1st draft: >    http://www.w3.org/2008/webapps/wiki/Selector-based_Mutation_Events > > 2nd draft: > >  http://www.w3.org/2008/webapps/wiki/MutationReplacement#NodeWatch_.2

Re: Element.create(): a proposal for more convenient element creation

On Mon, Aug 1, 2011 at 9:33 PM, Maciej Stachowiak wrote: > In an IRC discussion with Ian Hickson and Tab Atkins, we can up with the > following idea for convenient element creation: > Element.create(tagName, attributeMap, children…) >    Creates an element with the specified tag, attributes, and c

Re: Element.create(): a proposal for more convenient element creation

On Tue, Aug 2, 2011 at 2:05 PM, Tab Atkins Jr. wrote: > Read again - the idea is to auto-expand arrays. > > (I don't have much of a preference between "just use an array" and > "use varargs, but expand arrays".  I agree that using only varargs > without expansion would be bad.) I'm against "use v

Re: CfC: publish new WD of DOM Core; deadline August 10

On Wed, Aug 3, 2011 at 10:12 AM, Arthur Barstow wrote: > Anne would like to publish a new WD of DOM Core and this is a Call for > Consensus (CfC) to do so: > >  http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html > > Agreeing with this proposal: a) indicates support for publishing a new WD; >

Re: CfC: publish new WD of XMLHttpRequest Level 2; deadline August 10

On Wed, Aug 3, 2011 at 10:15 AM, Arthur Barstow wrote: > Anne would like to publish a new WD of XMLHttpRequest Level 2 and this is a > Call for Consensus (CfC) to do so: > >  http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ > > Agreeing with this proposal: a) indicates support for publishing a new

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

On Thu, Aug 11, 2011 at 6:28 AM, Arthur Barstow wrote: > Before we publish a new WD of Anne's DOM spec, I would like comments on how > the DOM specs should be organized. In particular: a) whether you prefer the > status quo (currently that is DOM Core plus D3E) or if you want various > additional

Re: Rescinding the DOM 2 View Recommendation?

On Fri, Aug 12, 2011 at 7:42 AM, Arthur Barstow wrote: > Anne, Ms2ger, All - can you live with adding a note to D2V rather than going > down the rescind path? I'm fine with having prominent notices in obsolescent standards pointing readers to the up-to-date work. If rescinding is too much of a h

Re: [indexeddb] Handing negative parameters for the advance method

On Fri, Aug 12, 2011 at 6:16 PM, Jonas Sicking wrote: > Yup. Though I think WebIDL will take care of the handling for when the > author specifies a negative value. I.e. WebIDL will specify what > exception to throw, so we don't need to. Similar to how WebIDL > specifies what exception to throw if

Re: [IndexedDB] Transaction Auto-Commit

On Mon, Aug 15, 2011 at 11:23 PM, Shawn Wilsher wrote: > On 8/3/2011 10:33 AM, Jonas Sicking wrote: >> >> IndexedDB does however not allow readers to start once a writing >> transaction has started. I thought that that was common behavior even >> for MVCC databases. Is that not the case? Is it mor

Re: [selectors-api] Return an Array instead of a static NodeList

On Sun, Aug 21, 2011 at 1:52 PM, Julien Richard-Foy wrote: > Since Javascript 1.6, a lot of useful collection functions are defined for > Array [1]. Unfortunately, they can’t be used directly with results returned by > .querySelectorAll, or even .getElementsByTagName since these functions return >

Re: [selectors-api] Return an Array instead of a static NodeList

On Thu, Aug 25, 2011 at 2:33 AM, Jonas Sicking wrote: > That works, but what is the advantage? The same advantage as having those methods work for Array. :) They're useful for lots of stuff. > And .push/.pop or other mutating functions wouldn't work. Right. I'm only talking about the methods

Re: [selectors-api] Return an Array instead of a static NodeList

On Thu, Aug 25, 2011 at 7:17 PM, Jonas Sicking 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, obv

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 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

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 . Unbolding should produce . My editing spec defines an algorithm for this

Re: Some way to change an element's name would be useful

On Mon, Aug 29, 2011 at 3:40 PM, Boris Zbarsky 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

I filed a bug against DOM Core: http://www.w3.org/Bugs/Public/show_bug.cgi?id=13971

Re: [selectors-api] Return an Array instead of a static NodeList

On Tue, Aug 30, 2011 at 4:33 AM, Jonas Sicking wrote: > My point was that it was a mistake for querySelectorAll to return a > NodeList. It should have returned an Array. Sounds like people agree > with that then? I don't have a problem with that, if it can be changed safely. However, some things

Re: Some way to change an element's name would be useful

On Tue, Aug 30, 2011 at 4:44 PM, Karl Dubost wrote: > > Le 29 août 2011 à 14:57, Aryeh Gregor a écrit : >> In editing, it's common to want to change an element's name.  For >> instance, document.execCommand("formatblock", false, "h1") will change

Re: RfC: how to organize the DOM specs [Was: CfC: publish new WD of DOM Core]

On Sun, Sep 4, 2011 at 9:12 AM, Arthur Barstow wrote: > Some members of the group consider the D3E spec as the highest priority of > our DOM-related specs and they have put considerable resources into that > spec. Doug and Jacob will continue to lead that spec effort, and as I > understand it, a C

Re: before/after editaction

On Wed, Sep 7, 2011 at 5:47 AM, Olli Pettay wrote: > What happens if beforeeditaction tears down the document, or > changes the document significantly or closes the window etc. > (Those a generic problems with before* events) It shouldn't make any difference. The behavior of all the edit actions

Re: DOM4 not compatible with ACID3 tests

On Thu, Sep 8, 2011 at 8:14 PM, Tim Down wrote: > I'd suggest the DOM Range tests in ACID3 could be modified to test > against the newer WHATWG Range spec, which clears up some ambiguities > in the DOM 2 Range spec (there's one about what happens to Range > boundaries after a particular insertNode

[editing] Using public-webapps for editing discussion

For the last several months, I was working on a new specification, which I hosted on aryeh.name. Now we've created a new Community Group at the W3C to host it: http://aryeh.name/spec/editing/editing.html http://www.w3.org/community/editing/ Things are still being worked out, but one issue is wha

Re: [editing] Using public-webapps for editing discussion

On Wed, Sep 14, 2011 at 7:30 PM, Arthur Barstow wrote: > Since some related functionality was included (at one point) in the HTML5 > spec, it seems like we should ask the HTML WG for feedback on Aryeh's email. > > Aryeh told me there are some related bugs: > >  http://www.w3.org/Bugs/Public/show_b

Re: [editing] Using public-webapps for editing discussion

On Fri, Sep 16, 2011 at 1:44 PM, Charles Pritchard wrote: > I don't think it's malicious. But, Google has unprecedented control over > these W3C specs. > They are absolutely using that control to benefit their priorities. Google has exercised no control over my spec. I've written it entirely at

Re: [editing] Using public-webapps for editing discussion

On Mon, Sep 19, 2011 at 12:48 PM, Arthur Barstow wrote: > Aryeh - coming back to your question below ... > > Since you are the Chair of the HTML Editing APIs CG [CG], would you please > explain what you see as the relationship between the CG and WebApps > vis-à-vis the Editing spec? In particular,

Re: [editing] Using public-webapps for editing discussion

On Mon, Sep 19, 2011 at 12:48 PM, Arthur Barstow wrote: > Since you are the Chair of the HTML Editing APIs CG [CG], would you please > explain what you see as the relationship between the CG and WebApps > vis-à-vis the Editing spec? In particular, what role(s) do the CG and WG > have? I notice yo

Re: [editing] Using public-webapps for editing discussion

On Thu, Sep 22, 2011 at 7:33 AM, Arthur Barstow wrote: > It seems to me, that by virtue of using public-webapps, it does give WebApps > WG a role e.g. to at least comment on the CG's editing spec. [Whether such a > role is "official" or not is probably just "splitting hairs".] I absolutely would

Re: [editing] Using public-webapps for editing discussion

On Thu, Sep 22, 2011 at 1:04 PM, Charles Pritchard wrote: > Does it have to be an either-or situation? Given that there are pressures to > publish in REC, to have a version which follows various procedures, it seems > plausible that the two can coexist. That's true, but there's no rush to create

Re: [editing] Using public-webapps for editing discussion

On Thu, Sep 22, 2011 at 2:44 PM, Arthur Barstow wrote: > It appears you are intentionally using "comments" here to differentiate > "contributions". Is that right? Right. > I ask because, as I understand the CG process: before a person can make a > contribution to a CG spec, they must agree to a

Re: [editing] Using public-webapps for editing discussion

On Fri, Sep 23, 2011 at 4:09 PM, Arthur Barstow wrote: > With this understanding, and having not noticed any objections to Aryeh's > proposal, I think we should consider Aryeh's proposal as accepted. Thank you. I've updated the spec and will use this list accordingly in the future: http://dvcs.

Re: Disabling non-collapsed selection

(sorry for the delay in responding, I was on vacation for about ten days) On Sat, Oct 15, 2011 at 1:51 PM, Ryosuke Niwa wrote: > Is there an interest in providing a way to prevent non-collapsed selection > under some node in a document? And if there is, what are use cases? > Authors periodically

Re: Disabling non-collapsed selection

On Mon, Oct 24, 2011 at 11:08 AM, Aryeh Gregor wrote: > As far as I know, the use-case is to prevent users from copying text > easily. . . . although on second thought, why would authors want to allow collapsed selections, then? Maybe I'm just confused.

Re: CfC: publish a Candidate Recommendation of DOM 3 Events; deadline October 21

On Fri, Oct 21, 2011 at 4:42 PM, Ms2ger wrote: > However, *I do object to the publication* of this specification because the > inappropriate resolution of the following issues (in no particular order): > > First (issue 123), it contradicts an uncontested requirement [1] in DOM4 > forbidding the mi

Re: HTML Editing APIs is already in scope [Was: Re: Draft Minutes: 31 October 2011 f2f meeting]

On Tue, Nov 8, 2011 at 9:17 AM, Arthur Barstow wrote: > My summary is: although HTML Editing APIs is in scope for WebApps, and we > agreed to use public-webapps for related discussions [1], given no one has > agreed to actively drive the spec in WebApps, we will not include it as an > explicit del

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Mon, Nov 21, 2011 at 11:34 AM, Boris Zbarsky wrote: > The sticking point here is obviously item #2.  Data needed on use of > "matches" and "is" as barewords in on* attributes, specifically. I don't follow. matchesSelector is on Element, not Node, right? Why is it relevant to on* attributes?

Re: window.find already exists

On Mon, Nov 21, 2011 at 11:29 AM, Tab Atkins Jr. wrote: > That only interferes if .find() for selectors is defined on window. > qSA is only defined on Document and Element, though, and I see no > reason that .find wouldn't be the same. So then we get another built-in method that will do different

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Mon, Nov 21, 2011 at 8:54 PM, Tab Atkins Jr. wrote: > You're not misunderstanding, but you're wrong.  ^_^  The element > itself is put in the lookup chain before document.  See this testcase: > > > foo > > (namespaceURI was the first property I could think of that's on > Element but not Docume

Re: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Tue, Nov 22, 2011 at 12:19 AM, Yehuda Katz wrote: > I like .is, the name jQuery uses for this purpose. Any reason not to go with > it? We might want it for something else. .matches clearly sounds like it's selector-related, and I have more trouble thinking of another meaning we'd ever really

Re: Adding methods to Element.prototype WAS: [Selectors API 2] Is matchesSelector stable enough to unprefix in implementations?

On Tue, Nov 22, 2011 at 1:04 PM, Boris Zbarsky wrote: > Again, some decent data on what pages actually do in on* handlers would be > really good.  I have no idea how to get it.  :( Can't browsers add instrumentation for this? You have users who have opted in to sending anonymized data. So for e

Re: XPath and find/findAll methods

On Tue, Nov 22, 2011 at 7:08 PM, Jonas Sicking wrote: > This expression finds all elements which has at least 6 > descendants and where an odd number of those elements have a > "data-foo" attribute equal to its parents "data-bar" attribute. It is > obviously trivial to add arbitrary additional

Affiliation change

This is just a heads-up that as of the new year, I'm contracting for Mozilla instead of Google. I'll continue to work on specifications and tests as before, in particular including the HTML Editing specification.

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 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 ta

Re: Pressing Enter in contenteditable: or or ?

On Fri, Jan 6, 2012 at 9:57 PM, Ojan Vafai 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 as a line separator at all, because it's also used as a block-level wrapper, while is specifically meant

Re: [editing] Feedback Link?

On Sun, Jan 8, 2012 at 2:28 PM, Doug Schepers 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 l

Re: Pressing Enter in contenteditable: or or ?

On Tue, Jan 10, 2012 at 3:50 PM, Ryosuke Niwa wrote: > p has default margins. That alone is enough for us not to adopt p as > the default paragraph separator. On Wed, Jan 11, 2012 at 5:15 AM, Simon Pieters wrote: > Sure, but some apps like to send their stuff in HTML email to clients that > don'

Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements

On Tue, Jan 10, 2012 at 4:48 PM, Charles Pritchard wrote: > Would users press Esc to get out of the tab lock? Do they need to be able to get out of it? They can't in a regular word processor, so why should they be able to in Google Docs? If some users need to be able to override the feature, th

[editing] Avoiding selections with no corresponding range, to simplify authoring

Anne asked me to investigate how exactly Ranges are added to Selections (bug: https://www.w3.org/Bugs/Public/show_bug.cgi?id=15470). It turns out browsers mostly don't interoperate. One interesting thing I found out is that in Gecko, if no one calls addRange/removeRange/removeAllRanges, rangeCoun

Re: [editing] Avoiding selections with no corresponding range, to simplify authoring

On Wed, Jan 11, 2012 at 12:27 PM, Ryosuke Niwa wrote: > Does gecko returns a Range at (document, 0) for getRange(0) in such cases? Okay, it looks like my testing before was off. Actually, all browsers have no range in the selection initially. But I was testing in Live DOM Viewer, which didn't f

Re: Pressing Enter in contenteditable: or or ?

On Wed, Jan 11, 2012 at 12:38 PM, Ryosuke Niwa wrote: > That sounds like a great idea. > > . . . > > I'm not sure if we should add just "editoptions" though given we might need > to add more elaborative options in the future. It might make more sense to > add a new attribute per option as in: > >

Re: Pressing Enter in contenteditable: or or ?

On Wed, Jan 11, 2012 at 3:15 PM, Ryosuke Niwa wrote: > That sounds workable. Presumably it's only available on the editing host (as > supposed to any element or any element with contenteditable content > attribute). Right.

Selection of a document that doesn't have a window

What does document.implementation.createHTMLDocument("").getSelection() return? * IE9 returns a Selection object unique to that document. * Firefox 12.0a1 and Opera Next 12.00 alpha return the same thing as document.getSelection(). * Chrome 17 dev returns null. I prefer IE's behavior just for the

Re: [editing] tab in an editable area WAS: [whatwg] behavior when typing in contentEditable elements

On Wed, Jan 11, 2012 at 3:09 PM, Charles Pritchard wrote: > The reason is listed in WCAG2 section 2.1.2 and CR5. > http://www.w3.org/TR/WCAG/ > > The items suggest that a standard means of moving focus be maintained. Users > should be given simple instructions on how to move focus if the keyboard

Re: Pressing Enter in contenteditable: or or ?

On Thu, Jan 12, 2012 at 4:58 AM, Hallvord R. M. Steen wrote: > Probably a stupid question, but one I've always wanted to ask: couldn't we > default to a different, smaller, possibly 0 margin for P when in editable > content? As Markus says: it breaks WYSIWYG. The idea of contenteditable is you c

Re: Selection of a document that doesn't have a window

On Fri, Jan 13, 2012 at 12:34 PM, Boris Zbarsky wrote: > I would prefer a definition that doesn't involve defaultView, actually.  I > don't expect browsers to converge defaultView behavior any time in the near > or medium future, so the testability would be illusory: tests would just > depend on w

Re: Selection of a document that doesn't have a window

On Thu, Jan 12, 2012 at 3:07 PM, Ojan Vafai wrote: > Can you do anything useful with a selection on a document that doesn't have > a window? If so, the IE9 behavior makes sense. If not, I prefer the WebKit > behavior. Per spec, you can add any Range at all to a Selection, so you can programmatica

Re: Selection of a document that doesn't have a window

On Fri, Jan 13, 2012 at 5:12 PM, Ojan Vafai wrote: > We could define it in terms of defaultView (or browsing context) and put our > effort into getting interoperability on defaultView? This is what I've done for now: http://dvcs.w3.org/hg/editing/rev/4dc4d65cc87e At least behavior is pretty cle

Re: [editing] input event should have a data property WAS: [D3E] Where did textInput go?

On Wed, Apr 4, 2012 at 10:07 PM, Ojan Vafai wrote: > The original proposal to drop textInput included that beforeInput/input > would have a data property of the plain text being inserted. Aryeh, how does > that sound to you? Maybe the property should be called 'text'? 'data' is > probably too gene

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

On Wed, May 2, 2012 at 3:56 AM, Ryosuke Niwa wrote: > That might make sense given how confusing these before* are. > > On the other hand, there are use cases to communicate enabledness of cut, > copy, & paste with UA. Maybe we can address this use case by letting > websites override > queryCommand

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

On Wed, May 2, 2012 at 9:04 AM, Ryosuke Niwa wrote: > That's a good point. What would be a viable alternative then? The use-case is "disable cut/copy/paste and also hide those options from context menus", right? I think these are two separate features. First, you want to prevent the action from

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

On Wed, May 2, 2012 at 9:27 AM, Ryosuke Niwa wrote: > Sounds like beforecut, beforecopy, and beforepaste suffice then... Maybe > these events are useful after all. I think they're useful, but very badly named -- authors will think they fire before every cut, copy, and paste. So while it's normal

Re: Clipboard API spec should specify beforecopy, beforecut, and beforepaste events

On Wed, May 2, 2012 at 4:57 PM, Boris Zbarsky wrote: > I would think that disabling cut/copy/paste would apply to main menus too, > not just context menus.  Most people I know who use menus for this (which is > precious few, btw, for the most part people I know seem to use keyboard > shortcuts for

Re: [editing] input event should have a data property WAS: [D3E] Where did textInput go?

On Thu, May 3, 2012 at 12:44 AM, Ojan Vafai wrote: > As I've said before, I don't think command/value should be restricted to > contentEditable beforeInput/input events. I don't see any downside to making > command, value and text all available for all three cases. It simplifies > things for autho

Re: [selectors-api] NAMESPACE_ERR or SYNTAX_ERR when both applied

On Sun, Jun 17, 2012 at 4:43 PM, Boris Zbarsky wrote: > On 6/17/12 9:33 AM, Anne van Kesteren wrote: >> >> Always throwing SyntaxError is probably better. > > > Also probably incompatible with a depth-first recursive descent parser > implementation.  Are we sure we want to overconstrain implementa

Re: [IndexedDB] Problems unprefixing IndexedDB

On Thu, Aug 9, 2012 at 3:53 PM, Robin Berjon wrote: > Trying to evangelise that something is experimental is unlikely to succeed. > But when trying out a new API people do look at the console a lot (you tend > to have to :). It might be useful to emit a warning upon the first usage of > an expe

Re: [IndexedDB] Problems unprefixing IndexedDB

On Fri, Aug 10, 2012 at 5:47 AM, Glenn Maynard wrote: > That makes it impossible for *anyone* to avoid breakage (unless they add the > unprefixed version before unprefixing happens). You're exchanging avoidable > breakage for unavoidable breakage, which doesn't make sense. It's not unavoidable.

Re: Feedback requested for UndoManager and DOM Transaction

Belatedly: for the record, I'm fine with that. I've appointed Ryosuke a co-chair of the HTML Editing APIs Community Group. On Wed, Mar 28, 2012 at 7:01 AM, Ryosuke Niwa wrote: > Hi, > > I've moved my draft to W3C repository at > http://dvcs.w3.org/hg/undomanager/raw-file/tip/undomanager.html > >

Re: [XHR] Open issue: allow setting User-Agent?

(I noticed people talking about this on IRC and commented, and zcorpan pointed me to this thread.) On Tue, Oct 16, 2012 at 7:08 PM, Boris Zbarsky wrote: > The point is that a browser can act as if every single server response > included "Vary: User-Agent". And perhaps should. Intermediary cache

Re: [editing] defaultParagraphSeparator

Sorry for the delayed response -- I've been busy with other things and didn't have time to check my e-mail. Thanks a lot for the feedback and questions! On Mon, Feb 4, 2013 at 9:59 PM, Alex Mogilevsky wrote: > There was a discussion here a while ago on desired default behavior for > Enter in con

Re: [editing] Is this the right list to discuss editing?

On Tue, Feb 19, 2013 at 11:26 AM, Ms2ger wrote: > FWIW, Aryeh is currently studying full time and doesn't follow web standards > discussions regularly. I do check them from time to time, though, and will check any personal e-mail I receive for the time being. In particular, I'm happy to answer a

Re: [editing] defaultParagraphSeparator

On Fri, Feb 22, 2013 at 2:42 AM, Alex Mogilevsky wrote: > Thanks for background, it helps a lot. I don't see a need to comment it by > point so let me just reference it [1] and try to summarize. > > 1. There is no consensus on what the default should be. There are >implementations favoring ea

Re: [editing] nested contenteditable

On Tue, May 28, 2013 at 8:27 PM, Travis Leithead wrote: > As far as I know, there is no actively maintained editing spec at the > moment. Aryeh’s document is a great start but by no means should it be > considered complete, or the standard to which you should target an > implementation… I think we

Re: [editing] nested contenteditable

On Sat, Jun 1, 2013 at 1:27 AM, Ojan Vafai wrote: > The main use case I can think of for mixed editability is an image with a > caption. If anyone has other use-cases, that would be helpful in reasoning > about this. http://jsfiddle.net/UAJKe/ A video with JavaScript controls comes to mind. An

Re: [editing] Multiple ranges in a single selection support

On Mon, Aug 5, 2013 at 10:25 AM, Mihnea-Vlad Ovidenie wrote: > I would like to know more about the corner cases mentioned above and the > problems encountered when trying to implement this feature. Are they > documented somewhere I can take a look? The basic issue is that in ~100% of cases, the s

Re: [editing] nested contenteditable

On Sun, Dec 22, 2013 at 2:22 AM, Johannes Wilm wrote: > Hey, > is there any news on this or on content editable in general? Would it > be a better idea to just forget about contenteditable and instead > implement everything using javascript, the way Codemirror has done it > ( http://codemirror.net

Re: [Editing] Splitting Selection API Into a Separate Specification

On Fri, Mar 14, 2014 at 1:43 AM, Ryosuke Niwa wrote: > It appears that there is a lot of new features such as CSS regions and shadow > DOM that have significant implications on selection API, and we really need a > spec. for selection API these specifications can refer to. > > Thankfully, Aryeh

Re: [Editing] Splitting Selection API Into a Separate Specification

On Mon, Mar 17, 2014 at 1:59 PM, Robin Berjon wrote: > My understanding from talking to various people is that at least part of the > problem comes from the type of code that is currently deployed in the wild. > An awful lot of it works around browser inconsistencies not through feature > testing

Re: [editing] insertHorizontalRule into while its ancestor is non-editable

On Thu, Mar 20, 2014 at 6:38 PM, Marta Pawlowska wrote: > Specification details that lead me to my conclusions: > > https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#the-inserthorizontalrule-command > > -> step 2. If "p" is not an allowed child of the editing host of node, abort > these ste

Re: Spec'ing innerText (Was Re: [Editing] Splitting Selection API Into a Separate Specification)

On Fri, Apr 11, 2014 at 9:05 PM, Ryosuke Niwa wrote: > Thanks for the pointer. > > Unfortunately, we might need to take a slightly different approach more based > on the CSS box tree because whitespace collapsing, etc... are defined in > CSS2.1 and CSS level 3 specifications. As far as I know,

Re: [Editing] Splitting Selection API Into a Separate Specification

On Sat, Apr 12, 2014 at 7:29 AM, Boris Zbarsky wrote: > The outcome of that was basically that the WebKit folks wanted innerText to > be some sort of complicated prettyprinting thing (which is nothing like the > spec linked above) while Gecko was not all that interested in implementing a > complic

Re: [selection] [editing] Selection API Bugzilla is available

On Mon, Apr 21, 2014 at 9:19 PM, Ben Peters wrote: > The Selection API Bugzilla component [1] is now available for bugs in the > Selection API spec [2]. I propose that we move selection-related bugs from > the HTML Editing APIs spec [3] to this new component. Are there any > objections? If not,

Re: [clipboard events] click-to-copy support could be hasFeature discoverable?

On Wed, May 21, 2014 at 2:01 AM, Glenn Maynard wrote: > I think I'd suggest avoiding the mess of execCommand altogether, and add new > methods, eg. window.copy() and window.cut() (or maybe just one method, with > a "cut" option). execCommand is such a nonsensical way to expose an API > that tryin

  1   2   >