Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 365935

Summary: Creating an element via DOM yields element with empty content
Product: [WebTools] WTP Source Editing Reporter: Konstantin Komissarchik <konstantin>
Component: wst.xmlAssignee: wst.xml <wst.xml-inbox>
Status: NEW --- QA Contact: Nick Sandonato <nsand.dev>
Severity: enhancement    
Priority: P3 CC: nsand.dev
Version: unspecified   
Target Milestone: ---   
Hardware: All   
OS: All   
Whiteboard:
Bug Depends on:    
Bug Blocks: 365774    

Description Konstantin Komissarchik CLA 2011-12-07 12:29:27 EST
When an element is created via XML editor DOM, we get something like this:

<root>
  <foo></foo>
</root>

Executing the same DOM API call against Apache DOM implementations yields the following text:

<root>
  <foo/>
</root>

Here is the DOM calls in question:

Element element = document.createElementNS( null, "foo" );
parent.insertBefore( element, refChild );

I don't believe DOM spec spells out which of this form is correct given the above API calls nor do I see any API in DOM to let one specify or change the form that is used.

This is particularly a problem for frameworks like Sapphire, where XML sits beneath something like form UI and users aren't typically editing XML source directly. We've heard multiple complaints from Sapphire adopters regarding this behavior. It is particular problematic for the following two cases:

1. Elements that only have attributes.
2. Marker elements (no attributes or content).

Users object to the editor producing empty content elements in this case.

It seems to me that XML editor DOM could follow Apache here and create self-closing element initially and only add separate closing tag when content is added.
Comment 1 Nick Sandonato CLA 2011-12-07 16:21:21 EST
Hi Konstantin,

This largely sounds like a style thing more than an actual problem, especially if the spec doesn't define a rule for this. If you had a patch to push us towards this, though, I'd be happy to take a look. Thanks.
Comment 2 Konstantin Komissarchik CLA 2011-12-07 16:35:52 EST
> This largely sounds like a style thing more than an actual problem

Users do see it as a problem. It doesn't matter if its a style issue or not. Arguably Apache behavior is more reasonable as I can control what variant I get by either inserting a blank text node or not adding any children.

> If you had a patch to push us towards this, though, I'd be happy to take a 
> look. 

I am afraid that I have no knowledge of SSE internals. The few times that I tried to dive in to debug things, I couldn't figure things out. There is an extra complication that I suspect the current behavior exists as a way to facilitate code completion, so if DOM behavior is changed to align with Apache, something would need to be done to get code completion working as originally intended. I think this issue requires attention of someone far more familiar with the code base than I am...