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).
--
/ Johan Sundström, http://ecmanaut.blogspot.com/
_______________________________________________
General mailing list
[email protected]
http://simile.mit.edu/mailman/listinfo/general
