Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
On Mon, Nov 14, 2011 at 6:45 PM, Michael Nordman wrote: > I sure hope specific exception messages are not getting codified in specs. Many folks in the web standards community would disagree. For example, the DOM4 effort is specifying these sorts of things: http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#exception-domexception Many years of fighting web compatibility have taught us the browsers need to interoperate precisely, even in error conditions, or else silos of content will calcify around browsers that are wildly used in different market segments. The prevailing direction in the web platform today is to specify precise error handling behavior. That pendulum may well swing back towards fuzzy specs, but I somehow doubt WebSQLDatabase will be the vanguard of that reversal. > I don't see where the discussion of other browsers is relevant becaus it's > pretty clear other impls of this component aren't going to happen, yet this > remains a useful feature of webkit/chrome for the time being. It has issues > and i'd like to make it more useful. I wouldn't be too sure of that. If mobile sites persist in using WebSQLDatabase and other rendering engines want to enter the mobile market, those browser vendors will face a decision to either be at a competitive disadvantage (i.e., not support WebSQLDatabse) or to swallow their pride (i.e., implement WebSQLDatabase). History suggests which path they'll take. >From the perspective of the WebKit project, however, we don't want to make it any harder for other browser vendors to implement WebSQLDatabase, which means keeping proprietary extensions to a minimum. Of course, the ideal outcome is for these mobile sites to move away from WebSQLDatabse and to IndexedDB. > Afaict, the "platform" does define a means of expressing exceptional > conditions including a means of conveying a message that ideally provides > useful information. I'm not sure what I should read into your putting the word platform in quotation marks. My initial read is that you're mocking the web as a platform for applications, but I presume you meant to communicate something else. > I'd like to fill in that useful information part, I understand that. I'm suggesting that doing so isn't the best thing for the web platform. > "INVALID_STATE_ERR: DOM Exception 11" isn't particularly useful to anyone. > Its fair to say INVALID_STATE for many distinct low level error conditions, > there's nothing wrong with the API. My intent in starting this thread was to > determine the best way of providing a more detailed message. I don't agree > that "error messages are evil"? No one said anything about evil. They just create a testing, maintenance, and interoperability burden. Given that we'd prefer that fewer people used WebSQLDatabase (given that the other browser vendors have refused to implement it), the benefits of adding this functionality seem outweighed by the costs. > In the case of websql or indexedDB, where > there is a complex backing store of some kind that's likely different across > browsers, i think it is helpful to surface useful implementation specific > details for diagnostic and debugging purposes. Adding this feature would be a short-term benefit to some number of people. However, there is a long term cost that we need to consider as well. Adam > On Mon, Nov 14, 2011 at 5:56 PM, Adam Barth wrote: >> >> On Mon, Nov 14, 2011 at 5:41 PM, Michael Nordman >> wrote: >> > On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth wrote: >> >> >> >> For SQLException, there are a hundred exception codes reserved, >> >> >> >> static const int SQLExceptionOffset = 1000; >> >> static const int SQLExceptionMax = 1099; >> >> >> >> of which, we appear to only be using eight. It sounds like you're >> >> considering exposing more than a finite enumerated number of error >> >> codes, however. Do we really want to make SQLite error messages part >> >> of the web platform? What if we want to upgrade to a newer version of >> >> SQLite in the future (which might have different error codes)? >> >> >> >> IMHO, we shouldn't be investing much more effort into WebSQLDatabase. >> >> It's something of a dead-end for the platform. If you're set on >> >> investing more effort, one path forward is to figure out which are the >> >> most important kinds of errors to distinguish and to give them error >> >> codes. You can then give them descriptions as usual without needing >> >> any custom bindings. >> > >> > I don't want to change the set of exception 'codes' really. >> > There are significant clients of WebSQL. They can't transition to IDB >> > until >> > it's up to the task and they've made that transition. For the time >> > being, >> > I'm willing to better support websql. There are a errors in the wild and >> > figuring out what errors are "important" isn't as easy as it sounds. >> > See http://code.google.com/p/chromium/issues/detail?id=98939 about >> > "INVALID_STATE_ERR: DOM Exception 1
Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
I sure hope specific exception messages are not getting codified in specs. I don't see where the discussion of other browsers is relevant becaus it's pretty clear other impls of this component aren't going to happen, yet this remains a useful feature of webkit/chrome for the time being. It has issues and i'd like to make it more useful. >From a practical point of view, without being able to observe what error conditions are actually arising makes improvements is more difficult. My thought was to expose information about that to developers which would also make its way back to us. There are a number of APIs that accept 'errorCallbacks', the messages delivered to those callbacks already contain more detailed messages. At this point I'm looking at improving the reporting for methods that directly throw exceptions. Most notable is the openDatabase() method. A more detailed message is being logged to the console, but i'd like that to be more directed into the hands of the callers of that method. Afaict, the "platform" does define a means of expressing exceptional conditions including a means of conveying a message that ideally provides useful information. I'd like to fill in that useful information part, "INVALID_STATE_ERR: DOM Exception 11" isn't particularly useful to anyone. Its fair to say INVALID_STATE for many distinct low level error conditions, there's nothing wrong with the API. My intent in starting this thread was to determine the best way of providing a more detailed message. I don't agree that "error messages are evil"? In the case of websql or indexedDB, where there is a complex backing store of some kind that's likely different across browsers, i think it is helpful to surface useful implementation specific details for diagnostic and debugging purposes. On Mon, Nov 14, 2011 at 5:56 PM, Adam Barth wrote: > On Mon, Nov 14, 2011 at 5:41 PM, Michael Nordman > wrote: > > On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth wrote: > >> > >> For SQLException, there are a hundred exception codes reserved, > >> > >> static const int SQLExceptionOffset = 1000; > >> static const int SQLExceptionMax = 1099; > >> > >> of which, we appear to only be using eight. It sounds like you're > >> considering exposing more than a finite enumerated number of error > >> codes, however. Do we really want to make SQLite error messages part > >> of the web platform? What if we want to upgrade to a newer version of > >> SQLite in the future (which might have different error codes)? > >> > >> IMHO, we shouldn't be investing much more effort into WebSQLDatabase. > >> It's something of a dead-end for the platform. If you're set on > >> investing more effort, one path forward is to figure out which are the > >> most important kinds of errors to distinguish and to give them error > >> codes. You can then give them descriptions as usual without needing > >> any custom bindings. > > > > I don't want to change the set of exception 'codes' really. > > There are significant clients of WebSQL. They can't transition to IDB > until > > it's up to the task and they've made that transition. For the time being, > > I'm willing to better support websql. There are a errors in the wild and > > figuring out what errors are "important" isn't as easy as it sounds. > > See http://code.google.com/p/chromium/issues/detail?id=98939 about > > "INVALID_STATE_ERR: DOM Exception 11". > > > > I'd like to be able to determine two things given the exception... > callsite > > in webcore that failed and the sqlite error code seen at that callsite. > That > > would make for a large number of new codes. > > The cost of exposing detailed error information is that all browsers > that implement WebSQLDatabase will need to generate the exact same > errors in the exact same situations. Part of the reason why other > browser vendors shot down WebSQLDatabase was that it was too reliant > on implementation details of SQLite. Exposing these ad-hoc error > states as part of the platform just makes that problem worse, > especially if you're talking about a large number of error conditions, > as you seem to be. > > > If there's no general case for > > returning a custom message, a reasonable option for me may be to use > > [custom] bindings for these methods and to have that custom binding set > the > > exception message attribute accordingly. > > The issue isn't the best way of implementing this feature, the issue > is whether we should be exposing this level of implementation detail > to the platform. If we can't abstract the error conditions into a > small, finite list, there's very unlikely we'll be able to maintain > precisely the same error behavior over time, let alone specify the > behavior in sufficient detail and correctness that someone else could > implement it precisely the same way. > > Adam > > > >> On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman > >> wrote: > >> > I guess the exception of interest is SQLException. > >> > Take a look
Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
On Mon, Nov 14, 2011 at 5:41 PM, Michael Nordman wrote: > On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth wrote: >> >> For SQLException, there are a hundred exception codes reserved, >> >> static const int SQLExceptionOffset = 1000; >> static const int SQLExceptionMax = 1099; >> >> of which, we appear to only be using eight. It sounds like you're >> considering exposing more than a finite enumerated number of error >> codes, however. Do we really want to make SQLite error messages part >> of the web platform? What if we want to upgrade to a newer version of >> SQLite in the future (which might have different error codes)? >> >> IMHO, we shouldn't be investing much more effort into WebSQLDatabase. >> It's something of a dead-end for the platform. If you're set on >> investing more effort, one path forward is to figure out which are the >> most important kinds of errors to distinguish and to give them error >> codes. You can then give them descriptions as usual without needing >> any custom bindings. > > I don't want to change the set of exception 'codes' really. > There are significant clients of WebSQL. They can't transition to IDB until > it's up to the task and they've made that transition. For the time being, > I'm willing to better support websql. There are a errors in the wild and > figuring out what errors are "important" isn't as easy as it sounds. > See http://code.google.com/p/chromium/issues/detail?id=98939 about > "INVALID_STATE_ERR: DOM Exception 11". > > I'd like to be able to determine two things given the exception... callsite > in webcore that failed and the sqlite error code seen at that callsite. That > would make for a large number of new codes. The cost of exposing detailed error information is that all browsers that implement WebSQLDatabase will need to generate the exact same errors in the exact same situations. Part of the reason why other browser vendors shot down WebSQLDatabase was that it was too reliant on implementation details of SQLite. Exposing these ad-hoc error states as part of the platform just makes that problem worse, especially if you're talking about a large number of error conditions, as you seem to be. > If there's no general case for > returning a custom message, a reasonable option for me may be to use > [custom] bindings for these methods and to have that custom binding set the > exception message attribute accordingly. The issue isn't the best way of implementing this feature, the issue is whether we should be exposing this level of implementation detail to the platform. If we can't abstract the error conditions into a small, finite list, there's very unlikely we'll be able to maintain precisely the same error behavior over time, let alone specify the behavior in sufficient detail and correctness that someone else could implement it precisely the same way. Adam >> On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman >> wrote: >> > I guess the exception of interest is SQLException. >> > Take a look at Database.cpp line 103. The ' errorMessage' string on that >> > line contains more detailed information about what went wrong in the act >> > of >> > opening the database, including things like an sqlite error code and >> > sqlite >> > error message. These strings are formed in the bowls of >> > AbstractDatabase::performOpenAndVerify(). >> > >> > On Mon, Nov 14, 2011 at 4:48 PM, Adam Barth wrote: >> >> >> >> I'm not sure exactly what you're trying to do, but one option is to >> >> add a new type of DOMException: >> >> >> >> >> >> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in >> >> >> >> Another option is to customize the message from an existing exception >> >> (here are the DOMCore exceptions): >> >> >> >> >> >> >> >> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp >> >> >> >> If you show me the spec you're trying to implement, I might have a >> >> more concept suggestion of the best way to implement it. >> >> >> >> Adam >> >> >> >> >> >> On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman >> >> wrote: >> >> > I have a case where given an IDL defined method thats defined to >> >> > raise a >> >> > DOMException, I'd like to set a custom exception message from within >> >> > the >> >> > webcore implementation and have that message percolate up into script >> >> > via >> >> > the bindings layer(s) and be accessible as the exception.message >> >> > attribute. >> >> > I don't see a non-custom way of doing that and am wondering if there >> >> > should >> >> > be support for something like this w/o having to resort to custom >> >> > bindings? >> >> > The particular methods I'm looking at are the openDatabase(...) >> >> > method >> >> > of >> >> > DOMWindow and WorkerContext, but this seems like it might be useful >> >> > in >> >> > other >> >> > cases as well. >> >> > >> >> > ___ >> >> > webkit-dev mailing list >> >> > webkit-dev@lists.webkit.org >> >> > htt
Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
On Mon, Nov 14, 2011 at 5:17 PM, Adam Barth wrote: > For SQLException, there are a hundred exception codes reserved, > > static const int SQLExceptionOffset = 1000; > static const int SQLExceptionMax = 1099; > > of which, we appear to only be using eight. It sounds like you're > considering exposing more than a finite enumerated number of error > codes, however. Do we really want to make SQLite error messages part > of the web platform? What if we want to upgrade to a newer version of > SQLite in the future (which might have different error codes)? > IMHO, we shouldn't be investing much more effort into WebSQLDatabase. > It's something of a dead-end for the platform. If you're set on > investing more effort, one path forward is to figure out which are the > most important kinds of errors to distinguish and to give them error > codes. You can then give them descriptions as usual without needing > any custom bindings. > I don't want to change the set of exception 'codes' really. There are significant clients of WebSQL. They can't transition to IDB until it's up to the task and they've made that transition. For the time being, I'm willing to better support websql. There are a errors in the wild and figuring out what errors are "important" isn't as easy as it sounds. See http://code.google.com/p/chromium/issues/detail?id=98939 about "INVALID_STATE_ERR: DOM Exception 11". I'd like to be able to determine two things given the exception... callsite in webcore that failed and the sqlite error code seen at that callsite. That would make for a large number of new codes. If there's no general case for returning a custom message, a reasonable option for me may be to use [custom] bindings for these methods and to have that custom binding set the exception message attribute accordingly. > Adam > > > On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman > wrote: > > I guess the exception of interest is SQLException. > > Take a look at Database.cpp line 103. The ' errorMessage' string on that > > line contains more detailed information about what went wrong in the act > of > > opening the database, including things like an sqlite error code and > sqlite > > error message. These strings are formed in the bowls of > > AbstractDatabase::performOpenAndVerify(). > > > > On Mon, Nov 14, 2011 at 4:48 PM, Adam Barth wrote: > >> > >> I'm not sure exactly what you're trying to do, but one option is to > >> add a new type of DOMException: > >> > >> > http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in > >> > >> Another option is to customize the message from an existing exception > >> (here are the DOMCore exceptions): > >> > >> > >> > http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp > >> > >> If you show me the spec you're trying to implement, I might have a > >> more concept suggestion of the best way to implement it. > >> > >> Adam > >> > >> > >> On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman > >> wrote: > >> > I have a case where given an IDL defined method thats defined to > raise a > >> > DOMException, I'd like to set a custom exception message from within > the > >> > webcore implementation and have that message percolate up into script > >> > via > >> > the bindings layer(s) and be accessible as the exception.message > >> > attribute. > >> > I don't see a non-custom way of doing that and am wondering if there > >> > should > >> > be support for something like this w/o having to resort to custom > >> > bindings? > >> > The particular methods I'm looking at are the openDatabase(...) method > >> > of > >> > DOMWindow and WorkerContext, but this seems like it might be useful in > >> > other > >> > cases as well. > >> > > >> > ___ > >> > webkit-dev mailing list > >> > webkit-dev@lists.webkit.org > >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > >> > > >> > > > > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
For SQLException, there are a hundred exception codes reserved, static const int SQLExceptionOffset = 1000; static const int SQLExceptionMax = 1099; of which, we appear to only be using eight. It sounds like you're considering exposing more than a finite enumerated number of error codes, however. Do we really want to make SQLite error messages part of the web platform? What if we want to upgrade to a newer version of SQLite in the future (which might have different error codes)? IMHO, we shouldn't be investing much more effort into WebSQLDatabase. It's something of a dead-end for the platform. If you're set on investing more effort, one path forward is to figure out which are the most important kinds of errors to distinguish and to give them error codes. You can then give them descriptions as usual without needing any custom bindings. Adam On Mon, Nov 14, 2011 at 4:58 PM, Michael Nordman wrote: > I guess the exception of interest is SQLException. > Take a look at Database.cpp line 103. The ' errorMessage' string on that > line contains more detailed information about what went wrong in the act of > opening the database, including things like an sqlite error code and sqlite > error message. These strings are formed in the bowls of > AbstractDatabase::performOpenAndVerify(). > > On Mon, Nov 14, 2011 at 4:48 PM, Adam Barth wrote: >> >> I'm not sure exactly what you're trying to do, but one option is to >> add a new type of DOMException: >> >> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in >> >> Another option is to customize the message from an existing exception >> (here are the DOMCore exceptions): >> >> >> http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp >> >> If you show me the spec you're trying to implement, I might have a >> more concept suggestion of the best way to implement it. >> >> Adam >> >> >> On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman >> wrote: >> > I have a case where given an IDL defined method thats defined to raise a >> > DOMException, I'd like to set a custom exception message from within the >> > webcore implementation and have that message percolate up into script >> > via >> > the bindings layer(s) and be accessible as the exception.message >> > attribute. >> > I don't see a non-custom way of doing that and am wondering if there >> > should >> > be support for something like this w/o having to resort to custom >> > bindings? >> > The particular methods I'm looking at are the openDatabase(...) method >> > of >> > DOMWindow and WorkerContext, but this seems like it might be useful in >> > other >> > cases as well. >> > >> > ___ >> > webkit-dev mailing list >> > webkit-dev@lists.webkit.org >> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev >> > >> > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
I guess the exception of interest is SQLException. Take a look at Database.cpp line 103. The ' errorMessage' string on that line contains more detailed information about what went wrong in the act of opening the database, including things like an sqlite error code and sqlite error message. These strings are formed in the bowls of AbstractDatabase::performOpenAndVerify(). On Mon, Nov 14, 2011 at 4:48 PM, Adam Barth wrote: > I'm not sure exactly what you're trying to do, but one option is to > add a new type of DOMException: > > http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in > > Another option is to customize the message from an existing exception > (here are the DOMCore exceptions): > > > http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp > > If you show me the spec you're trying to implement, I might have a > more concept suggestion of the best way to implement it. > > Adam > > > On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman > wrote: > > I have a case where given an IDL defined method thats defined to raise a > > DOMException, I'd like to set a custom exception message from within the > > webcore implementation and have that message percolate up into script via > > the bindings layer(s) and be accessible as the exception.message > attribute. > > I don't see a non-custom way of doing that and am wondering if there > should > > be support for something like this w/o having to resort to custom > bindings? > > The particular methods I'm looking at are the openDatabase(...) method of > > DOMWindow and WorkerContext, but this seems like it might be useful in > other > > cases as well. > > > > ___ > > webkit-dev mailing list > > webkit-dev@lists.webkit.org > > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > > > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
I'm not sure exactly what you're trying to do, but one option is to add a new type of DOMException: http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMExceptions.in Another option is to customize the message from an existing exception (here are the DOMCore exceptions): http://trac.webkit.org/browser/trunk/Source/WebCore/dom/DOMCoreException.cpp If you show me the spec you're trying to implement, I might have a more concept suggestion of the best way to implement it. Adam On Mon, Nov 14, 2011 at 4:44 PM, Michael Nordman wrote: > I have a case where given an IDL defined method thats defined to raise a > DOMException, I'd like to set a custom exception message from within the > webcore implementation and have that message percolate up into script via > the bindings layer(s) and be accessible as the exception.message attribute. > I don't see a non-custom way of doing that and am wondering if there should > be support for something like this w/o having to resort to custom bindings? > The particular methods I'm looking at are the openDatabase(...) method of > DOMWindow and WorkerContext, but this seems like it might be useful in other > cases as well. > > ___ > webkit-dev mailing list > webkit-dev@lists.webkit.org > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Custom exception messages for IDL defined methods that raise DOMException.
I have a case where given an IDL defined method thats defined to raise a DOMException, I'd like to set a custom exception message from within the webcore implementation and have that message percolate up into script via the bindings layer(s) and be accessible as the exception.message attribute. I don't see a non-custom way of doing that and am wondering if there should be support for something like this w/o having to resort to custom bindings? The particular methods I'm looking at are the openDatabase(...) method of DOMWindow and WorkerContext, but this seems like it might be useful in other cases as well. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] vertical text
On Nov 11, 2011, at 7:59 AM, Cary Clark wrote: > Thanks for the answer, Dave. That makes perfect sense. > > Why is it that the graphics context is rotated but the advances supplied to > Font::DrawGlyphs in the GlyphBuffer aren't? > Right now fonts are broken up into two categories: ones that are considered "vertical" and ones that are considered "horizontal", but a "vertical" font uses a text-orientation-specific fallback when the glyphs are known to have flexible orientation, e.g., they could render upright or sideways depending on the value of the text-orientation property. The default value of text-orientation is vertical-right, meaning that these flexibly oriented glyphs should render rotated in a vertical text environment. However, because we rotated the graphics context, we are able to simply use the horizontal version of the font data in this case, and this allows us to reduce memory usage and re-use all the cached horizontal font information. Therefore the flexible glyph advances are unrotated and are just the horizontal font data information. Instead we rotate the glyphs that are always locked to an upright orientation in a vertical text environment. Those advances are the ones that are rotated. In effect you have a double rotation (the graphics context rotates, and then the inflexible glyphs get rotated again when drawing). This may seem backwards and somewhat confusing, but I can assure you we'd have to write way more code if we flipped things around (and we'd consume 2x the memory for glyph width storage for English letters). dave (hy...@apple.com) ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting w3c ref tests and changing our convention
On 11/14/11 12:07 PM, "Ryosuke Niwa" wrote: > On Mon, Nov 14, 2011 at 11:41 AM, Darin Adler wrote: >> We may find we can automate (3) with a script. It sounds pretty mechanical. > > It appears that W3C mandates author name, etc... be included in the meta data > as well but I guess we can add something like "WebKit Community" or "WebKit > Authors"? W3C folks told us we can create a WebKit directory under submissions > so we can put all tests we export from our layout tests suite there with some > canonical author name. AFAIK the mandate is only that there be an author link with a title and an appropriate href. There are many examples of tests with only this author data: http://microsoft.com/"; /> So I assume something like this would be fine for WebKit submissions: http://webkit.org/"; /> Tests can have more than one author link if anyone wants to add additional contact info. Alan ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting w3c ref tests and changing our convention
On Mon, Nov 14, 2011 at 11:41 AM, Darin Adler wrote: > > We may find we can automate (3) with a script. It sounds pretty mechanical. > It appears that W3C mandates author name, etc... be included in the meta data as well but I guess we can add something like "WebKit Community" or "WebKit Authors"? W3C folks told us we can create a WebKit directory under submissions so we can put all tests we export from our layout tests suite there with some canonical author name. For (2), I would name the reference files *-expected.html to fit in with > other formats of expected results such as *-expected.txt and *-expected.png. > I'm sure this was discussed in length when we first implemented reftests, but the problem with that name convention is that some ref-tests expect the actual result to differ from the reference fie. That's why we currently use -match.html / -mismatch.html Given W3C test suites use -ref.html and -noref.html, it seems more natural for us to follow their naming convention. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Supporting w3c ref tests and changing our convention
On Nov 11, 2011, at 4:24 AM, Tor Arne Vestbø wrote: > On 07.11.11 15:44, Alan Stearns wrote: >> What if we defer some of the W3C metadata work until tests were actually >> submitted to the W3C? >> >> 1. Tests we pull from W3C can run from manifests, since they are provided. >> >> 2. Tests we develop ourselves just use a naming convention (refs are named >> *-ref.html, and there's one ref per test even if that's duplicative) >> >> 3. When we choose to share a set of tests with the W3C, we do the extra work >> of adding metadata to the tests and possibly refactoring to reduce the >> number of -ref files. Once the W3C approves the tests we pull their copies >> and delete ours. > > I think this is the "best of both worlds" approach Yes, I support this proposal too. We may find we can automate (3) with a script. It sounds pretty mechanical. For (2), I would name the reference files *-expected.html to fit in with other formats of expected results such as *-expected.txt and *-expected.png. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
