Author Topic: Problem mit gelöschtem <style>  (Read 641 times)

Offline masju

  • Posts: 110
  • Gender: Male
Problem mit gelöschtem <style>
« on: April 26, 2017, 05:23:03 PM »
Hallo liebes Forum,

ich habe in einem anderen Forum (eines WB-Forks  :wink:) ein prima droplet gefunden, mit dem man mithilfe von leaflet eine OSM-Karte mit Marker auf seine Webseite zaubern kann. Zunächst lief es nicht, und nach einigem Nachforschen stellte es sich heraus, dass WebsiteBaker eine wichtige <style>-Anweisung
Code: [Select]
<style>
   #map { height: '.$height.'px; }
</style>   
aus dem Droplet-Output herausfiltert. Ich habe daraufhin testweise im Output-Filter (fast) alle Optionen ausgeschaltet aber trotzdem keinen Erfolg: Die drei Zeilen blieben verschwunden. Nun die Frage an die Spezialisten: Welche Funktion filtert in den Droplets <style>-Anweisungen heraus? Und warum?

Viele Grüße,
masju

Offline jacobi22

  • Posts: 5738
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Problem mit gelöschtem <style>
« Reply #1 on: April 26, 2017, 05:52:26 PM »
Bei mir ist eigentlich der Link zum CSS im Content der Auslöser eines White Screens. Lt W3C sollen solche Links in den Head-Bereich gelegt werden, was bei WB ab 2.8.3 SP6 durch den Filter CSStoHead passiert.
Der gleiche Filter versucht das auch mit den Style-Anweisungen, was aber nicht funktioniert, weil der Dropletcode erst nach den Filter CSStoHead generiert wird

verzichte auf diese Style-Anweisung im Droplet-Code und ändere die nachfolgende Zeile im Droplet nach diesem Muster hier

<div id="map" onload="javascript:init();" style="height:'.$height.'px"></div>

tut das Gleiche und ist auch noch kürzer  :wink:
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline masju

  • Posts: 110
  • Gender: Male
Re: Problem mit gelöschtem <style>
« Reply #2 on: April 26, 2017, 08:40:01 PM »
Hallo Jacobi,

vielen Dank für Deine wie immer sehr fundierten und hilfreichen Tipps! Es hat tatsächlich funktioniert, damit den CSS-toHead-Filter zu überlisten.  :-).
Ich war fälschlicherweise davon ausgegangen, dass die <style>-Anweisung irgendwie noch vom java-Script ausgewertet wird, deswegen habe ich mich nicht rangetraut  :roll:.

Viele Grüße,
masju

PS: Darf ich Deinen Code im anderen Forum posten?
« Last Edit: April 26, 2017, 08:47:29 PM by masju »

Offline jacobi22

  • Posts: 5738
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Problem mit gelöschtem <style>
« Reply #3 on: April 27, 2017, 03:27:50 PM »
Quote
PS: Darf ich Deinen Code im anderen Forum posten?

Sie werden dich in der Luft zerreißen   :wink:

Es ist dort nicht wirklich relevant, weil sie diese Filter nicht haben/benutzen
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

Offline jacobi22

  • Posts: 5738
  • Gender: Male
  • Support also via PM or EMail
    • Jacobi22
Re: Problem mit gelöschtem <style>
« Reply #4 on: April 28, 2017, 01:05:48 PM »
Siehste, sagte ich doch.... Thematik nicht verstanden oder bewußt etwas falsches erzählt

ein "onload" ist eine Javascript-Anweisung, in diesem speziellem Fall soll es die Initialisierung der Karte anschubsen, nachdem der gesamte Content geladen wurde (auf deutsch: lade die Karte mit den in der init-Funktion bereitgestellten Werten wie Longitute, Latitude, Zoom-Level usw). Solch Javascript funktioniert oder eben nicht und wenn nicht, bleibt das <div> eben leer.

ein Inline-Style ist dagegen eine CSS-Anweisung, die in jedem Browser funktioniert, der CSS kann.

Dadurch, das onload erst startet, wenn der Content fertig geladen wurde, wurde auch der inline-Style mit
 style="height:'.$height.'px" bereits ausgeführt. Der Block wird also mit diesem Code in jedem Fall mit der vordefinierten Höhe dargestellt, wäre aber beim Abbruch der Funktion init() ein leerer Block mit z.b. 500px Höhe.
Das der WB-Filter einen <style>-Block im <body>Tag herausfiltert, ist m.E. auch nicht in Ordnung ist, weil dieser <style>-Block W3C-conform ist. Die Sache steht auf der ToDo-Liste, läßt sich aber in jedem Fall mit einem Inline-Style (eine Style-Anweisung innerhalb eines HTML-Tags - mein Beispiel) umgehen.

Man übersieht "drüben", das die Browser mehr und mehr dazu übergehen, nicht-regelconforme Sachen wie eben ein <link> im <body>-Tag einfach zu ignorieren und dann steht ein Addon auch mal ohne CSS da. Wir versuchen, mit Hilfe des Filters das zu korrigieren, was einige Addon-Autoren über die letzten 6 Jahre überlesen haben, so alt ist die Empfehlung nämlich schon, das ein Link zu einer CSS-Datei in den <head>-Bereich gehört. Gleiche Problematik trifft auch für viele Addons zu, die vor Herausgabe dieser Empfehlung erstellt wurden. Vieles davon läßt sich mit einfachen Mitteln übergehen, wenn man statt einem Link zur zu ladenen CSS im <body>-Tag innerhalb der frontend.css des betreffenden Moduls einen CSS-import@ verwendet. Innerhalb eines Droplet würde ich das mit LoadonFly machen, Beispiele dazu gibt es in den mitgelieferten Standard-Droplets.

Man sollte vielleich noch erwähnen, das WB weder HTML, noch PHP, noch CSS erfunden hat und auch nicht über deren Richtung bestimmt. Wir versuchen nur, die vorgegebenen Regeln einzuhalten, was nicht immer einfach ist, weil es Folgen für die User hat und deren Engagement erfordert, wie das Beispiel strike Orientierung auf das Charset UTF8 gerade zeigt. Es betrifft vorrangig User aus dem deutschsprachigen Raum mit überwiegend deutschen Anbietern. Die Vorgabe der PHP-Group ist nunmal UTF8. Die Umstellung hat zu einigen Problem geführt, die oft eine Konvertierung der Datenbank erforderten. Manche haben im Forum oder per PN gefragt, manche sind abgewandert, weil man mit einem anderen System auch noch mit Latin1 arbeiten kann. Ich hab nicht mitgezählt, aber es gab Tage, da habe ich solch Konvertierung bei 2,3 Useraccounts gemacht, um die 500 werden es sicher gewesen sein. Diesen Schritt haben die Kollegen noch vor sich und im schlimmsten Fall kommt es dann konzentriert, weil z.b. große Anbieter wie Strato oder 1&1 schlagartig eine großer Usergruppe umstellen, i.d.R. nach einem Serverupgrade, so wie es im letztem Jahr mit der Einführung von PHP 7.x war. Die Regeln, die übergeordnete Stellen für uns machen, zu befolgen, ist nicht unbedingt ein Nachteil. Ich weiß, das ich meine aktuellen WB 2.10.x-Installationen getrost und unangetastet bis mindestens Ende 2020 laufen lassen kann, weil ich auf Grund dieser "Benutzerbevormundun gen" oder "strikter Regeleinhaltung" schon jetzt "gezwungen" war, meine benutzten Module auf die neueste PHP-Version und Mysql-Strikt upzugraden. Andere User machen die gleiche Erfahrung, finden andere Probleme und mit der Summe der Erfahrungen und Lösungen erstellt man dann ein Modul-Upgrade, das allen dient (siehe laufende Upgrades der Module wie mpForm, OneforAll, Bakery usw)
Woanders laufen nicht mal die jetzt neu erstellten Addons ohne Meckerei  :wink:
« Last Edit: April 28, 2017, 01:12:00 PM by jacobi22 »
Probleme sind da, um sie zu lösen, nicht, um nach Ausreden zu suchen.

 

postern-length