Re: Simple template-based editing

> How edited content supposed to be saved/sent?

HTTP PUT of the whole document is what I've always assumed, as I believe
that these features were invented as a means of providing templates,
not a means of submitting rich text form fields.

(My view is that the need to enforce such templates indicates a failure
of the the original web concept of allowing ordinary people to author
content.)

> something new. (contentEditable does not allow you to send content without use 
> of scripting, sic!)

PUT is a very old method.  Seems to me that is a browser workaround.

> src - url, source of the content, optional.
>         Otherwise takes initial content in-place between
>         <htmlarea> and </htmlarea>

Once you have src, you have object like isolation, which seems to me
desirable, in any case for the rich text form field case.  This is
a different case from the template case.

> allow - string, comma delimited list of tag names of allowed
>        elements in the content.
> reject -  string, comma delimited list of tag names of forbidden
>        elements in the content.

This seems to me to be a re-invention of DTDs.  In fact these seem
like a cut down version of some of the features of SGML DTDs that were
dropped as too complex in XML (although the move to schemas indicates
that XML DTDs are now seen as not powerful enough).

> format - string, name of "rich text" format of the value of
>        the field, possible values: "html", "wiki", "blog", some other.

The precedent here is to use a "type" attribute, whose value is a MIME
media type, so this again looks like a re-invention.  Once you allow more
than HTML fragments, though, you can't assume things like elements and
out of line images.

The problem here, if anything, is that whilst your new, cut down, media
types are too generic, MIME ones are also too generic and one needs to be
able to specify an abstraction of schema/DTD identifier that is applicable
to other media types.  Media types require a formal registration process,
whereas DTDs/schemas only require some accessible web space.

> It inherits CSS styling of the content from its host document. It also knows 
> about overflow CSS attribute

Styling need not be CSS.  The problem here, though, is that once you allow
arbitrary media types, some may not have the necessary nested structure
and element concept needed to make styling work.

In both the rich input field and template case, I feel that the correct
place to put content constraints is in the schema/DTD, or equivalent
for the media type. For rich input, it is a schema for the field.
For templates, it is one for the whole document.  Once you start
validating fields in this way, you are no longer in a context where you
need to allow non-validating parsers, so schemas and DTD can be mandatory.

Received on Friday, 30 September 2005 07:09:50 UTC