Dmitri Rettig: Braucht man den IMG-Tag?

0 71

Braucht man den IMG-Tag?

Dmitri Rettig
  • meinung
  1. 0
    Götz
    1. 0
      Dmitri Rettig
      1. 0

        ist GIF heute noch ein Thema?

        Bert
        • sonstiges
        1. 0
          Orlando
          1. 0
            Bert
            1. 0
              Kai Lahmann
              1. 0
                Bert
                1. 0
                  Fabian Transchel
                2. 0
                  Kai Lahmann
                  1. 0
                    Bert
                    1. 0
                      Kai Lahmann
                      1. 0
                        Bert
                        1. 0
                          Kai Lahmann
                          1. 0
                            Bert
                            1. 0
                              Kai Lahmann
                              1. 0
                                Bert
                                1. 0
                                  Kai Lahmann
                                  1. 0
                                    Bert
                                    1. 0
                                      Michael Schröpl
                                    2. 0
                                      Kai Lahmann
                                      1. 0
                                        Michael Schröpl
                    2. 0
                      Michael Schröpl
      2. 0
        AndreasW
      3. 0
        herbalizer
        1. 0
          Dmitri Rettig
  2. 0
    Sven Rautenberg
    1. 0
      Dmitri Rettig
    2. 0
      Björn Höhrmann
  3. 0
    emu
    1. 0
      herbalizer
      1. 0
        emu
        1. 0
          herbalizer
          1. 0
            emu
            1. 0
              Kai Lahmann
              1. 0
                molily
                1. 0
                  Kai Lahmann
      2. 0
        Dmitri Rettig
        1. 0
          Kai Lahmann
    2. 0
      Björn Höhrmann
      1. 0
        emu
        1. 0
          Björn Höhrmann
          1. 0
            emu
            1. 0
              Kai Lahmann
              1. 0
                emu
                1. 0
                  Kai Lahmann
                  1. 0
                    Dmitri Rettig
                2. 0
                  Dmitri Rettig
            2. 0
              Michael Schröpl
              1. 0
                emu
                1. 0
                  herbalizer
            3. 0
              Dmitri Rettig
              1. 0
                emu
                1. 0
                  Henryk Plötz
                2. 0
                  Dmitri Rettig
            4. 0
              Björn Höhrmann
              1. 0
                emu
  4. 0
    xwolf
    1. 0
      emu
      1. 0
        xwolf
        1. 0
          Orlando
        2. 0
          Kai Lahmann
        3. 0
          emu
        4. 0
          Dmitri Rettig
  5. 0
    Kai Lahmann
    1. 0
      Sven Rautenberg
      1. 0
        Kai Lahmann
      2. 0
        Stefan
        1. 0
          Kai Lahmann
        2. 0
          Henryk Plötz
    2. 0
      Dmitri Rettig

Hallo,

in XHTML und HTML 4.01 hat man viele unnützliche Tags [im Vergleich zu HTML 3] entfernt (<center> <font>). Aber ein Tag wurde vergessen, und zwar der IMG-Tag. Mit IMG bindet man ein Bildobjekt ein. Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

MfG Dmitri

  1. Hallo Dmitri!

    in XHTML und HTML 4.01 hat man viele unnützliche Tags [im Vergleich zu HTML 3] entfernt (<center> <font>).

    Das stimmt.

    Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

    Naja, vielleicht weil man dachte, daß man Bilder viel öfter braucht, als Applets oder so, und deshalb aus Gründen der Abwärtskompatibilität keine so starke Veränderung einbauen wollte.

    Also mich persönlich stört das img-Element nicht ;)

    MfG
    Götz

    1. Puh, kein "Feed The Troll" ...

      Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

      Also mich persönlich stört das img-Element nicht ;)

      Es geht eigentlich ums Prinzip: Alle Tags, die durch universällere ersetzt werden können - RAUS!

      Ich habe einen Vorschlag: Jeder bindet auf seine Seite gleich neben sinen "Gib GIF keine Chance" Banner einen weiteren - "Gib IMG keine Chance".

      Ich machs vor:

      <img src="gib_img_keine_chance.gif" ... />

      Gruß Dmitri

      1. Hi,

        "Gib GIF keine Chance" Banner

        mal ernsthaft, ist GIF heute noch ein Thema, oder hab' ich da Probleme mit der Pointe?

        Grüsse

        Bert

        1. Hi Bert,

          mal ernsthaft, ist GIF heute noch ein Thema, oder hab' ich da Probleme mit der Pointe?

          also zum Lachen ist mir nicht zumute...

          http://www.gnu.org/philosophy/gif.de.html
          http://www.comrecht.de/deutsch/recht/pub/gifkontroverse.htm
          http://burnallgifs.org/

          LG Orlando

          --
          SELF-TREFFEN 2002
          http://www.rtbg.de/selftreffen/
          http://www.megpalffy.org/temp/penneninhh.html

          1. Hi Orlando,

            mal ernsthaft, ist GIF heute noch ein Thema, oder hab' ich da Probleme mit der Pointe?

            also zum Lachen ist mir nicht zumute...

            http://www.gnu.org/philosophy/gif.de.html
            http://www.comrecht.de/deutsch/recht/pub/gifkontroverse.htm
            http://burnallgifs.org/

            tx für die Links.

            Ich dachte die Patente wären bereits heute nicht mehr gültig.

            Immerhin scheint es aber in naher Zunkunft soweit zu sein:
            "beantragten ihre Patente 1983, so daß sie 2003 auslaufen werden"
            Quelle (s.o.) http://www.gnu.org/philosophy/gif.de.html

            Grüsse

            Bert

            1. hi

              Immerhin scheint es aber in naher Zunkunft soweit zu sein:
              "beantragten ihre Patente 1983, so daß sie 2003 auslaufen werden"

              kein wunder, dass die Patente dann auslaufen - oder glaubt irgendwer, dass Ende 2003 noch irgendein normaldenkender Mensch statische GIFs verwendet? ;)

              Grüße aus Bleckede

              Kai

              1. Hallo,

                ..oder glaubt irgendwer, dass Ende 2003 noch irgendein normaldenkender Mensch statische GIFs verwendet? ;)

                wohl immer noch zu heiss heute, den hab ich jetzt auch nicht verstanden.

                In einigen Monaten ist das Problem eh gar keins mehr, wer soll denn
                nun auf Gifs aus welchen Gründen verzichten, zumal wenn heute die Gifs
                von Corel oder Photoshop wohl legal erzeugt werden, und wo ist da der
                relevante Unterschied von statischen und nicht statischen Gifs ?

                Grüsse

                Bert

                1. Hallo,

                  hi

                  ..oder glaubt irgendwer, dass Ende 2003 noch irgendein normaldenkender Mensch statische GIFs verwendet? ;)

                  wohl immer noch zu heiss heute, den hab ich jetzt auch nicht verstanden.

                  och, das ist ganz einfach: man wird stattdessen die (soweit ich weiß freien...) PNGs nehmen, denn die können schlicht mehr.

                  In einigen Monaten ist das Problem eh gar keins mehr, wer soll denn
                  nun auf Gifs aus welchen Gründen verzichten, zumal wenn heute die Gifs
                  von Corel oder Photoshop wohl legal erzeugt werden, und wo ist da der
                  relevante Unterschied von statischen und nicht statischen Gifs ?

                  legal ja, aber ineffizient, weil es eben PNG gibt...

                  Grüsse

                  Bert

                  Fabian

                2. hi

                  In einigen Monaten ist das Problem eh gar keins mehr, wer soll denn
                  nun auf Gifs aus welchen Gründen verzichten, zumal wenn heute die Gifs
                  von Corel oder Photoshop wohl legal erzeugt werden, und wo ist da der
                  relevante Unterschied von statischen und nicht statischen Gifs ?

                  GIF kann 256 Farben, einfache Transparenz und eben Animationen - Punkte 1 und 2 sind inzwischen in allen aktuellen Browsern auf PNG-Basis möglich, wobei hier _zusätzlich_ mehr Farben (klappt auch überall) und abgestufte Transparenz (das klappt überall außer IE) möglich sind. Damit spricht für statische GIFs wirklich nix mehr.

                  Grüße aus Bleckede

                  Kai

                  1. Hallo,

                    .. und abgestufte Transparenz (das klappt überall außer IE) möglich sind.

                    .. Damit spricht für statische GIFs wirklich nix mehr.

                    Du möchtest offenbar nicht nur die Realität 'IE', sondern auch die Tatsache ignorieren, dass Gifs oft kleiner ausfallen und schneller aufgebaut, also einfach 'wirtschaftlicher' sind.

                    Grüsse

                    Bert

                    1. hi

                      Du möchtest offenbar nicht nur die Realität 'IE',

                      nochmal zum mitschreiben:
                      auch der IE kann auf PNG-basis schon alles, was mit GIF geht, sogar mehr.

                      sondern auch die Tatsache ignorieren, dass Gifs oft kleiner ausfallen und schneller aufgebaut, also einfach 'wirtschaftlicher' sind.

                      -rw-r--r--    1 KaiL     KaiL         2189 2002-08-01 12:26 xweb.gif
                      -rw-r--r--    1 KaiL     KaiL         2396 2002-08-01 12:27 xweb.png

                      Self-Logo als GIF und PNG. Ob nun 200Byte da wirklich ein Argument sind extra auf ein Format zu setzen, dass so viele Begrenzungen hat? Mit eienr optimierten Farbpalette geht das sicherlich auch kleiner.. gleich mal versuchen

                      Grüße aus Bleckede

                      Kai

                      1. Hallo,

                        nochmal zum mitschreiben:

                        also nochmal für dich zum mitlesen, es war nämlich deine Idee, "abgestufte Transparenz (das klappt überall außer IE) möglich sind." so etwas als Argument für png zu bringen.

                        Toll was png alles kann, das klappt überall außer IE, und das andere kann man mit gifs auch oder fast, sagst du ja selbst: "der IE kann auf PNG-basis schon alles, was mit GIF geht" (..'sogar mehr') Ich könnte da auch äussern ' der IE kann auf PNG-basis weniger als was mit GIF und JPG geht', was man alles so schreiben kann...

                        Ob nun 200Byte da wirklich ein Argument sind extra auf ein Format zu setzen,

                        200 Byte sind allerdings ein Argument und bei einer preview mit vielen Bildern kriegt man schonmal 30k oder mehr auf einer Seite zusammen. Ausserdem scheint png länger zum Aufbau zu brauchen.

                        Und dann, was soll eigentlich die hier -sorry- sinnleere Formulierung "  extra auf ein Format zu setzen, " ?
                        Gif ist zunächst das vorhandene Format, es geht also wenn überhaupt darum dass du nur im Falle png extra auf ein Format setzen willst.

                        Allgemein trifft das sowieso nicht, man nimmt bei Bedarf png oder gif oder sonstwas.
                        Oder du hättest irgendeinen Sonderfall im Blick, serverseitig Bilder zu generieren und kannst nur ein Format erstellen, von sowas war aber bislang wohl nicht die Rede?

                        Grüsse

                        Bert

                        1. hi

                          Und dann, was soll eigentlich die hier -sorry- sinnleere Formulierung "  extra auf ein Format zu setzen, " ?

                          dein Problem ist, dass du mit allen Mitteln ignorierst, dass GIF 256 Farben ermöglicht, PNG aber afaik 24 Bit (bzw. 32 mit dem Alpha-Kanal). Was meinst du wohl, warum Spielefirmen so gerne die Screenshots als PNGs auf die Seite nageln... genau, weil die am besten aussehen. JPEG hat Komprimierungsverluste und GIF sieht schon bei banalsten Farbverläufen zum Kotzen aus.

                          Grüße aus Bleckede

                          Kai

                          1. Kai, das wird wohl nix mehr mit uns.

                            Und dann, was soll eigentlich die hier -sorry- sinnleere Formulierung "  extra auf ein Format zu setzen, " ?

                            dein Problem ist, dass du mit allen Mitteln ignorierst, dass GIF 256 Farben ermöglicht, PNG aber afaik 24 Bit (bzw. 32 mit dem Alpha-Kanal). Was meinst du wohl, warum Spielefirmen so gerne die Screenshots als PNGs auf die Seite nageln... genau, weil die am besten aussehen. JPEG hat Komprimierungsverluste und GIF sieht schon bei banalsten Farbverläufen zum Kotzen aus.

                            Aber mit dem Lesen und dem Verstehen der Zusammenhänge klappt es wohl noch?

                            ' man nimmt bei Bedarf png oder gif oder '

                            Hast du das übersehen?

                            Gleich nochmal. Redundanz soll manchmal geholfen haben.

                            ' man nimmt bei Bedarf png oder gif oder '

                            und:

                            'was mit GIF und JPG geht'

                            Was da u.a. auch draus folgt: wenn ich etwas "mit allen Mitteln ignorieren" würde, würde ich einen Bedarf ebenfalls mit allen Mitteln ignorieren statt ihn zu erwähnen.

                            "dein Problem" ist offenbar fehlende Bereitschaft ernsthaft zu kommunizieren.
                            Ob irgendeine religiösen Bekehrung dahintersteckt oder Bequemlichkeit wäre Spekulation, ich wollte dich auch nicht beleidigen, aber bei dem trabenden Unsinn den du hier ablässt..

                            Und jetzt also nochmal ein anderes Thema, jetzt die Farben und die Kompressionsartefakte, auch da ist nur bei wenigen Bildern png vorteilhaft, es ist meist grösser als gif oder jpg ausser man reduziert die Farben soweit dass " banalsten Farbverläufen zum Kotzen aus."-sehen. Und mit dem Zeitaufwand einer extra Farbtabelle für ein png ist ein jpg schon schneller selektiv bearbeitet sodass die Kompression in Bildbereichen unterschiedlich zuschlägt. Das Ergebnis ist dann ansprechender als das png und liegt je nach Situation bei 10-40% Dateigrösse des png, jpg durch png grundsätzlich ersetzen zu wollen ist noch irrwitziger als die Geschichte mit den gifs, nur dass bei den Gifs die LZH Geschichte als Argument möglich war..

                            Grüsse

                            Bert

                            1. hi

                              ' man nimmt bei Bedarf png oder gif oder '

                              also nochmal die Verwendungszwecke...:

                              a) weniger als 256 Farben, jedes Pixel soll wie vorher aussehen -> GIF oder PNG (GIF 10% kleiner wenn man aus Gimp heraus ohne irgendwie groß nachzudenken und Optimierungen neu speichert)
                              b) mehr als 256 Farben, jedes Pixel soll wie vorher aussehen -> PNG
                              c) mehr als 256 Farben, Verfälschungen werden geduldet -> JPEG

                              ...sind wir uns da einig?

                              ein JPEG wird übrigens _nie_ dem unkomprimierten Original ähnlicher sehen als ein PNG-Bild, wenn man die Farbtiefe nicht runterdreht, weil ein PNG eben die genaue Information speichert, JPEG nur 'so ungefähr' wenn auch idr. recht erfolgreich, wenn man mit dem Platz nicht zu sehr geizt.

                              Du hällst dich übrigens mit aller Kraft an der Dateigröße fest. Wenn ich 'nen Screenshot habe, wo z.B. probleme mit der Gamma-Korrektur deutlich werden sollen, führt _NICHTS_ an einem PNG-Bild vorbei, da ist die Dateigröße scheißegal, es ist nur eben Typ b aus der Liste da oben.
                              Nächstes Beispiel Fotogalerieen - auch hier würde ich deutlich Größere Dateien zu gunsten eines perfekten Bildes in Kauf nehmen.
                              Die einfachen Grafiken, wie z.B. die Icons von SelfHTML sind übrigens wirklich als GIF am besten aufgehoben, aber ist es eine Totsünde, wenn man da vielleicht mal Icons will, die mehr als 256 Farben haben..?

                              Grüße aus Bleckede

                              Kai

                              1. Hallo,

                                ' man nimmt bei Bedarf png oder gif oder '

                                also nochmal die Verwendungszwecke...:

                                a) weniger als 256 Farben, jedes Pixel soll wie vorher aussehen -> GIF oder PNG (GIF 10% kleiner wenn man aus Gimp heraus ohne irgendwie groß nachzudenken und Optimierungen neu speichert)
                                b) mehr als 256 Farben, jedes Pixel soll wie vorher aussehen -> PNG
                                c) mehr als 256 Farben, Verfälschungen werden geduldet -> JPEG

                                ...sind wir uns da einig?

                                das sind z.Zt. keine realistischen bzw. im Internet häufigen Verwendungszwecke, ich halte mich nicht als Selbstzweck an der Dateigröße fest, sondern diese ist eine wichtige Sollanforderung.
                                Dabei kann die Relation von Grösse und Qualität bei den Formaten betrachtet werden, und die Anforderung beste Qualität mit Bildgrössen von 800k oder so muss wohl allgemein nicht weiter betrachtet werden.
                                Der Einsatzzweck 'Internet', die (nicht) möglichen Übertragungsraten, die Kosten für Traffic, die Usability ergeben je nach Situation bestimmte Dateigrössen, trotz dsl.
                                Ich habe mir wiederholt sehr sorgfältig 'png' für den Einsatz in verschiedenen Projekten angeschaut, das Ergebnis war immer sehr enttäuschend, abgesehen davon dass es noch vereinzelte Scherzkekse mit Netscape 4.01 gibt der erstmal kein png unterstützt.
                                Bei Dateigrössen unter 1k ist eigentlich nur gif einsetzbar.
                                Im Bereich um 10k konnte ich bei einem Projekt neben 93 jpg immerhin 29 png und 6 gif einsetzen, dabei war der Aufwand für die png eigentlich zu hoch, und beim Ergebnis bin ich zudem unsicher ob nicht die png länger laden bzw. rechnen lassen.
                                Bildformat und Filegrösse waren in etwa vorgegeben. Die png und gif waren erheblich farbreduziert um überhaupt mithalten zu können.
                                Bei grösseren Dateien 40-160k z.B. Fotogalerieen habe ich eigentlich immer jpg genommen, sogar bei Bildmaterial wo ich aufgrund der Anforderungen wie z.B. Schärfe fest mit gif oder png gerechnet hatte.
                                Das ärgerlich bei jpg sind m.E. weniger allgemeine Farbverfälschungen, Unschärfe oder Aetefakte, sondern die Farbveränderung bei kleinen Flächen mit in dem Bild sonst fehlenden Farben, muss bei stärkerer Kompression notfalls korrigiert werden. Aber waren da nicht Weiterentwicklungen wie 'lurawave' im Gespräch?

                                Grüsse

                                Bert

                                p.s.
                                wieviel Pixel soll denn ein Icon haben, um mit mehr als 256 Farben zu irgendeiner Darstellung zu kommen?
                                x3.gif z.B. hat nur 150 Pixel, geht schonmal nicht. xview.gif (Icon oder schon Logo?) auch nur 600 Pixel, wenn da keine zwei Pixel den gleichen Farbton haben sollten...

                                1. hi

                                  das sind z.Zt. keine realistischen bzw. im Internet häufigen Verwendungszwecke, ich halte mich nicht als Selbstzweck an der Dateigröße fest, sondern diese ist eine wichtige Sollanforderung.

                                  das ist seltsam - während also am HTML-code alles getan wird, um ihn wie einen Luktbalon aufzupusten, regt man sich bei Bildern über das bischen auf? Ich wette mit dir, dass ich bei mindestens 90% aller Websites diese 200Byte schon auf der Startseite wieder zurückholen kann, wenn man den HTML-Code entmüllt. Es ist schon ziemlich lächerlich, wenn man hier über das kleinere Bildformat diskutiert, wenn der HTML-Fuscher hunderte von Zeilen sinnlosem und redundantem JS- und HTML/Tabelle-Code aufstapelt - persönliches Highlight ist immer noch das Suchfeld bei http://www.heise.de/newsticker/. Übrigens ein tolles Beispiel für codeverschwendung in ganzen - wer da nicht 10 Byte pro Zeile findet, sucht schlecht oder hat keine Ahnung.

                                  [..] abgesehen davon dass es noch vereinzelte Scherzkekse mit Netscape 4.01 gibt der erstmal kein png unterstützt.

                                  falsch. Er kann zwar gänzlich keine Transparenz, aber nicht-transparente PNGs gehen.

                                  Grüße aus Bleckede

                                  Kai

                                  1. Hallo,

                                    das ist seltsam - während also am HTML-code alles getan wird, um ihn wie einen Luktbalon aufzupusten, regt man sich bei Bildern über das bischen auf? Ich wette mit dir, dass ich bei mindestens 90% aller Websites diese 200Byte schon auf der Startseite wieder zurückholen kann, wenn man den HTML-Code entmüllt. Es ist schon ziemlich lächerlich, wenn man hier über das kleinere Bildformat diskutiert, wenn der HTML-Fuscher hunderte von Zeilen sinnlosem und redundantem JS- und HTML/Tabelle-Code aufstapelt - persönliches Highlight ist immer noch das Suchfeld bei http://www.heise.de/newsticker/. Übrigens ein tolles Beispiel für codeverschwendung in ganzen - wer da nicht 10 Byte pro Zeile findet, sucht schlecht oder hat keine Ahnung.

                                    tolles Argument, esst Spanplatte, andere Dinge auf unseren Tellern sind ja auch keine Lebensmittel?
                                    Waren es deine 200 byte? Jedenfalls hatte ich die 200 oder was auch immer bei einer preview-site auf 40k oder so pro Seite hochgerechnet.
                                    Ich bin auch für kompakten angepassten code, also kein zumüllen mit "JS-Bibliotheken", argerlich wenn die Entwicklungen am Rande von xml, oder Sachen wie CMS den normalen html-code vergrössern.
                                    Ansonsten wird html-code je nach Zugang in Netz teilweise komprimiert übertragen, im Gegensatz zu Bildern, somit ist es nicht ganz so tragisch.
                                    Den heise-code find ich aber noch nicht ganz so wild, sind wohl auch nur 36k, zumal die offenbar einen schnellen Server haben.

                                    [..] abgesehen davon dass es noch vereinzelte Scherzkekse mit Netscape 4.01 gibt der erstmal kein png unterstützt.

                                    falsch. Er kann zwar gänzlich keine Transparenz, aber nicht-transparente PNGs gehen.

                                    nein, du irrst. Der 4.01 der damals erhältlich war kann das nicht. Vielleicht meinst du ab 4.03, oder hast etwas am 4.01 verändert.

                                    Grüsse

                                    Bert

                                    1. Hi Bert,

                                      [..] abgesehen davon dass es noch vereinzelte
                                      Scherzkekse mit Netscape 4.01 gibt der erstmal
                                      kein png unterstützt.
                                      falsch. Er kann zwar gänzlich keine Transparenz,
                                      aber nicht-transparente PNGs gehen.
                                      nein, du irrst. Der 4.01 der damals erhältlich war
                                      kann das nicht. Vielleicht meinst du ab 4.03, oder
                                      hast etwas am 4.01 verändert.

                                      PNG und "Content-Encoding: gzip" wurden (offenbar
                                      gemeinsam) zwischen 4.03 und 4.06 eingebaut (4.04 und
                                      4.05 gibt es m. E. nur in einigen wenigen speziellen
                                      Sprachen, die habe ich nicht getestet).

                                      Viele Grüße
                                            Michael

                                    2. hi

                                      Waren es deine 200 byte? Jedenfalls hatte ich die 200 oder was auch immer bei einer preview-site auf 40k oder so pro Seite hochgerechnet.

                                      selbst die kann man über ein komplettes Projekt rausholen (mal davon abgesehen, dass das über ISDN "gigantische" 5s ladezeit sind)

                                      Ich bin auch für kompakten angepassten code, also kein zumüllen mit "JS-Bibliotheken", argerlich wenn die Entwicklungen am Rande von xml, oder Sachen wie CMS den normalen html-code vergrössern.

                                      sehr richtig. Wobei das bei heise wohl auch amoklaufendes CMS ist... nur komisch, dass die CMS-Entwicklungen, die mein PHP-Coder zustandebringt nichts an Müll im Code hinterläßt!

                                      Ansonsten wird html-code je nach Zugang in Netz teilweise komprimiert übertragen, im Gegensatz zu Bildern, somit ist es nicht ganz so tragisch.

                                      eh - das passiert leider immer noch seeeeeeeeehr selten (heise übrigens afaik nicht)

                                      Den heise-code find ich aber noch nicht ganz so wild, sind wohl auch nur 36k, zumal die offenbar einen schnellen Server haben.

                                      da (also bei eienr Seite, die wohl viele als Startseite haben) sind 36KB (von deinen wohl 20 unnütz sind) egal, bei 'ner Bilderseite sind 40KB 'ne Katastrophe..?

                                      nein, du irrst. Der 4.01 der damals erhältlich war kann das nicht. Vielleicht meinst du ab 4.03, oder hast etwas am 4.01 verändert.

                                      achso, die GANZ alten Galoschen... Davon haste aber einen pro Monat, oder? Mal davon abgesehen, dass es außer Dummheit und Faulheit wohl keinen Grund für diese alte Version gibt (die übrigens auch nicht mit kompribiertem HTML-Code zurechtkommt)

                                      Grüße aus Bleckede

                                      Kai

                                      1. Hallo Kai,

                                        nein, du irrst. Der 4.01 der damals erhältlich war kann
                                        das nicht. Vielleicht meinst du ab 4.03, oder hast etwas
                                        am 4.01 verändert.
                                        achso, die GANZ alten Galoschen... Davon haste aber einen pro
                                        Monat, oder? Mal davon abgesehen, dass es außer Dummheit und
                                        Faulheit wohl keinen Grund für diese alte Version gibt (die
                                        übrigens auch nicht mit kompribiertem HTML-Code zurechtkommt)

                                        ... aber glücklicherweise auch keinen solchen anfordert - im
                                        Gegensatz zu 4.06-4.08, die das leider tun und es wirklich besser
                                        lassen sollten.

                                        Viele Grüße
                                              Michael

                    2. Hi Bert,

                      .. Damit spricht für statische GIFs wirklich nix
                      mehr.
                      Du möchtest offenbar nicht nur die Realität 'IE',
                      sondern auch die Tatsache ignorieren, dass Gifs oft
                      kleiner ausfallen und schneller aufgebaut, also
                      einfach 'wirtschaftlicher' sind.

                      ich bin seit einem entsprechenden Thread vor einigen
                      Wochen dabei, nach und nach sämtliche GIFs auf PNG
                      umzustellen.

                      Meine GIFs haben ausnahmslos 16 oder weniger Farben,
                      nutzen also das ureigenste Feld von GIF und keine der
                      in PNG möglichen zusätzlichen features.
                      Dennoch habe ich ausnahmslos bei jedem GIF ab einer
                      bestimmten Dateigröße (die irgendwo bei 600 Bytes
                      liegt) aufwärts durch die Umstellung auf PNG Einspa-
                      rungen erzielt (manchmal nur knapp, teilweise aber
                      20-30%).
                      Meine Stichprobe ist noch nicht wirklich aussagekräf-
                      tig (nur knapp über 100 Bilder), aber der Trend hat
                      mich doch positiv überrascht.

                      Ich habe keine Details über das PNG-Format parat,
                      glaube mich aber zu erinnern, daß der Komprimierungs-
                      ansatz dort grundsätzlich mächtiger ist (wenn ich mich
                      nicht irre: GIF komprimiert Zeilen, PNG komprimiert
                      Flächen).
                      Deshalb erwarte ich eigentlich generell bei der Um-
                      stellung auf PNG Einsparungen und lediglich bei sehr
                      kleinen Bildern einen eventuellen zusätzlichen Over-
                      head aufgrund ggf. komplexerer Basistabellen etc.

                      Viele Grüße
                            Michael

      2. Es geht eigentlich ums Prinzip: Alle Tags, die durch universällere ersetzt werden können - RAUS!

        Du meinst, nur noch object, div, span, form, input und a?

        So ein Schwachsinn!

      3. Puh, kein "Feed The Troll" ...

        Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

        Es geht eigentlich ums Prinzip: Alle Tags, die durch universällere ersetzt werden können - RAUS!

        Dann kannst du HTML gleich auf 3 Elemente reduzieren: object, div, input.
        Text- und Tabellenelemente kann man im div beliebig formatieren und bei input kann man ja auch die textarea-Funktion über ein Attribut verwirklichen.
        Aber so solls ja nicht sein. Schließlich sind Elemente wie p, q, acronym oder auch Tabellen Elemente die eine bestimmte Bedeutung mit sich herumtragen. Und so sehe ich das mit Bildern, wenn sie tatsächlich als Information enthaltendes Element verwendet werden. Object ist halt für Multimedia oder eben nicht in HTML ausdrückbare Inhalte da.

        Gruß Herbalizer

        1. Hallo,

          Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

          Es geht eigentlich ums Prinzip: Alle Tags, die durch universällere ersetzt werden können - RAUS!

          Dann kannst du HTML gleich auf 3 Elemente reduzieren: object, div, input.
          Text- und Tabellenelemente kann man im div beliebig formatieren und bei input kann man ja auch die textarea-Funktion über ein Attribut verwirklichen.
          Aber so solls ja nicht sein. Schließlich sind Elemente wie p, q, acronym oder auch Tabellen Elemente die eine bestimmte Bedeutung mit sich herumtragen. Und so sehe ich das mit Bildern, wenn sie tatsächlich als Information enthaltendes Element verwendet werden. Object ist halt für Multimedia oder eben nicht in HTML ausdrückbare Inhalte da.

          So war das auch nicht gemeint. P ist ein logisches Element, zum Formatieren von Absätzen. Solche elemente dürfen bleiben. [So wird es auch von W3C gemacht]. Aber das IMG-Element passt nicht in die Reihe der Vereinfachungen.

          MfG Dmitri

  2. Aloha!

    in XHTML und HTML 4.01 hat man viele unnützliche Tags [im Vergleich zu HTML 3] entfernt (<center> <font>). Aber ein Tag wurde vergessen, und zwar der IMG-Tag. Mit IMG bindet man ein Bildobjekt ein. Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

    Das <img>-Element muss bleiben. Allerdings wird es viel zu häufig benutzt (naja, natürlich nur deshalb, weil alte Browser anders damit nicht klarkommen).

    Im Prinzip sind nämlich alle dekorativen Grafiken überflüssig. Lediglich diejenigen Grafiken, die inhaltlichen Zwecken dienen, sollten per <img> eingebunden werden. Alle anderen gehören IMO als CSS-Hintergrundbild integriert.

    Wie immer bei so schönen Forderungen bleibt die Realität weit hinter der Theorie zurück. :)

    - Sven Rautenberg

    1. Hi,

      Im Prinzip sind nämlich alle dekorativen Grafiken überflüssig. Lediglich diejenigen Grafiken, die inhaltlichen Zwecken dienen, sollten per <img> eingebunden werden. Alle anderen gehören IMO als CSS-Hintergrundbild integriert.

      Aha, ich verstehe ... mal schnell ein Beispiel für die anderen:

      <div id="headline"><img src="/images/titel.jpg" width="600" height="120" alt="www.rtbg.de"></div>

      ... Das hier ist schlampig gemacht http://www.rtbg.de/selftreffen

      Irgendwie ist nie jemand mit mir einverstanden, das Web zu verbessern ;-(

      Gruß Dmitri

    2. in XHTML und HTML 4.01 hat man viele unnützliche Tags [im Vergleich zu HTML 3] entfernt (<center> <font>). Aber ein Tag wurde vergessen, und zwar der IMG-Tag. Mit IMG bindet man ein Bildobjekt ein. Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

      Das <img>-Element muss bleiben.

      Warum?

  3. Hallo!

    in XHTML und HTML 4.01 hat man viele unnützliche Tags [im Vergleich zu HTML 3] entfernt (<center> <font>).

    Ja, und langsam sollte das W3C auch vom Modul Presentation Abstand nehmen. Von Attributen wie align sowieso.

    Interessant fände ich aber neue Attribute zum Beispiel für Aussprache, etc.

    Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

    Daran habe ich noch gar nicht gedacht - aber stimmt eigentlich. Dann könnte man die verweissensitiven Flächen im <param>-Tag unterbringen.

    Die ganze Idee ist natürlich hauptsächlich etwas für Leute, die Anhänger der reinen logischen Auszeichnungssprache sind, so wie ich ;-)

    emu
    [...]

    1. Hallo!

      in XHTML und HTML 4.01 hat man viele unnützliche Tags [im Vergleich zu HTML 3] entfernt (<center> <font>).

      Ja, und langsam sollte das W3C auch vom Modul Presentation Abstand nehmen. Von Attributen wie align sowieso.

      Interessant fände ich aber neue Attribute zum Beispiel für Aussprache, etc.

      Hm, wie das? Du haust Element und Attribute für visuelles MarkUp raus und führst welche für aurales ein? Versteh ich nicht. Ausserdem gibt schon http://www.w3.org/TR/REC-CSS2/aural.html.

      Die ganze Idee ist natürlich hauptsächlich etwas für Leute, die Anhänger der reinen logischen Auszeichnungssprache sind, so wie ich ;-)

      Was ist an bedeutungslosen anonymen Elementen logisch?

      Gruß Herbalizer

      1. Hallo!

        Interessant fände ich aber neue Attribute zum Beispiel für Aussprache, etc.

        Hm, wie das? Du haust Element und Attribute für visuelles MarkUp raus und führst welche für aurales ein? Versteh ich nicht. Ausserdem gibt schon http://www.w3.org/TR/REC-CSS2/aural.html.

        Ich meine den Aussprachehinweis nach IPA-Lautschrift - wo etwas gehört für mich zur Auszeichnung, etwa so wie das title-Attribut.

        Mit CSS geht so etwas nicht und wäre auch nicht sinnvoll.

        emu
        [...]

        1. Hi!

          Ich meine den Aussprachehinweis nach IPA-Lautschrift - wo etwas gehört für mich zur Auszeichnung, etwa so wie das title-Attribut.

          Du meinst die LAutschrift wie sie in Wörterbüchern verwendet wird. Dann nimm halt Ruby http://www.w3.org/TR/ruby/

          Gruß Herbalizer

          1. Hallo!

            Ich meine den Aussprachehinweis nach IPA-Lautschrift - wo etwas gehört für mich zur Auszeichnung, etwa so wie das title-Attribut.

            Du meinst die Lautschrift wie sie in Wörterbüchern verwendet wird.

            Ja.

            Dann nimm halt Ruby http://www.w3.org/TR/ruby/

            Ein interessantes Konzept, ich hätte <ruby> in eine völlig andere Schublade gesteckt. Danke, jetzt weiß ich das auch.

            Kurios daran ist, dass es weder Opera noch Mozilla kennen, dafür Internet Explorer etwas damit anfangen kann - aber auch nicht allzuviel.

            Ein Skandal - wann wird Mozilla diesen schrecklichen Zustand ändern? ;-)

            emu
            [....]

            1. hi

              Ein Skandal - wann wird Mozilla diesen schrecklichen Zustand ändern? ;-)

              willste meine Ruby-Implementierung haben? ;)
              ...nur rbspan="" fehlt noch (sind 'nen paar CSS-Regeln)

              Grüße aus Bleckede

              Kai

              1. Hallo, Kai!

                [Ruby & Mozilla]

                Ein Skandal - wann wird Mozilla diesen schrecklichen Zustand ändern? ;-)

                willste meine Ruby-Implementierung haben? ;)
                ...nur rbspan="" fehlt noch (sind 'nen paar CSS-Regeln)

                Das würde mich interessieren. CSS-Regeln, die den Ruby Text relativ zur Ruby Base ausrichten?
                Auf http://www.akatsukinishisu.net/itazuragaki/2001_10.html#ruby_for_Mozilla_3 habe ich etwas ähnliches gefunden.
                Auf display:table-(row|header|footer)-group etc. wäre ich nicht gekommen, sieht aber recht elaboriert aus, werde ich einmal ausprobieren (momentan habe ich Mozilla gelöscht, weil 1.1x nicht target="_blank" als Tabs öffnen kann, bzw. kenne ich die korrespondierende prefs.js-Einstellung nicht, da muss ich wohl wieder auf 1.0 oder 1.0RCx umsteigen).
                Hat jemand Erfahrung mit http://www.cc-net.or.jp/~piro/xul/_rubysupport.html? Im Archiv wurde das scheinbar auch schon einmal angesprochen.

                Achja, Kai, seit Tagen kann ich mozilla.linuxfaqs.de nicht erreichen... "ein herber Verlust".

                Grüße,
                Mathias

                1. hi

                  Auf http://www.akatsukinishisu.net/itazuragaki/2001_10.html#ruby_for_Mozilla_3 habe ich etwas ähnliches gefunden.

                  jup, ist 'ne überarbeitete Version davon. Einige Kleinigkeiten habe ich verändert, u.a. das fehlerhafte 'rbspan' ganz raus.

                  weil 1.1x nicht target="_blank" als Tabs öffnen kann, bzw. kenne ich die korrespondierende prefs.js-Einstellung nicht, da muss ich wohl wieder auf 1.0 oder 1.0RCx umsteigen).

                  die Pref ist raus, weil sie nicht funktioniert hatte...
                  user_pref("browser.tabs.opentabfor.windowopen", true);
                  ..der müsste es sein - zumindest ist er bei mir noch in den Prefs, als root (wo ich im Dialog das gleiche eingestellt habe) aber nicht.

                  Achja, Kai, seit Tagen kann ich mozilla.linuxfaqs.de nicht erreichen... "ein herber Verlust".

                  Serverumzug...

      2. Hi,

        in XHTML und HTML 4.01 hat man viele unnützliche Tags [im Vergleich zu HTML 3] entfernt (<center> <font>).

        Interessant fände ich aber neue Attribute zum Beispiel für Aussprache, etc.

        Hm, wie das? Du haust Element und Attribute für visuelles MarkUp raus und führst welche für aurales ein? Versteh ich nicht. Ausserdem gibt schon http://www.w3.org/TR/REC-CSS2/aural.html.

        So etwas ist gemeint:

        <p audio-style="language:german; accent:saxonian; voice:masculine;">...</p>

        MfG Dmitri

        1. hi

          <p audio-style="language:german; accent:saxonian; voice:masculine;">...</p>

          sowas gehört in's CSS (naje, außer dem language - das is eh dann xml:lang=""), wo es das aooes sogar schon gibt -> aural styles.

          Grüße aus Bleckede

          Kai

    2. in XHTML und HTML 4.01 hat man viele unnützliche Tags [im Vergleich zu HTML 3] entfernt (<center> <font>).

      Ja, und langsam sollte das W3C auch vom Modul Presentation Abstand nehmen. Von Attributen wie align sowieso.

      Interessant fände ich aber neue Attribute zum Beispiel für Aussprache, etc.

      Du widersprichst dir selbst.

      1. Hallo!

        Interessant fände ich aber neue Attribute zum Beispiel für Aussprache, etc.

        Du widersprichst dir selbst.

        Wieso? Die Aussprache gehört meiner Meinung nach zum Inhalt bzw. zur Textauszeichnung, Angaben zu Schriftart, Ausrichtung, etc. nicht. Es ist ja nicht so, das ich fordere, sowenig Tags und Attribute wie möglich im Standard zu verewigen, es ist nur so, das man sich von den Elementen, die nicht logisch auszeichnend sind, verabschieden sollte.

        Mittlerweile ist das mit der Aussprache durch <ruby> gelöst, wie ich lernen durfte.

        emu
        [...]

        1. Interessant fände ich aber neue Attribute zum Beispiel für Aussprache, etc.

          Du widersprichst dir selbst.

          Wieso?

          Wiedergabe durch Sprache ist *Wiedergabe* und hat mit dem Inhalt nichts zu tun.

          Mittlerweile ist das mit der Aussprache durch <ruby> gelöst, wie ich lernen durfte.

          Ähm...

          1. Hallo!

            Wiedergabe durch Sprache ist *Wiedergabe* und hat mit dem Inhalt nichts zu tun.

            Aber natürlich hat das mit Inhalt etwas zu tun. Mit der selben Argumentation könntest du die Wiedergabe durch Lesen nicht zum Inhalt zählen.

            Mit CSS könnte und kann man bestenfalls Modalitäten der Aussprache definieren - Geschlecht, Tonlage, Akzent, Lautstärke, Schnelligkeit des Sprechers.

            Ganz abgesehen ist es mit CSS möglich, dass man man nur mit einer verlinkten Datei alles definiert, sogar ohne Klassen, etc. und das ist sogar der Sinn der Sache, so wie ich das verstanden habe - Inhalt und Aussehen trennen. Das wäre so nicht möglich.

            Wie soll das denn in der Praxis ausschauen? <span style="ipa:'si'lekt">select</span> oder so etwas in der Art? Ich weiß nicht - würde so eine Angabe nicht am Sinn von CSS vorbeigehen?

            Nein, Aussprachehinweise gehören im Gegensatz zu Aussprachemodalitäten zum Inhalt und nicht zum Äußeren. Ich denke, es ist etwa analog zu <abbr title=""> oder generell dem Einsatz von title.

            Was sagen eigentlich die HTML-Experten dazu?

            Mittlerweile ist das mit der Aussprache durch <ruby> gelöst, wie ich lernen durfte.

            Ähm...

            Ähm was? Das ist doch genau das gleiche, hier werden Aussprache- oder Verständnishinweise durch einen Tag an ein Wort gebunden. Dass diese Vorgehensweise vor allem in japanischen und chinesischen Texten vorkommt tut doch nichts zur Sache. Sinnvoll wäre es bei den internationalen Nachrichten auf jeden Fall, da die Aussprache von Eigennamen in anderen Sprachen ja nicht so leicht erkenntlich ist wie bei deutschsprachigen Namen. Sogar Reporter sprechen deswegen einige Namen falsch aus.

            Und die Einführung von Ruby auf HTML-Ebene ist für mich ein weiterer Beweis, das Aussprache dem Inhalt zuzurechnen ist.

            emu
            [...]

            1. hi

              Mit CSS könnte und kann man bestenfalls Modalitäten der Aussprache definieren - Geschlecht, Tonlage, Akzent, Lautstärke, Schnelligkeit des Sprechers.

              'nen Dialekt, wie hier vorgeschlagen macht allerdings auch Sinn - wobei auch ein xml:lang="de-BY" für bayrisch Sinn machen würde!

              Sinnvoll wäre es bei den internationalen Nachrichten auf jeden Fall, da die Aussprache von Eigennamen in anderen Sprachen ja nicht so leicht erkenntlich ist wie bei deutschsprachigen Namen. Sogar Reporter sprechen deswegen einige Namen falsch aus.

              Allerdings.... hier sind die ChampCar-Übertragungen von EuroSport und ORB immer ein nettes Beispiel gewesen:

              #27 Dario Franchitti [das "ch" klinkt wie "k", wenn's denn mal richtig ist]
              #4 Bruno Junqueira [das "i" ist _nicht_ zu sprechen]

              ...geht selbstredend zu 70% daneben.

              Grüße aus Bleckede

              Kai

              1. Hallo!

                'nen Dialekt, wie hier vorgeschlagen macht allerdings auch Sinn - wobei auch ein xml:lang="de-BY" für bayrisch Sinn machen würde!

                Naja, da bin ich skeptisch. Ich bin zwar kein Dialektexperte, aber ich denke, man kann das nicht so einfach definieren.

                Für mich ist es zum Beispiel immer lustig, wenn irgendwo steht, de_AT stünde für österreichischen Dialekt - da muss man sich nur einmal die erheblichen Verständigungsprobleme zwischen Wienern und Tirolern, die natürlich durch die weitgehende Aufgabe der Sahnefront in Tirol weniger geworden sind :-) - nicht einmal das österreichische Deutsch könnte man damit sinnvoll definieren, wenn man zum Beispiel Vorarlberg bedenkt.

                Aus einem besonders tollen, weil sehr aktuellen Heftchen von 1978 lese ich übrigens gerade, dass das Bairische sich über fast ganz Österreich und Bayern erstreckt - wer hätte gedacht, dass von München bis Wien der selbe Dialekt, Mittelbairisch, gesprochen wird ;-)

                Sprache in Computercodes zu basteln ist schwer, Dialekte unmöglich, nicht einmal eine grobe Differenzierung dürfte gelingen.

                Ich schweife ab...

                Sogar Reporter sprechen deswegen einige Namen falsch aus.

                Allerdings.... hier sind die ChampCar-Übertragungen von EuroSport und ORB immer ein nettes Beispiel gewesen: [...]

                Wie spricht man eigentlich Rubens Barichello aus? Im deutschen Fernsehen sagt man [-k-], im österreichischen [-tsch-], eigenartig wie die österreischisch-deutsche Unterschiede bei [michelin] und [mischlö]. Interessant auch Barcelona, wo eigentlich kaum jemand so genau weiß, wie man es denn auszusprechen hat.

                emu
                [sehr vom thema abkommend]

                1. hi

                  Für mich ist es zum Beispiel immer lustig, wenn irgendwo steht, de_AT stünde für österreichischen Dialekt - da muss man sich nur einmal die erheblichen Verständigungsprobleme zwischen Wienern und Tirolern, die natürlich durch die weitgehende Aufgabe der Sahnefront in Tirol weniger geworden sind :-) - nicht einmal das österreichische Deutsch könnte man damit sinnvoll definieren, wenn man zum Beispiel Vorarlberg bedenkt.

                  wenn du mich fragst kann man diese Dialekte allerhöchstens per Bundesland definieren - wobei wir dann bei 16 (DE) + 9 (AT) + weiß der Geier wie vielen Dialekten und der Schweiz und anderswo schon ziemlich viele Varianten hätten...

                  Wie spricht man eigentlich Rubens Barichello aus? Im deutschen Fernsehen sagt man [-k-], im österreichischen [-tsch-]

                  weiß nit, frag' ihn mal ;)
                  ach ne - sowas geht ja bei der Formel Vertuschung nicht...

                  Grüße aus Bleckede

                  Kai

                  [der letztens erst mit einigen Gechattet hat, die beim ChampCar-Rennen 2001 auf dem EuroSpeedway dabei waren - einer davon hatte morgens noch mit Alex Zanardi geplaudert...]

                  1. Grüß Gott,

                    wenn du mich fragst kann man diese Dialekte allerhöchstens per Bundesland definieren - wobei wir dann bei 16 (DE) + 9 (AT) + weiß der Geier wie vielen Dialekten und der Schweiz und anderswo schon ziemlich viele Varianten hätten...

                    16 (DE) ???

                    Schwäbisch != Badisch!

                    Adele!

                2. Hallo,

                  man muss auch Dialekt vom Akzent unterscheiden.

                  Es steht: <p>Ich gehe hinaus ...</p>
                  Schwäbischer Dialekt wäre dann "I gang nus".
                  Schwäbischer Akzent??? Ich glaube so einen Satz würden sie gar nicht produzieren.

                  Akzente ziehen z. B. Vokale lang usw.

                  Ein Sprachprogramm mit Akzent kann ich mir vorstellen - Dialekt nicht.

                  MfG Dmitri

            2. Hi emu,

              Wiedergabe durch Sprache ist *Wiedergabe* und
              hat mit dem Inhalt nichts zu tun.
              Mit der selben Argumentation könntest du die
              Wiedergabe durch Lesen nicht zum Inhalt zählen.

              Und das ist auch genau richtig:

              Dinge, die ausschließlich mit dem Lesen zu tun haben,
              wie etwa optische Auszeichnungen des Presentations-
              Moduls, gehören heutzutage nach CSS.

              Der reine Inhalt hingegen wird weiterhin durch das
              HTML-Dokument selbst repräsentiert.

              Verwechsele nicht Inhalt mit Leseinterpretation,
              nur weil Dir selbst im Augenblick kein Unterschied
              auffällt. Auch eine 1:1-Abbildung ist eine Abbildung.

              Viele Grüße
                    Michael

              1. Hallo!

                Dinge, die ausschließlich mit dem Lesen zu tun haben,
                wie etwa optische Auszeichnungen des Presentations-
                Moduls, gehören heutzutage nach CSS.

                Der reine Inhalt hingegen wird weiterhin durch das
                HTML-Dokument selbst repräsentiert.

                Verwechsele nicht Inhalt mit Leseinterpretation,
                nur weil Dir selbst im Augenblick kein Unterschied
                auffällt. Auch eine 1:1-Abbildung ist eine Abbildung.

                Ja, und was heißt das jetzt konkret? Wo soll man diese Angaben denn
                unterbringen, wenn sie nicht Inhalt sind? Soll so etwas in einem neu
                zu schaffenden CSS-Element enthalten sein? Wenn das so ist, liegt das
                Konsortium dann falsch, wenn es <ruby> eingeführt hat, oder hat das
                gar nichts damit zu tun?

                Ich verstehe dein Posting ehrlich gesagt nicht so wirklich.

                emu
                [...]

                1. Hallo!

                  Ja, und was heißt das jetzt konkret? Wo soll man diese Angaben denn
                  unterbringen, wenn sie nicht Inhalt sind? Soll so etwas in einem neu
                  zu schaffenden CSS-Element enthalten sein? Wenn das so ist, liegt das
                  Konsortium dann falsch, wenn es <ruby> eingeführt hat, oder hat das
                  gar nichts damit zu tun?

                  Nein. Ruby dient dazu Inhalt zugänglich zu machen. 12jährige japanische Knirpse kennen zum beispile noch nicht alle Kanji. Deswegen wird mit Ruby eine Umschrift in Kana geliefert, damit der Inhalt zugänglich ist!!!!!
                  Hörgeschichten die sich nur auf den Charakter von Sprache beschränken gehören nicht zu Inhalt sondern zur Presentation. So wie ich Text mit CSS visuell farbig gestallte ist dies auch mit Stimmlagen möglich (hypothetisch).

                  Gruß Herbalizer

            3. Hi,

              Wiedergabe durch Sprache ist *Wiedergabe* und hat mit dem Inhalt nichts zu tun.

              Aber natürlich hat das mit Inhalt etwas zu tun. Mit der selben Argumentation könntest du die Wiedergabe durch Lesen nicht zum Inhalt zählen.

              Mit CSS könnte und kann man bestenfalls Modalitäten der Aussprache definieren - Geschlecht, Tonlage, Akzent, Lautstärke, Schnelligkeit des Sprechers.

              Ganz abgesehen ist es mit CSS möglich, dass man man nur mit einer verlinkten Datei alles definiert, sogar ohne Klassen, etc. und das ist sogar der Sinn der Sache, so wie ich das verstanden habe - Inhalt und Aussehen trennen. Das wäre so nicht möglich.

              Aber mit dem CSS-Hypertext _Markup_Language_-Modell wird zwischen Inhalt und Aussehen getrennt. HTML ist logisch. Es wird gegliedert in Tabellen, Überschriften, Absätze etc.
              Mit <p>Es war einmal im Jahre 1602 ...</p> strukturiere ich das Dokument logisch. Der Text "Es war einmal im Jahre 1602 ..." ist ein Absatz. Wie dieser Absatz nun aussehen soll ist die Aufgabe von CSS.

              MfG Dmitri

              1. Hallo!

                Aber mit dem CSS-Hypertext _Markup_Language_-Modell wird zwischen Inhalt und Aussehen getrennt. HTML ist logisch. Es wird gegliedert in Tabellen, Überschriften, Absätze etc.
                Mit <p>Es war einmal im Jahre 1602 ...</p> strukturiere ich das Dokument logisch. Der Text "Es war einmal im Jahre 1602 ..." ist ein Absatz. Wie dieser Absatz nun aussehen soll ist die Aufgabe von CSS.

                Wenn du das jetzt ernst meinst, dann bin ich einigermaßen beleidigt. Mir brauchst du wirklich nicht den Unterschied zwischen HTML und CSS erklären, danke schön, das habe ich mittlerweile begriffen und auch schon mehreren erklärt, siehe auch Archiv.

                Ganz abgesehen davon kann ich zwischen deinem Posting und dem Diskussionsstrang keinerlei Anknüpfungspunkte finden - was willst du eigentlich mit dieser Belehrung sagen? Inwiefern trägt es dazu bei, festzustellen, ob ein Aussprache-Hinweis Teil von Inhalt oder Darstellung ist?

                emu
                [ogfressn]

                1. Moin,

                  Ganz abgesehen davon kann ich zwischen deinem Posting und dem Diskussionsstrang keinerlei Anknüpfungspunkte finden - was willst du eigentlich mit dieser Belehrung sagen? Inwiefern trägt es dazu bei, festzustellen, ob ein Aussprache-Hinweis Teil von Inhalt oder Darstellung ist?

                  Wahrscheinlich gar nicht, weil es die Trennung nicht geben kann. Aussprache kann Teil der Darstellung sein - etwa "alle Überschriften werden von einer sanften Frauenstimme gesprochen" - und Teil des Inhalts - beispielsweise um die einzelnen Sprecher in einem Interview zu differenzieren oder um zu markieren, dass ein bestimmtes Wort in diesem Kontext anders als landesüblich ausgesprochen wird.

                  --
                  Henryk Plötz
                  Grüße aus Berlin

                  * Help Microsoft combat software piracy: Give Linux to a friend today! *

                2. Hi,

                  Aber mit dem CSS-Hypertext _Markup_Language_-Modell wird zwischen Inhalt und Aussehen getrennt. HTML ist logisch. Es wird gegliedert in Tabellen, Überschriften, Absätze etc.
                  Mit <p>Es war einmal im Jahre 1602 ...</p> strukturiere ich das Dokument logisch. Der Text "Es war einmal im Jahre 1602 ..." ist ein Absatz. Wie dieser Absatz nun aussehen soll ist die Aufgabe von CSS.

                  Wenn du das jetzt ernst meinst, dann bin ich einigermaßen beleidigt. Mir brauchst du wirklich nicht den Unterschied zwischen HTML und CSS erklären, danke schön, das habe ich mittlerweile begriffen und auch schon mehreren erklärt, siehe auch Archiv.

                  Ganz abgesehen davon kann ich zwischen deinem Posting und dem Diskussionsstrang keinerlei Anknüpfungspunkte finden - was willst du eigentlich mit dieser Belehrung sagen? Inwiefern trägt es dazu bei, festzustellen, ob ein Aussprache-Hinweis Teil von Inhalt oder Darstellung ist?

                  Sorry, ich war schon im Halbschlaf, als ich das hier gelesen habe:

                  Ganz abgesehen ist es mit CSS möglich, dass man man nur mit einer verlinkten Datei alles definiert, sogar ohne Klassen, etc. und das ist sogar der Sinn der Sache, so wie ich das verstanden habe - Inhalt und Aussehen trennen. Das wäre so nicht möglich.

                  Bei Überfliegen habe ich verstenden: Es sei der Sinn der Sache ... zu trennen, es sei aber so nicht möglich. Ich solle früher Schlafen gehen.

                  MfG Dmitri

            4. Wiedergabe durch Sprache ist *Wiedergabe* und hat mit dem Inhalt nichts zu tun.

              Aber natürlich hat das mit Inhalt etwas zu tun.

              Wenn du mich damit überzeugen wolltest, ist dir das nicht gelungen, du musst schon ein paar Gründe für diese Auffassung vorbringen.

              Mit der selben Argumentation könntest du die Wiedergabe durch Lesen nicht zum Inhalt zählen.

              Lesen ist Informations-*Aufnahme*, nicht -Wiedergabe, ich verstehe nicht, worauf du hinauswillst. Wenn du mit "lesen" die visuelle Abbildung von Informationen meinst, würde das bedeuten, dass es für dich zum Inhalt zählt, ob z.B. ein Wort grün oder blau dargestellt wird, für mich ist das nicht der Fall. Es macht vielleicht vom Kontext her einen Unterschied, dann kann man den aber auch durch Markup begründen, so zum Beispiel via abbr, acronym, strong oder em.

              Mit CSS könnte und kann man bestenfalls Modalitäten der Aussprache definieren - Geschlecht, Tonlage, Akzent, Lautstärke, Schnelligkeit des Sprechers.

              Was im Detail derzeit möglich ist, kann jeder selber nachlesen, es ist richtig, dass CSS nur begrenzte Möglichkeiten bietet, Audio-Effekte zu nutzen, Sprachsynthese zu unterstützen und die generelle Aurale Wiedergabe zu beeinflussen, dass muss aber nicht so bleiben.

              Ganz abgesehen ist es mit CSS möglich, dass man man nur mit einer verlinkten Datei alles definiert, sogar ohne Klassen, etc. und das ist sogar der Sinn der Sache, so wie ich das verstanden habe - Inhalt und Aussehen trennen. Das wäre so nicht möglich.

              Weil du bestreitest, dass Eigenschaften der Auralen Wiedergabe Eigenschaften der Wiedergabe sind, und sie zur tatsächlichen Information eines Dokuments zählen willst. Ich sehe das anders.

              Wie soll das denn in der Praxis ausschauen?

              *Was*?

              <span style="ipa:'si'lekt">select</span> oder so etwas in der Art? Ich weiß nicht - würde so eine Angabe nicht am Sinn von CSS vorbeigehen?

              Vielleicht? Was willst du denn machen können? Welche Bedürfnisse existieren in diesem Bereich?

              Nein, Aussprachehinweise gehören im Gegensatz zu Aussprachemodalitäten zum Inhalt und nicht zum Äußeren.

              Wenn die Aussprache Einfluss auf die Bedeutung hat, gehört sie zum Inhalt. Nenn mal Beispiele, wo das der Fall ist und erkläre bitte anschliessend, wie diese Information Personen zugänglich gemacht wird, die nicht hören können.

              Ich denke, es ist etwa analog zu <abbr title=""> oder generell dem Einsatz von title.

              Dort ergänzt du Informationen um zusätzliche Informationen, die für das Textverständnis unerheblich aber hilfreich sind.

              Was sagen eigentlich die HTML-Experten dazu?

              Sehr schmeichelhaft...

              Mittlerweile ist das mit der Aussprache durch <ruby> gelöst, wie ich lernen durfte.

              Ähm...

              Ähm was? Das ist doch genau das gleiche, hier werden
              Aussprache- oder Verständnishinweise durch einen Tag

              [1]

              an ein Wort gebunden. Dass diese Vorgehensweise vor allem in japanischen und chinesischen Texten vorkommt tut doch nichts zur Sache. Sinnvoll wäre es bei den internationalen Nachrichten auf jeden Fall, da die Aussprache von Eigennamen in anderen Sprachen ja nicht so leicht erkenntlich ist wie bei deutschsprachigen Namen. Sogar Reporter sprechen deswegen einige Namen falsch aus.

              Du verwechselst Ruby-Inhalt mit Ruby-Markup.

              [1] "Tag" ist neutrum und eigentlich meinst du "Element", vgl. dazuhttp://www.netandmore.de/faq/fom-serve/cache/1241.html

              1. Hallo!

                Ich denke, mittlerweile habe ich deinen Standpunkt verstanden, und obwohl ich nicht ganz damit einverstanden bin, denke ich, eine weitere Diskussion wäre relativ sinnlos, weil wir uns gegenseitig kaum überzeugen können. Außerdem haben sich kaum andere eingemischt, also - Waffenstillstand bis zum nächsten Mal? :-)

                Nur noch zwei Dinge:

                [...] würde das bedeuten, dass es für dich zum Inhalt zählt, ob z.B. ein Wort grün oder blau dargestellt wird [...]

                Nein.

                Du verwechselst Ruby-Inhalt mit Ruby-Markup.

                Was ist Rubyinhalt? Was kann man damit denn machen? ich habe es doch so verstanden, dass man damit für dem Leser unbekannte Schriftzeichen eine Art vereinfachte Aussprache angibt, damit man es trotzdem lesen und verstehen kann. Oder?

                emu
                [...]

  4. Hi,

    die Frage richtet sich natuerlich nur an Puristen.
    Insofern ist es natuerlich gerechtfertigt.
    Doch HTML wir dnicht nur von Puristen gemacht.

    Was wuerdest du von dem Vorschlag halten, dass man Tastaturen auf 2 Tasten reduziert? Schliesslich ist es mathematisch und logisch beweisbar, dass sich jedes Kommando auf die Kombination der EIngaben von nur 2 Tasten reduzieren laesst.

    Jeder echte theoretische Informatiker würde doch vor Freude in die Haende klatschen bei solch einem STandard. Und ausserdem kann man auch die Umgangssprache abschaffen und nur noch ueber logische Sprachen, wie z.B. Scheme kommunizieren.

    Ciao,
      Wolfgang

    1. Hallo Wolfgang!

      die Frage richtet sich natuerlich nur an Puristen.

      Sicherlich, und die andere könnten damit leben, sieht man von so lächerlichen Kleinigkeiten wie Rückwärtskompatibilität ab ;-)

      Doch HTML wird nicht nur von Puristen gemacht.

      Tatsächlich ist das W3C ein Gremium, das hauptsächlich von Firmen  besetzt ist - insofern ist es eigentlich interessant, dass es sich so auf Logik und Standard zurückbesinnt hat.

      Was wuerdest du von dem Vorschlag halten, dass man Tastaturen auf 2 Tasten reduziert? Schliesslich ist es mathematisch und logisch beweisbar, dass sich jedes Kommando auf die Kombination der Eingaben von nur 2 Tasten reduzieren laesst.

      Der Vergleich hinkt. Es wäre doch kein großes Problem, statt <img> eben <object> zu schreiben, die sechs Buchstaben sind egal.

      Außerdem wäre so eine logische Auszeichnung nicht mehr möglich. Ja, ich weiß, es war ironisch gemeint.

      Was ist eigentlich *grundsätzlich* das Problem, Grafiken mit <object> zu referenzieren? Spricht außer umsetzungstechnischen Gründen irgendetwas dagegen?

      emu
      [...]

      1. Hi,

        Was ist eigentlich *grundsätzlich* das Problem, Grafiken mit <object> zu referenzieren? Spricht außer umsetzungstechnischen Gründen irgendetwas dagegen?

        Ja. Oekonomie.
        Spezialisten wir wir es sind und Mitglieder in den Gremien des W3Cs koennen sich locker an neue STandards anpassen.

        Aber die Allgemeinheit kann es nicht.
        Beispiel: In den letzten Monaten sind Bundesweit an VHSchulen sehr viele HTML-Kurse mit einigen Tausend zahlenden Teilnehmern durchgeführt wurden. Ebenso kam es zu (noch teureren) betrieblichen Ausbildungen innerhalb von Unternehmen und oeffentlichen Einrichtungen.

        So weit so gut. Nur ist es jetzt bei diesem Umfang und bei der grossen Verbreitung einer grossen Masse an Personen vermittelbar, dass sie umlernen muessen, wo sie "eben erst" für einen HTML-Kurs zahlten.

        Die Leute haben Ausbildungsbudgets (sowohl Firmen, als auch die Privatleute, nur heisst dort nicht so). Wieso sollte jemand, der einen VHS-Kurs gemacht hat, und vielleicht 50 Euro dafür zahlte, nur wegen einen neuen Standard nochmals Geld ausgeben, wenn die Aenderung im Standard mehr als minimal ist?

        Ciao,
         Wolfgang

        1. Hi Wolfang,

          Wieso sollte jemand, der einen VHS-Kurs gemacht hat, und vielleicht 50 Euro dafür zahlte, nur wegen einen neuen Standard nochmals Geld ausgeben, wenn die Aenderung im Standard mehr als minimal ist?

          das ist natürlich richtig, aber die Veränderung passiert ja nicht schlagartig, sondern äußerst (besser: furchtbar) langsam. Der Wegfall von Frames bei den strict-Varianten oder gar XHTML 1.1 ist da IMHO viel drastischer. Hier im Forum haben sich diesbezüglich schon Dramen abgespielt, sag' ich dir ;)

          LG Orlando

          --
          SELF-TREFFEN 2002
          http://www.rtbg.de/selftreffen/
          http://www.megpalffy.org/temp/penneninhh.html

        2. hi

          Aber die Allgemeinheit kann es nicht.
          Beispiel: In den letzten Monaten sind Bundesweit an VHSchulen sehr viele HTML-Kurse mit einigen Tausend zahlenden Teilnehmern durchgeführt wurden. Ebenso kam es zu (noch teureren) betrieblichen Ausbildungen innerhalb von Unternehmen und oeffentlichen Einrichtungen.

          es wäre offengesagt etwas ganz neues, wenn diese Kurze auf irgendwelche Standards achten würden. Anderenfalls würde man vielleicht aufhören <font>-Tags zu lehren und als Abschlussarbeiten eine grafisch auswändige Seite zu fordern, die in Netscape 2 gleich aussieht... Dort wird man dann wohl <object> eh nicht kennen und noch bis ca. 2010 mit <embed> arbeiten...

          Grüße aus Bleckede

          Kai

        3. Hallo!

          Wieso sollte jemand, der einen VHS-Kurs gemacht hat, und vielleicht 50 Euro dafür zahlte, nur wegen einen neuen Standard nochmals Geld ausgeben, wenn die Aenderung im Standard mehr als minimal ist?

          In allen Bereichen gibt es die eine oder andere Veränderung. Wenn man eine Word-Schulung macht, um jetzt einmal ein blödes Beispiel zu nennen, und bei der nächsten Version verändert sich ein Arbeitsablauf, werden Schaltflächen umgruppiert oder es gibt andere Veränderungen, ist die neue Version eine ökonomische Unsinnigkeit?

          Umgekehrt wäre zu fragen, ob denn sämtliche Veränderungen im HTML-Standard oder auch die Einführung von CSS eine einzige Dummheit waren.

          emu
          [...]

        4. Hallo,

          Was ist eigentlich *grundsätzlich* das Problem, Grafiken mit <object> zu referenzieren? Spricht außer umsetzungstechnischen Gründen irgendetwas dagegen?

          Ja. Oekonomie.
          Spezialisten wir wir es sind und Mitglieder in den Gremien des W3Cs koennen sich locker an neue STandards anpassen.

          Aber die Allgemeinheit kann es nicht.
          Beispiel: In den letzten Monaten sind Bundesweit an VHSchulen sehr viele HTML-Kurse mit einigen Tausend zahlenden Teilnehmern durchgeführt wurden. Ebenso kam es zu (noch teureren) betrieblichen Ausbildungen innerhalb von Unternehmen und oeffentlichen Einrichtungen.

          So weit so gut. Nur ist es jetzt bei diesem Umfang und bei der grossen Verbreitung einer grossen Masse an Personen vermittelbar, dass sie umlernen muessen, wo sie "eben erst" für einen HTML-Kurs zahlten.

          Die Leute haben Ausbildungsbudgets (sowohl Firmen, als auch die Privatleute, nur heisst dort nicht so). Wieso sollte jemand, der einen VHS-Kurs gemacht hat, und vielleicht 50 Euro dafür zahlte, nur wegen einen neuen Standard nochmals Geld ausgeben, wenn die Aenderung im Standard mehr als minimal ist?

          Und das ist deine Argumentation? Kaufst du dir einen neuen Computer - am nächsten Tag ist er schon veraltet. Ein neuest Auto - ebenfalls veraltet. Eine modische Jacke ... usw. Das ist die progressive Gesellschaft!

          MfG Dmitri

  5. hi

    Aber ein Tag wurde vergessen, und zwar der IMG-Tag. Mit IMG bindet man ein Bildobjekt ein. Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

    ich stimme dir da zu - das <img/> ist eigentlich überflüssig, mehr noch - es hat einen großen Nachteil, dass der Browser nicht hier schon über den Mime-Type informiert werden kann (type=""). Außerdem ist als Ersatz bei nicht-Darstellbarkeit nur ein einfacher Text vorgesehen, statt einfach eines anderen Bildformates oder eines formatierbaren Textes.
    Der Hauptgrund, warum es <img/> noch gibt ist wohl die kompatibilität zu ältesten Browsern.

    Grüße aus Bleckede

    Kai

    1. Aloha!

      ich stimme dir da zu - das <img/> ist eigentlich überflüssig, mehr noch - es hat einen großen Nachteil, dass der Browser nicht hier schon über den Mime-Type informiert werden kann (type=""). Außerdem ist als Ersatz bei nicht-Darstellbarkeit nur ein einfacher Text vorgesehen, statt einfach eines anderen Bildformates oder eines formatierbaren Textes.

      Gegen die Nichtdarstellbarkeit kann man etwas tun: Content Negotiation. Nur wird das aufgrund des Aufwandes (immerhin muss jede Grafik dann in mehrfacher Form angeboten werden) wohl eher nicht gemacht werden - oder es wird skriptgesteuert die Grafik generiert und dabei auf die Browserangaben Rücksicht genommen. Allerdings hilft das bei der Verwendung von PNG leider nicht viel weiter - der IE und auch Netscape 4 behaupten, dass sie das Format kennen. Stimmt ja auch - leider aber nur zum Teil. Tolle Transparenzeffekte gehen aber nur in Mozilla und Opera.

      - Sven Rautenberg

      1. hi

        kleines Beispiel (Theorie..)

        <object data="beispiel.mng" type="video/mng">
         <object data="beispiel.swf" type="application/x-shockwave-flash">
          <object data="beispiel.gif" type="image/gif">
           man, ihr Browser kann aber auch gar nix!
          </object>
         </object>
        </object>

        ....damit werden Mozilla- und konqueror-User schonmal nur mit MNGs versorgt. Rest ist hierfür zu doof und kriegt sein Flash. Wer kein Flash-Plugin hat -> dafür ist das GIF. Für die hoffnungslosen (und die nicht-grafischen) kann man da natürlich auch was netteres schreiben ;)

        zur Praxis:
        hier werden wohl die Meisten Browser einem erstmal versuchen ein MNG-Plugin andrehen zu wollen... die wenigsten (gar keiner?) kommt bis zum GIF durch.

        Grüße aus Bleckede

        Kai

      2. Allerdings hilft das bei der Verwendung von PNG leider nicht viel weiter - der IE und auch Netscape 4 behaupten, dass sie das Format kennen. Stimmt ja auch - leider aber nur zum Teil. Tolle Transparenzeffekte gehen aber nur in Mozilla und Opera.

        Und Konqueror.

        Stefan

        1. hi

          Und Konqueror.

          der kennt (zumindest bei mir) nur 1Bit transparenz.

          Grüße aus Bleckede

          Kai

        2. Moin,

          Allerdings hilft das bei der Verwendung von PNG leider nicht viel weiter - der IE und auch Netscape 4 behaupten, dass sie das Format kennen. Stimmt ja auch - leider aber nur zum Teil. Tolle Transparenzeffekte gehen aber nur in Mozilla und Opera.

          Und Konqueror.

          Und Dillo. Ja, auch ein voller Alpha-Kanal.

          --
          Henryk Plötz
          Grüße aus Berlin

          * Help Microsoft combat software piracy: Give Linux to a friend today! *

    2. Hallo,

      Aber ein Tag wurde vergessen, und zwar der IMG-Tag. Mit IMG bindet man ein Bildobjekt ein. Wäre es denn nicht einheitlicher und logischer, Bildobjekte wie normale Objekte zu behandeln, mit OBJECT? Schliesslich gibt es auch keinen <applet> mehr. Was haltet ihr davon?

      ich stimme dir da zu - das <img/> ist eigentlich überflüssig, mehr noch - es hat einen großen Nachteil, dass der Browser nicht hier schon über den Mime-Type informiert werden kann (type=""). Außerdem ist als Ersatz bei nicht-Darstellbarkeit nur ein einfacher Text vorgesehen, statt einfach eines anderen Bildformates oder eines formatierbaren Textes.

      Daran habe ich gar nicht gedacth ...

      Der Hauptgrund, warum es <img/> noch gibt ist wohl die kompatibilität zu ältesten Browsern.

      Wen interessieren ätere Browser? Stichwort: Positionierung und Formatieren mit CSS unter NN4.

      MfG Dmitri