Re: oldNode.replaceWith(...collection) edge case
before/after/replaceWith behave the same in this case is just a side effect of DOM trying to be less surprising and more symmetrical for the curious ones. I doubt most people would even aware they behave the same in this case. Whenever the user cases come, I believe most people will just use replaceWith. On Jan 27, 2015, at 8:51 PM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jan 22, 2015 at 11:43 AM, Jonas Sicking jo...@sicking.cc wrote: In general I agree that it feels unintuitive that you can't replace a node with a collection which includes the node itself. So the extra line or two of code seems worth it. You don't think it's weird that before/after/replaceWith all end up doing the same for that scenario? Perhaps it's okay... -- https://annevankesteren.nl/
[Bug 27914] New: [Custom]: Typo instantation --- instantiation
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27914 Bug ID: 27914 Summary: [Custom]: Typo instantation --- instantiation Product: WebAppsWG Version: unspecified Hardware: PC OS: Windows NT Status: NEW Severity: normal Priority: P2 Component: Component Model Assignee: dglaz...@chromium.org Reporter: je...@livedata.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org Blocks: 14968 instantation looks like a typo -- instantiation likely intended. -- You are receiving this mail because: You are on the CC list for the bug.
[DOM3Events/UIEvents] Minutes from 27 Jan 2015 teleconference
Minutes logged at: http://www.w3.org/2015/01/28-webapps-minutes.html Previous minutes: https://www.w3.org/2008/webapps/wiki/Bi-weekly_meetings masayuki Travis: Hi masayuki garykac: Hi, garykac masayuki: Hello garykac Travis is having trouble with IRC. He's working on a fix right now. masayuki Oh, I see. We have a few things to follow up on from last meeting. Spec name change is one 3 bugs from Masayuki blocking Gecko progress Removal of beforeinput and friends from the spec garykac And renaming and moving the spec. garykac Oops! I see that was already mentioned Spec name change garykac: Not done yet. ... will do next. ... hesitated since there are redirects to old one, etc. ... renaming and moving to new URL? ... can't remember the details. ... Are we going to move it to D4E? ... [and other questions] So, latest TR published is here: http://www.w3.org/TR/DOM-Level-3-Events/ So, the shortname is DOM-Level-3-Events Editor's draft is here: https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html So, under HG's dom3events folder. garykac Basically, we need to agree on the exact order that we do things in. One thing we should do is re-publish the current spec with a re-direct to it's new home So, unordered list first :) * Modifiy Editor's draft to change name * Copy editor's draft new location garykac * Decide where the editor's draft should live: the current D3E, current UIE, or a new place * Change current published doc's editor's draft link to point to new location. * Publish new draft in TR with new name and valid links * Update bug database component name? garykac I'm going to dig up the email where this was last discussed to remind myself what it says... garykac Philip suggested publishing an updated version (new name) and having *both* shortnames point to it. OK, well, first step is probably modify editor's draft so that we can do that :-) As for location, where do we put the editor's draft? garykac We need to make sure that both ED links point to the correct editor's draft garykac I think it makes sense to keep using the dom3events location I don't mind the mercurial path staying D3E (vesus a new location or D4E) garykac OK. so that means that we rename dom3events in-place So, scrap the Copy editor's draft to new location garykac: New shortname? ... nope, it'll be UIEvents Do you want to change the name of the file in mercurial? garykac I don't think it's necessary, but we can do that later if we need to. garykac: I would avoid doing that now--we can always do it later. beforeinput removal garykac Next topic garykac I removed beforeinput and input from the spec. garykac But we still have a few links that need to be updated garykac But I don't have a real spec to link them to. garykac This makes me sad garykac I'm waiting until we have a real link before fixing them - I'm assuming that we can get the links soon. garykac Ben's unofficial spec is at: http://w3c.github.io/editing-explainer/input-events.html http://w3c.github.io/selection-api/ masayuki Where the input spec go to? .isComposing is important and useful. So, it should be defined by somebody. Oh, I don't think my link was right... masayuki Oh, I see, bad timing... garykac The link I sent is an unofficial draft, so I'd like to see a more semi-official draft before fixing up all the links. garykac masayuki: isComposing is part of the input spec garykac They took their initial draft from the work we did masayuki garykac: Yeah, thanks, I confirmed. 3 bugs for masayuki (a new children's story) j/k bug 24739, 26019 and 26218 masayuki I updated bug 26218 now. scribe: [familiarizing ourselves with the bugs again] masayuki Our Linux's module owner, karlt, doesn't like adding Super and Hyper to the modifier key, but I like them. garykac So, for 24739 garykac Which keys are missing to support the Sun keyboard? garykac Props is there... masayuki garykac: its label is Props. masayuki USB keycode indicates Menu. garykac vs. ContextMenu garykac So, do we need Menu and ContextMenu (with Props mapping to Menu)? masayuki But it's different from ContextMenu and Sun's keyboard also has ContextMenu key. Therefore, we should provide different name for Props. masayuki It will provide a way to distinguish the keys. garykac Sun has ContextMenu and Props. But if Props - Menu, isn't that sufficient. masayuki I guess Props is a good name? Menu sounds like not good. garykac This assumes that we add Menu (in a way that clearly distinguishes it from ContextMenu) garykac masayuki: Yeah. Menu sounds to generic and will be probably be mis-used. garykac ContextMenu and Props are what we currently have in the spec. masayuki garykac: Yeah, it must be mis-used. masayuki Oh, you added Props already? masayuki https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3Events-code.html#code-Props garykac So, it sounds like the current spec has the definitions is needs? Is there
Re: [Selection] Should selection.getRangeAt return a clone or a reference?
So...we discussed 31 e-mails, time to try to reach a consensus? Please keep in mind, it's too obvious to everyone but you don't have to agree to build a consensus. We can build a consensus if all can live with single conclusion. 3 proposals so far: Proposal A: Leave it undefined. If it's not causing interop issues, we can leave it. Proposal B: Clone. Proposal C: Live. Which one you *can't* live with, and which one do you prefer? I can live with any, but prefer A or B. If anyone has more to say, I didn't intend to interrupt, please add more info. /koji On Sun, Jan 25, 2015 at 9:02 PM, Aryeh Gregor a...@aryeh.name wrote: On Sun, Jan 25, 2015 at 1:31 AM, Mats Palmgren m...@mozilla.com wrote: Gecko knows if a Range is part of a Selection or not. Authors don't, I don't think. Of course, we could expose this info to authors if we wanted, so that's not a big problem. True, I'm just saying that I don't see any practical problems in implementing live ranges to manipulate the Selection if we want to. I don't think there are any implementation problems, I just think it's an API that's confusing to authors relative to the alternative (returning copies). And it's probably easier for the UAs that return references to switch to returning copies than the reverse, so it increases the chance of convergence in the near term. Also, if mutating the range throws, it will break author code; but if it fails silently, it creates a what on earth is going wrong?! head-banging scenario for authors. And anything authors can do with a reference, they can do with a copy just as well, by mutating the copy, .removeRange(), .addRange(). So I think returning a copy makes much more sense.
Re: [Selection] Support of Multiple Selection (was: Should selection.getRangeAt return a clone or a reference?)
I thought a bit of the same thing as Tab when I saw the visual focus discussion in CSS WG, but my current conclusion is not to think the two the same thing. Focus may be possible, but selections is a different thing. It's true that you could use multi-range selections to select in visual order. But there are bunch of operations defined against selections. What does it copy? What will happen when you type a to replace the selected text? Spell check? Bi-di algorithm? Almost every text algorithm is built on top of the model, which is the DOM today, we can't just replace it. I actually like multi-selections. Visual Studio allows me to select multiple ranges, and when I type, it changes all of them at once, just like the replace-all command. That's really a nice feature. But as you can see in this example, operations would behave differently against multi-selections. I think visual order selections, if ever happens, should have a different architecture, and it should not be handled together with multi-range selections. /koji On Sun, Jan 25, 2015 at 8:57 PM, Aryeh Gregor a...@aryeh.name wrote: On Sat, Jan 24, 2015 at 9:18 PM, Tab Atkins Jr. jackalm...@gmail.com wrote: Though I believe browsers will soon have much more pressure to support multiple ranges as a matter of course, as increased design with Flexbox and Grid will mean that highlighting from one point to another, in the world of a range is defined by two DOM endpoints and contains everything between them in DOM order, can mean highlighting random additional parts of the page that are completely unexpected. Switching to a model of visual highlighting for selections will require multi-range support. In other words, it'll switch from being a rare thing to much more common. Most sites will probably not use flexbox or grid for a long time to come, and on sites that do non-contiguous selections will probably be rare, so I wouldn't rely on this as a mitigating factor. I once went through some common selection use-cases with the new selection API that I suggested before (returning a list of selected nodes or such), and for at least some common cases (like wrap the selection in a span) it handled non-contiguous selections automatically, and was easier to use as well. For typical selection use-cases, the author wants to deal with the selected nodes anyway, not the endpoints.
Re: Custom element design with ES6 classes and Element constructors
On Thursday, January 15, 2015, Domenic Denicola d...@domenic.me wrote:
Just to clarify, this argument for symbols is not dependent on modules.
Restated, the comparison is between:
```js
class MyButton extends HTMLElement {
createdCallback() {}
}
```
vs.
```js
class MyButton extends HTMLElement {
[Element.create]() {}
}
```
This doesn't save you anything, classes can have statics and the statics
inherit, so the .create will cause issues with name conflicts anyway.
We should probably introduce a new namespace if we want to do this.
We're already doing some crude namespacing with *Callback. I'd expect
that as soon as the first iteration of Custom Elements is out, people will
copy the *Callback style in user code.
This is a powerful point that I definitely agree with. I would not be
terribly surprised to find some library on the web already that asks you to
create custom elements but encourages you supply a few more
library-specific hooks with -Callback suffixes.
[Bug 27915] New: Clients of WebSockets are not NTP synced (and there is no NTP-alike spec)
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27915 Bug ID: 27915 Summary: Clients of WebSockets are not NTP synced (and there is no NTP-alike spec) Product: WebAppsWG Version: unspecified Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P2 Component: WebSocket API (editor: Ian Hickson) Assignee: i...@hixie.ch Reporter: cmarten...@gmail.com QA Contact: public-webapps-bugzi...@w3.org CC: m...@w3.org, public-webapps@w3.org All major browsers (Chromium, Opera, Firefox, IE) have problems when being used in realtime networking applications. Date.now() inside the browser is not synced with NTP, therefore clients can gain access to systems when they reset their clock to a previous date when WebRTC or WebSockets are used peer-to-peer. I think we need desperately a WebSocket extensions spec that can be implemented in order to sync the network connection with a heartbeat and tick(-ack). From a developer perspective, I can't believe nobody had the issue before. There are also no libraries available, which seems surreal as there are thousands of users of Socket.IO and other WebSocket libraries where all the libraries depend on a synced clock as they are using Date.now() etc. My questions so far are: - Why are browsers not synced with NTP in the background? - Why is there no WebSocket extension spec that implements an NTP-like behaviour? - How to overwrite the behaviour of Date.now(), it is pretty much bad approach to do so? -- You are receiving this mail because: You are on the CC list for the bug.
Re: Custom element design with ES6 classes and Element constructors
Agree with this completely. Yehuda Katz (ph) 718.877.1325 On Tue, Jan 27, 2015 at 9:32 PM, Domenic Denicola d...@domenic.me wrote: From: Elliott Sprehn [mailto:espr...@google.com] Perhaps, but that logically boils down to never use string properties ever just in case some library conflicts with a different meaning. We'd have $[jQuery.find](...) and so on for plugins. Nah, it boils down to don't use string properties for meta-programming hooks. Or more concretely isn't the new DOM Element#find() method going to conflict with my polymer-database's find() method? So why not make that [Element.find] so polymer never conflicts? You can overwrite methods on your prototype with no problem. The issue comes when the browser makes assumptions about what user-supplied methods (i.e., metaprogramming hooks) are supposed to behave like. More concretely, if there was browser code that *called* arbitraryElement.find(), then we'd be in a lot more trouble. But as-is we're not. (BTW find() was renamed to query(), IIRC because of conflicts with HTMLSelectElement or something?)
Re: Custom element design with ES6 classes and Element constructors
On Tuesday, January 27, 2015, Domenic Denicola d...@domenic.me wrote: It does. If a framework says “use clonedCallback and we will implementing cloning for you,” we cannot add a clonedCallback with our own semantics. Whereas, if a framework says “use [Framework.cloned] and we will implement cloning for you,” we’re in the clear. Better yet! If a framework is a bad citizen and says “we did Element.cloned = Symbol() for you; now use [Element.cloned] and we will implement cloning for you,” we are still in the clear, since the original Element.cloned we supply with the browser is not === to the Element.cloned supplied by the framework. This last is not at all possible with string-valued properties, since the string “clonedCallback” is the same no matter who supplies it. Perhaps, but that logically boils down to never use string properties ever just in case some library conflicts with a different meaning. We'd have $[jQuery.find](...) and so on for plugins. Or more concretely isn't the new DOM Element#find() method going to conflict with my polymer-database's find() method? So why not make that [Element.find] so polymer never conflicts? - E
RE: Custom element design with ES6 classes and Element constructors
From: Elliott Sprehn [mailto:espr...@google.com] Perhaps, but that logically boils down to never use string properties ever just in case some library conflicts with a different meaning. We'd have $[jQuery.find](...) and so on for plugins. Nah, it boils down to don't use string properties for meta-programming hooks. Or more concretely isn't the new DOM Element#find() method going to conflict with my polymer-database's find() method? So why not make that [Element.find] so polymer never conflicts? You can overwrite methods on your prototype with no problem. The issue comes when the browser makes assumptions about what user-supplied methods (i.e., metaprogramming hooks) are supposed to behave like. More concretely, if there was browser code that *called* arbitraryElement.find(), then we'd be in a lot more trouble. But as-is we're not. (BTW find() was renamed to query(), IIRC because of conflicts with HTMLSelectElement or something?)
Re: oldNode.replaceWith(...collection) edge case
On Jan 27, 2015 4:51 AM, Anne van Kesteren ann...@annevk.nl wrote: On Thu, Jan 22, 2015 at 11:43 AM, Jonas Sicking jo...@sicking.cc wrote: In general I agree that it feels unintuitive that you can't replace a node with a collection which includes the node itself. So the extra line or two of code seems worth it. You don't think it's weird that before/after/replaceWith all end up doing the same for that scenario? Perhaps it's okay.. Yeah, I think that's okay. / Jonas
Re: Custom element design with ES6 classes and Element constructors
I'm also curios why DOM mutation is a problem. I read arguments like using the nodes as a key in a Map but such code is already broken as a node can also be replaced with some user code; so such code should put into account the node replacement. I also don't understand how the two-tier construction (init + createCallback) fixes the issue about accessing siblings and parents. One might still write problematic code in createdCallback as they will use it as a replacement for constructor (e.g. accessing a sibling and calling an instance method can easily fail as createdCallback not called on the element yet). I think, overall, trying to abstract the upgrade process is a big band-aid; makes the upgrade more magical while not hiding away all implications. Developers still need to be aware of the upgrade process and program accordingly so I think it is better to be more explicit. To me it sounds saner to create custom elements as HtmlUnknownElement at the parsing stage (or HtmlUnitializedElement if it is necessary to distinguish them) and then explicitly upgrade them bottom up by first running the constructors and then replace the existing nodes with newly created ones. After the construction the event listeners and properties can be copied over to the new nodes. By this way, anyone who wants to traverse tree can easily identify uninitialized nodes and act accordingly (e.g. add a listener for an 'initialized' event). On Tue, Jan 13, 2015 at 1:07 PM, Yehuda Katz wyc...@gmail.com wrote: On Tue, Jan 13, 2015 at 9:50 AM, Domenic Denicola d...@domenic.me wrote: From: Boris Zbarsky [mailto:bzbar...@mit.edu] Just to be clear, this still didn't allow you to upgrade a my-img to be a subclass of img, because that required a change in allocation, right? Agreed. That needs to be done with img is=my-img, IMO. (Assuming the upgrading design doesn't get switched to DOM mutation, of course.) Can someone help outline for me exactly why DOM mutation is a problem here? I can definitely see downsides, but DOM mutation is a fact of life when scripts are involved on today's web, and it sidesteps a lot of the problems that we encounter by trying to make in-place upgrading (upgrades without changing the reference at all) work sanely. I mean, qSA might not work the way someone might expect, but it also might not work if you go `$(my-button).button()` using jQuery. What expectation do we imagine someone has here that we think is missing if we use DOM mutation (rather than object-model mutation) for upgrades. -- Yehuda
