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

[bugzilla-daemon at webkit.org]

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





------- Comment #118 from lkcl at lkcl.net  2008-12-31 13:53 PDT -------
mark, hi,

after reviewing and reading what HTMLAppletElement and HTMLEmbedElement are,
they are fairly low-priority HTML elements, and so the impact of them being int
or strings is minimal.

the reason why i had been so insistent that they be kept - according to the
de-facto standard that is "javascript" - is because i thought for quite some
time that these were offsetWidth and offsetHeight, of HTMLElement!

so, my case for insisting that the de-facto javascript standard be followed,
even though users will shoot themselves in the foot by doing so, still
applies - and even though we've been talking somewhat at cross-purposes
(for which i apologise) - _but_, given that it's _not_ HTMLElement
(thank god) that you're talking about, but two specific low-key elements,
i don't care enough about those to press the point.

the number of developers using DOM bindings on those elements is going to
be pretty small.  so - who cares.


toString is a different matter.

the algorithm that you describe - namely to identify those elements where
toString is offered, followed by identifying the alternate functions - i know
of a place where that algorithm is already implemented...

... it's in a project called... WEBKIT.

making every single developer who uses webkit bindings (and expects
toString to exist) _reimplement_ the functionality that _already_ exists
is... petty at best.  i can continue to think of lots of ways to say this:
none of them really get us anywhere, and leave us both wasting time
that would be better spent developing code and serving users.


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