(...and likely between many other browsers.)
I've just accidentaly noticed a little detail in the CSS:
Styles commented out with a double slash - // - are ignored by Firefox, but not by Explorer, which processes them. Styles hidden in /* */ are really hidden as they should be.
I wonder what the standards say on this. :)
---
Update on the onmousemove event: now I found out to be blamed is the image I have in the background. Under Explorer, if the mouse hovers over it, it will be the target for mouse events, even if there is a span hovering above it - Firefox uses the span. The visible borders always capture events (entertainingly enough, once you "grab" the border and start moving/resizing the span, Explorer accepts mouse events from all over the place... so there is obviously a bug.)
Now if you actually make the span contain something, Explorer will immediately consider the span as being more than just a few lines, and dutifully notes the events in the span. Duh.
An easy way to place something into a span that shall be completely transparent (what we work with is behind it), is to set the opacity on 1%, plus some background color. A small opacity won't be really noticed. (Unless you want to have visible borders on that span, which I wanted.)
Though I can't escape the thought that the browsers may be processing this information somewhere... calculating the effect anyway. Some other 'empty' effect would be nice.
Wednesday, June 6, 2007
Saturday, June 2, 2007
JavaScript Image Editor... sort of
At work, I am just making a sort of image editor in JavaScript. (What? Yes, really. In JavaScript.)
Of course it is not supposed to be a real image 'editor', it shall merely serve for 'cutting out' a fitting part of an existing image, then pass the parameters to another program on the server, which will do the cutting itself.
That's it, not very complicated, right?
Well, not with JavaScript. Moving a single layer (the selection over an image) and especially resizing it is quite tricky. Let's see a few hurdles:
- already getting the coordinates of something on a page isn't easy. Luckily there are well-tested functions to be found outside! I've got one from Quirksmode (a good resource to remember for web development, btw). The coordinates of a mouse are then simple.
- it got a bit more complicated, once I've started using absolute positioning, to actually have control over the 'editor'. In the end, I have used a separate object, that remembered the position and sizes of the resizing area; with every move or resize it was updated, its values used to change the resize layer.
- once you use the onmouseover event, your CPU load goes up, and if you fool around a little (moving the layer wildly around), it may jump up to 100%. I may not care, but this thing should eventually be used by the customers, who might not like the load. Also, if you try debugging (and you will need it), which you have to do in some textbox, everything will go _much_ slower. Be prepared for that.
- the actual calculations for moving and resizing something are so easy to break, and so hard to get right. Especially if you want the dingus to be resizable from all sides - up or down, left or right, doesn't matter. I have seen only one script that actually did this, and it worked in a horribly complicated way, with neat design but very ugly code. (Will add link to it.)
- additional fun was our special condition: we wanted the resulting image to be of a certain size in the end; what we selected could also have any size, but we could enlarge it or make smaller. But what I had to maintain, was the width-to-height ratio.
Developing at two browsers at once gets annoying; I rather kept testing with Firefox (blesseth be Firebug!) until it was somewhat stable, and then tried it with Explorer. Glad that you asked, there were some differences:
- the worst were the different names of the JavaScript objects that were desperately needed. How do you find out where the mouse came from or went to? I know it now (at least for the two browsers), but it took some annoying experimenting.
- Firefox apparently waited, until the image was loaded; Explorer didn't, and kept executing the code after the loading was requested - so an onload function had to be implemented for the image, that did all the initialization. But that was actually an improvement.
- pretty bad was Explorer's treatment of the mouseDown event. What worked well with Firefox, failed there. Turns out that it somehow refuses to fire the event, if the layer has only a border defined, and nothing else. But as soon as a background color is set, it works! That of course sucks, as the image in the background had to be visible. In the end, I have set up a large transparency for the resizing layer, and had both things... well, it isn't perfect. I'd like the border to be completely visible, and the transparency/opaqueness to be very gentle, so most of the picture stays visible. Still some work to do with this... or somehow bypass it. Duh.
Well, that's how it is starting, and much is to be done (the closing functionality that tests if the selection is correctly positioned isn't yet complete, so it can be broken), but the basics already work! Guess I will post some image a maybe even some of the code so it is clear what it actually does, and how.
Of course it is not supposed to be a real image 'editor', it shall merely serve for 'cutting out' a fitting part of an existing image, then pass the parameters to another program on the server, which will do the cutting itself.
That's it, not very complicated, right?
Well, not with JavaScript. Moving a single layer (the selection over an image) and especially resizing it is quite tricky. Let's see a few hurdles:
- already getting the coordinates of something on a page isn't easy. Luckily there are well-tested functions to be found outside! I've got one from Quirksmode (a good resource to remember for web development, btw). The coordinates of a mouse are then simple.
- it got a bit more complicated, once I've started using absolute positioning, to actually have control over the 'editor'. In the end, I have used a separate object, that remembered the position and sizes of the resizing area; with every move or resize it was updated, its values used to change the resize layer.
- once you use the onmouseover event, your CPU load goes up, and if you fool around a little (moving the layer wildly around), it may jump up to 100%. I may not care, but this thing should eventually be used by the customers, who might not like the load. Also, if you try debugging (and you will need it), which you have to do in some textbox, everything will go _much_ slower. Be prepared for that.
- the actual calculations for moving and resizing something are so easy to break, and so hard to get right. Especially if you want the dingus to be resizable from all sides - up or down, left or right, doesn't matter. I have seen only one script that actually did this, and it worked in a horribly complicated way, with neat design but very ugly code. (Will add link to it.)
- additional fun was our special condition: we wanted the resulting image to be of a certain size in the end; what we selected could also have any size, but we could enlarge it or make smaller. But what I had to maintain, was the width-to-height ratio.
Developing at two browsers at once gets annoying; I rather kept testing with Firefox (blesseth be Firebug!) until it was somewhat stable, and then tried it with Explorer. Glad that you asked, there were some differences:
- the worst were the different names of the JavaScript objects that were desperately needed. How do you find out where the mouse came from or went to? I know it now (at least for the two browsers), but it took some annoying experimenting.
- Firefox apparently waited, until the image was loaded; Explorer didn't, and kept executing the code after the loading was requested - so an onload function had to be implemented for the image, that did all the initialization. But that was actually an improvement.
- pretty bad was Explorer's treatment of the mouseDown event. What worked well with Firefox, failed there. Turns out that it somehow refuses to fire the event, if the layer has only a border defined, and nothing else. But as soon as a background color is set, it works! That of course sucks, as the image in the background had to be visible. In the end, I have set up a large transparency for the resizing layer, and had both things... well, it isn't perfect. I'd like the border to be completely visible, and the transparency/opaqueness to be very gentle, so most of the picture stays visible. Still some work to do with this... or somehow bypass it. Duh.
Well, that's how it is starting, and much is to be done (the closing functionality that tests if the selection is correctly positioned isn't yet complete, so it can be broken), but the basics already work! Guess I will post some image a maybe even some of the code so it is clear what it actually does, and how.
Subscribe to:
Posts (Atom)