input type= date datetime datetime-local month week time

[Luke Inman-Semerau]

ahh, html5... http://www.w3.org/TR/html-markup/input.html

Proposal:

Overload WebElement.sendKeys()  to allow passing in a DateTime object (as appropriate to client language).

The client binding will then send across the wire a well formatted ISO 8601 datetime string. Like:

"2013-04-02T14:58:33Z"

The driver implementations can then interpret this appropriately for their input as needed. Currently only WebKit implements this ~ so Safari, mobile Safari and Chrome *right now*. Firefox / IE treat the field as a type=text. I'll ashamedly say I don't know what Opera does.

Essentially I've already done part of this implementation in the atoms (for type=date):

https://code.google.com/p/selenium/source/detail?r=bc59c1aea536de63174dc7328e8cb54fb947f7f6

https://code.google.com/p/selenium/source/detail?r=6790a0b4e2a4e6959b76e55cbb04ae18d031467d

Client bindings would need updating.

Let me know what everyone thinks (especially you spec writers out there).

-Luke

[Mike Riley]

I think you are opening a can of worms there.  If you allow for one conversion type then people will want to pass all sorts of other types and have them automatically converted.  They can convert it into a string in their code and simply send the string.

Most web sites require separate date and time fields, and you might even have to break it down to MM DD YYYY HH MM SS (assuming all fields are used).

BTW - I have not seen such a date format as that allowed in anything I wrote or used, so it would be useless to me, but I am guessing it is controlled by some sort of Locale setting.

Mike

[Luke Inman-Semerau]

I'm certainly not suggesting handling any javascript widgets or multiple input fields as sites display them.

My first concern was dealing with <input type="date" />   <- if you look at one of those in chrome and click on it, you'll get a browser rendered date calendar to pick the value of the input. The key here is that is not rendered by the page's javascript.

The value stored in that date field is only ISO format. The display of the value in the browser seems to be subjective to the browsers locale. (At least in Chrome). So we don't need to do anything special per local, set the value in the ISO format and we will get back the ISO format too.

-Luke

--
You received this message because you are subscribed to the Google Groups "Selenium Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[David Burns]

WebComponents and HTML5 widgets are going to be very interesting for us in general, but luckily I brought this up during a face to face with Simon in the Autumn of last year.

We have added how to handle Shadow DOM[1] to the spec which is the underlying technology for this. It doesn't shortcut input methods as you have but gives us access to the DOM that is created for each widget/ component.

I like your change however my gut feel is we shouldn't expect users to know the correct format go send through. Sending through a string, that can be coaxed to ISO on the server side should be good enough. I am pragmatic enough to know there be dragons do this route too!

Also your patch only mentions Apple Safari, doesn't it work on Chrome?

David 

[1] https://dvcs.w3.org/hg/webdriver/raw-file/default/webdriver-spec.html#switching-to-hosted-shadow-doms

On Tue, Apr 2, 2013 at 11:12 PM, Luke Inman-Semerau <luke.s...@gmail.com="mailto:luke.s...@gmail.com">> wrote:

ahh, html5... http://www.w3.org/TR/html-markup/input.html Proposal: Overload WebElement.sendKeys() to allow passing in a DateTime object (as appropriate to client language). The client binding will then send across the wire a well formatted ISO 8601 datetime string. Like: "2013-04-02T14:58:33Z" The driver implementations can then interpret this appropriately for their input as needed. Currently only WebKit implements this ~ so Safari, mobile Safari and Chrome *right now*. Firefox / IE treat the field as a type=text. I'll ashamedly say I don't know what Opera does. Essentially I've already done part of this implementation in the atoms (for type=date): https://code.google.com/p/selenium/source/detail?r=bc59c1aea536de63174dc7328e8cb54fb947f7f6 https://code.google.com/p/selenium/source/detail?r=6790a0b4e2a4e6959b76e55cbb04ae18d031467d Client bindings would need updating. Let me know what everyone thinks (especially you spec writers out there). -Luke -- You received this message because you are subscribed to the Google Groups "Selenium Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to selenium-develo...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.

[Simon Stewart]

I am starting to get The Fear that we may be overloading sendKeys a little bit too much. The next thing would be to also allow colour pickers to work by sending the rgb string through, and....

This is probably a really good time to put some serious thought into this, and possibly revisit the file upload thing as well (because we're not going to handle the multi-file uploads particularly gracefully right now and that makes me a sad panda) Having said that, I'm not particularly keen on having a welter of new methods being added to the wire protocol because the HTML5 spec has decided to define an indeterminate number of new input types.

Simon

[Luke Inman-Semerau]

On Apr 3, 2013, at 10:53 PM, "David Burns" <david...@theautomatedtester.co.uk>

>
> Also your patch only mentions Apple Safari, doesn't it work on Chrome?
>

Yes, it does work on chrome.

-Luke

[David Burns]

While I agree that we should be wary of overloading sendKeys but the user can type in this field for browsers that do and dont support this input type. Since a lot of the new elements degrade gracefully but the thing we really need to support is navigating the Shadow DOM to allow people to do what a user will probably do which is click()

David

David Burns
URL: http://www.theautomatedtester.co.uk/

[Ross Patterson]

If sendKeys(DateTime value) is implemented for <input type=”date”/> etc., I would strongly recommend the wire protocol and the Webdriver spec require the timestamp to be in RFC3339 date-time form, and ideally restricted to UTC (i.e., “yyyy-mm-ddThh:mm:ss[.nnn…]Z” only).  Even for <input type=”datetime-local”/> (and with the appropriate trimming for more coarsely-grained types).  Calendrical issues in software tend to be not well thought out in advance, and if there’s one thing this business should know by now, it’s that programs can only be trusted to operate in a fixed, explicit time zone, translating to other values only at the human-focused edges.

 

Ross

P.S. If anyone has any clout in the HTML Working Group, they need to understand that <input type=”time”/> defining its value as an RFC3339 partial-time is a mistake.  They should really use full-time, otherwise the browser et al. have to guess the value from 24 possibilities.  RAP

[David Burns]

Ross,

Your request is the reason why I would rather leave it as sending over a string. It keeps our code somewhat sane if the HTML working group change their mind. I am definitely with Andreas that we should just keep strings because all fallbacks go to <input type='text'>

David

David Burns
Email: david...@theautomatedtester.co.uk
URL: http://www.theautomatedtester.co.uk/

--

[Ross Patterson]

As I thought more about this, I realized that choice of API style (sendKeys(DateTime) or sendKeys(String)) doesn’t address the interpretation of the value, which was my primary concern.  The question of how the browser drivers are supposed to treat the value received over the wire protocol for <input type=”date”/> etc. fields exists regardless of how the programmer specifies the value.  The question is a matter of preference as long as some time zone is specified (“…Z”, “…+04”, etc.), although I’d argue from a cleanliness perspective that UTC-as-…Z is the right answer for the wire protocol and the spec.  But values that lack an explicit zone specification are essentially undefined, and could have serious interpretation problems in current-day scenarios:  how should “2013-04-10T08:51:00” be interpreted when a CI system in Europe is running a test through a cloud-based test provider hosted in Amazon’s US-West region?  Even leaving out cross-zone usages, I would hate to have IEDriver interpret that as EST/EDT, ChromeDriver as PST/PDT, and OperaDriver as CET/CEST.

 

Ross

[Jason Leyba]

For cookie expiration dates, the wire protocol uses seconds since January 1, 1970 UTC:  https://code.google.com/p/selenium/wiki/JsonWireProtocol#Cookie_JSON_Object

How we'd surface dates in the user API is another matter (and one that I'm not particularly in favor of)

--

[Simon Stewart]

This is a conversation that keeps on rearing its head in random ways. We've seen it manifest here as "what do we do about date inputs", and there's another on going discussion about multiple file uploads going on too. I'd like us to have a strategy for dealing with these in a way that's consistent with our goals of keeping the API manageable and yet one that leads developers to Do The Right Thing. Using strings that are magically interpreted is pretty opaque, and I'm not keen on that one bit. I regret doing that with the file uploads, since it set a bad precedent.

Our main problem is this:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element

Or, put another way: there's an absolute ton of types, and we need to handle them. Our changes will be in two parts: one to the wire protocol, one to the user facing APIs. Although I realize that these are separate, for now I'm smooshing both cases together.

Things that I'm considering:

1) These will, by definition, degrade to straight text boxes on older browsers. We can continue to treat as text boxes and just tell users to use formatted strings.

2) We extend WebElement with strongly typed methods to handle dates, files, colours and ranges. We then extend the wire protocol, clearly defining how these are translated to user friendly values. And we spell "colour" with a "u" in the protocol if needs be. This also implies getters.

3) Add new wire protocol methods and add some role-based interfaces to WebElements, allowing users to cast them to whatever is appropriate. The wire protocol changes would be as with "2", with the addition that if we're returning a WebElement that represents an INPUT we also send the type attribute on the wire so we can bind the correct interfaces to the created WebElement instance.

4) We acknowledge that these new types are probably implemented using the Shadow DOM, and we make users delve into the Shadow DOM to interact with the elements.

1 and 4 are off the table. They're not sympathetic to our users and they're just not very nice. "3" is consistent with the way that we currently offer users additional functionality, but I'm not crazy keen on adding the type attribute to the element structure in the wire protocol. "2" has the advantage of being easy to expose to users, but clutters the API in the common case.

I'm leaning towards "3". How about you?

Simon

[Simon Stewart]

Anyone?

[Jason Leyba]

I don't think we should add role interfaces for this - they're not very discoverable.  Instead, I think simple utility classes would work just fine:

DateInput input = new DateInput(webElement);

input.setDate(new DateTime(1234, DateTimeZone.UTC));

[David Burns]

My thoughts are inline

David Burns
URL: http://www.theautomatedtester.co.uk/

On Fri, Apr 19, 2013 at 12:10 PM, Simon Stewart <simon.m...@gmail.com> wrote:

This is a conversation that keeps on rearing its head in random ways. We've seen it manifest here as "what do we do about date inputs", and there's another on going discussion about multiple file uploads going on too. I'd like us to have a strategy for dealing with these in a way that's consistent with our goals of keeping the API manageable and yet one that leads developers to Do The Right Thing. Using strings that are magically interpreted is pretty opaque, and I'm not keen on that one bit. I regret doing that with the file uploads, since it set a bad precedent.

Our main problem is this:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element

Or, put another way: there's an absolute ton of types, and we need to handle them. Our changes will be in two parts: one to the wire protocol, one to the user facing APIs. Although I realize that these are separate, for now I'm smooshing both cases together.

Things that I'm considering:

1) These will, by definition, degrade to straight text boxes on older browsers. We can continue to treat as text boxes and just tell users to use formatted strings.

This is a consistent way that we are currently doing with other things.

 

2) We extend WebElement with strongly typed methods to handle dates, files, colours and ranges. We then extend the wire protocol, clearly defining how these are translated to user friendly values. And we spell "colour" with a "u" in the protocol if needs be. This also implies getters.

I would prefer not to do this at all. It goes against what we have done with our API. I appreciate that we are manipulating the WebElement but it just feels wrong.

 

3) Add new wire protocol methods and add some role-based interfaces to WebElements, allowing users to cast them to whatever is appropriate. The wire protocol changes would be as with "2", with the addition that if we're returning a WebElement that represents an INPUT we also send the type attribute on the wire so we can bind the correct interfaces to the created WebElement instance.

I have no real problem with this. The thing that I would like to avoid is overloading sendKeys or things like that since dynamically typed languages will have to do some nasty things that are not idiomatic! Having a role, with new JSONWireProtocol calls, is fine and we can then have things like setDate, or the idiomatic equivalent.

The potential issue that I can see is that users will think they are typing in the element, which is the reason why it was initially thought was against that. The roles might not be intuitive to users, as Jason said, but utility classes won't be as intuitive either but can be sorted by documentation.

 

4) We acknowledge that these new types are probably implemented using the Shadow DOM, and we make users delve into the Shadow DOM to interact with the elements.

We should allow people, if they want to go into the weird and wonderful world of the Shadow DOM. Having these mechanisms will allow users to manipulate new input types that come out of the spec that we don't implement straight away. This will give us the forward thinking that we want for the API.

[Simon Stewart]

Inline too :)

On Wed, Apr 24, 2013 at 5:11 PM, David Burns <david...@theautomatedtester.co.uk> wrote:

My thoughts are inline

David Burns
URL: http://www.theautomatedtester.co.uk/

On Fri, Apr 19, 2013 at 12:10 PM, Simon Stewart <simon.m...@gmail.com> wrote:

This is a conversation that keeps on rearing its head in random ways. We've seen it manifest here as "what do we do about date inputs", and there's another on going discussion about multiple file uploads going on too. I'd like us to have a strategy for dealing with these in a way that's consistent with our goals of keeping the API manageable and yet one that leads developers to Do The Right Thing. Using strings that are magically interpreted is pretty opaque, and I'm not keen on that one bit. I regret doing that with the file uploads, since it set a bad precedent.

Our main problem is this:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-input-element.html#the-input-element

Or, put another way: there's an absolute ton of types, and we need to handle them. Our changes will be in two parts: one to the wire protocol, one to the user facing APIs. Although I realize that these are separate, for now I'm smooshing both cases together.

Things that I'm considering:

1) These will, by definition, degrade to straight text boxes on older browsers. We can continue to treat as text boxes and just tell users to use formatted strings.

This is a consistent way that we are currently doing with other things.

And the way we're handling things now isn't scaling and is probably wrong. Magic detection of files is probably an indication that something's gone awry :) One of the things that I found hardest to deal with when using RC was that the locators were a mini language of their own, which were totally opaque until you read the docs. I'm not keen on repeating that.

 

 

2) We extend WebElement with strongly typed methods to handle dates, files, colours and ranges. We then extend the wire protocol, clearly defining how these are translated to user friendly values. And we spell "colour" with a "u" in the protocol if needs be. This also implies getters.

I would prefer not to do this at all. It goes against what we have done with our API. I appreciate that we are manipulating the WebElement but it just feels wrong.

Agreed.

 

3) Add new wire protocol methods and add some role-based interfaces to WebElements, allowing users to cast them to whatever is appropriate. The wire protocol changes would be as with "2", with the addition that if we're returning a WebElement that represents an INPUT we also send the type attribute on the wire so we can bind the correct interfaces to the created WebElement instance.

I have no real problem with this. The thing that I would like to avoid is overloading sendKeys or things like that since dynamically typed languages will have to do some nasty things that are not idiomatic! Having a role, with new JSONWireProtocol calls, is fine and we can then have things like setDate, or the idiomatic equivalent.

One reason for using the role-based interfaces would be to allow us to attach meaningful names to the methods: I'm not planning on overriding sendKeys.

 

The potential issue that I can see is that users will think they are typing in the element, which is the reason why it was initially thought was against that. The roles might not be intuitive to users, as Jason said, but utility classes won't be as intuitive either but can be sorted by documentation.

We'll see what happens. I think that our users will cope.

 

4) We acknowledge that these new types are probably implemented using the Shadow DOM, and we make users delve into the Shadow DOM to interact with the elements.

We should allow people, if they want to go into the weird and wonderful world of the Shadow DOM. Having these mechanisms will allow users to manipulate new input types that come out of the spec that we don't implement straight away. This will give us the forward thinking that we want for the API.

Handling the Shadow DOM is definitely something we should do, but it's a Really Bad Way to handle inputs in the common case: I find it hard to believe that those browsers that don't use native controls will use the same DOM structure for each of the inputs. And, it should be noted, there's no requirement for these new input types to be implemented using the DOM: a native control is also a perfectly reasonable way for these to be implemented.

Simon

[Simon Stewart]

Additional interfaces added to a class are more discoverable than utility classes: you can stumble across the interfaces accidentally in a debugger. You can't stumble across utility classes that way. 

Simon

[Jim Evans]

I can't agree with that statement. I don't find role-based interfaces to be discoverable at all. Certainly not more so than utility classes. It's the path we've chosen, and it fits the pattern of the API thus far, so I won't raise a fuss if this is the direction we decide on.

Speaking as the .NET bindings maintainer, I've come round to the opinion that explicit casting to the interface is not really idiomatic of recent-vintage .NET libraries. My personal opinion is that it looks tacky, but I don't know if that should enter into it.

[Simon Stewart]

What alternative would you prefer?

Simon

Sent from my iPhone

On 24 Apr 2013, at 17:51, Jim Evans <james.h....@gmail.com> wrote:

> I can't agree with that statement. I don't find role-based interfaces to be discoverable at all. Certainly not more so than utility classes. It's the path we've chosen, and it fits the pattern of the API thus far, so I won't raise a fuss if this is the direction we decide on.
>
> Speaking as the .NET bindings maintainer, I've come round to the opinion that explicit casting to the interface is not really idiomatic of recent-vintage .NET libraries. My personal opinion is that it looks tacky, but I don't know if that should enter into it.
>

[Jim Evans]

You've sussed out the reason I generally keep my proverbial trap shut in discussions like these. I'm not sure I have a good alternative. I haven't figured out my preferred alternative. That's also why I took pains to point out that I'm not raising a fuss if we decide on a certain design direction. I'm not done thinking about it by a long shot though.

[Daniel Wagner-Hall]

+1

I find the role based interfaces very awkward and hard to discover.  Utility classes are also awkward to discover, but once you know they're there, they feel much simpler to me.  Maybe the augmenter has soured my view of them more than I would otherwise feel.

I would favour a wrapper class:

new DateElement(webelement).setDate(org.joda.time.DateTime)

On 24 April 2013 22:51, Jim Evans <james.h....@gmail.com> wrote:

I can't agree with that statement. I don't find role-based interfaces to be discoverable at all. Certainly not more so than utility classes. It's the path we've chosen, and it fits the pattern of the API thus far, so I won't raise a fuss if this is the direction we decide on.

Speaking as the .NET bindings maintainer, I've come round to the opinion that explicit casting to the interface is not really idiomatic of recent-vintage .NET libraries. My personal opinion is that it looks tacky, but I don't know if that should enter into it.