HI,
I'd like to announce / document the existence of two public repositories for Prince-related scripts and test cases:

The "miscellaneous testcases" repo is a collection of tests based on sample code from the forum and from various issues and bugs Prince has had in the past. All files are modified to make it as obvious as possible what the correct rendering is - for example coded to output "PASS" or "FAIL".

https://github.com/yeslogic/miscellaneous-testcases

The "prince scripts" repo is all but empty still, but the intention is to gather and publish useful scripts and snippets - for example stopgap compatibility helpers that can be used to make script libraries that otherwise wouldn't work run in Prince.

https://github.com/yeslogic/prince-scripts/

I hope we'll curate some interesting stuff here - and all contributions are of course welcome.

-Hallvord

PS: I have not really introduced myself. I live in Oslo, Norway, and contribute to Prince on a part-time basis doing QA, analysis of web pages and JavaScript Prince doesn't handle well, and some random customer support through these fora. I have done similar work for Opera Software and Mozilla in the past. So far it has been fun and interesting, and I remain very impressed by YesLogic's small team for managing to implement so much of the Web Platform. They don't support absolutely everything, but then the missing bits and pieces are for me to find and help prioritise

Announcement: repos for tests/utils

Thanks for putting those up!

> The "miscellaneous testcases" repo is a collection of tests based on sample code from the
> forum and from various issues and bugs Prince has had in the past. All files are modified to
> make it as obvious as possible what the correct rendering is - for example coded to output
> "PASS" or "FAIL".

Have you or Prince developers considered submitting those tests (or a significant part of those tests) to the correspondent CSS Test suites?

Gérard

Hi Gérard,

We've considered releasing parts of our internal test suite for the CSS Tests. While we support the idea and plan to do so, it's a non-trivial amount of work as I'm sure you'll understand. I can't give you a timeframe on this, sorry.

Mark

I'd be happy to help with this. I've written a few tests for GCPM, but so much more needs to be done!

Thanks,

Dave Cramer
CSSWG

Mark,

https://github.com/yeslogic/miscellaneous-testcases/tree/master/layout

has 40 tests and

https://github.com/yeslogic/miscellaneous-testcases/tree/master/generated-content

has 1 test.

Regarding Prince's internal test suite of CSS tests, CSS tests involving vendor-prefixed properties (and vendor-prefixed property values) are not welcomed and tests involving at-risk properties should not be submitted (not or less recommendable).

> we support the idea and plan to do so, it's a non-trivial amount of work

There is no rush, no pressure from me.

Gérard

By "internal" I just mean those that aren't publicly available, not ones using Prince-specific properties. And yes, selecting appropriate tests that are only testing the specs and don't depend on Prince is part of the work I was referring to.

I have glanced at the code of a dozen of tests and several adjustments would have to be done on tests in order to comply with test writing guidelines and other code requirements.

Gérard

As the OP says, the tests are based on forum posts, which don't generally meet WPT guidelines. We don't want to require contributions to the repository to meet WPT guidelines either. Generally the tests here would be expected to be specific to Prince.

Edited 25 Sep 2017 by markbrown

Hi Gérard, early days yet for this repository. I don't know if any of these tests so far are of interest to the WPT suite, and my main concern is that it might be rather time consuming to find out if any given test is "new" and interesting or just covers ground that a lot of existing tests cover. That said I'd personally be happy to contribute, and since the repository is still small it's also easy to adjust the contents to be better aligned with the guidelines. I suppose you mean the documentation found on http://web-platform-tests.org/ ?

Naturally, these tests will tend to focus on pagination, media=print and things that may not be well covered in the existing tests.

Announcement: repos for tests/utils

> I don't know if any of these tests so far are of interest to the WPT suite

The general rule with regard to your statement is: if any of the 3 major mainstream rendering engine (Gecko [Firefox], Edge [MS-Edge], webkit [Chrome, Safari]) fail one of your CSS test in your public (or non-public) available repository, then such test would be of interest.

> since the repository is still small it's also easy to adjust the contents to be better aligned
> with the guidelines

Some quick feedback (overall, the tests are good quality).

If the test is a reftest, then there is no need to do CSS 0-resets. The reference file, just like the test, should use/rely on the UA default values.

General rule: avoid CSS 0-reset... unless of course there is a reason to.
eg
body {
background: #fff;
margin: 0;
padding: 0;
font-family: Arial, Helvetica, sans-serif;
font-weight: normal;
}
are 5 unneeded, unnecessary declarations.

Tests should be minimized. Tests should try to only use the properties, containment needed for test, for what the test is supposed to be testing, claiming to be checking. Tests should avoid extraneous containers.

eg in /layout/column-count-column-span-and-page-breaks-001.htm :
I would say that <div class="outerContainer"> duplicates what <body> does already. So, I would remove such container (remove lines 23 and 56). line 7 would become "body {".
line 11 would become: "h1 {".

eg in master/layout/column-span-margin-inheritance-003.htm (this test is interesting..)
The best first node inside the <head> section in HTML5 document should be the <meta charset="...">: we want user agents to know as earliest as possible about the character encoding.
line 9: media="all" : not a mistake but not needed since media="all" is the default.
colors and background colors: personally, I prefer named colors (instead of #RGB): that way, I do not have to think and review is easier.
line 31: column-gap: 0;
line 32: column-rule: 20px normal #fff; Is this intended? normal is not a border-style. Anyway, those 2 declarations are not part of the test, so I would remove them.

- - - - - - -

specific media=print related tests have the following guidelines:

They must have: <meta name="flags" content="page">

For multiple pages, we usually start print-related test with the preliminary:

"
PREREQUISITE: Switch to print preview or a page media view of the page.

Test passes if only and exactly N pages are printed and if ...
"

and then follow-up with other pass-fail-conditions if the test requires more.

- - - - - - -

The guidelines for CSS tests are:

Writing Tests
http://web-platform-tests.org/writing-tests/

General Test Guidelines
http://web-platform-tests.org/writing-tests/general-guidelines.html

Test Review Checklist
http://web-platform-tests.org/reviewing-tests/checklist.html

Test Templates
http://web-platform-tests.org/appendix/test-templates.html

Writing Reftests
http://web-platform-tests.org/writing-tests/reftests.html

Gérard