Beiträge von Grevas

andoll übertreibt da etwas... Es geht um ein Hobby-Projekt, also im 3 Stelligen (also ~500-999) Bereich wäre durchaus schon was machbar (dennoch, für ein Schüler da einen Semi-Profi anzuheuern, wird wohl nicht drin sein).

Wenn du jemanden suchst, der es just 4 fun macht, musst du deine Community ansprechen (um die aufzubauen, kanns auch ruhig mal was von der Stange sein). Nebenbei sei erwähnt, dass du einen Profi dafür wohl eher nicht bekommen würdest (zumindest nicht per Auftrag) - das was du machst befindet sich in einer Grauzone der legalität (oder vllt. sogar das nicht mehr - ich weiß nur, dass ich mich auf sowas nicht einlassen würde).

//P.S. der Name des Threads sollte kein [Jobangebot] enthalten - ohne Bezahlung ist es auch kein Job!

Bin zwar noch lange davon entfernt ein RegEx-Guru zu werden,
aber so als Vorschlag (für den von dir verwendeten Smiley):

$regex = '(^[.]|\s+?):\)';
$replace = '\1<img ... />';

Getestet mit:

>:)
:)
 :)

Offtopic:
hab mich etwas gewundert, dass ich jemanden mit so 'vielen' Posts noch nie gesehen hab - du darfst ruhig auch mal Helfen und nicht nur fragen ;P

Pöh.

1. Also, Popup blocker werden kein Problem sein. Diese Filtern nur bestimmte URL's, aber ein JavaScript popup das du selbst auf deiner Seite erstellst, wird nicht geblockt.
2. Bessere Möglichkeit wäre es, gleich fest in die Seite zu integrieren und evtl. per Cookie setzen ob jemand schon abgestimmt hat (solche Umfragen kann man nicht 'fälschungssicher' machen, man kann höhstens noch die IP speichern beim voten).
3. Die Buttons und co. machst du am besten gleich als Formular (HTML, und so, ne?...)
4. Dann brauchst du ein Serverseitiges Script / Programm, dass diese Auswertet.

So, machen werd ichs dir aber nicht

Ui, das wusst ich noch gar nicht wie oft hab ich mir das schon überlegt - eigentlich wunderts mich auch, dass es geht, aber schön isses trotzdem *g*.
Funzt super { P.S.: außer, dass man so natürlich nichtmehr was aus dem tooltip kopieren kann, da er wieder versteckt wird sobald man den Fokus vom <a> verliert }

<style>
div { display: none; }
a:focus + div { display: block; }
</style>


<a href="#">hi</a>
<div>focus liegt über mir!</div>

Übrigens, zu dem Verschachteln von anderen Elementen innerhalb von <a> - da machen ein paar Browser Fehler beim Parsen (z.B. der IE9). Wenn man ein <div> in ein <a> klatscht, parst sich der Browser das raus und setzt es unter das <a> (unabhängig der CSS Eigenschaften) ...

Was du suchst, ist ein WYSIWYG Editor.

Allerdings für Newsletter ist sowas ungeeignet, die einzelnen Hoster haben da ihre problemchen.

Ich würde es eher Fehlerfrei nennen.
Wie beschrieben, der Validator kann gar nicht bewerten ob es richtig oder falsch ist. Der verwendet nur die defaults der Elemente - die kann man allerdings überschreiben (wie eben beim <a> 'display' auf 'block' setzen).
An Validator-Fehler kommt man manchmal gar nicht drum rum (beispielsweise die Einbindung von Flash mit <embed> - driver hat dazu mal eine Seite gepostet wie man das umgehen kann, lohnt sich aber imo nicht der Aufwand).

*sigh* wie gesagt, nur ob etwas von einem HTML Parser als Valide oder nicht erkannt wird, hat noch lange nichts zu sagen.

Wenn du unbedingt willst, dass ein Parser es richtig erkennt, musst du für den halt die Sachen beschönigen indem du z.B. <span>'s statt der Tabelle verwendest (kannst es entweder mit display: table oder auch display: inline-block erreichen).
Empfinde ich aber als etwas unnötig, denn, ein <a> kann AUCH ein Blockelement sein - nur wird sowas bei HTML Überprüfung nunmal nicht berücksichtigt. Aber das ist dann nichtmehr 'mein' Problem.

Ich weiß nicht wie du auf diese Idee kommst...

Auch zukünftige Browser rendern mehr als HTML. Nur weil ein <a> Tag per default ein inline Element ist - heißt es nicht, dass man es so verwendet. Der Grund warum ein <table> innerhalb von <a> nicht Valide ist, ist nur, dass innerhalb von Inline-Elementen nur andere Inline-Elemente 'erlaubt' sind.

//P.S. deine 'einfachste Lösung' deckt nicht die Anforderungen die du gegeben hast. Die Untermenüs bleiben nicht offen, wenn man nur drauf geklickt hat... (und übrigens, funktioniert die Lösung im IE6 nicht - was allerdings auch recht egal ist)

Gratuliere,

Diese Antwort ist auf einen fast 3 Wochen alten Thread sicherlich hilfreich.
FONT != font-size.
Er soll nachschaun ob er irgendwo im CSS Angaben zur Größe macht?
Das hat er doch schon geschrieben: "Ich setze diese auf 1.2em" - das ist bereits CSS...

Vorschlagen den Code hochzustellen? Wurde auch bereits vorgeschlagen, anscheinend gabs dazu aber keinen Bedarf. *sigh*
Ich finds toll, wenn man anderen versucht zu helfen, aber bitte erstmal den Thread anschauen bevor man was schreibt

Es muss ja keine Tabelle sein.

Das hab ich geschrieben, ja, nagut, fast...
Ich dachte eher, dass nur die besetzten Felder als Grafik generiert werden - spart unnötige Durchläufe.

Du brauchst JavaScript um die Bereiche anklickbar zu machen.

Beim clickevent die Mauskoordinaten relativ zur Karte holen / berechnen und schon hast du deine Koordinaten.

Wegen sowas würd ich die Seite nicht nochmal besuchen und dir da sagen 'weil du mich fragst warum ich mein Browser schließ'...

Ich dachte auch eher daran, dass beim unload der Schließvorgang nicht abgebrochen wird.

unload ist aber mit den Anforderungen falsch. Und nun?

schwan: sry, aber ich sags dir nicht, ich find solche Scripte sau nervig (nach dem Motto: VERDAMMT NOCH MAL. JA!!!! ICH BIN SICHER!!! Hab doch gerade auf den Button geklickt!... Wenn ich soetwas irgendwo in der 'Wildniss' begegne, kannst du davon ausgehen, dass ich diese Seite nicht mehr besuche). Vielleicht machts jemand anders

Du suchst an der falschen Stelle nach dem Problem.

50x50 Karte ergibt bei dir 187329 Zeichen
100x100 ergibt schon 712181
Also nach dem Ansatz, den du hier gepostet hast. Auf der 'live' Version bestimmt noch weitaus mehr durch die Links.

Merkst was?

Aber auch bei der Herangehensweise: eine Klasse statt jedesmal einer Styleangabe würde die Datenmenge schonmal etwas reduzieren (oder vllt. auch eine bedingte CSS Anweisung à la .class td *mhh* noch weniger unnötigen mist)

//P.S. so zum Vergleich, jQuery minified hat ohne das Kommentar derzeit 84893 Zeichen. Das sind 29kb - und du hast ein gebilde das auch noch gerendert werden muss.

Noch ein Tipp: man kann mit JS die Mauskoordinaten auslesen, bin jetzt nicht sicher ob es relativ zu einem Container geht - aber die Karte dann mit einem Script zu verwenden würde dir seeeehr viel sparen (im Zweifel kann man die relativen Koordinaten auch selbst berechnen). Dafür könntest du einmal eine kleine gif für die grauen Kästchen machen und für die 'besetzten' eine Grafik dynamisch generieren und die da drüber legen. Tada - Karte die bis in die 1000x1000 gehen kann (auch wenn vllt. 250x250 schon ausreichen sollte, eine 1000x1000 Grafik hat auch schon 'paar' KB und generieren dürfte auch etwas dauern - aber da kann man wieder etwas cachen...).

Ist aber wohl ein Mythos

Ich bezweifle sehr stark, dass google die Inhalte nach der URL indexiert - wohl eher domain & path. Dem 'site:' Filter ist es zumindest schonmal egal *g*

Es ist ein Snippet. Eine Vorlage. Statt den Code per Hand neu zu tippen, reicht ein shortcut / abbrevation um das Grundgerüst für eine Query parat zu haben.

Was du jetzt gepostet hast, würd ich dagegen mal eine Helper-Funktion nennen *g*. Nix gegen, hilft ja auch.

//EDIT: hier noch paar Drupal-Snippets.
Eigentlich mehr als Tipp gedacht, für was man sich alles Snippets anlegen kann.
Beispiel Form API:

$form['[[%tabstop:title]]'] = array(
  '#type' => 'textfield',
  '#title' => t('[[%tabstop2:Title]]'),
  '#default_value' => '[[%tabstop3:value]]',
  '#description' => t('[[%tabstop4:Description]]'),
  '#size' => [[%tabstop5:60]],
  '#maxlength' => [[%tabstop6:128]],
  '#required' => [[%tabstop7:TRUE]],
);

Eine Drupal-Select Query

$q = 'SELECT [[%tabstop:*]] FROM {[[%tabstop2:db]]} [[%tabstop2]]';
$res = db_query($q);
while($row = db_fetch_array($res)) {
    $row;
}

Und etwas allgemeines, ein Class-Snippet direkt aus Komodo:

/*
 * class [[%tabstop1:class]]
 */


class [[%tabstop1]] [[%tabstop:extends [[%tabstop:class]]]] {

    /*
     * __construct()
     * @param $[[%tabstop2:arg]]
     */

    function __construct($[[%tabstop2]]) {
        [[%tabstop:parent]]
    }
}

Für die Einträge?

Mit CSS3 gibt es die möglichkeit elemente zu drehen.

https://developer.mozilla.org/en/css/-moz-transform

synaptic: nicht zwangsweise, wie gesagt, man kann per Trigger Sachen direkt in ein File schreiben. Damit belastest du die DB nicht wirklich. Eine paar KB große .txt zu laden tut dem Provider garantiert nicht weh

@jojo: stimmt, müsste man halt etwas erweitern - wenn es auf mehrere User skalierbar sein soll - dann muss man den Stand der einzelnen User irgendwo speichern. Da kann man auch noch etwas tricksen. Aber ich glaube das geht irgendwann zu weit und lohnt einfach nicht^^, jenach Requirements ändert sich der Lösungsweg...

Es geht doch nur darum, neue Einträge anzuzeigen - wofür da bitte eine connection aufrecht erhalten?

Wenn es nur anhand der Einträge sein soll, muss man die Einträge irgendwie markieren wie jojo beschrieben hat. Oder man macht eine Prozedur die beim Insert getriggert wird. Dann muss man nur noch eine andere Tabelle abrufen die gesäubert wird beim auslesen. Oder man lässt bei der Prozedur die neuen Einträge (vllt. etwas gekürzt auf die 'interessanten' Daten) in ein File schreiben. Statt der Prozedur kann man ja auch eine eigene Eintrag-Maske basteln die eben das erledigt. Oder oder oder...

Wegen Performance würde ich mir aufjedenfall keine Sorgen machen, soll doch nur im Admin-Interface passieren.