Closed
Bug 30027
(WYSIWYG)
Opened 24 years ago
Closed 14 years ago
Composer should support XML and DHTML
Categories
(SeaMonkey :: Composer, enhancement)
SeaMonkey
Composer
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...
Comment 1•24 years ago
|
||
we need help to make this happen!
Comment 2•24 years ago
|
||
Marking NEW to get it of the bugathon radar.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 3•24 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•24 years ago
|
Status: NEW → ASSIGNED
Comment 4•24 years ago
|
||
I'll help! Give me some direction and I'll look into it.
Comment 5•24 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•24 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 8•23 years ago
|
||
-->brade
Updated•22 years ago
|
Alias: WYSIWYG
Summary: editor should support xml and dhtml → Composer should support XML and DHTML
Comment 12•21 years ago
|
||
What's the status now? Is there anybody works on it?
Comment 13•21 years ago
|
||
leechenhwa@163.com: are you volunteering to work on this? if not then it's not a priority.
Comment 14•21 years ago
|
||
timeless@myrealbox.com : How could I help? If it's possible, I'm glad to.
Comment 15•21 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•20 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.
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
Assignee: composer → nobody
Priority: P3 → --
QA Contact: sujay → composer
Target Milestone: Future → ---
Comment 17•15 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•15 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•15 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•15 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•15 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•15 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•15 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•14 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
Closed: 14 years ago
Resolution: --- → EXPIRED
Comment 25•13 years ago
|
||
Ever confirmed: true
You need to log in
before you can comment on or make changes to this bug.
Description
•