Am 30.07.2008 um 11:17 schrieb Troy A. Griffitts: >>> What don't you like about how HTMLHREF display? Is it the >>> superscripted >>> 'x'? Could we put it in a <span class="footnote_marker"> allowing >>> you >>> to write a CSS rule to display or hide as you would like? >> >> What I have in mind is that all additional information in the HTML is >> hidden. It actually could be plain text then. >> Some information should be shown while moving the mouse over the >> words >> in the HTML view or somewhere in another floating information window. >> That would mean making the word a link that has normal display >> attributes. But the data of the link might be something individual. >> I don't kknow at the moment if this can be done by adding a marker >> and >> using CSS. Actually I didn't thought about using CSS. > > Have a look at SWORDWeb (click on any word in the text): > > http://crosswire.org/study/passagestudy.jsp > > This is done by hiding the looking information into > getEntryAttributes(). If you change lookup.cpp back to WEBIF output, > you can see how it is done. It obviously doesn't have to operate with > onclick, but could be on a hover over action. I think most of the > other > frontends do the similar things while moving the mouse over words.
JavaScript, hmm... I think we mean something different. With 'word' I meant that the word itself should be the link. I.e. in Gen 1:1: the whole term 'In the beginning' is tagged with lemma. So I want to be this whole term a link that doesn't look like a link and while moving the mouse over the link showing a tooltip. This requires creating my own HTMLHREF filter subclass I guess. But no problem as long as I can do it. Do I need to create a filter subclass for all raw types then? > I think with footnotes though, it is a little different. The user > doesn't really know where a footnote is, so there should be some > marker > in the text which lets them know that further information is available > here. And obviously there should be a way to turn these things on > and off. Yes, a small indication. Manfred > >> >> The thing is that I want to have the text display for text only (or >> almost only) and other information is shown somewhere else. The text >> display should be kept as simple as possible. >> >> Maybe this can be achieved somehow by creating HTML filter >> subclasses. I >> was also thinking about using the OSIS filters that Chrtis mentioned. >> But parsing XML myself is actually something I don't want to do. >> >> >> >> Regards, >> Manfred >> >> >>> >>> >>> Manfred Bergmann wrote: >>>> Am 29.07.2008 um 09:25 schrieb Chris Little: >>>> >>>>> >>>>> Manfred Bergmann wrote: >>>>>> Am 29.07.2008 um 09:10 schrieb Chris Little: >>>>>> >>>>>>> Greg Hellings wrote: >>>>>>>> On Tue, Jul 29, 2008 at 1:45 AM, Manfred Bergmann >>>>>>>> <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: >>>>>>>>> Although I don't understand right now how the Sword module >>>>>>>>> data is >>>>>>>>> stored, >>>>>>>>> my proposal here is that Sword should have a simple >>>>>>>>> intermediate >>>>>>>>> XML format >>>>>>>>> that can be used by API users to have full access to the >>>>>>>>> module >>>>>>>>> data. >>>>>>>>> Simple HTML/RTF can still be produced from this intermediate >>>>>>>>> format by >>>>>>>>> Sword. But HTML should not be used to give access to the >>>>>>>>> module >>>>>>>>> data while >>>>>>>>> at the same time raw data access should not be used. >>>>>>>>> Having XSDs would make is easy for API-users to use XML- >>>>>>>>> >Object >>>>>>>>> binding (I >>>>>>>>> only know JAXB in Java but this might be available to most >>>>>>>>> languages as it >>>>>>>>> is used in protocols like SOAP). >>>>>>>>> Also XSLT stylesheets can be used to produce HTML or whatever >>>>>>>>> output. >>>>>>>>> Frontends could choose to use the HTML rendered output or >>>>>>>>> choose >>>>>>>>> totally >>>>>>>>> different approaches by using the data of the intermediate >>>>>>>>> XML. >>>>>>>>> Let me know what you think. >>>>>>>> It seems to me that this is one of the better ideas. After >>>>>>>> all, >>>>>>>> the >>>>>>>> library should supply display-agnostic data to the front end, >>>>>>>> which >>>>>>>> then renders it into a display format, rather than presenting >>>>>>>> it >>>>>>>> with >>>>>>>> a list of a few preselected display formats which are >>>>>>>> supported at >>>>>>>> the >>>>>>>> engine level. >>>>>>> If you want OSIS, just ask the engine for OSIS. There's no >>>>>>> requirement >>>>>>> that you tell the API to render text as HTML or RTF. You can >>>>>>> just as >>>>>>> easily tell the API to render to OSIS, and it will happily >>>>>>> perform >>>>>>> (or >>>>>>> at least attempt) the conversion from GBF and ThML to OSIS. The >>>>>>> GBFOSIS >>>>>>> and ThMLOSIS filters might need a little more work, but they >>>>>>> should >>>>>>> already work fairly well. >>>>>> So that means, basically, there is something like intermediate >>>>>> XML >>>>>> produced on the fly. >>>>> Not by default, but you can certainly ask the API for XML in a >>>>> single >>>>> format. >>>> >>>> Do you know approximately how expensive it is to filter to OSIS >>>> instead of HTML? >>>> >>>> >>>> >>>> Manfred >>>> >>>> >>>> _______________________________________________ >>>> sword-devel mailing list: sword-devel@crosswire.org >>>> <mailto:sword-devel@crosswire.org> >>>> http://www.crosswire.org/mailman/listinfo/sword-devel >>>> Instructions to unsubscribe/change your settings at above page >>> >>> >>> _______________________________________________ >>> sword-devel mailing list: sword-devel@crosswire.org >>> <mailto:sword-devel@crosswire.org> >>> http://www.crosswire.org/mailman/listinfo/sword-devel >>> Instructions to unsubscribe/change your settings at above page >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sword-devel mailing list: sword-devel@crosswire.org >> http://www.crosswire.org/mailman/listinfo/sword-devel >> Instructions to unsubscribe/change your settings at above page > > > _______________________________________________ > sword-devel mailing list: sword-devel@crosswire.org > http://www.crosswire.org/mailman/listinfo/sword-devel > Instructions to unsubscribe/change your settings at above page _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
