Enabling the HTML5 tree builder soon
We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work. The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world. There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the <isindex>, which we've chosen to match the spec exactly, or the <keygen> element, which needs some shadow DOM love to hide its implementation details from web content. As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction. I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know. Adam P.S., you can follow along by CCing yourself on the master bug, <https://bugs.webkit.org/show_bug.cgi?id=41123>, or by looking at our LayoutTest failure triage spreadsheet, <https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEE&hl=en>.
Love your work Adam, Eric and all involved with this project. On 22 July 2010 11:30, Adam Barth <abarth@webkit.org> wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work.
The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world.
There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the <isindex>, which we've chosen to match the spec exactly, or the <keygen> element, which needs some shadow DOM love to hide its implementation details from web content.
As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction.
I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know.
Adam
P.S., you can follow along by CCing yourself on the master bug, <https://bugs.webkit.org/show_bug.cgi?id=41123>, or by looking at our LayoutTest failure triage spreadsheet, < https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHl...
.
webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Would someone from Apple be willing to run the patch below though the PLT? We're doing well on our parsing benchmark (4% speedup), but the PLT might have a different mix of HTML. Thanks, Adam diff --git a/WebCore/html/HTMLTreeBuilder.cpp b/WebCore/html/HTMLTreeBuilder.cpp index 7a9c295..5b89c37 100644 --- a/WebCore/html/HTMLTreeBuilder.cpp +++ b/WebCore/html/HTMLTreeBuilder.cpp @@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer* tokenizer, HTMLDocument* documen , m_originalInsertionMode(InitialMode) , m_secondaryInsertionMode(InitialMode) , m_tokenizer(tokenizer) - , m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new LegacyHTMLTreeBuilder(document, reportErrors) : 0) + , m_legacyTreeBuilder(0) , m_lastScriptElementStartLine(uninitializedLineNumberValue) , m_scriptToProcessStartLine(uninitializedLineNumberValue) , m_fragmentScriptingPermission(FragmentScriptingAllowed) On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth <abarth@webkit.org> wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work.
The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world.
There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the <isindex>, which we've chosen to match the spec exactly, or the <keygen> element, which needs some shadow DOM love to hide its implementation details from web content.
As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction.
I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know.
Adam
P.S., you can follow along by CCing yourself on the master bug, <https://bugs.webkit.org/show_bug.cgi?id=41123>, or by looking at our LayoutTest failure triage spreadsheet, <https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEE&hl=en>.
I can do this. -- Stephanie Lewis On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
Would someone from Apple be willing to run the patch below though the PLT? We're doing well on our parsing benchmark (4% speedup), but the PLT might have a different mix of HTML.
Thanks, Adam
diff --git a/WebCore/html/HTMLTreeBuilder.cpp b/WebCore/html/HTMLTreeBuilder.cpp index 7a9c295..5b89c37 100644 --- a/WebCore/html/HTMLTreeBuilder.cpp +++ b/WebCore/html/HTMLTreeBuilder.cpp @@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer* tokenizer, HTMLDocument* documen , m_originalInsertionMode(InitialMode) , m_secondaryInsertionMode(InitialMode) , m_tokenizer(tokenizer) - , m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new LegacyHTMLTreeBuilder(document, reportErrors) : 0) + , m_legacyTreeBuilder(0) , m_lastScriptElementStartLine(uninitializedLineNumberValue) , m_scriptToProcessStartLine(uninitializedLineNumberValue) , m_fragmentScriptingPermission(FragmentScriptingAllowed)
On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth <abarth@webkit.org> wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work.
The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world.
There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the <isindex>, which we've chosen to match the spec exactly, or the <keygen> element, which needs some shadow DOM love to hide its implementation details from web content.
As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction.
I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know.
Adam
P.S., you can follow along by CCing yourself on the master bug, <https://bugs.webkit.org/show_bug.cgi?id=41123>, or by looking at our LayoutTest failure triage spreadsheet, <https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEE&hl=en>.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Thanks! On Mon, Jul 26, 2010 at 9:36 PM, Stephanie Lewis <slewis@apple.com> wrote:
I can do this.
-- Stephanie Lewis
On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
Would someone from Apple be willing to run the patch below though the PLT? We're doing well on our parsing benchmark (4% speedup), but the PLT might have a different mix of HTML.
Thanks, Adam
diff --git a/WebCore/html/HTMLTreeBuilder.cpp b/WebCore/html/HTMLTreeBuilder.cpp index 7a9c295..5b89c37 100644 --- a/WebCore/html/HTMLTreeBuilder.cpp +++ b/WebCore/html/HTMLTreeBuilder.cpp @@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer* tokenizer, HTMLDocument* documen , m_originalInsertionMode(InitialMode) , m_secondaryInsertionMode(InitialMode) , m_tokenizer(tokenizer) - , m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new LegacyHTMLTreeBuilder(document, reportErrors) : 0) + , m_legacyTreeBuilder(0) , m_lastScriptElementStartLine(uninitializedLineNumberValue) , m_scriptToProcessStartLine(uninitializedLineNumberValue) , m_fragmentScriptingPermission(FragmentScriptingAllowed)
On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth <abarth@webkit.org> wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work.
The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world.
There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the <isindex>, which we've chosen to match the spec exactly, or the <keygen> element, which needs some shadow DOM love to hide its implementation details from web content.
As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction.
I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know.
Adam
P.S., you can follow along by CCing yourself on the master bug, <https://bugs.webkit.org/show_bug.cgi?id=41123>, or by looking at our LayoutTest failure triage spreadsheet, <https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEE&hl=en>.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
I measure it as a 1% win on the PLT. -- Stephanie On Jul 26, 2010, at 12:36 PM, Stephanie Lewis wrote:
I can do this.
-- Stephanie Lewis
On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
Would someone from Apple be willing to run the patch below though the PLT? We're doing well on our parsing benchmark (4% speedup), but the PLT might have a different mix of HTML.
Thanks, Adam
diff --git a/WebCore/html/HTMLTreeBuilder.cpp b/WebCore/html/HTMLTreeBuilder.cpp index 7a9c295..5b89c37 100644 --- a/WebCore/html/HTMLTreeBuilder.cpp +++ b/WebCore/html/HTMLTreeBuilder.cpp @@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer* tokenizer, HTMLDocument* documen , m_originalInsertionMode(InitialMode) , m_secondaryInsertionMode(InitialMode) , m_tokenizer(tokenizer) - , m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new LegacyHTMLTreeBuilder(document, reportErrors) : 0) + , m_legacyTreeBuilder(0) , m_lastScriptElementStartLine(uninitializedLineNumberValue) , m_scriptToProcessStartLine(uninitializedLineNumberValue) , m_fragmentScriptingPermission(FragmentScriptingAllowed)
On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth <abarth@webkit.org> wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work.
The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world.
There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the <isindex>, which we've chosen to match the spec exactly, or the <keygen> element, which needs some shadow DOM love to hide its implementation details from web content.
As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction.
I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know.
Adam
P.S., you can follow along by CCing yourself on the master bug, <https://bugs.webkit.org/show_bug.cgi?id=41123>, or by looking at our LayoutTest failure triage spreadsheet, <https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEE&hl=en>.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
I measure it as a 1% win on the PLT.
Might be a good idea to test HTML iBench as well. - Maciej
-- Stephanie
On Jul 26, 2010, at 12:36 PM, Stephanie Lewis wrote:
I can do this.
-- Stephanie Lewis
On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
Would someone from Apple be willing to run the patch below though the PLT? We're doing well on our parsing benchmark (4% speedup), but the PLT might have a different mix of HTML.
Thanks, Adam
diff --git a/WebCore/html/HTMLTreeBuilder.cpp b/WebCore/html/HTMLTreeBuilder.cpp index 7a9c295..5b89c37 100644 --- a/WebCore/html/HTMLTreeBuilder.cpp +++ b/WebCore/html/HTMLTreeBuilder.cpp @@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer* tokenizer, HTMLDocument* documen , m_originalInsertionMode(InitialMode) , m_secondaryInsertionMode(InitialMode) , m_tokenizer(tokenizer) - , m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new LegacyHTMLTreeBuilder(document, reportErrors) : 0) + , m_legacyTreeBuilder(0) , m_lastScriptElementStartLine(uninitializedLineNumberValue) , m_scriptToProcessStartLine(uninitializedLineNumberValue) , m_fragmentScriptingPermission(FragmentScriptingAllowed)
On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth <abarth@webkit.org> wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work.
The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world.
There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the <isindex>, which we've chosen to match the spec exactly, or the <keygen> element, which needs some shadow DOM love to hide its implementation details from web content.
As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction.
I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know.
Adam
P.S., you can follow along by CCing yourself on the master bug, <https://bugs.webkit.org/show_bug.cgi?id=41123>, or by looking at our LayoutTest failure triage spreadsheet, <https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEE&hl=en>.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak <mjs@apple.com> wrote:
On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
I measure it as a 1% win on the PLT.
Might be a good idea to test HTML iBench as well.
Sure. I'd be happy to. Is that benchmark available publicly? Adam
I believe it is somewhere, but the setup is a hassle, so I'll run it tomorrow for you. -- Stephanie On Jul 28, 2010, at 8:13 PM, Adam Barth wrote:
On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak <mjs@apple.com> wrote:
On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
I measure it as a 1% win on the PLT.
Might be a good idea to test HTML iBench as well.
Sure. I'd be happy to. Is that benchmark available publicly?
Adam
slewis++ On Thu, Jul 29, 2010 at 3:15 AM, Stephanie Lewis <slewis@apple.com> wrote:
I believe it is somewhere, but the setup is a hassle, so I'll run it tomorrow for you.
-- Stephanie
On Jul 28, 2010, at 8:13 PM, Adam Barth wrote:
On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak <mjs@apple.com> wrote:
On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
I measure it as a 1% win on the PLT.
Might be a good idea to test HTML iBench as well.
Sure. I'd be happy to. Is that benchmark available publicly?
Adam
For future reference, iBench can be found here: ftp://ftp.pcmag.com/Benchmarks/i-bench/ib50.exe However, it requires a Windows system with IIS to set up the server, and is generally a hassle to set up as Stephanie said. Cheers, Maciej On Jul 28, 2010, at 10:09 PM, Adam Barth wrote:
slewis++
On Thu, Jul 29, 2010 at 3:15 AM, Stephanie Lewis <slewis@apple.com> wrote:
I believe it is somewhere, but the setup is a hassle, so I'll run it tomorrow for you.
-- Stephanie
On Jul 28, 2010, at 8:13 PM, Adam Barth wrote:
On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak <mjs@apple.com> wrote:
On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
I measure it as a 1% win on the PLT.
Might be a good idea to test HTML iBench as well.
Sure. I'd be happy to. Is that benchmark available publicly?
Adam
No change in iBench. -- Stephanie On Jul 28, 2010, at 8:15 PM, Stephanie Lewis wrote:
I believe it is somewhere, but the setup is a hassle, so I'll run it tomorrow for you.
-- Stephanie
On Jul 28, 2010, at 8:13 PM, Adam Barth wrote:
On Wed, Jul 28, 2010 at 7:39 AM, Maciej Stachowiak <mjs@apple.com> wrote:
On Jul 27, 2010, at 9:06 PM, Stephanie Lewis wrote:
I measure it as a 1% win on the PLT.
Might be a good idea to test HTML iBench as well.
Sure. I'd be happy to. Is that benchmark available publicly?
Adam
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Awesome. Thanks. Adam On Wed, Jul 28, 2010 at 6:06 AM, Stephanie Lewis <slewis@apple.com> wrote:
I measure it as a 1% win on the PLT.
-- Stephanie
On Jul 26, 2010, at 12:36 PM, Stephanie Lewis wrote:
I can do this.
-- Stephanie Lewis
On Jul 26, 2010, at 5:57 AM, Adam Barth wrote:
Would someone from Apple be willing to run the patch below though the PLT? We're doing well on our parsing benchmark (4% speedup), but the PLT might have a different mix of HTML.
Thanks, Adam
diff --git a/WebCore/html/HTMLTreeBuilder.cpp b/WebCore/html/HTMLTreeBuilder.cpp index 7a9c295..5b89c37 100644 --- a/WebCore/html/HTMLTreeBuilder.cpp +++ b/WebCore/html/HTMLTreeBuilder.cpp @@ -327,7 +327,7 @@ HTMLTreeBuilder::HTMLTreeBuilder(HTMLTokenizer* tokenizer, HTMLDocument* documen , m_originalInsertionMode(InitialMode) , m_secondaryInsertionMode(InitialMode) , m_tokenizer(tokenizer) - , m_legacyTreeBuilder(shouldUseLegacyTreeBuilder(document) ? new LegacyHTMLTreeBuilder(document, reportErrors) : 0) + , m_legacyTreeBuilder(0) , m_lastScriptElementStartLine(uninitializedLineNumberValue) , m_scriptToProcessStartLine(uninitializedLineNumberValue) , m_fragmentScriptingPermission(FragmentScriptingAllowed)
On Thu, Jul 22, 2010 at 3:30 AM, Adam Barth <abarth@webkit.org> wrote:
We're getting close to enabling the HTML5 tree builder on trunk. Once we do that, we'll have the core of the HTML5 parsing algorithm turned on, including SVG-in-HTML. There are still a bunch of details left to finish (such as fragment parsing, MathML entities, and better error reporting), but this marks a significant milestone for this work.
The tree builder is markedly more complicated than the tokenizer, and I'm sure we're going to have some bad regressions. I'd like to ask your patience and your help to spot and triage these regressions. We've gotten about as much mileage as we can out of the HTML5lib test suite and the LayoutTests. The next step for is to see how the algorithm works in the real world.
There are about 84 tests that will require new expectations, mostly due to invisible differences in render tree dumps (e.g., one more or fewer 0x0 render text). In about half the cases, we've manually verified that our new results agree with the Firefox nightly builds, which is great from a compliance and interoperability point of view. The other half involve things like the exact text for the <isindex>, which we've chosen to match the spec exactly, or the <keygen> element, which needs some shadow DOM love to hide its implementation details from web content.
As for performance, last time we ran our parser benchmark, the new tree builder was 1% faster than the old tree builder. There's still a bunch of low-hanging performance work we can do, such as atomizing strings and inlining functions. If you're interested in performance, let me or Eric know and we can point you in the right direction.
I don't have an exact timeline for when we're going to throw the switch, but sometime in the next few days. If you'd like us to hold off for any reason, please let Eric or me know.
Adam
P.S., you can follow along by CCing yourself on the master bug, <https://bugs.webkit.org/show_bug.cgi?id=41123>, or by looking at our LayoutTest failure triage spreadsheet, <https://spreadsheets.google.com/ccc?key=0AlC4tS7Ao1fIdEo0SFdLaVpiclBHMVNQcHlTenV5TEE&hl=en>.
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
participants (4)
-
Adam Barth
-
Cameron Wall
-
Maciej Stachowiak
-
Stephanie Lewis