Some of the problems I have found is where built-in tasks have to function differently depending upon the web browser. I need a way of indicating which browsers can do what under which versions.
That's not always going to be possible, so I need to be able to fall back to "standard level of support" for cases where it's not specified.
What I guess I need is a browser name, version and capability matrix. It must be possible to subclass this matrix, so that implementations may provide further information (should the provided info go out of date). Indeed, it would be good if the matrix itself were a separate NuGet package.
Capability names need to be strings and the web driver factories should provide browser names and versions where at all possible.
The net effect is that (in the screenplay registrations), the capability matrix would be a registered service, which will automatically populate the BrowseTheWeb ability with appropriate information when it is created.
craigfowler
commented
6 years ago
Some of the problems I have found is where built-in tasks have to function differently depending upon the web browser. I need a way of indicating which browsers can do what under which versions.
That's not always going to be possible, so I need to be able to fall back to "standard level of support" for cases where it's not specified.
What I guess I need is a browser name, version and capability matrix. It must be possible to subclass this matrix, so that implementations may provide further information (should the provided info go out of date). Indeed, it would be good if the matrix itself were a separate NuGet package.
Capability names need to be strings and the web driver factories should provide browser names and versions where at all possible.
The net effect is that (in the screenplay registrations), the capability matrix would be a registered service, which will automatically populate the BrowseTheWeb ability with appropriate information when it is created.