On Wed, Jun 29, 2011 at 1:01 PM, Geoffrey Garen wrote:
>
> On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote:
>
>> On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen wrote:
>>> Hi Dmitri.
>>>
Since this is an experimental API, here are the actual API names we want
to use:
Eleme
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
On Jun 28, 2011, at 5:15 PM, Dimitri Glazkov wrote:
> On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen wrote:
>> Hi Dmitri.
>>
>>> Since this is an experimental API, here are the actual API names we want to
>>> use:
>>>
>>> Element.webkitShadow
>>> Element.webkitPseudo
>>> document.webkitCreat
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?
On Wed, Jun 29, 2011 at 10:12, Jeffre
Consolidating replies to avoid spamming the thread:
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.
If the new parser
In case you're not aware, I believe you can access the XML parser via
JavaScript at window.DOMParser, which might be helpful for testing.
Adam
On Jun 28, 2011 6:41 PM, "Jeffrey Pfau" wrote:
> See responses inline:
>
> On Jun 28, 2011, at 6:26 PM, Adam Barth wrote:
>
>> A question and a comment:
That was done, long ago. You can find the old patches in our svn history. :)
On Tue, Jun 28, 2011 at 6:44 PM, Wyatt Carss wrote:
> If that were all, would it be possible to patch libxml2 to use UTF-16? That
> might be less of an undertaking than writing a new xml library, but that
> could just b
Correct. We convert from UTF16 to UTF8 (for libxml2) and then back to UTF16.
There has been at least one libxml-related security fix to WebCore in
recent memory.
We have various hacks in the libxml2 parser due to libxml2 being
designed to be a library used by applications, and not used by a
libr
If that were all, would it be possible to patch libxml2 to use UTF-16? That
might be less of an undertaking than writing a new xml library, but that
could just be my youthful naivety..
On Tue, Jun 28, 2011 at 6:36 PM, Jeffrey Pfau wrote:
> I don't know all of the problems libxml2 has, but one of
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
I don't know all of the problems libxml2 has, but one of the ones I've heard is
that WebCore uses UTF-16 internally, and libxml2 uses UTF-8, so the data is
perpetually converted between the two formats--and this is slow. If there are
any other big ones, I haven't been told them, only that it wou
Can you expand a bit more on "using libxml2 exposes its own share of problems"?
-- Dirk
On Tue, 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 o
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.
2) One thing we found very helpful in working on the HTML parser was a
good test suite. Presumably there are existing XML parsin
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 ne
On Fri, Jun 24, 2011 at 7:11 AM, Levi Weintraub wrote:
> Emil and I looked into what Firefox did. They did go with a
> fixed-point-esque approach where one of their units represents 1/96th of a
> pixel. That number should tell you something about when this work was done,
> and they were mostly co
On Tue, Jun 28, 2011 at 4:49 PM, Geoffrey Garen 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.WebKitTr
On Jun 28, 2011, at 12:22 PM, Ojan Vafai wrote:
> On Tue, Jun 28, 2011 at 10:10 AM, Maciej Stachowiak wrote:
> On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote:
>> Can you give an example of a smooth UI that you'd need the more complex API
>> for? When I think of the existing mail and chat apps in
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 ter
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 Comp
On Tue, Jun 28, 2011 at 10:10 AM, Maciej Stachowiak wrote:
> On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote:
>
> Can you give an example of a smooth UI that you'd need the more complex API
> for? When I think of the existing mail and chat apps in iOS/Android that
> I've use, could give just as sm
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
On Jun 27, 2011, at 9:49 AM, Ojan Vafai wrote:
> Can you give an example of a smooth UI that you'd need the more complex API
> for? When I think of the existing mail and chat apps in iOS/Android that I've
> use, could give just as smooth a UI as the existing
> apps, it's just on the browser s
On Mon, Jun 27, 2011 at 9:42 PM, dipak kumar 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 GTKLaun
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 es
On Mon, Jun 27, 2011 at 15:36, Ojan Vafai wrote:
> On Mon, Jun 27, 2011 at 3:17 PM, Alexey Proskuryakov wrote:
>>
>> 27.06.2011, в 14:03, Darin Fisher написал(а):
>> > I think we can make this behavior a Setting, and then certainly each
>> > embedder of WebKit
>> > can decide how prominently to s
On Mon, Jun 27, 2011 at 5:49 PM, Ojan Vafai wrote:
> Can you give an example of a smooth UI that you'd need the more complex API
> for? When I think of the existing mail and chat apps in iOS/Android that
> I've use, could give just as smooth a UI as the
> existing apps, it's just on the browser
26 matches
Mail list logo
