Closed Bug 290845 Opened 20 years ago Closed 20 years ago

the nsIDOMCanvasRenderingContext2D interface is too script oriented

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED INVALID

People

(Reporter: sicking, Unassigned)

References

()

Details

See bug 288714 comment 38 item 3 by bz as well as a comment by me a few comments
down. The nsIDOMCanvasRenderingContext2D interface is too scriptoriented with
optional arguments (if I understand the spec correctly) and a bunch of
properties being nsISupports which'll suck for non-script users.

As bz points out, interfaces like this is what got us the current "DOM level 0"
mess we have today. So lets try to come up with something better and implement
that in mozilla (with an eye towards what apple does so that we can have some
compatibility)
OS: Solaris → All
Hardware: Sun → All
This is partially an XPCOM/XPIDL failing; there is no way to do optional
arguments on methods, among other things.  One option is to add a few [noscript]
drawImage calls that take the 3 different parameter settings.
No, this is a whatwg failing. DOM interfaces are supposed to be language
neutral, and very few languages support optional arguments. Especially few
non-script languages do. This is why no interfaces defined by w3c uses optional
arguments.
If you're complaining about shortcomings of the spec, you should complain on the
whatwg mailing list, I suspect, although now that Tiger has shipped and we're
about to, I don't imagine us changing the current API in non-compatible ways.
It's not a WHATWG failing. The interface was specifically designed for scripting
users, since those are the ones that are going to use it.

If you want to use canvas from C++ code, don't use this interface. It's
specifically designed for script-using authors. Instead, make up a new interface
that fulfills your needs. If you care about interoperability with other vendors
(and I don't see why you would, for a Mozilla-specific C++ interface), then
create your own spec. You could call it Cairo. Oh wait! ;-)

IMHO this is INVALID -- the interface is acting exactly as designed.
sicking: "too script-oriented" is a good thing.  The script writer is not a
long-haired C++ (or Pascal ;-) pedant, so don't make things harder than they
should be just to uphold some hoary formalism.

/be
I agree this bug is INVALID is stated.  How about we make another interface only
if need arises?  This bug can be resummarized to await that day, or INVALIDated
now to save brainprint.

/be
Yeah, I guess there's a certain amount of logic to that. Though I still think
the drawImage signatures are unneccesarily complicated (simple is good even for
script). But since we're following apples lead here I guess we're stuck with
what we've got.

However some of the DOMObject datatypes are still wrong since DOMObject maps to
nsISupports and not nsIVariant (which makes sense since a string isn't a
DOMObject). But that's something that should be changed on the spec side and
debated in the whatwg lists.

Marking invalid.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
I don't agree with the way this was resolved.

> If you want to use canvas from C++ code, don't use this interface. It's
> specifically designed for script-using authors. Instead, make up a new interface
> that fulfills your needs.

Lots of DOM interfaces have examples with Java bindings. I think the attitude
that the DOM is just for scripting and users of "real" languages shouldn't be
using Web standards is silly, and strategically dangerous. Novell people want to
access XPCOM interfaces from Mono/C#. They want to use C# to write local apps
using Web technology. What frameworks should they be using instead? Avalon?
I have no problem with a more language-neutral interface, but I'm agin' anyone
who says "too script oriented" like it's a bad thing.  New bug needed?

/be
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.