On Aug 14, 2012, at 5:41 PM, Elliott Sprehn espr...@chromium.org wrote:
The point of the vendor prefix is to assert the instability of the feature.
The WebKit project uses vendor prefixes to avoid compatibility conflict between
a feature and a later incompatible standardized feature that would
On Wed, Aug 15, 2012 at 12:55 PM, Darin Adler da...@apple.com wrote:
On Aug 14, 2012, at 5:41 PM, Elliott Sprehn espr...@chromium.org wrote:
The point of the vendor prefix is to assert the instability of the feature.
The WebKit project uses vendor prefixes to avoid compatibility conflict
Hi all,
As many of you know, we normally treat the -expected files as
regression tests rather than correctness tests; they are intended
to capture the current behavior of the tree. As such, they
historically have not distinguished between a correct failure and an
incorrect failure.
The chromium
This sounds like it's adding even more complication to an already complicated
system.
Given how many tests we currently have, I also don't buy that continuing to run
a test that is already known to fail provides much benefit. If the test covers
two things and one fails while the other
On Wed, Aug 15, 2012 at 12:27 PM, Filip Pizlo fpi...@apple.com wrote:
This sounds like it's adding even more complication to an already complicated
system.
In some ways, yes. In other ways, perhaps it will allow us to simplify
things; e.g., if we are checking in failing tests, there is much
I've received at least one bit of feedback off-list that it might not
have been clear what problems I was trying to solve and whether the
solution would add enough benefit to be worth it. Let me try to
restate things, in case this helps ...
The problems I'm attempting to solve are:
1) Chromium
It seems to me that there are two issues here. One is Chromium specific about
process conformity. It seems to me that should stay a Chromium issue without
making the mechanism more complex for all ports. The other ports seem to make
things work using the existing framework.
The other
I think this is the best compromise between the benefits of the
historically chromium approach (i.e. add to TestExpectations) and the
historically non-chromium approach (either skip the test or check in a
failing result, usually the latter). The only thing Dirk's proposal changes
for these ports
On Aug 15, 2012, at 12:27 PM, Filip Pizlo fpi...@apple.com wrote:
This sounds like it's adding even more complication to an already complicated
system.
Given how many tests we currently have, I also don't buy that continuing to
run a test that is already known to fail provides much
On Wed, Aug 15, 2012 at 1:36 PM, Michael Saboff msab...@apple.com wrote:
It seems to me that there are two issues here. One is Chromium specific
about process conformity. It seems to me that should stay a Chromium issue
without making the mechanism more complex for all ports. The other
WebKit is the only browser that implements the magic counter named
list-item and we have no tests for it. This is from the CSS3 Lists module
(http://dev.w3.org/csswg/css3-lists/). This special counter was added back
in the initial implementation of CSS counters 6 years ago.
ex.
style li:before {
On Aug 15, 2012, at 2:16 PM, Maciej Stachowiak m...@apple.com wrote:
On Aug 15, 2012, at 12:27 PM, Filip Pizlo fpi...@apple.com wrote:
This sounds like it's adding even more complication to an already
complicated system.
Given how many tests we currently have, I also don't buy that
Apparently I was somewhat unclear. Let me restate. We have the following
mechanisms available when a test fails:
1) Check in a new -expected.* file.
2) Modify the test.
3) Modify a TestExpectations file.
4) Add the test to a Skipped file.
5) Remove the test entirely.
I have no problem
Can I remove this feature?
See http://trac.webkit.org/wiki/DeprecatingFeatures
It would be nice to first have some usage data.
Benjamin
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev
Since it sounds like it doesn't do anything, then yes. Removing it
sounds like the correct course of action. Someone who later
implements ::marker or lands CSS3-list tests, can revert your patch.
On Wed, Aug 15, 2012 at 2:29 PM, Elliott Sprehn espr...@chromium.org wrote:
WebKit is the only
On Aug 15, 2012, at 2:29 PM, Elliott Sprehn espr...@chromium.org wrote:
WebKit is the only browser that implements the magic counter named
list-item and we have no tests for it.
Seems like we really ought to add some tests for it.
It's not useful since we don't support the ::marker pseudo
On Wed, Aug 15, 2012 at 3:06 PM, Filip Pizlo fpi...@apple.com wrote:
Apparently I was somewhat unclear. Let me restate. We have the following
mechanisms available when a test fails:
1) Check in a new -expected.* file.
2) Modify the test.
3) Modify a TestExpectations file.
4) Add the
On Aug 15, 2012, at 4:02 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Aug 15, 2012 at 3:06 PM, Filip Pizlo fpi...@apple.com wrote:
Apparently I was somewhat unclear. Let me restate. We have the following
mechanisms available when a test fails:
1) Check in a new -expected.* file.
I have a concern that a lot of people wouldn't know what the correct
output is for a given test.
For a lot of pixel tests, deciding whether a given output is correct or not
is really hard. e.g. some seemingly insignificant anti-alias different may
turn out be a result of a bug in Skia and other
On Wed, Aug 15, 2012 at 5:00 PM, Filip Pizlo fpi...@apple.com wrote:
On Aug 15, 2012, at 4:02 PM, Dirk Pranke dpra...@chromium.org wrote:
On Wed, Aug 15, 2012 at 3:06 PM, Filip Pizlo fpi...@apple.com wrote:
Apparently I was somewhat unclear. Let me restate. We have the following
On Wed, Aug 15, 2012 at 5:00 PM, Filip Pizlo fpi...@apple.com wrote:
I believe that the cognitive load is greater than any benefit from
catching bugs incidentally by continuing to run a (1-fail) or (3) test, and
continuing to evaluate whether or not the expectation matches some notions
of
The typical approach used in situations that you describe is to rebase, not
skip. This avoids the problem of not knowing when the test started passing.
Hence, I'm not sure what you're implying. Maybe a better example would help.
On Aug 15, 2012, at 5:39 PM, Peter Kasting
On Wed, Aug 15, 2012 at 5:45 PM, Filip Pizlo fpi...@apple.com wrote:
The typical approach used in situations that you describe is to rebase,
not skip.
Which is precisely what Dirk is proposing. Literally the only difference
here is that the rebased test expectation would contain an optional
On Aug 15, 2012, at 5:51 PM, Peter Kasting pkast...@chromium.org wrote:
On Wed, Aug 15, 2012 at 5:45 PM, Filip Pizlo fpi...@apple.com wrote:
The typical approach used in situations that you describe is to rebase, not
skip.
Which is precisely what Dirk is proposing. Literally the only
On Wed, Aug 15, 2012 at 6:02 PM, Filip Pizlo fpi...@apple.com wrote:
2) Possibility of the sheriff getting it wrong.
(2) concerns me most. We're talking about using filenames to serve as a
kind of unchecked comment. We already know that comments are usually bad
because there is no
I also thought about what you said. But I'm not sure whether WTF::Function
will be used for cross thread communication only.
So, I'd like to know whether WTF::Function won't be used for single
threaded case.
On Tue, Aug 14, 2012 at 8:57 AM, KwangYul Seo sk...@company100.net wrote:
Currently,
26 matches
Mail list logo
