Bug 162980 - Add html tag after HTML 4.01 doctype via outline view's "Add After" adds lots of extra tags
Summary: Add html tag after HTML 4.01 doctype via outline view's "Add After" adds lots...
Status: RESOLVED WONTFIX
Alias: None
Product: WTP Source Editing
Classification: WebTools
Component: wst.html (show other bugs)
Version: 1.5   Edit
Hardware: PC Windows XP
: P3 major (vote)
Target Milestone: Future   Edit
Assignee: Ian Tewksbury CLA
QA Contact: Nitin Dahyabhai CLA
URL:
Whiteboard:
Keywords: helpwanted
Depends on:
Blocks:
 
Reported: 2006-10-31 14:28 EST by Amy Wu CLA
Modified: 2009-09-09 13:31 EDT (History)
2 users (show)

See Also:


Attachments
screenshot - trying to reproduce bug (40.93 KB, image/png)
2009-03-11 12:19 EDT, Davoud Salahi Rad CLA
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Amy Wu CLA 2006-10-31 14:28:43 EST
Using WTp 1.5.2

1. create an html file with just the following:
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2. from the outline view, rightclick the DOCTYPE tag, Add After -> html - menu -> html 
3. The following is inserted:
<html>
<head>
<title></title>
</head>
<frameset>
	<frame>
</frameset>
<map name="">
	<area alt="">
</map>
<pre></pre>
<bdo dir="ltr"></bdo>
<input>
<p></p>
<noscript></noscript>
<i></i>
<button></button>
<label></label>
<u></u>
<h6></h6>
<center></center>
<basefont size="">
<s></s>
<blockquote></blockquote>
<h3></h3>
<ul>
	<li></li>
</ul>
<b></b>
<select>
	<option></option>
</select>
<q></q>
<strike></strike>
<script type="text/javascript"></script>
<abbr></abbr>
<big></big>
<h1></h1>
<img alt="" src="">
<acronym></acronym>
<del></del>
<noframes>
<body></body>
</noframes>
<textarea rows="" cols=""></textarea>
<h2></h2>
<font></font>
<object></object>
<kbd></kbd>
<iframe></iframe>
<hr>
<h4></h4>
<dir>
	<li></li>
</dir>
<samp></samp>
<ins></ins>
<h5></h5>
<sup></sup>
<a></a>
<dfn></dfn>
<isindex>
<dl>
	<dt></dt>
</dl>
<var></var>
<fieldset><legend></legend></fieldset>
<table>
	<tr>
		<td></td>
	</tr>
</table>
<br>
<tt></tt>
<applet alt=""></applet>
<ol>
	<li></li>
</ol>
<small></small>
<cite></cite>
<form action=""></form>
<div></div>
<code></code>
<span></span>
<sub></sub>
<em></em>
<menu>
	<li></li>
</menu>
<address><tt></tt></address>
<strong></strong>
</html>

This only seems to happen with HTML 4.01 doctype (xhtml is fine) and it seems to just happen if you are inserting the html tag (inserting head, body, frameset all appear to work as expected)
Comment 1 Amy Wu CLA 2008-10-27 04:28:16 EDT
reassigning to inbox
Comment 2 Davoud Salahi Rad CLA 2009-03-11 12:19:40 EDT
Created attachment 128393 [details]
screenshot - trying to reproduce bug


I'm a Seneca student trying to fix some bugs. I'm not able to reproduce this bug. Could it be that it has been fixed? Right-clicking on the doctype tag, I don't see the options in the bug report. Please see attached screenshot.

Could you please confirm if the bug exists and if it does, could someone provide any information as to whether or not this bug should be looked at, what the expected behavior is and what the reason could be that it adds so much more information!?

What kind of change would be acceptable and would you be able to provide any help or hint as to which package or method this bug could be related to? 

Thanks and I look forward to hear from you...
Comment 3 Nitin Dahyabhai CLA 2009-03-12 02:11:56 EDT
In the org.eclipse.wst.html.ui plug-in, the org.eclipse.wst.html.ui.internal.contentoutline.HTMLNodeActionManager would be the place to start as it supplies the outline's context menu actions.  You'd have to not have the "html" element in the document to start to reproduce this, I think, and there's nothing I can think of that would have already fixed this problem.  I appreciate you taking a look at it.
Comment 4 Nick Sandonato CLA 2009-04-17 16:36:59 EDT
Hi Davoud,

If you're still looking at a place to get started, check out the org.eclipse.wst.html.core.internal.contentmodel.CtdHtml in project org.eclipse.wst.html.core class. It's responsible for setting up the children of the HTML element in the content model. Because the min/max occurrence of an element is calculated by the group's min/max occurrence, there might be a problem that stemmed from fixing bug 97342, which would say those elements all have a min occurrence of 1.

Furthermore, DOMContentBuildImpl is responsible for calculating the min and max number of occurrences of an element when building DOM content. Check out the method visitCMElementDeclaration in there.
Comment 5 Davoud Salahi Rad CLA 2009-04-22 15:54:29 EDT
Nitin, Thanks very much for your help and quick reply.

Nick, Thanks for the reply and the information you have provided; it's certainly great help. 

I will look into it and keep you guys posted. 

p.s. the course I had taken as part of which a bug had to be fixed has ended, it's exam week now and it's also my last semester, but these won't stop me from exploring Eclipse bugs :) I hope to come back with a patch. 

Comment 6 Ian Tewksbury CLA 2009-09-09 13:31:12 EDT
I spent a significant amount of time looking into this a few weeks back and this is not a trivial problem.  The cause is built into the core of the html content model code caused in part because each html tag has a hand coded Hed* class that represents that tag in an attempt to represent the restrictions put on tags in the HTML 4 spec.

To put it simply there is no trivial or even moderately not trivial way of changing this behavior without completely overhauling the HTML content model code base.  After speaking with others it was decided that this bug will not be fixed.  It has been almost 3 years since it was opened and other then the original opener there has been no other complaints about this functionality.  Therefor it is my assumption that while this functionality is not ideal there seems to be no complaint about it (most likely because no one ever tries to do it) and the time needed to change the functionality to something more ideal is not worth the effort for the return of this one seemingly unused scenario.

As a side note, when/if it comes time to implement HTML 5 new approaches will be considered that will not have this same flaw.