[Webkit-unassigned] [Bug 66295] [Meta] Support w3c reftests

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=66295





--- Comment #19 from Hayato Ito <hayato at chromium.org>  2011-11-03 10:43:24 PST ---
For better communication, we should have good names for each 'reftests'. Lets call that.
1. 'non-w3c reftests', which is already supported in WebKit.
2. 'w3c reftests'

The naming convention of '-expected.html' and '-expected-mismatch.html' came from the discussion of  bug 36065. That convention should only be used for non-w3c reftests.
At that time of the discussion, w3c reftests format had not appeared.

'-ref.html' and '-notref.html' convention should be preserved for w3c reftests.
Once we can support w3c reftests, there is no reason to write non-w3c reftests for new tests.
'non-w3c reftests' should be deprecated.


(In reply to comment #18)
> (In reply to comment #9)
> > We could probably get away with only reading the file to look for the links if the don't find a text (or audio) baseline. In addition, it looks like the WG is recommending that the reference files be named as -ref.html or -notref.html, so we could check for the existence of those filenames as well and only parse the file looking for a link as a last resort.
> 
> Makes sense to me. I'm sure this would completely mitigate the potential performance hit.
> 
> To your second point, if the W3C versions use -ref.html and -notref.html, perhaps we should rename ours from -expected.html and -expected-mismatch.html. I've found that everyone I explain reftests to is a little confused by these names. -ref and -notref might be more clear since it's clearly about reftesting.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.