HyperTalk used identifiers like field and button to locate screen elements for later use, using a string to match the element ID or NAME. I see several benefits to adding this:
It makes code a little more explicit, because we can label what kind of element we're looking for.
In the case of field (and possibly button) we could fall back to searching by the element name=""
It allows us to use variables to identify DOM elements cleanly without a lot of magic characters: I'm looking at you, <#${dude}/>
How it Should Look
set field "MyField" to "123"
send click to button "MyButton"
add .className to tag "MyTag"
This syntax would work great with variables that name the field/button/tag instead of hard-coding tag names
set field VariableThatContainsAFieldName to "boo-ya"
tell novelist SelectorVariable remove me
Identifier
Result
tag
returns the first tag whose ID that matches the provided string
button
returns the first button whose ID (or NAME?) matches the provided string
field
returns the first input, select-box, or textarea whose ID or NAME matches the provided string (special handling for checkboxes and radio buttons
nodelist
returns a NodeList (array) of elements that match the provided selector. (Similar to < /> but works with a string variable
1cg
commented
3 years ago
HyperTalk used identifiers like
fieldandbuttonto locate screen elements for later use, using a string to match the element ID or NAME. I see several benefits to adding this:name=""<#${dude}/>How it Should Look
This syntax would work great with variables that name the field/button/tag instead of hard-coding tag names
< />but works with a string variable