Selecting Events with Style

AdamSobieski commented 1 year ago

What problem are you trying to solve?

How can criteria for filtering event streams and related program logic be made portable between clients and servers?

If able to transmit these criteria and related program logic between computers, fewer events would need be to be sent in event streams.

What solutions exist today?

Web developers often use JavaScript to filter DOM events and HTML server-sent events. For example:

const sse = new EventSource("/api/v1/sse");

sse.addEventListener("notice", (e) => {
  console.log(e.data);
});

sse.addEventListener("update", (e) => {
  console.log(e.data);
});

At the WICG, there is also an Observable API under development. Here is an API example:

element.on('click')
  .filter(e => e.target.matches('.foo'))
  .map(e => ({x: e.clientX, y: e.clientY }))
  .subscribe({next: handleClickAtPoint});

The DOM interface for events is Event and the HTML interface for server-sent events is EventSource.

Comparable models of events and event streams include XES, OCEL, xAPI, and Caliper.

Software libraries for reactive programming and event stream processing are myriad; some are listed here.

In .NET, there is an interface IQbservable<T> which enables client-side event-stream queries to be constructed in such a way that resultant queries can be processed server-side.

Event-stream querying languages include, but are not limited to: Stream Analytics Query Language, StreamSQL, Kafka KSQL, SQLStreams, SamzaSQL, and Storm SQL.

How would you solve it?

CSS is a Web Standard and Web developers are familiar with its syntax and semantics. Using CSS selectors, software developers could: (1) perform client-side or server-side event-stream filtering, and (2) transmit filtering criteria and related program logic between clients and servers. As CSS is modifiable at runtime via the CSSOM, event-stream filtering could be dynamic and responsive.

With respect to representing events, a number of non-mutually-exclusive options can be considered. Events could implement:

Types of events could be identified by URI's, having both a namespace URI and a local name. Events could have attributes. Events could have classes or categories, resembling the publish-subscribe pattern. Events could have arguments or data. In markup, these features, all together, might resemble:

<html:progressevent class="cls1 cls2" xmlns:html="http://www.w3.org/1999/xhtml">
  <data key1="value1" key2="value2" />
</html:progressevent>

With such an XML-based model of events, CSS-based selectors can be utilized.

A special-purpose CSS property, process, could be used for expressing whether a client wants to subscribe to a selected event.

.cls1:has(> [key1='value1']) { process: true; }

Alternatively, this special-purpose property could be multi-valued and utilized to indicate which event processors or JavaScript functions to route selected events to:

.cls1:has(> [key1='value1']) { process: function1 function2; }

For a concrete example, let us imagine a website which delivers real-time stock market data for visualization. There are roughly 2,400 companies traded on the New York Stock Exchange and there is far too much data to stream every update to every client for subsequent client-side filtering. As users dynamically select the stocks of interest to them, CSS filters could be created which describe the interesting events. These event selectors could be transmitted to servers so that users would need only receive those events interesting to them, the update events for those companies of interest to them.

<nyse:update xmlns:nyse="...">
  <data company="ABCD" value="12.34" time="12:34:56.78" />
</nyse:update>

and a corresponding CSS selector to select incoming updates for company ABCD might resemble:

nyse|update:has(> [company='ABCD']) { process: onupdate; }

The text for the CSS selector nyse|update:has(> [company='ABCD']) could be sent to the server, alongside other selectors, to indicate which events to send to the client, which companies' stock market data that the user wanted to instantaneously visualize.

Anything else?

Syntactic possibilities for CSS selectors could be explored with which to select events based on temporal patterns occurring in event streams.

Thank you.

annevk commented 1 year ago

Hey, please give https://whatwg.org/faq#adding-new-features a read and improve the problem description based on that.

AdamSobieski commented 1 year ago

@annevk, thank you. I enhanced the problem description. What do you think?

annevk commented 1 year ago

I think the problem description still very much assumes a particular solution. Ideally it would not talk about that at all and instead focus on something people cannot do right now that you would like to solve.

An alternative approach might be demonstrating through widespread library adoption and Stack Overflow questions that this is a pattern worth building into the web platform.

AdamSobieski commented 1 year ago

I think the problem description still very much assumes a particular solution. Ideally it would not talk about that at all and instead focus on something people cannot do right now that you would like to solve.

Ah, thank you for clarifying. I revised the problem description again.

emilio commented 12 months ago

Making CSS determine what JS function is going to execute is a big no-go IMO. You don't want to force style recalculation every time you need to read that process property.

AdamSobieski commented 12 months ago

In theory, stylesheets of event selectors, in the above cases CSS-based, would be runtime-compiled into functions which would invoke JavaScript functions as matching events were detected.

The goal is to be able to efficiently filter and process streams of incoming events. My thoughts for the CSS-based proposal are that most Web developers already understand CSS selectors syntax and the CSSOM. The hope is that it would be easier for Web developers to modify stylesheets, as needed, than to modify event-filtering logic in JavaScript files.

Also, selectors-based approaches would mean that filtering would be portable between clients and servers. Clients could update their filtering criteria, e.g., in response to users' UI gestures, and transmit updated selectors to servers.

Event-stream querying languages include, but are not limited to: Stream Analytics Query Language, StreamSQL, Kafka KSQL, SQLStreams, SamzaSQL, and Storm SQL.

Other possibilities include utilizing selectors from JSON querying languages, e.g., JSONiq and JQL.

From the JSONiq specification:

The main source of inspiration behind JSONiq is XQuery, which has been proven so far a successful and productive query language for semi-structured data (in particular XML). JSONiq borrowed a large numbers of ideas from XQuery, like the structure and semantics of a FLWOR construct, the functional aspect of the language, the semantics of comparisons in the face of data heterogeneity, the declarative, snapshot-based updates. However, unlike XQuery, JSON is not concerned with the peculiarities of XML, like mixed content, ordered children, the confusion between attributes and elements, the complexities of namespaces and QNames, or the complexities of XML Schema, and so on.

dead-claudia commented 4 days ago

That proposal could be easily extended to fire custom events based on CSS properties with something along the lines of @event { click: detail_expr; } that's active as long as its selector matches.

whatwg / dom