one other question about your method: can I combine it with the standard
method? eg put a pointer to some schema in a link from the head while
putting actual data into the html table?
Johan Sundström wrote:
> On 2/3/07, David Huynh <[EMAIL PROTECTED]> wrote:
>
>>> The .exhibit-timelineView-timelineContainer element has the border,
>>> but playing in Firebug, it looks like this should work if it was
>>> instead put on the div classed "exhibit-timelineView-timeline
>>> timeline-container" instead. Should I file that as a feature request
>>> ticket instead of mentioning it here?
>>>
>> You can just include your own CSS rules *after* you include
>> exhibit-api.js to override Exhibit's styles. That's the "right" way :-)
>>
>
> I figured out a better way. Setting the width of the view panel to
> make room for a browse panel on the right via some javascript (for
> once there is no real point trying to do it in CSS) solved the issues
> I had with content colliding with the floated browse panel.
>
>
>> Very nice! I turned off Javascript and still saw the content--that's great!
>>
>
> There is a cute some-javascript-handled hack there too which ghosts
> all past performances and emboldens the next one, in case Exhibit
> failed to load. ;-)
>
>
>>> All that functionality probably hasn't completely stabilized yet, but
>>> some of it could use more eyes and discussion already.
>>>
>> Do you want to stabilize this before locking down Exhibit 1.0 to start
>> on 2.0? (Yeah, I know, 2.0...)
>>
>
> I think it might be in a fairly decent state already, though it would
> be useful with more prying eyes and people trying to use it, to see if
> I have just not hit all the scenarios people are likely to encounter
> and which should be possible. At the moment I've worked out all the
> bugs that bit *me*, anyway, which is always something. :-)
>
>
>> It's quite a trade-off, though. Each record, e.g.,
>>
>> <tr><td>1</td><td>2</td><td>Thingy</td><td>Stratford-Upon-Avon</td></tr>
>>
>> is less self-describing than its equivalent in JSON:
>>
>> { Property1: 1,
>> Property2: 2,
>> label: "Thingy",
>> Property4: "Stratford-Upon-Avon"
>> }
>>
>
> I never really liked HTML tables either, but the lack of context isn't
> any worse than with tab or comma separated values. HTML tables are not
> particularly well suited for text editors, though, even if it gets a
> little better formatted as my example page where a typical row looks
> like this:
>
> <tr><td>2004-09-18 kl 20</td>
> <td>San Leonardo</td>
> <td>Konsert</td>
> <td>Verbania, Italien</td></tr>
>
> ...which is almost readable, and certainly even more so in the context
> of surrounding rows. But I won't argue the point; HTML beautifully
> combines being neither very pleasant as a markup nor layouting format.
> ;-)
>
>
>>> (I havent tied in the map functionality yet, since I didn't remember
>>> how to do it at the time, so the final tab puts the Exhibit into an
>>> eternal busy state, for the time being.)
>>>
>> In the location array, replace "name" with "id". Then in the map view,
>> remove ex:start and ex:end and add ex:latlng="latlong". Hope that works!
>>
>
> I ended up taking my time remodeling relations and doing a lot more in
> the process, heavily tweaking things and messing about with the map
> view code, and am sort of happy with the updated outcome:
>
> http://ecmanaut.googlepages.com/choir-events.html
>
> The multi-hop facets (.location.Stad here, for "city") behave a little
> surprisingly; first, they don't exist at all, when the page has
> loaded. Toggle something on and off, though, and they show up.
>
> Unrelated side thought: I am starting to lean towards modeling all
> data in English, to get presentation layer issues like CSS class names
> and similar that don't violate W3C rules (I presume some browsers
> might not like unicode names there, though I honestly haven't tried
> the territory much).
>
>
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
