On Tuesday 20 January 2009, wrote:
> But holding back the label of "conformant" is the primary
> way to bring vendors to the table to propose and document such features.
> If we just label everything conformant, than why would a vendor trouble
> with the time and effort to get their proposals accepted formally into the
> standard? Why buy the cow when you can get the milk for free?
I understand that. But on the other hand, why should an implementation
be marked as "non-conformant" just because it adds one tiny attribute
in a style somewhere for mostly internal reasons?
> But your point on editing hints versus content extensions is well taken.
> Maybe there is some way we can formulate a conformance clause that takes
> account of that. But I'd rather have an extension framework that handles
> things like that in a structured way than to allow any XML anywhere.
Right, in fact I think that allowing extensions in style properties is a given,
while indeed allowing any element in the middle of content elements
would just open the door to non-standard content. I think your ideas work
well together: by only allowing extensions inside style properties, only
additional settings to _existing_ content elements can be added, no actual
new content.
Of course styles can affect rendering as well as editing, but that's the
impossible-to-draw line.
--
David Faure, , sponsored by Qt Software @ Nokia to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
