[webkit-dev] XML Serialization Issues
I was working on using MathJax [1] to turn MathML into SVG and ran into some serious serialization issues. In summary, as MathJax programmatically creates SVG renderings of the MathML, when it creates XLink attributes, it doesn't seem to define a prefix. While this works for rendering, it does when you try to extract a serialization of the SVG. That is, MathJax creates SVG 'use' elements like (assuming SVG as the default namespace): use xlink:href=#MJMATHI-78 xmlns:xlink=http://www.w3.org/1999/xlink/ but instead I get: use href=#MJMATHI-78 xmlns=http://www.w3.org/1999/xlink/ which makes the SVG incorrect as the 'use' element is now in the xlink namespace. You can work around this by manually setting the prefix property on each xlink:href attribute. Looking into why this happens, I can see that the serializer seriously broken in a number of ways when the DOM is constructed with incomplete (e.g. missing namespace declarations) or inconsistent information (e.g. same prefix used for different namespaces in the same context). I found at least 6 bugs outstanding (#16739 [2], #16496 [3], #19121 [4], #22958 [5], #83056 [6], #106531 [7]) and filed a new one (#117764 [8]). Some of these date back to 2007 (6 years ago!). These bugs break down to these categories: 1. Default namespace issues: #16739, #106531, #16496 2. Conflicting prefix mappings: #117764, #19121 3. Namespace attribute issues: #22958, #83056, #117764 In looking at the code (MarkupAccumulator.cpp), they all suffer from one of two problems: 1. The computed prefix used isn't properly used for the declaration. 2. The generated namespace mappings aren't properly stored, scoped, or dealt with when they are inconsistent. There is an general assumption in the code that certain prefixes should always be used for certain namespaces. Unfortunately, it does so without looking to see whether there is a conflict already in scope. Also, when the namespace is not recognized and there is no prefix, a prefix needs to be generated for the serialization. Having written several robust XML Serializers for other projects, this can all be fixed in a straightforward way. I've looked at the code and know what should be done. The changes are probably modest. Unfortunately, I can't spend the time to directly write and test the code till probably after November. :( I am certainly willing to help, explain my strategy, advise, test, etc. if there was another willing developer out there who would like to see these bugs closed. [1] http://www.mathjax.org/ [2] https://bugs.webkit.org/show_bug.cgi?id=16739 [3] https://bugs.webkit.org/show_bug.cgi?id=16496 [4] https://bugs.webkit.org/show_bug.cgi?id=19121 [5] https://bugs.webkit.org/show_bug.cgi?id=22958 [6] https://bugs.webkit.org/show_bug.cgi?id=83056 [7] https://bugs.webkit.org/show_bug.cgi?id=106531 [8] https://bugs.webkit.org/show_bug.cgi?id=117764 -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
On Tue, Jun 28, 2011 at 6:41 PM, Jeffrey Pfau jp...@apple.com wrote: See responses inline: On Jun 28, 2011, at 6:26 PM, Adam Barth wrote: A question and a comment: 1) Will this let us to remove the code for both the libxml2 and the QtXml parsers? I'd certainly much rather have one XML parser than three. This won't replace libxslt or QtXmlPatterns for XSL-T, as they depend on the respective XML libraries. The goal for this XML parser is to be able to replace the core XML parser itself. XSL-T support would have to come later. 2) One thing we found very helpful in working on the HTML parser was a good test suite. Presumably there are existing XML parsing test suites. You might consider landing one (or more) of these test suites as a first step. Adam I know that W3C provides a test suite, but it's probably not that comprehensive. I can try to find more online; I'm sure that some of the open source projects like libxml2 provide some. Actually, the XML test suite [1] is quite good and provides about 3058 tests (just checked). It is maintained by the XML Core working group. If you find something insufficient, I suggest you contact them or post on the mailing list for the test suite. Having written an XML parser before, I'd be happy to help in your endeavor. I had started to look into this myself but got distracted by other things. [1] http://www.w3.org/XML/Test/ -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
On Tue, Jun 28, 2011 at 6:50 PM, Eric Seidel e...@webkit.org wrote: I'm in general in favor of this effort (having worked extensively on the existing XML parsers). But I would caution you that xml is a ridiculously tiny fraction of the web. And it may not be worth the engineering effort to make a better parser. http://www.google.com/search?q=filetype:html = 25,270,000,000 http://www.google.com/search?q=filetype:xml = 71,000,000 I can't let this one just pass by! ;) First, filetype is by extension and not media type [1]. As such, that is an incorrect accounting of the amount of XML on the web. Secondly, just using file extensions, you'd have to enumerate and sum all the extensions used by all XML media types (e.g. .xhtml, .svg, etc.). Third, there is plenty of content on the web that Google does not crawl (the dark web) where there are petabytes of XML waiting for browsers to do something with it (e.g. astronomical data cone search services). I know the parser's speed is terrible as I've measured it recently. This is partially due to some of the things we are doing to deal with Unicode decoding to work around libxml2 issues. I think moving to native strings and decoding would improve the speed by a huge amount. It would be well work it to some to fix this. [1] http://www.google.com/support/webmasters/bin/answer.py?hl=enanswer=35287 -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
On Wed, Jun 29, 2011 at 3:39 AM, Maciej Stachowiak m...@apple.com wrote: Both RapidXml and Expat apparently have not been updated in quite some time (since 2009 and 2007 respectively). Copying an unmaintained project into the WebKit repository and forking it is certainly a possible alternative to writing something new based on the approach of our HTML5 parser. But I'm not sure it this approach gives us a long term more hackable code base. Cases where we've done this have often resulted in code that doesn't fit WebKit style and isn't fully understood by anyone. RapidXml in particular only claims reasonable W3C compatibility, which likely is not an adequate level of conformance for a browser engine. I don't know if updating it to full XML 1.0 and Namespaces in XML 1.0 compliance would be a lesser effort than adapting the HTML parser. I agree with this assessment. I went through an extensive search earlier this year (just after the contributor's meeting). Expat is a good parser but I worry about the support. It will also suffer from the string copy problem. I also checked around with some of my contacts at XML software vendors to determine what they've done. Some of them have gone native as well and wrote their own to deal with performance issues regarding their own internal apis, etc. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
On Tue, Jun 28, 2011 at 10:10 PM, Dirk Schulze k...@webkit.org wrote: Am 29.06.2011 um 05:42 schrieb TAMURA, Kent: I'm a little negative of developing a new XML parser. I'm afraid that the new parser introduces a lot of security/stability problems which existing parsers already resolved. I feel the same. Writing a new parser from scratch means introducing a lot of new security bugs, parsing errors and maybe bigger performance lost at the beginning. Speaking from the SVG side, we fail at least three tests on the W3C SVG Test Suite because of parsing bugs if libxml2 on MacOS. All of these bugs are fixed in later versions of libxml2. Updating libxml2 more often on MacOS would help a lot. With the new parser we won't loose support XSLT and XLink support? If we write our own XML parser, we'd still have to use libxml2 via the libxslt in the short term. libxslt uses its own internal data structures for XML documents and does not have a way to interface our DOM implementation. As such, you load documents via the libxslt's API for it to use. There are several XSLT bugs the relate to serialization of the XML and error reporting due to this usage. That does mean that we'd have one XML parser for loading documents (e.g. XHTML) and XMLHttpRequest and then another one for when we run XSLT. There are other choices for XSLT engines. XQuilla [1] has an almost complete XSLT 2 implementation with an API that allows bootstrapping both the DOM and parser usage. I've been chatting with one of the developers about their API and integration issues with WebKit but I haven't actually tried to integrate it yet. Another option is to use a javascript-based XSLT engine. I recently saw some exceedingly impressive demonstrations of cross-compiled XSLT processors interacting with the browser at XML Prague [2]. Personally, I like the idea of a javascript-based XSLT engine but that would be a departure from a native implementation and I wonder how that would work on all our supported platforms. [1] http://xqilla.sourceforge.net/HomePage [2] http://www.xmlprague.cz/2011/sessions.html#XSLT-on-the-browser -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
On Wed, Jun 29, 2011 at 7:18 AM, par...@paroga.com wrote: On Wed, 29 Jun 2011 06:55:57 -0700, Alex Milowski a...@milowski.org wrote: I know the parser's speed is terrible as I've measured it recently. This is partially due to some of the things we are doing to deal with Unicode decoding to work around libxml2 issues. I think moving to native strings and decoding would improve the speed by a huge amount. It would be well work it to some to fix this. With the same UTF-8 content the libxml2 parser is _faster_ than our HTML parser: https://bugs.webkit.org/show_bug.cgi?id=52036#c1 I don't think that there is a huge difference between the HTML and XML parser, so comparing should be ok in this case. After my (simple) performance tests I still think that parsing UTF-8 is better than UTF-16, since it usually has only half of the memory size. I should test your patch against the speed tests I used. I'll try to get to that soon. It is unclear to me how this relates to the original reasons why we decode, recode, and then decode due to issues with libxml2. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
On Wed, Jun 29, 2011 at 10:01 AM, Adam Barth aba...@webkit.org wrote: For what it's worth, we've got an extremely primitive XML parser PerformanceTest already: http://trac.webkit.org/browser/trunk/PerformanceTests/Parser/xml-parser.html I also have some tests I could post as a patch. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MathML Anonymous Block Conundrum
I've run into a conundrum with anonymous blocks yet again. I was helping track down a crash relating to DOM manipulation. While I fixed that particular case by just marking all the instances as anonymous blocks, this solution doesn't work in general. In many places in the MathML rendering code we create RenderMathMLBlock instances that are used to layout different constructs. For example, for fractions we stack two RenderMathMLBlock instances as wrappers for the numerator and denominator. In many instances, that is all we need to do. In other instances, such as fractions, we set style properties on each created instance. Here's the problem: If the created wrappers are marked as anonymous, the style created for the wrapper is ignored due to this bit from the CSS 2.1 recommendation: The properties of anonymous boxes are inherited from the enclosing non-anonymous box (e.g., in the example just below the subsection heading Anonymous block boxes, the one for DIV). Non-inherited properties have their initial value. For example, the font of the anonymous box is inherited from the DIV, but the margins will be 0. [1] If we don't mark them as anonymous, we can get a crash related to Javascript DOM manipulation at RenderBlock.cpp:680: ASSERT(anonymousChild-isAnonymous()); where it is searching for the anonymous wrapper that doesn't exist. In fact, I believe the problem is that the beforeChild parameter is the rendering object that has been wrapped and not the wrapper. As such, beforeChild is wrong and by adding something like: if (beforeChild !beforeChild-isRenderMathMLBlock()) beforeChild = beforeChild-parent(); I can fix that before I use it to add the wrapper. I would have to do this in all places where I know that I have wrappers with styles and where I could actually guarantee what I'm doing. In the case of fractions, over/under, and a few others, this may work fine. This doesn't feel like a good general solution. Also, if I wrap an added child and code elsewhere assumes that the parent/child relationship is the same as in the DOM, then I've broken their assumption. I see this same kind of behavior with table sections in the RenderTable object and I wonder why beforeChild isn't a problem there. I fail to understand why I need to mark things as anonymous as they aren't anonymous in the same sense of CSS. This is a layout construct needed to display the Mathematics. I need to create these rendering objects that do not correspond directly to a element in the way as most others do. I think I'm beginning to appreciate some of what Dave Hyatt was hinting at to me that I may need my own line layout algorithm but I still really don't want to go there. That is, layout of a fraction doesn't feel like line layout to me. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XMLReader Interface Patch XML Prague 2011
I've just uploaded a patch for WebKit that provides event-oriented parser for XML called XMLReader that is a variant of the behavior of XMLHttpRequest but, instead of building a whole document DOM, it delivers XML Events to an EventListener. The implementation has very low memory consumption characteristics and provides a great deal of flexibility for designing receiving applications that accomplish their XML tasks during the processing of the XML (e.g. data binding). I am presenting this interface at XML Prague tomorrow (Sunday, March 27th) and I've put the paper up at: http://www.milowski.com/research/xmlreader/ The page is #57145: https://bugs.webkit.org/show_bug.cgi?id=57145 I'm curious about any feedback you all might have. I should have sent this out earlier but I haven't had the time. Even gut feel or immediate reactions would be interesting. Don't hold back... :) -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Selection Highlight for Canvas Rendering Object on Mobile Platforms?
I'm not sure this is exactly the right place to start, but I'll start here since the intersection of Andriod, iOS, and other developers are here. I've been testing some ideas for using the HTML5 canvas on mobile platforms versus desktop and I've notice an annoying feature on the mobile platforms. It is most noticeable on Android but also shows up on iOS on the iPad or iPod touch devices. The application involves the use of a HTML5 canvas that intercepts touch events on the canvas. Areas of a geometric image changes shading when touched to represent fractions of the object. On both platforms, there seems to be something about focus from the touch even that causes a highlight for the whole box containing the canvas element. On iOS, a gray shaded version of the canvas shows up for a very, very short period of time. It is inconsistent and depends how long the touch gesture is on the canvas. Some very short touch gestures do now cause the highlight of the canvas. That may be because it is just too short of a period of time to draw the highlight. On Andriod, any touch gesture cases a border and highlight around the canvas. Both are undesired effects. I'm trying to understand why the canvas has special highlight features for touch gestures over any other rendering object. Looking at the code, the highlight seems to be from the fact that RenderHTMLCanvas inherits from RenderReplaced just like RenderImage does. It all seems to key off of whether the canvas is selected. But the highlight isn't there for mouse clicks on desktop platforms. None of the CSS tricks (e.g. -webkit-user-select: none) seem to help on mobile platforms. It seems to me that on touch-enabled platforms (e.g. mobile) you should be able to disable this selection highlight behavior for canvas somehow. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection Highlight for Canvas Rendering Object on Mobile Platforms?
On Fri, Mar 11, 2011 at 3:35 PM, David Hyatt hy...@apple.com wrote: -webkit-tap-highlight-color: transparent is what you need I suspect (at least for iOS). Yes, that does fix it for iOS. Thanks! On Android, there is still some selection behavior but it is now slightly different and happens, oddly, every other tap. :( -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Enable ArrayBuffer by default?
On Fri, Feb 11, 2011 at 1:41 AM, Adam Barth aba...@webkit.org wrote: How would folks feel about enabling ArrayBuffer by default? It seems to be a basic data type that's used by a bunch of stuff today and likely to be used by more stuff in the future. The API seems pretty stable and it's implemented by Firefox as well. +1 I'd like to have it enabled by default so we can get more feedback on its use. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Plugin Troubles with Local Builds vs. Nightly Build Differences
On Thu, Feb 10, 2011 at 3:55 PM, Jon Shier j...@jonshier.com wrote: Alex: See my bugs here: https://bugs.webkit.org/show_bug.cgi?id=49146 https://bugs.webkit.org/show_bug.cgi?id=37507 Basically, updated versions of the required executables aren't part of the open source repository. Workaround: Copy the WebKitPluginAgent and WebKitPluginHost to your locally built WebKit.framework from a recent nightly. Does that work for debugging as well? Seems like it should ... -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EventTarget Changes Causes Safari Launch Problems
On Wed, Feb 9, 2011 at 8:03 PM, Alex Milowski a...@milowski.org wrote: In a recent set of experiments in changes to XML processing, I added a new EventTarget class called XMLReader. As such, I had to add a toXMLReader() method to the EventTarget class. Previously, this has worked well but now, after updating this code to the latest trunk, I have a problem launching Safari (it crashes right at startup without even showing a window). It is unclear to me why it would have worked before but now does not. I've narrowed my troubles down to what I think is a virtual table change relating to the class structure although I really haven't proven that. If I hack my way around the need for the toXMLReader() method on EventTarget, doing some very unsavory things, the latest trunk with my changes and the latest version of Safari work fine. Any ideas why, within the last month, this would all change? Was I just lucky before? Grumble. This is a complete mystery but I think something in the build is trying to be too smart. It didn't make sense that code that I built (WebKit) would have a wrong virtual table for other code that I just build (WebCore). After leaving out my final change to the EventTarget class, I added in my method again, removed the build directory, and rebuilt. I can now launch safari. In the last couple days, I have done the same process of deleting the WebKitBuild directory, starting over with a clean build, and safari crashes. Is there something else that I should delete to make sure everything is in sync? Pre-compiled headers? I think the WebKit code built was out of sync with the WebCore changes I made but I can't see why that would be when I removed the build directory and ran the build-webkit script. That should have built everything correctly since I started from scratch. Anyway, things are back to normal. I'll put the paper and the patch up somewhere nearer to when I present this at XML Prague in late March. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Plugin Troubles with Local Builds vs. Nightly Build Differences
I've been trying to get some plugins to work with a locally built version of WebKit without much success. They do work in the nightly build and so that makes me think that my configuration or build is somehow different. I've noticed that when I use Tools/Scripts/run-safari, the plugin is launched using: /System/Library/Frameworks/WebKit.framework/WebKitPluginAgent instead of my locally build WebKit.framework from my build directory. In fact, the 'WebKitPluginAgent' executable isn't there in my locally built version of 'WebKit.framework'. Also, I would like to build a version of 'WebKit.app' like the nightly build. The nightly build works with these plugins. I was able to run Tools/BuildSlaveSupport/build-launcher-app but that put the frameworks in the wrong spot and the sparkle framework wasn't built. I was able to move things around a bit to get a working app but plugins still do not work. Is there a correct sequence of build steps to reproduce what the nightly build does to build WebKit.app such that WebKitPluginAgent also gets built (and hopefully plugins work)? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Plugin Troubles with Local Builds vs. Nightly Build Differences
On Thu, Feb 10, 2011 at 3:55 PM, Jon Shier j...@jonshier.com wrote: Alex: See my bugs here: https://bugs.webkit.org/show_bug.cgi?id=49146 https://bugs.webkit.org/show_bug.cgi?id=37507 Basically, updated versions of the required executables aren't part of the open source repository. Workaround: Copy the WebKitPluginAgent and WebKitPluginHost to your locally built WebKit.framework from a recent nightly. Great. The workaround worked! Thanks! I've wasted a lot of time tracking this down. We should really try to get this updated so a local build works with plugins. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] EventTarget Changes Causes Safari Launch Problems
In a recent set of experiments in changes to XML processing, I added a new EventTarget class called XMLReader. As such, I had to add a toXMLReader() method to the EventTarget class. Previously, this has worked well but now, after updating this code to the latest trunk, I have a problem launching Safari (it crashes right at startup without even showing a window). It is unclear to me why it would have worked before but now does not. I've narrowed my troubles down to what I think is a virtual table change relating to the class structure although I really haven't proven that. If I hack my way around the need for the toXMLReader() method on EventTarget, doing some very unsavory things, the latest trunk with my changes and the latest version of Safari work fine. Any ideas why, within the last month, this would all change? Was I just lucky before? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] EventListener Invocation Cost?
On Mon, Jan 10, 2011 at 10:19 AM, Darin Adler da...@apple.com wrote: On Jan 9, 2011, at 11:56 AM, Alex Milowski wrote: I'm not sure there is a lot that can be done about it. I’m sure we can speed it up if we have a reason to. Step one is to find out exactly where the time is spent. Then we figure out ways to streamline the code path. The experts on this may not have the same priorities you do, so they may not have plans to spend time improving it. I will certainly spend some time trying to narrow this down but I also think my current situation is rather extreme and so I may have spoke too soon. Digging deeper into the performance of the API I'm experimenting with shows, by no surprise, that it delivers an extreme number of small event objects. There is always going to be a penalty for that but the relative performance of the execution of the event listener is actually rather good if you take the number of events delivered into account. I'm certain that a listener within C++ would perform better, but that isn't a big surprise either. When you take the overall application speed into account, things look very different. That is, not just the speed of parsing and delivering the XML information but how long does it take the application to load or use the data it has received. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] EventListener Invocation Cost?
I'm working on an experiment that uses EventListener instances to handle a large number of events. I've noticed there is quite a bit of overhead when invoking a Javascript-based event listener. I'm not sure there is a lot that can be done about it. I've looked through the implementation of how the Javascript function gets evaluated. The only question I have right now is whether the event handler function from Javascript is JIT compiled. I'm not sure that really matters. It seems to be the invocation which causes the most cost. If I attach an empty function for the event, the processing slows down (i.e. the cost is incurred regardless of what is going on inside the function). It just seems like the cost of crossing the language boundary between C++ and Javascript is quite expensive. I've only tried this with JavascriptCore. I've not looked into bindings for v8 as of yet. Thoughts on this? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore Binding Problem
On Wed, Jan 5, 2011 at 7:38 PM, Alex Milowski a...@milowski.org wrote:
I've got a new IDL class I'm working of for some experiments in XML
and I've run into an interesting snag. I have a call to a parse
method from Javascript where the string argument seems to be getting
mangled. The IDL for the method looks like:
boolean parse(in DOMString str);
and the call from javascript looks like:
reader.parse(doctitleI am a document/title/doc);
Everything else about this interface implementation works fine.
Unfortunately, for the above method, the string of XML to parse comes
in as empty. It looks to me like things are mangled in some way but
I can't determine why.
Just as an experiment, I set a breakpoint in the Javascript debugger
inside Safari and found another interesting data point. The code in
the test case goes from the source:
window.onload = function() {
var xml = doc/;
reader.parse(xml);
}
to this displayed in the inspector when the breakpoint is hit:
window.onload = function() {
var xml = ;
reader.parse(xml);
}
That's very strange. Any ideas of what to look at here? Could the
JIT compiler for JavascriptCore be dropping/mangling the string
constant somehow?
--
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.
Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JavaScriptCore Binding Problem
Completely embarrassing ... but it is an XHTML file and so the markup in the string gets parsed unless I escape it ... *sigh* Too many hours wasted in the debugger on this one. :( So, it is a non-issue. Thanks to Evan Martin for pointed that out. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] libxml2 override encoding support
On Wed, Jan 5, 2011 at 5:07 AM, Patrick Gansterer par...@paroga.com wrote: Is there a reason why we can't pass the raw data to libxml2? E.g. when the input file is UTF-8 we convert it into UTF-16 and then libxml2 converts it back into UTF-8 (its internal format). This is a real performance problem when parsing XML [1]. Is there some (required) magic involved when detecting the encoding in WebKit? AFAIK XML always defaults to UTF-8 if there's no encoding declared. Can we make libxml2 do the encoding detection and provide all of our decoders so it can use it? [1] https://bugs.webkit.org/show_bug.cgi?id=43085 Looking at that bug, the XSLT argument is a red herring. We don't use libxml's data structures and so when we use libxslt we either turn the XML parser completely over to libxslt or we serialize and re-parse (that's how the javascript-invoked XLST works). In both cases, we're probably incurring a penalty for this double decoding of Unicode encodings. A native XML parser for WebKit would help in the situation where you aren't using XSLT. Only a native or different XSLT processor in conjunction with a native XML parser would help in all cases. The XSLT processor question is a thorny one that I brought up awhile ago. I personally would love to see us use a processor that has better integration with WebKit's API. There are a handful of choices but many of them are XSLT 2.0. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] libxml2 override encoding support
On Tue, Jan 4, 2011 at 7:14 PM, Eric Seidel e...@webkit.org wrote: You should feel encouraged to speak with dv (http://veillard.com/) more about this issue. Certainly I'd love to get rid of the hack, but I gave up after that email exchange. In the shorter term, fixing this bug or lack of feature in libxml2 would be ideal. I need to understand the two different ways we invoke XML parsing a bit better. We bootstrap the libxml2 parser slightly different depending on whether it is a string parser or a memory parser. Why is there a difference? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] JavaScriptCore Binding Problem
I've got a new IDL class I'm working of for some experiments in XML
and I've run into an interesting snag. I have a call to a parse
method from Javascript where the string argument seems to be getting
mangled. The IDL for the method looks like:
boolean parse(in DOMString str);
and the call from javascript looks like:
reader.parse(doctitleI am a document/title/doc);
Everything else about this interface implementation works fine.
Unfortunately, for the above method, the string of XML to parse comes
in as empty. It looks to me like things are mangled in some way but
I can't determine why.
The generated code from the IDL is:
EncodedJSValue JSC_HOST_CALL jsXMLReaderPrototypeFunctionParse(ExecState* exec)
{
JSValue thisValue = exec-hostThisValue();
if (!thisValue.inherits(JSXMLReader::s_info))
return throwVMTypeError(exec);
JSXMLReader* castedThis = static_castJSXMLReader*(asObject(thisValue));
XMLReader* imp = static_castXMLReader*(castedThis-impl());
const String str = ustringToString(exec-argument(0).toString(exec));
if (exec-hadException())
return JSValue::encode(jsUndefined());
JSC::JSValue result = jsBoolean(imp-parse(str));
return JSValue::encode(result);
}
The 'str' object in the debugger is empty and the argument from which
it is converted has a strange string of length 1 character.
Any ideas how this could get mangled? Something is obviously stepping
on some object but I can't see where. The other possibility is
something related to JIT compiling in the Javascript environment but
that is a pure guess at this point. The backtrace shows some JIT
compile code in the stack.
--
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.
Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] libxml2 override encoding support
I'm working through some rather thorny experiments with new XML
support within the browser and I ran into this snippet:
static void switchToUTF16(xmlParserCtxtPtr ctxt)
{
// Hack around libxml2's lack of encoding overide support by manually
// resetting the encoding to UTF-16 before every chunk. Otherwise libxml
// will detect ?xml version=1.0 encoding=encoding name? blocks
// and switch encodings, causing the parse to fail.
const UChar BOM = 0xFEFF;
const unsigned char BOMHighByte = *reinterpret_castconst unsigned
char*(BOM);
xmlSwitchEncoding(ctxt, BOMHighByte == 0xFF ?
XML_CHAR_ENCODING_UTF16LE : XML_CHAR_ENCODING_UTF16BE);
}
Looking at the libxml2 API, I've been baffled myself about how to
control the character encoding from the outside. This looks like a
serious lack of an essential feature. Anyone know about this above
hack and can provide more detail?
--
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.
Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] MathML renderer
On Tue, Jan 4, 2011 at 1:50 PM, Maciej Stachowiak m...@apple.com wrote: On Jan 4, 2011, at 11:03 AM, Dirk Schulze wrote: Hi webkit-dev, I was looking at the MathML code recently and I wonder, that all files are located at WebCore/mathml, even the renderer. Shouldn't the rendering code be moved to WebCore/rendering/? Or better WebCore/rendering/mathml/? Yes, the rendering code would be better placed in the rendering/ directory. Well, not to buck the trend, but ... I actually prefer having it all under the 'mathml' directory so that is what I did. No one has complained before. If there is a strong preference to move the RenderMathML* files to WebCore/rendering/, I'm not against it. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] libxml2 override encoding support
On Tue, Jan 4, 2011 at 7:05 PM, Alexey Proskuryakov a...@webkit.org wrote: 04.01.2011, в 18:40, Alex Milowski написал(а): Looking at the libxml2 API, I've been baffled myself about how to control the character encoding from the outside. This looks like a serious lack of an essential feature. Anyone know about this above hack and can provide more detail? Here is some history: http://mail.gnome.org/archives/xml/2006-February/msg00052.html, https://bugzilla.gnome.org/show_bug.cgi?id=614333. Well, that is some interesting history. *sigh* I take it the work around is that data is read and decoded into an internal string which is represented by a sequence of UChar. As such, we treat it as UTF16 character encoded data and feed that to the parser, forcing it to use UTF16 every time. Too bad we can't just tell it the proper encoding--possibly the one from the transport--and let it do the decoding on the raw data. Of course, that doesn't guarantee a better result. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Web Links (RFC 5988)
On Tue, Nov 9, 2010 at 6:01 PM, Alexey Proskuryakov a...@webkit.org wrote: Moving or copying essential information about a document into HTTP headers is frustrating for charset declarations, why do that for anything else? With charsets, there is at least the explanation that many text formats don't have a place to declare it internally. The charset parameter on the content-type header is more reliable than what is in the document. It also gives you a way to know how to decode the bytes into a character stream before you look into those bytes. The absence of a charset parameter requires the user agent to attempt strange things as the default character encoding for HTTP 1.1 is ISO-8859-1. In this way, it is very unlike the reservations some might have for the Link header. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Tue, Nov 9, 2010 at 8:00 PM, Eric Seidel e...@webkit.org wrote: This conversation is heading in a dangerous direction... :) Allowing QXML parser support to be added to WebKit was probably a mistake. Adding custom QXPath or QXSLT support would be another. WebKit is one platform. If XSLT or XPath 2.0 is good for the web, we should add them to all ports, just like we did XPath 1.x. The only reason XMLDocumentParserQt hasn't been a bigger compatibility problem (or source of crashes, security bugs, etc.) for the Qt Port is that XML is used so very very very little on the web (and it's relatively simple to parse). (The XMLDocumentParserQt was a huge headache for Adam and I when trying to re-factor DocumentParser for HTML5, for example. I'm sure we introduced still-present bugs in it.) Implementing XSLT 2.0 or just XPath 2.0 is a huge engineering effort. Like many other things, we should rely on an existing implementation if possible that can be used on the various platforms. I'd rather see a general solution where you can turn on 2.0 support and swap out the current use of libxslt. XSLT 2.0 is continuously asked about by those people who use XSLT in the browser. There are so many things that just work better or features that are now standard. It would be a real win to have such support that also runs efficiently within the context of transforming XML. Most of the implementations that I've looked at would also solve a number of issues with the current integration of libxslt as they wouldn't require serialization of the document to transform an exist XML DOM (e.g. transforming a node via javascript). The question is which one? I'm leaning towards xquilla as a choice but their XSLT 2.0 implementation isn't quite finished. The API is relatively clean and their implementation is active. It would also provide the ability to use XPath 2.0 and XQuery (although there is no API for that as of yet). The technical issue with xquilla is that their API uses XMemory, MemoryManager and few other low-level base classes for certains aspects like memory management, strings, etc. This would have to be resolved (or accepted) so that it would integrate well with WebKit. I suspect this sounds like a radical departure to many of you out there. In the case of things like libxslt, we expect it to be available on the platform or development environment so that it can be linked into WebKit somehow. We'd now add another such dependency for a new library that you might have to compile somehow. Thoughts on that? Also, keep in mind that I'm still trying to figure out which implementation would be the best choice given the architecture and API design of WebKit. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 10, 2010 at 10:29 AM, Maciej Stachowiak m...@apple.com wrote: The first thing we should figure out is whether XSLT 2.0 is something we even want to implement. If it's not backwards compatible with XSLT 1.0 and other browsers are not planning on implementing it, then it's a significant risk to move to XSLT 2.0. We'd likely break backwards compatibility with Web content, and end up long-term incompatible with other browsers. That's not very well aligned with the goals of the project. Breaking backwards compatibility is generally considered unacceptable, unless we can convincingly show it won't affect real-world content. XSLT 2.0 provides what it calls backwards compatibility mode. When an XSLT 2.0 processor encounters a transformation labeled with a version of 1.0, it can run that transform in the backwards compatibility mode. There are very minor differences but I highly doubt they would break existing uses (see [1]). For example, XPath 2.0 has the concept of sequences rather than node sets and within certain context, the string value will be space separated rather than the string value of the first node. If someone wrote a stylesheet assuming (or more likely accidentally using) that fact, with an XSLT 2.0 processor, the string value in the result would be from all the nodes. The output would essentially be slightly different. One could argue that was a poorly written stylesheet and it would be very easy to fix so that it had consistent behavior in XSLT 1.0 and 2.0 stylesheets. I need to look/ask around and see if I can quantify the scope of these incompatibilities in live stylesheets used on the web to help answer this question. If, in addition, XSLT 2.0 requires a major engineering effort and/or a large external dependency, then this would not be a cheap experiment. Now, we could add it under a new API, but then we'd be stuck carrying around two versions of XSLT forever, and Web content might not be able to reliably use the new version in any case. I guess I was thinking, to begin with, that this would be a compile-time feature that you could turn on. That's not a cheap experiment but, to begin with, I'm really talking about *my* time to implement such an integration. I have uses for such things and I just want to do it in such a way that the work would be an acceptable implementation if vendors choose to switch to 2.0. What we'd normally do in a situation like this is check with other implementors whether they are prepared to implement the new technology. I would recommend starting there, before we talk implementation strategy. I'd be curious about that too. For those that use XSLT in the browser, better (e.g. more reliable, consistent, and modern) support for XSLT would be very, very welcome. It is a long road to getting XSLT and XPath 2.0 support into *all* the major browsers. It has to start somewhere and a standoff of browser vendors, each looking at each other, waiting for each other to say yes first is where I believe we are right now. Possibly some are hoping that no one will say yes and the status quo will reign. [1] http://www.w3.org/TR/xslt20/#backwards-compatibility-behavior -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 10, 2010 at 11:25 AM, Maciej Stachowiak m...@apple.com wrote:
Do most existing XSLT 1.0 stylesheets have an explicit 1.0 label? Does XSLT
require this? How would unlabeled stylesheets be processed?
You are required to have a version attribute and it is a static error
if it does not. As a result, most web-oriented stylesheets will have
1.0 for this attribute. If the version is, say, 2.0, a 1.0
processor must process the transformation in forwards compatible mode
(without an error). Obviously, the result won't necessarily be the
same and certain expressions may cause errors (e.g. an unguarded XPath
2.0 only expression).
This allows someone to write a single transform that uses an
xsl:choose and do different things depending on the version available.
For example:
xsl:choose
xsl:when test=system-property('xsl:version') = 2.0
divWahooo!/div
/xsl:when
xsl:otherwise
divBooo!/div
/xsl:otherwise
/xsl:choose
I need to look/ask around and see if I can quantify the scope of these
incompatibilities in live stylesheets used on the web to help answer
this question.
Yeah, I am more interested in how much content would be affected, than
whether it is poorly written.
That is the question. Define content. We're not guarantee the
output is the same but I really wonder about the actual subset of XSLT
1.0 in use due to incompatibilities that exist (or have existed)
between browsers.
Looking at [1], Mozilla does not have full support for these XSLT 1.0 elements:
xsl:fallback (not supported)
xsl:import (mostly supported)
xsl:namespace-alias (not supported)
xsl:number (partially supported)
xsl:output (partially supported)
xsl:stylesheet (partially supported)
xsl:text (partially supported)
xsl:value-of (partially supported)
I personally have had major issues with xsl:import.
I'd be curious about that too. For those that use XSLT in the
browser, better (e.g. more reliable, consistent, and modern)
support for XSLT would be very, very welcome.
It is a long road to getting XSLT and XPath 2.0 support into *all* the
major browsers. It has to start somewhere and a standoff of browser
vendors, each looking at each other, waiting for each other to say
yes first is where I believe we are right now. Possibly some are
hoping that no one will say yes and the status quo will reign.
The informal information I have so far is that none of them want to say yes
and hope no one else does, because they don't like the complexity or
featureset.
In this case, they is some subset of developers and not they as in
users of XSLT on the web. XSLT 2.0 is just better than XSLT 1.0 in
many ways and vastly improves on the interoperability of
implementations.
Interesting, Mozilla does have a page for XSLT 2.0 [2] and they point
to an extension that provides XSLT 2.0 support via an extension [3].
I still am interested in what criteria would be used to judge a set of
patches to support XSLT 2.0 or XPath 2.0:
* Must it be home grown?
* If it is an external library, like XSLT 1.0 support is today, what
are the integration criteria (e.g. platform library vs. statically
linked, etc.)?
* As a library, what licenses are allowed (e.g. some of these
implementations are under the Apache license v2)?
[1] https://developer.mozilla.org/en/XSLT/Elements
[2] https://developer.mozilla.org/en/XSLT_2.0
[3] https://addons.mozilla.org/en-US/firefox/addon/5023/
--
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.
Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 10, 2010 at 2:12 PM, Alex Milowski a...@milowski.org wrote: * If it is an external library, like XSLT 1.0 support is today, what are the integration criteria (e.g. platform library vs. statically linked, etc.)? One more datum, that I just discovered, Apple has implemented XPath 2.0, XSLT 2.0, and XQuery: http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/NSXML_Concepts/NSXML.html (oh, the use of the fragment identifier for content location is just horrific!) Thus, on some platforms (Mac OS X, iOS 4.x), you get XSLT 2.0 support for free. Seems like the ability to use an OS's native support would be ideal as long as the same specification version support is available through some means on each port. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] HTML5 Web Links (RFC 5988)
Now that RFC 5988 is a proposed standard [1] and HTML5 references the Link: header [2], has anyone plans to introduce such support into WebKit ? It seems like a straight forward behavior to adopt. At minimum, the CSS stylesheets specified in the Link: header would be inserted, in order, between the user agent stylesheets and the document's stylesheets. Are there any implementation issues that one could imagine with this RFC? There are some obvious interoperability questions until enough browsers sufficiently support this feature. [1] http://tools.ietf.org/html/rfc5988 [2] http://dev.w3.org/html5/spec/Overview.html#the-link-element -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Sun, Nov 7, 2010 at 1:25 AM, Frans Englich fengl...@fastmail.fm wrote: Qt has complete XPath 2.0, XQuery 1.0, XSL-T 1.0 and Schema 1.0 stacks as well as a partly complete XSL-T 2.0 stack: http://doc.qt.nokia.com/4.7/xmlprocessing.html#features-and-conformance Very interesting. Has this been integrated at all with WebKit? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 3, 2010 at 6:28 PM, Alexey Proskuryakov a...@webkit.org wrote: 03.11.2010, в 10:11, Alex Milowski написал(а): many of the incompatibilities may not occur within the context of the browser with a pre-built DOM. WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. Also, we can't expect to stay at XPath 1.0 forever. Actually, I see this situation as similar to XHTML 2.0. XPath is embedded into browsers both directly and via XSLT. Any incompatible specification featuring the same name is likely to end up as an academic exercise, dead on arrival. Looking at Mozilla bugs, they seem to have zero interest in XPath 2.0 and XSLT 2.0: https://bugzilla.mozilla.org/show_bug.cgi?id=396966 https://bugzilla.mozilla.org/show_bug.cgi?id=370173 They might not but users do. Mozilla has its own XSLT 1.0 implementation that is not complete. I don't think that's a great comparison. We would need to pull an off the shelf implementation of XPath and XSLT 2.0. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Thu, Nov 4, 2010 at 2:16 PM, Alex Milowski a...@milowski.org wrote: WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. My belief, and please correct me if I'm wrong, is that once the XML has been parsed and built into a DOM, applyXSLTransform() at Document.cpp:3954 is eventually called with the correct XSLT from some xml-stylesheet processing instruction. With the libxslt, the DOM is serialized back into a string so it can be loaded into their internal format as they don't provide a way to give them a pre-existing DOM. I've been trying to trace through all the places where XSLT is used and how this all fits together. Finding an alternative to libxslt is something I think is a worthwhile endeavor due to the inability to integrate tightly with a pre-built DOM instance. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Thu, Nov 4, 2010 at 2:17 PM, Alex Milowski a...@milowski.org wrote: On Thu, Nov 4, 2010 at 2:16 PM, Alex Milowski a...@milowski.org wrote: WebKit currently applies XSLT to document source, not to pre-built DOM. This is different from Firefox, but in strict compliance to the spec. WebKit currently applies XSLT to a serialization of the pre-build XML DOM. As such, we have several bugs relating to cases where that serialization is not the same as the data received off the wire. Nevermind. My mistake. I should have dug further. Yes, I see that in the case of XSLT via the xml-stylesheet, we use the cached source. In the case of the Javascript XSLT processor, that's not the case and that's how we get differences. Nevertheless, I don't see how the xml-stylesheet spec [1] says you have to use the bytes off the wire. [1] http://www.w3.org/TR/xml-stylesheet/ -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing amp; MathML
On Tue, Nov 2, 2010 at 7:55 AM, David Carlisle d.p.carli...@gmail.com wrote: Personally I agree with you that this desire to make html elements forcibly close the surrounding math elements is entirely bogus, and it causes all sorts of problems in annotation-xml (where you really want nested html) but we failed to convince the html WG (or the html editor) of that and so ended up with a special case workaround for annotation-xml http://www.w3.org/Bugs/Public/show_bug.cgi?id=9887#c16 sometimes you have to take what you can get:-) I will take a look. However I don't agree that using the token elements as extension points is only necessary because of html parser strangeness, I think it leads to a cleaner design, and better fallback behaviour for systems that do not understand the foreign elements, in any case. Uncle! This will take some work to get working correctly with the implementation in WebKit. Right now, in XHTML documents with MathML, we get non-token XHTML for free. Within MathML token elements, this won't necessarily be the case. For example, the 'mo' element renderer as currently implemented won't preserve child rendering objects. We'll need to detect these situations and decide what to do. It would have been nice if MathML 3 had a foreign token element or indication via attribute typing so that we'd know that there is some kind of non-MathML content children that should be rendering according to the host language. We'll now have to have some kind of de-facto default set of rules that say that mixed content within a MathML is identified and handled slightly differently (especially if it contains things like SVG). That is, we'll need to detect things like: mathmo random text svg ... /svg more random text/mo/math While this example is rather pathological, it is still possible and should render as a stack of line boxes wrapped in the inline-block for the 'mo'. Also, this: mathmtext div .../div /mtext/math should be equivalent to the XHTML chunk: math xmlns='http://www.w3.org/1998/Math/MathML/'div xmlns='http://www.w3.org/1999/xhtml'.../div/math Both of the above examples should work today but once we implement the renderers for mtext/mi/mn etc. we'll need to take this foreign element rendering into account. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing amp; MathML
On Wed, Nov 3, 2010 at 7:49 AM, David Carlisle d.p.carli...@gmail.com wrote: It would have been nice if MathML 3 had a foreign token element or indication via attribute typing so that we'd know that there is some kind of non-MathML content children that should be rendering according to the host language. But elsewhere you argue that such an element isn't needed and you should just be able to drop in other namespaced elements anywhere. in fact MathML3-in-(x)html does specify such an element, namely content of mo mi mtext are specified as being html. Sure. ...didn't win that one! :) We have these token categories: * identifier (mi) * number (mn) * operator (mo) * text (mtext) * space (mspace) * string (ms) What if our use of some chunk of HTML doesn't fit in the categorization of the above? I would have been nice to have an ability to annotate foreign markup as some kind of layout element implemented in, say, HTML, and then potentially use embedded additional MathML for inner constructs. That way, things like accessibility would know that the foreign markup isn't a terminal structure of the Mathematics and might know (e.g. via ARIA) the role of the layout. ...so, that's what I meant. Just an idea ... We'll now have to have some kind of de-facto default set of rules that say that mixed content within a MathML is identified and handled slightly differently (especially if it contains things like SVG). differently to what? Sorry I'm not sure I understand what you mean here, can't you just always view the content of mtext as inline html: it basically has the same content model as the content of an html span. SVG is allowed there just because it's allowed in any inline html. Right. That's not different from what we'd expect. In section 3.2.1, it says: Token elements (other than mspace) should be rendered as their content, if any, (i.e. in the visual case, as a closely-spaced horizontal row of standard glyphs for the characters or images for the mglyphs in their content). Introduce a few SVG and HTML elements and then you have to make the assumptions about the children that are being rendered according to the normal rules (plus mglyph) so that this works: mi xyzzy div /div /mi Without any CSS, that 'div' will be a block whose rendering will cause a new block to be stacked within the inline. That's a consequence of my choice of using inline blocks and allowing the rendering of the 'div' to default to the current internal style within WebKit. I think that's the right choice but there might be other interpretations. For example, one could say that divs inside MathML have a display property of inline-block by default. That choice isn't covered by either MathML3 nor HTML5. I'm not sure it should be. That is, we'll need to detect things like: mathmo random text svg ... /svg more random text/mo/math as above i don't see why you need to detect such things any more than you need to detect Well, that's a consequence of building the rendering tree. Right now we don't have a special rendering object for token elements other than for 'mo'. In the case of operators, this becomes complicated due to operator stretching. It may work out to be straightforward but those feel like famous last words. That's all I meant. In fact your original proposal was that mathspan.svg should just work, and so what is to stop mtext being treated exactly like span? No much and hopefully it stays that way. At this point I'm not raising any issue except that I know that our 'mo' implementation is currently broken in this regard. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XPath Issues?
As far as I can tell, these are the only filed issues with XPath implementation within WebKit: https://bugs.webkit.org/show_bug.cgi?id=26157 https://bugs.webkit.org/show_bug.cgi?id=12504 https://bugs.webkit.org/show_bug.cgi?id=13233 https://bugs.webkit.org/show_bug.cgi?id=12632 https://bugs.webkit.org/show_bug.cgi?id=12496 https://bugs.webkit.org/show_bug.cgi?id=36427 Anything else out there? Is it complete? I'm curious about how robust this implementation is and what enhancements have been filed for it. I'm also looking at what it would take to enhance this implementation to support XPath 2.0 ... -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
On Wed, Nov 3, 2010 at 9:56 AM, Alexey Proskuryakov a...@webkit.org wrote: XPath 2.0 is not fully compatible with 1.0. JavaScript API for XPath doesn't provide a way to choose version - at least, it didn't when I last checked. So, we can't really support 2.0. I'm not sure that turns out to be a real issue considering this particular context. I've been shopping this idea around here at the W3C TPAC meeting and many of the incompatibilities may not occur within the context of the browser with a pre-built DOM. I'll have to dig further on that. It is certainly flawed that you can't choose a version. Unfortunately, there isn't a good way to test for XPath 1.0 but you can use an XPath 2.0 only expression to test for XPath 2.0 support. This should be fixed in the API. Also, we can't expect to stay at XPath 1.0 forever. At any rate, this would be considered completely experimental. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Focus Crash Relating to MathML
On Mon, Oct 18, 2010 at 8:22 PM, Alex Milowski a...@milowski.org wrote: In cases where specialized render objects (typically with display inline-block) are used (e.g. an operator), the assert fires: a href='#' math xmlns='http://www.w3.org/1998/Math/MathML'mox/mo/math /a The culprit in this particular case turns out to be a call to destroyLeftoverChildren() during the layout. The RenderMathMLOperator class potentially re-stacks the glyphs and that causes the children to be destroyed. During that process, the container ancestors are marked as having a child needing layout. At the end of the ancestor's layout() method, the MathML rendering objects have all sorted themselves out and no longer need layout. The result is that the tree is inconsistent. If the ancestors can easily be marked as having a child needing layout during the descendant's layout() process, shouldn't each ancestor check the consistency between if m_normalChildNeedsLayout and their actual children before leaving layout()? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Focus Crash Relating to MathML
On Tue, Oct 19, 2010 at 11:29 AM, David Hyatt hy...@apple.com wrote: (1) Make sure any layout methods you call do setNeedsLayout(false) at the end of them. (2) Look for any early returns in any of your layout methods, since maybe you did an early return causing the setNeedsLayout(false) to be missed. (3) Make sure you aren't dirtying a child for a re-layout without immediately doing that re-layout, e.g., don't call setChildNeedsLayout(true, false) on some child and then bail without doing a layout. While this is helpful, the current code (in the patch) follows these principles (except when RenderBlock::layout() is called last and so setNeedsLayout(false) is already done). The problem I have is an *ancestor* is marked as having a child needing layout during the layout process. When then MathML layout finishes, the MathML rendering objects do not need layout but the parent is marked with m_normalChildNeedsLayout set to true. This only becomes a problem when the parent of the RenderMathMLMath rendering object is a RenderInline instance as the a RenderBlock will call setNeedsLayout(false) on itself at the very end of layout. To me, although I have yet to confirm this, it seems like setNeedsLayout(false) is called during the layout of the inline flow from RenderBlock::layoutInlineChildren() on the RenderInline instance and then the RenderInline is marked with a child needing layout. Unfortunately, none of the above suggestions are going to fix that. I think the call to destroyLeftoverChildren() is also something we should reconsider. In my very simple example, this is what is causing the RenderInline instance to be marked with a child needing layout as it causes a traversal through the ancestors. I know why it is there but it doesn't necessarily seem like the right way (or place) to reorganize the operator stacking. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Focus Crash Relating to MathML
On Tue, Oct 19, 2010 at 1:44 PM, David Hyatt hy...@apple.com wrote: Also, if your pattern of code in a layout method is (1) Call base class RenderBlock::layout (2) Do other stuff that might cause dirtying Then you should really bulletproof that code by adding (1) Call base class RenderBlock::layout (2) Do a setChildNeedsLayout(true, false) on yourself just to make yourself already dirty. (3) Do other stuff that might cause dirtying (4) Do a setNeedsLayout(false) We don't really have a good setup for calling base class layout methods... technically you should stay dirty throughout the lifetime of your own layout method, but the base class method will mark you as clean. We should come up with something better at some point, but for now I think if you just dirty for the rest of the code you want to run and then mark yourself clean at the end, you'd stop the problem as well. This all sounds good. I'm going to experiment a bit and see if there is a better solution than using destroyLeftoverChildren() in RenderMathMLOperator. That will probably solve my immediate problem. I'll also look into changing when setNeedsLayout(false) is called as you have described. I think that change would be good to make sure that inline contents can't leave the tree in a strange state as it is quite easy to cause ancestors to get marked with descendants needing layout when, at the end of the layout for the subtree, that is no longer true. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Focus Crash Relating to MathML
On Sat, Oct 16, 2010 at 3:38 PM, Alex Milowski a...@milowski.org wrote: If anyone has any ideas of this bug: https://bugs.webkit.org/show_bug.cgi?id=47745 Even more curious is that I just noticed the crash only happens with a debug build. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Focus Crash Relating to MathML
On Mon, Oct 18, 2010 at 12:48 PM, Alexey Proskuryakov a...@webkit.org wrote: 18.10.2010, в 12:33, Alex Milowski написал(а): https://bugs.webkit.org/show_bug.cgi?id=47745 Even more curious is that I just noticed the crash only happens with a debug build. The crash is an assertion failure, so it's not surprising that it only occurs in debug builds. Assertions aren't compiled into release builds. OK. Less curious now! :) Sometimes, looking at svn blame to see when the assertion was added help one figure out what it is about. In general, asking a renderer-related question like isFocusable() needs finished layout indeed - e.g. display:none makes a node unfocusable, but before layout (recalcStyle?), the renderer doesn't know that. Yes, that makes sense. This has something to do with the inline flow. The whole problem goes away if you change the display property of the anchor to block. All the children are marked as not needing layout but the parent (the anchor) has m_normalChildNeedsLayout set to true. If you remove the MathML math element, everything works as expected. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Focus Crash Relating to MathML
Most of the MathML rendering objects have a display style property value of inline-block. Whenever these rendering objects are used, somehow the parent container gets marked as having children in need of layout. The MathML math rendering object completes its layout and marks itself as not needing layout. In the end, the container (e.g. the anchor element) render object has itself in a state where m_normalChildNeedsLayout is true but no child is marked as needing layout. I've gone through the MathML rendering objects and remove all uses of markContaingBlocksForLayout() and setNeedsLayoutPrefWidthsRecalc() which generally cause the container to be marked with a child needing layout. These calls were unnecessary and the resulting code should be more efficient. In situations where the MathML does not contain a rendering object that is an inline-block, everything works fine. For example: a href='#' math xmlns='http://www.w3.org/1998/Math/MathML'mix/mi/math /a Keep in mind, in the above, the 'mi' element just uses RenderInline as it has no special semantics as of yet. In cases where specialized render objects (typically with display inline-block) are used (e.g. an operator), the assert fires: a href='#' math xmlns='http://www.w3.org/1998/Math/MathML'mox/mo/math /a At this point, I don't think my code is directly causing the anchor to get marked with a child needing layout. I do rely on RenderBlock::layout() within most of the rendering objects to handle the actual layout after adjustments. I've tried making sure that the parent or container schedule a re-layout but that hasn't really helped. You can see all these adjustments and optimizations in the patch for: https://bugs.webkit.org/show_bug.cgi?id=43462 Any ideas of what to look at next would be appreciated. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Odd Build Issue on Gtk Port
On Sat, Oct 16, 2010 at 12:35 AM, Holger Freyther ze...@selfish.org wrote: On 10/16/2010 12:13 AM, Alex Milowski wrote: I kept getting GDK_DISPLAY related errors on my Ubuntu-based development machine. It turns on in Gtk 2.22.0 that GDK_DISPLAY just isn't defined (at least via Ubuntu 10.10). In debug build we build with the various *_DISABLE_DEPRECATED flags. Due the GNOME 3.0/GTK 3.0 thing, there is a lot more deprecation going on. Ah. I was building the debug build. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection Highlight and MathML
On Fri, Oct 15, 2010 at 11:43 AM, David Hyatt hy...@apple.com wrote: Do the objects actually overlap each other? Yes. Most of the overlap comes from containment (e.g. inline blocks containing other constructs. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Odd Build Issue on Gtk Port
On Fri, Oct 15, 2010 at 3:34 PM, Martin Robinson martin.james.robin...@gmail.com wrote: On Fri, Oct 15, 2010 at 3:32 PM, Evan Martin e...@chromium.org wrote: gdk_display_get_default() has been available since 2.2, which is older than anything still around. You should probably fix the call site rather than doing this header tweak. I concur. Ideally GtkVersioning.h should be used for API that exists in newer versions of GTK and not older ones. OK. This is not my area of expertise. I just hacked my way through it to get a working version. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Selection Highlight and MathML
I've taken an initial look at this bug: https://bugs.webkit.org/show_bug.cgi?id=43818 and I'm curious as to why MathML seems to be treated differently for selection highlights. Is there something a rendering object should do to define the selection highlight? Ideally, we'd just have one highlight for the root MathML element's rendering object (typically, 'math'). -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Selection Highlight and MathML
On Thu, Oct 14, 2010 at 5:19 PM, Darin Adler da...@apple.com wrote: On Oct 14, 2010, at 2:12 PM, Alex Milowski wrote: I'm curious as to why MathML seems to be treated differently for selection highlights. Differently from what? I’m not sure what your question is. If you try out the attachment from the bug you'll see what I mean. Essentially, MathML seems to get several overlapping highlights that get darker and darker the more that they overlap via several layers. As such, the content eventually gets washed out by the highlight color. I do not see this behavior for non-MathML content and that leads me to believe we need to something in the rendering objects for MathML. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing amp; MathML
On Sat, Oct 2, 2010 at 3:48 PM, David Carlisle d.p.carli...@gmail.com wrote: Alex Milowski alex at milowski.org writes: From reading the section on in foreign content' [1], it would seem that it should assign the 'svg' elements to the MathML namespace when they are embedded as above. That means cutting and pasting the same content fragment gives two very different interpretations--which is more of a problem for the HTML5 spec than webkit. As (since?) confirmed elsewhere on another list, but mentioned here for the record, the example becomes valid (and parse-able by html5 parser) if you wrap the svg in mi elements. the presentation mathml token elements, mi, mtext, etc are specified as being the extension points where you can embed html (and thus svg). That presents a challenge to the way the MathML implementation is current organized. In the current implementation, token elements are not suppose to contain element content. We'll need to completely re-architect the token elements to handle this in all situations as we won't get it by default in several cases. For example, if the SVG is embedded in an 'mo' element, the SVG will be ignored. That also questions what should be done in cases like: mo random text svg ... /svg /mo I still stand by my position that wrapping foreign elements in token elements in MathML is completely unnecessary for SVG, HTML, or other vocabularies that have rendering semantics that translate into some sequence of inline or block boxes. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] HTML5 Parsing MathML
On Fri, Oct 1, 2010 at 12:52 PM, Adam Barth aba...@webkit.org wrote: Our parser follows the spec (modulo late-breaking spec changes that we haven't picked up yet). The different namespaces can only be nested in certain ways, unlike in XML where arbitrary nesting is possible. Actually, I don't think a MathML annotation-xml with an SVG child element is going to work properly in WebKit the way the current code is setup. I'll test that. This is place where I think the parsing rules for HTML5 need to be adjusted so we get the same results for HTML or SVG embedded in MathML regardless of HTML or XHTML syntax. Digging deeper into what the HTML5 specification says for foreign content, the HTML div element would generate a parse error: p ... math mfenced open='[ close=] div ... random stuff /div /mfenced /math /p It would then pop the open stack back to the parent p element and the div element would be a child of the paragraph and not of the fencing. In XHTML, assuming there are appropriate uses of namespaces, everything would work fine and you'd get a div element fenced with stretching square brackets. So, if you cut-n-pasted the same content with the 'xmlns' attributes, you'd get two very different results. That really feels fixable but I'm going to need to think a bit more about what adjustments there would need to be to the rules. I wonder what the intersection of local names is between MathML and HTML ... This is, of course, an HTML5 issue and not really an WebKit issue except for the question of difficulty of implementation. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] HTML5 Parsing MathML
I'm curious as to what the current HTML5 parser does when MathML and SVG are mixed. In a recent review of MathML 3 I made the comment that this kind of markup, in XHTML, works just fine: math xmlns=ttp://www.w3.org/1998/Math/MathML mfrac svg .. happy smilely../svg mrow svg .. happy smilely../svg mo+/mo svg .. unhappy smilely../svg /mrow /mfrac /math Yet, it does not seem to be blessed by MathML3 as valid or allowed. I'm still debating that restriction with others. Note that the svg elements would need to have the SVG namespace declared and used somehow. In HTML5, the namespace declarations and use for MathML or SVG wouldn't be required (or really allowed). div math mfrac svg .. happy smilely../svg mrow svg .. happy smilely../svg mo+/mo svg .. unhappy smilely../svg /mrow /mfrac /math /div So, my question is: What does webkit do? From reading the section on in foreign content' [1], it would seem that it should assign the 'svg' elements to the MathML namespace when they are embedded as above. That means cutting and pasting the same content fragment gives two very different interpretations--which is more of a problem for the HTML5 spec than webkit. I've looked at HTMLTreeBuilder.cpp and it looks like it will assign all child elements to the MathML namespace. That's not 100% correct as the 'annotation-xml' has a special case for SVG annotations. From a browser perspective, when you are using the XHTML syntax, you can compose elements from different namespaces--embedding them as above--and it does work. In fact, the above kind of embedding of SVG as direct actors in rendering a fraction works right now in WebKit. That is, of course, an unsanctioned behavior. [1] http://dev.w3.org/html5/spec/Overview.html#parsing-main-inforeign -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review queue crazy idea
On Fri, Jul 23, 2010 at 12:51 PM, Eric Seidel e...@webkit.org wrote: I've never really liked trac.webkit.org/wiki/WebKit%20Team. Its always seemed more of place to brag about webkit involvement, than a useful reference. I think we could build a much better who should I ask to review this tool based on SVN information. Were you thinking of some kind of automated harvesting of this information? I seems like a simple data file that can be processed by systems would be a good way to start. Then people can submit patches (or commit changes) to file changing the areas that they are willing to review and others can see/review that commitment. People who are looking for a reviewer can look through that file for individuals. If a review doesn't want to get reminder e-mails or requests from systems or individuals, they would then have to remove that review area for themselves from that data file. I would personally use an XML format ... but that's me. ;) -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review queue crazy idea
On Fri, Jul 23, 2010 at 1:11 PM, Eric Seidel e...@webkit.org wrote: Given a patch file, you have its line number ranges. Given a git checkout, you can very quickly find who has made changes to what lines in that file. You then can have a bot post to the bug, saying that 10 people have touched the lines you're touching in your patch. 3 of them are active reviewers, here are their names: That sounds like a heat map for code. I wonder if there are existing tools that do that? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review queue crazy idea
On Fri, Jul 23, 2010 at 1:15 PM, Alex Milowski a...@milowski.org wrote: On Fri, Jul 23, 2010 at 1:11 PM, Eric Seidel e...@webkit.org wrote: Given a patch file, you have its line number ranges. Given a git checkout, you can very quickly find who has made changes to what lines in that file. You then can have a bot post to the bug, saying that 10 people have touched the lines you're touching in your patch. 3 of them are active reviewers, here are their names: That sounds like a heat map for code. I wonder if there are existing tools that do that? This looks interesting: http://www.statsvn.org/ I'm not sure if it can answer this line of code has these reviewers but it is worth a look. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Crash in RenderLayer related to setStyle() - Questions
I've identified a crash with the MathML implementation related to use of
CSS style rules that cause a RenderLayer instance to be created. In the
MathML code's various createRenderer() methods, they always call
RenderObject::setStyle() on the object they've just created.
When the setStyle() method is called, a style difference is calculated
and propagated. If you call setStyle() inside your createRenderer()
method, you're calling it on an unattached RenderObject instance.
Further, if there happens to be a rule like:
math {
overflow: auto;
}
you'll get a layer created by RenderBoxModelObject. That layer
will get the style change.
Right now, as the code stands, you'll get an exception and crash
due to the fact that the RenderLayer code makes some assumptions
about the RenderObject instance being attached to the tree.
The fix is trivial but my question is basically: what's the right thing
to do here? Should the setStyle() be called in createRenderer() ? It
seems like the answer is no because the style gets associated
somewhere else. If I remove the call, the crash is also fixed (without
any change to RenderLayer) and the tests still all pass for MathML.
Further, should RenderLayer be made more safe? Should it check
for zero pointer values in a couple places and avoid this?
If we shouldn't be calling setStyle() in createRenderer(), then fixing
RenderLayer would just hide that fact. While an ASSERT wouldn't
hide things, it would still only arise when a layer is created.
I know how to fix the MathML code and I just want to make
sure I understand why calling setStyle() is bad.
I'm not sure what should be done about RenderLayer or otherwise.
Suggestions?
--
--Alex Milowski
The excellence of grammar as a guide is proportional to the paucity of the
inflexions, i.e. to the degree of analysis effected by the language
considered.
Bertrand Russell in a footnote of Principles of Mathematics
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] review queue crazy idea
On Thu, Jul 22, 2010 at 8:29 AM, Maciej Stachowiak m...@apple.com wrote: I think a better UI for reviews, plus some better attempts at active notification of potential reviewers, could go a long way. I'm a strong believer in trying nudges and positive incentives before implementing harsher policies. Maybe we could have the system try to contact reviewers who have expressed interest/ability in review patches for certain areas (or components)? For example, if someone registered as being a reviewer for MathML patches, the system could e-mail all the registered reviewers. If the set of reviewers is too large, the system could pick a random subset to e-mail. I have certainly had a consistent set of individuals who have been kind enough to review my patches. On occasion, I've contacted individuals to ask directly for a review when a patch has been there for awhile. I've gotten comfortable enough with the process to do this. Newer contributors or those contributing outside their normal areas might not feel so comfortable and so having the system do this would be very good for keeping things moving forward. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
If we want to put the STIX fonts up somewhere to be downloaded, where would that be if it can't be in subversion? I think we'd just have a couple of the font files up for download. We can't really download the from stixfonts.org. Of course, we'd have to include some program for download as well. :) -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
On Tue, Jul 20, 2010 at 4:11 PM, Darin Adler da...@apple.com wrote: On Jul 20, 2010, at 4:39 AM, Alex Milowski wrote: We can't really download them from stixfonts.org. Why? Well, because the zip file is behind a form that requires you to accept the license. It doesn't seem right to try to hack our way through that form to run tests. Besides, some organization should accept the terms of the license and the responsibility for distributing this font to test systems (or developers running tests). -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
On Tue, Jul 20, 2010 at 4:35 PM, Darin Adler da...@apple.com wrote: On Jul 20, 2010, at 8:24 AM, Alex Milowski wrote: some organization should accept the terms of the license and the responsibility for distributing this font to test systems (or developers running tests). Some organization? You lost me there. Isn’t the STI Pub Companies an organization? They're the licensor we're the user accepting the right to use the artifact. An automated program can't legally accept a license. An organization can ... All I'm saying is that I don't think the STIX folks would appreciate us hacking our way through their license acceptance form just to download the fonts. Someone should download them from stixfonts.org, accepting their license, and make them available for our purposes. My question is where do I put them if I can't check them into subversion? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
On Tue, Jul 20, 2010 at 4:30 PM, Antonio Gomes (:tonikitoo) toniki...@gmail.com wrote: Again, maybe something like http://gitorious.org/qtwebkit/testfonts as QtWebKit does for the exactly same propose? Maybe I missed this somewhere in the discussion. Sure. That looks like an option. Are there the same licensing snags with these fonts as we have with the STIX fonts? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
On Tue, Jul 20, 2010 at 5:39 PM, Darin Adler da...@apple.com wrote: In my opinion, we, the WebKit project as a whole, are not users. It’s the people who are making use of WebKit, building it or testing it or possibly incorporating it into a product, that are the users. I don’t think the WebKit project can accept the terms of the license. In that interpretation, we'd need to have anyone who runs the webkit tests for MathML install the STIX fonts ... somehow. They'd have to download and at least put them in a known location. I'm not sure if that is an acceptable solution for the whole WebKit project. Anyway, if the real question is finding a server to post the fonts on, then I think you just have to satisfy whoever runs the server that they have the right to post them. That's the way I was leaning. The only issue is who has the resources to provide a reliable server for the size of our development community? I don't personally have one that I can offer. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] SIL Open Font License and WebKit
On Tue, Jul 20, 2010 at 5:58 PM, Zoltan Herczeg zherc...@inf.u-szeged.hu wrote: We can't really download them from stixfonts.org. Alex, wouldn't be possible to contact them and ask some help? Maybe they could offer us an acceptable solution. I can try but as a consortium of mostly user organizations, I'm not certain who'd respond. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] SIL Open Font License and WebKit
We have a licensing issue we need to address for MathML. We need the STIX fonts as they will provide consistent rendering for Mathematics. I highly suspect these fonts will find themselves on our desktops somewhere down the road. Meanwhile, we need them for our testing infrastructure to actually work across all the platforms. The STIX Fonts are available under the SIL Open Font License: http://scripts.sil.org/cms/scripts/page.php?site_id=nrsiitem_id=OFL_web You can see the patch that adds these fonts here: https://bugs.webkit.org/show_bug.cgi?id=41961 I think we need to adjust our licensing policy to include font licenses like the above. It is unlikely that the STIX consortium will change their font licensing. In reality, they don't need to do so. The font license is intended to support open source fonts. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
On Mon, Jul 12, 2010 at 7:49 PM, Maciej Stachowiak m...@apple.com wrote: I think it's fine to enable MathML soon, as long as we make sure of the following: 1) Using a MathML-enabled build shouldn't cause stability problems or functional or performance regressions when browsing ordinary non-MathML content. Some of tis is testable by passing all our test cases, right? Or did you have something else in mind? Do we have anything that measures performance for regressions? I suspect that the performance on MathML with complicated row structures isn't going to be good at the moment. There are two many multiple rendering passes for operator and content stretching and that can probably be optimized. On the other hand, it seems to do quite well on reasonable MathML. 2) We should try to do some fuzz testing to verify that MathML doesn't create security risks. #2 can happen after we enable MathML, but should probably happen before anyone ships it. What is involved in (2) ? I'm happy to try to beat on the code to make sure it works well enough for people to feel comfortable turning it on. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
On Sat, Jul 10, 2010 at 2:19 AM, David Kilzer ddkil...@webkit.org wrote: IMO, it should be closed once MathML is enabled in the WebKit nightly builds and/or most ports. I would think we'd close it when we've actually completely implemented MathML. Just enabling it seems like something we could do now but our implementation is quite impoverished with respect to MathML 3.0. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Bugzilla Question - Master Bug vs Component?
On Sat, Jul 10, 2010 at 2:24 AM, Adam Barth aba...@webkit.org wrote: Out of curiosity, is there an estimate of when that might be? There's some interaction with the new HTML5 parser because it supports MathML-in-HTML. That's something we're trying to get a handle on right now. Sausset François is going through the W3C test suite. One idea that occurred to me was to file bugs for each feature that block the master bug 3251. When all of those are complete and we can pass the W3C test suite, we can close 3251. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Bugzilla Question - Master Bug vs Component?
For MathML we have a master bug 3251 that we've been making depend on every new patch for MathML. That is a very nice in that as new patches are added and committed, you can get notifications of the changes in status. We also have the MathML component that all bugs should be associated with. As time goes but, bugs should get filed against the MathML component but they won't be associated with the master bug for MathML. What is the preferred process here? Should we keep the master bug? Should we use it only for our implementation efforts and not make it depend on every random bug filed for the MathML component? I certainly have my opinion on this. I'd rather not associated everything that gets reported with the master bug. Instead, I'd rather we only associated our implementation efforts or issues describing sub-features related to implementation of certain features of MathML (e.g. glyph inspection to tighten under/over placement). We can then make the bugs filed by random users depend on such implementation efforts associated with the master bug. I expect to get a lot of bugs like my MathML is messed up, here's an example where the specifics of why will be associated with a number of different specific technical issues. Basically, my preference is: master bug - feature or technical issue - user bug -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Commit Queue Love
Independently of the other long thread, I'd like to express my love of the commit queue. It is actually quite a nice feature for someone like myself who is off in a corner. I don't want commit access. I'd rather my changes go through some process like the commit queue to ensure that it doesn't break other people's code or block forward development in some way. It is very frustrating sometimes when your patch is stuck in the commit queue for days. I don't necessarily see that as being caused by the commit queue. That is directly because it isn't getting the love it deserves! :) Being able to go around the commit queue means you can cheat. That seems like something that should be reserved for more severe problems where we know the process used by the commit queue will fail. If committers need some kind of specialized access, maybe they just need a fast track commit queue, a higher priority, or some additional options, so that the policies for building and testing can be uniformly applied while still meeting their needs. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Commit Queue Love
On Fri, Jul 9, 2010 at 3:39 PM, Timothy Hatcher timo...@apple.com wrote: On Jul 9, 2010, at 3:38 AM, Alex Milowski wrote: Being able to go around the commit queue means you can cheat. That seems like something that should be reserved for more severe problems where we know the process used by the commit queue will fail. That is not how I see it at all. And calling it cheating is quite offensive to me. Just because I want control over when and how my patch is committed is suddenly considered cheating? Sorry, that wasn't meant to be offensive. It is going around a process. That said, not everyone has committed to using that process. So, you're right. It isn't cheating. All I'm advocating is using the commit queue much more often. I don't have any control over when my code hits the trunk. Somehow, it all works out in the end. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] STIX Fonts and MathML Tests
Sausset François has been looking at using the newly released STIX fonts [1] for the MathML implementation. If we start requiring STIX font support for MathML, how do we guarantee: * these fonts exist in the build process so the tests will succeed, * these fonts exist on the target platform. Certainly, we can create a stylesheet that degrades when the fonts are missing. We could also do something with web fonts [2] but that seems like a bad idea for WebKit as a core platform for a variety of browsers. In general, we're working towards a point where we'd like to turn on MathML by default and, at that point, the tests must be run. For the tests to succeed, we'd need the STIX fonts available. Is there any precedence for this or default policy for tests requiring fonts? [1] http://www.stixfonts.org/ [2] http://hublog.hubmed.org/archives/001931.html -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] STIX Fonts and MathML Tests
On Wed, Jul 7, 2010 at 5:31 PM, Dan Bernstein m...@apple.com wrote: On Jul 7, 2010, at 3:48 AM, Alex Milowski wrote: Is there any precedence for this or default policy for tests requiring fonts? Yes. Some tests require the Ahem font, so the font is checked into the repository and—at least on Mac OS X and Windows—DumpRenderTree activates the font while running the tests. The STIX fonts are relatively small (2.6MB for the full download) and we probably don't need all of them. Would it be acceptable to check these in like the Ahem font? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Closing MathML Bugs?
What's the process for closing out a MathML related bug? I'm not the reporter, I'm not assigned, and these both look like they are now fixed: https://bugs.webkit.org/show_bug.cgi?id=36540 https://bugs.webkit.org/show_bug.cgi?id=36528 -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Interpreting LEAK: on Shutdown
I looked at this document on the wiki: http://trac.webkit.org/wiki/Memory%20Use and I'm curious about how to interpret the output on the console when running via Safari. For example, here's one output when I just quit with windows open: LEAK: 2 WebCoreNode LEAK: 29 CachedResource Here's another when all the windows were closed: No leak checking done: At least one WebView is still open. I'm particularly interested in whether the MathML code is leaking. I don't have any direct concerns but I want to understand how to check my rendering object implementations. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MathML Component in Bugzilla?
Could someone create a MathML component for bug reports in Bugzilla? Please? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Interpreting LEAK: on Shutdown
On Tue, Jun 22, 2010 at 6:06 PM, Geoffrey Garen gga...@apple.com wrote: Those messages indicate that some objects were not deleted before shutdown. Ensuring that all known references are released before shutdown, and then verifying that all objects are deleted, is an aid to debugging memory leaks. But the mechanism to ensure that all known references are released before shutdown seems to have bit-rotted a bit. Maybe you can fix it. OK. But how do you avoid this: No leak checking done: At least one WebView is still open. If you quit all the windows you still get it. In general, the documentation on all this is a little sparse. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XML Processor Profiles WebKit
The XML Processing Model Working Group at the W3C has been recently working on XML processor profiles as part of our subsequent work after the XProc recommendation. There is currently a draft at: http://www.w3.org/TR/xml-proc-profiles/ I distinctly want one of the XML processor profiles to be that which a web browser does when processing XML content. I've been doing some research as to how WebKit uses libXML to process XML and here's what I've reported back to the XProc working group so far: * does not read the external subset. * does read the internal subset and provide any attribute normalization as specified per the XML recommendation for non-validating parsers. * does default attributes read in the internal subset. * does process and xml:base attributes properly * does not process ID/IDREF to allow DOM's getElementById() to work. * does not process xml:id attributes to allow DOM's getElementById() to work. * reports all whitespace as text nodes in the DOM regardless of what is in the internal subset. While I'd like xml:id and/or ID/IDREF to work along with the DOM's getElementById(), I'm not sure about the historical or technical contexts as to why they currently do not. Basically, the profile would be much like what is described as the minimum XML processor profile except that reading the external subset would not be required. Thoughts? We could certain ask for more. I'm curious about xml:id handling. I know there is also a bit of XLink supported for SVG use but it is also incomplete. If you all had to define an XML Processor Profile for WebKit, what would you want it to do? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MathML in Qt
My patch for MathML support in the Qt port build has just been committed. So far it looks good. There are some issues with the over all MathML rendering code on Linux that I'm looking into (e.g. stack operators have some font issues). These aren't specific to the Qt port. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Turning on MathML by Default?
With the latest patch (37044) having been committed, I feel like we're at a point where I'd like the MathML implementation to be available in the nightly builds. The code has been built and tested successfully on the Mac and Gtk builds. I intend to look at the windows build next. We have a growing community of developers and interested users and having a nightly build with MathML would allow testing, submission of issues, and receipt of fixes. What do others think? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Turning on MathML by Default?
On Wed, Apr 28, 2010 at 1:14 PM, İsmail Dönmez ism...@namtrac.org wrote: Did anyone tested it on Qt port? Just curious... No, not yet. I haven't setup a Qt build for myself quite yet (just Mac Gtk). That actually might be easier to do than Windows. :) I'll look into that today or tomorrow. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Turning on MathML by Default?
On Wed, Apr 28, 2010 at 3:11 PM, İsmail Dönmez ism...@namtrac.org wrote: I wonder if it'll work fine since MathML also needs strong font support. Font support is still an issue on all platforms. The STIX fonts that I've gotten ahold of are terrible. Maybe when they ship they'll be better. It is likely that the CSS will have to be customized on each platform to pick the correct expected font from the system. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Turning on MathML by Default?
On Wed, Apr 28, 2010 at 3:53 PM, İsmail Dönmez ism...@namtrac.org wrote: On Wed, Apr 28, 2010 at 5:52 PM, Alex Milowski a...@milowski.org wrote: On Wed, Apr 28, 2010 at 3:11 PM, İsmail Dönmez ism...@namtrac.org wrote: I wonder if it'll work fine since MathML also needs strong font support. Font support is still an issue on all platforms. The STIX fonts that I've gotten ahold of are terrible. Maybe when they ship they'll be better. Uh, they are supposed to be the best math fonts available :-) That's the rumor. I'll wait and see what they look like when they are officially released. So far, the fonts I've been playing with (beta versions) have some obvious errors for operators. It is unclear when they will be officially released. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Why I'm reviewing patches outside my area (and why you should too)
On Tue, Mar 9, 2010 at 1:17 PM, David Hyatt hy...@apple.com wrote: On Mar 9, 2010, at 1:45 PM, Adam Barth wrote: (1) The patch needs to be reviewed by David Hyatt. David Hyatt appears to be a bottleneck in the project because he's an expert on a number of components that no one else understands as well but he doesn't spend as much time reviewing patches as Maciej or Darin. I think the best solution here is to have more folks gain expertise in these areas. Dave needs to review this is used as an excuse by others to get out of doing reviews in my opinion. :) MathML is a great example of this. I don't need to be the sole person reviewing MathML patches that don't affect core code. If the MathML rendering code lands in the tree with some mistakes or issues that can be fixed later, it's really not a big deal. Maybe I would have noticed something that another reviewer wouldn't have, but the mistakes will get caught eventually. It is a great example of this. While I've been very appreciative of Dave Hyatt's review and help, it has really been great to have others jump in a review my code. At this point, I've had more iterations of reviews and patches and the code (and my understanding of WebKit) has gotten quite a bit better just because people decided to review the MathML code rather than wait for it to get to the top of Dave's stack! -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire: a tragedy of the commons
On Fri, Feb 26, 2010 at 7:09 AM, Eric Seidel e...@webkit.org wrote: On Fri, Feb 26, 2010 at 4:14 AM, Kenneth Christiansen kenneth.christian...@openbossa.org wrote: 1) Contributor uploads patch and nominates it for review. 2) Patch vetted by the EWS on numerous platforms. When a non-committer uploads a patch, it is not being vet by EWS. I know that is due to security issues. It would be really nice with an option for a reviewer to accept it to run on the EWS. The only EWS which requires committer access is Mac-EWS. All other EWS bots will run any patch. Why is that? That's the platform I'm most interested in see run. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire: a tragedy of the commons
On Fri, Feb 26, 2010 at 7:17 AM, Eric Seidel e...@webkit.org wrote: On Fri, Feb 26, 2010 at 7:12 AM, Alex Milowski a...@milowski.com wrote: The only EWS which requires committer access is Mac-EWS. All other EWS bots will run any patch. Why is that? That's the platform I'm most interested in see run. Various reasons. Mostly due to our current hardware setup. If someone has some mac hardware they'd like to donate to the cause it would be most welcome. That seems really, really solvable. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] The tree is on fire: a tragedy of the commons
On Fri, Feb 26, 2010 at 8:55 AM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 26, 2010 at 8:47 AM, Alex Milowski a...@milowski.com wrote: On Fri, Feb 26, 2010 at 8:19 AM, Adam Barth aba...@webkit.org wrote: On Fri, Feb 26, 2010 at 7:24 AM, Alex Milowski a...@milowski.com wrote: On Fri, Feb 26, 2010 at 7:17 AM, Eric Seidel e...@webkit.org wrote: On Fri, Feb 26, 2010 at 7:12 AM, Alex Milowski a...@milowski.com wrote: The only EWS which requires committer access is Mac-EWS. All other EWS bots will run any patch. Why is that? That's the platform I'm most interested in see run. Various reasons. Mostly due to our current hardware setup. If someone has some mac hardware they'd like to donate to the cause it would be most welcome. That seems really, really solvable. The core issue here is that the license for Mac OS X prevents us from running the OS in a virtual machine. The way we protect ourselves from random folks haxoring the EWS on Linux is by running them on EC2 and re-imagining the machines periodically. So, it is possible to run Mac OS X on a virtual machine: Oh, awesome! The real issue is you can't run this in the cloud like on an EC2 server because of the hardware restriction in Apple's license, right? EC2 has support for Linux and Windows, but not Mac. I have been meaning to set up a Windows box, but I haven't gotten around to it yet. If you know of a cloud provider that has Mac, we can set up the mac-ews there. The only non-dedicated server hosting provider I've found is GoDaddy: http://www.godaddy.com/hosting/mac-hosting.aspx I don't know if starting/stopping instances is as easy as Amazon's EC2 service (which I use). I've never used their virtual hosting service. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Google Summer Of Code 2010
I'd love to see something related to MathML on this list but I'm not a committer. I'd need a committer volunteer but I'd be happy to be directly involved. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Troubles with Anonymous Blocks
On Mon, Feb 8, 2010 at 9:42 PM, Roland Steiner rolandstei...@google.com wrote: Just a stab in the dark here, and without knowledge about recent changes that could have caused your code to break (so this could be wildly off). The difference between the 2 versions AFAICT is whether m_isAnonymous is set or not, which leads me to the question: have you properly overridden createsAnonymousWrapper() in the parent? I haven't overridden that method. What does it do? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Troubles with Anonymous Blocks
I've been struggling with odd issues with anonymous blocks that I don't quite understand. For example, to build a fraction in MathML I wrap the numerator and denominator in an anonymous block: RenderBlock* row = new (renderArena()) RenderBlock(document()); I then set border, padding, and text-align style properties on the style for that anonymous block. These settings seem to have stopped working in the latest round of work. If I change the construction of the row wrapper to: RenderBlock* row = new (renderArena()) RenderBlock(node()); which is backed by the 'mfrac' element, all the border/etc. style properties work. When I trace through with the debugger, the border properties seem to disappear from the style object when the node is the document node and the block is anonymous. Any ideas on what is happening? I see that there is little code that uses an anonymous blocks directly as I do. Is there are a preferred way to do this? My intended design for fractions was: 1. The mfrac is a inline-block with block flows for its children 2. The numerator and denominator are blocks that stack vertically. 3. The denominator has a border property for the fraction line separator. 4. These wrapper blocks for the numerator and denominator can have arbitrarily complicated flows of their own. Currently, if I use the second construct above and use node() as the backing node for the block wrappers for the numerator and denominator, it almost works. There seem to be situations where the border is drawn short of the overall width--which is a another problem I'm struggling with but may be unrelated to this issue. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MathML Update: Recent Progress
I've just added support for mfrac (fractions) as a separate patch. I've also updated the monster patch with all the latest code against the trunk. You can get this from: https://bugs.webkit.org/show_bug.cgi?id=33703 There are a number of individual patches that need review: https://bugs.webkit.org/show_bug.cgi?id=34277 - munder, mover, and munderover support https://bugs.webkit.org/show_bug.cgi?id=34278 - msubsup, msub, and msup support https://bugs.webkit.org/show_bug.cgi?id=34347 - mrow and stretchy operator support https://bugs.webkit.org/show_bug.cgi?id=34741 - mfrac support All of these patch involve one or two new render objects. The most complex is probably the row/operator support (34347). The others should be straight forward. If these patches can make some progress getting into the trunk, WebKit will be able to do a reasonable job of rendering mathematics for a limited but useable subset of MathML. My next task is to get some kind of root/square root implementation that works reasonably well. I have something now in the monster patch but it has lots of issues. There are plenty of MathML features that do not work as of yet but with the above core those features should be smaller changes based on these pieces as starting points. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MathML Component in Bugzilla?
For those in control of Bugzilla, I think it would be a good idea to have a MathML component in Bugzilla just like there is a SVG component. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] MathML Patch Review Request
There are a number of relatively new MathML related patches waiting to be reviewed: * https://bugs.webkit.org/show_bug.cgi?id=34228 - compile-time layout debugging support * https://bugs.webkit.org/show_bug.cgi?id=34275 - CSS update * https://bugs.webkit.org/show_bug.cgi?id=34277 - mover, munder, and munderover support * https://bugs.webkit.org/show_bug.cgi?id=34278 - msubsup (super subscripts) support The first two are quite simple. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Showing Baseline and Container Box
For all of my MathML rendering objects I've optionally compiled in a simple override to the paint() method to provide a visual representation of the containing box's boundary and the baseline position. I've been using this to debug the layout of the Mathematics. What is the proper way to wrap this kind of code when I go to create a patch? Right now it is a compile time feature that I turn on with a define. Also, what I'd really like is the ability to inspect the full rendering tree associated with the MathML and turn on this outlining of the box and baseline for every rendering object in that subtree that reduces to a RenderBoxModelObject instance. Is there some tool that could do this already or via some modification? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Showing Baseline and Container Box
On Mon, Jan 25, 2010 at 10:31 AM, Maciej Stachowiak m...@apple.com wrote: It's reasonable to use an ENABLE() flag for debugging features like this, in my opinion. I don't know if we have any direct precedent. Doesn't ENABLE() require a feature define? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] baselinePosition() and zoom factor
Does the return value of the baselinePosition() scale with the zoom factor? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] Transforming Content MathML?
One of the things I need to research is how I'm going to handle content MathML. Typically, content MathML is transformed into presentation MathML for display and this is often done with an XSLT transformation. When WebKit encounters some MathML, I'd like to follow this process: * the content MathML is transformed into a chunk of presentation MathML. * the presentation MathML's rendering object tree is constructed * that rendering tree is used in place of the content MathML. Have a complete severed subtree of content MathML seems like the wrong way to go about this. What options do I have for dealing with this multiple layers of transformation (e.g. content MathML - presentation MathML - render tree)? -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] XSLT serialize/parse
I'm surprised to see that documents have to be serialized and parsed whenever XSLT is used. Looking at the way libxslt works, I don't see any way for this to change. Has anyone considered using the C++ version of Xalan? This would allow direct interoperability between the DOM and XSLT as well as the possibility for incrementally rendering the result. The performance should be better just by removing serialize and parse steps. -- --Alex Milowski The excellence of grammar as a guide is proportional to the paucity of the inflexions, i.e. to the degree of analysis effected by the language considered. Bertrand Russell in a footnote of Principles of Mathematics ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
