Add CSS @nest tests

[argyleink]

Hoping this is a sturdy base we can build upon 👍🏻

[tabatkins]

Test structure seems good.

As a general rule, unless a custom reference is needed to make something testable (or at least to make the test clearer and easier to understand), we should use the standard refs when possible. Notably, https://github.com/web-platform-tests/wpt/blob/master/css/reference/ref-filled-green-100px-square.xht is usually the most appropriate standard ref. All of these tests would be trivial to switch over to that ref.

Alternately, since these tests aren't really about rendering, we could do all of them with a simple script test, verifying that the computed style of a test element is what we expect. That way a single test file could run thru a bunch of scenarios, rather than needing a bunch of single-test files.

(You can also avoid the single-test-file problem while still using refs by stacking multiple of them into a single ref. For example, doing ten tests, each of which will correctly produce a 10x100 green rectangle, so that when stacked you'll get the 100x100 green square. But for this sort of feature, script tests should be just fine.)

[argyleink]

I stacked 4 at 100x100, how's that lookin?!

I've slimmed it down to 2 files, the tests and the ref. I think i'll make another PR or add another file that does some script tests. Looks like I can piggy back on the is-where-parsing.html work yeah?

thx for the help 🙂

[argyleink]

I've added a file which hopes to test whether or not rules can be created with nesting or not. I'd love a tip or two if it's flimsy, since I'm not sure I can count on the cssText to match what I put in?

[argyleink]

adds more of both, ref tests and parsing tests 👍🏻

[argyleink]

yay! FWPD approved today 💯

[argyleink]

[alolalo]

Hi Adam, thanks for this preview. I was wondering about how css-variables would be handled, and if that is an option.

let's say I don't use "green" as a color-value, but it's hex or hsl value. Will it then still look for green?

Say I want to check if green is used at all, since this is a color, will it check for the variable green? Or will it look for it's value?

I think it would make a great difference knowing what is checked, the variable or the value, and if that is something you can put under your control tbw. That would make your tests strictly typed and robust imo.

[argyleink]

there's 2 different kinds of tests here, parsing tests and painting tests. the painting ones need green, the parsing ones don't. does that help answer the Q!?

[alolalo]

Yes, thank you, and also raises a few thoughts. It is a bit confusing which is which, and what seperates their tests. Does the painting-test look for the value? And the parsing-test for the variable? Or is it more of a mental model and they both do the same?

I'm curious because just like with base64 encoding to ascii, a-to-b (ascii to binary) and b-to-a (binary to ascii) actually work in reverse and that's the feeling I get from the naming of this. Sounds like some under the hood JS thing that on top of the hood creates some confusion.

For everyone else's information; I'm a designer who reads & writes code, not a front-end dev. But I would love to write my own tests in CSS, and with something Adam made. Always good stuff :)

[argyleink]

=) lemme see if i can help here more and answer a few:

A clear divider is whether JS is involved or not. Also, my document names and <title>'s try to help here too. The parsing ones are marked as such and then use JS to insert CSS into the page, and then ask the page for the CSS it just put in. If the browser doesnt understand the CSS inserted, it'll return wrong and the test will fail.

The painting tests compare images of a rendered page. There's infra here to support rendering nesting.html against nesting-ref.html (the expected outcome). They're like visual unit tests. A green box in a non -ref test is a success, the css was used and drew the expected outcome.

It's tech created long before me. I'm just putting in documents to test features by following patterns already established in the test code base. Some are JS, some are HTML/CSS. If you're hunting for fun ways to write CSS tests, I'd suggest trying out a visual regression test suite (saas or run it yourself with node). It's really fun picking a "golden screenshot" that becomes a test fixture for any changes to compare against.

[tabatkins]

Yeah, the "scripting" tests are run by executing the script on the page, most notably the test() function, and generally it's just gonna check string equality. We usually just check that a rule or value serializes to a particular known string, hopefully indicating that the syntax we're testing was correctly parsed and understood.

The other types of tests are "ref" tests, where you write the test using the feature in question, then write the same page again using less-powerful, more mature features (usually just width, height, abspos, and background color), and then check whether the two pages render identically using automated screenshots. All the checking is done by the test harness on the server; nothing special is done by the test author.

Sometimes a scripting test is also designed to be readable as a normal page, so you can just look at the test page and see if it's working without having to check the test() results. But that's just for fun; it doesn't have any effect on the test's validity.

Check the documentation in the README of this repo for more details.

[alolalo]

Thanks for the clear explenation all of you, I think it's really good to know that regardless of the fact you're using a style to test, it's not testing it visually. I think that's an easy mistake to make for people who would write tests like me, but I cannot undo the traumas I've experienced when people don't get certain first principles. Like making a 3d-game and finding out your artist didn't understand that part and just made 2d art because "the concept looked 2d". I would like to return that favor too.

I have a way of thinking more symmetrical and using a base-line as a point of reference. Would test also be able to look for certain min-max values? Like saying ' IF luminosity (hsl) of green >= 50 { do this };'

And finally, I was also a bit let down by SVG's SMIL implementation recently as it doesn't seem to be able to support css-variables inline all the way, and I hope that for future specs this is a given so regardless if it was created long before you, the next in line doesn't inherit that nested problem, and they can straight up hook their design system into these new useful features.