Author Topic: WB 2.8 Fehlermeldungen (war xhtml strict) (Read 32314 times)

Stefek · « **Reply #50 on:** July 14, 2009, 10:18:40 PM »

SM2 ist auf jeden Fall empfehlenswerter.
Außerdem könnte SM2 leicht erweitert werden, wenn man einiges im Core erweitert.

Gruß,
Stefek

doc · « **Reply #51 on:** July 14, 2009, 10:20:28 PM »

@Hans:

Quote from: Hans>NULL (Post 38)

Das Target-Problem wird per JS gelöst (alle externen Links erzeugen autom. ein neues Fenster)

Und prüft man im Template den verwendeten Doctype, könnte man zwei show_menu2 Aufrufe integrieren. Für XHTML Strict halt ohne target="[target]", für andere Doctyp mit target="[target]". So hätte man abhängig vom verwendeten Doctyp auch ohne Javascript valides HTML

Doc

StudioVerlag · « **Reply #52 on:** July 14, 2009, 10:29:44 PM »

@doc
Ich weiß, es ist die feinere Art, besser als manches JS-Gefrickelie, doch JS hat sich in den von mir angewandten Feldern bisher bewährt, haben sich doch auch hier Standards gebildet (ECMA).
Bisher hatte ich das Arbeiten mit Doctype wg. mögl. fehlender Crossbrowsertauglic hkeit vermieden, und mich nicht weiter damit beschäftigt. Da mittlerweile aber keine Probleme mehr zu befürchten sind, sollte ich wohl so langsam wieder mal umdenken. Alles was man längerfristig aussperrt kann zur Wissenslücke werden.
Wenn's Ressourcensparende und schneller Alternativen gibt, nutze ich die meistens auch.
Gruß, Hans>NUL

doc · « **Reply #53 on:** July 14, 2009, 11:13:59 PM »

Hi,

und wenn mal mit WB 3.0 vollständiger Support für XHTML 1.0 Strict möglich ist, würde es mich nicht wundern, wenn das W3C nach ca. 15 Jahren frickeln an HTML 5 einen ersten Entwurf verabschiedet. XHTML 2 scheint diesbezüglich nicht mehr die grössten Prioritäten zu haben (zumindest was den Etar angeht)

Doc

Luisehahne · « **Reply #54 on:** July 14, 2009, 11:17:20 PM »

So langsam weiss man nicht mehr worum es hier ging.

@Hans>NULL

Quote

Ich wäre schon froh, wenn die o.a. Änderung/en in einem neuen trunk einfließen würden.
Immer 'nen neuen trunk zu saugen und dann die eigenen Korrekturen jedesmal einzupflegen verleidet einem die Arbeit.

Gebt mir nochmal ein paar Infos, dann brauche ich nicht alles zu lesen. Ich habe übrigens bei Trunk SVN 985 angefangen. Mein Rechner läuft langsam über.

Dietmar

StudioVerlag · « **Reply #55 on:** July 14, 2009, 11:51:39 PM »

@doc
XHTML 1.0 Strict ist mir wg. der Nähe zu XML wichtig. "Ab zur XML-Umgebung" geht ohne Schwierigkeiten. Von dort aus "geht alles".
XHTML 1.1 macht Probleme mit Barrierefreiheit (Auch wenn die Probleme eher in den Monopolen des Geräte-Marktes für Eingeschränkte Nutzer zu sehen sind)
HTML 5 betrachte ich vorerst noch als weiteren Output für Websites (wie XML>xhtml).
Teilweise können's die Browser schon ( z.B. canvas )

@Luisehahne

Quote

So langsam weiss man nicht mehr worum es hier ging.

Oine Saite vorher steht's

Also Schritt für Schritt...

Ach, gaaanz vergessen GEWONNEN: Changeset 839

Gruß, Hans>NUL

doc · « **Reply #56 on:** July 15, 2009, 06:57:14 AM »

Hi,

Code von Hans aus Post 11 in diesem Thread:

Code: [Select]

<body>
<?php
if(function_exists(&#39;register_frontend_modfiles&#39;)) {
   register_frontend_modfiles(&#39;js&#39;); 
   echo "<noscript></noscript>";
} ?>
...

Was ist mit Javascript Dateien, die im Head eingebunden werden müssen damit Sie funktionieren? Gibt zwar nur wenige, aber es gibt Sie.

Kann auch Deine Fehlermeldung mit Einbindung von externen JS Dateien mittels <script type="text/javascript" src="xxx.js"></script> nicht nachvollziehen. Der W3C Validator meckert die verlinkte Seite (trotz JS Einbindung im head) nicht an (XHTML 1.0 Transitional, übrigens seit WB 2.7 so). Auch beim Umschalten auf Strict meckert er nicht über das <script> im Head. Auf W3C wurde ich diesbezüglich auch nicht fündig, auf dieser Seite auch nicht.

Doc

ruebenwurzel · « **Reply #57 on:** July 15, 2009, 08:00:19 AM »

Hallo,

vielleicht eine Idee für künftige Versionen:

frontend.js wie bisher im head einbinden
neue funktion für eine eine frontend_body.js integrieren, die das js dann vor </body> einbindet.

Damit dürften dann alle Optionen abgedeckt sein.

Matthias

susigross · « **Reply #58 on:** July 15, 2009, 08:14:07 AM »

Quote

Was ist mit Javascript Dateien, die im Head eingebunden werden müssen damit Sie funktionieren? Gibt zwar nur wenige, aber es gibt Sie.

Na das ist doch mit jquery alles kein Problem mehr. Da kann ich doch jede beliebige Datei nachträglich in den Header befördern mit $.insert

Man muß über das Template lediglich die beiden folgende Dateien in den Header laden, alle anderen kann man dann in seinem Modul nachladen.
jquery-1.3.2.js
jquery.insert.js

Luisehahne · « **Reply #59 on:** July 15, 2009, 08:18:18 AM »

Quote

Was ist mit Javascript Dateien, die im Head eingebunden werden müssen damit Sie funktionieren? Gibt zwar nur wenige, aber es gibt Sie.

Kann aber nur passieren, wenn mitten im Quelltext functionen aufgerufen werden, die dort enthalten sind. Also Umsteigen, Gedanken machen, sich von Alten lösen. Stillstand bedeuted Rückstand. Nach vorne schauen, sagt euch ein 58 Jahre alter Sack.

Dietmar

susigross · « **Reply #60 on:** July 15, 2009, 08:28:58 AM »

Quote from: Luisehahne on July 15, 2009, 08:18:18 AM

Quote
Was ist mit Javascript Dateien, die im Head eingebunden werden müssen damit Sie funktionieren? Gibt zwar nur wenige, aber es gibt Sie.

Kann aber nur passieren, wenn mitten im Quelltext functionen aufgerufen werden, die dort enthalten sind.

Ja der Anfang vom Modul ist dann aber wohl auch schon mitten im Quelltext, oder?

Luisehahne · « **Reply #61 on:** July 15, 2009, 08:39:53 AM »

Hatte ja das Problem mit dem Umsetzen einiger Adminfiles in Templates. Habe dann allen Javascript Code der im Quelltext stand ausgelagert. Wenn du es geschickt anfängst, brauchst du kein Javascript irgendwo mittendrin. man muss eben halt umdenken. Ist schwer, das weiss ich natürlich. Das ist genauso, die Umdenke in den 70ern Jahren, wo die Älternen dann sagten, "das ist Schweinekram". Da denkt heute keiner mehr drüber nach.

Dietmar

susigross · « **Reply #62 on:** July 15, 2009, 08:45:35 AM »

Quote

Habe dann allen Javascript Code der im Quelltext stand ausgelagert. Wenn du es geschickt anfängst, brauchst du kein Javascript irgendwo mittendrin. man muss eben halt umdenken. Ist schwer, das weiss ich natürlich.

Ich glaube du bist da wieder ein wenig neben dem Thema, Dietmar.
Wir sind uns wohl einig, dass JS am besten in externen Dateien aufgehoben ist.
Das Problem, wleches doc ansprach, war, das diese Dateien nachträglich in den Header geladen werden müssen.
Ich verstehe nicht, was deine Phrasen damit zu tun haben.

Luisehahne · « **Reply #63 on:** July 15, 2009, 08:53:23 AM »

Eben deswegen. Warum in den Header? Du kannst alles nach unten packen. Nichts ist mit jquery und seiner callbackfunction unmöglich. Wir müssen umdenken.

Aber ob oben oder unten, ist doch eigentlich unwichtig, es muss funktionieren. Das mag eben jeder für sich entscheiden. Du kannst ja auch mit Javascript unten, ein Jsavascriptfile oben setzen.

Dietmar

P.S.

Keiner versteht mich

doc · « **Reply #64 on:** July 15, 2009, 09:04:05 AM »

Hi,

denke auch, dass hier etwas am Thema vorbeigeredet wird

Dachte Hans>NULL ging es darum, dass der Validator bei XHTML meckert, wenn externe Scripte im Head-Bereiche eingebunden werden. Das konnte ich aber so nicht nachvollziehen siehe z.B. WB Hilfeseite. Dort wird externes JS im <head> Abschnitt eingebunden, dem W3C Validator ist es wurscht.

Also es geht nicht darum, alte JS-Scripte umzubauen oder sonstiges. Ich persönlich binde alles im Head ein oder lade JS per jQuery nach und hatte bisher noch nie Probleme mit dem W3C Validator und XHTML Transitional 1.0.

Doc

Luisehahne · « **Reply #65 on:** July 15, 2009, 09:26:14 AM »

Jau, Bin gerade dabei alles hier durchzulesen. Ziemlich durcheinander und unüberschaubar.

Dietmar

ruebenwurzel · « **Reply #66 on:** July 15, 2009, 01:47:51 PM »

Hallo,

==offtopic==

Hab das Thema mal geteilt, die login geschichte ist jetzt hier zu finden:
https://forum.WebsiteBaker.org/index.php/topic,14509.0.html

==ende offtopic==

Matthias

StudioVerlag · « **Reply #67 on:** July 15, 2009, 04:50:57 PM »

@doc
Erstmal zur Klärung eines Mißverständnisses, zudem ich anscheinend durch die nichtspezifische Nennung des Begriffs VALIDATOR beitrage.
Geprüft wird in der Reihenfolge:
1.) Prüfung auf Fehler in xhtml-strict/transitional
(css im Template und Editor bleiben in der ersten Phase draussen)
Die Prüfung geschieht mit eigener Software, W3C, Validome und anderen.
2.) Prüfung nach WAI -Mit eigener Software und Online-Tools auf eigenem Server
(http://www.w3.org/TR/1999/WAI-WEBCONTENT-19990505/)
Erst bei der Templateerstellung kommt dann noch BITV dazu
(Später dann Tests auf Screenreader, Lesesoftware usw. was aber mit WB nix mehr zu tun hat)

Das "<noscript></noscript>"-Problem wird bei der Prüfung nach WAi angezeigt
W3C zeigt "This document was successfully checked as XHTML 1.0 Transitional!"
Das "<noscript></noscript>"-Problem wird im Netz auch diskutiert.

Soll heißen, auch WB 2.7 war möglicherweise trotz "transitional" nicht WAI-gerecht, was ich aber nicht getestet habe.
Da wir aber mit WB 2.8 auch ein wenig aufräumen wollten, wo notwenig und machbar, und nicht weiter alte Probleme mitschleppen wollen (wir sind ja nicht MS) kommt's halt jetzt auf den Tisch. (Meine Mosereien kamen nicht aus schlechter Laune heraus, auch wenn man über den Stil streiten kann.)

Außerdem stelle ich meine "Feststellungen" bei der Fehlersuche gleichzeitig zur Disposition. Viele Werkzeuge sind ja nicht automatisch gleichbedeutend mit Qualität -auch wenn ich viel Zeit für die Auswahl aufgebracht habe. Praktisch läuft's so ab, daß auf Fehleranzeigen sehr oft das Nachlesen in den Dokus folgt. Wenn ich einem möglichen "false positiv" aufsitze ist das m.E. nicht nur für mich sinnvoll zu erkennen, sondern nutzt auch anderen.

Gruß, Hans>NUL

doc · « **Reply #68 on:** July 15, 2009, 05:59:36 PM »

Hi,

Quote from: Hans>NULL

Erstmal zur Klärung eines Mißverständnisses, zudem ich anscheinend durch die nichtspezifische Nennung des Begriffs VALIDATOR beitrage.

Nicht nur dadurch, auch durch den Topic (xhtml strict) und durch die Tatsache, dass in diesem Thread so nebenbei auch noch über andere Sachen "getratscht" wird

Zwecks Validatoren, da sollten Online-Validatoren verwendet werden, die jedem zugänglich sind. Wenn eigenes CSS oder Template, bitte posten und gegen dieses validieren, damit ALLE die gleiche Basis haben.

Denke Firefox mit dem Plugin "Webdeveloper Toolbar" ist ein guter Startpunkt. Dort sind folgende Validatoren verlinkt:
CSS: http://jigsaw.w3.org/css-validator/
HTML: http://validator.w3.org/
Section 508 / WAI: http://www.contentquality.com/

Sollten die verwendeten Validatoren von den oben genannten abweichen, müssen diese Explizit genannt werden. Anonsten hat man 20 verschieden Baselines, nichts ist nachvollziehbar und die paar aktiven Devs dürften dann auch schnell die Lust verlieren, allen Unkenruf nachzurennen

Doc

StudioVerlag · « **Reply #69 on:** July 15, 2009, 06:07:26 PM »

@doc
Na, dann nimm doch Online-Validatoren.
Die zusätzliche Software -habe ich an anderer Stelle im Forum gelistet, wenn's keinen interesssiert ist's nicht mein Problem- ist auch kostenlos. Man braucht sie nur downloaden und installieren.
WB 2.8 Accessibility Check (Tools)
Man kann aber auch ohne Software Testen, so wie bei BITV (das sind in Deutschland nämlich nur (teure) Empfehlungen).
Bezgl. WAI siehe das Datum: 1999 !
Gruß, Hans>NUL

Edit: Wie schon gesagt ist das Problem im Netz bekannt. Da ist das Streiten um Validatoren doch überflüssig. Ich gehe sowieso nur Fehlern nach, wo man auf Standards und Dokus zurückgreifen kann. Alles andere würde wie von Dir befürchtet in eine nicht mehr handhabbare Situation führen.

Edit 2: Was den Thread betrifft- Der geht auf auf (in etwa) Form xhtml strict kompatible? zurück (Nov. 2008) zurück und findet hier in v2.8 seine Fortsetzung, wenn auch unter etwas anderen Voraussetzungen. Bin ja nicht der einzige der mal wechselt oder wecheln muß (siehe Cookie-Beitrag)

Luisehahne · « **Reply #70 on:** July 15, 2009, 06:11:43 PM »

Ich nehme immer den Lokalen Validator von FF, der zeigt mehr an als der Online. WAI ist super, da gibst Error, die mir so nie aufgefallen wären und auch W3.org/check nicht angezeigt werden.

Im Grunde genommen wolle nwir alle dasselbe, auch wenn wir manchmal aneinander vorbei reden

Dietmar

doc · « **Reply #71 on:** July 15, 2009, 06:47:33 PM »

@Hans

Quote from: Hans>NULL

Die zusätzliche Software -habe ich an anderer Stelle im Forum gelistet, wenn's keinen interesssiert ist's nicht mein Problem- ist auch kostenlos. Man braucht sie nur downloaden und installieren.

Jo, nur hilft es nicht wirklich diese Liste woanders zu posten und hier stillschweigend als gegeben vorauszusetzen. Ein Link auf diese Liste hätte manches "Missverständnis" vermieden.

Quote from: Hans>NULL

Bin ja nicht der einzige der mal wechselt oder wecheln muß (siehe Cookie-Beitrag)

Zum Cookie-Beitrag gibt es auch aktuellere Infos.

Doc

StudioVerlag · « **Reply #72 on:** July 15, 2009, 06:56:19 PM »

Quote

und hier stillschweigend als gegeben vorauszusetzen

Ja, da muß ich Dir zustimmen. Werde den Status mit solchen Mitteilungen ergänzen.
Dann wäre es, bis auf die Gesprächskultur und einigen anderen Kleinigkeiten, fast wie in meinen fachbezogenen Mailing-Listen. Heißt: Streng neutral und über's Wetter darf auch nix gesagt werden

Für die Entwickler wäre es das Paradies
Doch bei solch' strengen Regeln würde sich das Forum hier wohl selbst zerlegen.

Gruß, Hans>NUL

Edit: Man kann es auch anders sehen. Die Liste ist JETZT versteckt, sie war sehr frühzeitig veröffentlicht, und wie schon gesagt, man braucht DIESE Tools nicht zwingend auf eigenem Rechner. Es erleichtert nur die Fehlersuche. Recherchieren gehört weiterhin zur Sorgfaltsplicht.

StudioVerlag · « **Reply #73 on:** July 15, 2009, 10:40:04 PM »

Betrifft
News-Modul
WB 2.8 RC1 trunk-r1068
Installiert auf Portable
News-Inhalt ist mit Kommentar versehen

WAI-Anpassung gemacht:
font-size: von Pixel auf em umgestellt
in frontend.css

Beanstandung:
1.) Wie gehabt "src" + "alt" attribute (leer)
<td rowspan="3" style="display: none"><img src="" alt="" /></td>

XHTML ist OK
Test nach WAI beanstandet diesen Zustand.

Dieser Fehler wird z.B. auch angezeigt, wenn die Felder im Header nicht mit Angaben versehen werden, also Beschreibung, Keywords etc. In Modulen mit Eintragsfeldern (wie Form) gibt es möglicherweise auch dieses Problem. Man müßte also bei fehlendem Inhalt die entsprechenden PHP-Befehle unterbinden, damit das nicht im html-Output erscheint, wäre da mein erster Gedanke.
(Mit "Rübenwurzel" absprechen, bitte)

Zur Zeit steht auch noch "das Wie" einer endgültigen Einbindung von JS aus. (Siehe das "<noscript></noscript>"-Problem), zumal man aus Performance-Gründen JS auch am Ende einer Seite einbinden/laden könnte. Da sind u.U. auch noch die JQuery-Spezies gefragt.

Eine für mich vorläufige funktionierende Lösung gibt's HIER

Probleme, die sich durch Verwendung von SM statt SM2 ergaben, werde ich noch beseitigen.

Gruß, Hans>NUL

Luisehahne · « **Reply #74 on:** July 15, 2009, 10:47:43 PM »

Hallo Hans>NUL,

Stimmt WAI meckert die fehlenden von dir beschriebenen Meta Tags an.

Zum 1. Punkt, ich nehme auch gerne die em, meine aber irgendwo gelesen zu haben, dass das auf pixel umgerechnet wird wegen der Bildschrimanzeige, macht dann wahrscheinlich der BRowser, was aber dann wieder Zeit kostet, nicht viel aber immerhin, es kann sich zusammen läppern. Was sagst du dazu?

Dietmar

News

Support WebsiteBaker

Your donations will help to:

You can donate by clicking on the button below.

Author Topic: WB 2.8 Fehlermeldungen (war xhtml strict) (Read 32314 times)

doc

StudioVerlag

doc

StudioVerlag

doc

susigross

susigross

susigross

doc

StudioVerlag

doc

StudioVerlag

doc

StudioVerlag

StudioVerlag