W3C home > Mailing lists > Public > www-style@w3.org > September 2005

Re: Simple template-based editing

From: Andrew Fedoniouk <news@terrainformatica.com>
Date: Fri, 30 Sep 2005 10:31:25 -0700
Message-ID: <006101c5c5e4$c88cc050$3201a8c0@Terra>
To: "David Woolley" <david@djwhome.demon.co.uk>, <www-style@w3.org>

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 

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:20 UTC