- From: Brian Birtles via GitHub <sysbot+gh@w3.org>
- Date: Tue, 21 Mar 2023 00:50:31 +0000
- To: public-css-archive@w3.org
I'm afraid I'm still opposed to the current naming. I don't think ranges are a fundamental concept. The overwhelming majority usage of the API will continue to be for time-based animations and I think we should bias towards that. - Adding `getCurrentTime` makes using the API harder in the common case. When your editor suggests both `currentTime` and `getCurrentTime` how do you know which one to choose? You have to look them up to find out what their (subtle) distinction is. - Generally, authors should prefer using `currentTime` because it is more backwards compatible. If we _must_ have `getCurrentTime` because we expect it to be useful for non-range cases then we really should use a property bag. Doing so is necessary to: - Make the code readable. How on earth could you guess that the single string argument to `getCurrentTime` represents a range otherwise? - Make the API extensible. If we're going with something as generic as "get current time", then we'll no doubt want to add further conditions to that query in future and having an API that switches between positional arguments and property bags is an unnecessary wart. Now that TS/JS language servers are able to automatically refactor positional arguments into property bags, property bags have become much more common so I believe this approach is also idiomatic. -- GitHub Notification of comment by birtles Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8201#issuecomment-1477137378 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 21 March 2023 00:50:33 UTC