Closed Bug 30027 (WYSIWYG) Opened 24 years ago Closed 14 years ago

Composer should support XML and DHTML

Categories

(SeaMonkey :: Composer, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: oliver, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: helpwanted)

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...
we need help to make this happen!
Keywords: helpwanted
OS: other → All
Hardware: PC → All
Target Milestone: M20
Marking NEW to get it of the bugathon radar.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Status: NEW → ASSIGNED
reassign my M20 bugs to beppe so the editor rfe's are all in one spot :-)
Assignee: brade → beppe
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
I'll help!  Give me some direction and I'll look into it.
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.
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.
moving to future milestone
Target Milestone: M20 → Future
-->brade
-->brade
Assignee: beppe → brade
Status: ASSIGNED → NEW
spam composer change
Component: Editor: Core → Editor: Composer
Depends on: 25728
Depends on: 137092
Depends on: 176981
Alias: WYSIWYG
Summary: editor should support xml and dhtml → Composer should support XML and DHTML
Depends on: 92525
-->
Assignee: brade → composer
Blocks: 202755
What's the status now?
Is there anybody works on it?
leechenhwa@163.com: are you volunteering to work on this?
if not then it's not a priority.
timeless@myrealbox.com :
How could I help?
If it's possible, I'm glad to.
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.
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 → ---
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
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
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
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
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
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
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
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
Closed: 14 years ago
Resolution: --- → EXPIRED
Ever confirmed: true
You need to log in before you can comment on or make changes to this bug.