The point of having Fireworks not export anything particular in the HTML for slices that are not selected is that it leaves the developer open to fill those slices with CSS color or tiled background images, rather full-sized images. In any case,if you just need a quick fix in your code...why not just edit the code? (HTML developers don't really need Fireworks to export code at all. )
Fireworks is not ImageReady and there is a large base of long-time Fireworks users who would be very upset if Adobe re-wrote it to work "just like ImageReady" did. (For example, see the threads about the font and text issues and bugs that have arisen from the replacement of the Macromedia text engine with the Photoshop text engine.) I realize it's disruptive to have to learn a new program, especially after having used one you really liked, but I think it helps to approach learning a new program with a "how does this one work?" attitude rather than a "why doesn't this one work like my old one did?" attitude.
lol I have been a designer and developer for over 10 years, so I think that qualifies me to that "yes" we do need a function in fireworks that just copies html for selected slices as did ImageReady.
The suggested functionality of "Copy HTML Code" and the sub option "use selected slices" clearly implies that only the selected slices html will be copied to the clipboard. Maybe q/a should review it with there development team and they should talk to the original ImageReady team who was able to make this work correctly.
Listen I am not here as a fanboy of either fireworks or ImageReady. I use there suite to develop and fireworks like many other WYSIWYG takes what should be realitivly simple html code and adds tons of unecessary tags etc. For dopey people its fine, but for anyone who hand codes its a lot of extra code, which goes against the grain of development imo.
Now back to what developers need. As I developer fireworks "Copy HTML Code" should focus on exactly the selected slices within a document imo. There are times when you need to make a small correction to say an image that is sliced up in a few spots but don't need all the excessive fireworks tagging. In other words I just need the exact table this image is cut up into and nothing more. So if I select those slices and copy HTML code I should get those slices and nothing more.
Both fireworks and ImageReady had good and bad things. Adobe deciding to not to implement the good from ImageReady is a poor decision.
This is a user to user forum. If you have a request you want Adobe to hear, the best thing is to fill out the Wish List /Bug report form on adobe.com
Thanks Jim I am planning on adding this comment to the wish list.
I thought I recognized your name, being that you are a teacher and know the application well, I would like to hear you opinion on the matter. Especially if you have used ImageReady in the past.
Well, I've used Photoshop for hi-res imaging since about version 2, Fireworks for screen graphics since it first came out. Anytime I tried to use IR, I just found it too clunky, but maybe that's just me. Soooo, I don't miss it.
As for exporting out HTML specific to a slice, I'm not sure if I'd use that. I think it'd be faster for me to update the HTML in DW. But perhaps a sample of what you're wishing for or trying to do would help us all better visualize the workflow you're describing.
If I did have a specific area I wanted to segregate as a separate table, what I've done in the past is copy that segment to either a new PNG or new page and export it separately. Then I can round trip that part of the layout. Let me know if that makes sense.
There are times when you need to make a small correction to say an image that is sliced up in a few spots but don't need all the excessive fireworks tagging.
Sorry, I still don't see it. If all you've changed are images, then all you need to do is re-export the images. You don't need HTML for that. If you've changed how the document is sliced, how would FW (or ImageReady for that matter) know that you haven't changed the number of columns for the table? Software is not "smart." Because the software cannot make assumptions or logical deductions, the full page is output.
Adobe deciding to not to implement the good from ImageReady is a poor decision.
I disagree strongly with this statement. Just because ImageReady had some good features is no reason to try to cram them into Fireworks when the decision was made to drop IR.
As I said before, replacing the Macromedia text engine in Fireworks with the Adobe text engine used in Photoshop (for the CS4 release) was clearly a considered move and yet that code replacement has made the software so buggy for text handling that it is nearly impossible to use. Many users have had to drop back to CS3. For Adobe to have consistent text management across their software offerings is a reasonable goal. For Adobe to produce an amalgam of all the features of IR and FW is not.
My example did not go into a huge amount of detail. Lets just that if you slice something up and hit copy html code for those specfic slices, you should get just the code for those slices and have the ability to export them as well.
Pixlor it is clear that you are a "fanboy" lol. You sound like one of these guys that can't accept that both softwares had pros and cons.
Fireworks is garbage imo but since ImageReady has been scrapped I am force to adjust my workflow. Fireworks still isn't even fully web standards compliant when you export CSS, lmao. Adobe's goals for software is continue to improve the software and add useful functionality that speeds up development for its end users. But I won't waste my time arguing development features with someone who can only see out of Macromedia's software platform eyes.
Jim I am going to work up an example and post it back up hopefully this weekend to give some insight to the functionality I was hoping Adobe would bring into fireworks.
Fireworks still isn't even fully web standards compliant when you export CSS, lmao. Adobe's goals for software is continue to improve the software and add useful functionality that speeds up development for its end users. But I won't waste my time arguing development features with someone who can only see out of Macromedia's software platform eyes.
A graphics program, whether it's FWs IR or PS, will never produce standards code,. They are graphics programs not xhtml editors. The code produced maybe fine for prototyping but not for live production.
In over 10 years of web development I have never once used the html produced by FWs it's all done in DW or a text editor. If it were up to me, I wouuld remove the code writing/export feature from FWs altogether :-)