Wednesday, September 12, 2007, 10:37:10 AM, Hussein Shafie wrote:
> Santy, Michael wrote:
>> I can understand the rationale of making table cells as wide as possible
>> by default to ease editing within cells. However, I think the closer
>> that you can render the table in XXE to the final rendered product is a
>> good thing. I think that adding support for the pgwide attribute (or a
>> corresponding css attribute on table-body) will save some unnecessary
>> iteration between editing and rendering a document to get the tables to
>> look correct.
>>
>
> Frankly, we cannot implement this kind of RFE. The whole point of
> structured documents is to forget about the rendering of the document
> you are editing and instead totally focus on its contents.
I will not say any opinion regarding this concrete issue (as I don't
know it enough), but there is something that you guys (the XXE
developers) don't seem to get regarding XML documents. It's that what
is "structure" (with other words, semantic) and what is "presentation"
("rendering", you may would say) is not decided by you, but by the
designers of the XML Schema in question. If the XML schema allows
specifying the width of a column, or the spacing of an itemizedlist,
etc., then that's all semantic, and not just presentation. The "We
don't want to show that in the editor because that's not structure" is
not a valid argument in itself, because if it's the part of the schema
then it is structure. Of course, the goal is not that the editor view
will look like the rendered output -- that's not even desirable in
many cases --, but that the user can see the content of the XML, and
that usually means that you more-less use the same visual effect as
the rendered output. Like, the spacing of a list can be shown pretty
much straightforwardly and without causing any visual hassle. It's
just good, because then the user sees immediately if he has set the
spacing correctly. Yet you insist not showing that. Maybe the
situation is similar with this table related issue as well.
--
Best regards,
Daniel Dekany
