Open
Bug 92525
Opened 23 years ago
Updated 15 years ago
Allow users to change DOCTYPE of edited HTML documents
Categories
(SeaMonkey :: Composer, enhancement)
SeaMonkey
Composer
Tracking
(Not tracked)
NEW
People
(Reporter: piskozub, Unassigned)
References
(Blocks 1 open bug)
Details
This is a spin-off of bug 92474. It seems that the Editor by design uses a DOCTYPE which is parsed by Mozilla in quirks (as opposed to strict) mode. If the user (web author) knows what (s)he is doing, (s)he should be able to change the present DOCTYPE of Mozilla edited HTML: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> to something that is rendered by Mozilla in strict mode, like: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> Presently this is impossible to change even in the "<HTML> Source" editor mode. IMHO, this should be changeable from the menu and/or preferences. The latter would make it possible to add some text explaining which DOCTYPE is rendered in strict and which in quirks mode. Presently the only info on that I could find is in Bugzilla. It's not what I would call documented :-(
Reporter | ||
Comment 1•23 years ago
|
||
mozilla1.0 & correctness -> keywords (as enabling the creation of HTML code which can be rendered in strict mode is the correct behavior).
Keywords: mozilla1.0
Summary: [RFE] Allow users to change DOCTYPE of edited → [RFE] Allow users to change DOCTYPE of edited
Reporter | ||
Updated•23 years ago
|
Keywords: correctness
Comment 3•23 years ago
|
||
handing this one over to cmanske -- could we have an entry in the Page Titles and Properties dialog where they could change the doctype? Maybe have a drop-down with pre-filled values?
Assignee: beppe → cmanske
Priority: -- → P3
Summary: [RFE] Allow users to change DOCTYPE of edited → Allow users to change DOCTYPE of edited
Whiteboard: [RFE]
Target Milestone: --- → mozilla1.0.1
Comment 4•23 years ago
|
||
We discussed the general issue before and concluded that we weren't supporting any doctype other thatn 4.01 internally, thus it is bad to edit it in page. But if we can distinquish between quirks mode or not (which I agree is good thing to do), then we should simply have a checkbox or radio buttons after the read-only doctype to let user decide which to use. That way we could use whatever description text we like: [x] HTML Strict DTD
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → mozilla0.9.5
Comment 5•23 years ago
|
||
I'm not saying that this would happen, but let's make sure we get the phrasing right. We don't need any more bugs filed to fix misleading/incorrect wording. "Strict mode" which the reporter mentioned is the Strict DTD, not standards mode which I believe he meant to say. Anyway, an ideal choice would be something like this: (I hope that XHTML 1.0 will be supported as well?) checkbox: [x] Use standards mode? radio buttons: (o) HTML 4.01 Transitional (o) XHTML 1.0 Transitional (o) HTML 4.01 Strict (o) XHTML 1.0 Strict (o) HTML 4.01 Framset (o) XHTML 1.0 Frameset
Reporter | ||
Comment 6•23 years ago
|
||
Reporter (yours truly) used the name as half of Mziilla developers uses it. Mozilla has two modes of parsing the Markup code: "strict" or "standard" and "quirks". Which DOCTYPe triggers which is discussed in bug 1312. Not once a "standards mode" is mentioned there. It is half-and-half "strict mode" and "standard mode". Only Gerv on the Bugzilla Helper page uses "standards mode" (he probably invented the name). The problem is that the quirks mode is defined Mozilla code as NavQuirks why the other (strict, standard or standards) mode is just NavQuirks==0. The standard (default) mode of parsing HTML is actually the quirks mode so I would avoid using other name than "strict" to avoid confusion. So from now on "strict mode"and "standards" mode are the same thing and have nothing to do with strict DTD. So much about terminology. This bug is not about choosing HTML 4.01 Transitional, XHTML 1.0 Transitional, HTML 4.01 Strict, XHTML 1.0 Strict, HTML 4.01 Framset or XHTML 1.0 Frameser, as Christopher proposes. The Mozilla Editor supports only HTML 4.01 Transitional so there are no DTDs to choose from. This bug is about choosing the way Mozilla will parse the code generated by the Editor. Please do not morph the bug! Let me remind you when quirks mode is used. I'll copy a comment by Boris Zbarski from bug 92313: > Here is how quirks mode works. We go into quirks mode for: > > 1) No doctype > 2) An HTML < 4.0 doctype > 3) An HTML 4.0 Transitional doctype of any kind (this is an outdated HTML version) > 4) An HTML 4.01 Transitional doctype without a DTD uri > > All other doctypes (including 4.01 Transitional with a DTD uri will trigger strict mode). [Notice him using "strict mode"] In short this means that presently Mozilla uses the quirks mode 95% of time, including parsing code generated by itself (no URI in the 4.01 Transitional DOCTYPE). So we need probably radio buttons: (o) HTML 4.01 Transitional without an DTD URI (parsed by Mozilla in "quirks" mode) (o) HTML 4.01 Transitional with DTD URI (parsed by Mozilla in "strict" mode
Comment 7•23 years ago
|
||
We say strict mode because it takes less typing than standards mode and when you are thinking of what to say it comes as second nature because in your mind it is less sylables, I don't know why we say it. But now is not the time to just throw out words that are easier and that all the QA/developers use as slang. We don't want to confuse the user. "Standards mode" is something the user will recognize. Strict mode will mean the HTML strict DTD to them and people avoid that like the plague (only boring sites use the strict DTD they think since you can't use <font>, etc). Anyway, I know we use the term "strict mode" all too often which is why I brought it up. As far as your two choices, if we are going to do this bug, why are we going to exclude the Strict DTD and the Frameset DTD? There are 3 DTDs that are standardized by the W3C and we should support all 3. Whether they include a URI or not (to invoke standards mode) is up to the creator. So we have the 3 radio buttons picking 3 DTDs, and then the checkbox for turning on/off standards mode (which would include the URI). Let's not have this bug come back later: "RFE- allow users to pick Frameset DOCTYPE of edited" "RFE- allow users to pick Strict DOCTYPE of edited". Let's get them all now. And I included XHTML 1.0 as radio buttons because I personally would like to see that supported since it *is* the W3C recommended version of HTML to use.
Reporter | ||
Comment 8•23 years ago
|
||
Christopher: 1) I'm not a native speaker of English but I was taught that things like "standards mode" are bad English. You are allegedly not supposed to use plural forms of nouns when used as an adjective. BTW, I see where it came from as "strict" can be mistaken with Strict HTML and "standard" with default (which is actually the quirks mode). But I still do not like this name and I am not convinced it is the official one as it is not much used outside of the Bugzilla Helper page. 2) This bug is not about supporting XHTML, strict dtd or anything. It is about the user given the choice of producing code that will be parsed by Mozilla with NaqvQuirks mode off (meaning the strict/standards mode to speak less precisely). Today all code produced by the Editor is treated as quirks/legacy code which is IMHO controversial. If you want Mozilla Editor to support anything else, please file separate bugs. When/if Mozilla Editor will start supporting anything other than HTML 4.01 Transitional, we can add the MarkUp language versions as more choices. Presently this is pointless and moot. Let's avoid the controvesial names and make it as follows: radio buttons: (o) HTML 4.01 Transitional without an DTD URI (parsed by Mozilla as legacy HTML code) (o) HTML 4.01 Transitional with DTD URI (treated by Mozilla as compliant with the W3C standards)
Reporter | ||
Comment 9•23 years ago
|
||
The history of making HTML 4.* Transitional parsed in quirks mode is interesting. It was checked in by harishd on 6/29/2000 as fix for bug 43274 (Documents with unknown DTDs should trigger stict mode in layout). He added an interesting comment in /mozilla/htmlparser/src/nsParser.cpp: > The following code is here because to deal with a nasty backward compatibility problem. > The composer product emits <doctype HTML 4.0 Transitional> for the documents it creates, > but the documents aren't really compliant. To prevent lots of pages from breaking, well > disable proper handling of Transitional doctypes and use quirks mode instead. If lucky, > we'll get to add a pref to allow power users to get the right answer. I believe this luck is exactly what this bug is about (even as the Editor/Composer now "emits" 4.01 Transitional. . He later added a condition to parse HTML 4.01 Transitional with a DTD URI as strict. It was a check-in for bug 42525 ([DOCTYPE] Transitional DOCTYPE with URI should trigger strict layout mode). The two bugs and nsParser.cpp contain all the documentation there is about this problem.
Comment 10•23 years ago
|
||
The code in nsHTMLDocument::CreateShell() seems to tell a different story: aContext->SetCompatibilityMode(((eDTDMode_strict== mDTDMode) ? eCompatibility_Standard : eCompatibility_NavQuirks)); It means that a document with a Transitional DTD triggers the quirks mode. Similar code can be found in other places, I think. About the Editor, I think that a simple checkbox as proposed by cmanske on [2001-07-27 13:20] would be enough for now. Let's not hold off implementing the basic aspects of the feature because we want to put many more things into it.
Comment 11•23 years ago
|
||
You should be notified that an effort is underway to implement a new Mozilla.org v2 website and that the team leading this effort (which includes myself) are leaning towards using HTML 4.01 Strict code. If Netscape/Mozilla Composer users are unable to create/modify documents using this DOCTYPE and gecko mode, it will probably increase the work we have to do in (continually) fixing document content.
Reporter | ||
Comment 12•23 years ago
|
||
Pierre: see bug 42525 and attachement http://bugzilla.mozilla.org/showattachment.cgi?attach_id=11201 which tests HTML 4.01 with an URL in the DOCTYPE as strict (standards).
Reporter | ||
Comment 13•23 years ago
|
||
This is the important fragment of mozilla/htmlparser/src/nsParser.cpp (lines 1045-1047): if(eDTDMode_transitional==aParseMode) { if(eHTML4Text==aDocType) aParseMode=(0==theMinorVersion) ? eDTDMode_quirks: eDTDMode_strict; To make the plot even more convoluted it requires DISABLE_TRANSITIONAL_MODE to be defined (and it is the only instance of using this constant!). It seems to be a trace of a former "transitional parser mode" (see 2000-06-15 Hixie's comment on bug 42525 for proof of its existence). later turned into "compatibility parser mode". It seems we still have three parser modes (compatibility, standard, and strict): HTML 4.01 with an URL in doctype is parsed as strict if it has a strict.dtd URL while in compatibiliy mode if it has loose.dtd. (see mozilla/htmlparser/src/nsParser.cpp lines 747-779 for proof). To sum this up we seem to have two layout modes (quirks and stric/standards) and three parser modes. This certainly badly needs documenting (and I mean: not only in the source). Loose.dtd triggers eDTDMode_transitional (funny name for the "compatbility" mode), so the code fragment I copied above simply says that for HTML >4.0 Transitional with loose.dtd in the code we will use strict/standards layout mode even as we use compatibility parser mode. Sorry for the spam, but it may clear the discussion a little.
Summary: Allow users to change DOCTYPE of edited → Allow users to change DOCTYPE of edited HTML documents
Comment 14•23 years ago
|
||
Charles, help me out here. Are you the proper owner of this bug? Is it possible to get this in for 0.9.5 or need we push it out?
Comment 16•23 years ago
|
||
This is getting more complicated and definitely involves work that will be done by others. Pushing off milestone.
Whiteboard: [RFE] → [RFE] EDITORBASE (2 days)
Target Milestone: mozilla0.9.5 → mozilla1.0
Updated•23 years ago
|
Whiteboard: [RFE] EDITORBASE (2 days) → [RFE] EDITORBASE- (2 days)
Updated•23 years ago
|
Whiteboard: [RFE] EDITORBASE- (2 days) → [RFE] (2 days)
Comment 17•23 years ago
|
||
is this a dupe/dependency of bug 74377?
Comment 18•23 years ago
|
||
*** Bug 74377 has been marked as a duplicate of this bug. ***
Comment 20•23 years ago
|
||
removing myself from the cc list
Updated•22 years ago
|
Target Milestone: mozilla1.1alpha → mozilla1.2beta
Comment 21•22 years ago
|
||
*** Bug 149199 has been marked as a duplicate of this bug. ***
Comment 22•22 years ago
|
||
*** Bug 153125 has been marked as a duplicate of this bug. ***
Comment 23•22 years ago
|
||
Anyone fancy updating the status / target milestone here? Given that nothing seems to be happening, a target milestone of future seems more appropriate. This also seems to block bug 30027 (Composer should support XML and DHTML), as per comment 5 in that bug.
Blocks: WYSIWYG
Comment 24•22 years ago
|
||
For what it is worth . . . I'm using v1.3a on WindowsME and the composer hard codes the following on all pages created or edited: <!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en"> This does not validate at: http://validator.w3.org/file-upload.html w3.org lists the following as a valid DOCTYPE: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
Comment 25•22 years ago
|
||
Thanks for the msg BalowStar. Could someone upgrade this from enhancement, i think "normal" at a minimumn represents this problem, it is a broken feature for composer to create nonstandard html code. JG > ------- Additional Comments From BalowStar@boomerbible.com 2003-01-31 06:11 ------- > For what it is worth . . . > > I'm using v1.3a on WindowsME and the composer hard codes the following on all > pages created or edited: > <!DOCTYPE doctype PUBLIC "-//w3c//dtd html 4.0 transitional//en"> > > This does not validate at: > http://validator.w3.org/file-upload.html > > w3.org lists the following as a valid DOCTYPE: > <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" > "http://www.w3.org/TR/html4/loose.dtd"> >
Comment 26•22 years ago
|
||
Balow Star--I don't see that in my daily build from today (almost 1.3beta?). I see: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> When I validate a dummy file it tells me that it validates fine. Can you try a newer build to see if you see what I see? If it is a problem, could you file a new bug? Thanks! JG--This particular bug is an enhancement. The problems Balow Star describes above are not a part of this bug. It should be covered in a new bug if indeed it is a problem in recent builds.
Target Milestone: mozilla1.2beta → ---
Comment 27•21 years ago
|
||
I wish this bug would be fixed soon. I think its current priority should be increased and a target set to a defined milestone. Allowing Composer to use strict HTML 4.01 brings many benefits to webpages: - more consistent rendering across W3C web standards compliant browsers - triggering standards compliant rendering mode in MSIE 6 where the CSS1 box model is correctly implemented. MSIE 6 is by far the most frequently used browser out there. - strict 4.01 pages are parsed and rendered faster on all W3C web standards compliant browsers - etc.. It is in the best interests of Composer users to be able to edit a webpage with a strict HTML 4.01 DTD. Right now, strict HMTL 4.01 DTD triggers standards compliant rendering mode in all web standards compliant browsers which support doctype switching/triggering. I wish I could fix this bug. I wish I could help Mr Manske. All I can do is vote for this bug. Thanks for listening.
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 28•20 years ago
|
||
*** Bug 282238 has been marked as a duplicate of this bug. ***
Updated•16 years ago
|
Assignee: cmanske → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: sujay → composer
Whiteboard: [RFE] (2 days)
Comment 29•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 30•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 31•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 32•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 33•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 34•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 35•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
You need to log in
before you can comment on or make changes to this bug.
Description
•