25680 2014-05-13 10:51:05 +0000 Don't tell what User Agent MUST do 2015-10-26 03:07:30 +0000 1 1 1 Unclassified Browser Test/Tools WG WebDriver unspecified All All RESOLVED WORKSFORME P2 normal --- 20860 1 vlotoshnikov public-browser-tools-testing botalov.andrey dburns james mike public-browser-tools-testing oldest_to_newest 105825 0 vlotoshnikov 2014-05-13 10:51:05 +0000 Section "10.1 Determining if an element is displayed" mentions that "The User Agent MUST NOT allow negative scrolling." Is trying to define what a User Agent MUST do out of scope of this spec? Should we just delete that sentence or formulate it as a prescription for the WD remote end? 105838 1 dburns 2014-05-13 12:42:06 +0000 The spec is designed to tell the User Agent (the browser) what it MUST/SHOULD do or not do. In this case browsers never do negative scrolling but if they ever do we have it in writing that it should never be handled. 105893 2 botalov.andrey 2014-05-13 18:51:01 +0000 So that means that it should tell "The remote end MUST NOT allow negative scrolling." 106008 3 vlotoshnikov 2014-05-15 01:00:36 +0000 David, I believe the distinction between (similarly sounding) "what browser should/must do" and "what WD remote end should/must make the browser do" is important. We know that the spec is for 'implementors of the WebDriver API', that it describes two components - local and remote ends - and that implementors are not necessarily people who have complete control over browser behavior in certain situations. In the ideal situation, implementors of WebDriver are a browser vendor and they have some control, but even then WebDriver API doesn't feel right place to define what browser should/must do in WebDriver-irrelevant situations (such as supporting or not supporting negative scrolling); for that there are other specs. Does this make sense? We could defer it to the F2F or something since it doesn't appear to be blocking anything. Now I also noticed several other places in the spec with 'user agent must/should'. 123920 4 james 2015-10-26 03:07:30 +0000 I agree with the premise of this bug, but I think all the instances are fixed now. If not please open specific bugs.