Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3C8E7E35.2F9CD5B9@apache.org>
Date: Tue, 12 Mar 2002 23:16:21 +0100
From: Stefano Mazzocchi <stefano@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org
Subject: Re: Wyona / Xopus (IE vs.Mozilla)
References: <3C8A8412.3030809@koberg.com> <3C8A8AF9.8070609@koberg.com>
 <3C8B3F04.9F1B1A2E@apache.org> <3C8B638E.4080802@koberg.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

"Robert S. Koberg" wrote:

> First, anything visible on a computer screen is in a rectangle :)

Correct. The key difference is 'everything is in a rectangle' compared
to 'everything is a rectangle'. I hope you agree with me that this is a
huge difference.

> Anyway, I get what you mean but is not true. Try:
> 
> <DIV CONTENTEDITABLE="true">
> <IMG SRC="boo.gif" align="left"/>
> blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah
> b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah
> </DIV>
> 
> Or:
> 
> <DIV CONTENTEDITABLE="true">
> <IMG SRC="boo.gif" STYLE="float:left"/>
> blah b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah blah
> b;lah blah blah b;lah blah blah b;lah blah blah b;lah blah
> </DIV>
> 
> Is this what you want to do?

Hmmm, that partially solves my issue, thanks!

> >
> > I hate this!
> >
> > You can take your favorite news page with complex layout, turn editing
> > on with a javascript-powered DOM crawler and, voila', the layout of the
> > page changes if the text blocks are non-rectangular.
> 
> I don't understand. I don't see this. My pages are pretty complex and I
> can have text wrapping an image. They look the same with or without
> contentEditable.

I have a few pages scraped off cnn.com that I use for inline-editing
demos that do change shape (I mean, the layout changes slightly) when I
turn contentEditable on. And all text flows seem to get
'rectangularized' when contenteditable is turned on (and they go back to
normal when its turned off)

> > This sucks!
> >
> > My *biggest* reason to work on Mozilla is to *fix* contenteditable, not
> > to recreate it on other platforms (that's the second biggest reason).
> 
> Other platforms is the killer.  Many people I know won't use anything
> other than a Mac.

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 :)
 
> >
> > 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.
 
> > Sure, many of you might not give a damn about a small layout change, but
> > almost *all* the writers I've showed a demo to, they say they would be
> > *much* more interested to see a *fully* WYSIWIG semi-structural editing
> > solution... the goal is to *remove* their need to 'preview' the page.
> > Completely!
> 
> Yes! They want Word in a browser. We cannot give them this much freedom,
> but if you break it down into small content chunks it gets easier to
> give them a good deal of freedom without sacrifing validity.

I totally agree.

> e.g.
> I give the user the option to right-click on the image or double-click
> it to launch an image modal dialog that gives the user the chance to
> move the IMG above or below, or float/align left or right.  This does
> what you want, I believe.

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

<snip/>

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

> >
> >>What happens when
> >>you want to edit bold text or a link in the DIV?
> >>
> >
> > Via javascript. You can either have:
> >
> >  1) keyboard shortcuts (CTRL-B for bold, contentEditable does this
> > automatically and also places 'semantic' tags in there! <strong> instead
> > of <b>, <em> instead of <i>)
> >  2) floating toolbar with buttons (you could do it with an
> > absolute-positioned <div> with draggable controls, or with a frameset
> > (LIME does this), or with reactions on other parts of the same page)
> >  3) context menu (right-click and follow the menu, Xopus does this right
> > now)
> >
> 
> I personally like to use a modeless window AND context sensitive menus.
> I hate floating DIVs - very ugly and jerky. I had played with a FRAMESET
> but that intrudes on the look of the page.

LIME uses a nice to implement a nice and smooth floating DIV: the page
contains an absolutely positioned <div> with some javascript that
controls the dragging, and contains only an <iframe> that contains the
actual page on a lower z-index.

That allows complete smooth scrolling (and with PNG, might also allow
alpha blending between the div and the underlying <iframe>, LIME uses a
tranparent gif with a dither to obtain a similar effect)

Anyway I agree that it should be possible to configure the generated
editing wrapping code so that the UI is easily configurable.
 
<snip/>

> If you go this route, then you will be giving up some nice 'free'
> features. For example, the user is in a P tag -> they hit enter -> a new
> para is created. Or even better, they are in a numbered list -> they hit
> enter anywhere in the list and a new item, numbered correclty, is
> inserted. You could catch keys-presses, of course, and duplicate the
> functionality.
> 
> Why are you worried about setting contentEditable at the outermost DIV
> that wraps the content piece? You can have a kind of freeform editing
> and still control what the user does.
> 
> Aside - about HTML and case:
> I hate that XHTML and XSLT both require lowercase. This ruins a very
> simple but effective 'separation.' When I create XSLT I use uppercase
> for all HTML. This way an HTML person can jump in and know exactly what
> they can affect. Anything in lowercase they should not touch. Anyway...

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.

>
> 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? :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org