blog.t8d.de

Eigentlich hat man sich ja damit abgefunden, dass der IE immer irgendwelche Zicken macht, aber heute hat mich mal wieder die pure Wut gepackt, nachdem ich einen komplett wahnsinnigen IE7 CSS Bug aufgespürt habe:

Ich habe in eriner Seite einen Iframe eingebunden. Um die vertikalen Scrollbalken zu verhindern, hatte ich mit einem Conditinal Comment folgendes geschrieben:


<!--[if lte IE 7]>
<style type="text/css">
html {
overflow-x:hidden;
}
</style>
<![endif]-->


Eigentlich komplett einfach: lass die Scrollbalken der X-Achse weg (versteht eh nur der IE). Hat auch alles funktioniert – die Scrollbalken sind weg.
Leider funktioniert danach das Mausrad im Iframe nicht mehr, obwohl die Y-Achsen Scrollbars da sind und man auch ganz normal scrollen kann, wenn man auf den Scrollbar benutzt -nur eben nicht mit dem Wheel. Muss man nicht verstehen – einfach nur irre. Liest sich jetzt ganz einfach, aber da das Ganze in einem relativ komplexen Layer-Zusammenhang benutzt wird hab ich natürlich erstmal an 1000 andern Stellen gesucht…

Naja, wenn das alles so einfach wärewürds ja auch jeder machen. Hoffentlich hilft das hier jemand

Ich habe den Status der Diskussion für die Mailingliste einmal zusammengefasst. Hier der Inhalt, da noch nicht im Archiv verfügbar:

Hi all,
imo it makes sense to come back to the question: what is the goal?

Give me a try to collect what you have mentioned (I abridge a bit):
- TMDM-ish (consensus, I think)
- Java-ish/Java-centric, stay Java-ish and become TMDM-ish
- Java 1.5
- UML (class diagrams) and Java reference impl., derive handcrafted translations to other languages
- Be much less Java-centric
- Still be model based (i.e. it is not a streaming SAX-style API, but an
OO DOM-style API)
- Define an event model, event model afterwards
- streaming API
- Ideally provide interface specifications for multiple languages (and
auto generation from a single standard)
- 2 layers of interfaces: r and rw
- auto-generation of interfaces with DSL
- XMI ugly, overhead, too complicated

I see one “keen” approach which is a TMDM-oriented revision/further dev. of the original Java-ish TMAPI containing UML class diagrams and a Java (reference) implementation (tmapi.org).
A more generalized approach has been spoken out but there is no concrete suggestion (Kal, I assume that you also think of UML as a starting point here?) and I can’t identify supporters here on the list so far (by contribution/articulation).

Lars H. has posted a list of features he likes to see. Many of them (“80%”) have been realized by Xuân in TM4J2 and in PHPTMAPI (no surprise, Lars H. supported the translation The UML sleeps here: http://phptmapi.sourceforge.net/uml_core.html). Obviously there is a certain consensus about what a (Java-ish) revision should look like.

My opinion as a third party is: The “stay Java-ish and become TMDM-ish” approach is pragmatic. It costs the fewest time and effort. Translating TMAPI to PHP was no rocket science and thus would be no rocket science again. Therefore I appreciate this approach although a more general approach really sounds nice. However I can only speak for the www’s workhorse PHP.
The UML then should be put in the center from where any translation to other lang. starts. IMO terminological differences (renaming scope to theme) should be avoided as this collides with the goal to be TMDM-ish. As method overloading is not supported in PHP it would be nice if every method will get a unique name. If not, I don’t mind.
Some standardization for serializing/de-serializing is very useful, Lars H. has published a proposal. (Lars G.: the event model you mentioned affects this point?)
Implementing r or rw should be left to the implementor. Auto-generation sounds useful but is language specific. IMO this should be left to implementors/translators, too. TMAPI 2.0′s job is also to serve as a documentation/starting point/practical introduction, that’s why I think UML in the center really makes sense.
Moving the index funtions to the core objects is usefu because there is the place where they are needed. PHPTMAPI has no locator object, this also has been proposed by Xu̢n and Benjamin if I remember correctly. This is pragmatic, too Рhowever I also see the problems if you, e.g., enter the library world.

Rho raised the question of how easy impl. ontop of TMAPI will be. I have the unspecified idea of a “Simple API” as part of TMAPI in mind which works ontop of TMAPI. It is high level and captures common aka the most needed operations in a comfortable way. Any thoughts?

Best regards,
Johannes

p.s. Rho bezieht sich dabei auf TMQL.

Das de-facto Standard API für Topic Maps Applications, TMAPI, hängt konzeptuell zwischen dem (rudimentären) Datenmodell von XTM 1.0 und dem TMDM. Entsprechend könnte man überspitzt sagen, dass TMAPI und seine Referenzimplementierung in Java weder Fisch noch Fleisch ist. Nun ist auf der TMAPI-Mailingliste die Diskussion über TMAPI 2.0 gestartet, das “TMDM-ish” sein soll. (Das Archiv ist hier einzusehen: http://sourceforge.net/mailarchive/forum.php?forum_name=tmapi-discuss) Dies bedeutet also eine zum Standard hin orientierte Revision. Einige Vorschläge sind bereits bei PHPTMAPI umgesetzt worden, der Portierung von TMAPI nach PHP5. Unklar ist zur Zeit noch, wie TMAPI 2.0 aussehen sein wird. Ein Ansatz sieht die Revision von TMAPI vor (“Java-ish”), ein anderer geäußerter Vorschlag beinhaltet einen generalisierten Ansatz. Contributions are welcome!

Seit heute kann man bei Flickr auch seine eigenen Videos hochladen. Die Länge ist dabei auf 90 Sekunden begrenzt, also wirklich nur für kurze persönliche selbst erstellte Videos gedacht – trotzdem spannend.

via Simon Willison