Bug 10612 - Fieldsets show up nested when block element is defined using shorthand
Summary: Fieldsets show up nested when block element is defined using shorthand
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: 420+
Hardware: Mac OS X 10.4
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-08-28 15:32 PDT by Parag Shah
Modified: 2010-09-20 01:20 PDT (History)
2 users (show)

See Also:


Attachments
Reduced testcase. (175 bytes, text/html)
2006-08-28 15:32 PDT, Parag Shah
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Parag Shah 2006-08-28 15:32:07 PDT
This may be a dupe of a more general bug (although I wasnt sure what keyword to search for).

When trying to show two fieldsets on top of each other, inserting a block element inside the first one (like this: "<div />") will cause the second fieldset to be a child of the first.

Safari doesnt seem to respect shorthand notation for block elements in this case.

See reduced testcase below.

Tested on latest nightly (8/28/06).
Comment 1 Parag Shah 2006-08-28 15:32:47 PDT
Created attachment 10289 [details]
Reduced testcase. 

Compare w/ FF or IE.
Comment 2 Alexey Proskuryakov 2007-10-05 04:50:35 PDT
> Safari doesnt seem to respect shorthand notation for block elements in this
> case.

No browser respects XML self-closing syntax in HTML files, so "<div />" is exactly the same as "<div>". However, WebKit error recovery doesn't match HTML5 and other browsers in this case.

Might be a duplicate of bug 6302.
Comment 3 Adam Barth 2010-09-20 00:37:09 PDT
Fixed by the HTML5 parser.
Comment 4 Alexey Proskuryakov 2010-09-20 00:39:19 PDT
Does this need a test case landed? There is even one attached to the bug.
Comment 5 Adam Barth 2010-09-20 00:49:23 PDT
We have lots of test cases for this sort of thing.
Comment 6 Alexey Proskuryakov 2010-09-20 01:10:08 PDT
A problem with HTML5 test cases is that they have no history behind them - so if the spec changes, and the tests change, we won't know what this means in practice.

Relying on these tests alone means losing information about practical consequences of reverting to old behavior. This bug is not the best example, since it doesn't list any live sites, but other bugs that are being closed now do.
Comment 7 Adam Barth 2010-09-20 01:20:50 PDT
Presumably changes to the specification will be done after considering lots of evidence.  What we have in bugs is only anecdotal.  I'm not sure I agree that one flavor of test is more tasty than another.  The nice thing about the HTML5lib test suite is that the test harness is optimized for testing the parser.  By adding tests to that test suite, we get to leverage the harness and share the tests with Firefox and whoever else is using the upstream test repo.