[webkit-dev] Can't build Chromium Linux
Both my Chromium Linux boxes are getting this compile error, which doesn't seem to be showing up on the bots: WebKit/chromium/third_party/ffmpeg/patched-ffmpeg-mt/libavcodec/libvpxdec.c:27: fatal error: vpx/vpx_decoder.h: No such file or directory This is preventing the chromium-ews from running. Anyone know what's going on? Adam ___ 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] HTML5 Web Links (RFC 5988)
Alex, I'm hacking at this right now, and hope to have a CL uploaded soon. - Gavin On 9 November 2010 06:51, Alex Milowski a...@milowski.org wrote: 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 ___ 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)
Are there any specific link types we should support in the Link: header besides stylesheets? I know other browsers support Link to reference a stylesheet, so it's probably good for interop if we do it too. Regards, Maciej On Nov 9, 2010, at 3:51 AM, Alex Milowski wrote: 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 ___ 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)
09.11.2010, в 03:51, Alex Milowski написал(а): Now that RFC 5988 is a proposed standard [1] and HTML5 references the Link: header [2] Note the way in which HTML5 references it: Some versions of HTTP defined a Link: header. That's about HTTP 1.0 only. Specifying stylesheets in HTTP headers seems like a most obvious misfeature to me, and other potential uses of the Link header field are so unimportant that RFC 5988 doesn't even bother to mention them in its introduction. - WBR, Alexey Proskuryakov ___ 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)
09.11.2010, в 9:20, Maciej Stachowiak написал(а): It might be worth testing which other browsers support it. I know at least Firefox supports associating a stylesheet with Link. It does seem like a fairly ill-conceived feature, but not so much that it is worth being the sole holdout, if other browser engines all do it. Agreed. I don't know whether IE supports it, but given that this hasn't been a source of compatibility bugs, I suspect that it doesn't. And there are some plausible use cases - same document served with multiple stylesheets, without having to modify the document on the fly, just the headers. Yes, and that seems to be a (potential?) source of trouble for everyone, not just browser vendors. Surely one doesn't want to fight with a misconfigured hosting that forces a CSS stylesheet on their pages, or to discover that their own server was doing that, after spending an eternity analyzing their HTML source for mistakes. 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. - WBR, Alexey Proskuryakov ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] XPath Issues?
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.) Please excuse me if I mis-understood your suggestions of integrating these Qt features with WebKit. -eric On Tue, Nov 9, 2010 at 1:46 AM, Alex Milowski a...@milowski.org wrote: On Mon, Nov 8, 2010 at 7:09 PM, Frans Englich fengl...@fastmail.fm wrote: As far as I know, no, but I'm busy with studies these days. I guess one of the first questions is rather how the two stacks, Qt and Webkit, should relate to each other on this particular field, what the aim of the integration is and the nature of the integration, as well as dependencies. But it seems interesting to have these technologies in Webkit. What's your thoughts on how it would be carried be done? I think the simplest answer is for one to be able to turn on Qt XML support without having to use the whole Qt port. In my research into how all this is put together, the XPath and XSLT support within the browser is separable. Any library could be integrated by simply adding a build option to do so. I've been looking at XQuilla in this same way. They have an XPath 2.0, XQuery, and XSLT 2.0 implementation that looks to be very easy to integrate. The only is that they rely on some internals from Xerces-C that seem rather superfluous. That is, you don't have to use the Xerces-C parser to use their system. Any implementation of XSLT or XPath needs to be able to use the XML DOM directly in some way. This would avoid any kind of strange serialization (which is what happens when XSLT is called from Javascript with libxslt) that currently causes bugs. In addition, the XPath implementation can't really serialize and expect to get the context node correct. (I wrote the XPath, XQuery and XSL-T code and mentored the Schema code. However, I'm no longer employed by Nokia.) That's good to know! Have the compliance tests for XSLT 2.0 and XQuery been 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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
