Re: [webkit-dev] focusin/focusout events

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 he

Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)

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: > > > > description("foo"); > shouldBe("foo", "bar"); > > > > Instead of the current (cumbersome) templating system. Should be > po

Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)

> > Then again it should be possible to re-write our script-test support > so that this is all you need to write: > > > > description("foo"); > shouldBe("foo", "bar"); > > > > Instead of the current (cumbersome) templating system. Should be > possible to even get rid of the final "end-script-t

Re: [webkit-dev] Auto-injecting JavaScript with DRT (was Introducing dumpAsMarkup)

On Mon, Jul 26, 2010 at 8:22 PM, Maciej Stachowiak 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): >> http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner

Re: [webkit-dev] Introducing dumpAsMarkup

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 http://code.google.com/

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.

On Jul 26, 2010, at 4:27 PM, Ryosuke Niwa wrote: > > On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak 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 remov

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.

Filed as Bug 43017 - removeFormant needs to be reimplemented . Best, Ryosuke On Mon, Jul 26, 2010 at 4:27 PM, Ryosuke Niwa wrote: > > On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak wrote: >> >> I agree. We should test and see what other brow

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.

On Mon, Jul 26, 2010 at 1:10 PM, Maciej Stachowiak 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 > correspond

Re: [webkit-dev] Introducing dumpAsMarkup

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

Re: [webkit-dev] Introducing dumpAsMarkup

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 anot

Re: [webkit-dev] Introducing dumpAsMarkup

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

Re: [webkit-dev] Introducing dumpAsMarkup

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 shorte

Re: [webkit-dev] Introducing dumpAsMarkup

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 lowe

Re: [webkit-dev] Introducing dumpAsMarkup

That looks similar to the dom2string library from HTML5lib. dom2string makes DOM dumps that look like the following: helloworldhowdoyou | | | | | | "hello" | | "world" | | "how" | | "do" | "you" | It lets you see all the wh

[webkit-dev] Introducing dumpAsMarkup

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: This is a dumpAsMarkup test. window.getSelection().se

Re: [webkit-dev] Enabling the HTML5 tree builder soon

Thanks! On Mon, Jul 26, 2010 at 9:36 PM, Stephanie Lewis 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% speedup), bu

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.

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 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 r

Re: [webkit-dev] Enabling the HTML5 tree builder soon

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 > > > d

Re: [webkit-dev] [HTML Editing] WebKit's implementation of removeFormat is completely different from other UAs.

Thanks a lot for the feedback! On Sun, Jul 25, 2010 at 5:07 PM, Maciej Stachowiak 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 that we car

Re: [webkit-dev] Enabling the HTML5 tree builder soon

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 7a9c295..5b89c37

[webkit-dev] Webkit/Gtk+ ARM min requirement?

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 mem

Re: [webkit-dev] focusin/focusout events

On Mon, Jul 26, 2010 at 12:06 AM, Darin Adler 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 Firefox a

Re: [webkit-dev] focusin/focusout events

On Wed, 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

Re: [webkit-dev] focusin/focusout events

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 > fo