- From: Simon Stewart <simon.m.stewart@gmail.com>
- Date: Sun, 23 Dec 2012 02:27:23 -0800
- To: Ross Patterson <rpatterson@parature.com>
- Cc: public-browser-tools-testing <public-browser-tools-testing@w3.org>
- Message-ID: <CAOrAhYHH1e0b+zp6Q3wSpSKb-NFe+QzSi0NcTNjQn9VPTmGuQw@mail.gmail.com>
Hi, David and I have both spent some time working on the draft. Please take a look at tip of tree, as I've merged David and my edits together. If there are no more blockers, I say we push this once it all validates. Cheers, Simon On Fri, Dec 7, 2012 at 5:17 AM, Ross Patterson <rpatterson@parature.com>wrote: > On Fri, Dec 7, 2012 at 1:44 AM, Simon Stewart < simon.m.stewart@gmail.com> wrote: > **** > > ** ** > > Wait, 1:44 AM? Wow, that’s commitment.**** > > ** ** > > On Thu, Nov 8, 2012 at 9:42 AM, Ross Patterson <rpatterson@parature.com> > wrote:**** > > * Sec. 7.2 conflates three different parameters as "name". Shouldn't > there instead be "id", "windowHandle", and "windowName" parameters with > separate value sets?**** > > ** ** > > The "name" parameter could mean one of several things. That list describes > the order in which that parameter should be compared with attributes of the > window. The reason for doing things this way is to make the local end > easier to implement: each of these types is commonly represented as a > string. Given we're not even strongly typing "windowHandle" the local end > (it's an opaque string) a poorly designed framework layered on top of > WebDriver will cause all sorts of trouble. This way, we push the complexity > into the remote end but can clearly express behaviour.**** > > ** ** > > I think the spec should strive to eliminate ambiguity and to ensure > clarity of intent between local and remote ends, but I see your point. *** > * > > **** > > * Sec. 9 discusses the difference between a WebDriver "id" attribute and a > DOM "id" attribute. Given the huge history of ignoring the uniqueness > requirement for DOM's "id", the "The IDs used to refer to different > underlying DOM Elements must be unique within the session over the entire > duration of the session." Should probably explicitly reject the historical > illegal usage of non-unique DOM "id" values.**** > > ** ** > > Isn't that expressed in "must be unique"? Or does it need to be made even > clearer?**** > > ** ** > > As a colleague says, “’Need’ is such a strong term” J I would have > thought the DOM id uniqueness requirement was pretty darned clear also. > But no, I think I was just venting on this particular topic J **** > > **** > > * Sec. 16.2 says "One of those monitors would be very cool." Very true, > but also the only instance of humor in the spec so far :-)**** > > ** ** > > The second: section 1.1 has The Other Joke in it. :)**** > > ** ** > > OK, +1 for more jokes then J**** > > ** ** > > Thanks,**** > > Ross Patterson**** > > Parature**** > > ** ** >
Received on Sunday, 23 December 2012 10:27:50 UTC