Re: [Fwd: My future of HTML position paper]

Russel O'Conner wrote

| > 1) limited baseline alignment
| > 
| >    Object elements only allow TOP, MIDDLE and BOTTOM baseline
| >    alignment.
| 
| Shouldn't layout be handled by style sheets?
| 
| > 2) limited communication with the ambient environment
| > 
| >    For math equations and many graphics (especially ones that
| >    incorporate text) the renderer handling the contents of the
| >    OBJECT element needs much better access to the browser
| >    layout engine.  It needs to be able to query the browser for
| >    the ambient fontsize and style, the background colors, whether
| >    it is inline or blocklevel, etc.  Then, based on these parameters
| >    it needs to negotiate for screen space.  In particular, if you
| >    have to specify height and width in advance (as is required for
| >    the OBJECT element) it is not possible to match textsizes in
| >    graphics or equations to the surrounding content, at least not
| >    without introducing gaps or clipping.
| 
| I don't follow this point.  First of all Width and Height attributes are
| not required for the Object element.  Secondly I don't see why a rendering
| device can't communicate with the browser.  This sounds outside the scope
| of the HTML specs anyways.  If a graphical browser is going to embed
| MathML in the document window (natively or by a plug-in), it should have
| no problem accessing background colours, and ambient font size, and hence
| render the Object in an appropreate manner.  If the browser launches an
| external program to view the object, then getting the background and font
| size is no relevent. 

In both cases, I think you are focusing on the way things should be,
whereas I was describing the way things are.  

Over the last two years, the Math WG has watched a number of specs
come out, and heard a lot of talk about how things will work when the
next up-and-coming technology becomes available.  However, in
practice, what has tended to happen is that the issues I pointed to
keep ending up at the bottom of the priority stack, because they are
simple in concept, and hard to implement.  From another point of view,
they are easy to agree to up front, and easy to rationalize omitting
from your implementation later...

From a language design point of view, I have no problem with your
original assertion that math and 2D graphics belong in an OBJECT tag.
My point, however, is that unless the difficulties of then adequately
implementing the OBJECT tag are built into the discussion, realpolitick
dictates that they are unlikely to be addressed at all.

Robert Miner

--------------------------------------------------------------------
Robert Miner                               http://www.geom.umn.edu
The Geometry Center                        phone: (612) 626-8313
HTML-Math WG co-chair                      fax:   (612) 625-8083
--------------------------------------------------------------------

Received on Wednesday, 13 May 1998 17:01:57 UTC