Document URL parameters for HTML Runner

[gibson042]

Assuming the QUnit URL parameters are to be treated as part of the public interface (rather than just a mechanism for conveying GUI interactions to subsequent loads), we should document them:

• filter → QUnit.config.filter
• seed → QUnit.config.seed (boolean true replaced with a random string)
• module (QUnit.config relation to be determined by Reintroduce QUnit.config.module or QUnit.config.moduleFilter #956)
• testId → QUnit.config.testId (splitting on commas until Document and prefer multiply-specified URL parameters over comma-separated #954 is resolved)
• moduleId → QUnit.config.moduleId (splitting on commas until Document and prefer multiply-specified URL parameters over comma-separated #954 is resolved)
• hidepassed → QUnit.config.hidepassed (HTML reporter boolean option)
• noglobals → QUnit.config.noglobals
• notrycatch → QUnit.config.notrycatch
• user-defined by QUnit.urlConfig → QUnit.config[id]

[gibson042]

Since this issue is getting hot, I think it's worth asking if all of those parameters are to be treated as public interface... in short, do we feel comfortable with encouraging manually-constructed URLs and not breaking them between major releases?

For my own part, I say "yes".

[trentmwillis]

do we feel comfortable with encouraging manually-constructed URLs and not breaking them between major releases?

I vote "yes" as well, and know that most developers I work with do manually construct urls currently anyway.

With that said, I'm not sure we should keep both module and moduleId as they seem redundant. I'll add more context to that in the appropriate issue.

[leobalter]

aye

[leobalter]

I'm not sure we should keep both module and moduleId as they seem redundant.

for now, I prefer keeping both. It's good to get feedback on their uses as I believe module=<name> might still be better for some particular and manual usages, but moduleId is good for interface use.

Using only one is good for keeping QUnit lean, but we can handle this.