<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2900.6058" name=GENERATOR>
<STYLE>@font-face {
        font-family: 宋体;
}
@font-face {
        font-family: Verdana;
}
@font-face {
        font-family: @宋体;
}
@page Section1 {size: 595.3pt 841.9pt; margin: 72.0pt 90.0pt 72.0pt 90.0pt; layout-grid: 15.6pt; }
P.MsoNormal {
        TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
LI.MsoNormal {
        TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
DIV.MsoNormal {
        TEXT-JUSTIFY: inter-ideograph; FONT-SIZE: 10.5pt; MARGIN: 0cm 0cm 0pt; FONT-FAMILY: "Times New Roman"; TEXT-ALIGN: justify
}
A:link {
        COLOR: blue; TEXT-DECORATION: underline
}
SPAN.MsoHyperlink {
        COLOR: blue; TEXT-DECORATION: underline
}
A:visited {
        COLOR: purple; TEXT-DECORATION: underline
}
SPAN.MsoHyperlinkFollowed {
        COLOR: purple; TEXT-DECORATION: underline
}
SPAN.EmailStyle17 {
        FONT-WEIGHT: normal; COLOR: windowtext; FONT-STYLE: normal; FONT-FAMILY: Verdana; TEXT-DECORATION: none; mso-style-type: personal-compose
}
DIV.Section1 {
        page: Section1
}
UNKNOWN {
        FONT-SIZE: 10pt
}
BLOCKQUOTE {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px; MARGIN-LEFT: 2em
}
OL {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
UL {
        MARGIN-TOP: 0px; MARGIN-BOTTOM: 0px
}
</STYLE>
</HEAD>
<BODY style="FONT-SIZE: 10pt; MARGIN: 10px; FONT-FAMILY: verdana">
<DIV><FONT face=Verdana color=#000080 size=2>thank you!</FONT></DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Verdana color=#000080 size=2></FONT> </DIV>
<DIV><FONT face=Verdana color=#c0c0c0 size=2>2011-06-22 </FONT></DIV><FONT 
face=Verdana color=#000080 size=2>
<HR style="WIDTH: 100px" align=left color=#b5c4df SIZE=1>
</FONT>
<DIV><FONT face=Verdana color=#c0c0c0 size=2><SPAN>523060808</SPAN> 
</FONT></DIV>
<HR color=#b5c4df SIZE=1>

<DIV><FONT face=Verdana size=2><STRONG>发件人:</STRONG> webkit-dev-request 
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>发送时间:</STRONG> 2011-06-22  22:00:33 
</FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>收件人:</STRONG> webkit-dev </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>抄送:</STRONG> </FONT></DIV>
<DIV><FONT face=Verdana size=2><STRONG>主题:</STRONG> webkit-dev Digest, Vol 73, 
Issue 28 </FONT></DIV>
<DIV><FONT face=Verdana size=2></FONT> </DIV>
<DIV><FONT face=Verdana size=2>
<DIV>Send webkit-dev mailing list submissions to</DIV>
<DIV>webkit-dev@lists.webkit.org</DIV>
<DIV></DIV>
<DIV>To subscribe or unsubscribe via the World Wide Web, visit</DIV>
<DIV>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</DIV>
<DIV>or, via email, send a message with subject or body 'help' to</DIV>
<DIV>webkit-dev-request@lists.webkit.org</DIV>
<DIV></DIV>
<DIV>You can reach the person managing the list at</DIV>
<DIV>webkit-dev-owner@lists.webkit.org</DIV>
<DIV></DIV>
<DIV>When replying, please edit your Subject line so it is more specific</DIV>
<DIV>than "Re: Contents of webkit-dev digest..."</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>Today's Topics:</DIV>
<DIV></DIV>
<DIV>   1. MathML Anonymous Block Conundrum (Alex Milowski)</DIV>
<DIV>   2. Making Webkit - PluginViewGtk.cpp error (Tom Smith)</DIV>
<DIV>   3. Re: Making Webkit - PluginViewGtk.cpp error (Ariya Hidayat)</DIV>
<DIV>   4. Re: Making Webkit - PluginViewGtk.cpp error (Tom Smith)</DIV>
<DIV>   5. Re: DumpRenderTree for the EFL port :) (Raphael Kubo da Costa)</DIV>
<DIV>   6. Accessibility Object Searching (Samuel White)</DIV>
<DIV>   7. Re: Accessibility Object Searching (Charles Pritchard)</DIV>
<DIV>   8. Re: Accessibility Object Searching (Chris Fleizach)</DIV>
<DIV>   9. Re: Accessibility Object Searching (Chris Fleizach)</DIV>
<DIV>  10. Re: Spellcheck API for WebKit (Simon Fraser)</DIV>
<DIV>  11. Re: Spellcheck API for WebKit (Hironori Bono (?? ??))</DIV>
<DIV>  12. Re: Spellcheck API for WebKit (Ryosuke Niwa)</DIV>
<DIV>  13. Setting up Eclipse IDE for Webkit.. (Tom Smith)</DIV>
<DIV>  14. Re: Setting up Eclipse IDE for Webkit.. (Alexis Menard)</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>----------------------------------------------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 1</DIV>
<DIV>Date: Tue, 21 Jun 2011 15:39:12 +0100</DIV>
<DIV>From: Alex Milowski <alex@milowski.org></DIV>
<DIV>To: webkit-dev Development <webkit-dev@lists.webkit.org></DIV>
<DIV>Subject: [webkit-dev] MathML Anonymous Block Conundrum</DIV>
<DIV>Message-ID: <BANLkTimJhZQBYdNsaMMt+L6ZTKMh2gfibA@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset=ISO-8859-1</DIV>
<DIV></DIV>
<DIV>I've run into a conundrum with "anonymous blocks" yet again.  I was</DIV>
<DIV>helping track down a crash relating to DOM manipulation.  While I</DIV>
<DIV>fixed that particular case by just marking all the instances as</DIV>
<DIV>anonymous blocks, this solution doesn't work in general.</DIV>
<DIV></DIV>
<DIV>In many places in the MathML rendering code we create</DIV>
<DIV>RenderMathMLBlock instances that are used to layout different</DIV>
<DIV>constructs.  For example, for fractions we stack two RenderMathMLBlock</DIV>
<DIV>instances as wrappers for the numerator and denominator.  In many</DIV>
<DIV>instances, that is all we need to do.  In other instances, such as</DIV>
<DIV>fractions, we set style properties on each created instance.</DIV>
<DIV></DIV>
<DIV>Here's the problem:</DIV>
<DIV></DIV>
<DIV>If the created wrappers are marked as anonymous, the style created for</DIV>
<DIV>the wrapper is ignored due to this bit from the CSS 2.1</DIV>
<DIV>recommendation:</DIV>
<DIV></DIV>
<DIV>"The properties of anonymous boxes are inherited from the enclosing</DIV>
<DIV>non-anonymous box (e.g., in the example just below the subsection</DIV>
<DIV>heading "Anonymous block boxes", the one for DIV). Non-inherited</DIV>
<DIV>properties have their initial value. For example, the font of the</DIV>
<DIV>anonymous box is inherited from the DIV, but the margins will be 0."</DIV>
<DIV>[1]</DIV>
<DIV></DIV>
<DIV>If we don't mark them as anonymous, we can get a crash related to</DIV>
<DIV>Javascript DOM manipulation at RenderBlock.cpp:680:</DIV>
<DIV></DIV>
<DIV>   ASSERT(anonymousChild->isAnonymous());</DIV>
<DIV></DIV>
<DIV>where it is searching for the anonymous wrapper that doesn't exist.</DIV>
<DIV>In fact, I believe the problem is that the beforeChild parameter is</DIV>
<DIV>the rendering object that has been wrapped and not the wrapper.  As</DIV>
<DIV>such, beforeChild is "wrong" and by adding something like:</DIV>
<DIV></DIV>
<DIV>    if (beforeChild && !beforeChild->isRenderMathMLBlock())</DIV>
<DIV>        beforeChild = beforeChild->parent();</DIV>
<DIV></DIV>
<DIV>I can fix that before I use it to add the wrapper.  I would have to do</DIV>
<DIV>this in all places where I know that I have wrappers with styles and</DIV>
<DIV>where I could actually guarantee what I'm doing.  In the case of</DIV>
<DIV>fractions, over/under, and a few others, this may work fine.</DIV>
<DIV></DIV>
<DIV>This doesn't feel like a good general solution.</DIV>
<DIV></DIV>
<DIV>Also, if I wrap an added child and code elsewhere assumes that the</DIV>
<DIV>parent/child relationship is the same as in the DOM, then I've broken</DIV>
<DIV>their assumption.  I see this same kind of behavior with table</DIV>
<DIV>sections in the RenderTable object and I wonder why beforeChild isn't</DIV>
<DIV>a problem there.</DIV>
<DIV></DIV>
<DIV>I fail to understand why I need to mark things as anonymous as they</DIV>
<DIV>aren't anonymous in the same sense of CSS.  This is a layout construct</DIV>
<DIV>needed to display the Mathematics.  I need to create these rendering</DIV>
<DIV>objects that do not correspond directly to a element in the way as</DIV>
<DIV>most others do.</DIV>
<DIV></DIV>
<DIV>I think I'm beginning to appreciate some of what Dave Hyatt was</DIV>
<DIV>hinting at to me that I may need my own line layout algorithm but I</DIV>
<DIV>still really don't want to go there.  That is, layout of a fraction</DIV>
<DIV>doesn't feel like line layout to me.</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>-- </DIV>
<DIV>--Alex Milowski</DIV>
<DIV>"The excellence of grammar as a guide is proportional to the paucity of the</DIV>
<DIV>inflexions, i.e. to the degree of analysis effected by the language</DIV>
<DIV>considered."</DIV>
<DIV></DIV>
<DIV>Bertrand Russell in a footnote of Principles of Mathematics</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 2</DIV>
<DIV>Date: Tue, 21 Jun 2011 12:16:52 -0400</DIV>
<DIV>From: Tom Smith <penguin.linux1@gmail.com></DIV>
<DIV>To: webkit-dev@lists.webkit.org</DIV>
<DIV>Subject: [webkit-dev] Making Webkit - PluginViewGtk.cpp error</DIV>
<DIV>Message-ID: <BANLkTi=Vyv1LoWiyJhOmzCfhuj8pOyXoHA@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset="windows-1252"</DIV>
<DIV></DIV>
<DIV>Hello,</DIV>
<DIV></DIV>
<DIV>I'm trying to install Webkit on Ubuntu, but I get the following error:</DIV>
<DIV></DIV>
<DIV>WebCore/plugins/gtk/PluginViewGtk.cpp: In member function ?void</DIV>
<DIV>WebCore::PluginView::init()?:</DIV>
<DIV>WebCore/plugins/gtk/PluginViewGtk.cpp:552: error:</DIV>
<DIV>?NPSetWindowCallbackStruct? was not declared in this scope</DIV>
<DIV>WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: ?ws? was not declared in</DIV>
<DIV>this scope</DIV>
<DIV>WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: expected type-specifier</DIV>
<DIV>before ?NPSetWindowCallbackStruct?</DIV>
<DIV>WebCore/plugins/gtk/PluginViewGtk.cpp:552: error: expected ?;? before</DIV>
<DIV>?NPSetWindowCallbackStruct?</DIV>
<DIV>WebCore/plugins/gtk/PluginViewGtk.cpp:572: error: ?struct NPWindow? has no</DIV>
<DIV>member named ?ws_info?</DIV>
<DIV>make[1]: *** [WebCore/plugins/gtk/libWebCore_la-PluginViewGtk.lo] Error 1</DIV>
<DIV>make[1]: Leaving directory `/home/screamer/Canmore/usr/src/WebKit-r36247'</DIV>
<DIV>make: *** [all] Error 2</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>I tried looking at the PluginViewGtk.cpp file, but I'm not sure how to fix</DIV>
<DIV>this. Can anyone help?</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>Best regards,</DIV>
<DIV>Tom</DIV>
<DIV>-------------- next part --------------</DIV>
<DIV>An HTML attachment was scrubbed...</DIV>
<DIV>URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110621/a2fa2b94/attachment-0001.html></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 3</DIV>
<DIV>Date: Tue, 21 Jun 2011 09:32:41 -0700</DIV>
<DIV>From: Ariya Hidayat <ariya.hidayat@gmail.com></DIV>
<DIV>To: Tom Smith <penguin.linux1@gmail.com></DIV>
<DIV>Cc: webkit-dev@lists.webkit.org</DIV>
<DIV>Subject: Re: [webkit-dev] Making Webkit - PluginViewGtk.cpp error</DIV>
<DIV>Message-ID: <BANLkTimR7+aB0wRkcKyUhe6KXSNoDTY8=g@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset=ISO-8859-1</DIV>
<DIV></DIV>
<DIV>You post too many build errors lately. Care to tell us what exactly</DIV>
<DIV>did you run? How did you invoke the 'build-webkit' script?</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>-- </DIV>
<DIV>Ariya Hidayat</DIV>
<DIV>http://www.linkedin.com/in/ariyahidayat</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 4</DIV>
<DIV>Date: Tue, 21 Jun 2011 13:51:01 -0400</DIV>
<DIV>From: Tom Smith <penguin.linux1@gmail.com></DIV>
<DIV>To: Ariya Hidayat <ariya.hidayat@gmail.com></DIV>
<DIV>Cc: webkit-dev@lists.webkit.org</DIV>
<DIV>Subject: Re: [webkit-dev] Making Webkit - PluginViewGtk.cpp error</DIV>
<DIV>Message-ID: <BANLkTinq9xgiyvBW=Em6RJwZeYTT1NaQEg@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset="iso-8859-1"</DIV>
<DIV></DIV>
<DIV>Hello,</DIV>
<DIV></DIV>
<DIV>I used the command: ./autogen.sh --prefix=${BUILD_DEST} to setup and</DIV>
<DIV>configure webkit, which compiled fine. But I get errors when I try to make</DIV>
<DIV>it. I'm running Ubuntu 10.10 with</DIV>
<DIV>WebKit-r36247.</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>Best regards,</DIV>
<DIV>Tom</DIV>
<DIV>On Tue, Jun 21, 2011 at 12:32 PM, Ariya Hidayat <ariya.hidayat@gmail.com>wrote:</DIV>
<DIV></DIV>
<DIV>> You post too many build errors lately. Care to tell us what exactly</DIV>
<DIV>> did you run? How did you invoke the 'build-webkit' script?</DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV>> --</DIV>
<DIV>> Ariya Hidayat</DIV>
<DIV>> http://www.linkedin.com/in/ariyahidayat</DIV>
<DIV>></DIV>
<DIV>-------------- next part --------------</DIV>
<DIV>An HTML attachment was scrubbed...</DIV>
<DIV>URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110621/9aa2c209/attachment-0001.html></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 5</DIV>
<DIV>Date: Tue, 21 Jun 2011 16:34:59 -0300</DIV>
<DIV>From: Raphael Kubo da Costa <kubo@profusion.mobi></DIV>
<DIV>To: webkit-dev@lists.webkit.org</DIV>
<DIV>Subject: Re: [webkit-dev] DumpRenderTree for the EFL port :)</DIV>
<DIV>Message-ID: <87pqm7dllo.fsf@profusion.mobi></DIV>
<DIV>Content-Type: text/plain</DIV>
<DIV></DIV>
<DIV>Leandro Pereira <leandro@profusion.mobi> writes:</DIV>
<DIV></DIV>
<DIV>> At last, the EFL port of WebKit got a DumpRenderTree implementation!</DIV>
<DIV>> We're still working on ironing out a lot of bugs found by some of the</DIV>
<DIV>> LayoutTests, but the DRT (and ImageDiff) code has been submitted to</DIV>
<DIV>> Bugzilla. It would be awesome if anyone could help reviewing these</DIV>
<DIV>> patches.</DIV>
<DIV></DIV>
<DIV>Thanks to eseidel, a few of our patchas have already made their way</DIV>
<DIV>upstream.</DIV>
<DIV></DIV>
<DIV>Unfortunately, he needs to take a break from too much exposure to</DIV>
<DIV>C-style code, so we need someone else to review our remaining</DIV>
<DIV>patches :-)</DIV>
<DIV></DIV>
<DIV>The remaining DRT patches are:</DIV>
<DIV></DIV>
<DIV>https://bugs.webkit.org/show_bug.cgi?id=61962</DIV>
<DIV>https://bugs.webkit.org/show_bug.cgi?id=61974</DIV>
<DIV>https://bugs.webkit.org/show_bug.cgi?id=63086</DIV>
<DIV>https://bugs.webkit.org/show_bug.cgi?id=61974</DIV>
<DIV></DIV>
<DIV>-- </DIV>
<DIV>Raphael Kubo da Costa</DIV>
<DIV>ProFUSION embedded systems</DIV>
<DIV>http://profusion.mobi</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 6</DIV>
<DIV>Date: Tue, 21 Jun 2011 16:30:47 -0700</DIV>
<DIV>From: Samuel White <samuel_white@apple.com></DIV>
<DIV>To: webkit-dev@lists.webkit.org</DIV>
<DIV>Subject: [webkit-dev] Accessibility Object Searching</DIV>
<DIV>Message-ID: <87C46CFC-F185-44D6-8986-F32DC1203C71@apple.com></DIV>
<DIV>Content-Type: text/plain; CHARSET=US-ASCII</DIV>
<DIV></DIV>
<DIV>Hey everybody,</DIV>
<DIV></DIV>
<DIV>I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information.</DIV>
<DIV></DIV>
<DIV>I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out.</DIV>
<DIV></DIV>
<DIV>Thanks</DIV>
<DIV>Sam</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 7</DIV>
<DIV>Date: Tue, 21 Jun 2011 17:45:36 -0700</DIV>
<DIV>From: Charles Pritchard <chuck@jumis.com></DIV>
<DIV>To: Samuel White <samuel_white@apple.com></DIV>
<DIV>Cc: "webkit-dev@lists.webkit.org" <webkit-dev@lists.webkit.org></DIV>
<DIV>Subject: Re: [webkit-dev] Accessibility Object Searching</DIV>
<DIV>Message-ID: <DB51F91C-7EFA-44A3-A2F1-6614A25BF3C3@jumis.com></DIV>
<DIV>Content-Type: text/plain; charset=us-ascii</DIV>
<DIV></DIV>
<DIV>On Jun 21, 2011, at 4:30 PM, Samuel White <samuel_white@apple.com> wrote:</DIV>
<DIV></DIV>
<DIV>> Hey everybody,</DIV>
<DIV>> </DIV>
<DIV>> I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information.</DIV>
<DIV>> </DIV>
<DIV>> I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out.</DIV>
<DIV>> </DIV>
<DIV>> Thanks</DIV>
<DIV>> Sam</DIV>
<DIV></DIV>
<DIV>While you're rooting around in there, I'd love to see the tree exposed to WebKit inspector at some point. It might make ARIA a little easier to use.</DIV>
<DIV></DIV>
<DIV>I'm still months away from being a contributor-- I'm hoping to see the canvas shadow DOM made accessible, and subsequently, see paths supported by assistive technology, like Apple's gesture-based eyes-free mode in Mobile Safari/iOS.</DIV>
<DIV></DIV>
<DIV>-Charles</DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 8</DIV>
<DIV>Date: Tue, 21 Jun 2011 18:56:44 -0700</DIV>
<DIV>From: Chris Fleizach <cfleizach@apple.com></DIV>
<DIV>To: Samuel White <samuel_white@apple.com></DIV>
<DIV>Cc: webkit-dev@lists.webkit.org</DIV>
<DIV>Subject: Re: [webkit-dev] Accessibility Object Searching</DIV>
<DIV>Message-ID: <342566E7-B50F-4192-B66A-BE57F23BBF01@apple.com></DIV>
<DIV>Content-Type: text/plain; CHARSET=US-ASCII</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>Searching for elements on a webpage is one of the important functions for a screen reader, so this has the potential for vastly improving screen reader access on the web.</DIV>
<DIV></DIV>
<DIV>What's nice about this approach is that it will allow other platforms to also take advantage. It should significantly reduce memory usage, number of IPC calls and overall runtime whenever searching is done.</DIV>
<DIV></DIV>
<DIV>On Jun 21, 2011, at 4:30 PM, Samuel White wrote:</DIV>
<DIV></DIV>
<DIV>> Hey everybody,</DIV>
<DIV>> </DIV>
<DIV>> I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information.</DIV>
<DIV>> </DIV>
<DIV>> I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out.</DIV>
<DIV>> </DIV>
<DIV>> Thanks</DIV>
<DIV>> Sam</DIV>
<DIV>> </DIV>
<DIV>> _______________________________________________</DIV>
<DIV>> webkit-dev mailing list</DIV>
<DIV>> webkit-dev@lists.webkit.org</DIV>
<DIV>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 9</DIV>
<DIV>Date: Tue, 21 Jun 2011 18:59:42 -0700</DIV>
<DIV>From: Chris Fleizach <cfleizach@apple.com></DIV>
<DIV>To: Charles Pritchard <chuck@jumis.com></DIV>
<DIV>Cc: "webkit-dev@lists.webkit.org" <webkit-dev@lists.webkit.org></DIV>
<DIV>Subject: Re: [webkit-dev] Accessibility Object Searching</DIV>
<DIV>Message-ID: <DCEDCDAD-A113-454B-B883-71EE7FF6C267@apple.com></DIV>
<DIV>Content-Type: text/plain; CHARSET=US-ASCII</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>On Jun 21, 2011, at 5:45 PM, Charles Pritchard wrote:</DIV>
<DIV></DIV>
<DIV>> On Jun 21, 2011, at 4:30 PM, Samuel White <samuel_white@apple.com> wrote:</DIV>
<DIV>> </DIV>
<DIV>>> Hey everybody,</DIV>
<DIV>>> </DIV>
<DIV>>> I'm new to the list and thought it would be a good idea to get some feedback on an accessibility feature before filing a bug or submitting anything. Currently, no functionality exists in WebKit to search through AccessibilityObjects using basic search criteria like next link or next table internally. Screen readers and other access devices often must instead probe WebKit and build up their own internal representation of a page before they can begin searching for what they are after. This presents two big problems for the users of access technology. First, pages such as the HTML 5 working doc have a massive number of DOM elements and building up an external representation can be a very expensive and slow task. Secondly, maintaining an accurate external representation of a site can become difficult if that site has a large amount of dynamic content and users may not be accessing relevant information.</DIV>
<DIV>>> </DIV>
<DIV>>> I would like to make a few small changes to the AccessibilityObject class that adds the functionality I've mentioned. I think these small but important additions will allow existing access technologies to rely much more on WebKits representation of a page and thus eliminate the problems I've described above. I appreciate any feedback and look forward to helping out.</DIV>
<DIV>>> </DIV>
<DIV>>> Thanks</DIV>
<DIV>>> Sam</DIV>
<DIV>> </DIV>
<DIV>> While you're rooting around in there, I'd love to see the tree exposed to WebKit inspector at some point. It might make ARIA a little easier to use.</DIV>
<DIV>> </DIV>
<DIV></DIV>
<DIV>The accessibility hierarchy is usually coupled (tightly at times) to the platform's implementation. Often there are tools on the platform to help figure out the accessibility hierarchy. </DIV>
<DIV></DIV>
<DIV>On the Mac, there's "Accessibility Inspector", which conveniently can also be run on the iOS simulator. Just start the program and hover the mouse over an item on a webpage to learn how it's exposed to the platform.</DIV>
<DIV></DIV>
<DIV>> I'm still months away from being a contributor-- I'm hoping to see the canvas shadow DOM made accessible, and subsequently, see paths supported by assistive technology, like Apple's gesture-based eyes-free mode in Mobile Safari/iOS.</DIV>
<DIV>> </DIV>
<DIV>> -Charles</DIV>
<DIV>> _______________________________________________</DIV>
<DIV>> webkit-dev mailing list</DIV>
<DIV>> webkit-dev@lists.webkit.org</DIV>
<DIV>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 10</DIV>
<DIV>Date: Tue, 21 Jun 2011 21:17:22 -0700</DIV>
<DIV>From: Simon Fraser <simon.fraser@apple.com></DIV>
<DIV>To: Hironori Bono (?? ??) <hbono@chromium.org></DIV>
<DIV>Cc: webkit-dev Development <webkit-dev@lists.webkit.org></DIV>
<DIV>Subject: Re: [webkit-dev] Spellcheck API for WebKit</DIV>
<DIV>Message-ID: <F2275B0C-3EE9-4E81-9C0E-B2E63E176664@apple.com></DIV>
<DIV>Content-Type: text/plain; charset=utf-8</DIV>
<DIV></DIV>
<DIV>On May 31, 2011, at 3:38 AM, Hironori Bono (?? ??) wrote:</DIV>
<DIV></DIV>
<DIV>> Greetings WebKit developers,</DIV>
<DIV>> </DIV>
<DIV>> These days, we have talked about adding Spellcheck API in the</DIV>
<DIV>> public-webapps ML:</DIV>
<DIV>> <http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0516>.</DIV>
<DIV>> This API currently consists of two functions (addSpellcheckRange and</DIV>
<DIV>> removeSpellcheckRange) and an attribute (spellcheckRanges) to editable</DIV>
<DIV>> elements of HTML so web-application developers (and extension</DIV>
<DIV>> developers) can implement custom spellcheckers. Also, I have uploaded</DIV>
<DIV>> a reference implementation of this API to <http://webkit.org/b/59693>.</DIV>
<DIV>> Even though this change enables this SpellcheckAPI only on Chromium,</DIV>
<DIV>> it would be definitely helpful to give me your feedback not only for</DIV>
<DIV>> this Spellcheck API and also for my WebKit change.</DIV>
<DIV>> Thank you for your help in advance.</DIV>
<DIV></DIV>
<DIV>This new API got turn on inadvertently on Mac just now, and a few of us spent</DIV>
<DIV>a wasted hour trying to get things to build. In this light, my comments on the API</DIV>
<DIV>may not be as favorable as they would otherwise be.</DIV>
<DIV></DIV>
<DIV>First, why is the API on HTMLDivElement?</DIV>
<DIV></DIV>
<DIV>Second, since this exposes to the web API in a non-final spec, the new methods</DIV>
<DIV>should be prefixed with 'webkit' to avoid potential conflict if the API changes later.</DIV>
<DIV></DIV>
<DIV>Simon</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 11</DIV>
<DIV>Date: Wed, 22 Jun 2011 15:04:09 +0900</DIV>
<DIV>From: Hironori Bono (?? ??)  
<hbono@chromium.org></DIV>
<DIV>To: Simon Fraser <simon.fraser@apple.com></DIV>
<DIV>Cc: webkit-dev Development <webkit-dev@lists.webkit.org></DIV>
<DIV>Subject: Re: [webkit-dev] Spellcheck API for WebKit</DIV>
<DIV>Message-ID:</DIV>
<DIV><BANLkTim9TzR2y70AJpWJSM1WJVY7qE+LQdjb5RP6bEkvxrXbCw@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset=ISO-8859-1</DIV>
<DIV></DIV>
<DIV>Greetings Simon,</DIV>
<DIV></DIV>
<DIV>Apologies for my stupid change in advance.</DIV>
<DIV>My change just tried to straightforwardly implement a suggestion</DIV>
<DIV><http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/0545.html></DIV>
<DIV>without deep consideration about WebKit manners noted by your e-mail.</DIV>
<DIV></DIV>
<DIV>On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser <simon.fraser@apple.com> wrote:</DIV>
<DIV>> This new API got turn on inadvertently on Mac just now, and a few of us spent</DIV>
<DIV>> a wasted hour trying to get things to build. In this light, my comments on the API</DIV>
<DIV>> may not be as favorable as they would otherwise be.</DIV>
<DIV>></DIV>
<DIV>> First, why is the API on HTMLDivElement?</DIV>
<DIV></DIV>
<DIV>Unfortunately, I have just copied and pasted my code in</DIV>
<DIV>HTMLTextAreaElement to support contenteditable elements and designMode</DIV>
<DIV>ones because I did not have better ideas at that time. I should have</DIV>
<DIV>asked about it in this ML before landing this change.</DIV>
<DIV></DIV>
<DIV>> Second, since this exposes to the web API in a non-final spec, the new methods</DIV>
<DIV>> should be prefixed with 'webkit' to avoid potential conflict if the API changes later.</DIV>
<DIV></DIV>
<DIV>This is totally my fault. (The sin of ignorance.) Sorry again for that.</DIV>
<DIV></DIV>
<DIV>By the way, I wonder how I should treat my r88332 even though I</DIV>
<DIV>understand this change was wrong. Even though there are several</DIV>
<DIV>options: 1. re-design the API, 2. revert my r88332 and re-implement</DIV>
<DIV>it, 3. send changes that apply these comments, etc. Would it be</DIV>
<DIV>possible to give me your advice?</DIV>
<DIV></DIV>
<DIV>Regards,</DIV>
<DIV></DIV>
<DIV>Hironori Bono</DIV>
<DIV>E-mail: hbono@chromium.org</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 12</DIV>
<DIV>Date: Tue, 21 Jun 2011 23:27:12 -0700</DIV>
<DIV>From: Ryosuke Niwa <rniwa@webkit.org></DIV>
<DIV>To: Hironori Bono (?? ??)  
<hbono@chromium.org></DIV>
<DIV>Cc: webkit-dev Development <webkit-dev@lists.webkit.org></DIV>
<DIV>Subject: Re: [webkit-dev] Spellcheck API for WebKit</DIV>
<DIV>Message-ID: <BANLkTini7srECj3Oj-wCa=BOK+FdZZEKsw@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset="iso-2022-jp"</DIV>
<DIV></DIV>
<DIV>2011/6/21 Hironori Bono (?? ??) <hbono@chromium.org></DIV>
<DIV>></DIV>
<DIV>>  On Wed, Jun 22, 2011 at 1:17 PM, Simon Fraser <simon.fraser@apple.com></DIV>
<DIV>> wrote:</DIV>
<DIV>> > This new API got turn on inadvertently on Mac just now, and a few of us</DIV>
<DIV>> spent</DIV>
<DIV>> > a wasted hour trying to get things to build. In this light, my comments</DIV>
<DIV>> on the API</DIV>
<DIV>> > may not be as favorable as they would otherwise be.</DIV>
<DIV>> ></DIV>
<DIV>> > First, why is the API on HTMLDivElement?</DIV>
<DIV>></DIV>
<DIV>> Unfortunately, I have just copied and pasted my code in</DIV>
<DIV>> HTMLTextAreaElement to support contenteditable elements and designMode</DIV>
<DIV>> ones because I did not have better ideas at that time. I should have</DIV>
<DIV>> asked about it in this ML before landing this change.</DIV>
<DIV>></DIV>
<DIV></DIV>
<DIV>contenteditable attribute can appear in any element so I don't think we</DIV>
<DIV>should restrict it to div.</DIV>
<DIV></DIV>
<DIV> > Second, since this exposes to the web API in a non-final spec, the new</DIV>
<DIV>> methods</DIV>
<DIV>> > should be prefixed with 'webkit' to avoid potential conflict if the API</DIV>
<DIV>> changes later.</DIV>
<DIV>></DIV>
<DIV>> This is totally my fault. (The sin of ignorance.) Sorry again for that.</DIV>
<DIV>></DIV>
<DIV>> By the way, I wonder how I should treat my r88332 even though I</DIV>
<DIV>> understand this change was wrong. Even though there are several</DIV>
<DIV>> options: 1. re-design the API, 2. revert my r88332 and re-implement</DIV>
<DIV>> it, 3. send changes that apply these comments, etc. Would it be</DIV>
<DIV>> possible to give me your advice?</DIV>
<DIV>></DIV>
<DIV></DIV>
<DIV>Given that the original patch seems to have various issues and we're going</DIV>
<DIV>to make a lot of changes (i.e. move it to HTMLElement and prefix it with</DIV>
<DIV>webkit or chrome), option 2 seems most suitable approach here.</DIV>
<DIV></DIV>
<DIV>- Ryosuke</DIV>
<DIV>-------------- next part --------------</DIV>
<DIV>An HTML attachment was scrubbed...</DIV>
<DIV>URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110621/aabce8e8/attachment-0001.html></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 13</DIV>
<DIV>Date: Wed, 22 Jun 2011 09:19:05 -0400</DIV>
<DIV>From: Tom Smith <penguin.linux1@gmail.com></DIV>
<DIV>To: webkit-dev Development <webkit-dev@lists.webkit.org></DIV>
<DIV>Subject: [webkit-dev] Setting up Eclipse IDE for Webkit..</DIV>
<DIV>Message-ID: <BANLkTi=vuYFpzdpWR5cfQ2iXAE9KNA5veg@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset="iso-8859-1"</DIV>
<DIV></DIV>
<DIV>Hi everyone,</DIV>
<DIV></DIV>
<DIV>  Has anyone used Eclipse IDE on Ubuntu?  If so do you have</DIV>
<DIV>any recommendations?</DIV>
<DIV></DIV>
<DIV>Thanks.</DIV>
<DIV>-------------- next part --------------</DIV>
<DIV>An HTML attachment was scrubbed...</DIV>
<DIV>URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20110622/0bf55c8a/attachment-0001.html></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>Message: 14</DIV>
<DIV>Date: Wed, 22 Jun 2011 10:22:24 -0300</DIV>
<DIV>From: Alexis Menard <alexis.menard@openbossa.org></DIV>
<DIV>To: Tom Smith <penguin.linux1@gmail.com></DIV>
<DIV>Cc: webkit-dev Development <webkit-dev@lists.webkit.org></DIV>
<DIV>Subject: Re: [webkit-dev] Setting up Eclipse IDE for Webkit..</DIV>
<DIV>Message-ID: <BANLkTinD-vcmMC_g_GBgB65La89hgDK44A@mail.gmail.com></DIV>
<DIV>Content-Type: text/plain; charset=ISO-8859-1</DIV>
<DIV></DIV>
<DIV>Hi,</DIV>
<DIV></DIV>
<DIV>Which port you want to build?</DIV>
<DIV></DIV>
<DIV>For Qt :</DIV>
<DIV></DIV>
<DIV>QtCreator for the Qt port works pretty well, just open the WebCore.pro</DIV>
<DIV>or QtWebKit.pro with it.</DIV>
<DIV></DIV>
<DIV>Though I've never tried Eclipse on the Qt port.</DIV>
<DIV></DIV>
<DIV>On Wed, Jun 22, 2011 at 10:19 AM, Tom Smith <penguin.linux1@gmail.com> wrote:</DIV>
<DIV>> Hi everyone,</DIV>
<DIV>> ? Has anyone used Eclipse IDE on Ubuntu? ?If so do you have</DIV>
<DIV>> any?recommendations?</DIV>
<DIV>> Thanks.</DIV>
<DIV>> _______________________________________________</DIV>
<DIV>> webkit-dev mailing list</DIV>
<DIV>> webkit-dev@lists.webkit.org</DIV>
<DIV>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</DIV>
<DIV>></DIV>
<DIV>></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>-- </DIV>
<DIV>Alexis Menard</DIV>
<DIV>Software Engineer</DIV>
<DIV>INdT Recife Brazil</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>------------------------------</DIV>
<DIV></DIV>
<DIV>_______________________________________________</DIV>
<DIV>webkit-dev mailing list</DIV>
<DIV>webkit-dev@lists.webkit.org</DIV>
<DIV>http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</DIV>
<DIV></DIV>
<DIV></DIV>
<DIV>End of webkit-dev Digest, Vol 73, Issue 28</DIV>
<DIV>******************************************</DIV>
<DIV></DIV>
<DIV></DIV></FONT></DIV></BODY></HTML>