Basic functionality of a new Parchment IO system
Dannii
system? Images? More font control? Tell me!
DanMonroe
Just to let you know that we are still out here reading and thanks for
keeping this up.
There are a few additions that I would welcome. Here are a couple
that I can remember right now and I'm sure there are some that I am
forgetting from me work a few months ago. Forgive my lack of correct
terms for the "IF game"
Remove all the specific CSS style settings from the code and use CSS
classes instead. Let the visual implementation be done in the css
style sheet instead of the code.
Hooks to be able to call javascript functions and insert DIVs with
specific css classes from the IF game. i.e, drive manipulation of the
DOM from user actions in the game. I can use this to display the
images.
Hooks to easily (or more clearly) interject commands from javascript
into the IF game to be parsed by the game engine.
I'm sure there are more, but there is my brain dump at the moment from
my pre-cofffee state of mind.
Dan
Dannii
Having story files run arbitrary Javascript does present a potential
security risk. Atul, any ideas there? Perhaps we could simply ask the
user if they are ok with running the scripts.
What you've suggested does in fact line up closely with my grand dream
for a new webby IO system. At the moment though I don't want to do a
full implementation like that, nor do I want to focus on the final
protocol/format or zcode/glulx/I6 implementation. I want to implement
a few things in I7 which we can test out. Then later on we can change
how the backend works, while keeping the front end the same.
Atul Varma
The current hosting-place for Parchment doesn't actually have anything that malicious JS code could take advantage of, other than whatever state Parchment itself keeps track of, so I wouldn't expect it to matter much until/unless we actually bring identity or other things into the app.
Another option is to use things like Content Security Policy [1] to ensure that JS can only do certain things.
- Atul
[1] http://people.mozilla.org/~bsterne/content-security-policy/
--
You received this message because you are subscribed to the Google Groups "Parchment" group.
To post to this group, send email to parc...@googlegroups.com.
To unsubscribe from this group, send email to parchment+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/parchment?hl=en.
weevil
Basic image support, inline images or an image window that can have
its background swapped by prompts in the story.
keep style separated from content, i.e. in css rather than in
javascript.
As far as glulx support goes. I think the problem is not with
parchment, but with inform 7. It would be great to optimise inform 7
code somehow so that it doesn't depend on glulx just over issues of
game size. It seems like glulx was created to handle complicated
variations in UI, but it ends up being a crutch to support bloated
story files over issues of size alone.
> > parchment+...@googlegroups.com<parchment%2Bunsubscribe@googlegroups .com>
Dannii
> My wish list is-
> Basic image support, inline images or an image window that can have
> its background swapped by prompts in the story.
> keep style separated from content, i.e. in css rather than in
> javascript.
>
> As far as glulx support goes. I think the problem is not with
> parchment, but with inform 7. It would be great to optimise inform 7
> code somehow so that it doesn't depend on glulx just over issues of
> game size. It seems like glulx was created to handle complicated
> variations in UI, but it ends up being a crutch to support bloated
> story files over issues of size alone.
Thanks weevil!
I think your wish list is what I had in mind.
As for glulx... well I think there are definite improvements to be
made in both file size and speed. I've had ideas about redoing the
rulebooks code for example. If Graham ever shares the ni source with
me I'll see what I can do.