Re: Math IG comments on CDF Last call documents

On Sat, 28 Jan 2006 19:19:47 +0100, David Carlisle <>  
> Am I correct to assume that was a personal response, not the official
> CDF  WG response to the last call comment?

Yes. Sorry for not explictly saying so.

>> This is entirely delegated to CSS which defines exactly what should  
>> happen
>> for replaced elements.
> It is entirely within the remit of the CDF group to specify how the
> compound document, once assembled by reference, is exposed to CSS (or
> anything else).

I'm not sure what you mean here. I'm just talking about how to determine  
the size of a replaced element. <object> would be an example of a replaced  

The rules for determining the 'width' are described here:

The rules for determining the 'height' are described here:

> Plugins for netscape 4 era browsers designed to support
> compound documents have API calls to expose the natural height depth and
> width of the fragment, so allowing the size to be set (typically in that
> era, by just document.write-ing a modified object or embed tag). At the
> very least, anything aiming to be a "compound document framework" must
> standardise the essential feature of setting the size.

It is not clear to me at all what this means. Are you talking about  
interfaces like (for setting the size):

I assume that with the other things you mean various interfaces from  
"DOM0" like innerWidth and all that. I'm not sure why the CDF WG would  
have to look into those. That seems rather something for the Web APIs WG  
to sort out.

> Even so having to
> make explicit calls in script to modify the object tag is of course
> rather a poor version of CDF support compared with the rather more
> natural, automatic resizing on elements from "foreign" namespaces as has
> been available in IE since 5.5 and mozilla since 0.9.something (that is
> for years), so given that this is 2006 not 1996, one would have hoped
> for rather more than a set of calls to allow size determination. To have
> not _even_ that is rather shocking, to be honest.

That is a completely different thing. In that case you no longer have to  
deal with a replaced element. (By the way, since when does IE have any  
support for namespaced documents?)

> If the intention is to develop a framework for making very simple
> documents on very constrained devices, then fine, there is nothing wrong
> with that, but don't call it a "compound document framework" as the
> suggestion that a system which implements just the features suggested by
> this framework is capable of rendering a compound document of any
> complexity is completely misleading.

It is still not entirely clear what you mean with all this. What  
complexity? Most of the problems the CDF WG deals with are already solved.  
We just say how they are solved. Could you perhaps give some clear  
examples that are not covered by the CDR Framework or its dependencies?

>> I suggest the Math IG raises its issues with the  CSS WG instead
> The interaction of Math and CSS has been on the agenda for CSS and Math
> for some time, and if there are issues that would need CSS WG input then
> clearly we could take those up with the CSS group, but the present
> issues are with CDF rather than with CSS.

Good to hear. I hope that when you or the Math IG provide some examples  
I'll understand the problem better given that I believe the problem is a  
solved problem and that what you want in particular has to be solved by  
rewriting parts of the algorithm as defined in section 10 of the CSS 2.1  
specification. (Given that it is a solvable problem.)

Anne van Kesteren

Received on Saturday, 28 January 2006 18:39:18 UTC