Re: Selectors API naming
On 12/20/06, Jim Ley [EMAIL PROTECTED] wrote: Not that I'm overly energised with naming, but... ... I agree with this view entirely. getSomething is a pattern worth keeping for developer sanity. JS programmers use short names for these things. Like $() instead of getElementById. The names in the draft look fine to me. I like my fingers, and I don't like autocomplete :) -- Robert Sayre
Re: Selectors API naming
Jon Ferraiolo [EMAIL PROTECTED] wrote: FWIW - Dojo's function is actually [window.]dojo.byId() and I believe that Yahoo's is [window.]YAHOO.util.get() Yes, those are the canonical locations. They are usually copied around. But we arguing about the right side of the last period anyway. On 12/20/06, Doug Schepers [EMAIL PROTECTED] wrote: That those methods have failed is not conclusive. Well, the possibility has certainly been widely discussed. http://www.google.com/search?q=DOM+sucks I don't understand the appeal of consistency when each of the methods takes a string mini-language as an argument. Ian Hickson wrote: In my experience with cat fighting on mailing lists, what you'll end up having is whoever gave up last wins. This is more a test of who has the most free time, not a test of who has the strongest case. Agree. good luck, Robert Sayre
Re: Selectors API naming
On 12/20/06, Chris Wilson [EMAIL PROTECTED] wrote: ? I never claimed there were technical problems with matchAll or select either - just that they didn't fit the pattern established by the other DOM Recommendation APIs, Web authors don't encounter a consistent pattern, and what is and isn't a DOM Recommendation API is an artificial distinction that doesn't matter to most of them, though interoperability does (of course). If the issue is only one of clarity and consistency, then I heartily concur with Ian--that's what editors are for. To become a Recommendation, it has to go through a lot more analysis by multiple parties and multiple implementations, etc Recommendations seem to vary widely in that regard. -- Robert Sayre
Re: Selectors API naming
On 12/20/06, Doug Schepers [EMAIL PROTECTED] wrote: Huh? The first 2 pages (at least) of that search seemed to complain about the lack of consistency in support among different browsers, not about the supposed failure of the longer DOM method names. [1] Can't say it much better than DOM sucks, and JavaScript uses DOM. DOM is heavy and unintuitive. Result 6, from kde.org. Many results do complain about interoperability. A good indication of where our priorities should lie. [1] FWIW, I also tried googling for robots+kill and fluffy+bunnies+eat+grass, but couldn't find any relevant information on the topic there either, oddly enough. Thanks for that. -- Robert Sayre
Re: Selectors API updates
On 1/9/07, Anne van Kesteren [EMAIL PROTECTED] wrote: These names are short, don't clash with autocomplete and provide a superset of the functionality given by the other get* methods. Works for me. Thanks, Anne. -- Robert Sayre http://franklinmint.fm http://mozilla.com
Re: Selectors API naming
On 1/25/07, Jon Ferraiolo [EMAIL PROTECTED] wrote: I encourage you to read the process document I encourage you to read the WG charter. http://www.w3.org/2006/webapi/admin/charter Looking over the charter, I see the proceedings of the WG are Member-Only (bad), but it also states: For example, the Working Group should publish specifications often, send summaries of Working Group activity to a public list and participate in those public lists, responding to comments in a timely manner. If the WG doesn't provide public minutes, and doesn't otherwise respond to public comments from WG members and the general public, I think it should change its charter to be entirely Member Confidential. I wouldn't want that, but it seems like it would be more accurate. -- Robert Sayre
Re: Selectors API naming
On 1/26/07, Robin Berjon [EMAIL PROTECTED] wrote: On Jan 25, 2007, at 21:51, Robert Sayre wrote: I encourage you to read the WG charter. http://www.w3.org/2006/webapi/admin/charter I think Jon knows the charter :) Well, I thought I would match his tone :) If the WG doesn't provide public minutes It used to, but it is a lot of work ... This WG responds all the time, I don't know why you're saying that. ... This comes from completely nowhere. Well, I saw several comments from significant implementors that indicated they were unhappy with getElementsListBySelector. I don't think the WG needs to provide detailed minutes, but a list of people present at the meeting and a coherent rationale would do the trick. -- Robert Sayre
Re: Selectors API naming
On 1/26/07, Charles McCathieNevile [EMAIL PROTECTED] wrote: On Fri, 26 Jan 2007 13:05:13 -0500, Robert Sayre [EMAIL PROTECTED] wrote: Roughly speaking, the rationale was that nobody except Anne felt get was good, there was little support for match and strong resistance, and then we got getElementBySelectors as the only obvious choice for the single element method - which everyone except Anne was happy with. An 's' on the end too? This is the worst name for an API I have seen in a long time, and I agree with all of Hixie's comments on the process. This is not an effective way to make changes to the Web. -- Robert Sayre http://blog.mozilla.com/rob-sayre/
Re: Selectors API naming
On 1/26/07, Charles McCathieNevile [EMAIL PROTECTED] wrote: Since I have the reponsibility for getting this group to finish its work in a particular timeframe, I made a decision to find some kind of resolution in line with the process under which we are working. Which happens to offer the opportunity to discuss with Microsoft in advance, and with various other implementors, and see if they are prepared to agree to something. I'm not trying to hold you up. Keep the terrible name. In the end, it is easy to route around. The point on the process stands, though, and shows a awful flaw that future W3C WGs need to avoid. Perhaps this WG should be rechartered as well. The W3C process should produce standards that use idiomatic HTML, JavaScript, and CSS. That never happens. Instead, we get the typical W3C product: a result of compromise between IDE vendors, Java/C# programmers, and Semantic Web advocates. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Selectors API naming
On 1/26/07, Charles McCathieNevile [EMAIL PROTECTED] wrote: I'm not trying to hold you up. Keep the terrible name. In the end, it is easy to route around. Indeed. This was a point raised again and again by various people. And it applies to all sides of the debate, so any claims of strong resistance are bogus. Should have stuck with the editor's initial choice and saved WG time. Feel free to propose a new W3C process of some kind, but that isn't actually the concern of this working group, which has certain tasks to do under an existing set of conditions. You should take them up with the right part of W3C if you want to have an effective conversation. If you want to create effective specifications, the way to respond to harsh technical and ethical criticism is not to dismiss it by pointing out that you are following the correct bureaucratic procedure. -- Robert Sayre
Re: Progress event spec
On 1/27/07, Ian Hickson [EMAIL PROTECTED] wrote: It's important, in terms of API design, to make the main use cases trivial. I believe the above design would do that. Adding to that, I see there is an issue open on whether timings should be standardized to some degree. I believe they should. Mozilla receives bug reports when we fail to match IE's event timing for XHR. -- Robert Sayre
Re: Progress event spec
On 1/27/07, Jim Ley [EMAIL PROTECTED] wrote: The arbritrariness of the value is why I do not feel it should be in the spec, but left to vendors. I'd be interested to hear from browser vendors that want to change or delete the values in Hixie's proposal. -- Robert Sayre
Re: Selectors API: Multiple elements with the same ID
On 1/27/07, Anne van Kesteren [EMAIL PROTECTED] wrote: Yes, they are prolly slightly different (although I haven't actually seen any documentation on how getElementById exactly works). MSDN says it returns the first object. http://msdn.microsoft.com/workshop/author/dhtml/reference/methods/getelementbyid.asp -- Robert Sayre
Re: XMLHttpRequest for Last Call
On 2/13/07, Anne van Kesteren [EMAIL PROTECTED] wrote: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/XMLHttpRequest/Overview.html?content-type=text/html;%20charset=utf-8 as Last Call Working Draft by next Monday. If you have any objections please post them to the public list. Where do the requirements for the username and password productions come from? Is there an old list discussion on them? -- Robert Sayre
Re: XMLHttpRequest for Last Call
On 2/17/07, Anne van Kesteren [EMAIL PROTECTED] wrote: On Sat, 17 Feb 2007 21:15:04 +0100, Robert Sayre [EMAIL PROTECTED] wrote: Where do the requirements for the username and password productions come from? Is there an old list discussion on them? Mainly offlist feedback. There's been some discussion (on list) on the userinfo production though if you are referring to that: http://www.google.com/search?q=inurl:public-webapi+userinfo OK. AFAIK, Basic and Digest are not interoperable outside of ASCII, and this specification provides no guidance on the encoding of the credentials. Is there anything useful we can say here? Maybe just warn that it isn't internationalized? -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [XMLHttpRequest] update from the editor
On 5/14/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: Personally I don't think lack of registration is a particularly strong reason not to define handling for a particular MIME type. At the very least, the W3C/IETF liasons should discuss this. It is exceedingly bad manners to squat a on parts of a shared namespace, such as MIME types or HTML tag names, in the first place. The W3C should not reward that behavior by standardizing unregistered types. I have to wonder why the type was suggested if no one has any usage data. If people are using it, this particular type is water under the bridge, so I personally feel that the IETF should register and document it. The registration procedures are a lot easier now. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [XMLHttpRequest] update from the editor
On 5/14/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: Defining particular behavior when a type is seen is not the same as standardizing it, in my opinion. Disagree, since MIME types are used to route messages to code with particular behaviors. However, I personally don't feel too strongly about this issue. -- Robert Sayre
Re: [xhr2] PATCH support
On 8/6/07, Anne van Kesteren [EMAIL PROTECTED] wrote: On Mon, 06 Aug 2007 15:38:52 +0200, Robert Sayre [EMAIL PROTECTED] wrote: Partial resource updates are a pretty compelling use case for XHR2. You can always use POST for this, but it's a pain if you need to use POST for something else. What exactly would need to be supported? I think it should be required. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: XHR: definition of same-origin
On 8/28/07, Maciej Stachowiak [EMAIL PROTECTED] wrote: The XHR spec doesn't define same-origin. We had a webkit bug filed differently where we apparently interpreted same-origin differently than IE or Firefox: http://bugs.webkit.org/show_bug.cgi?id=15100 In particular, we would not consider https://example.com:443/ to be the same origin as https://example.com/. Agree. This should come in handy: - RFC 3986, section 6.2.3 (Scheme-Based Normalization) -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: multipart, server-sent events, and
On Feb 19, 2008 12:20 AM, Mark Baker [EMAIL PROTECTED] wrote: Well, I'd like to see some hard evidence of this before we write it off. I'd like to see Maciej go first. ;) -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Geolocation API proposal
On Thu, Mar 6, 2008 at 5:55 PM, Aaron Boodman [EMAIL PROTECTED] wrote: I posted this to the WhatWG mailing list, but it was suggested that this might be a more appropriate place. Surely WhatWG would be more convenient? I mean, the editor can just rubber stamp it for you... -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: [selectors-api] Why no querySelector(All) on DocumentFragments?
On Thu, Mar 13, 2008 at 11:24 PM, Ian Hickson [EMAIL PROTECTED] wrote: Yeah, I was just jumping in to clarify the :root thing. Personally I think you're right, it would be useful to have the method on DocumentFragment, I agree. but that's up to Lachlan. :-) Fully disagree. -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Proposed errata for DOM2 Range regarding insertNode()
On Wed, May 14, 2008 at 6:15 PM, Ian Hickson [EMAIL PROTECTED] wrote: To my knowledge, very little Web content relies on this spec at all. That's why Acid3 tested it, to make it interoperable enough that it could be used. :-) I thought Acid3 tested things that have been written down for at least 5 years or something like that. confused, Rob -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Proposed errata for DOM2 Range regarding insertNode()
On Wed, May 14, 2008 at 9:02 PM, Ian Hickson [EMAIL PROTECTED] wrote: As I said in the very first e-mail on this subject, that's what I'd like to do. However, that's a significantly higher cost (years vs weeks) than releasing an errata, and it was my impression that the Mozilla community would like a quick turnaround on this. It looks to me like you're retroactively specifying something in your test. I asked a simple question to determine whether that was the case, since I would like to know the exact nature of the bugs Google is (rather pompously) flaming us for.[1] If there is disagreement about a change to normative behavior, it seems like the right thing to do would be to discuss it, not pick one interpretation and try to jam it through as errata. I don't see how one can claim the spec can be interpreted both ways, but also that the intent is clear. Is one of the possible interpretations a real stretch? [1] http://diveintomark.org/archives/2008/05/07/when-the-fall-is-all-thats-left -- Robert Sayre I would have written a shorter letter, but I did not have the time.
Re: Proposal to work on Geolocation
The WebAPI WG seems like the best venue. - Original message - Hi, Chaals- Charles McCathieNevile wrote (on 5/27/08 6:3... On 5/27/08, Doug Schepers [EMAIL PROTECTED] wrote: Hi, Chaals- Charles McCathieNevile wrote (on 5/27/08 6:34 PM): On Tue, 27 May 2008 23:38:37 +0200, Maciej Stachowiak [EMAIL PROTECTED] wrote: I could not find record of any such objection in the Advisory Committee mailing list archives, or any record of an official W3C decision on this point. As Team contact, could you please explain who made this decision and on what basis? In which case I presume that someone used their ability to reply to the Team privately instead of being open about what they wanted. This disturbs me a little since it increases the resources and coordination required, IMHO, to do what is a pretty simple piece of work. I think you may be overstating how simple this is, for what it's worth. Exposing coordinates sounds simple, sure... but the security and privacy implications are stickier, as is the legal landscape (both in terms of privacy laws and of IPR). For the record, Opera would also like to see the geolocation work take place inside the webAPI group and is unhappy that it has been removed from the proposed charter for Web Apps. Noted. I will convey your sentiments to the Team. Regards- -Doug Schepers W3C Team Contact, SVG, CDF, and WebAPI -- Sent from Gmail for mobile | mobile.google.com Robert Sayre I would have written a shorter letter, but I did not have the time.
