Servus zusammen!
folgendes, ich habe im moment etwa folgendes:
<p>Hallo, mach Schritt 1 und dann Schritt 2<noscript> und dann noch Schritt 3</noscript></p>Nun ist das ja allerdings nicht unter XHTML 1.0 erlaubt, da man den noscript-tag nicht in nen absatz packen darf.
hat vielleicht i-wer ne lösung anzubieten?
mfg und danke im voraus,
emil 
Ich meine, bei der XHTML-Variante des Arbeitsentwurfes für HTML5
ist das Element komplett gestrichen.
Die normale Lösung liegt darin, eine Seite ohne Skript, aber
komplett funktionsfähig anzubieten.
Auf diese skriptlose Variante wird dann das Skript losgelassen,
welches über das DOM die dekorativen Änderungen vornimmt.
Wenn man so vorgeht, ist noscript in der Tat komplett redundant,
weil die Skript-Variante ohnehin nur eine alternative Darstellung
ist, die nur in Erscheinung tritt, wenn Skriptinterpretation aktiv
ist.
Du mußt also einfach die Logik umdrehen, genau wie beim
Einsatz von CSS steckt die Information im (X)HTML und CSS oder
js ändern nur dekorative Aspekte oder erzeugen alternative
Ansichten oder Zugänge zum Inhalt.
ah klar,
capiscé…
danke
souuu, hab mir das jetz wie folgt gedacht:
und entsprechend 2 spans
den Javascript-Code habe ich im geschrieben - außerhalb einer funktion sollte er ja dann direkt beim laden der seite ausgeführt werden.
mein problem? - er macht nix 
sollte doch so eigentlich stimmen, nich?
Nein, stimmt nicht.
Lerne bitte die JS-Fehlerkonsole zu nutzen, wenn du mit JavaScript arbeiten willst.
Zum Testen eignet sich vorzugsweise Firefox - und wenn du noch mehr als nur eine reine Fehlerkonsole haben willst, dann empfiehlt sich das Add-On Firebug sehr stark.
Zudem spricht das ja nur einen dekorativen Aspekt an.
Wenn also jemand CSS deaktiviert hat und js aktiv, so sollte man
eigentlich nicht über das DOM die Eigenschaft display ändern
können (habe es aber nicht probiert). Sinnvoller wäre es also, per
DOM das komplette Element zu zernichten, nicht nur die Dekoration
ändern, wenn das wirklich nicht anwendbar sein soll, genau dann
wenn js aktiv ist.
ZERNICHTE!
Ich wollte es mir verkneifen
Schreib mal was in der GZ, sonst bin ich gezwungen, hier weiterzulesen
Schon ein Klassiker wie Schiller hat das Wort ‘zerrnichten’ gern
benutzt - sollten wir da zurückstehen? ;o)
Es gibt sooo viele schöner Wörter, die zunehmend aus der Mode
geraten …
jetz sag blos das stand mal im duden
zernichten… muss ich mir merken 
Ich habe hier einen Duden von 1996 herumstehen (schon mit neuer
Rechtschreibung zwischen Reform und Konterreform) - und da steht
es wenigstens drin ;o)
Da gibt es gar keinen Grund, sich zu echauffieren, pikiert zu sein
oder sich kodderig zu fühlen, das gehört zu den formidablen
Kleinoden unseres Sprachschatzes…
langsam wirds echt zu nem fall für die GZ würd ich meinen 
zu geil…
Ha! Ich wusste doch, dass das aus “Die Räuber” kam…
Ähäm, mal wieder zum Thema.
Dass das noscript-Tag in XHTML (Stricht) gestrichen worden bzw. invalide ist, ist einfach falsch. Es wurden nur einige, mir der Sinnhaftigkeit nicht ganz schlüssige, Einschränkungen vorgenommen.
Das Element noscript gehört seit XHTML zu %misc, sodass das umgebende Element ebenfalls %misc als Inhalt erlauben muss, was für den p-Tag nicht gilt, wohl aber beispielsweise das div-Element.
Dennoch wird deine Seite weiterhin invalide sein, da noscript kein %inline als Inhalt zulässt, wozu Text jedoch gehört. Du musst noch ein %block-Element drumherumpacken.
Wenn du all dies beachtest, sähe dein Code also folgendermaßen oder bedeutungsgleich aus: <div class="paragraph">Hallo, mach Schritt 1 und dann Schritt 2<noscript><p class="inline" und dann noch Schritt 3</p></noscript></div> Ist zwar semantisch der größte Mist, den man jemandem vorsetzen kann, aber es läuft. Evtl. lassen sich auch noch Elemente finden, die semantisch besser passen.
@hoffmann: Ich kann nach einer kurzen Googlesuche nicht den geringsten Hinweis auf ein Fehlen des Elements in HTML5 finden - normalerweise schläge sowas ja hohe Wogen. Wenn ich ehrlich bin, hielte ich das auch für den größten Mist, den das W3C verzapft hat, seit der Aufrechnung des Paddings auf die Elementbreite. Schließlich dient JavaScript nicht nur dem Klickibunti, sondern bietet ernsthafte Vorteile - AJAX könnte ich wohl komplett vergessen, wenn ich mein CMS auch für noscript-Nutzer ohne Einschränkungen auslegen müsste, denn welchen Sinn hat die Reservierung eines Artikels für einen Nutzer, während er sie bearbeitet, wenn dann ein noscript-Nutzer die Seite doch bearbeiten kann?
lg
Hi,
okay, danke. aber ich habs inzwischen schon anders gelöst.
ich habe es einfach anders herum angepackt: zuerst der html-code. wenn der fertig ist, eben diesen mit javascript manipulieren / benutzerfreundlicher machen.
achja - praktische anwendung findet das auf aurachtaler.de/bilder.php (übrigens auch genau die seite, auf der ich das zuerst mit lösen wollte 
)
mfg
emil
Genauer lesen 
hoffman sprach von der XML-Variante von HTML5.
dev.w3.org/html5/spec/Overview.h … pt-element
[quote]The noscript element must not be used in XML documents.
Note: The noscript element is only effective in the HTML syntax, it has no effect in the XHTML syntax.[/quote]
thorr - ich habe bei deinem Beispiel immer noch nicht mitbekommen,
wozu das noscript gut sein soll. Ob oder wer da was bearbeiten
darf, wirst du doch wohl auf dem server zwischenspeichern.
Ob da was gesperrt wurde, bekommt nach der Sperrung in der Tat
erst jeder Nutzer mit, wenn eine entsprechende Information vom
server angefordert wird - kann per AJAX eventuell schneller oder
zumindest mit weniger Datenaufkommen passieren.
Das Skript auf dem server jedenfalls sollte ja mindestens dann
gucken, ob eine Datei gesperrt ist, bevor sie jemand versucht zu
ändern. Gegebenenfalls hat dieser dann vergeblich gearbeitet oder
muß seinen Kram dann erstmal zwischenspeichern und nachher
einflicken, wenn die Datei nicht gesperrt ist. Ich denke so oder
ähnlich machen es auch die Wiki-Systeme oder auch CVS, sofern
die überhaupt was sperren und nicht nur warnen.
Bei intensiv kollektiv betreuten Dokumenten soll das ein lustiges
Geduldsspiel sein, bis man dann seinen eigenen Senf dazugeben
kann ;o) Ich denke, daß kann man auch nicht mit noscript, AJAX
oder sonstwas verhindern - allenfalls könnte man die Wartezeit
mit eingeblendeter Unterhaltung/Werbung besser überbrücken,
wenn man AJAX verwendet ;o)
Zur HTML5-Arbeitsgruppe: Da schlägt einiges hohe Wogen, was
die so verzapfen, die haben aber auch ein dickes Fell und Leute,
die es gewohnt sind, so lange vor sich hinzuargumentieren, daß
die interessierte Öffentlichkeit mit anderer Meinung nur noch
frustriert abwinkt und sich um anderes kümmert - einige Leute
dort, die dann überwiegend auch in der WHAT-WG sind, glauben
sowieso, den Stein der Weisen gefunden zu haben und die Weisheit
mit Löffeln gefressen zu haben - da kommt man schwer gegen an -
und ich und andere haben es an einigen Stellen versucht, die
augenfällig blödsinnig sind ;o)
Immerhin muß man zu ihrer Verteidigung sagen, daß für deren
Verhalten teils auch jene Autoren mitverantwortlich sind, die
gleichgültig grob fehlerhafte oder von der Struktur her
unsinnige Dokumente veröffentlichen und von den
browser-Anbietern dafür eine sinnvolle Anzeige erwarten.
Mit den Jahren bekommt man dann so eine Frustreaktion wie den
HTML5-Arbeitsentwurf, der nur allzu deutlich zeigt, daß die
eigentlich nicht mehr weiterwissen mit HTML, weil es aber so
stark genutzt wird, muß damit ja irgendwie weitergebastelt werden
…
[quote=“hoffmann”]Ob da was gesperrt wurde, bekommt nach der Sperrung in der Tat
erst jeder Nutzer mit, wenn eine entsprechende Information vom
server angefordert wird - kann per AJAX eventuell schneller oder
zumindest mit weniger Datenaufkommen passieren.
Das Skript auf dem server jedenfalls sollte ja mindestens dann
gucken, ob eine Datei gesperrt ist, bevor sie jemand versucht zu
ändern.[/quote] Von dieser Seite hast du natürlich vollkommen Recht. Beim Laden würde der Status überprüft werden und dann gegebenenfalls ein Hinweis erscheinen - wenn die Seite in der Bearbeitungsphase gesperrt wird, dann erfährt der Nutzer davon beim nächsten Speichern.
Allerdings liegt das Problem schon in der Ursache - wie soll ich eine Seite sperren, die keine Rückmeldung gibt, ob sie gerade bearbeitet wird? Ich könnte zwar dem Nutzer die Möglichkeit geben, die Seite für x Minuten zur Bearbeitung zu sperren, aber das würde meines Erachtens und meiner Erfahrung nach zu zu viel (auch ungewolltem) Missbrauch führen. Auch das Überprüfen des Bearbeitungszeitpunkts und das Vergleichen mit dem Aufruf des Formulars ist prinzipiell möglich.
Aber ich weiß nicht, ob das so viel Sinn ergibt, denn ich gehe nicht davon aus, dass einer der künftigen Nutzer kein JavaScript aktiviert haben wird, und ich bin auch für Fortschritt - man kann nicht auf ewig auf neue Technologien verzichten oder andauernd die Seiten so programmieren, dass sie mit möglichst wenig neuer Technologie auskommen.
Als neue Technologie würde ich java-script ja nicht gerade
bezeichnen. Das ist immerhin älter als CSS und war schon bei der
Entstehung damals bei netscape als privates Format unausgegoren,
instabil und sicherheitstechnisch bedenklich und eine
Zugänglichkeitsbarriere. Das hat sich ja über die Jahre nicht
wirklich geändert, obwohl da die browser-Anbieter ja jedes Jahr
zahlreiche Lücken in ihren Implementierungen schließen (sonst
könnten sie sich vermutlich mehr und die Implementierung
anderer Formate, wirklich neuer und schöner Technologien
kümmern, wenn das nicht wäre ;o)
Mag ja auch sein, daß bislang niemandem für XML-Strukturen
etwas plausibleres und einfacher nutzbares eingefallen ist, als
die java-script/ecma-script-Notation für das DOM - aber letztlich
ist die Sprache immer noch nichts, was sich wirklich als
’autorensicher’ erwiesen hat, in dem Sinne, daß die browser
da Fehler und Angriffe und Ungeschicklichkeiten von Autoren gut
wegstecken können. Ganz zu schweigen, daß man sich ja wohl
offenbar immer noch nicht einig darüber ist, wie die konkrete
Sprachumsetzung einheitlich bei allen browsern funktionieren soll
Insofern ist das eher ein alter Ansatz aus dem letzten Jahrtausend,
der letztlich immer noch nicht richtig ausgereift ist - was natürlich
auch daran liegen kann, das die ursprüngliche Idee von netscape
eben unausgegoren war und das Folgen für das ganze Format hat,
die man nicht mehr ausbügeln kann.
Wenn mehrere Leute ein Dokument betreuen, ergeben sich daraus
zwangsläufig Konflikte und Probleme, die im Zweifelsfalle eine
genaue Absprache der Autoren erfordern - zumindest bei den
Autoren wissenschaftlicher Publikationen klappt das meiner
Beobachtung nach über Jahrzehnte schon ganz gut.
Wikipedia etc bringt natürlich ganz neue Typen von Autoren
zusammen, wo man erst wieder neu herausfinden muß, wie die
sinnvoll zusammenarbeiten können (edit wars etc) - das ist mehr
ein soziales Problem, welches man auch mit noch so viel Technik
nicht wird lösen können.
Bei verantwortungsvollen Autorengruppen wird es weitgehend
unproblematisch sein, daß ein Autor selbst das Dokument für
eine Stunde bis einen Tag sperren kann, solange er daran arbeitet.
Oftmals reicht da auch ein Hinweis im Quelltext des Dokumentes
(Modell von wikibooks), an den sich andere Autoren dann zu
halten pflegen. Sobald ein Sperrvermerk vorliegt, ist ja derjenige
informiert, der es zur Bearbeitung aufruft. Da wäre nur der
seltene Fall problematisch, bei dem jemand die Seite zur
Bearbeitung aufruft, wonach jemand anderes Sekunden später
den Sperrvermerk einträgt. Bei einigen wiki gibt es auch einen
Warnhinweis mit 15-Minutenfrist für den Autor. Hat er das
Dokument zur Bearbeitung aufgerufen, trägt das System gleich
den Warnhinweis für andere ein. Der nächste, der das Dokument
binnen 15 Minuten zur Bearbeitung aufruft, bekommt den
Warnhinweis. Innerhalb der 15 Minuten muß der aktuelle Autor
die Vorschau der Seite aktualisieren, damit die Seite weiterhin
ihm zugeordnet bleibt und andere einen Warnhinweis bekommen.
Das schließt zumindest eine versehentliche Doppelbearbeitung
aus, wenn die Autoren kooperieren - wenn nicht, handelt es sich
ohnehin wie bereits gesagt mehr um ein soziales Problem.
