On Jul 21, 2010, at 5:24 PM, Ojan Vafai wrote:
Opera 10.6: blur, domfocusout, focus, domfocusin
Moves activeElement immediately before firing any events.
WebKit nightly: blur, (dom)focusout, focus, (dom)focusin
Clears activeElement before blur/focusout, sets active element before
On Wed, Jul 21, 2010 at 5:24 PM, Ojan Vafai o...@chromium.org wrote:
Opera 10.6: blur, domfocusout, focus, domfocusin
Moves activeElement immediately before firing any events.
WebKit nightly: blur, (dom)focusout, focus, (dom)focusin
Clears activeElement before blur/focusout, sets active
On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler da...@apple.com wrote:
Sounds like some differences are:
1) The blur event in Opera and IE will see the new focused node as the
active element, but in WebKit and Firefox will see no active element at all.
2) Same for DOMFocusOut, but IE and
Hi all:
I'm now working on porting Webkit/Gtk+ to DirectFB/Gtk+ of
freescale i.MX27ADS board.
Cross compile is passed, and GtkLauncher can be running. But it
seems that with 64M ram, the demo will crash when load website. With
128M ram, it will be OK.
I wonder what is the minimum
Would someone from Apple be willing to run the patch below though the
PLT? We're doing well on our parsing benchmark (4% speedup), but the
PLT might have a different mix of HTML.
Thanks,
Adam
diff --git a/WebCore/html/HTMLTreeBuilder.cpp b/WebCore/html/HTMLTreeBuilder.cpp
index
Thanks a lot for the feedback!
On Sun, Jul 25, 2010 at 5:07 PM, Maciej Stachowiak m...@apple.com wrote:
I think the key question here is what counts as as formatting. That needs
to be determined empirically by testing other browsers, not just by reading
their docs.
I agree, it's crucial
I can do this.
-- Stephanie Lewis
On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
Would someone from Apple be willing to run the patch below though the
PLT? We're doing well on our parsing benchmark (4% speedup), but the
PLT might have a different mix of HTML.
Thanks,
Adam
diff
On Jul 26, 2010, at 11:46 AM, Ryosuke Niwa wrote:
Thanks a lot for the feedback!
On Sun, Jul 25, 2010 at 5:07 PM, Maciej Stachowiak m...@apple.com wrote:
I think the key question here is what counts as as formatting. That needs
to be determined empirically by testing other browsers, not
Thanks!
On Mon, Jul 26, 2010 at 9:36 PM, Stephanie Lewis sle...@apple.com wrote:
I can do this.
-- Stephanie Lewis
On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
Would someone from Apple be willing to run the patch below though the
PLT? We're doing well on our parsing benchmark (4%
If tests you write only require comparing DOMs, you want to read this.
We've recently added dump-as-markup. It allows your tests to be platform
independent and gives output that is easier to read than render tree dumps.
For example, if I have:
script src=../../resources/dump-as-markup.js/script
That looks similar to the dom2string library from HTML5lib.
dom2string makes DOM dumps that look like the following:
!DOCTYPE htmllihelloliworldulhowlido/ulyou/body!--do--
| !DOCTYPE html
| html
| head
| body
| li
| hello
| li
| world
| ul
| how
| li
There is another DOM dump format which the html5lib tests use:
http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected-html5.txt
Note, it's a DOM Dump, not a Markup dump, but it serves a similar purpose.
I I think I like the html5lib format better for a few reasons:
1. All
Thinking about it more, I'm not sure markup is as useful as DOM is.
We should have tests which test our DOM-Markup serialization. Maybe
all the editing tests want that. But I think most tests just want to
test the DOM, which (as demonstrated by the html5lib tests) can be
sterilized in a shorter
On Jul 26, 2010, at 3:06 PM, Ryosuke Niwa wrote:
If tests you write only require comparing DOMs, you want to read this.
We've recently added dump-as-markup. It allows your tests to be platform
independent and gives output that is easier to read than render tree dumps.
For example, if I
I like the idea of standardizing the dump output and the dumping code for
that matter. If we can resolve the below, then we can make sure all the
dumping logic in dom2string gets moved into dump-as-markup and standardize
on that. As best I can tell, there's only 2 uses of dom2string.
There is
You can see many more examples of dom2string in the non-html5 results
(where there are a zillion failure cases):
http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected.txt
dom2string.js came from http://code.google.com/p/html5lib I thought,
but I couldn't find the source for it
On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak m...@apple.com wrote:
I agree. We should test and see what other browsers do in various cases.
But since it's impossible for us to enumerate every possible formatting, I
propose to just remove text-decoration, font-weight, etc... and the
Filed as Bug 43017 - removeFormant needs to be
reimplementedhttps://bugs.webkit.org/show_bug.cgi?id=43017
.
Best,
Ryosuke
On Mon, Jul 26, 2010 at 4:27 PM, Ryosuke Niwa rn...@webkit.org wrote:
On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak m...@apple.com wrote:
I agree. We should test
On Jul 26, 2010, at 4:27 PM, Ryosuke Niwa wrote:
On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak m...@apple.com wrote:
I agree. We should test and see what other browsers do in various cases.
But since it's impossible for us to enumerate every possible formatting, I
propose to just
On Jul 26, 2010, at 4:25 PM, Eric Seidel wrote:
You can see many more examples of dom2string in the non-html5 results
(where there are a zillion failure cases):
http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected.txt
dom2string.js came from
On Mon, Jul 26, 2010 at 8:22 PM, Maciej Stachowiak m...@apple.com wrote:
On Jul 26, 2010, at 4:25 PM, Eric Seidel wrote:
You can see many more examples of dom2string in the non-html5 results
(where there are a zillion failure cases):
Then again it should be possible to re-write our script-test support
so that this is all you need to write:
script src=script-tests.js/script
script
description(foo);
shouldBe(foo, bar);
/script
script src=end-script-test.js/script
Instead of the current (cumbersome) templating system.
On Jul 26, 2010, at 5:46 PM, Ojan Vafai wrote:
Then again it should be possible to re-write our script-test support
so that this is all you need to write:
script src=script-tests.js/script
script
description(foo);
shouldBe(foo, bar);
/script
script src=end-script-test.js/script
There are a few concerns on the table:
1. We don't match the DOM3 spec. I'm not too worried about this. Neither
does anyone else. We could probably get the spec to change if noone is going
to implement it as is.
2. We don't match other browsers. It's not clear to me what changes are
worth making
24 matches
Mail list logo
