You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The file tests.js is a massive piece of code that describes hundreds of recognition tests for CSS features as unique non-cyclic entry point (window.Specs) that is never modified afterwards.
That seems like a perfect candidate for being converted to one or multiple JSON files.
This would make the tests machine-readable, but also serializables, allowing external scripts to be run on them.
As an use case, later, we could even imagine generating automatically some tests from the CSS syntax and dumping them as JSON files.
Currently, we already do generate some tests with the help of concat, add and times array methods, but i currently count only about twenty such occurrences in the whole testbase, thus making a very minor part of it.
So converting to JSON would need to manually expand those tests but it should not be a big hurdle. We could also create a declarative syntax for these functions instead.
This currently somehow conflicts with the proposal in #219, that would like to split tests.js into individual JS modules, statically imported, since the current story with JSON files in browsers is that they cannot be imported as modules, but rather have to be fetched dynamically (we would have to wait for import assertions to land first to become able to statically import them as modules).
The text was updated successfully, but these errors were encountered:
Because we ended up splitting the tests up into several files in #219 and we define DOM tests via functions since #236, converting the tests to JSON became obsolete. Therefore I close this issue now.
The file
tests.js
is a massive piece of code that describes hundreds of recognition tests for CSS features as unique non-cyclic entry point (window.Specs
) that is never modified afterwards.That seems like a perfect candidate for being converted to one or multiple JSON files.
This would make the tests machine-readable, but also serializables, allowing external scripts to be run on them.
As an use case, later, we could even imagine generating automatically some tests from the CSS syntax and dumping them as JSON files.
Currently, we already do generate some tests with the help of
concat
,add
andtimes
array methods, but i currently count only about twenty such occurrences in the whole testbase, thus making a very minor part of it.So converting to JSON would need to manually expand those tests but it should not be a big hurdle. We could also create a declarative syntax for these functions instead.
This currently somehow conflicts with the proposal in #219, that would like to split
tests.js
into individual JS modules, statically imported, since the current story with JSON files in browsers is that they cannot be imported as modules, but rather have to be fetched dynamically (we would have to wait for import assertions to land first to become able to statically import them as modules).The text was updated successfully, but these errors were encountered: