Re: [css-grid] display-grid, display-inline-grid and parsing-display-grid-inline: review request

On Nov 10, 2014, at 11:19 AM, Gérard Talbot <css21testsuite@gtalbot.org> wrote:
> 
> 
>>> With GitHub, I can not view the test as rendered in a browser (don't
>>> know how; I had to copy and save the code into an HTML editor and then
>>> open it in a browser ... not convenient!) and I can not verify things
>>> like trailing whitespace (whitespace at the end of lines) or Unicode
>>> byte order mark (BOM U+FEFF) (Shepherd is able to spot and report this,
>>> btw) and usage of Unix line endings.
>> I guess the syncbot is doing this kind of checks, but I cannot tell for
>> sure.
>> I'm talking about this kind of comments:
>> https://github.com/w3c/csswg-test/pull/626#issuecomment-62379089
> 
> This is odd..
> 
> https://github.com/w3c/csswg-test/pull/626#issuecomment-61505965
> 
> stated that your tests submitted 7 days ago passed validation
> 
> "
> syncbot commented 7 days ago
> Automatic validation checks of commit 93504e0 passed.
> "
> 
> but it sure did not pass HTML validation... I'm wondering what kind of validation GitHub is exactly doing... it could be very basic edition kind of validation...

These messages are not from GitHub, they are from Shepherd (SyncBot on GitHub). It runs the same validation checks against Pull Requests that it does on tests that are checked in to the repo.

Note that Shepherd does not perform any kind of HTML validation (like the W3C HTML validator does), since tests may require "bad" html. Neither does it look for minor issues like BOMs, tabs vs spaces, or line endings. Those are "nice to haves", but we wouldn't reject tests over them (and some tests require BOMs).

Shepherd does ensure that XHTML parses properly (as XML), and it primarily checks for the proper metadata in the test files.

> 
> 
>> There's a way to see the files directly but I think it's an external
>> service: https://rawgit.com/
>> However it's not working properly for XHTML only for HTML I've just
>> reported the issue [1].
>> Besides, the testharness.js tests won't work.
>>> Addendum
>>> ********
>>> For a reason I do not understand, locally, I must edit
>>> <script type="text/javascript" src="./resources/testharness.js"></script>
>>> <script type="text/javascript"
>>> src="./resources/testharnessreport.js"></script>
>>> because this linkage
>>> <script type="text/javascript" src="/resources/testharness.js"></script>
>>> <script type="text/javascript"
>>> src="/resources/testharnessreport.js"></script>
>>> will not work.
>> Checking other tests they're all using "/resources/testharness.js" so I
>> think I should keep it as it is.
> 
> Yes, yes. Keep using "/resources/testharness.js" as it is. I think I just experienced a particularity (environment path) setting with Linux on my system.


Yes, the script path must be "/resources/testharness.js". If you are testing on a local web server you can create an alias to serve the script at the proper url, otherwise if you're using the files directly, you can create a file system link in your root directory, ie: "ln -s /path/to/resources/repository /resources"