Re: Simplifying metadata

On 10/27/2015 04:31 PM, Geoffrey Sneddon wrote:
>
> a) "CSS 2.1 Reference" as a <title> for potentially hundreds of references is utterly useless—I'd rather doing something more
> descriptive as to what it is. Presto-testo has titles like:
>
>   * Reference rendering - this should be green (green text)
>   * Reference rendering - There should be no red below
>   * Reference rendering - pass if F in Filler Text is upper-case
>
> This isn't perfect either, but it's more useful than "CSS 2.1 Reference", IMO.

I don't care what <title> is used on references. :)

> b) We don't need author metadata on any new tests, because that metadata is stored in git/hg. (It's essentially been entirely
> redundant since we moved away from SVN, as git/hg can store arbitrary authorship data regardless of whether the author has
> source-tree access.)

We also use it to generate the acknowledgements on the test suite cover page, btw.

I'd like to get rid of this also, but we should have some way of tracking
this information for copyright and acknowledgement purposes.

> c) We haven't actively been adding reviewer metadata for quite a while. I suggest if we *really* want reviewer metadata (which
> I'm not at all sure we do—a single file may be reviewed by multiple people, especially in the testharness.js case), we do it
> in the commit description (along the lines of Signed-Off-By in the Linux repo). On the whole, I suggest we just go by the
> assumption that anything in the repo has been reviewed (at the current time outwith work-in-progress and vendor-imports), and
> don't bother storing the metadata. It doesn't really matter—when do we need to know who reviewed the test? The current model
> can be misleading, when the test is changed there's still a "reviewed" link, but that person hasn't necessarily reviewed the
> edited test.

I'm fine with dropping this as well.

> d) Specification links I'm kinda unconvinced by, but I don't really care enough to argue over. I know Shepard uses it.

These are, as plinss points out, important to keep.

> e) Requirement flags
>
> * ahem — we should simply just state "the CSS test suite requires the Ahem font to be available" and get rid of this flag

Agree

> * animated — this is good because it has a real use (excluding tests from automated testing)

Agree

> * asis — this makes sense with the current build system

Until we drop the build system, yes. :)

> * combo — do we actually care? is anyone doing anything with this? In CI systems you likely want to run all the files, combo
> and not.

I think we should drop this, it's no longer important imho.

> * dom — sure, I suppose. not very useful for actual browsers, to be fair, so just extra overhead to release tests.

We can key off of <script> and such instead if needed.

> * font — we should simply just state "the CSS test suite requires these fonts to be installed" and get rid of this flag

I'm fine with that.

> * history — is there any UA that *doesn't* support session history? Yes, in *theory* one could exist, but if we don't know of
> one, we shouldn't optimise for it. The cost of metadata is too high (yes, even a flag!).

Yes, PDF renderers don't have history. But we can drop the flag,
I don't think this is important to track -- it's only :visited
that cares afaict.

> * http — we should just move to using the same mechanism as web-platform-tests for HTTP headers (rather than .htaccess), and
> then this can statically be determined by whether test.html.headers exists for a given test.html, leaving less metadata.

I defer to plinss on this.

> * image — like history, is this not just for a hypothetical UA?

Yeah, I think we can get rid of this, too.

> * interact — sure.

Definitely keep.

> * invalid — do we need an actual flag for this? I presume we want this for lint tools, in which case we should probably have a
> better (generic) way to silent bogus lint rules for a given test.

It's both for lint tools, but also so that the test suite can be used by validators.
So I think it's worth keeping.

> * may — on the whole reasonable

Yeah, we need this.

> * namespace — is this not just for a hypothetical UA?

Yeah, we can drop this.

> * paged — sure
> * scroll — sure

These are useful, yes.

> * speech — um, I guess

:)

> * svg — do we still want to treat SVG as something not universal?

No, I don't think we need to do that anymore. It's reasonably easy to detect
if you need that information for some reason.

> * userstyle — sure

> Also, I wonder if we should just merge "animated", "interact", and "userstyle" into one?

I don't think so. I don't think it's easier to people writing tests, either.
It's very clear to determine whether something is animated, requires interaction,
or tests a user style sheet. It's harder to say "it's not supported by our
current CI tools".

Also, I think we should loosen the restrictions on filenames to just
"if there's an index number, it must be zero-filled to 3 digits".

~fantasai

Received on Wednesday, 28 October 2015 08:27:39 UTC