Yeah, that page’s .css import is broken (404). The page should look more like this: http://www.macosxautomation.com/applescript/firsttutorial/02.html http://ww

Yeah, that page’s .css import is broken (404). The page should look more like this: http://www.macosxautomation.com/applescript/firsttutorial/02.html http://www.macosxautomation.com/applescript/firsttutorial/02... That site is Sal Soghoian’s, and my own opinion of the man’s work and his ability to accept criticism is well known. Still, if you can find a way to give him a heads-up his CSS is broken (and probably has been for a decade), crack on. I think even he’ll concede and hopefully thank you for drawing it to his attention. … The other thing I’ll say about that particular page is that GUI Scripting is absolutely the worst of the worst, the “Bad Automation” approach to be used only when an app doesn’t provide an “AppleScript” (Apple event IPC) interface of its own. With GUI Scripting, your script is literally mimicking the interactions of a human user: pushing buttons, reading and typing text in text boxes. This is far from optimal when talking program-to-program. The whole point of a GUI View layer is to present the data held in the app’s Model layer in a format that is easy for human users to visually read and write with keyboard and mouse. Conversely, an “AppleScript” View layer presents the same Model data in a format that is easy for other programs to automate. The data is presented as a queryable tree of “objects” (an Apple Event Object Model), with a set of standard commands for manipulating those nodes. Sal’s tutorial pages I linked to above describe the “Good Automation” which AppleScript is rightly known for. It’s actually a pretty awesome API and the [few] developers who genuinely “get it” genuinely love it too. Way more REST-ful than what most webapps today call “REST APIs”[1], a powerful, elegant, and very high-level user-queryable abstraction (it’s closest to SQL, *not* OOP). You can find my own (now very old) attempt to explain its conceptual model to programmers at: https://appscript.sourceforge.io/py-appscript/doc/appscript-manual/02_aboutappscripting.html https://appscript.sourceforge.io/py-appscript/doc/appscript-... Not a great explanation, but still way better than Apple’s. Someone else also linked Dr William Cook’s AppleScript paper up-thread, which is a must-read for understanding these principles. … Alas, for historical reasons Apple events and AEOM got shackled to AppleScript early on. And while AppleScript speaks Apple events flawlessly, as a general scripting language it is horrible obfuscated crap. But the app-to-app IPC that sits underneath is [when it works right] damned awesome. -- [1] “REST API” is an oxymoron: REST describes how “REST-ful” apps’ *UI/UX* should universally behave at a high-level. How the interface should look and feel to its users, regardless of whether a given user is a machine or a human; not list low-level procedure calls and arguments. Like HTTP, Apple events suffered terminally weak, unhelpful, incomplete early documentation, and all the misconceptions and dysfunctional implementations subsequently arose from that. Fielding’s thesis should’ve been the web’s equivalent to Apple’s Human Interface Guidelines, but was published a decade too late to have any influence, and lacking good and bad working examples of real-world design for non-academic readers to follow/avoid. Likewise, Apple didn’t publish its Scripting Interface Guidelines (https://developer.apple.com/library/archive/technotes/tn2002/tn2106.html https://developer.apple.com/library/archive/technotes/tn2002...) until over a decade after AppleScript’s release.