Re: Simple template-based editing

Hi, David,

From: "David Woolley" <david@djwhome.demon.co.uk>
>
>> 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.

HTTP PUT is not a practical solution as it needs then parsing support
on server side to strip edited content.
In real life as a rule
editable content resides in different storage on the server from
static templates and final page is always a compilation of template and 
data.

>
> (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.

Yes it simplifies the whole system a lot. In practical
implementations I mean.

>
>> 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).

Agree. But it is fast and verification code is less than one kb in binary.

>
>> 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.

"Wiki language" here is just a one-to-one transformation wiki/html
Being loaded wiki markup is seen in the DOM as plain HTML DOM.

In fact in our "master style sheet" htmlarea declared as

htmlarea { display:block; behavior:text-editor(rich); role:form-field }
textarea { display:block; behavior:text-editor(plain); role:form-field }

And to be honest
behavior: editor could be assigned to any arbitrary element, e.g.
div[contentEditable] { behavior:editor(rich);  }
but this is again has not too much sense.

>
> 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.

Let's say this way: Styling can be CSS if input language (Wiki,Blog)
has consistent mapping to HTML. This is true in our case.

>
> 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.
>

Where to put  content constraints verification?
On the server side or on the client side?

Received on Friday, 30 September 2005 17:31:38 UTC