Bug 14506

Summary: CSS rendering problem when adding DOM objects with javascript
Product: WebKit Reporter: François Lamboley <webkit.org>
Component: Layout and RenderingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Major CC: ap
Priority: P2    
Version: 523.x (Safari 3)   
Hardware: Mac (PowerPC)   
OS: OS X 10.4   
Attachments:
Description Flags
Test case
none
First attempt
darin: review-
New approach mjs: review-

François Lamboley
Reported 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.
Attachments
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-
DetailsFormatted DiffDiff
New approach (28.65 KB, patch)
2007-07-08 10:06 PDT, Rob Buis 		mjs: review-
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
François Lamboley
Comment 1 2007-07-03 01:25:59 PDT
Created attachment 15360 [details] Test case
Rob Buis
Comment 2 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 :} Cheers, Rob.
Maciej Stachowiak
Comment 3 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().
Darin Adler
Comment 4 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!
mitz
Comment 5 2007-07-08 07:24:45 PDT
See also bug 8007.
Alexey Proskuryakov
Comment 6 2007-07-08 08:31:15 PDT
..and bug 10932, which also contains a lot of discussion.
Rob Buis
Comment 7 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? Cheers, Rob.
Alexey Proskuryakov
Comment 8 2007-07-08 10:59:40 PDT
HTML 5 currently says: --------------- Document.createElement() 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?
Maciej Stachowiak
Comment 9 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.
Maciej Stachowiak
Comment 10 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.
Darin Adler
Comment 11 2007-07-09 09:46:05 PDT
*** This bug has been marked as a duplicate of 8007 ***
Note You need to log in before you can comment on or make changes to this bug.