Open Bug 92525 Opened 23 years ago Updated 15 years ago

Allow users to change DOCTYPE of edited HTML documents

Categories

(SeaMonkey :: Composer, enhancement)

Product:
SeaMonkey
Component:
Composer
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

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 :-(
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
Keywords: correctness
*** Bug 92474 has been marked as a duplicate of this bug. ***
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
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
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 (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


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.
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)



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. 
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.

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. 

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).
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
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?
spam composer change
Component: Editor: Core → Editor: Composer
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
Whiteboard: [RFE] EDITORBASE (2 days) → [RFE] EDITORBASE- (2 days)
Whiteboard: [RFE] EDITORBASE- (2 days) → [RFE] (2 days)
is this a dupe/dependency of bug 74377?
*** Bug 74377 has been marked as a duplicate of this bug. ***
changing milestone
Target Milestone: mozilla1.0 → mozilla1.1
removing myself from the cc list
Target Milestone: mozilla1.1alpha → mozilla1.2beta
*** Bug 149199 has been marked as a duplicate of this bug. ***
*** Bug 153125 has been marked as a duplicate of this bug. ***
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
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">
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">
> 
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 → ---
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.
Product: Browser → Seamonkey
*** Bug 282238 has been marked as a duplicate of this bug. ***
Assignee: cmanske → nobody
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: sujay → composer
Whiteboard: [RFE] (2 days)
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
Still a valid RFE.
Status: UNCONFIRMED → NEW
You need to log in before you can comment on or make changes to this bug.