Re: Requirements for (level >=3) tests

On Thu, Feb 16, 2012 at 8:47 PM, Linss, Peter <peter.linss@hp.com> wrote:
> HTML5 input is acceptable now, but XHTML is still preferred as it avoids potential parser/markup issues.

What are some examples?

On Thu, Feb 16, 2012 at 8:47 PM, Linss, Peter <peter.linss@hp.com> wrote:
> Aryeh, simply ignoring the guidelines is not acceptable. They exist for a reason and have been developed over years of experience developing CSS test suites by many people.

To be clear -- I ignored the guidelines because my initial priority
was getting a set of rough and usable tests going.  I was aiming to
have tests that I could use for experimentation, not necessarily ones
suited for reuse yet.  That's part of why my tests are still in
incoming/ and not submitted/.  I didn't mean to imply that I don't
expect to change the tests in the future to work with existing
toolchains.  I apologize if I sounded dismissive.

> Also note however, that built test suites include HTML, XHTML and XHTML-Print versions of the tests. These versions are generated by the build system from the single source input. This is true for both tests and reference files (at least reference files in XHTML or HTML).
>
> While using a minimal HTML test source should work, the test that will be part of the official test suite will be the output of the build process, and will be a serialization of the DOM.

That sounds reasonable.

> Furthermore, while you can get away with minimal markup in HTML source files, most of the other metadata components listed in the requirements are not optional (the only thing really optional is the assertion, and that's helpful to have anyway). For example the spec links are absolutely mandatory, the build system will be using those to map tests to test suites. They're also used by Shepherd to help searching for tests and issues. As I told you previously, once you actually submit your tests, Shepherd will point out the issues with the format.

Okay.  Makes sense.

> Another issue with submitting tests in a minimal markup form is that it has the potential to introduce unnecessary diffs. Shepherd will at some point allow editing of test metadata via the web interface, when this happens, the test will be re-serialized from its DOM and will contain significantly more diffs than those required by the edit, which will be bad. Others may use other tools to edit the files and have similar results.

This should apply to any document that doesn't round-trip through
serialization, though, right?  It could be just as relevant to XHTML
1.0.  For instance, if the input file had something like:

  <p style="color: green"
     class="foo">Some text</p>

it will probably get serialized to something like:

  <p style="color: green" class="foo">Some text</p>

The diff will be smaller, but still potentially very confusing.  This
seems like a reason not to ever try to round-trip the files through
serialization.  If automated markup alteration is desired, perhaps a
better approach would be to try doing a dumb regex-based substitution
or insertion, check if the parsed DOM was modified as intended, and
fail with an error if it wasn't.

Received on Friday, 17 February 2012 16:48:59 UTC