If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.
Bug 30027 (WYSIWYG)

Composer should support XML and DHTML

RESOLVED EXPIRED

Status

SeaMonkey
Composer
--
enhancement
RESOLVED EXPIRED
18 years ago
6 years ago

People

(Reporter: oliverthered, Unassigned)

Tracking

(Depends on: 1 bug, Blocks: 1 bug, {helpwanted})

Trunk
helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

18 years ago
it seams a sensible idea that the mozilla editor should be able to a wisiwig
production of all the markup langages mozilla supports.
not just a partial implementation of html...

Comment 1

18 years ago
we need help to make this happen!
Keywords: helpwanted
OS: other → All
Hardware: PC → All
Target Milestone: M20

Comment 2

18 years ago
Marking NEW to get it of the bugathon radar.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 3

18 years ago
reassign my M20 bugs to beppe so the editor rfe's are all in one spot :-)
Assignee: brade → beppe
Status: ASSIGNED → NEW

Updated

18 years ago
Status: NEW → ASSIGNED

Comment 4

18 years ago
I'll help!  Give me some direction and I'll look into it.

Comment 5

18 years ago
one of the first things we need to understand is how to get the editor to 
understand teh different DTDs that may result from this. We need to understand 
how to ensure that each element gets normalized (force end tags). Back to the 
DTD we need to ensure that wherever the focus is, that we are ensured that only 
the appropriate elements are allowed to be inserted. Think real-time parsing.
(Reporter)

Comment 6

18 years ago
could you use a dynamic parser based on domains, and rules. for conversion
between whatever eg dhtml,xml,wml and a base structure (eg sgml)  and visa versa.
the information could be stored internaly in a universal format and parsed to
produce a human readable form, this could be flexable enough to prevent
'artifacts' from being inserted into the original document unless requested (i
find this most anoying if i'm editing a php/asp document and it ends up with
head/body tags.

this may be a stupid comment as i havn't had chance to look at the code/api for
the editor.

Comment 7

18 years ago
moving to future milestone
Target Milestone: M20 → Future

Comment 8

16 years ago
-->brade

Comment 9

16 years ago
-->brade
Assignee: beppe → brade
Status: ASSIGNED → NEW

Comment 10

16 years ago
spam composer change
Component: Editor: Core → Editor: Composer

Updated

15 years ago
Depends on: 25728

Updated

15 years ago
Depends on: 137092

Updated

15 years ago
Depends on: 176981

Updated

15 years ago
Alias: WYSIWYG
Summary: editor should support xml and dhtml → Composer should support XML and DHTML

Updated

15 years ago
Depends on: 92525

Comment 11

15 years ago
-->
Assignee: brade → composer
Blocks: 202755

Comment 12

14 years ago
What's the status now?
Is there anybody works on it?

Comment 13

14 years ago
leechenhwa@163.com: are you volunteering to work on this?
if not then it's not a priority.

Comment 14

14 years ago
timeless@myrealbox.com :
How could I help?
If it's possible, I'm glad to.

Comment 15

14 years ago
Well... a spec would be one thing to start with... perhaps
http://viper.haque.net/~timeless/blog/70/ (the content there is subject to
change, I just decided that inlining it here was a bad idea, i'll write the
setup /69 later).

integrating DOMI w/ composer might be another...

Can someone please explain how DHTML relates to this bug?
I can understand XML since Composer definitely doesn't support that. However,
DHTML is just HTML w/ javascript that does stuff -- Composer supports one flavor
of html and allows you to have or manage blocks of javascript.

I really don't know where to begin. IMO teaching composer or parser some rules
for all possible flavors of html, or even a grammar so that it could learn a
flavor of sgml or xml seems like overkill. Yes it'd be nice if composer could do
what someone wants, but is it worth the cost (time, space, code, size)?

Hrm, so ... I guess the first thing to do is to find out what happens if you
make composer use say HTML3.2 as its doctype instead of HTML 4.01 Transitional. 

The second thing to do is to come up with a decent way of dealing with the
variation that seriously supporting xml would entail. The current composer has
special buttons for things like tables and links and images. But how would a
flexible editor deal with random items? Consider <xul:image> <zip:image>
<html:image> <xul:img> <zip:img> <html:img>, ideally some of these would be
mapped to the pretty image button instead of a boring/ugly [img] or [image]
button, but how?

I think that with enough time and resources I could probably make something like
what i'm describing there (and like something I'm envisioning but not describing
above), but it wouldn't look like composer, and really it wouldn't be composer
(from memory, I think what I'm describing is probably closer to Acadia Infuse,
but I'm not sure where I can find that).

I've actually spoken w/ people who worked on designing a ui based on an xml
ruleset. Their generated content was usable but not something a mac user would love.

Comment 16

14 years ago
This could theoretically make Composer a killer app.

Some of my thoughts:

Start off by stripping out all of the hard-coded HTML stuff entirely.  Turn it
into a raw XML editor.  Let me add elements, delete elements, move elements
around.  Let me add/remove/change attributes and text content.  

Then add DTD support and allow for real-time validation.  Tags are now
pre-defined and I can insert them through menus or toolbars.  Elements that
allow text should allow me to type text.  The editor must be usable in this
form, since we're never guaranteed to know or understand the nature of the XML
document.  We'd bundle Composer with DTD's for all of the markup languages
known, including XHTML.  Other SGML output types may be desirable too (e.g. HTML
with its implied closing tags), but I consider that extra stuff.  At this point
Composer is still an XML editor; it can just load a DTD to make it aware of
what's legal.

Optionally, make it XML namespace-aware.  Maybe let it use XML Schemas instead
of DTDs.

Finally, teach it CSS.  This enables the WYSIWYG layer and allows for more
user-friendly editing options.  (I can still fall back to the style-less editor
if I want to manipulate raw XML data.)

So by this point, all you have is an XML editor that understands DTDs and style
sheets.  Nothing about it is HTML-specific.  HTML behaviors come about by way of
honoring the DTDs and style sheets.  Some language-specific semantics may have
to be defined in a third Composer-specific resource, such as an understanding of
what a link is, meta-data in the <head> element, etc.  XHTML 2 might make some
of this easier if it opts to use XML namespaces for these types of things.  Then
you'd just have to teach it what RDF and XLink are, for example.  Some link
between elements and toolbar buttons would probably be needed at this point.
Product: Browser → Seamonkey
Assignee: composer → nobody
Priority: P3 → --
QA Contact: sujay → composer
Target Milestone: Future → ---

Comment 17

9 years ago
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
Status: NEW → UNCONFIRMED

Comment 18

9 years ago
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 19

9 years ago
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 20

9 years ago
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 21

9 years ago
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

9 years ago
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 23

9 years ago
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 24

8 years ago
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → EXPIRED

Comment 25

6 years ago
*** This bug has been confirmed by popular vote. ***
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.