4. CSS-Styles überschreiben?

CSS-Styles überschreiben?

  • G

    hast du dir schon mal h1 bis h6 umzudefienieren, würde bestimt ne menge treffic sparen wenn man statt
    <span class="kw">int</span> ein
    <h1>int</h1> übertragen müsste
    natürlich kann man dann h1-h6 nicht mehr in den restlichen template benutzen (aber wer tut das? und fals doch dann soll er sich classen defineieren uns sein template umschreiben :p)
    und auf browsern die kein css können würde das bestimt auch schräg aussehen

    0
  • S

    Hallo.

    Ähhh... ja, was willst du mir jetzt damit sagen? Soll ich über die Neu-Definition der H-tags die Kompatibilitätsprobleme bei machen Brwosern umgehen oder wie?

    Bye.

    0
  • G

    Happosai schrieb:

    Hallo.

    Ähhh... ja, was willst du mir jetzt damit sagen? Soll ich über die Neu-Definition der H-tags die Kompatibilitätsprobleme bei machen Brwosern umgehen oder wie?

    Bye.

    nö die h-tag neu definieren was ne neue idee, wollte wissen was du von hällst

    0
  • S

    Hallo.

    Eigentlich brauchte ich nur die Info, ich hab an sich kein großes Interesse daran, mich wirklich tief und eingehend mit der Thematik CSS zu beschäftigen...
    Der Traffic ist mir so ziemlich egal. Auf meine Website kommt eh nie jemand und das Forum, für das ich den SH-Mod schribe, liegt auf nem Server, für den ich nix zahle (sondern Floyd *g*).

    Die genaue Definition der CSS-Styles gibts beim W3C, oder?

    0
  • G

    Happosai schrieb:

    Der Traffic ist mir so ziemlich egal. Auf meine Website kommt eh nie jemand und das Forum, für das ich den SH-Mod schribe, liegt auf nem Server, für den ich nix zahle (sondern Floyd *g*).

    das für deine seite so selten besucht ist, hast du dir aber ganz schön mühe gegeben bei deinen SH-MOD 🙂

    0
  • C

    @Happosai:
    Wird dieser Code von deinem SH-Mod korrekt eingefärbt?

    "/* Test */"
// "Test"
// sollte sich nicht stören lassen von einem " im Kommentar
if
"/* Test"
"Das auch */"
"// Das ist auch in Ordnung" // Kommentar aber erst ab hier
    0
  • S

    @Dimah: der Mod ist ja auch net für mich, sondern für das Board des Projektes, an dem ich z.Zt. mitarbeite... trotzdem danke.
    Der Mod soll dann ja mal Open Source werden... als Multilingual Snytax Highlighting Mod, basierend auf sog. LSTs (Language Syntax Templates), mit denen der Mod beliebig viele Sprachen unterstützeen kann. Viel Arbeit, aber das ergebnis ist es wert. 😉

    @cd9000: Lass mich das mal eben testen ... ja, völlig korrekt geparst. Ein Screen als Beweis gibt's hier (niedrige Qualität, 73 KB) Hättest du wohl gern, dass mein Mod da Kapriolen schlägt, gelle? 😃 Tut er nicht, dafür ist er aber leider auch extrem langsam ... ich arbeite dran, dank Dimah bin ich jetzt schon ein gutes Stück näher an einer guten Lösung... *freu*

    Bye.

    0
  • S
    Mod

    h1 tag umdefinieren???
    ja sagt einmal!

    h1 steht für Header1
    und jetzt stell dir mal vor jemand schaut ohne CSS fähigen browser ins forum - der kann keinen code mehr lesen.

    nein, nein, nein.

    mach doch lieber ein
    <b class="key">
    wobei <span> immer noch das beste ist. (und nur 3 zeichen länger)

    btw:
    bei der traffic verschwendung vom PHPBB kommts auf das syntax highlight auch nicht mehr an.

    und hau das ganze JS mal in eine datei...

    0
  • H

    Wieso ist <span> besser?

    Ich würde eher <em> Vorschlagen, denn es handelt sich ja um eine "Hervorhebung".

    Und h1-h6 umdefinieren ist wirklich schwachsinn. Damit würdest du den Inhalt der Seite falsch beschreiben.

    0
  • C

    Happosai schrieb:

    @cd9000: Lass mich das mal eben testen ... ja, völlig korrekt geparst. Ein Screen als Beweis gibt's hier (niedrige Qualität, 73 KB) Hättest du wohl gern, dass mein Mod da Kapriolen schlägt, gelle? 😃 Tut er nicht, dafür ist er aber leider auch extrem langsam ... ich arbeite dran, dank Dimah bin ich jetzt schon ein gutes Stück näher an einer guten Lösung... *freu*

    Du hast gesagt, "// int" ist ein Problemfall. Deswegen benutzt du doch jetzt die CSS-Pseudoformate, oder?
    Ich hab mir gedacht, wenn // "foo" ein Problemfall ist (und gelöst wurde), wurde dann auch der umgekehrte Fall "// foo" gelöst? So wie es aussieht hast du es aber gut hinbekommen. 🙂

    Warum ich gefragt habe?
    Ich hab das Syntaxcoloring von diesem Forum geschrieben, Dimah hat es eingebunden und verbessert.
    Das Grundprinzip deines Parsers ist es wohl, den Code Zeichen für Zeichen durchzugehen (stand AFAIK in einem anderen deiner Postings). Ähnlich funktioniert auch unser derzeitiges Modul hier. Bei dieser Variante (Zeichen für Zeichen) sind verschachtelte Tags der übelsten Sorte aber überhaupt kein Problem. Das Problem ist, wie du auch schon festgestellt hast, die Geschwindigkeit. Und die einfache Erweiterbarkeit um neue Sprachen.

    Ich arbeite im Moment an einer neuen und schnelleren Version. Die geht nicht mehr Zeichen für Zeichen durch.
    Dabei treten aber leider Probleme bei solchem Code auf, wie dem, den ich dir gegeben habe. Diese Probleme hab ich mittlerweile einigermaßen im Griff, aber eben wieder auf Kosten der Geschwindigkeit. 🙄

    Arbeitet dein Parser eigentlich immer noch Zeichen für Zeichen?

    0
  • S

    Hallo.

    Die Sache ist so:

    Der aktuelle Parser (BETA #2) arbeitet noch Zeichen für zeichen, daher - wie du schon richtig bemerkt hast - sind verschachtelte Codes überhaupt kein Problem. Nur leider ist der Parser zu langsam.
    Der farbige Code, den ich euch gezeigt hatte, wurde noch mit dem "alten" (BETA #2) Parser erstellt, daher lief alles wunderbar.

    Der neue Parser wird mit sog. regulären Ausdrücken arbeiten. Und genau aus diesem Grund brauche ich die verschachtelten Tags.

    Zur Zeit läuft der neue Parser so:

    Als erstes weredn die Sonderzeichen ersetzt. Den Code hab ich vom phpBB, ist ganz simpel, aber wichtig.
    Danach wird folgendes auf den Code angewandt:

    $string = preg_replace("#/\*(.*?)\*/#si","<span class=|comment|>/*\\1*/</span>",$string);

    Dadurch färbe ich schonmal die /**/-Kommentare ein. (Die | haben ihre Gründe, keine Sorge...)
    Nun versuche ich dasselbe auch mit "" (Strings) und '# (Strings) zu machen, wobei da noch Fehler auftreten, wenn in einem Kommentar ein einzelnes ' steht (z.B. bei "it's a comment"). Lösung: Die ', die in Kommentaren stehen, werden einfach durch ihre dezimale Entität (' (oder35?)) ersetzt, wodurch sie beim nächsten preg_replace wegfallen. 💡
    Da ich genau dort (' -> ') noch Probleme hab, bin ich noch nicht viel weiter, ich weiß aber, dass ich vorher noch die Zahlen einfärben muss, da sonst die 39 der dez. Ent. auch eingefärbt wird.

    Um möglichst viele Sprachen zu unterstützten, gibt es die LSTs, die alle relevanten Daten (Keywords, String-Anfäneg und -enden, die zu verwendenden SPAN-Styles etc.) einer Sprache enthalten. Über diese LSts kann der Mod dann praktisch belibig viele Sprachen unterstützen. Zur Zeit hab ich LSTs für C++, PHP, Delphi, VB.NET, Pascal und ruby.
    Mehr über die LSTs gibt's bei PU.com, auf der ersten Seite dieses Themas hab ich einen entsprechenden Link gepostet)

    Dieser neue Mod bekommt dann erstmal die Bezeichnung BETA #3 und wird auf pu.com ausführlich von den Membern getestet werden. 😉 Die fertige Version kommt dann als Open Source-Mod raus.

    Um nicht wieder so langsam zu werden, versuche ich diesmal, wirklich so viel wie möglich über reguläre Ausdrücke zu machen, da diese wohl dammig schnell sein sollen. 😮

    Für den Fall, dass mein Mod irgendwann 😃 mal fertig wird, soll ich ihn dir dann mal schicken? Vielleicht habt ihr ja Bedarf dran. 🙄

    Mal unter uns: Ich hab doch letztens so'n Forum von Spezies gesehen, wo jemand stolz wie Oscar behauptet hat, er hätte voll das geile SH geschrieben. OK, das SH war geil, dafür hat er aber auch bloß eine einzige Zeile am Board (phpBB2 Plus) geändert: Ein Auruf von highlight_string() wurde hinzugefügt... 👎

    Bye.

    0
  • C

    Happosai schrieb:

    Der neue Parser wird mit sog. regulären Ausdrücken arbeiten. Und genau aus diesem Grund brauche ich die verschachtelten Tags.

    Meine neue Version arbeitet auch mit regulären Ausdrücken. Es stimmt, die sind viel schneller als die manuelle Lösung, dafür aber auch anfälliger gegenüber Verschachtelungen.

    Ich habe die Sonderfälle so berücksichtigt, dass 2 öffnende Farb-Tags nie direkt aufeinander folgen können. Dazu habe ich 1-2 zusätzliche Schleifen eingebaut, die die Sonderfälle bearbeiten. Momentan klappt das auch ganz gut. Evtl. könnte man diese Schleifen auch durch reguläre Ausdrücke ersetzen, ich bin mir aber nicht sicher, ob das sinnvoll ist.

    Meine Konfigurationsdatei besteht übrigens nicht auch LST-Definitionen. Sie hat ein eigenes Format und besteht fast nur aus den regulären Ausdrücken, die zum Parsen verwendet werden.

    0
  • S

    cd9000 schrieb:

    Meine Konfigurationsdatei besteht übrigens nicht auch LST-Definitionen. Sie hat ein eigenes Format und besteht fast nur aus den regulären Ausdrücken, die zum Parsen verwendet werden.

    ist auch ne gute Lösung, aber ich wollte meine Konf-Dateien möglichst einfach halten.

    Ich muss jetzt nur noch die Keywords ordentlich parsen, dann kann ich mich dran machen, die veschachtelten Quellcodes zu überprüfen...

    In meiner Parser-Funktion sind bisher insgesamt 3 Schleifen drin... 2x Strings und 1x Keywords.

    Bye.

    0
  • C

    Happosai schrieb:

    In meiner Parser-Funktion sind bisher insgesamt 3 Schleifen drin... 2x Strings und 1x Keywords.

    Mein SH arbeitet allgemeiner, es kennt weder Strings noch Kommentare noch Keywords. Es übernimmt nur die regulären Ausdrücke aus der Konfigurationsdatei. Denn nicht jede Sprache hat Keywords. Oder Strings.

    Berücksichtigt dein Parser maskierte Zeilenumbrüche und maskierte Zeichen?

    // Kommen-\
   tar
"\""
/* \*/ "Mehrzeiliger Kommentar ist nicht maskierbar*/"

    Das gibt es auch nicht in jeder Sprache. Steht sowas auch in der LST-Datei?

    0
  • S

    Kannste mir mal helfen und nen Auszug aus deiner Konf.-Datei posten/PN? Vielleicht komm ich ja damit selbst drauf, wie ich meinen Code verbessern kann... 😉

    Bye.

    0
  • C
     

    <language=cpp "C/C++ Code">
<!--
Im php-Code steht z.B.:
preg_match($color[1], $code, $matches);

Zu dem Format dieser Datei:
Die erste Zahl nach <color ist die Farbnummer.
0 = Kommentare
1 = Keywords
2 = Strings
3 = Präprozessor o.ä.
usw..
Das sind alles nur Vorschläge, dem php-Code ist egal, was es welcher Farbnummer zuordnet! 

Die zweite (die 1. alleinstehende Zahl) gibt das Element von $matches an, das eingefärbt werden muss.

Als Beispiel hier die Definitionen für Kommentare und Keywords.
-->
<color0 0>#(//((\n)|([^\n]))*)|(/\*(.*?)\*/)#s</color0>
<color1 1 "cpp_keywords.txt">#(?:(?:[^a-zA-Z_])|(?:^))("cpp_keywords.txt")(?:(?:[^a-zA-Z_])|(?:$))#</color1>

</language>

    Der String "cpp_keywords.txt" im regulären Ausdruck für Keywords wird durch die ganze Liste von Keywords ersetzt, die in der Datei cpp_keywords.txt steht.
    Das sieht dann so aus:

    #(?:(?:[^a-zA-Z_])|(?:^))(auto|bad_cast|bad_typeid|bool|break|usw...)(?:(?:[^a-zA-Z_])|(?:$))#

    Das Format ist sicher nicht ideal. Ich habe das nicht wirklich geplant, das ist eher beim coden gewachsen. 🙂
    Vielleicht wäre es auch besser, die Definitionen direkt in das Skript zu schreiben. Dann würde man sich den Overhead der externen Dateien sparen.

    0
Anmelden zum Antworten