RE: Declarative invocation and progressing Web Intents

Dear Frederick,

Ok, I can start writing up use cases, and can write up some options for the declarative markup.

The issue that at I have the least clarity on is how it would work with the webpage presentation.  For example, would a webpage declare a 'share' intent and remove all social widgets leaving it to the web browser UI to invoke one, or would the webpage bind the invocation to a single button, or would you want to support separate buttons for specific social websites?

Would a webpage declare an 'advertisement viewing' intent that the web browser would invoke.  Could inline web apps implement embedded ads in declared areas of a page.  Can this be made to work for both full screen ad presentation on small screen devices and embedded presentation within content on devices with a larger screen.

For form input elements, would the UI be responsible for providing invocation buttons and cues, or would they be bound to buttons.  A file input element could naturally pop up suitable invocation choices, but for a group of input elements containing a contact and address would the web browser be responsible for providing a UI to invoke a web app to look up an address or would it be bound to a button webpage presentation.

The design choices might be directed by a desire to be able to markup 'web intents' on a webpages that do not include markup.  For example, offering 'web intent' choices for a file input element even if the webpage had not included markup to support this.   For example, adding a wikimedia rich editor invocation button to a textbox on a known webpage.  Should this be done via DOM changes, and if so should it be visible to the document script.  Should any web browser applied invocation opportunities be effectively chrome and not visible to the document.

Anyway, I'll write up some options and this process generally helps me clarify matters.   Feedback welcome.

cheers
Fred