Re: beforescroll as the "intention" contract for scrolling

On Fri, Sep 26, 2014 at 2:06 PM, Ben Peters <Ben.Peters@microsoft.com>
wrote:

>  Hi Rick! It sounds like you would be a great asset to have for our
> Intentions conversations! The purpose of the Intentions Explainer is to
> bring together known and future Intention-style events so that developers
> have a consistent experience. Extensibility is very much a goal (maybe I
> should make that clearer in the doc), and composition is something that has
> crossed my mind but I don’t currently have a firm handle on. It would be
> very valuable to have your contribution on the subject. Further, scrolling
> is not something that we currently have an expert for, so having help there
> would also be great.
>

Sure, I'm happy to provide advice where I can.  My focus is primarily
touchscreen input though, so I might not have a lot of input on the
editing-specific pieces.

We have just added a meeting to discuss these subjects at TPAC on Monday
> between 15-16:00. Are you (or someone else on your team) going to be there
> so you can join our conversation?
>
>
Yes, I'm planning on being there Mon-Wed - I'm happy to attend.

I have been working with Julie Parent on the editing side at Google, and I
> understand that Kenji Baheux just took over the area from her. If you have
> more contacts that might be interested at Google (browsers, sites,
> frameworks), that would be great too- send them over to join our list!
>

Kenji (and his editing team in Tokyo) is the person I was thinking of.

See you soon!
   Rick



>   *From:* rbyers@google.com [mailto:rbyers@google.com] *On Behalf Of *Rick
> Byers
> *Sent:* Tuesday, September 23, 2014 2:00 PM
> *To:* public-editing-tf@w3.org
> *Cc:* Timothy Dresser
> *Subject:* beforescroll as the "intention" contract for scrolling
>
>
>
> Hi,
>
> I just read your explainer
> <http://w3c.github.io/editing-explainer/commands-explainer.html>, and
> although I don't have much context on editing in particular, the high level
> concepts really resonated with me.  We (blink input team) have been
> struggling with related problems around input for awhile and now have a
> proposal
> <https://docs.google.com/a/chromium.org/document/d/1oEVWIVdMZ2OlVZMvcZZ3IgaT6RAUNSKAzpzb9AlVeLw/edit#heading=h.kd0gtwwz5bf9> which
> we're pretty excited about.
>
>
>
> Our 'beforescroll' event corresponds exactly to your definition of an
> 'intention' for scrolling.  However our motivation is pretty different from
> what you describe as: "... several issues including difficultly
> understanding what a user intends, complexity in building Accessible sites,
> and complex localization".  These are probably problems for scrolling too,
> but the bigger problems in our mind are around composition and
> extensibility.  Without a contract for the intention, components that
> transform behavior into actions can't compose properly with each other.  In
> the context of scrolling, this means it's impossible for JavaScript to
> customize scrolling because they'd have to re-implement everything
> themselves and there's no API exposed for some browser behavior so no way
> to compose with it. By defining a contract for mediating composition (the
> event that defines the intention), we enable customization of actions
> (custom generators of the event) and customization of behavior (custom
> consumers of the event) independently in a way that composes properly with
> other actions and behaviors for the same intention.  We see this as an
> important step towards a more extensible web
> <http://extensiblewebmanifesto.org> (cleanly dividing the platform into a
> kernel of core primitives and a framework layer of optional components
> built on top of those primitives).  If the abstraction also enables better
> accessibility, understandability and localization too then that's great too.
>
>
>
> Although it's not really my area of expertise, I think we also have
> composition/extensibility problems with text editing in blink as well.  Eg.
> how is a rich custom editor like Google Docs (which manages text layout and
> selection itself in JS) supposed to properly integrate with the text
> editing facilities of a touch-centric browser?  What if you want to build
> an editor which does all it's rendering using canvas or WebGL instead of
> DOM?  As you work on the appropriate "intention" APIs for text editing, I'd
> urge you to consider how it can make the platform more easily extensible -
> breaking down what today are monolithic "magic" browser features into
> components that can be used or replaced individually according to the needs
> of the app.  If this is a direction you're interested in and would like
> involvement from the blink team, I can try to find the right people to get
> involved - this is directly relevant to blink's high-level mission of
> making the web more competitive with native mobile platforms.
>
>
>
> Thoughts?
>
>   Rick
>