Re: Non-goal for HTML: A Graphics API

On Apr 16, 2007, at 10:45 AM, Murray Maloney wrote:

>
> At 10:34 AM 4/16/2007 -0700, Chris Wilson wrote:
>
>> T.V Raman [mailto:raman@google.com] wrote:
>> >If we're talking about HTML producing pixel perfect rendering,
>> >then I suggest it's time to press the reset button -- that was
>> >never HTML's goal, and nor should it ever become its goal.
>>
>> I agree, but then I don't think it's rational to put a graphics  
>> API in the middle of the HTML spec.  (And actually, I'm kinda on  
>> the fence - other than OS-native controls, I'm not sure if  
>> rendering isn't de facto part of the spec anyway.  It's not like  
>> we could decide that <div> should have a default margin of 2ems or  
>> anything.  :)
>
>
> HTML is not the place for a graphics API. This should be promoted  
> to Design Principle.

Even if this assertion is correct, I don't think it makes for an  
appropriate design principle. None of the principles so far are of  
the  form "HTML must not support feature X". It's hard to see how  
such a principle could ever be justified in general, unless feature X  
intrinsically violates the other principles. (For example, full read/ 
write filesystem access would violate the security principle, but for  
that reason I don't think it's worth mentioning.)

> It may well be the best Graphics API that was ever built, but it  
> still doesn't belong inside of HTML.

It seems entirely appropriate to me for "A language evolved from  
HTML4 for describing the semantics of documents and applications on  
the World Wide Web" and "Document Object Model (DOM) interfaces  
providing APIs for such a language" to satisfy the very common  
application use-case of an immediate-mode drawing area.

So the charter seems to allow (arguably even encourage) such a thing.  
Do you have any argument against?

Regards,
Maciej

Received on Monday, 16 April 2007 18:03:04 UTC