Event Data

event(field) reads data of the current event inside a mutation: where a press happened, which key was pressed, what a field contains. Fields are checked against the trigger at compile time.

event(field)

event(field) gives one value from the event that is running the rule: a pointer position, a key, a field’s value. It is valid only inside a mutation of an :on() rule.

.pad {  --x: state(0px);  --y: state(0px);}.pad:on(pointerdown) {  --x: set(event(local-x));  --y: set(event(local-y));}

.pad {  --x: state(0px);  --y: state(0px);  --key: state("none");}/* A snapshot of where the press happened, relative to the pad. */.pad:on(pointerdown) {  --x: set(event(local-x));  --y: set(event(local-y));}/* Keyboard fields exist only for keyboard triggers. */.pad:on(keydown) {  --key: set(event(key));}.pad .dot { translate: var(--x) var(--y); }.pad .x { content: var(--x); }.pad .y { content: var(--y); }.pad .k { content: var(--key); }

• A snapshot. The value is copied when the event happens. The state keeps it until the next mutation; nothing follows the pointer afterwards.
• A closed list. event() reads the fields listed below, nothing else. It is not access to the JavaScript Event object: no methods, no other properties, no script.
• Checked against the trigger. Each field belongs to a category, and the trigger decides which categories exist. event(key) in an :on(click) rule is a compile error that lists the fields click provides.
• Only in mutations. Anywhere else, event() is a compile error, because there is no event there.

Reference: event().

Fields

Lengths are in CSS px. A field the event does not carry writes nothing: the mutation is skipped, never set to NaN or an empty value.

General

Pointer

Pointer events here are click, contextmenu, pointerdown, pointerup, pointermove, pointerenter, pointerleave, pointercancel, outside(click) and outside(pointerdown). Mouse events are dblclick, mousedown, mouseup, mousemove, mouseenter and mouseleave; they have no pointer-id, pressure or pointer-type. When a browser delivers click as a plain MouseEvent, those three fields write nothing.

.map {  --pin-x: state(0px);  --pin-y: state(0px);  --input: state("none");}.map:on(click) {  --pin-x: set(event(local-x));  --pin-y: set(event(local-y));}/* "mouse", "pen" or "touch": style per input type with :when(). */.map:on(pointerdown) {  --input: set(event(pointer-type));}

Keyboard

.field-help {  --last: state("");}.field-help:on(keydown) {  --last: set(event(key));}

Form

The control is event.target, and it must be an input, select or textarea; otherwise the field writes nothing. Password, one-time-code and payment fields (autocomplete="cc-…") always give "" for value, and nothing for value-as-number, so a stylesheet can never read what is typed into them.

.search {  --query: state("");  --limit: state(10);}.search input[type=search]:on(input) {  --query: set(event(value));}.search input[type=number]:on(change) {  --limit: set(event(value-as-number));}

To keep a control and its own state equal in both directions, use state("", bind(value)) instead: see Data Binding.

Drag

Experimental. Available in drag triggers only.

The pointer fields above are available too; local-x and local-y are relative to the element’s box at drag start.

.card {  --x: state(0px);  translate: var(--x) 0;  touch-action: none;}.card:on(drag) {  --x: set(event(x));}

Scroll

.feed {  --top: state(0px);  overflow: auto;}.feed:on(scrollend) {  --top: set(event(scroll-top));}

Focus, submit, reset, animation, transition and toggle triggers provide type only.

Elements involved

Three elements can take part in one event:

.list {  --picked: state("");}.list li:on(click) {  --picked: set(attr(data-id));}

A click on a <span> inside an <li> has the span as event.target. The rule element is the <li>, so attr(data-id) reads the <li>’s attribute, and the value is stored in .list’s --picked.

Snapshots at the event

Inside a mutation, these functions are evaluated once, when the event happens. Outside mutations they keep their usual behavior.

So event(client-x), mouse(x), element(width) and attr(data-id) answer different questions:

• event(client-x) is a field of this event, checked against the trigger;
• mouse(x) in a mutation is the same number. Outside a mutation it is a subscription to the pointer, re-evaluated as it moves;
• element(width) measures the rule element, not the event;
• attr(data-id) reads the rule element’s markup, whatever the event was.

.dice {  --roll: state(1);}/* A new number at each click. random(min, max, step) and by step both work here. */.dice:on(click) {  --roll: set(random(1, 6, 1));}

Stability

The pointer, keyboard and form fields are recommended as stable for 0.9.0. The drag fields are experimental, like drag gestures, until they are validated on real touch and pen hardware.

Related