[Webkit-unassigned] [Bug 16401] [GTK] GObject/C DOM binding

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=16401





------- Comment #190 from mrowe at apple.com  2009-04-22 03:34 PDT -------
(In reply to comment #188)
> > At this point I'm a bit perplexed as to what it will take to get this patch
> > accepted. 
> 
> likewise.  it's been nearly eight months since it was created.

That's not at all accurate.  It's been around two months since a patch that was
in a reasonable state was uploaded.  I can understand that it is disappointing
that it hasn't been reviewed in the two months since.  Personally,  I hadn't
seen this bug since it was updated in February as someone appears to have
cleared or neglected to set the review flag on the most recent iteration of the
patch, meaning that it dropped out of the review queue.  If that is set once
again then it should get a little more visibility.

> as a result of a lack of initiative from apple, i'm abandoning webkit in favour
> of gecko, having worked out that python-hulahop provides the missing link
> between gecko's DOM and python, in exactly the same way that [modified]
> pywebkitgtk provides python access to a DOM model.

Great.  I wish you the best of luck with Gecko, and I would encourage you to
contribute to and enrich their project in similar manner to how you've
contributed to and enriched WebKit.

I also hope that this decision will cause you to cease adding further
uninformed and inflammatory comments to this bug so that those who are actively
working on improving WebKit can do so without having to wade through your
ramblings.

> there has been active hostility towards making webkit language bindings
> fully de-facto standards compliance, with total and pathological silence
> as the answer when strong evidence is presented that webkit is the only web
> engine that fails to comply with modern de-facto standards.

It is an intentional design decision to treat the JavaScript behavior as what
is effectively a backwards-compatibility mode on top of the formal DOM
standards.  It's clear you don't agree with that decision, but it's ridiculous
to claim that this somehow means we're failing to comply with standards.  There
are no backwards-compatibility constraints for non-JavaScript content, so there
is nothing to comply with, and no compelling reasons to add additional baggage
to new API.

> overall, then, the possibilities for webkit are terminated by apple's
> intransigence and deliberate hostility towards de-facto standards
> compliance and support for the features that this patch provides.
>
> anyone reading this is advised think twice before using webkit until
> such time as apple get their act together.

I can't tell whether you're more upset by the fact the functionality isn't
currently available in WebKit or that Apple drives core WebKit development but
doesn't work directly on the GTK port.  A lot of your rhetoric seems to
completely ignore the actual points of discussion and instead focusses on
assigning blame to Apple.  That's an incredibly counter-productive approach to
participating in any sort of useful discussion.

> for example - to the gnome developers reading this: you made the right
> decision to pull webkit from epiphany and use gecko.

Yes, the Epiphany developers have clearly pulled WebKit and are using Gecko, as
can be seen from the recent changes at
<http://git.gnome.org/cgit/epiphany/log/>… … …


-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.