Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. window.WebKitShadowTreeConstructor // all trees begin at a root, right? window.WebKitShadowTreeScopeConstructor // assuming this can only be used inside the shadow tree For uniformity we were going to also make documents tree scopes. This makes things simpler for script because every element, text node, etc. will be in a tree scope (a document or a shadow root.) Dominic Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
I had the same idea a year ago, and got only negative feedback. My main intention was/is the performance of the parser (see [1]). I improved the performance of it a lot in the meantime (see dependencies of [2]) [2] tries to remove this UTF-8 - UTF-16 - UTF-8 overhead. The patch isn't perfect at the moment (some LayoutTest don't work, and it bypasses the whole DocumentWriter stuff). So if someone really want to replace it, it would be great to check the performance against libxml2 with applied [2]. Comment #1 at [2] shows that the current libxml2 implementation is about 6% faster than the HTML parser (same data, only different mime types). So if we really want to add a new XML parser, someone should convert the HTML parser to work with the encoding of the document (or at least UTF-8) to add the required common code first, before adding a second parser with the same performace problem (sorry for that, i don't want to say that out parser is bad, i only see room for improvement). libxml2 has security bugs reasonably often, and creates the need for an extra upstream update to pull those fixes. Isn't libxml2 a system library and _the system_ responsible for security issues in it? [1] https://bugs.webkit.org/show_bug.cgi?id=43085 [2] https://bugs.webkit.org/show_bug.cgi?id=52036 - Patrick Am 29.06.2011 um 07:10 schrieb Dirk Schulze: 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? Dirk ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
29.06.2011, 07:42, TAMURA, Kent tk...@chromium.org: 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. How about importing Expat parser to WebKit repository and maintain it by ourselves? What about RapidXml? http://rapidxml.sourceforge.net/ -- Regards, Konstantin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding CSS3 font feature propreties
Do you have a master bug for them? On Fri, Jun 24, 2011 at 12:16, Kenichi Ishibashi ba...@chromium.org wrote: Hi webkit-dev, I'm thinking about adding CSS3 font feature properties[1] support to WebKit. It allows page authors to control over advanced typographic features. Firefox has an experimental implementation and an article[2] shows how these properties work. I really would like to add this feature so I'd like to ask comments and suggestions in advance. My current plan is starting with adding the font-feature-settings property (6.12 Low-level font setting control) as -webkit-font-feature-settings, following a similar approach that Firefox did. For OpenType fonts, other properties can be treated as specific cases of the font-feature-settings property and I think adding this property is good starting point. One shortcomings of this approach is that it requires OpenType support for each port. A port which uses AAT might not be able to support this property, or we need to add an extra text rendering subsystem which can handle OpenType features to the port. If I get started with this plan, I will start implementing css parsing part, then implement font rendering part on a specific port (Chromium Linux port is in mind for now) on trial. I'd also like to put some notes of supporting CSS3 font feature properties with AAT and CoreText here: - AAT features are listed at [3]. - While the spec lists the equivalent OpenType feature tag for each property, it is unclear that what AAT feature setting corresponds with each property. An email written by the spec editor[4] lists them partially but not complehensive. - [5] describes OpenType support of CoreText (I'm not sure this is correct, though). Comments and suggestions are highly appreciated. [1] http://dev.w3.org/csswg/css3-fonts/#font-rend-props [2] http://hacks.mozilla.org/2010/11/firefox-4-font-feature-support/ [3] http://developer.apple.com/fonts/registry/ [4] http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html [5] http://en.wikipedia.org/wiki/OpenType_feature_tag_list Regards, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- TAMURA Kent Software Engineer, Google ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Adding CSS3 font feature propreties
Hi, On Wed, Jun 29, 2011 at 7:18 PM, TAMURA, Kent tk...@chromium.org wrote: Do you have a master bug for them? Not yet, but I'll make a master bug for them when I don't see a strong objection. On Fri, Jun 24, 2011 at 12:16, Kenichi Ishibashi ba...@chromium.orgwrote: Hi webkit-dev, I'm thinking about adding CSS3 font feature properties[1] support to WebKit. It allows page authors to control over advanced typographic features. Firefox has an experimental implementation and an article[2] shows how these properties work. I really would like to add this feature so I'd like to ask comments and suggestions in advance. My current plan is starting with adding the font-feature-settings property (6.12 Low-level font setting control) as -webkit-font-feature-settings, following a similar approach that Firefox did. For OpenType fonts, other properties can be treated as specific cases of the font-feature-settings property and I think adding this property is good starting point. One shortcomings of this approach is that it requires OpenType support for each port. A port which uses AAT might not be able to support this property, or we need to add an extra text rendering subsystem which can handle OpenType features to the port. If I get started with this plan, I will start implementing css parsing part, then implement font rendering part on a specific port (Chromium Linux port is in mind for now) on trial. I'd also like to put some notes of supporting CSS3 font feature properties with AAT and CoreText here: - AAT features are listed at [3]. - While the spec lists the equivalent OpenType feature tag for each property, it is unclear that what AAT feature setting corresponds with each property. An email written by the spec editor[4] lists them partially but not complehensive. - [5] describes OpenType support of CoreText (I'm not sure this is correct, though). Comments and suggestions are highly appreciated. [1] http://dev.w3.org/csswg/css3-fonts/#font-rend-props [2] http://hacks.mozilla.org/2010/11/firefox-4-font-feature-support/ [3] http://developer.apple.com/fonts/registry/ [4] http://lists.w3.org/Archives/Public/www-style/2009Jun/0506.html [5] http://en.wikipedia.org/wiki/OpenType_feature_tag_list Regards, ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev -- TAMURA Kent Software Engineer, Google -- Kenichi Ishibashi ba...@google.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote: On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. Calling it shadow tree or shadow content may be imprecise, but surely calling it shadow is outright inaccurate. Consider how you'd complete this sentence: I'd use the Element.webkitShadow API to get the __ for that element. I think I'd fill in that blank with shadow tree or shadow DOM. I certainly wouldn't fill it in with shadow. It sounds like your discussion leans in the direction of shadow container or maybe shadow root. In fact the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes sense. Further question: are these APIs going to be part of whatever the XBL2 spec turns into? I can't find them in the latest Editor's draft: http://dev.w3.org/2006/xbl2/Overview.html In fact, XBL2 itself maintains the invariant that the shadow dom cannot be directly observed from the outside at all. Is there a record of the rationale for this rather different direction? Are Mozilla and other likely future implementors (Opera, Microsoft) on board with this change of direction? The aforelinked document (http://dglazkov.github.com/component-model/dom.html) doesn't really explain the reasons . I also found a list of use cases: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases. But there's not really an explanation of how this proposal meets the use cases, and from cursory examination it seems to blatantly violate one of them in a way that XBL2 did not: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Using_Shadow_DOM_Boundary_for_Isolation I'd like to see all of this explained better before putting this experimental API in the tree. If we are going to invent a new thing instead of implementing XBL2 or working with the relevant standards groups to improve XBL2, I think everyone should understand the reasoning for doing so. Regards, Maciej ___ 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 Jun 29, 2011, at 2:13 AM, Konstantin Tokarev wrote: 29.06.2011, 07:42, TAMURA, Kent tk...@chromium.org: 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. How about importing Expat parser to WebKit repository and maintain it by ourselves? What about RapidXml? http://rapidxml.sourceforge.net/ 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. Regards, Maciej ___ 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: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] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 7:35 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote: On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. Calling it shadow tree or shadow content may be imprecise, but surely calling it shadow is outright inaccurate. Consider how you'd complete this sentence: I'd use the Element.webkitShadow API to get the __ for that element. I think I'd fill in that blank with shadow tree or shadow DOM. I certainly wouldn't fill it in with shadow. It sounds like your discussion leans in the direction of shadow container or maybe shadow root. In fact the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes sense. I think webkitShadowRoot makes sense—it is precise, the parallelism with the constructor name makes sense, and the reflexive shadowHost/shadowRoot is nice. Further question: are these APIs going to be part of whatever the XBL2 spec turns into? I can't find them in the latest Editor's draft: http://dev.w3.org/2006/xbl2/Overview.html In fact, XBL2 itself maintains the invariant that the shadow dom cannot be directly observed from the outside at all. Is there a record of the rationale for this rather different direction? Are Mozilla and other likely future implementors (Opera, Microsoft) on board with this change of direction? The aforelinked document ( http://dglazkov.github.com/component-model/dom.html) doesn't really explain the reasons . I also found a list of use cases: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases. But there's not really an explanation of how this proposal meets the use cases, and from cursory examination it seems to blatantly violate one of them in a way that XBL2 did not: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Using_Shadow_DOM_Boundary_for_Isolation These are good questions; Dimitri is a better person to answer them than me. On the security and isolation use case: I take the point about exposing shadowRoot running counter to using shadow DOM as a security boundary. I’m skeptical about that particular use case. I think isolation should be supported by something that puts less emphasis on presentation and is more closely related to the isolation boundary web pages have today (ie iframes.) Easier isolation is appealing, but feels like a pork-barrel amendment to XBL use cases. I have been and am going to keep arguing against it in other venues. I'd like to see all of this explained better before putting this experimental API in the tree. If we are going to invent a new thing instead of implementing XBL2 or working with the relevant standards groups to improve XBL2, I think everyone should understand the reasoning for doing so. Dominic Regards, Maciej ___ 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] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 6:49 AM, Dominic Cooney domin...@chromium.org wrote: On Wed, Jun 29, 2011 at 7:35 PM, Maciej Stachowiak m...@apple.com wrote: On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote: On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. Calling it shadow tree or shadow content may be imprecise, but surely calling it shadow is outright inaccurate. Consider how you'd complete this sentence: I'd use the Element.webkitShadow API to get the __ for that element. I think I'd fill in that blank with shadow tree or shadow DOM. I certainly wouldn't fill it in with shadow. It sounds like your discussion leans in the direction of shadow container or maybe shadow root. In fact the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes sense. I think webkitShadowRoot makes sense—it is precise, the parallelism with the constructor name makes sense, and the reflexive shadowHost/shadowRoot is nice. Further question: are these APIs going to be part of whatever the XBL2 spec turns into? I can't find them in the latest Editor's draft: http://dev.w3.org/2006/xbl2/Overview.html In fact, XBL2 itself maintains the invariant that the shadow dom cannot be directly observed from the outside at all. Is there a record of the rationale for this rather different direction? Are Mozilla and other likely future implementors (Opera, Microsoft) on board with this change of direction? The aforelinked document (http://dglazkov.github.com/component-model/dom.html) doesn't really explain the reasons . I also found a list of use cases: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases. But there's not really an explanation of how this proposal meets the use cases, and from cursory examination it seems to blatantly violate one of them in a way that XBL2 did not: http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Using_Shadow_DOM_Boundary_for_Isolation These are good questions; Dimitri is a better person to answer them than me. On the security and isolation use case: I take the point about exposing shadowRoot running counter to using shadow DOM as a security boundary. I’m skeptical about that particular use case. I think isolation should be supported by something that puts less emphasis on presentation and is more closely related to the isolation boundary web pages have today (ie iframes.) Easier isolation is appealing, but feels like a pork-barrel amendment to XBL use cases. I have been and am going to keep arguing against it in other venues. Right -- we discussed this on public-webapps a while back: http://lists.w3.org/Archives/Public/public-webapps/2011JanMar/0900.html. I'd like to see all of this explained better before putting this experimental API in the tree. If we are going to invent a new thing instead of implementing XBL2 or working with the relevant standards groups to improve XBL2, I think everyone should understand the reasoning for doing so. XBL2 is an awesome spec, and we borrow from it as much as can (in fact, most of style/event plumbing follows the spec pretty precisely), but in trying to tackle an immense
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 5:01 AM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. This falls into the broad bucket of things that webdevs are exposed to that tend to be unnecessarily long (querySelectorAll vs. query) for no good reason. Meaning comes with use. My bias as a webdev is to want the shortest thing that means something close. In particular, since you'll be scripting through this property a LOT, having it be short is a serious win. With those preferences, is there something we can do that's better *and* shorter than shadow? Element.webkitShadowTree Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() window.WebKitShadowTreeConstructor // all trees begin at a root, right? window.WebKitShadowTreeScopeConstructor // assuming this can only be used inside the shadow tree Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
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, 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. - Patrick ___ 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] Shadow DOM API (first iteration) ready for landing
On Wed, Jun 29, 2011 at 3:35 AM, Maciej Stachowiak m...@apple.com wrote: On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote: On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen gga...@apple.com wrote: On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote: On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen gga...@apple.com wrote: Hi Dmitri. Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor Even though we've been using shadow as a term in our internal development, I think it makes a bad API name, since it's vague to its purpose, and it conflicts with the existing meaning of shadow on the web, which is a color radiating around a visual element. I sympathize and agree that there's a naming collision, but I think the train has left the station on this one. Shadow tree and shadow content are terms that have been used pretty much universally to describe this construct, from XBL/XUL and XBL2 to SVG. I don't think we need to invent a new name for it. Fair enough. How about using shadow tree or shadow content consistently instead of just shadow? I can imagine webkitShadow meaning a lot of different things. webkitShadowTree or webkitShadowContent seems clearer. Element.webkitShadowTree I agree that just shadow could be confused with CSS shadows, although those are boxShadow and textShadow, so maybe just shadow is OK from a grepping point of view. shadow*Tree* doesn’t feel quite right to me; consider shadowTree.firstChild? An element has a firstChild; a tree has lots of nodes. Element.webkitPseudo // not sure what this is -- showing my ignorance document.webkitCreateShadowTree() …Tree could be confusing because the object being created is just the container; it starts out empty. To me, tree and content refer to the whole shadow subtree, and the thing being created here is more specific. Calling it shadow tree or shadow content may be imprecise, but surely calling it shadow is outright inaccurate. Consider how you'd complete this sentence: I'd use the Element.webkitShadow API to get the __ for that element. I think I'd fill in that blank with shadow tree or shadow DOM. I certainly wouldn't fill it in with shadow. It sounds like your discussion leans in the direction of shadow container or maybe shadow root. In fact the interface is called ShadowRoot so perhaps Element.webkitShadowRoot makes sense. Further question: are these APIs going to be part of whatever the XBL2 spec turns into? I can't find them in the latest Editor's draft: http://dev.w3.org/2006/xbl2/Overview.html In fact, XBL2 itself maintains the invariant that the shadow dom cannot be directly observed from the outside at all. Is there a record of the rationale for this rather different direction? Are Mozilla and other likely future implementors (Opera, Microsoft) on board with this change of direction? Also, I'll post on public-webapps as a follow-up to our earlier discussions and present this API-let as the first step forward. :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] [Webkit GTK][Windows] Plug-ins fails to load
Dear Martin, Thanks a lot for your prompt response. Now I am trying to build WebKit-GTK port on X11 using CygWin on Windows. I will try to load my plug-ins with the help of new set-up. Is this the right approach? Or is it possible that just for plugin I will open XP_UNIX flag, compile it and resolve all the compilation error. With this approach, plugin should use loading mechanism as of X11. Please suggest if I am missing some thing. Many Thanks, Dipak Kumar On Tue, Jun 28, 2011 at 9:20 PM, Martin Robinson martin.james.robin...@gmail.com wrote: On Mon, Jun 27, 2011 at 9:42 PM, dipak kumar mail.di...@gmail.com wrote: I have configured Webkit GTK port on Win32. Apart from that I have created some NPAPI architecture based plug-in to implement my own functionality. I have created DLL's and keeping them on the standard MOZ_PLUGIN_PATH path. But my GTKLauncher application is unable to load these plug-ins. What I am doing wrong? I couldn't find anything on net apart from a bug ( https://bugs.webkit.org/show_bug.cgi?id=54531 ). Could anybody please confirm whether it is possible to load plug-in on windows or not. As the bug says, I don't think it works at the moment. We'd appreciate someone with a stake in plugins working on Windows to fix this. I believe it should not be *too* difficult, but right now people using WebKitGTK+ on Windows are very few. --Martin ___ 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 6:55 AM, Alex Milowski a...@milowski.org wrote: 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). +1. Also, a lot of .asp, .php, etc... files serve XHTML contents. - Ryosuke ___ 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:12 PM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). I have also daydreamed about undertaking such a project, as libxml is generally kind of terrifying to me. (At one point I found we had somehow compiled its table of HTML tags from its half-hearted HTML processor inside a Chrome binary, sigh.) Aside from XSLT (which others have already mentioned), the other problem that kept me from this is that any reasonably large project that sits atop WebCore likely already needs to parse XML already, which means that a library like libxml is already a dependency for other reasons. For example, I am pretty sure in Chrome's case using your new XML library would only serve to double our XML parser code weight. Here are some places where Chrome uses XML outside of processing web pages: http://codesearch.google.com/codesearch#search/exact_package=chromiumq=libxml%20-file:third_party%20file:cctype=cs It would be nice if you could construct your library such that it either wasn't buried within the guts of WebCore or such that it could be used independently of WebCore. But I wouldn't be surprised if either of those aren't really important goals for you; I'm also not sure there's much public demand for a UTF-16-only xml parser outside of WebKit internals. PS: I wrote a much simpler and setjmp-free PNG decoder library with the intent of integrating it into Chrome, then went through more or less the same thought process as above and shelved it. ___ 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
Hi; On Wed, Jun 29, 2011 at 3:12 AM, Jeffrey Pfau jp...@apple.com wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. Did you have a look at iksemel [0] ? Its a self contained C library for parsing XML. [0] http://code.google.com/p/iksemel/ Regards. ___ 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
I think considerable effort should be put into building up a suite of performance tests in advance of the new parser (probably culled from xml encountered in the wild, but also a number of extreme edge cases wouldn't go a miss either). We should also put effort into reducing any/all recursion in the parser as stack depth guards are not the most efficient mechanism to prevent stack overflows. --Oliver On Jun 28, 2011, at 6:12 PM, Jeffrey Pfau wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Writing a new XML parser with no external libraries
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 Adam On Wed, Jun 29, 2011 at 9:22 AM, Oliver Hunt oli...@apple.com wrote: I think considerable effort should be put into building up a suite of performance tests in advance of the new parser (probably culled from xml encountered in the wild, but also a number of extreme edge cases wouldn't go a miss either). We should also put effort into reducing any/all recursion in the parser as stack depth guards are not the most efficient mechanism to prevent stack overflows. --Oliver On Jun 28, 2011, at 6:12 PM, Jeffrey Pfau wrote: Currently, WebCore uses libxml2, or, if available, QtXml to parse incoming XML. However, QtXml isn't always available, and using libxml2 exposes its own share of problems. As such, I'm undertaking writing an XML parser that uses no external libraries. The first step to doing this is to add a new flag that switches off the other two parsers. As the parsers are already independent and can be switched between by checking USE(QXMLSTREAM), I am adding USE(LIBXML2) checks, replacing the #else conditionals, and also a new ENABLE check, tentatively called NEW_XML (although names such as NATIVE_XML or XML_NATIVE, etc, may be more appropriate). As there will probably be a new slew of files pertaining to XML parsing, I will put these files in WebCore/xml/parser, and move the existing XMLDocumentParser* file into this new directory. As far as I know, the placement of these files in WebCore/dom/ is legacy, and, assuming the build on each platform is changed, it makes sense to move them. Once all the files are in a logical place, I plan to make a new file for a skeleton of the new XMLDocumentParser, at least to get it to link until a real one is in place, even if the XML parser at that point is just a data sink. From there, I plan to copy and modify a good chunk of the lower level HTML tokenization and parsing code, and make changes as necessary to make it work on generalized XML, at least until I can generalize the common code in such a way that the HTML and XML tokenizers can be subclasses and use common code. I'd probably do the refactoring at the end. I'm still exploring the existing parsing code, but I'd probably work my way up from there. I've read a lot of the XML 1.0 spec in preparation, as well, but it doesn't have much on implementation itself. If QtWebKit or parsing people have any comments, concerns, or help, I'd be more than willing to listen--I'm just starting here, and I'm not completely familiar with the codebase. Although no code is checked in so far, I've started on this list already and have gotten as far as the new flags, a skeleton XMLDocumentParserNew.cpp, and making a tokenizer that compiles and links, but is completely untested. Jeffrey Pfau ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
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
Re: [webkit-dev] Writing a new XML parser with no external libraries
On 29 June 2011 01:10, 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. Specifically these test failures are due to a bug with internal entities in libxml2 which was first seen with OS X 10.5.8, so before that it worked. Maybe a new libxml2 version is used in Lion and will fix it, but should a new XML parser come about entities are an area that should work even though little SVG files out there actually seem to use it in practice. Cheers, Rob. ___ 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 Jun 29, 2011, at 7:14 AM, Alex Milowski wrote: 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. We could also write a new native XSLT engine down the line, since we have our own XPath code already. This would let us fix a lot of oddities and hacks with the way our libxslt-based XSLT support works. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)
Thanks Adam! I've filed an Enhancement with Apple: Bug ID# 9697244. -Paul -Original Message- From: aba...@gmail.com [mailto:aba...@gmail.com] On Behalf Of Adam Barth Sent: June 28, 2011 1:28 PM To: Mossman, Paul (Paul) Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419) This isn't a WebKit issue. It's an issue for the embedding application. You'll need to file a bug with the relevant browser vendor. For Apple, you can use https://bugreport.apple.com/ or Chromium, you can use http://new.crbug.com/ Good luck! Adam On Tue, Jun 28, 2011 at 8:39 AM, Mossman, Paul (Paul) paulmoss...@avaya.com wrote: Hi all, I originally sent this to webkit-help, but I probably should have posted it here instead. I'd like to request an alternate resolution to the following issue: https://bugs.webkit.org/show_bug.cgi?id=41419 We should log the reason when a secure wss WebSocket connection could not be established (was: Secure wss WebSocket connections cannot be established) Consider an example https://appliance.example.com, which uses a self-signed SSL certificate. iOS Safari will warn the user: Cannot Verify Server Identify Safari can't verify the identity of appliance.example.com. Would you like to continue anyway? Cancel / Details / Continue The user chooses to Continue. Safari then trusts the identity of appliance.example.com, and proceeds. The resulting HTML may spawn additional https:// requests, which will also proceed. Suppose though that a wss:// connection to appliance.example.com is initiated. As issue 41419 states, this will fail in Safari and WebKit (r87480.) Chrome on the other hand, consider the user's acceptance of the server's identity as valid for both wss:// and https:// connection. This seems reasonable. The user accepted the server's identity, with no caveat on the protocol. Can this behaviour be implemented in WebKit as the resolution to issue 41419? -Paul paulmoss...@avaya.com ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)
28.06.2011, в 8:39, Mossman, Paul (Paul) написал(а): Can this behaviour be implemented in WebKit as the resolution to issue 41419? Which of the below most accurately describes what you would like implemented? Some of these would actually be WebKit issues. 1. If the user has already accepted an invalid certificate for an https document, the same certificate should be silently accepted when talking to a WebSocket server on the same domain and port. 2. If the user has already accepted an invalid certificate for an https document, any invalid certificate should be silently accepted when talking to a WebSocket server on the same domain and port. 3. If the user has already accepted an invalid certificate for an https document, any invalid certificate should be silently accepted when talking to any WebSocket server. 4. If an invalid certificate is presented for a WebSocket connection, the browser should display a confirmation dialog akin to the one for https. 5. As the only good use for invalid certificates is development, there should be an option in browser's Development menu to disable certificate checks, perhaps until browser restart or just in current window. We don't want users to make the decision whether an invalid certificate means that they are unsafe. 6. Something different. There is a large movement in the opposite direction - browsers are going to completely block any content that is even remotely suspicious from security point of view. I am surprised that Chromium is so forgiving in this case. - WBR, Alexey Proskuryakov___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)
Hi Alexey, Definitely #1 - same certificate, same domain, and same port. -Paul From: Alexey Proskuryakov [mailto:a...@webkit.org] Sent: June 29, 2011 2:03 PM To: Mossman, Paul (Paul) Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419) 28.06.2011, в 8:39, Mossman, Paul (Paul) написал(а): Can this behaviour be implemented in WebKit as the resolution to issue 41419? Which of the below most accurately describes what you would like implemented? Some of these would actually be WebKit issues. 1. If the user has already accepted an invalid certificate for an https document, the same certificate should be silently accepted when talking to a WebSocket server on the same domain and port. 2. If the user has already accepted an invalid certificate for an https document, any invalid certificate should be silently accepted when talking to a WebSocket server on the same domain and port. 3. If the user has already accepted an invalid certificate for an https document, any invalid certificate should be silently accepted when talking to any WebSocket server. 4. If an invalid certificate is presented for a WebSocket connection, the browser should display a confirmation dialog akin to the one for https. 5. As the only good use for invalid certificates is development, there should be an option in browser's Development menu to disable certificate checks, perhaps until browser restart or just in current window. We don't want users to make the decision whether an invalid certificate means that they are unsafe. 6. Something different. There is a large movement in the opposite direction - browsers are going to completely block any content that is even remotely suspicious from security point of view. I am surprised that Chromium is so forgiving in this case. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unverified cert
From: webkit-dev-boun...@lists.webkit.org [mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Alexey Proskuryakov Sent: Wednesday, June 29, 2011 2:03 PM To: Mossman, Paul (Paul) Cc: webkit-dev@lists.webkit.org Subject: Re: [webkit-dev] Unverified cert: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419) 5. As the only good use for invalid certificates is development, there should be an option in browser's Development menu to disable certificate checks, perhaps until browser restart or just in current window. We don't want users to make the decision whether an invalid certificate means that they are unsafe. By invalid you mean unverified right? Yesterday I self-signed a certificate and installed it on a new jabber server, and then got it talking to gmail. Isn't that a good use for invalid certificates? I can see that the front of the web might be pickier, but don't shut out us indie operators! -Nick Guenther ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Unverified cert
29.06.2011, в 11:30, Nick Guenther написал(а): 5. As the only good use for invalid certificates is development, there should be an option in browser's Development menu to disable certificate checks, perhaps until browser restart or just in current window. We don't want users to make the decision whether an invalid certificate means that they are unsafe. By invalid you mean unverified right? Yesterday I self-signed a certificate and installed it on a new jabber server, and then got it talking to gmail. Isn't that a good use for invalid certificates? I can see that the front of the web might be pickier, but don't shut out us indie operators! It appears that expired certificates should get the same treatment - if the user has already bypassed a confirmation dialog for https, there is no need to block wss. And yes, I was talking about it in the context of web browsing. In fact, a better solution for development could be adding your local signing authority key to Keychain, but I wasn't sure if the request was about development or deployment. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing
Hi Dimitri, First of all, nice work on getting to this point! It is not clear to me why we wouldn't stick with XBL2 for now, at least until there is more community consensus on going another way, and a spec and editor are available to take the API forward. I think it would help if you could explain what considerations you took into account when making this decision, and further, why this subset is a good starting place. What are the use cases of this subset? - Sam On Jun 28, 2011, at 7:42 PM, Dimitri Glazkov wrote: Dear WebKit, After nearly a year of building up the shadow DOM plumbing and converting WebKit to use it, we are finally at the point where we can expose this plumbing as public-facing API. The approach we take here is a very cautious one: we want to expose the minimum subset of the larger Web Component Model (some of you might remember is it as XBL2). The goal is to minimize the impact, but have something useful enough for Web developers to help us gather feedback. After careful consideration, we've come up with this subset for our first iteration: http://dglazkov.github.com/component-model/dom.html Since this is an experimental API, here are the actual API names we want to use: Element.webkitShadow Element.webkitPseudo document.webkitCreateShadow() window.WebKitShadowRootConstructor window.WebKitTreeScopeConstructor We will also provide the ENABLE(COMPONENT_MODEL) flag to control availability of this API and its iterations, even though all of the C++ code will always compile, since it's used throughout WebKit. NOTE: This iteration of the API is not intended to ship in a release version of a browser (think nightlies and dev channel only). Be sure to disable it on your respective release branches. Please chime in if you have concerns. Wish us luck! :DG ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
