Thanks for your reply Sean. Unfortunately no time to look for the masabi extension trouble yet. I do hope to get to it soon.
Sean Gilligan wrote: >Well the noHistoryStack and backButtonHack option(s) would be easy to >implement with a CSS class and iui.hasClass() Finding a 'standard' place to >put an href >or a string is little tougher. One approach that could be used >is an element within each fragment/page/div/ul that contains the link and >title. That element could >then be hidden by iui.css. Could you explain >(remind?) what the use case is and exactly how the alt location and alt text >are used? Here's what I'm working on. Its a checkbook app. The pages I need to override back button on are as follows. A = account list B = transaction list from A C = form to add new transactions goes back to B on submit When adding several transactions you end up with a trail like A->B->C->B->C->B->C->B->C->B That's a lot of backing out to get back to A In my case I don't want C to ever show up when you go back(Page C needs noHistoryStack), and I want the back button on B to always go back to A no matter how many transactions are entered(Page B Back button would need to always be labeled "Accounts" and link back to Page A, Thus the alt location and text). I had not thought about class based detection, good idea. Using the idea of css hiding of elements made me think of this... for pages left out of of back nav altogether like my page C <form> <input type = "hidden" id = "noHistoryStack" value = "true" /> </form> for pages like my page B that need back to always go to one particular location. <form> <input type = "hidden" id = "backButtonHack" value = "true" /> <input type = "hidden" id = "altBackButtonHref" value = "location to go to" /> <input type = "hidden" id = "altBackButtonText" value = "name of page to go back to" /> </form> If a page happens to be a form already, just add these hidden forms to it, or add the form to pages with no form present. We could detect this with scripting to make these types of overrides possible and I wouldn't think it hard to publish these as standards for developing iUI powered sites with these needs. Let me know what you think. >The non-standard tags will result in error messages from HTML validators >and could potentially conflict with attributes added as part of the HTML >5 spec, for example. There might be a few other possible bad outcomes. >My preference is to avoid using them if there is an (easy?) alternative. All good points I had not thought of. The idea with hidden forms would prevent the negatives mentioned, yes? Vic Hudson -- You received this message because you are subscribed to the Google Groups "iPhoneWebDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/iphonewebdev?hl=en.
