111750 - Rename "Preview" edit mode tab to indicate editability OR make "Preview" mode non-editable

Status: REOPENED

(SeaMonkey :: Composer, defect)

Description

[Max]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.6) Gecko/20011120
BuildID:    2001112009

If you press the 'Preview' tab at the bottom of the window, you can still edit
the document just as you would be able to when clicking on the 'Normal' tab. It
does not preview the document.

Reproducible: Always
Steps to Reproduce:
1. Click 'Preview' at the bottom of the window
2. Click on the white page
3. Type something.

Actual Results:  The text typed appeared.

Expected Results:  It should have just given a preview of the document (what it
would like in a browser)

Comment 1

[Syd Logan]

Over to Charles -- is this by design? I don't see this as editorbase, just not
sure if the intent was to disable editing in the preview window or not.

Comment 2

[Charles Manske]

Preview mode is designed as completely WYSIWYG editing mode. That's a *feature*.
It is exactly the same layout as in the Browser. Normal mode is very nearly 
WYSIWYG, but we show dotted lines for table borders and an icon for Named Anchor
which don't show in Preview mode.

Comment 3

[sujay]

verified

Comment 4

[Charles Manske]

*** Bug 156107 has been marked as a duplicate of this bug. ***

Comment 5

[Alex Hosking]

Very Strange how none of the other Seriouse WYSIWYG editors avilible allow you
to edit pages from within the prievew tab Maybe you should write to Adobe,
Macromedia, Microsoft and Evrsoft and tell them how wrong they are.

Comment 6

[Charles Manske]

Enough of this!
There's enough feedback to indicate we shouldn't call this "Preview" since too
many users don't seem to like that we allow editing in this mode.

Comment 7

[Max]

It would normally be assumed that a 'preview' tab would allow you to view how
the page looks like when viewed from within a browser window.

--M.

Comment 8

[Charles Manske]

Kathy, Robin: Any suggestions? I originally liked using "WYSIWYG".

Comment 9

[Charles Manske]

Yes, the Preview tab allows you to view the page *exactly* as it appears in 
the Browser. But why should this preclude allowing editing?

Comment 10

[Max]

Can you view a web page in a browser window, click  in it and start editing it? No.

Comment 11

[timeless]

wordperfect9 has:
view>
 Draft
 Page
 Two Pages
 Web Page
 -
 Reveal Codes
you can edit in any of these modes
it also has
File>Print Preview
 in which you can also edit.

however, wp9 allows you to do all sorts of things using realtime preview (hover 
over a font size for a few seconds and you can see the result of the font size. 
moving off/cancelling will revert to the current setting).  Zoom even behaves 
this way...

So in answer to the question, is there any app which allows editing in preview? 
"yes, wp". Hrm, I've mentioned this before, i wonder where...

The reason that preview is wanted is to be able to do wysiwyg editing. Browser 
preview forces you to save. You can't preview a page in navigator without giving 
it a url, and I don't think we want to send web pages to navigator as 
data:text/html,<img src="data:image/jpeg;base64,..."><iframe 
src="data:text/html,&lt;html&gt;...">...

I can only offer "Live Edit" which really isn't that good.

The alternative is to rename the first tab. you could call it "Draft" and the 
last tab "Normal" or something...

Perhaps we should reorder the tabs:
Normal(currently Preview), Draft (currently Normal), All Tags, Source.

Advantages: logical progression from no html exposure to full exposure
Disadvantages: inconsistent w. n6 and past mozilla milestones.

minor con: my use of 'draft' doesn't quite match wp's...

Note that there's no n4 compat issue and n6 does not have a large userbase. 
However if we go down this road, we might want to consider n7 which might garner 
a userbase (will it be a mozilla1.0.x derivative?). But as this is a usability 
issue, i think netscape should be willing to accept an improvement for their 
product release if we offer it quickly enough.

Comment 12

[Max]

The problem I have with the preview tab is that there is no noticeable
difference between it and the normal tab.

Comment 13

[Charles Manske]

ukmeatisrubbish: Then I guess you have never included any tables with border="0"
or named anchors in any page you have edited. The former are very commonly used
as a layout guide in web pages. There will be more differences visible when
we complete form widget support (a <form> will show a border in "Normal" mode.)
The fact that the difference is minimal attests to the excellent WYSIWYG nature
of the "Normal" editing mode; however it is not 100%, thus the current "Preview"
mode remains valuable to see if table borders (or lack of them) are correct, etc.

Comment 14

[Max]

2 items: tables and anchors . Is that all? Then what's the point????

Comment 15

[Alex Hosking]

oo grovey grovey now hip hip Wordperfect 9!

Comment 16

[Max]

>> oo grovey grovey now hip hip Wordperfect 9!

Erm? ....

Comment 17

[Jose Duarte]

Speaking solely as a user: if you use a lot of css and javascript like current
webdesign usually demands the "preview" is not that usefull, as the layout is
almost the same as the "normal" mode. It would be far more usefull to not have
the preview mode editable and simply use it as a quick way to see the layout
that the browser would produce. A temporary file could be saved so that a true
browser window could be used to preview the layout.
I know it may raise a lot of controversy because it would mean changing
something that's been around for a long time, but in terms of usability it would
be better and also more familiar to those migarting from non open source html
editors to mozilla.
That said great job on making composer more up to date! Just waiting for colored
sintax in the html mode and i'll be using it full time ;)

Comment 18

[irongut]

I'd like the editability of Preview kept but it would be nice if it really was a
preview of what the browser shows. It really should parse JavaScript at the least.

Comment 19

[timeless]

um.
that's pretty much impossible. javascript has this tendency to deform documents.
if you were to let javascript run and then make a change to the document, what
would you expect to have happen when you saved it? (javascript could for
instance delete a bunch of nodes.)

there are certain things i'd want from preview, but i can't remember offhand
what they are.

Comment 20

[Prognathous]

I find the name "Normal" a bit odd. What's so normal about it and abnormal about
the other tabs? personally, I would prefer to rename it to Edit and to add two
buttons for toggling some visual elements. Here's the general scheme:

* Edit  (plus buttons for Show/Hide HTML Tags and for complete WYSIWYG view)
* Source
* Preview

This way, direct visual editing is always done in the same tab.

Now, since Edit is actually a multi-function merge of the current Normal, HTML
tags and Preview, it would make sense to change the Preview tab to be similar to
common read only view, as in other editors.


An alternative approach could be to merely rename Normal to Edit and add a
Browse tab for previewing the page in a browser view:

* Edit
* HTML Tags
* <HTML> Source
* Preview
* Browse

Personally, I prefer the first option, but this one is more evolutionary of the
current design and that does have its merits.

Prog.

Comment 21

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 22

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420

Comment 23

[Rainer Bielefeld]

I still prefer "WYSIWYG" to "Preview"