Bug 14506 - CSS rendering problem when adding DOM objects with javascript
Summary: CSS rendering problem when adding DOM objects with javascript
Status: RESOLVED DUPLICATE of bug 8007
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh PowerPC OS X 10.4
: P2 Major
Assignee: Nobody
Depends on:
Reported: 2007-07-03 01:25 PDT by François Lamboley
Modified: 2007-07-09 09:46 PDT (History)
1 user (show)

See Also:

Test case (1.41 KB, application/xhtml+xml)
2007-07-03 01:25 PDT, François Lamboley
no flags Details
First attempt (30.54 KB, patch)
2007-07-04 13:15 PDT, Rob Buis
darin: review-
Details | Formatted Diff | Diff
New approach (28.65 KB, patch)
2007-07-08 10:06 PDT, Rob Buis
mjs: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description François Lamboley 2007-07-03 01:25:01 PDT
When I create an element (using DOM functions) with javascript, the rendering is not well done: the class names are not checked. Even the element name is not seen: the only thing that's done is adding the text node in the p element generated.
Comment 1 François Lamboley 2007-07-03 01:25:59 PDT
Created attachment 15360 [details]
Test case
Comment 2 Rob Buis 2007-07-04 13:15:17 PDT
Created attachment 15388 [details]
First attempt

This fixes the testcase and some existing tests. Unfortunately it is hard to see if it changes pixel tests rather than layout tests, since so many seem to fail anyway :}

Comment 3 Maciej Stachowiak 2007-07-05 19:34:37 PDT
I'm not sure this should be limited to a subset of xhtml doctypes. xhtml is never in quirks mode, so it would be better not to have quirks. I think it might make sense to just always do this for createElement().
Comment 4 Darin Adler 2007-07-08 05:16:31 PDT
Comment on attachment 15388 [details]
First attempt

Setting review- based on Maciej's comments. I don't think we want to create a strict vs. quirks mode for XML unless there's some other browser or at least some specification suggesting we should do so.

It's probably right to have createElement always create XHTML elements in any XML document, especially if that's consistent with what other browsers do.

Looking at Document::setTitle, it seems that function already assumes it will do so!
Comment 5 mitz 2007-07-08 07:24:45 PDT
See also bug 8007.
Comment 6 Alexey Proskuryakov 2007-07-08 08:31:15 PDT
..and bug 10932, which also contains a lot of discussion.
Comment 7 Rob Buis 2007-07-08 10:06:14 PDT
Created attachment 15445 [details]
New approach

This patch follows comment #18 in bug 10932, i.e. Opera's solution. dom/xhtml/level3/core/nodelookupprefix10 is a bit special, it fails in Opera, FF2 and with this
patch, so maybe that test is broken?

Comment 8 Alexey Proskuryakov 2007-07-08 10:59:40 PDT
HTML 5 currently says:

The canonical form of HTML markup is all-lowercase; thus, this method will lowercase the argument before creating the requisite element. Also, the element created must be in the HTML namespace.

This follows a long discussion from Mozilla bugs, e.g. <https://bugzilla.mozilla.org/show_bug.cgi?id=354318#c2>.

Also, does the new test need to be a pixel one?
Comment 9 Maciej Stachowiak 2007-07-09 01:08:40 PDT
Comment on attachment 15445 [details]
New approach

Given what HTML5 says, and Mozilla's stance, I think we should just make createElement always use the xhtml namespace. It would then be possible to remove the HTMLDocument override for createElement.
Comment 10 Maciej Stachowiak 2007-07-09 01:11:44 PDT
http://bugs.webkit.org/show_bug.cgi?id=8007 is a duplicate and my proposed solution would render http://bugs.webkit.org/show_bug.cgi?id=10932 a wontfix.
Comment 11 Darin Adler 2007-07-09 09:46:05 PDT

*** This bug has been marked as a duplicate of 8007 ***