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

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Fri Oct 17 16:52:52 PDT 2008


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





------- Comment #90 from lkcl at lkcl.net  2008-10-17 16:52 PDT -------
(In reply to comment #85)
> (In reply to comment #50)
> > --- WebCore/html/HTMLEmbedElement.idl   (revision 36459)
> > +++ WebCore/html/HTMLEmbedElement.idl   (working copy)
> > @@ -30,7 +30,7 @@
> >          ImplementationUUID=93e0407a-8380-4ff0-978d-f773f2dee6a3
> >      ] HTMLEmbedElement : HTMLElement {
> >                   attribute [ConvertNullToNullString] DOMString align;
> > -#if defined(LANGUAGE_JAVASCRIPT)
> > +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT)
> >                   attribute [ConvertNullToNullString] DOMString height;
> >  #else
> >                   attribute [ConvertFromString] long height;
> > @@ -38,7 +38,7 @@
> >                   attribute [ConvertNullToNullString] DOMString name;
> >                   attribute [ConvertNullToNullString] DOMString src;
> >                   attribute [ConvertNullToNullString] DOMString type;
> > -#if defined(LANGUAGE_JAVASCRIPT)
> > +#if defined(LANGUAGE_JAVASCRIPT) || defined(LANGUAGE_GOBJECT)
> >                   attribute [ConvertNullToNullString] DOMString width;
> >  #else
> >                   attribute [ConvertFromString] long width;
> > 
> > 
> > 
> > exact same functionality as javascript is required.  an int width
> > and an int height is of absolutely no use.
> > 
> > pyjamas-desktop needs to be able to set width and height to what
> > _javascript_ does - not objectiveC.
> > 
> > i.e. "100%".  "10em".  "20px".
> 
> The width and height properties of the DOM specification are defined as being
> longs, so that is what they should be exposed to all bindings as. 

 wrong.  absolutely wrong.  if in the "real world", because of javascript -
exactly as you say - people pass in things OTHER than integers, then the DOM
specification can take a hike!

> JavaScript
> is a special case as there is the requirement for compatibility with the
> millions of real-world web pages that were coded to the initial implementations
> of the DOM in browsers that did not adhere to the spec.

 and thus this is EXACTLY the reason why the glib bindings MUST, i repeat,
 MUST, i repeat MUST provide EXACTLY the same functionality.

 how are we supposed to tell people, "if you port your application from
javascript to use a high-level-language that binds to webkit-glib bindings, you
can do everything you expect to be able to do in javascript.... oh, _except_
you can't use "20px", you _have_ to specify "20", and you can't use "100%", you
have to work out the percentage yourself".

no, no, no and no.




> It's worth noting that setting the .width or .height properties of a
> HTMLEmbedElement to "10em", "10en", or any other value followed by a CSS unit
> is unlikely to do what you think.

 ... how intriguing.

i've never _used_ em or en in any apps, but _have_ used px and %, and found
them to work in all cases where they're used, and found them to work as
expected.


> > the integer-only parameters are no use to anyone wishing to maintain
> > line-for-line javascript equivalent functionality, which is what
> > pyjamas-desktop is about: ripping out the javascript and replacing it with
> > exact-equivalent code, written in python instead of javascript.
> 
> That may be what your project is about,

 it's "my" project, it's _a_ project that i happen to be
 working on, at present.

 let's reinterpret this sentence, and go from there:

> That may be what that one example project is about,

 yes, it's one example - that demonstrates why it is necessary to follow
 javascript's lead, rather than a rigid (and ignored) standard.

 the _very fact_ that people have ignored the DOM specification _immediately_
says that the glib bindings MUST expose EXACTLY the same functionality as
javascript.

 NOT the rigid and non-adhered to standard.

> but it's not what DOM bindings in
> WebKit are about.  DOM bindings are about exposing the standard WebKit DOM to
> client applications,

 which is useless, as demonstrated by the warped javascript _real world_
 interpretation.

 be pragmatic.


> not about exposing JavaScript's somewhat warped
> interpretation of the DOM.

 javascript _is_ the standard.

 it wins.

 de-facto.

 there's no putting the genie back in the bottle - it's too late.

 javascript wins.  get the standard updated.

 plus, the reason _why_ people specify "75%", "20px", "10em" etc is because
_only_ being able to specify an integer is bloody useless!

 being able to specify "75%" is a _damn_ good idea.

 so - following JS bindings it is.


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



More information about the webkit-unassigned mailing list