- From: Lyza Gardner <web-platform-tests-notifications@w3.org>
- Date: Thu, 06 Apr 2017 19:25:09 GMT
- To: public-web-platform-tests-notifications@w3.org
@zcorpan I've pushed a commit that adds some tests for invalid values of `top`, `left`. I'm basing my logic on [Rules for Parsing Integers](https://html.spec.whatwg.org/multipage/infrastructure.html#rules-for-parsing-integers) — thing is, none of the browsers I tested in seem to be following that. Thus, a lot of fails here. Anyway, before I go further: it seems evident that no browser implements parsing these values per the "rules for parsing integers". Am I misunderstanding the spec ? Is the spec wrong? Or just browsers not following the spec :) ? BTW, my source here is [step 11 under step 5 (parsing the tokens) in the CSSOM View spec](https://www.w3.org/TR/cssom-view-1/#the-features-argument-to-the-open%28%29-method). While the HTML spec now, as of your recent changes, defines the tokenization itself, it doesn't—so far as I know—define the parsing of the tokens. Right? An aside: during the work on these tests, I got bogged down for some time by flaky behavior in my stable Chrome (57.0.2987.133) wherein sometimes opened windows inexplicably set their `window.screenX` and `window.screenY` values to `0` (which seems to persist until the open window gains focus). This was making me tear my hair out, especially as the behavior was variable and hard to track down. Given a test that rapid-fire opened 5 or more windows in one go with a `left` or `top` value, I had a near 100% ability to reproduce it — that is, at least one of the opened windows would report a `screenX` and/or `screenY` value of 0 — but _which_ windows would be affected varied. However, it's a non-issue in Chrome Canary—tests behave as expected. There's some allusion to the wonky behavior in [this ancient Chromium bug](https://bugs.chromium.org/p/chromium/issues/detail?id=35980). I wanted to mention this in case I need to worry about it further. View on GitHub: https://github.com/w3c/web-platform-tests/pull/5390#issuecomment-292285860
Received on Thursday, 6 April 2017 19:25:25 UTC