Re: [webkit-dev] Shadow DOM API (first iteration) ready for landing

[Sam Weinig]

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

Re: [webkit-dev] Unverified cert

[Alexey Proskuryakov]

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] Unverified cert

[Nick Guenther]

>> 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: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)

[Mossman, Paul (Paul)]

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: Allow wss:// if user has accepted https:// warning? (WebKit Bug 41419)

[Alexey Proskuryakov]

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)

[Mossman, Paul (Paul)]

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) 
>  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] Writing a new XML parser with no external libraries

[Brent Fulgham]

Hi,

On Tue, Jun 28, 2011 at 10:10 PM, Dirk Schulze  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. [...] Updating libxml2 more often on MacOS would help a lot.

While I would welcome the reduction in build dependencies, I really
wonder if time wouldn't be better spent making libxml2 better so that
all projects that use it could benefit.

Does libxml2 suffer from architectural/design issues that mean that
throwing it out would be a better option than just fixing the problems
with it?

-Brent
___
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

[Maciej Stachowiak]

On Jun 29, 2011, at 7:14 AM, Alex Milowski wrote:

> On Tue, Jun 28, 2011 at 10:10 PM, Dirk Schulze  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] Writing a new XML parser with no external libraries

[Rob Buis]

On 29 June 2011 01:10, Dirk Schulze  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

[Alex Milowski]

On Wed, Jun 29, 2011 at 10:01 AM, Adam Barth  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

[Adam Barth]

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  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

[Oliver Hunt]

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

[İsmail Dönmez]

Hi;

On Wed, Jun 29, 2011 at 3:12 AM, 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.
>
>
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

[Evan Martin]

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 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=chromium&q=libxml%20-file:third_party%20file:cc&type=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

[Ryosuke Niwa]

On Wed, Jun 29, 2011 at 6:55 AM, Alex Milowski  wrote:

> On Tue, Jun 28, 2011 at 6:50 PM, Eric Seidel  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] [Webkit GTK][Windows] Plug-ins fails to load

[dipak kumar]

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  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] Shadow DOM API (first iteration) ready for landing

[Dimitri Glazkov]

On Wed, Jun 29, 2011 at 3:35 AM, Maciej Stachowiak  wrote:
>
> On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote:
>
> 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:
>
> 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] Writing a new XML parser with no external libraries

[Alex Milowski]

On Wed, Jun 29, 2011 at 7:18 AM,   wrote:
> On Wed, 29 Jun 2011 06:55:57 -0700, Alex Milowski 
> 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

[paroga]

On Wed, 29 Jun 2011 06:55:57 -0700, Alex Milowski 
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

[Alex Milowski]

On Tue, Jun 28, 2011 at 10:10 PM, Dirk Schulze  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] Shadow DOM API (first iteration) ready for landing

[Alex Russell]

On Wed, Jun 29, 2011 at 5:01 AM, 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:
> >>>
> >>> 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] Shadow DOM API (first iteration) ready for landing

[Dimitri Glazkov]

On Wed, Jun 29, 2011 at 6:49 AM, Dominic Cooney  wrote:
>
>
> On Wed, Jun 29, 2011 at 7:35 PM, Maciej Stachowiak  wrote:
>>
>> On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote:
>>
>> 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:
>>
>> 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
>> () doesn't really
>> explain the reasons . I also found a list of 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: 
>
> 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 fo

Re: [webkit-dev] Writing a new XML parser with no external libraries

[Alex Milowski]

On Wed, Jun 29, 2011 at 3:39 AM, Maciej Stachowiak  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

[Alex Milowski]

On Tue, Jun 28, 2011 at 6:50 PM, Eric Seidel  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=en&answer=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] Shadow DOM API (first iteration) ready for landing

[Dominic Cooney]

On Wed, Jun 29, 2011 at 7:35 PM, Maciej Stachowiak  wrote:

>
> On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote:
>
> 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:
>
>
> 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

[Alex Milowski]

On Tue, Jun 28, 2011 at 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:
>>
>> 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

[Maciej Stachowiak]

On Jun 29, 2011, at 2:13 AM, Konstantin Tokarev wrote:

> 
> 
> 29.06.2011, 07:42, "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.
>> 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] Shadow DOM API (first iteration) ready for landing

[Maciej Stachowiak]

On Jun 28, 2011, at 11:33 PM, Dominic Cooney wrote:

> 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:
> 
> 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 
() doesn't really explain 
the reasons . I also found a list of 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: 


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] Adding CSS3 font feature propreties

[石橋 賢一]

Hi,

On Wed, Jun 29, 2011 at 7:18 PM, TAMURA, Kent  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 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
>
>
>
>


-- 
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] Adding CSS3 font feature propreties

[TAMURA, Kent]

Do you have a master bug for them?


On Fri, Jun 24, 2011 at 12:16, Kenichi Ishibashi  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] Writing a new XML parser with no external libraries

[Konstantin Tokarev]

29.06.2011, 07:42, "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.
> 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] Writing a new XML parser with no external libraries

[Patrick Gansterer]

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