Added more flexibility in exceptions

[plehegar]

This allows the following definitions:

{
  "css-": [
    {
      "rule": "validation.css",
      "type": "at-rule"
    }
  ],
  "css-ui-3": [
    {
      "rule": "validation.css",
      "type": "generator.unrecognize"
    }
  ]
}

Based on startsWith comparison, any shortname starting with "css-" will match the set of rules, and
css-ui-3 will take into account both set of rules (so both errors will be excluded in that case).

[deniak]

I don't think it's safe to have a set of exceptions for all the specifications starting with a specific string.
We are taking the risk to skip rules for a specification without even noticing it. There will be new shortnames in the future and who knows, another WG might want a shortname starting with css- too.
As its name suggests, exceptions should be exceptional.

I understand it makes sense for the CSS WG to have such system in place as all their specifications are affected by the CSS validator not being up-to-date but I think the validator should trigger a warning instead of an error if that's the case (eg. css-ui-3).

[plehegar]

the at-rule exception is recurring on ALL CSS drafts. How do you propose to codify that without repeating it 50 times?

[deniak]

My suggestion is to update the CSS validator so it simply reports a warning instead of an error (cc @ylafon)

[plehegar]

The error is triggered by the use of @supports , which is defined in
http://www.w3.org/TR/css3-conditional/#at-supports

[plehegar]

See also http://caniuse.com/#feat=css-featurequeries

[plehegar]

An other information bit: the official definition of CSS is in
http://www.w3.org/TR/CSS/#css
and it includes @supports

[tripu]

(Description edited, but only to format that JSON.)

[tripu]

I think I agree with @deniak on this one: we're opening the door to these exception not being exceptional at all if we allow shortname prefixes (and it's risky, as he pointed out). We do that, and soon we find ourselves allowing wildcards for validation errors, too. It'll make it almost too easy to circumvent and ignore problems in specs.

I'd rather have a list of exceptions with 50 lines like these in it

{
  "css-foo": [{"rule": "validation.css", "type": "at-rule"}],
  "css-bar": [{"rule": "validation.css", "type": "at-rule"}],
  "css-baz": [{"rule": "validation.css", "type": "at-rule"}]
}

to make it explicit that we have granted fifty exceptions to fifty specs.

Anyway, hopefully these changes in the CSS validator will be feasible soon; let's hear what @ylafon has to say!

[deniak]

I talked to @ylafon and switching from error to warning is not an easy task. He said he'd rather spend time implementing css3-conditional

[deniak]

@plehegar, I just merged #294 so I think we can close that one. Sorry I should have continued with your PR.