Of course. But the user would need to know how to tag it, and then there would be nothing in the interface but an empty box. Another issue would be that if they assigned custom attributes to the text area (type and appearance settings), they would have to assign those manually in the html enclosed in the widget.
I thought you were looking for something available from the interface to avoid that.
My thinking is you would point the data source via nav services to an external file, and show its content in the interface for preview. Then when an export was done, you swap that out for the include command and a relative path for the file source. Since the call to PHP is within a text container, it would inherit any class/style info assigned to it.
It is not something I need or want, I was just thinking out loud. If I needed it for anything I would just assign some placeholder text like the relative file path in the Blocs text container, and use textfactories to search and replace that with the PHP after export. I may in fact do something like this in the future as the one bitch about some CMS is if I have to post changes to say a Cushy’d site by uploading a new Blocs export, I overwrite their current edits.
BUT… to reconsider the original request from @Ian, I discovered when doing my little test that my host has allow_url_include turned off in its PHP config for security reasons, and am assuming most other hosts would be configured similarly. This means that pointing to data on another site would not be possible… so in this context the whole thing is a bit moot. (c;