Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
On Mar 7, 2013 10:37 PM, Brady Eidson beid...@apple.com wrote: On Thu, Mar 7, 2013 at 2:14 PM, Michael Saboff msab...@apple.com wrote: The various tokenizers / lexers work various ways to handle LChar versus UChar input streams. Most of the other tokenizers are templatized on input character type. In the case of HTML, the tokenizer handles a UChar character at a time. For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. There may be additional performance to be gained by doing all other possible handling in 8 bits, but an 8 bit stream can still contain escapes that need a UChar representation as you point out. Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer. The HTML tokenizer uses SegmentedString's that can consist of sub strings with either LChar and UChar. That is where the LChar to UChar zero extension happens for an 8 bit sub string. My research showed that at the time showed that there were very few UTF-16 only resources (5% IIRC), although I expect the number to grow. On Mar 7, 2013, at 2:16 PM, Adam Barth aba...@webkit.org wrote: Yes, I understand how the HTML tokenizer works. :) I didn't understand these details, and I really appreciate Michael describing them. I'm also glad others on the mailing list had an opportunity to get something out of this. ~Brady I agree with Brady. I got some interesting learning out of this thread. Always nice to read explanations and documentation about how things work. Valuable content. Luis ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
On Sat, Mar 9, 2013 at 12:48 PM, Luis de Bethencourt l...@debethencourt.com wrote: On Mar 7, 2013 10:37 PM, Brady Eidson beid...@apple.com wrote: On Thu, Mar 7, 2013 at 2:14 PM, Michael Saboff msab...@apple.com wrote: The various tokenizers / lexers work various ways to handle LChar versus UChar input streams. Most of the other tokenizers are templatized on input character type. In the case of HTML, the tokenizer handles a UChar character at a time. For 8 bit input streams, the zero extension of a LChar to a UChar is zero cost. There may be additional performance to be gained by doing all other possible handling in 8 bits, but an 8 bit stream can still contain escapes that need a UChar representation as you point out. Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer. The HTML tokenizer uses SegmentedString's that can consist of sub strings with either LChar and UChar. That is where the LChar to UChar zero extension happens for an 8 bit sub string. My research showed that at the time showed that there were very few UTF-16 only resources (5% IIRC), although I expect the number to grow. On Mar 7, 2013, at 2:16 PM, Adam Barth aba...@webkit.org wrote: Yes, I understand how the HTML tokenizer works. :) I didn't understand these details, and I really appreciate Michael describing them. I'm also glad others on the mailing list had an opportunity to get something out of this. I agree with Brady. I got some interesting learning out of this thread. Always nice to read explanations and documentation about how things work. Valuable content. In retrospect, I think what I was reacting to was msaboff statement that an unnamed group of people had decided that the HTML tokenizer was too unwieldy to have a dedicated 8-bit path. In particular, it's unclear to me who made that decision. I certainly do not consider the matter decided. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Should we create an 8-bit path from the network stack to the parser?
On Mar 9, 2013, at 3:05 PM, Adam Barth aba...@webkit.org wrote: In retrospect, I think what I was reacting to was msaboff statement that an unnamed group of people had decided that the HTML tokenizer was too unwieldy to have a dedicated 8-bit path. In particular, it's unclear to me who made that decision. I certainly do not consider the matter decided. It would be good to find out who it was that said that (or more specifically: Using a character type template approach was deemed to be too unwieldy for the HTML tokenizer.) so you can talk to them about it. Michael? Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
On Mar 8, 2013, at 3:09 PM, Adam Barth aba...@webkit.org wrote: I've posted a patch to limit the -apple- and -khtml- CSS vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=111890 My understanding is that I also need to add a runtime flag in order to fully hide these prefixes from the web because Safari and Dashboard share the same WebCore binary on Mac OS X. I found the following entry in Settings.in: usesDashboardBackwardCompatibilityMode initial=false, conditional=DASHBOARD_SUPPORT However, some of the paces we need to check this flag do not have easy access to the Page and therefore have trouble finding the Settings object. Would it be possible to use a global static flag to hide these prefixes from the web? I don't understand the details of how Safari and Dashboard share WebCore to know if a global static flag would work correctly. Safari and DashboardClient (the executable that actually renders widgets) link the same copy of WebCore on disk, but are separate executables at runtime. Dashboard backwards compatibility mode is triggered by the per-WebView _setDashboardBehavior: call which then sets the usesDashboardBackwardCompatibilityMode setting. It appears that any app using this SPI either sets it on all WebViews or none. So it's probably workable to make usesDashboardBackwardCompatibilityMode be effectively a global setting. Reviewing the pre-installed widgets and a random sampling of other widgets, I found: - The only -apple prefixed property used is -apple-dashboard-region. This property is seemingly always used with a -apple prefix and never with -khtml or -webkit. - The builtin widgets use a -khtml prefix for -khtml-user-select and -khtml-user-modify. I filed a bug to fix this. Some third-party widgets use the -khtml prefix on random other properties. My recommendation would be: * Do one of the following two options: - Plan A: Rename -webkit-dashboard-region to -apple-dashboard-region in CSSPropertyNames.in (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). - Plan B: Support -apple- as a prefix alias only for -webkit-dashboard-region (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). * Remove all other support for the -apple- prefix as a synonym for -webkit- * Make -khtml- prefix alias support only available if ENABLE_DASHBOARD_SUPPORT is on, and also runtime-conditional based on usesDashboardBackwardCompatibilityMode having ever been set for any Settings object. Depending on whether Plan A or Plan B is preferred, I can file a bug to replace -apple-dashboard-region with -webkit-dashboard-region in the preinstalled Dashboard widgets. Regards, Maciej Thanks, Adam On Fri, Mar 1, 2013 at 4:57 PM, Maciej Stachowiak m...@apple.com wrote: I think we'll want to take these out for Apple ports as soon as we can check prevalence in older Apple-specific content (e.g. Dashboard widgets). On Fri, Mar 1, 2013 at 9:11 AM, David Hyatt hy...@apple.com wrote: I agree with you that this would be pretty terrible. We definitely don't want developers doing that. On Feb 28, 2013, at 6:02 PM, Adam Barth aba...@webkit.org wrote: I noticed this comment on the Hacker News thread about Paul Irish's recent blog post: ---8--- CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-. Using this information, can you target Chrome with the webkit- prefix and Safari with the apple- prefix? Specifying the apple- prefix after webkit- will ensure that Safari uses that one, right? ---8--- http://news.ycombinator.com/item?id=5302150 If developers start using this technique, it might be harder to remove these prefixes in the future. Chromium's experience removing these prefixes has been quite positive. We ran into one compatibility problem on apple.com, which Apple was gracious enough to fix. I'd recommend that the rest of the ports disable ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- and -apple- CSS prefixes before it's too late. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 8, 2013, at 3:09 PM, Adam Barth aba...@webkit.org wrote: I've posted a patch to limit the -apple- and -khtml- CSS vendor prefixes to ENABLE(DASHBOARD_SUPPORT): https://bugs.webkit.org/show_bug.cgi?id=111890 My understanding is that I also need to add a runtime flag in order to fully hide these prefixes from the web because Safari and Dashboard share the same WebCore binary on Mac OS X. I found the following entry in Settings.in: usesDashboardBackwardCompatibilityMode initial=false, conditional=DASHBOARD_SUPPORT However, some of the paces we need to check this flag do not have easy access to the Page and therefore have trouble finding the Settings object. Would it be possible to use a global static flag to hide these prefixes from the web? I don't understand the details of how Safari and Dashboard share WebCore to know if a global static flag would work correctly. Safari and DashboardClient (the executable that actually renders widgets) link the same copy of WebCore on disk, but are separate executables at runtime. Dashboard backwards compatibility mode is triggered by the per-WebView _setDashboardBehavior: call which then sets the usesDashboardBackwardCompatibilityMode setting. It appears that any app using this SPI either sets it on all WebViews or none. So it's probably workable to make usesDashboardBackwardCompatibilityMode be effectively a global setting. Reviewing the pre-installed widgets and a random sampling of other widgets, I found: - The only -apple prefixed property used is -apple-dashboard-region. This property is seemingly always used with a -apple prefix and never with -khtml or -webkit. - The builtin widgets use a -khtml prefix for -khtml-user-select and -khtml-user-modify. I filed a bug to fix this. Some third-party widgets use the -khtml prefix on random other properties. My recommendation would be: * Do one of the following two options: - Plan A: Rename -webkit-dashboard-region to -apple-dashboard-region in CSSPropertyNames.in (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). - Plan B: Support -apple- as a prefix alias only for -webkit-dashboard-region (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). * Remove all other support for the -apple- prefix as a synonym for -webkit- * Make -khtml- prefix alias support only available if ENABLE_DASHBOARD_SUPPORT is on, and also runtime-conditional based on usesDashboardBackwardCompatibilityMode having ever been set for any Settings object. Depending on whether Plan A or Plan B is preferred, I can file a bug to replace -apple-dashboard-region with -webkit-dashboard-region in the preinstalled Dashboard widgets. That sounds like a good plan. Given that Plans A and B differ only builds shipped by Apple, I'll leave that choice up to you. I'm happy to write a patch that executes the parts of this plan that involve the WebKit codebase. Adam On Fri, Mar 1, 2013 at 4:57 PM, Maciej Stachowiak m...@apple.com wrote: I think we'll want to take these out for Apple ports as soon as we can check prevalence in older Apple-specific content (e.g. Dashboard widgets). On Fri, Mar 1, 2013 at 9:11 AM, David Hyatt hy...@apple.com wrote: I agree with you that this would be pretty terrible. We definitely don't want developers doing that. On Feb 28, 2013, at 6:02 PM, Adam Barth aba...@webkit.org wrote: I noticed this comment on the Hacker News thread about Paul Irish's recent blog post: ---8--- CSS parsing is the same, though. Slurping up your CSS and turning it into CSSOM’s pretty standard. Yeah, though Chrome accepts just the -webkit- prefix whereas Apple and other ports accept legacy prefixes like -khtml- and -apple-. Using this information, can you target Chrome with the webkit- prefix and Safari with the apple- prefix? Specifying the apple- prefix after webkit- will ensure that Safari uses that one, right? ---8--- http://news.ycombinator.com/item?id=5302150 If developers start using this technique, it might be harder to remove these prefixes in the future. Chromium's experience removing these prefixes has been quite positive. We ran into one compatibility problem on apple.com, which Apple was gracious enough to fix. I'd recommend that the rest of the ports disable ENABLE(LEGACY_CSS_VENDOR_PREFIXES) to remove support for the -khtml- and -apple- CSS prefixes before it's too late. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
On Mar 9, 2013, at 8:00 PM, Adam Barth aba...@webkit.org wrote: On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak m...@apple.com wrote: My recommendation would be: * Do one of the following two options: - Plan A: Rename -webkit-dashboard-region to -apple-dashboard-region in CSSPropertyNames.in (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). - Plan B: Support -apple- as a prefix alias only for -webkit-dashboard-region (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). * Remove all other support for the -apple- prefix as a synonym for -webkit- * Make -khtml- prefix alias support only available if ENABLE_DASHBOARD_SUPPORT is on, and also runtime-conditional based on usesDashboardBackwardCompatibilityMode having ever been set for any Settings object. Depending on whether Plan A or Plan B is preferred, I can file a bug to replace -apple-dashboard-region with -webkit-dashboard-region in the preinstalled Dashboard widgets. That sounds like a good plan. Given that Plans A and B differ only builds shipped by Apple, I'll leave that choice up to you. I'm happy to write a patch that executes the parts of this plan that involve the WebKit codebase. I very slightly prefer Plan A. The main downside is having a non-webkit prefix in the code with no migration path off of it. But it's a property that is not applicable to anything but Dashboard as designed[*]. So maybe lack of migration path is OK. I wasn't sure if anyone else would object to semi-permanently having code for a -apple- property, which is why I listed the alternative, which does have a migration path. Regards, Maciej * - The problem it's trying to solve - determining what parts of the widget react to mouse events normally and which parts can be used to drag the whole widget around -- was solved for touch scrolling on iPhone without having to introduce any new CSS properties. So I wouldn't recommend anyone ever doing anything similar, even if they had a similar problem to solve. ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] -khtml- and -apple- CSS prefixes
On Sat, Mar 9, 2013 at 8:55 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 9, 2013, at 8:00 PM, Adam Barth aba...@webkit.org wrote: On Sat, Mar 9, 2013 at 5:02 PM, Maciej Stachowiak m...@apple.com wrote: My recommendation would be: * Do one of the following two options: - Plan A: Rename -webkit-dashboard-region to -apple-dashboard-region in CSSPropertyNames.in (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). - Plan B: Support -apple- as a prefix alias only for -webkit-dashboard-region (it is only compiled in with ENABLE_DASHBOARD_SUPPORT anyway). * Remove all other support for the -apple- prefix as a synonym for -webkit- * Make -khtml- prefix alias support only available if ENABLE_DASHBOARD_SUPPORT is on, and also runtime-conditional based on usesDashboardBackwardCompatibilityMode having ever been set for any Settings object. Depending on whether Plan A or Plan B is preferred, I can file a bug to replace -apple-dashboard-region with -webkit-dashboard-region in the preinstalled Dashboard widgets. That sounds like a good plan. Given that Plans A and B differ only builds shipped by Apple, I'll leave that choice up to you. I'm happy to write a patch that executes the parts of this plan that involve the WebKit codebase. I very slightly prefer Plan A. The main downside is having a non-webkit prefix in the code with no migration path off of it. But it's a property that is not applicable to anything but Dashboard as designed[*]. So maybe lack of migration path is OK. I wasn't sure if anyone else would object to semi-permanently having code for a -apple- property, which is why I listed the alternative, which does have a migration path. That doesn't seem like a big burden for the project, especially if it's just one property and not exposed to the web. The real risk here is web sites becoming dependent on these prefixes to handle quirks between CoreAnimation and the Chromium Compositor. Adam ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
