Stefano Mazzocchi wrote:
>"Robert S. Koberg" wrote:
><snip>
>
>
>Don't tell me, my girlfiend is one of them :) and given the overall
>beauty of macosx I might turn into one of them myself shortly :)
>
I am about 70% on OSX now that I have a mozilla mail client :) Have you
burned a DVD yet? (: rhetorical :)
>
>
>
>>>If you try Mozilla Composer, it is fully capable of performaing
>>>non-rectangular editing of text... for example, text flows around
>>>images, so my wild guess would be that by merging the editing
>>>capabilities of the editor XPCOM component and the rendering capability
>>>of the Necko XPCOM component, we can have the behavior we want.
>>>
>>I have never tested on Mozilla before (never had the req). I am using it
>>now. Very cool, but the memory... There are a couple of other IE
>>features that would be good to have (don't know if they already have it...):
>>
>>- control over the right-click (context sensitive menu)
>>
>
>You get this with XUL out-of-the-box.
>
>>- modal and modeless dialogs
>>
>
>could be that XUL has this but I'm not sure.
>
>
>>>Even the best inline editor existing (q42's LIME, see
>>>www.q42.nl/products/lime) is based on contentEditable and thus inherits
>>>this 'rectangular only' behavior that messes up layout.
>>>
>>I believe there is a better one out there :)
>>
>
>Which one, I'm curious.
>
I thought it was obvious I was talking about mine :) The one that is due
to be released in January of 2002 :)
I believe it has improved a great deal since you saw it last. But this
does not meet your needs because it is not cross platform and does not
currently set up a dynamic site, just static. I have a previous
Dreamweaver SE working on the JavaScript to get it as professional as it
can get. It does not actually run in cocoon. To get it to work in cocoon
would require major rewrites of my XSLT (my tool is mostly XSLT and XML,
heavily using the xsl document function).
I want to make my "storyboard" tool *export* a cocoon site. The
storyboard is 'active' or 'live' meaning that it should change as your
site structure and content changes. I see cocoon being a later stage in
the final product, not for text editing (at least for my needs). I see a
good spot alongside things like cocoon. I believe that in the beginning
stages of a site's development you have to be much more fluid than you
are allowed with cocoon (that is my impression since I can't quite grasp
everything about cocoon).
I have only taken static sites on as jobs recently. But of course a
static site can be changed daily given the ability to generate at will.
I just took a project where i am converting a workbook to an online
version. This will eventually live in cocoon.
><snip/>
>
>
>Yes, more or less, but semi-structure at the editing level is definately
>what we need: less freedom than Word but more freedom than forms, all
>without moving from your browser.
>
>
>>>And this is *NOT* currently possible in any browser in the world!
>>>
>>I must be missing something.
>>
>
>My experience indicates that it's not possible to use contenteditable
>without sacrificing some layout changes due to the rectangular-ness of
>the implementation.
>
>I'm not saying it's not possible *at all* (it is, in fact) but that
>isn't good enough for my quality standards (and my girlfriend's, she's
>even more picky than I am... even a pixel off when I turn
>contenteditable on and she screams!)
>
I am with her (and you, but she is probably more attractive :). I don't tolerate pixel
shifts (from my CDROM days...). I don't have the experience of contentedtiable
changing my layout, though. When we added our visual rollover indicator (dashed border
on rollover of an editbale region) it shifts by the size of the border. We *fixed*
that by swapping a background color border with the dashed one. That is the only
thing. The tool is, however, in complete control of the HTML written on the page
during editing. We are not trying to make this work with just any HTML.
>>>This was only an example. And, BTW, I think you could do *very* powerful
>>>semi-structured editing with just <div> and <span>
>>>
>>Yes, I agree. There are many different types of documents to edit! For
>>example an article should be much more free-form than a use-case :) The
>>transformation determines which javascript parser script to include;
>>parser_article.js or parser_use-case.js
>>
>
>Exactly! This is why I would like this editing-driving javascript to be
>created on the server directly by transforming the XMLSchema describing
>the document structure (we could add cocoon-specific namespaced
>information about the client-side user behavior that would be turned
>into javascript logic for the client side)
>
This sounds really cool. I really have to start learning about schemas
:) I have been able to get away with DTDs... On this, I am kind of torn
between the time it would take to create the XSLT versus the time it
would take to just write the JS.
We have been writing each js parser by hand. This is most frustraing
when trying to deal with content that was pasted in from MS Word (which
I am thinking should not be allowed at this point).
<snip/>
>
>lowercase HTML is more compressible. This is the reason why they forced
>you to use lowercase and I *do* agree it's a good thing. Using case to
>differentiate syntax is a hack: people should not edit markup by hand
>anyway and if they do, they sure know how to indent it properly so no
>need for HTML and then having 20% of the world's bandwith wasted because
>of that.
>
This is the first good explanation I have heard (and now it makes
sense). I asked the w3c-html group and they came up with very lame
answers (mostly that it was just arbitrary).
But this hack is a useful one (though now I see it's problems). At
LearningNetwork (read more about it on f*ckedcompany.com :) we had
more-skilled people set up the XSLT and then this was turned over to
HTMLers to tweak to a designer's specification. The difference between
the uppercase text and lowercase text was invaluable. If they want to
save bandwidth they should criminalize images for Navs :). I don't
understand why you say people should not edit markup by hand, other than
the obvious that they will f*ck it up. But I don't want to spend money
on a valueable person going through rounds (and rounds and rounds,
etc...) of tweaking XSLT's HTML. This is perfectly able to be done by a
less skilled (and less expensive) person. Also, it would be tough to
keep a skilled person if they spent a good part of each day tweaking the
HTML part. arrrgggghhhh....
>
>>In my site.xml config document (and a corresponding content.xml that
>>further describes each individual content piece) I describe the site
>>hierachically with folders and pages (mirroring what the site structure
>>would be if not dynamic). At the folder and page level I set the columns
>>for the page. Inside of the columns I put XML content pieces which
>>determine the rows or individual CONTENTEDITABLE regions in each column.
>>The content pieces at the folder level cascade down to the page level
>>(unless overridden). By having the hierarchical representation you can
>>build nav's and links on the fly (either dynamic or static depending on
>>whether you are in dev or generating). Each content piece has an owner.
>>When a user hits a page they can only edit those pieces that they own
>>(rollover editable area and user sees a light outline, click on an
>>editable area and the background color changes in that section). Once
>>they click on the editable area, setup what you need to and let them
>>have at it.
>>
>>I give the user the oppourtunity to generate the site (SAX
>>ContentHandler going through the site.xml triggers transformations on
>>cahced XSLT). So for a simple site you can use the same virtual host to
>>see the Dev (and QA) version which is dynamic and using the config to
>>guide the transformations pulling content from WEB-INF or a DB (I like
>>text files). When ready to go to QA they generate the site to static
>>HTML which populates the docroot writing out pages according to the
>>config. When QA'd they can just copy the generated site to the live server.
>>
>
>Hmm, that would make a great cocoon sample, can you share it with us? :)
>
As I mentioned earlier, I intend to set up my storyboarding tool to
export a cocoon site, but the tool itself is not in cocoon.
best,
-Rob
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
