HTML: Bug when using dropshadows with mouseovers

**Charles Moir** · 27 April 2008, 09:03 PM

IOW: The updated area of the original object is also updating another object.

No it's not. The button includes its shadow and so it's only updating the area of the original button+shadow.

Attached a .xar file that shows a working example, where the shadows have been separated from the buttons and put behind as described above.

**steve.ledger** · 27 April 2008, 09:12 PM

Cheers Charles, that works fine.
Though in the back of my mind there's a small question as to why applied object shadows cannot be processed this way 'on export' by the filter <evil grin emot'>

Yes my comment ought to have read:
IOW: The updated area of the original object *appears* to be updating another object.

**steve.ledger** · 27 April 2008, 09:16 PM

PS: Any thoughts as to why the alt= and title= attributes work perfectly fine when there is no URL, but as soon as the (image) object includes an URL, alt= and title= attributes fail to work (inspite of being present in the source). ?

update.
hmmm - I just tried reproducing this in a new file and cannot??. Yet the site I'm working on simply doesn't show either attribute as a tip on hover in any browser inspite of the source showing them applied the same way as the test file I just created.. I may have to remove them completey and start over, I only noticed this bug after moving them about the page while designing the layout, something may have broken..

**covoxer** · 28 April 2008, 05:07 PM

Originally Posted by sledger

But though padding is a work around, the point is, it's NOT a WYSIWYG result.

Correct. The rollover and pop-up effects are not WYSIWYG - you don't see them just as you get them. The WYSIWYG statement is true for the design, which active elements are not part of, sine Xtreme does not posses instruments to implement active content.

**covoxer** · 28 April 2008, 05:14 PM

Originally Posted by sledger

PS: Any thoughts as to why the alt= and title= attributes work perfectly fine when there is no URL, but as soon as the (image) object includes an URL, alt= and title= attributes fail to work (inspite of being present in the source). ?

One possible reason is that if you have a group, the name containing title= or alt= has to be added to the group. Names of the objects within the group are ignored.

**steve.ledger** · 28 April 2008, 07:31 PM

Originally Posted by covoxer

Correct. The rollover and pop-up effects are not WYSIWYG - you don't see them just as you get them. The WYSIWYG statement is true for the design, which active elements are not part of, sine Xtreme does not posses instruments to implement active content.

Well of course John

What I'm referring to as not being WYSIWYG is not the popping up action, but the appearance of the objects 'after' the action.
(the to be pedantic, I can see this action in Xtreme by clicking the mouseover layer on/off quickly to visually confirm positioning

)

Originally Posted by covoxer

One possible reason is that if you have a group, the name containing title= or alt= has to be added to the group. Names of the objects within the group are ignored.

Nup - items were either not a group, or had the attributes applied to a group 'after' they were grouped.
In my tests it seems random, and more likely to happen as the documents grows in complexity.

I'm also coming across other mouseover problems whereby the results are displaced severly on the exported html page and are always visible instead of only showing onhover. Again, this appears to only happen once the document grows in complexity.

**covoxer** · 29 April 2008, 08:33 AM

Well of course John What I'm referring to as not being WYSIWYG is not the popping up action, but the appearance of the objects 'after' the action.

Sorry, no. There's no "action" concept in Xtreme, so it can't tell or show you anything that's a result of the action. All we do with effect layers etc is an emulation of such a tool, not more. So it's not really WYSIWYG. You can't actually see the cropped part of the mouseover layer as it will appear in case of mouseover event for the particular object in the browser.

As I say, the static design is WYSIWYG. All other HTML filter specific features achieved by setting special values to the web address or name attributes are meaningless to Xtreme, so they are not WYSISYG.

(the to be pedantic, I can see this action in Xtreme by clicking the mouseover layer on/off quickly to visually confirm positioning )

Precisely - but that absolutely not what you'll get on export since mouseover layer is cropped by the script, and you miss this that part.

**steve.ledger** · 29 April 2008, 11:08 AM

Thanks John, we're getting cross wired a bit with my choice of words

I'll find work arounds to arrive at the results I'm seeking.

**snicho** · 03 May 2008, 09:04 AM

Steve,

I'm also seeing exported popup objects positioned incorrectly as pages become more complex.

I placed some text and a surrounding filled rectangle (as a background to the text) on a popup layer. That worked fine in the first instance, but repeating this on the same page multiple times resulted in all the text popups being positioned correctly, but their associated background rectangles were shifted down the page.

The results were the same whether the rectangles and text were grouped or individual objects on the popup layers.

For now, my workaround has been to put a single background rectangle on the main layer and just have the text popup in front of it.

The result is not a nice from a design aspect, but it will have to do for now.

Steve