Sorry for the late reply, this thread flew under my radar.
I made the original name change, because I honestly was entirely confused
about the meaning of "selfOnlyRef" (it's done by Node on Document, so what
is "self"? Why is it needed?) - so I guess we'll have to agree to disagree
which one is cl
Hello all,
I am actually novice in webkit but i want to learn *make webkit (on
webkit.org) compliant with new HTML5 Tags & Features.
*Could anyone guide me through the steps to start with ?
Kindly suggest if i haven't put things inappropriately.
Thanks & Regards,
Navanshu
__
On Fri, Jun 15, 2012 at 3:18 AM, Navanshu Mahor wrote:
> Hello all,
>
> I am actually novice in webkit but i want to learn *make webkit (on
> webkit.org) compliant with new HTML5 Tags & Features.
> *Could anyone guide me through the steps to start with ?
>
> Kindly suggest if i haven't put things
On Jun 15, 2012, at 12:12 AM, Roland Steiner wrote:
> I made the original name change, because I honestly was entirely confused
> about the meaning of "selfOnlyRef" (it's done by Node on Document, so what is
> "self"? Why is it needed?)
A good rule of thumb, the one that I use, is that a name l
On Jun 15, 2012, at 7:23 AM, Ryosuke Niwa wrote:
> Filing bugs on bugs.webkit.org for things that make WebKit not compliant with
> the HTML5 specifications is a good starting point.
Another useful task is to learn to write good regression tests, and write tests
that demonstrate the problems you
On Fri, Jun 15, 2012 at 9:30 AM, Darin Adler wrote:
> On Jun 15, 2012, at 12:12 AM, Roland Steiner wrote:
>
> I made the original name change, because I honestly was entirely confused
> about the meaning of "selfOnlyRef" (it's done by Node on Document, so what
> is "self"? Why is it needed?)
>
>
On Jun 15, 2012, at 9:47 AM, Ryosuke Niwa wrote:
> // Nodes belonging to this document hold guard references -
> // these are enough to keep the document from being destroyed, but
> // not enough to keep it from removing its children. This allows a
> // node that outlives its document to still hav
On Jun 15, 2012, at 12:12 AM, Roland Steiner wrote:
> Sorry for the late reply, this thread flew under my radar.
>
> I made the original name change, because I honestly was entirely confused
> about the meaning of "selfOnlyRef" (it's done by Node on Document, so what is
> "self"? Why is it ne
On Fri, Jun 15, 2012 at 9:49 AM, Darin Adler wrote:
> On Jun 15, 2012, at 9:47 AM, Ryosuke Niwa wrote:
>
> > // Nodes belonging to this document hold guard references -
> > // these are enough to keep the document from being destroyed, but
> > // not enough to keep it from removing its children.
An update: it appears that the GTK and EFL ports have added at least
basic support for end-of-task delivery, in
http://trac.webkit.org/changeset/108628 and
http://trac.webkit.org/changeset/110568. They now pass all
MutationObserver tests. Do these tests pass in the actual browsers
built from GTK an
On Jun 15, 2012, at 10:15 AM, Maciej Stachowiak wrote:
> But it's hard to explain fully in a function name w/o excess verbosity.
I think my favorite excess verbosity version is refDocumentButNotOtherNodes.
-- Darin
___
webkit-dev mailing list
webkit-d
Before unprefixing it, can we make sure we also pass Mozilla's tests and
vice versa? Mutation events was a huge mess partially because browsers
didn't interoperate. I'd like to make sure this API interoperates well from
day 1.
- Ryosuke
On Fri, Jun 15, 2012 at 10:31 AM, Adam Klein wrote:
> An u
I was working closely with Olli Pettay when he was putting together
the tests for Firefox, and we passed all of those (as of a couple
months ago; our code hasn't changed since then). Just ran through our
tests with Firefox Aurora and everything passed modulo differences in
supported features (they
Great!
What is the difference in handling the style attribute?
Also, can we convert existing tests to use testharness.js and submit them
to W3C? That way, we can help other browser vendors implement it
"correctly" when they do. (of course, this shouldn't block unprefixing the
API)
- Ryosuke
On J
On Fri, Jun 15, 2012 at 11:15 AM, Ryosuke Niwa wrote:
> Great!
>
> What is the difference in handling the style attribute?
It's this test:
http://trac.webkit.org/browser/trunk/LayoutTests/fast/mutation/observe-attributes.html#L741
Firefox mutates the attribute even though nothing changed. Per O
Hey,
Could i get EditBugs for my bugzilla account? (pab...@motorola.com)
I'm not a commiter, but i've contributed a bunch of patches already.
Thanks!
--
pablo flouret
motorola | webkit / browser team
___
webkit-dev mailing list
webkit-dev@lists.webki
On Jun 15, 2012, at 10:31 AM, Darin Adler wrote:
> On Jun 15, 2012, at 10:15 AM, Maciej Stachowiak wrote:
>
>> But it's hard to explain fully in a function name w/o excess verbosity.
>
> I think my favorite excess verbosity version is refDocumentButNotOtherNodes.
Things I dislike about that
On Fri, Jun 15, 2012 at 12:14 PM, Maciej Stachowiak wrote:
>
> I am not sure how to get the key points across without being accurate or
> misleading. A version that I think explains the complete design without
> saying anything false or misleading:
>
>
> refTheDocumentItselfButUnlikeTheRegularRefD
On Jun 15, 2012, at 12:22 PM, Ryosuke Niwa wrote:
> On Fri, Jun 15, 2012 at 12:14 PM, Maciej Stachowiak wrote:
> I am not sure how to get the key points across without being accurate or
> misleading. A version that I think explains the complete design without
> saying anything false or mislea
Done.
Folks should feel free to ping me on #webkit rather than emailing
webkit-dev abou this sort of thing.
Adam
On Fri, Jun 15, 2012 at 12:03 PM, Pablo Flouret wrote:
> Hey,
>
> Could i get EditBugs for my bugzilla account? (pab...@motorola.com)
>
> I'm not a commiter, but i've contributed a
On Fri, Jun 15, 2012 at 12:40 PM, Maciej Stachowiak wrote:
> On Jun 15, 2012, at 12:22 PM, Ryosuke Niwa wrote:
>
> On Fri, Jun 15, 2012 at 12:14 PM, Maciej Stachowiak wrote:
>>
>> I am not sure how to get the key points across without being accurate or
>> misleading. A version that I think expl
I would like to change chromium's ImageDiff to reflect the magnitude of
pixel changes. Currently, if the pixel has any difference, the entire pixel
is marked as 100% red. I'd like to change it so that miniscule difference
are 20% red and large differences are 100% red. Looking at the code for CG,
g
On Fri, Jun 15, 2012 at 4:24 PM, Tony Payne wrote:
> I would like to change chromium's ImageDiff to reflect the magnitude of
> pixel changes. Currently, if the pixel has any difference, the entire pixel
> is marked as 100% red. I'd like to change it so that miniscule difference
> are 20% red and
On Fri, Jun 15, 2012 at 4:27 PM, Ryosuke Niwa wrote:
> On Fri, Jun 15, 2012 at 4:24 PM, Tony Payne wrote:
>
>> I would like to change chromium's ImageDiff to reflect the magnitude of
>> pixel changes. Currently, if the pixel has any difference, the entire pixel
>> is marked as 100% red. I'd like
On Fri, Jun 15, 2012 at 8:24 PM, Tony Payne wrote:
> Looking at the code for CG, gtk and Win versions of ImageDiff, I think they
> already do something similar. Is this correct?
The GTK and Efl produces a grayscale image, where the pixel goes from
black (no difference) to white, gradually, propor
On Fri, Jun 15, 2012 at 8:27 PM, Ryosuke Niwa wrote:
> People with Protanomaly like myself won't be too happy about it. I'm already
> having a really hard time finding the red pixels on diffs without zooming.
Perhaps generating a list of rectangles where there are differences
would help produce s
26 matches
Mail list logo
