Added option to filter tests #212
Conversation
|
It's really cool is much faster. Anchors work better. There is something weird: And it would be nicer if we could filter those in "experimental". |
Yes, that's a benefit. Hope Lea is fine with that, too. She held onto the animation in the past.
It was reset for every test. I've fixed that now.
Good point! I've added a filter for them. Sebastian |
|
I did quite like the animation, and it allows us to have slower tests too, but I'll concede if you both agree with removing it. I'm not one to hold a project back just because of my opinions. :) Is there a screenshot or something about this change? It would help review it! |
You may want to mark it as draft until it's ready to merge |
|
I also liked the animation somewhat, though it also had some issues. Firstly, the mentioned anchor problem, i.e. you can't get to the spec. by entering a URL with its anchor. Also, with more tests it takes longer and longer until the final values appear. And the displayed time it took to execute the tests is a bit misleading as it takes much longer until they are displayed, so users might not immediately understand what that value means. So, at least for now, I am for removing it. We may add back an animation solely for the display of the score at some point. I think with the latest commits the changes aren't WIP anymore. Again, detailed feedback is very welcome. Here's a screenshot:
Sebastian |
|
The animation was a cool at first, but now it becomes a problem, because there is really a lot of tests. Even to test the addition of new tests, it is little useless, because you have to wait longer and longer. I think it would be beneficial for everyone to remove it. |
Forgot to push that change. Did that now. Please give it a shot! Sebastian |
|
Maybe we should move "whatwg" and "svg" in separate group. |
|
Now that I saw the screenshot I understand what the PR is about. What a fantastic feature!!! Thank you so much for implementing it! |
Let's discuss this in a separate issue, please! I'd like to get this feature online first. Afterwards we can still iterate on it and add more filters. I'll also create new features for the questions I had above, so we can discuss them separately and iterate on what we have now. Sebastian |
There was a problem hiding this comment.
Overall, LGTM, i think this is a useful feature.
This allows to see how both the CSS language, and the support for it evolve.
But in practice, i don't think this reduces the noise that much : there's a lot of green in the snapshots coming from the previous better supported versions.
We could still add diffs between snapshots later, like in Kangax's compatibility table for JavaScript.
Just one more question: what makes a spec "stable" or "experimental"?
csstest.js
Outdated
| } | ||
|
|
||
| function runTests(filter = '') { | ||
| let specs = []; |
There was a problem hiding this comment.
I see you replaced some var keywords by let.
Do we want to embrace ES6-style javascript now? or still being somehow compatible with old browsers?
There was a problem hiding this comment.
IE isn't really dead yet. For me, it would be necessary to wait until it's definitely dead (removal of Windows). I let you decide.
There was a problem hiding this comment.
According to caniuse.com, IE has (partial) support for let. The biggest percentage of a non-supporting browser is Opera Mini with ~1%. And the overall support is at ~95%, which seems pretty stable to me.
Personally, I prefer to use ES6+ features as long as there is good browser support for them. If you two believe we should strive for full backwards compatibility, I could change it back to var.
Though I have to admit, I never tried to call the site in a very old browser so far. I assume there are other pieces of code that might be unsupported in older browsers.
Having said that, I am also planning to push #57 forward which requires a good browser coverage. So maybe that requires the JS part to be backwards compatible.
Sebastian
There was a problem hiding this comment.
For me, it would be necessary to wait until it's definitely dead (removal of Windows).
For what it's worth, IE is removed in Windows 11 and finally will be gone in June this year, though it will surely still take many years until nobody uses IE anymore.
According to statcounter IE still has a market share of 0.46%.
Sebastian
There was a problem hiding this comment.
Because there's a mixture of var and let after that patch, I decided to roll back to var again for now.
I'll file a follow-up issue on refactoring the code base, instead.
Sebastian
There was a problem hiding this comment.
I've filed #216 now to discuss whether and which ES6+ features we want to use. Feel free to comment there!
Sebastian
There was a problem hiding this comment.
Could this line also be reverted to var?
There was a problem hiding this comment.
Done. Thank's for the hint!
|
@PolariTOON Thank you for the detailed feedback!
That's true. Currently, the snapshot filters include all specifications listed as part of the official CSS definition of the related snapshot. Adding diffs between two snapshots shouldn't be too hard.
Sorry, I added a description to the filters in their I defined "stable" as everything that's listed in the latest snapshot plus all the predecessor specifications and those that probably won't change much anymore. Sebastian |
SebastianZ
force-pushed
the
filter
branch
2 times, most recently
from
dade275 to
5adb380
Compare
|
@PolariTOON I think I've addressed all your points now. For most of them I've created separate issues to discuss them further. If there's anything left you think should be in this first version of the feature, please tell me! Otherwise, it would be great if you also gave your approval, so it can be merged. Sebastian |
csstest.js
Outdated
| } | ||
|
|
||
| function runTests(filter = '') { | ||
| let specs = []; |
There was a problem hiding this comment.
Could this line also be reverted to var?
csstest.js
Outdated
|
|
||
| function runTests(filter = '') { | ||
| let specs = []; | ||
| let timeBefore = +new Date; |
This addresses #178 and adds a drop-down list to the sidebar allowing to filter the tests by specification status. The options are "All", "Stable", and the different CSS snapshots. The chosen option is saved in the local storage and read on page load to keep the shown info stable.
For that to work I added a new
statusfield to the specifications which holds the fieldstabilityindicating whether a spec. isstableorexperimental. Optionally, there are two fieldsfirst-snapshotandlast-snapshotindicating the first and last snapshot a specification got included as official part of CSS, respectively.last-snapshotindicates that a higher level spec. supersedes a previous one in a later snapshot. I.e. it ensures that only the level listed in the snapshot is shown.Note that this is still WIP. In its current form I had to drop the counting up animation. Instead, the results are shown right away. Also, I'd like to get some feedback on whether that's generally the right direction I am heading. Are you missing any options? Is the idea of superseding specs ok? Should the default option be changed? Should the options be more fine-grained (maybe even be feature based as discussed earlier)? Should specific features listed in "Safe to Release pre-CR Exceptions" be included even when their specification isn't?
Sebastian