Can we do more with img tags?

mykael

Not sure if this is the right place to request new features.

Any chance of getting a couple of tweeks to the img tag into 1.4.2 or 1.4.3?

First one would be to support a variable name that holds the name of the image to show.

At present you have to code:

<<set $current to "forest">>

<<if $current is "forest">>[img[forest]]<<endif>>
<<if $current is "lake">>[img[lake]]<<endif>>

Be a lot nicer if I could just code:

<<set $current to "forest">>

[img[$current]]

Second thing is image maps.  Each would be an array of regions in the image, each associated with a link (and, maybe, a tail).

Syntax might be:

<< set $map to [ { shape: { "rect", top, left, bottom, right }, link: "forest", tail: '$link to "track"' },
{ shape: { "rect", top, left, bottom, right }, link: "lake", tail: '$link to "boat"' }
] >>

[img[areamap][$map]]

Where they click on the image determines which link, if any, gets activated.

Dazakiwi38

+ 1 to these ideas. I think it would be great if you could have clickable regions in images, you could examine objects within an image of a scene for clues. What would also be nice to include with clickable regions is popup bubbles as another option instead of linking to another passage. The popup bubble could be a mere sentence or paragraph. 

You could have an image scene where there are characters which you can click on one and interview (if playing as a a detective for example) the passage for the conversation with that character could have a closeup of that character and play out the conversation before going back to the previous passage and click on another character etc.

These same popup bubbles could be also used with the image to display a speech or thought bubble like a comic or graphic novel. These bubbles could have an opacity value to help blend in. But maybe the speech bubble popup might be too tricky to implement. Just a thought.

Sharpe

Is this what you're seeking with your first suggestion? I've been using it for several months now.

<<set $current = "[img[forest]]">>

<<print $current>>

L

I've implemented the first suggestion in 1.4.2.

L

I feel like one of Twine's current irks is that there's currently no real connection between HTML structures like <a> and Twine internal links or internal references. There's no way to express

So, I'm thinking of adding a "passage" attribute that you can put on HTML <a>, <img>, <map> and <area> tags.


<a passage="Distant woods">Some text</a>


would be equivalent to [[Some text|Distant woods]], but with the advantage that extra attributes can also be included.

So would


<img passage="Trees">


be equivalent to [img[Trees]].

What this means is that complex structures like image maps can be created through HTML, and Twine passage hyperlinks can then be added quite simply.

Note that the passage attribute would NOT appear in the rendered HTML element - it would be dynamically replaced with the code and event handlers used by normal Twine links.

mykael

Nice. Pretty simple to understand and gets us a lot of bang for your buck ;-)

L

L wrote:

I feel like one of Twine's current irks is that there's currently no real connection between HTML structures like <a> and Twine internal links or internal references. There's no way to express

So, I'm thinking of adding a "passage" attribute that you can put on HTML <a>, <img>, <map> and <area> tags.


<a passage="Distant woods">Some text</a>


would be equivalent to [[Some text|Distant woods]], but with the advantage that extra attributes can also be included.

So would

<img passage="Trees">


be equivalent to [img[Trees]].

What this means is that complex structures like image maps can be created through HTML, and Twine passage hyperlinks can then be added quite simply.

Note that the passage attribute would NOT appear in the rendered HTML element - it would be dynamically replaced with the code and event handlers used by normal Twine links.

OK, I've implemented this, with two changes:

1) Images now use "imgpassage" to source imported images, so that they can also link to a passage on click:

<img imgpassage="Tree" passage="Go to tree">

2) The "passage" and "imgpassage" attributes DO appear on the rendered HTML element, because some built-in CSS necessary to get the hand cursor working is required.

mth

L wrote:

1) Images now use "imgpassage" to source imported images, so that they can also link to a passage on click:

<img imgpassage="Tree" passage="Go to tree">

Does an image passage do anything besides generating a data URL? If not, you could create a more generic mechanism by having the user insert placeholder URLs which are replaced by data URLs on compilation:

[[<img src="passage:Tree">|Go to tree]]

An advantage of this kind of URL replacement is that it would work for any type of embedded data, such as fonts or audio.

greyelf

Do these new element attributes end up in the HTML generated (via the Twine Build option) as passage and imgpassage?

And if they do, should the attribute names not be preceded by "data-"?

TheMadExile

L wrote:

1) Images now use "imgpassage" to source imported images, so that they can also link to a passage on click:

<img imgpassage="Tree" passage="Go to tree">

Why would do that, rather than:

<a passage="Go to tree"><img imgpassage="Tree"></a>

In which case you wouldn't need "imgpassage" and could simply use "passage":

<a passage="Go to tree"><img passage="Tree"></a>

L wrote:

2) The "passage" and "imgpassage" attributes DO appear on the rendered HTML element, because some built-in CSS necessary to get the hand cursor working is required.

As brought up by greyelf, I'd suggest transforming those into data-* attributes.

L

TheMadExile wrote:

L wrote:

1) Images now use "imgpassage" to source imported images, so that they can also link to a passage on click:

<img imgpassage="Tree" passage="Go to tree">

Why would do that, rather than:

<a passage="Go to tree"><img imgpassage="Tree"></a>

In which case you wouldn't need "imgpassage" and could simply use "passage":
<a passage="Go to tree"><img passage="Tree"></a>

I guess the reason is that I like a 1-to-1 relation between HTML attributes and Twine functionality: "passage" maps 1-to-1 with linking, and "imgpassage" maps 1-to-1 with image sourcing. But, maybe it'd be a smidge simpler if just one was present.

TheMadExile wrote:

L wrote:

2) The "passage" and "imgpassage" attributes DO appear on the rendered HTML element, because some built-in CSS necessary to get the hand cursor working is required.

As brought up by greyelf, I'd suggest transforming those into data-* attributes.

Well, OK then - although I think the extra 5 characters are something of a usability hit, these attribute(s) are only intended as "last resort" fallbacks when the normal syntax is insufficient, so it isn't that important.

So, just one "data-passage" attribute it is, then.

mth wrote:

L wrote:

1) Images now use "imgpassage" to source imported images, so that they can also link to a passage on click:

<img imgpassage="Tree" passage="Go to tree">

Does an image passage do anything besides generating a data URL? If not, you could create a more generic mechanism by having the user insert placeholder URLs which are replaced by data URLs on compilation:

[[<img src="passage:Tree">|Go to tree]]

An advantage of this kind of URL replacement is that it would work for any type of embedded data, such as fonts or audio.

I thought about this, but I don't really like the look of "src='passage:Tree'" - it feels like there's one layer of indirection. And, I prefer having a separate HTML attribute on the (admittedly dubious) basis that someone could CSS-select the attribute (and they couldn't with that URI because it'd be substituted at runtime).

TheMadExile

L wrote:

TheMadExile wrote:

L wrote:

2) The "passage" and "imgpassage" attributes DO appear on the rendered HTML element, because some built-in CSS necessary to get the hand cursor working is required.

As brought up by greyelf, I'd suggest transforming those into data-* attributes.

Well, OK then - although I think the extra 5 characters are something of a usability hit, these attribute(s) are only intended as "last resort" fallbacks when the normal syntax is insufficient, so it isn't that important.

So, just one "data-passage" attribute it is, then.

I think we've had a misunderstanding.  I was not suggesting that the actual syntax be data-passage.  I was suggesting that as part of processing the passage attribute, it be replaced with the data-passage attribute.

For example: (this is how it's currently implemented in my local SugarCube repo)

This author code:


<a passage="Go to tree"><img passage="Tree"></a>


Would be transformed into: (notionally, that's not actually how the click event is attached)


<a data-passage="Go to tree" onclick=""><img data-passage="Tree" src=""></a>


IOW, using the non-standard passage attribute on the author-side HTML elements is fine, however, don't pass it through to the output as-is.  If having source of the passage attribute in the output is desirable (and I believe it is), then add a copy prefixed with data- and remove the original.

L

TheMadExile wrote:

I think we've had a misunderstanding.  I was not suggesting that the actual syntax be data-passage.  I was suggesting that as part of processing the passage attribute, it be replaced with the data-passage attribute.

I have some deep-seated reluctance to modifying the user's given HTML any more so than required, even for just one attribute. I take the position that anyone who adds raw HTML should have a guarantee that it'll remain as-is to the greatest extent. I admit it's quite unlikely that people would actually CSS-select a custom-inserted HTML attribute, or write a script that selects the thing using the attribute selector "[passage=...]", but I don't want to trip people up in the event that does happen.

(As currently implemented, the only DOM changes data-passage invokes are to change the src of <img>s, and alter the onclick of non-imgs (but I'm changing it to use addEventListener/attachEvent now).)

TheMadExile

Coming back to this, I decided to add a few extra bits to SugarCube's implementation.