Re: [webkit-dev] Adding element to WebCore

[Alex Russell]

My object is somewhat different. I think it's useful for the readability
use-case (and the other proposed "solutions" are mostly bad jokes), but it
doesn't strike me that this give you much default UI and doesn't plumb
through any new low-level capability.

In that vein, I wonder why it's not being proposed as an ARIA role instead?

On Tuesday, November 27, 2012, Ojan Vafai wrote:

> As I said on the thread you link to, I don't think this element addresses
> any real use-cases. I think people are far too likely to misuse this for it
> to be useful for things like readability to use.
>
> If Apple really wants this, I won't object, but my preference would be to
> not implement this.
>
>
> On Mon, Nov 26, 2012 at 2:01 PM, Steve Faulkner 
>  'faulkner.st...@gmail.com');>
> > wrote:
>
>> Hi all,
>>
>> this is my first post to the list.
>>
>> I have submitted a patch [1] to add   element support to webkit and
>> would appreciate your consideration.
>>
>> the main element is defined here:
>> http://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html 
>> current
>> status unofficial draft, CFC [2] to publish as a first working draft via
>> HTML WG ends today.
>>
>> Rationale and use cases:
>> http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction
>>
>> details of data set and data analysis conducted during development of
>> feature:
>> http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html
>>
>> There has been discussion and feedback provided on the WHATWG list [3]
>> and IRC and at TPAC 2012 HTML WG meeting.
>>
>> I look forward to your comments!
>>
>>
>> [1] https://bugs.webkit.org/show_bug.cgi?id=103172
>> [2]
>> http://lists.w3.org/Archives/Public/public-html/2012Nov/thread.html#msg129
>> [3] threads start here:
>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/thread.html#msg55
>>
>> --
>> with regards
>>
>> Steve Faulkner
>> Technical Director - TPG
>>
>> www.paciellogroup.com | www.HTML5accessibility.com |
>> www.twitter.com/stevefaulkner
>>
>>  
>>
>> ___
>> webkit-dev mailing list
>> webkit-dev@lists.webkit.org > 'webkit-dev@lists.webkit.org');>
>> http://lists.webkit.org/mailman/listinfo/webkit-dev
>>
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] New feature flag proposal: Joystick API

[Alex Russell]

On Wed, Aug 24, 2011 at 8:36 AM, Scott Graham  wrote:
> Hi,
>
> I wanted to let everyone know that I propose to add a new feature
> flag, JOYSTICK. http://webkit.org/b/66859
>
> This flag will enable an API and events for accessing joysticks and
> related devices. There's a prototype effort happening in Mozilla also
> (https://wiki.mozilla.org/JoystickAPI), and the design is intended to
> be similar.

The API they're advocating for over in mozilla-land is strange. Why
not an  type or other element with DOM events firing from it?
Handling connection/disconnection seems like it shouldn't be necessary
in the common case. Further API can be then hung off of the element,
avoiding warts like permission prompts in most cases.

> As it will not necessarily make sense for all ports, nor be
> implemented immediately in all ports, a feature flag seems
> appropriate.
>
> Please let me know if you have any concerns or comments.
>
> Thanks
> ___
> 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

[Alex Russell]

On Thu, Jun 30, 2011 at 4:22 PM, John J. Barton  wrote:

> From: Alex Russell 
>
>
>> We observe that web developers are attempting to use DOM in both
>> structural
>> ("semantic" or "component-oriented") and visual ways inside the same
>> document.
>>
> I would like to understand what you mean here: can you suggest an example
> or other place to read? In particular I imagine the DOM as a tree of visual
> components which can be interpreted in multiple ways, some of which cause
> the tree to become a graph. I don't understand the split between "visual"
> and "components".
>
>  This creates tension and requires unnatural levels of discipline.
>> Notably:
>>
>>
>>- Understanding your DOM as a retained-mode component tree is
>> confounded
>>by the presence of "visual" nodes in the document.
>>- It's currently impossible to build new "components" which can be
>> added
>>to the tree in a native way. Instead, systems like Closure, Dojo, YUI,
>> etc.
>>build parallel trees of components in script which manage chunks of
>> "visual"
>>DOM. Anyone who attempts to script this visual DOM risks blowing up the
>>entire world as ownership becomes confused.
>>
> By "parallel trees of components" do you mean "logical or conceptual
> components managed by Closure/Dojo et al rather than DOM"?
>

Yes. The "DOM is semantic" instinct leads this reality for large apps to
create serious cognitive overhead. In using a new component, you must be
aware of (and know the rules for) this parallel tree as well as its
relationship to other DOM which, for all intents and purposes, might be just
fine for *some* bits of your app. Forms are a great example of this, wherein
you want a regular  in one place and a constrained date
picker in the next. Mixing and matching these today requires feats of
discipline that custom, "real DOM" components could help alleviate.


> - The parallel trees that these toolkits create are non-interoperable.
>>
>>The low-level bits of these toolkits are generally interoperable to the
>>extent that they agree on DOM, therefore, allowing components to be
>>expressed with a DOM interface would bolster interoperability.
>>- Working with DOM as a visual representation for components is made
>>difficult because of tension between the desire to add structure to
>> enable
>>visual controls and the "markup is semantic" ideal.
>>
> This last phrase is the one that really caught my interest, but I don't
> understand the sentence.  How can one work with the DOM as a visual
> representation without adding structure?


That's exactly the problem. Re-arranging elements visually often requires
re-parenting them with respect to ne structure. That structure isn't there
to convey meaning in terms of the tree of components, only their layout.
Having to wade through this sea of formatting nodes makes working with
DOM-as-component-tree less than satisfying.


> How can this be in tension with "markup is semantic"? By "markup is
> semantic" ideal do you mean "gee it would be awesome if markup exactly
> expressed my full-formed, universally  understood, perfect Web page which
> can't possibly exist"?


No.


>  It just seems odd to juxtapose a practical thing with something that is
> impossible.
>

I'm not trying to. I used lower-case "s" and quotes around "semantic" to
(unsuccessfully) avoid that. Custom components will only ever have local
or probabilistic non-local meaning, but my view is that's the best you'll do
in any casethe Meta Crap argument, if you will.

DOM is confused on many levels, and I'm only trying to explain how the
desire to express the relationships between components is currently in
tension with the desire to use HTML/CSS/DOM for rapid creation of component
view and layout. A shadow or view axis for components can alleviate this
tension.


> Sorry if my questions are naive. I've worked quite a lot with XBL and now
> we are planning to get rid of it in our code so I'm puzzled by arguments
> between two groups who want to improve it (or so that is how I interpret
> this thread).


Assume that my position from here on out is this:


   - XBL and XBL2 contain many good ideas
   - These ideas may have more leverage as small additions to HTML/CSS/DOM
   than as a large, coordinated and interdependent spec
   - Many of the use-cases that XBL and XBL2 handle are not primary in the
   toolkits that are being used widely on the web today. As far as suitability
   for inclusion in the web platform goes, I argue that we should pay more
   attention to common practice than to un-implemented standards. One of the
   two has a test function for utility, and it isn't the one without users.
___
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]

Hi Sam,

On Thu, Jun 30, 2011 at 3:50 AM, Sam Weinig  wrote:

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


XBL2 introduces complexities we didn't see the need to accommodate as the
use cases differ (see below). Instead of saying "lets just do XBL2", it
would help to understand what properties it has that you think are valuable
-- other than being "out there" for a long time, since that's not actually
of any value to web developers.

In trying to come up with a model that satisfies the needs of web developers
who are trying to build components, we've found that many of the concepts
XBL2 embodies can be handled orthogonally. For instance, data binding can
happen independently of the XBL concept of "bindings" (see the MDV
experiments), as can the templating language. These systems have power to
handle expanded, important use cases when decouples from XBL, and at a
minimum are more easily and clearly understood when presented in a way that
composes them instead of bundling them.


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


We observe that web developers are attempting to use DOM in both structural
("semantic" or "component-oriented") and visual ways inside the same
document. This creates tension and requires unnatural levels of discipline.
Notably:


   - Understanding your DOM as a retained-mode component tree is confounded
   by the presence of "visual" nodes in the document.
   - It's currently impossible to build new "components" which can be added
   to the tree in a native way. Instead, systems like Closure, Dojo, YUI, etc.
   build parallel trees of components in script which manage chunks of "visual"
   DOM. Anyone who attempts to script this visual DOM risks blowing up the
   entire world as ownership becomes confused.
   - The parallel trees that these toolkits create are non-interoperable.
   The low-level bits of these toolkits are generally interoperable to the
   extent that they agree on DOM, therefore, allowing components to be
   expressed with a DOM interface would bolster interoperability.
   - Working with DOM as a visual representation for components is made
   difficult because of tension between the desire to add structure to enable
   visual controls and the "markup is semantic" ideal. The lack of a view-DOM
   axis for components means that implementation and interface must always
   bleed into each other.
   - CSS rules have over-broad application as a result of specificity, and
   having some mechanism for targeting CSS to "just my component" would enable
   developers to write more terse, less unintentionally over-specific rules
   that are easier to maintain and integrate.
   - Building custom components without platform support leads to a
   duplication of infrastructure between toolkits, slowing apps unnecessarily.
   - Decoration is the exceptional case, not the base-case, and is currently
   handled in script with utilities like querySelectorAll(). This appears to be
   workable and explicit system support isn't justified at this point.

That's not exhaustive, and I can elaborate with examples if you prefer. I
look forward to understanding your perspective better.


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

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] Adding ENABLE_CONTACTS to WebCore

[Alex Russell]

On Mon, Jun 27, 2011 at 5:49 PM, Ojan Vafai  wrote:

> Can you give an example of a smooth UI that you'd need the more complex API
> for? When I think of the existing mail and chat apps in iOS/Android that
> I've use,  could give just as smooth a UI as the
> existing apps, it's just on the browser side to make the UI good instead of
> on the web developer side.


This has lots of follow-on advantages too:


   - Browser-provided UI is consistent for the user WRT the OS (see file
   pickers). Your app would need to guess to match the visual and interaction
   style.
   - Browsers can handle all of this with much less code on your part. The
   latency involved in building and sending the custom UI makes for a bad
   experience, and is it work you really want to be biting off for your app?
   - A11y, focus management, and all the rest with Just Work (TM).



> On Mon, Jun 27, 2011 at 3:37 AM, Alex Nicolaou wrote:
>
>> A user agent defined solution will make apps like mail, chat,
>> Facebook, and so on all feel awful in safari versus installing a
>> native app. It's like j2me all over again unless the website can
>> provide a smooth ui.
>>
>> Alex
>>
>>
>> On Friday, June 24, 2011, Ojan Vafai  wrote:
>> > Is there a document that lists the use-cases for this API? I couldn't
>> find anything from a quick glance through the DAP working group's mailing
>> list archive. A list of use-cases would help evaluate whether this is the
>> best API. At first glance, it strikes me that something like > type=contacts> would meet the uses-cases I can think of better.
>> >
>> >
>> > Ojan
>> >
>> > On Thu, Jun 23, 2011 at 11:28 PM, 김동관  wrote:
>> >
>> >
>> > Hi webkit-dev!
>> >
>> > I wanted to let you know that I plan to add Contacts API support to
>> WebKit.
>> > This API is a new feature that is published by W3C.
>> > The Device APIs Working Group of W3C has just released a Last Call
>> Working Draft of its Contacts API:
>> > http://www.w3.org/TR/2011/WD-contacts-api-20110616/
>> >
>> > I'm going to commit patch for Contacts API implementation very soon.
>> >
>> > This support will be behind the ENABLE_CONTACTS feature define. See:
>> > https://bugs.webkit.org/show_bug.cgi?id=63223
>> >
>> > We'll be setting up a buildbot to track then ENABLE_CONTACTS build
>> shortly. We expect
>> > this feature to be eventually enabled by all ports.
>> > Looking forward to your comments.
>> >
>> > Thank you.
>> >
>> > Donggwan
>> > ___
>> > webkit-dev mailing list
>> > webkit-dev@lists.webkit.org
>> > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>> >
>> >
>> >
>>
>> --
>> --
>> Try Gmail Offline for Chrome > >,
>> and send me your complaints!
>>
>
>
> ___
> 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] Adding ENABLE_CONTACTS to WebCore

[Alex Russell]

On Fri, Jun 24, 2011 at 7:27 PM, Ojan Vafai  wrote:

> Is there a document that lists the use-cases for this API? I couldn't find
> anything from a quick glance through the DAP working group's mailing list
> archive. A list of use-cases would help evaluate whether this is the best
> API. At first glance, it strikes me that something like  type=contacts> would meet the uses-cases I can think of better.


Seconded.


> On Thu, Jun 23, 2011 at 11:28 PM, 김동관  wrote:
>
>> Hi webkit-dev!
>>
>> I wanted to let you know that I plan to add Contacts API support to
>> WebKit.
>> This API is a new feature that is published by W3C.
>> The Device APIs Working Group of W3C has just released a Last Call Working
>> Draft of its Contacts API:
>>http://www.w3.org/TR/2011/WD-contacts-api-20110616/
>>
>> I'm going to commit patch for Contacts API implementation very soon.
>>
>> This support will be behind the ENABLE_CONTACTS feature define. See:
>> https://bugs.webkit.org/show_bug.cgi?id=63223
>>
>> We'll be setting up a buildbot to track then ENABLE_CONTACTS build
>> shortly. We expect
>> this feature to be eventually enabled by all ports.
>> Looking forward to your comments.
>>
>> Thank you.
>>
>> Donggwan
>>
>
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] webkit editing rewrite?

[Alex Russell]

On Tue, Aug 3, 2010 at 5:07 PM, Geoffrey Garen  wrote:
>> Some of us had a somewhat crazy idea to rewrite much of the editing code 
>> (e.g. document.execCommand) in JavaScript.
>>
>> Pros:
>
>> -Ensures that the APIs we expose to the web are at least good enough for our 
>> own editing code
>
> I don't think this necessarily follows. Not everything exposed to the 
> internal editing implementation would necessarily be exposed to the web. If 
> we required that everything exposed to the internal editing implementation be 
> exposed to the web, that would substantially slow development, since every 
> new API would need to be vetted and possibly standardized. So this is either 
> not true or a substantial con.

It's not like that's a serial process. More to the point, assuming the
current command API is the result (as proposed) and that DOM ranges
are supported, it's unclear that standardization is a major risk. In
any case, we won't get better APIs if we don't try and the current
APIs suck hard.

>> -Ensures that editing code never crashes (outside of JSC/V8 bugs)
>
> JavaScript can still crash -- you just get an unhandled exception instead of 
> a segfault. It's not clear to me why that would be better. I can think of 
> reasons why it would be worse:

These crashes are much less likely to be exploitable security issues.
That's one (major) plus.

> - Can't use standard OS tools like CrashReporter to detect problem areas.
> - Harder to debug, since you need to use the Web Inspector, which:
>        - doesn't have all the features of modern C++ debuggers, like 
> watchpoints and breakpoint commands
>        - creates a circular dependency
> - Sometimes, instead of an unhandled exception, you'll just get incorrect 
> behavior that's very hard to track down.
>
> A similar set of cons pertains to performance issues.

I'm not sure that's clearly true.

>> -Gives a clean slate for starting the editing code anew
>
> This is an argument for a rewrite, not an argument for JavaScript. A rewrite 
> can happen in any language.
>
> A rewrite is not self-evidently a good thing.

Nobody suggested it was? The basis for the suggestion is:

  * today's JS APIs are not fit for the tasks that are being asked of them
  * the command system isn't extensible from JS, causing incredible
amounts of hackery and rework in every JS wrapper for editors
  * when things go south in the current system, crashes are
potentially exploitable

>> -Moves code out of WebCore
>
> Changing the language doesn't move the code out of WebCore.
>
> Moving code out of WebCore is not self-evidently a good thing.
>
>> -If other browser vendors choose to expose the same APIs, then we can share 
>> the editing library and make the world better for web developers
>
> That's a big if. Do you have any evidence that other vendors are interested? 
> Are there vendors specifically interested in adopting WebKit's editing 
> library, but not WebKit as a whole? That would surprise me.

Fair enough, but consider the case of a rich text editing system as
exists in products like GMail and Mobile Me where the current
infrastructure is as much a liability as an asset. For those systems,
having better plumbing and being able to operate on more
deterministic, low-level APIs for editing would be a serious plus.

>> Cons:
>> -Potentially slower since DOM calls are now JS-->C++
>> -Potential for regressions due to holes in the layout test coverage
>> -Not statically typed
>
> I notice that you don't mention the added complexity of gluing two languages 
> together for core DOM operations. I think that's probably the main con.

The bindings are already opaque. How is this really worse?

>> I'm not too concerned about the perf hit. It should be no more than a 
>> constant-factor and, historically, the editing perf problems have been 
>> order-of-magnitude issues.
>
> You're not considering the hurt that the editing JavaScript code could put on 
> website code. If the editing memory footprint is large, the GC hit on other 
> websites could be substantial.
>
> JavaScript's scoping rules also have a nasty tendency to introduce accidental 
> memory references that keep large object graphs alive, exacerbating this 
> problem.

Luckily Ojan et. al. happen to be very good at JavaScript ;-)

Regards

> For security reasons, we might need to instantiate a new copy of the editing 
> code for every webpage. That could be a substantial memory use regression.
>
>> As for the functionality regressions, I think they're inevitable. We'd hit 
>> most of the same issues trying to refactor the existing C++ code on top of 
>> better APIs.
>
> I agree that a rewrite inevitably introduces a large number of bugs, 
> regardless of whether it happens in C++ or JavaScript.
>
> However, I don't agree that refactoring inevitably introduces just as many 
> bugs as rewriting. I would submit that the entire history of the WebKit 
> project demonstrates the value of refactoring over rewriting.
>
> Geoff
> ___

Re: [webkit-dev] MD5 in WebCore

[Alex Russell]

Hate to ask a dumb question, but why MD5? Isn't it on its last legs as
a secure hash? New protocols should be avoiding it.

On Tue, Apr 20, 2010 at 11:48 AM, Michael Nordman  wrote:
> In webcore, should we use the same impl on all platforms rather than use
> cryptdll on windows and md5.cc elsewhere?
> For chrome, I don't think we can have a dependency between
> WebKit/WebKit/chromium and /src/base/, and 'base' depending on 'webkit' also
> doesn't work. How can we avoid replicating the code? I guess having
> webcore's MD5 be platform specific could help us along those lines?
>
> On Tue, Apr 20, 2010 at 4:12 AM, Maciej Stachowiak  wrote:
>>
>> On Apr 20, 2010, at 3:32 AM, Fumitoshi Ukai (鵜飼文敏) wrote:
>>
>> I'm implementing new protocol of WebSocket
>> ( http://www.whatwg.org/specs/web-socket-protocol/ ).
>> Since it now requires MD5 in handshake, I wonder how I could add MD5 in
>> WebCore.  For now, there is no MD5 in WebCore.  It is in
>> WebKitTools/DumpRenderTree to get message digest of image file.
>> I'm thinking to add new header file as WebCore/platform/MD5.h, which
>> provides the following functions.
>>   struct MD5_CTX;
>>   void MD5_Init(MD5_CTX*);
>>   void MD5_Update(MD5_CTX*, unsigned char* input, unsigned length);
>>   void MD5_Final(unsigned char hash[16], MD5_CTX*);
>> In Windows platform, it is implemented using "Cryptdll.dll".   Is it ok to
>> copy WebKitTools/DumpRenderTree/win/MD5.cpp to WebCore/platform/win/MD5.cpp,
>> or move?
>> In Mac platform, it is provided by  with
>> #define COMMON_DIGEST_FOR_OPENSSL ?
>> In Chromium, there is chrome/src/base/md5.{h,cc}.   Should I copy this in
>> WebCore/platform/chromium, or add dependency to base from WebCore?
>> How about other ports?  is it ok to link openssl or some other library?
>>  (or use implementation used in chromium?)
>> I'm also wonder I need to put these functions in namespace WebCore.
>>
>> If you put this code in WebCore, it should go in the WebCore namespace. I
>> think it would also be a good idea to turn the API into something more
>> WebCore-ish, something like:
>> namespace WebCore {
>>     class MD5 {
>>         MD5(); // what was MD5_Init
>>         addBytes(uint8_t* input, size_t length); // what was MD5_Update ;
>> or maybe this should take a Vector?
>>         Vector checksum(); // what was MD5_Final
>>     };
>> }
>> (The key point being to match the coding style guidelines for names, but
>> it also seems better to use a class here instead of a struct and functions
>> that take a pointer to it.)
>> Regards,
>> Maciej
>>
>> ___
>> 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] Join the URL hackathon (already in progress)!

[Alex Russell]

On Tue, Apr 13, 2010 at 11:39 PM, David Levin  wrote:
>
>
> On Tue, Apr 13, 2010 at 11:35 PM, Adam Barth  wrote:
>>
>> Ah, sorry, I meant to the point where the library was integrated with
>> the various build systems, etc.  Maybe that's already possible today.
>> I haven't investigated it in detail.  It probably also makes sense to
>> talk about correctness between steps (1) and (2), once we have the
>> tests and their results to compare across browsers.
>>
>> Adam
>>
>>
>> On Tue, Apr 13, 2010 at 11:28 PM, Darin Fisher  wrote:
>> > #4 is already basically done.  See USE(GOOGLEURL).
>> > -Darin
>> >
>> >
>> > On Tue, Apr 13, 2010 at 11:17 PM, Adam Barth  wrote:
>> >>
>> >> I think Maciej took notes, but my recollection is as follows:
>> >>
>> >> 1) Convert as many of the unit tests to LayoutTests as possible.
>> >> 2) Land GURL in svn.webkit.org as is.
>
> I think there was:
>    2.5 Change the name from GoogleURL to something else.
>
> (WebKitUrl?)

In the long tradition of first-letter-then-URL, we had also jokingly
suggested "BURL" in reference to Brett's parentage of the library.
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Making browsers faster: Resource Packages

[Alex Russell]

On Tue, Nov 17, 2009 at 3:00 PM, James Robinson  wrote:
> On Tue, Nov 17, 2009 at 2:19 PM, Alexander Limi  wrote:
>>
>> Good people of Webkit!
>>
>> We'd all like for the web to be faster, and therefore I'd love your feedback 
>> on my proposal — it would be great to see support for this in additional 
>> browsers, not just Firefox:
>>
>> http://limi.net/articles/resource-packages/
>>
>> Summary:
>> What if there was a backwards compatible way to transfer all of the 
>> resources that are used on every single page in your site — CSS, JS, images, 
>> anything else — in a single HTTP request at the start of the first visit to 
>> the page? This is what Resource Package support in browsers will let you do.
>>
>> Looking forward to hear your thoughts on this.
>
> It seems like a browser will have to essentially stop rendering until
> it has finished downloading the entire .zip and examined it.

I think that's not entirely true. In zip archives the manifest comes
first and can be examined while the rest of the body is still
downloading.

>  This
> will most likely slow down the time taken to render parts of the page
> as they arrive. From the blog post:
>
> "A given browser will probably block downloading any resources until
> the lists of files that are available in resource packages have been
> accounted for — or there may be a way to do opportunistic requests or
> similar, we leave this up to the browser vendor unless there’s a
> compelling reason to specify how this should work."
>
> This also means that a browser would have to stop tokenizing the HTML
> when it hits the next 

Re: [webkit-dev] GlobalScript API.

[Alex Russell]

On Tue, Sep 1, 2009 at 9:58 PM, Ojan Vafai wrote:
> On Tue, Sep 1, 2009 at 9:07 PM, Oliver Hunt  wrote:
>>
>> On Sep 1, 2009, at 4:13 PM, Dmitry Titov wrote:
>>
>> Thanks a lot Maciej!
>> As a note to the API described in this thread: there was a proposal in
>> private thread to replace the JS constructor with 4 parameters with a tag:
>> instead of
>> var globalScript = new webkitGlobalScript(name, url, loadHandler,
>> errorHandler);
>
> I know this as been discussed a million times already, but this bugs me.
> What if you want to load multiple scripts or populate a globalscript from
> the parent page(s)? I prefer the other importScript-like ideas.
> I'd much prefer if we made creating a globalScript synchronous and with no
> network request. The async load of iframes with an empty src is really
> frustrating to web developers and causes lots of bugs and performance
> problems in practice.
> If we keep this syntax, we should at least try and special-case leaving out
> the url argument so that we load the globalscript synchronously. I'm not
> sure if this is really feasible given the time it takes to create a
> Document, but we should at least try it and measure the performance..

Not to harp, but for lack of a missing abstraction (Deferreds or
Futures, or whatever your particular CS dept called them), we've seen
every JS library on the planet re-invent some "onready" abstraction
when the built-in events don't quite cover it. This is just another
place where having a uniform for way to listen for a single event
(which possibly already happened) would turn this into a simpler
problem.

Something like:

var globalScript = new webkitGlobalScript(name);

// ...time/flow control passes...

globalScript.onready(handler);

// ...time passes

globalScript.src = "";

// ...time passes, ready happens

// handler is called immediately on registration since future already arrived.
globalScript.onready(anotherHandler);

Regards

>> to have this:
>> > onerror=...>
>>
>> This actually displays one of the issues i have with global script as a
>> concept, you are basically just doing
>> 
>> And that gives you a context that achieves almost everything the global
>> script concept gives you.
>
> People keep saying that this is no better than a new window or an iframe
> because you can script those synchronously across pages, but that totally
> misses the point. The the frame/script/window survives when it's parent page
> is closed if there's another page pointing to it and, in some versions of
> this proposal, it survives same-origin page navigations. That isn't true of
> iframes or windows and is exactly what makes these useful.
> For the record, I'm on the fence about this idea, but it seems worth
> experimenting with if there are web pages that will follow through with
> using them, understanding that they're experimental APIs of course.
> Ojan
> ___
> 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] Implementation thoughts on HTML5 elements

[Alex Russell]

Lots of stuff on the web is best-effort, particularly when system
integration is the point. I'm not sure that saying "the experience
will be different" changes what semantics should be available to
authors in any way.

Regards

On Wed, Aug 26, 2009 at 3:25 PM, Peter Kasting wrote:
> On Wed, Aug 26, 2009 at 3:23 PM, Michelangelo De Simone 
> wrote:
>>
>> 2009/8/27 Peter Kasting :
>> > Consider that if the user uses a web mail app (e.g. Gmail) the UA will
>> > have
>> > no way of getting that data.  In fact, the UA may not even know what
>> > mail
>> > client the user prefers to use, especially if he uses several different
>> > ones.
>>
>> Implementing such functionality in a port-specific way may address
>> this
>
> My main point is that it's clearly not possible to offer an identical
> experience for all users in all UAs, so I can't see how a web author could
> be relying on such a thing, and thus I can't see how _not_ having it in the
> current WebKit implementation is somehow harming web authors.
> PK
> ___
> 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] Implementation thoughts on HTML5 elements

[Alex Russell]

On Wed, Aug 26, 2009 at 10:47 AM, Ojan Vafai wrote:
> On Tue, Aug 25, 2009 at 11:45 PM, Maciej Stachowiak  wrote:
>>
>> On Aug 25, 2009, at 11:21 PM, Maciej Stachowiak wrote:
>>
>> Hi everyone,
>> Recently at Apple we've been considering our plans to implement new HTML
>> elements from HTML5. I'd like to share our thoughts with the WebKit
>> community and see if we are in sync before passing this on to the HTML
>> Working Group. Does anyone have thoughts to add to the below:
>> --
>>
>> I realized I forgot to cover  and .
>> - 
>>   The list form of a menu seems straightforward enough, it is good to have
>> a list type specifically for popup menus. The toolbar form does not seem
>> fully baked. First, it seems weird to think of a toolbar as a kind of menu.
>> Second, the rendering is too inflexible and underspecified for the real Web
>> content authoring use cases for toolbars. And finally, an important point of
>> toolbars in many applications is that they can embed custom controls in a
>> flexible layout that also includes some standard buttons, but > type="toolbar"> does not seem flexible enough to handle this. The context
>> menu form does seem genuinely useful. But it also seems like a lot of
>> complexity for the somewhat marginal case of overriding the context menu. It
>> seems like about a dozen different elements are allowed, all with different
>> processing requirements. This seems like overkill for the use case of a
>> context menu. It doesn't even make much semantic sense for a context menu to
>> contain a button. Overall, it doesn't seem like the cases of menu list,
>> toolbar and context menu really share enough behavior or appropriate content
>> model to make them use the same element.
>> - 
>>   It's unclear if this element is worth having without the use cases for
>> toolbars or menus, and it also has 0 implementations so far and seems like
>> it might not be fully baked.
>
> While I don't disagree, I'm a little sad to see these not move forward in
> some form. JS libraries currently use a ridiculous amount of code to create
> simple flexible toolbars and menus that are keyboard accessible. Would be
> nice if someone with experience here (looking at you Hyatt) could chime in
> on whatwg with what a better design would look like so progress can be made.

+1.

Menus (menu strips, lists, what have you) and toolbars that share
keyboard accelerators are a huge burden today, particularly in
rich-text editing where focus constraints mean that in order to
implement a11y for toolbars, you need to do lots of magical
focus/selection saving in order to service the ad-hoc toolbar for
things like keyboard navigation. Even if WebKit decides against the
current HTML 5 spec for this stuff, having a toolbar and menu system
that's sufficient for implementing the states needed for a rich text
editor (think drop-down menus from a toolbar, toggle-buttons
corresponding to style application, button-sets for multiple state
toggles, e.g. alignment, etc.) would go a very long way to making a
lot of UIs load faster and suck less (since, hopefully, a
browser-provided UI would remove the ad-hoc nature of much of these
UIs).

Regards
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

[webkit-dev] parallel layout research

[Alex Russell]

After a discussion this morning about the potential for parallel CSS
layout with Erik Aarvidson, he pointed out a group at Berkeley doing
research in this area:

http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/

The bits that jumped out to me were:

   * the source is available [0]
   * they've implemented an abstract language for describing the CSS
spec for parameterizing layout. It reminds me a lot of the work Badros
did circa 2000 [1]. They suggest that this model does layout of the
CSS 2.1 spec in time similar to the hand-tuned sequential engine in
Gecko [2]
   * using Cilk++ to handle low-level paralleism, they've seen
significant speedups beyond that for multi-core [2]

It's exciting to me to see this kind of parallelism being extracted
from CSS layout operations, which have shown up in profiling of Google
apps as a serious bottleneck. I hesitate to ask about the WebKit
community's interest in this since I assume that if patches show up
and can prove their value, they'll be accepted, but I would like to
know where people are either supportive or skeptical about such an
approach.

Regards

[0]: http://code.google.com/p/pbrowser/source/browse/#svn/trunk
[1]: http://www.badros.com/greg/papers/gjbadros-dissertation.pdf
[2]: 
http://www.eecs.berkeley.edu/~lmeyerov/projects/pbrowser/retreatwinter2009/playout.pdf
, slide #19
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Re: [webkit-dev] Need help in understanding how webkit handles clicks event

[Alex Russell]

The PDF handling stuff is related to a mimetype filter. The web server  
sends a particular mime type along with each document, and if it's not  
something that the browser knows how to deal with directly, it'll  
interrogate all of its plugins to see if they want to handle it. When  
plugins are registered they provide a list of types they'll handle. See:



http://developer.apple.com/DOCUMENTATION/InternetWeb/Conceptual/WebKit_PluginProgTopic/Concepts/AboutPlugins.html

And:

http://trac.webkit.org/browser/trunk/WebCore/plugins

Regards

On Jan 28, 2009, at 5:25 PM, Meryl Silverburgh wrote:


Hi,

Can you please how webkit handles a mouse click from a user?
For example, when user clicks an anchor, it will load the web page.
But if the links points to  a pdf document, it will load the document
using pdf reader.

Can you please tell me where in the code handles that?


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev