Tabelle, Ja oder Nein?

[Jnnbo]

Hallo,

ich verstelle gerade ein Mitarbeiter Datenblatt. Dieses ist so aufgebaut:

Name: xxx
Vorname: xxxx
Straße: xxxx

usw. Bin am Überlegen, wie ich dieses in HTML umsetzten soll. Tabellarische Daten können auch heute noch in eine Tabelle gepackt werden, nur zählen solchen Daten auch dazu? Oder lieber ein paar DIVS nehmen?

[Christian Kruse]

Hallo Jnnbo,

du hast JEHOVA gesagt! ;-)

ich verstelle gerade ein Mitarbeiter Datenblatt. Dieses ist so aufgebaut:

Name: xxx
Vorname: xxxx
Straße: xxxx

usw. Bin am Überlegen, wie ich dieses in HTML umsetzten soll. Tabellarische Daten können auch heute noch in eine Tabelle gepackt werden, nur zählen solchen Daten auch dazu? Oder lieber ein paar DIVS nehmen?

Über Semantik-Themen lässt sich ewig und drei Tage diskutieren. Meiner Meinung nach wärst du hier mit einer Definition List allerdings besser bedient. Im übrigen bin ich mir sicher, dass es dazu Opposition geben wird ;)

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Meiner Meinung nach wärst du hier mit einer Definition List allerdings besser bedient. Im übrigen bin ich mir sicher, dass es dazu Opposition geben wird ;)

Na klar. ;-) dl steht für description list.

LLAP

[Matthias Apsel]

Hallo Christian Kruse,

Über Semantik-Themen lässt sich ewig und drei Tage diskutieren. Meiner Meinung nach wärst du hier mit einer Definition List allerdings besser bedient. Im übrigen bin ich mir sicher, dass es dazu Opposition geben wird ;)

Genau;-)

http://forum.selfhtml.org/users/1 Dort hast du auch eine Tabelle verwendet.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

http://forum.selfhtml.org/users/1 Dort hast du auch eine Tabelle verwendet.

Hehe, ich hab nur drauf gewartet dass dieser Einwand kommt ;) Ja, habe ich, aus Faulheit bzw weil ich noch so viel anderes zu tun hatte und das hinten angestellt habe.

LG,
CK

[Gunnar Bittersmann]

@@Matthias Apsel

http://forum.selfhtml.org/users/1 Dort hast du auch eine Tabelle verwendet.

Die mit der Unterbringung des Bildes als

    <tr>
      <td rowspan="4"><img alt="Hunde avatar" src="/system/cf_users/avatars/000/000/001/medium/Hunde-Avatar.jpg?1428473954" /></td>
      <th>Name:</th>
      <td>Christian Kruse</td>
    </tr>

doch etwas nach Layouttabelle müffelt.

LLAP

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

ich verstelle gerade ein Mitarbeiter Datenblatt. Dieses ist so aufgebaut:

Name: xxx
Vorname: xxxx
Straße: xxxx

usw. Bin am Überlegen, wie ich dieses in HTML umsetzten soll. Tabellarische Daten können auch heute noch in eine Tabelle gepackt werden, nur zählen solchen Daten auch dazu? Oder lieber ein paar DIVS nehmen?

Über Semantik-Themen lässt sich ewig und drei Tage diskutieren. Meiner Meinung nach wärst du hier mit einer Definition List allerdings besser bedient. Im übrigen bin ich mir sicher, dass es dazu Opposition geben wird ;)

Das sehe ich ganz und gar nicht so!

Eine Tabelle ist hier genau richtig, denn es handelt sich um Daten, die aus einer Tabelle (DBMS) in eine Tabelle (HTML) fließen können. Eine DL wäre im Sinne des Datenmodells eine nicht hinreichend bzw. vollständig normalisierte Darstellung der Daten. Sie würde den Schritt zur Normalisierung (im DBMS) sogar wieder zerstören.

Eine Liste ist laut Definition nur eine einspaltige Tabelle, die ggf. noch bestimmte Attribute erhalten kann.

Spirituelle Grüße
Euer Robert
[e-mail]

[Christian Kruse]

Hallo robertroth,

Eine Tabelle ist hier genau richtig, denn es handelt sich um Daten, die aus einer Tabelle (DBMS) in eine Tabelle (HTML) fließen können.

Richtig, und deshalb passt eine DL auch ziemlich gut: DT ist der Spalten-Name und DD ist der Wert.

Eine DL wäre im Sinne des Datenmodells eine nicht hinreichend bzw. vollständig normalisierte Darstellung der Daten. Sie würde den Schritt zur Normalisierung (im DBMS) sogar wieder zerstören.

Kannst du das argumentativ untermauern?

Eine Liste ist laut Definition nur eine einspaltige Tabelle, die ggf. noch bestimmte Attribute erhalten kann.

Diese Definition halte ich nicht für übertragbar auf DLs.

LG,
CK

[Gunnar Bittersmann]

@@robertroth

Eine Tabelle ist hier genau richtig, denn es handelt sich um Daten, die aus einer Tabelle (DBMS) in eine Tabelle (HTML) fließen können. Eine DL wäre im Sinne des Datenmodells eine nicht hinreichend bzw. vollständig normalisierte Darstellung der Daten. Sie würde den Schritt zur Normalisierung (im DBMS) sogar wieder zerstören.

Ob die Daten aus einem DBMS kommen oder per Stille Post weitergegeben werden, ist für deren Markup völlig irrelevant.

Eine Liste ist laut Definition nur eine einspaltige Tabelle, die ggf. noch bestimmte Attribute erhalten kann.

Eine Beschreibungsliste (description list) ist per Definition eine zweipspaltige Tabelle mit Name-Wert-Paaren.

LLAP

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Eine Tabelle ist hier genau richtig, denn es handelt sich um Daten, die aus einer Tabelle (DBMS) in eine Tabelle (HTML) fließen können. Eine DL wäre im Sinne des Datenmodells eine nicht hinreichend bzw. vollständig normalisierte Darstellung der Daten. Sie würde den Schritt zur Normalisierung (im DBMS) sogar wieder zerstören.

Ob die Daten aus einem DBMS kommen oder per Stille Post weitergegeben werden, ist für deren Markup völlig irrelevant.

Du wirst unsachlich! Noch so ein Ding und ich drücke auf DNU.

Wenn die Daten in einem DBMS oder bei der stillen Post bereits normalisiert aufbereitet vorliegen, dann besteht kein Anlass dazu, sie im Markup wieder zu verwürfeln. Markup ist dafür gemacht, Datenarten und Datenbeziehungen darstellen zu können, und das auf die einfachste und klarste Art.

Spirituelle Grüße
Euer Robert
[e-mail]

[Matthias Apsel]

Hallo robertroth,

Du wirst unsachlich! Noch so ein Ding und ich drücke auf DNU.

Die Daumen gibt es nicht mehr lange! Deren Funktionalität schon.

https://trello.com/c/saRulBud/8-voting-area

Bis demnächst
Matthias

[Tabellenkalk]

Hallo,

Die Daumen gibt es nicht mehr lange! Deren Funktionalität schon.

Da musste ich jetzt erstmal drüber meditieren, was die Medaillennachricht mit dem DNU zu tun hat. Ein roter Kringel um die Votingarea wäre hilfreich gewesen!

Gruß
Kalk

[Matthias Apsel]

Hallo Tabellenkalk,

Da musste ich jetzt erstmal drüber meditieren, was die Medaillennachricht mit dem DNU zu tun hat. Ein roter Kringel um die Votingarea wäre hilfreich gewesen!

Meditationshilfe

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@robertroth

Du wirst unsachlich! Noch so ein Ding und ich drücke auf DNU.

Findest du?

Wenn die Daten in einem DBMS oder bei der stillen Post bereits normalisiert aufbereitet vorliegen, dann besteht kein Anlass dazu, sie im Markup wieder zu verwürfeln. Markup ist dafür gemacht, Datenarten und Datenbeziehungen darstellen zu können, und das auf die einfachste und klarste Art.

Markup ist dafür gemacht, Daten menschenlesbar darzustellen. Das kann eine Tabelle sein, aber auch Fließtext:

<p>
{% for item in userdata %}
  {% case item.name %}
    {% when 'name' %}
      Ich heiße {{ item.value }}.
    {% when 'registeredSince' %}
      Ich bin seit {{ item.value }} hier im Forum.
  {% endcase %}
{% endfor %}
</p>

LLAP

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Du wirst unsachlich! Noch so ein Ding und ich drücke auf DNU.

Findest du?

Wenn die Daten in einem DBMS oder bei der stillen Post bereits normalisiert aufbereitet vorliegen, dann besteht kein Anlass dazu, sie im Markup wieder zu verwürfeln. Markup ist dafür gemacht, Datenarten und Datenbeziehungen darstellen zu können, und das auf die einfachste und klarste Art.

Markup ist dafür gemacht, Daten menschenlesbar darzustellen. Das kann eine Tabelle sein, aber auch Fließtext:

staun

Das stimmt überhaupt nicht!

HTML dient als Auszeichnungssprache dazu, einen Text semantisch zu strukturieren, nicht aber zu formatieren.[6] Die visuelle Darstellung ist nicht Teil der HTML-Spezifikationen und wird durch den Webbrowser und Gestaltungsvorlagen wie CSS bestimmt. Ausnahme sind die als veraltet (englisch deprecated) markierten präsentationsbezogenen Elemente.

Seit wann benötige ich Markup, um Daten menschenlesbar zu machen? Da haben die Steuerzeichen von ASCII schon (fast) ausgereicht. Für den Bildschirm kam dann mit den ANSI-Sequenzen sogar Farbe ins Spiel. Markup dient der Maschinenlesbarkeit von Daten!

Spirituelle Grüße
Euer Robert
[e-mail]

[Gunnar Bittersmann]

@@robertroth

Markup ist dafür gemacht, Daten menschenlesbar darzustellen. Das kann eine Tabelle sein, aber auch Fließtext:

staun
[…]

Seit wann benötige ich Markup, um Daten menschenlesbar zu machen?

Du wirst staunen, wie wenig Markup in dem von mir gezeigten Fließtext-Beispiel ist.

Markup dient der Maschinenlesbarkeit von Daten!

Seit wann benötigest du Markup, um Daten menschenlesbar zu machen? Das tun Formate wie CSV oder JSON auch, vielleicht sogar besser.

Ich hab den Verdacht, wir reden aneinander vorbei.

LLAP

[Tabellenkalk]

Hallo,

Markup dient der Maschinenlesbarkeit von Daten!

Seit wann benötigest du Markup, um Daten menschenlesbar zu machen? Das tun Formate wie CSV oder JSON auch, vielleicht sogar besser.

Hier ist wohl "Daten maschinenlesbar zu machen?" gemeint gewesen.

Ich hab den Verdacht, wir reden aneinander vorbei.

durchaus denkbar.
Kann es sein, dass markup dazu dient, Daten sowohl menschen- alsauch maschinenlesbar darzustellen?

Gruß
Kalk

[Camping_RIDER]

Aloha ;)

Kann es sein, dass markup dazu dient, Daten sowohl menschen- alsauch maschinenlesbar darzustellen?

Kommt drauf an. Irgendwie ein bisschen alles und nichts davon. Zumindest meiner Denke nach. Wieso nicht -verstehbar (oder interpretierbar) statt -lesbar?

Markup macht Daten in meinen Augen maschinenverstehbar. Ohne Markup weiß die Maschine (der Browser) nicht, um was für Daten es sich handelt, auch wenn sie die Daten vorher schon lesen kann. Das Markup erhöht also die maschinelle Daten-Interpretierbarkeit (bzw. ermöglicht diese erst).

Dass Markup Daten menschenlesbar macht, halte ich (in diesem Sinne, ich glaube nicht dass Gunnar das ursprünglich in diesem Sinne meinte) für vollkommen falsch. Schließlich ist ein Quellcode mit Markup, Sonderzeichen ... viel schwerer lesbar für einen Menschen als die Daten ohne Markup. Ein Mensch ist in der Lage, aus dem Kontext heraus Daten sogar ohne Markup auch zu interpretieren. Insofern hat Markup auf Menschen-Lesbarkeit eher negative Auswirkungen und kaum einen direkten Effekt auf die Menschen-Interpretierbarkeit. Einen indirekten Effekt zeigt das Markup aber trotzdem, weil die Interpretation der Daten durch den Browser (die nur durch Markup möglich ist) dem Mensch das interpretieren der Daten erleichtert und teilweise abnimmt.

Von daher:

Markup hat Einfluss auf...

• Maschinenlesbarkeit: 0
• Maschineninterpretierbarkeit: +
• Menschenlesbarkeit: -
• Menscheninterpretierbarkeit: (direkt) 0/+ (indirekt)

Einverstanden? Ich gebe zu, dass die Unterscheidung zwischen Lesbarkeit und Interpretierbarkeit vielleicht auch ein bisschen spitzfindig ist...

Grüße,

RIDER

[Auge]

Hallo

Name: xxx
Vorname: xxxx
Straße: xxxx

Meiner Meinung nach wärst du hier mit einer Definition List allerdings besser bedient.

Das sehe ich ganz und gar nicht so!

Eine Tabelle ist hier genau richtig, denn es handelt sich um Daten, die aus einer Tabelle (DBMS) in eine Tabelle (HTML) fließen können. Eine DL wäre im Sinne des Datenmodells eine nicht hinreichend bzw. vollständig normalisierte Darstellung der Daten. Sie würde den Schritt zur Normalisierung (im DBMS) sogar wieder zerstören.

Das ist nicht mehr als eine Ausgabe, die steht am Ende einer Verarbeitungskette, an der nichts mehr zu „zerstören“ ist. Zudem ist eine Definitionsliste für die Art von Ausgabe, wie sie oben schematisch gezeigt wird, genau richtig. Ein Begriff als datensatzweit eindeutiger Identifikator (Spaltenüberschrift, Titel → dt) und der dazugehörige Teil des Datensatzes (Datum → dd).

Eine Liste ist laut Definition nur eine einspaltige Tabelle, die ggf. noch bestimmte Attribute erhalten kann.

Das ist laut Definition für eine Definitionsliste unzutreffend.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Eine Tabelle ist hier genau richtig, denn es handelt sich um Daten, die aus einer Tabelle (DBMS) in eine Tabelle (HTML) fließen können. Eine DL wäre im Sinne des Datenmodells eine nicht hinreichend bzw. vollständig normalisierte Darstellung der Daten. Sie würde den Schritt zur Normalisierung (im DBMS) sogar wieder zerstören.

Das ist nicht mehr als eine Ausgabe, die steht am Ende einer Verarbeitungskette, an der nichts mehr zu „zerstören“ ist. Zudem ist eine Definitionsliste für die Art von Ausgabe, wie sie oben schematisch gezeigt wird, genau richtig. Ein Begriff als datensatzweit eindeutiger Identifikator (Spaltenüberschrift, Titel → dt) und der dazugehörige Teil des Datensatzes (Datum → dd).

Das ist ganz und gar nicht so. Dann könnte man die Daten nämlich auch einfach in ASCII (oder Nachfolger) ausgeben. Leerzeichen, Tabzeichen, Zeilenumbrüche und die paar übrigen Steuerzeichen würden dann vollommen genügen. Markup ist dazu gemacht, Daten auszuzeichnen, ihnen also genau die semantische Bedeutung zuzuordnen, die sie haben. Das hat mit Darstellung erst einmal gar nicht viel zu tun. Dafür wurde später zum Glück CSS erfunden.

Suchmaschinen und andere Kandidaten (Screenreader, Pagegrabber, ...) freuen sich über sinnvolles Markup. Das hilft nämlich dabei, die Daten leicht zu analysieren und genau dafür ist Markup ersonnen worden.

Wenn Du es nicht glaubst, frag Sir Tim Berners-Lee.

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Zudem ist eine Definitionsliste für die Art von Ausgabe, wie sie oben schematisch gezeigt wird, genau richtig. Ein Begriff als datensatzweit eindeutiger Identifikator (Spaltenüberschrift, Titel → dt) und der dazugehörige Teil des Datensatzes (Datum → dd).

Das ist ganz und gar nicht so. … Markup ist dazu gemacht, Daten auszuzeichnen, ihnen also genau die semantische Bedeutung zuzuordnen, die sie haben.

Du willst hier also postulieren, dass eine Liste, die die Zuordnung zwischen Typ (Spalte) und Wert (Datum) explizit herstellt, die Semantik zerstört?

Suchmaschinen und andere Kandidaten (Screenreader, Pagegrabber, ...) freuen sich über sinnvolles Markup. Das hilft nämlich dabei, die Daten leicht zu analysieren und genau dafür ist Markup ersonnen worden.

Das funktioniert auch super duper mit Definitionslisten.

Wenn Du es nicht glaubst, frag Sir Tim Berners-Lee.

billige Polemik

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Zudem ist eine Definitionsliste für die Art von Ausgabe, wie sie oben schematisch gezeigt wird, genau richtig. Ein Begriff als datensatzweit eindeutiger Identifikator (Spaltenüberschrift, Titel → dt) und der dazugehörige Teil des Datensatzes (Datum → dd).

Das ist ganz und gar nicht so. … Markup ist dazu gemacht, Daten auszuzeichnen, ihnen also genau die semantische Bedeutung zuzuordnen, die sie haben.

Du willst hier also postulieren, dass eine Liste, die die Zuordnung zwischen Typ (Spalte) und Wert (Datum) explizit herstellt, die Semantik zerstört?

Was bedeutet "postulieren"? Da fehlt mir jetzt die Definitionsliste!

Ich will damit sagen, dass eine Definitionsliste eine Wertigkeit zwischen den Daten herstellt, die zunächst einmal bei einer Tabelle nicht besteht.

Da sind alle Datenspalten gleichwertig. Es wird leidiglich zwischen den Zellen einer Zeile eine innere Abhängigkeit behauptet, aber nicht, welche Zelle der Spalte nun die führende in der Hierarchie sein soll.

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Sorry, ich kann dir echt nicht mehr folgen. Erkläre du bitte, was der Vorteil der Auszeichnung eines Datensatzes als Tabelle gegenüber der Auszeichnung als Definitionsliste ist.

Tschö, Auge

[robertroth]

Liebe Mitdenker, liebe Wissende, liebe Neugierige,

ja!

Sorry, ich kann dir echt nicht mehr folgen. Erkläre du bitte, was der Vorteil der Auszeichnung eines Datensatzes als Tabelle gegenüber der Auszeichnung als Definitionsliste ist.

Macht ja nix. Ich hab auch nicht immer alles gleich kapiert :-P

Ich schrieb das bereits. Eine Tabelle ist eine gleichberechtigte Darstellung von Daten mehrerer Datensätze. Das bedeutet, dass es innerhalb eines Datensatzes bzw. zwischen den Spalten keine Prioritäten gibt. Bei einer Definitionsliste sind die Daten aber von einem "Ankerwert" abhängig und alleine nicht mehr sinnvoll.

Spirituelle Grüße
Euer Robert
[e-mail]

[Auge]

Hallo

Sorry, ich kann dir echt nicht mehr folgen. Erkläre du bitte, was der Vorteil der Auszeichnung eines Datensatzes als Tabelle gegenüber der Auszeichnung als Definitionsliste ist.

Ich schrieb das bereits. Eine Tabelle ist eine gleichberechtigte Darstellung von Daten mehrerer Datensätze. Das bedeutet, dass es innerhalb eines Datensatzes bzw. zwischen den Spalten keine Prioritäten gibt. Bei einer Definitionsliste sind die Daten aber von einem "Ankerwert" abhängig und alleine nicht mehr sinnvoll.

Ok, jetzt fügst du bitte deiner für dein Postulat ungeeigneten Struktur Spaltenüberschriften hinzu (jetzt und erst jetzt ist die Tabelle für die maschinelle Verarbeitung überhaupt geeignet) und schon hast du eine für mehrere Datensätze geeignete Entsprechung der vom OP gezeigten Liste für einen Datensatz. Mit Ankerwert, ohne irgendwelche Prioritäten – die auch die Definitionsliste nicht hat, weiß der Geier, wo du das her hast – und allem Pipapo.

Den herablassenden Rest ignoriere ich fürderhin.

Tschö, Auge

[Christian Kruse]

Hallo robertroth,

Da sind alle Datenspalten gleichwertig. Es wird leidiglich zwischen den Zellen einer Zeile eine innere Abhängigkeit behauptet, aber nicht, welche Zelle der Spalte nun die führende in der Hierarchie sein soll.

Äh, kann es sein, dass du definition lists nicht verstanden hast? Es gibt da keine Hierarchie in der Auszeichnung.

LG,
CK

[Gunnar Bittersmann]

@@Christian Kruse

Da sind alle Datenspalten gleichwertig. Es wird leidiglich zwischen den Zellen einer Zeile eine innere Abhängigkeit behauptet, aber nicht, welche Zelle der Spalte nun die führende in der Hierarchie sein soll.

Äh, kann es sein, dass du definition lists nicht verstanden hast?

Ich glaube, er hat Tabellen nicht verstanden: den Unterschied zwischen th und td nicht und den zwischen thead und tbody nicht.

Es gibt da keine Hierarchie in der Auszeichnung.

Ich glaube, er meint, dass dt und dd nicht gleichwertig sind. Ebensowenig wie th und td.

LLAP

[Gunnar Bittersmann]

@@robertroth

Suchmaschinen und andere Kandidaten (Screenreader, Pagegrabber, ...) freuen sich über sinnvolles Markup. Das hilft nämlich dabei, die Daten leicht zu analysieren und genau dafür ist Markup ersonnen worden.

Wenn Du es nicht glaubst, frag Sir Tim Berners-Lee.

Als (damals noch nicht Sir) Tim Berners-Lee HTML ersonnen hatte, gab’s denn da schon Suchmaschinen und andere Kandidaten (Screenreader, Pagegrabber, ...)?

Bringst du hier was durcheinander?

LLAP

[1unitedpower]

Über Semantik-Themen lässt sich ewig und drei Tage diskutieren. Meiner Meinung nach wärst du hier mit einer Definition List allerdings besser bedient.

Semantisch bin ich auf deiner Seite. Gestalterisch ergeben sich häufiger Probleme, weil es kein gruppierendes Element für <dt> und <dd> gibt. Früher konnte ich mich daran aufhalten und stundenlang probieren, das Problem mit CSS in den Griff zu kriegen, inzwischen fehlt mir die Geduld und ich weiche kurzerhand auf Tabellen aus. Das ist semantisch nicht ganz so elegant, aber auch nicht völlig falsch.

[Gunnar Bittersmann]

@@1unitedpower

Semantisch bin ich auf deiner Seite. Gestalterisch ergeben sich häufiger Probleme, weil es kein gruppierendes Element für <dt> und <dd> gibt.

Mein Gerede. Und die Probleme sind nicht nur gestalterischer Natur, sondern auch semantischer.

LLAP

[1unitedpower]

Mein Gerede. Und die Probleme sind nicht nur gestalterischer Natur, sondern auch semantischer.

Alles mus man selber machen:

document.registerElement('d-i', {
    prototype: Object.create(HTMLLIElement.prototype, {
        createdCallback : function () {
           var content = document.createElement('content');
           content.setAttribute('select','*');
           this.appendChild(content);
        }
    }),
    extends: 'li'
});

[Auge]

Hallo

    extends: 'li'

Bist du sicher, dass di li erweitern soll? Wenn ich Gunnar richtig verstehe, soll es in dl jedes Paar von dt und dd semantisch zu einem „Datensatz“ zusammenfassen. An der Stelle ist kein li im Spiel.

Tschö, Auge

[1unitedpower]

Bist du sicher, dass di li erweitern soll? Wenn ich Gunnar richtig verstehe, soll es in dl jedes Paar von dt und dd semantisch zu einem „Datensatz“ zusammenfassen. An der Stelle ist kein li im Spiel.

Man könnte es auch weglassen. Weil ich den Prototypen vom <li>-Element erbe, kann es nur gut sein auch das WebIDL-Interface zu erben: es könnte ja mal vorkommen, dass eine Prototyp-Methode sich auf ein WebIDL-Attribut bezieht . Der Prototyp des <li>-Elements ist aktuell nur ein leere Hülle und das WebIDL-Interface hat nur ein einziges Attribut zu bieten. Weil sich das in Zukunft ja mal ändern könnte, habe ich eben beides einfach stumpf so übernommen. Du kannst die Vererbung natürlich auch weglassen, dann erbt das <d-i>-Element eben nur das HTMLElement-WebIDL-Interface und den gleichnamigen Prototypen. Das ist fast Jacke wie Hose.

[Auge]

Hallo

Ich sach ma: Öhhm, … Gesundheit!

Du wirst schon wissen, was du sagst. :-)

Tschö, Auge

[MudGuard]

Hi,

Bist du sicher, dass di li erweitern soll? Wenn ich Gunnar richtig verstehe, soll es in dl jedes Paar von dt und dd semantisch zu einem „Datensatz“ zusammenfassen.

Nicht jedes Paar, jede Gruppe.

<dl>
  <di>
    <dt>Schimmel</dt>
    <dd>weißes Pferd</dd>
    <dd>Pilze</dd>
  </di>
  <di>
    <dt>Steuer</dt>
    <dt>Lenkrad</dt>
    <dd>Teil, mit dem man ein Fahrzeug lenkt</dd>
  </di>
</dl>

cu,
Andreas a/k/a MudGuard

[Auge]

Hallo

Wenn ich Gunnar richtig verstehe, soll es in dl jedes Paar von dt und dd semantisch zu einem „Datensatz“ zusammenfassen.

Nicht jedes Paar, jede Gruppe.

Recht hassu.

oder:

<dl>
  <di>
    <dt>Steuer</dt>
    <dd>Teil, mit dem man ein Fahrzeug lenkt</dd>
    <dd>Geldleistung an ein Gemeinwesen ohne Anspruch auf individuelle Gegenleistung</dd>
  </di>
</dl>

Tschö, Auge

[MudGuard]

Hi,

Recht hassu.

Ich habe immer ...

... mal wieder Recht ;-)

cu,
Andreas a/k/a MudGuard

[Gunnar Bittersmann]

@@Jnnbo

ich verstelle gerade ein Mitarbeiter Datenblatt.

Ertippt?

Dieses ist so aufgebaut:

Name: xxx
Vorname: xxxx
Straße: xxxx

usw. Bin am Überlegen, wie ich dieses in HTML umsetzten soll.

Sieht mir nach description list aus.

LLAP

[Jnnbo]

Hallo Gunnar,

Ertippt?

eher vertippt :)

Sieht mir nach description list aus.

also meinst du so?

<dl>
  <dt>Benutzername</dt>
  <dd>xxx</dd>
  <dt>Name</dt>
  <dd>xxx</dd>
  <dt>Straße</dt>
  <dd>xxx</dd>
  <dt>PLZ / Ort</dt>
  <dd>xxx</dd>
  <dt>Telefon</dt>
  <dd>xxx</dd>
  <dt>Mail-Adresse</dt>
  <dd>xxx</dd>
</dl>

[Jnnbo]

Und so mein CSS dazu:

dl {
  width: 600px;
}

dt {
  width: 150px;
  display: inline-block;
}

dd {
  width: 260px;
  display: inline-block;
}

Ja, ich verwende hier derzeit noch px, das ist gewollt und wird erst am Ende komplett umgestellt, darauf kommt es mir hier auch nicht an.

[Gunnar Bittersmann]

@@Jnnbo

> dl {
>   width: 600px;
> }
> 
> dt {
>   width: 150px;
>   display: inline-block;
> }
> 
> dd {
>   width: 260px;
>   display: inline-block;
> }

Da stehen also das erste dt-Element, das erste dd-Element und das zweite dt-Element in einer Zeile. Ist das so gewollt?

Ja, ich verwende hier derzeit noch px, das ist gewollt und wird erst am Ende komplett umgestellt, darauf kommt es mir hier auch nicht an.

Worauf dann? Dass dt-Elemente eine neue Zeile beginnen?

Und ja, beim Stylen von Beschreibungslisten macht sich das Fehlen des di-Elementtyps schmerzlich bemerkbar.

LLAP

[Gunnar Bittersmann]

@@Jnnbo

Und so mein CSS dazu:

dl { width: 600px; }

Ja, ich verwende hier derzeit noch px, das ist gewollt und wird erst am Ende komplett umgestellt, darauf kommt es mir hier auch nicht an.

Und dass der Viewport beim Nutzer durchaus schmaler sein kann als 600 Pixel willst du auch erst am Ende berücksichtigen?

LLAP

[Jnnbo]

Hallo Gunnar,

Und dass der Viewport beim Nutzer durchaus schmaler sein kann als 600 Pixel willst du auch erst am Ende berücksichtigen?

du hast schon gelesen was ich geschrieben habe? Ich gebe die Daten ein und das System ist eine kleine Kundenverwaltung die auf meinem Rechner läuft. Nur ich habe Zugriff auf das System, also kann ich zu 100% sagen dass es passt :)

[Gunnar Bittersmann]

@@Jnnbo

Und dass der Viewport beim Nutzer durchaus schmaler sein kann als 600 Pixel willst du auch erst am Ende berücksichtigen?

du hast schon gelesen was ich geschrieben habe? Ich gebe die Daten ein und das System ist eine kleine Kundenverwaltung die auf meinem Rechner läuft. Nur ich habe Zugriff auf das System, also kann ich zu 100% sagen dass es passt :)

Und die Kundenverwaltung machst du für immer und ewig an deinem Desktop-PC? Armes Würstchen! Morgen soll schönes Wetter werden. Vielleicht willst du dann lieber im Park sitzen und die Kundenverwaltung über dein Smartphone erledigen.

LLAP

[Jnnbo]

Hallo Gunnar,

Und die Kundenverwaltung machst du für immer und ewig an deinem Desktop-PC? Armes Würstchen! Morgen soll schönes Wetter werden. Vielleicht willst du dann lieber im Park sitzen und die Kundenverwaltung über dein Smartphone erledigen.

jetzt mal ganz locker bleiben :) Ich liebe mein Laptop, der ist immer mit dabei. Aber OK, ich bin auch sehr viel mit dem Handy online, hier im Forum ist es ja leider nicht mehr möglich. Ich werde das ganze also noch etwas optimieren, du hast mich überzeugt.

[Gunnar Bittersmann]

@@Jnnbo

ich bin auch sehr viel mit dem Handy online, hier im Forum ist es ja leider nicht mehr möglich.

Nicht? Ich finde, es hat sich schon einiges gebessert. So hatte z.B. Safari auf iOS bei HTTP-Authentifizierung meinen Namen immer wieder vergessen (oder mein Passwort?) und ich musste mich immer wieder neu anmelden. Mit dem Keks-Login ist das endlich vorbei.

Aber es besteht einiger Optimierungsbecdarf, ohne Zweifel. Welche konkreten Probleme hast du denn? Die kannst du gern im Meta-Forum ansprechen.

Ich werde das ganze also noch etwas optimieren, du hast mich überzeugt.

Freut mich.

LLAP

[Jnnbo]

Hallo Gunnar,

Aber es besteht einiger Optimierungsbecdarf, ohne Zweifel. Welche konkreten Probleme hast du denn? Die kannst du gern im Meta-Forum ansprechen.

haben wir gestern Abend bereits geklärt :)

So sieht es bei mir unter dem Android Browser aus: http://forum.selfhtml.org/meta/2015/mar/24/handy-ansicht/1636675#m1636675

So sieht es bei mir unter Firefox aus: http://forum.selfhtml.org/meta/2015/mar/24/handy-ansicht/1636691#m1636691

Zwar etwas schade, dass ich einen alternativen Browser benötige, aber OK, FAcebook musste dran glauben :D

[Gunnar Bittersmann]

@@Jnnbo

also meinst du so?

Ich meine so:

<dl>
  <di>
    <dt>Benutzername</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>Name</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>Straße</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>PLZ / Ort</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>Telefon</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>Mail-Adresse</dt>
    <dd>xxx</dd>
  </di>
</dl>

Leider meint die HTML5-Spec (d.h. Hixie), dass das di-Element zur Gruppierung zusammengehörender dt- und dd-Elemente nicht nötig wäre.

LLAP

[Jnnbo]

Hallo Gunnar,

Ich meine so:

<dl>
  <di>
    <dt>Benutzername</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>Name</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>Straße</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>PLZ / Ort</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>Telefon</dt>
    <dd>xxx</dd>
  </di>
  <di>
    <dt>Mail-Adresse</dt>
    <dd>xxx</dd>
  </di>
</dl>

So möchte ich die Darstellung allerdings nicht haben. Bei mir sollte es nebeneinander stehen, also so:

Benutzername: xxxxx Name: xxxxx Straße xxxxx

usw..

Orrr, warum macht er jetzt hier kein Umbruch wie ich es in der Vorschau sehe? :/ Nach den XXX sollte jeweils ein Umbruch sein.

[Auge]

Hallo

So möchte ich die Darstellung allerdings nicht haben.

Dir ist klar, dass Gunnar hier Pseudoquellcode zeigte?

Bei mir sollte es nebeneinander stehen, also so:

Benutzername: xxxxx
Name: xxxxx
Straße xxxxx

Orrr, warum macht er jetzt hier kein Umbruch wie ich es in der Vorschau sehe? :/ Nach den XXX sollte jeweils ein Umbruch sein.

Das ist die Markdown/Kramdown-Syntax. Mehrere Zeilen, die ohne Leerzeile direkt aufeinander folgen, werden zu einem Block zusammengefasst. Entweder, du setzt dein Beispiel als Codeblock, was hier – weil das heute ja das Lieblingsthema ist – semantisch falsch wäre, oder du setzt an das Ende jeder Zeile zwei Leerzeichen, wie ich es hier mal gemacht habe.

Tschö, Auge

[Gunnar Bittersmann]

@@Jnnbo

Bei mir sollte es nebeneinander stehen, also so:

Benutzername: xxxxx
Name: xxxxx
Straße xxxxx

Also

dl { display: table }
di { display: table-row }
dt, dd { display: table-cell }

Womit wir wieder beim fehlenden di-Elementtypen wären.

Also vielleicht doch dd { display: inline-block; width: 7em }? Wobei 7em eine magic number ist (welche man vermeiden sollte!), die sich nach dem Inhalt des längsten dt-Elements richtet? Mehr oder weniger, denn der Platzbedarf hängt nicht nur vom Inhalt, sondern auch von der verwendeten Schriftart ab – auf die der Webentwickler nicht 100%ige, also so gut wie keine Kontrolle hat.

Was soll passieren, wenn der Inhalt eines dt-Elements nicht in die vorgegebene Breite passt?

Was soll passieren, wenn der Inhalt eines dd-Elements (die xxxxx) nicht in die restliche Zeilenlänge passt?

LLAP

[Gunnar Bittersmann]

@@Gunnar Bittersmann

Also vielleicht doch dd { display: inline-block; width: 7em }? Wobei 7em eine magic number ist (welche man vermeiden sollte!), die sich nach dem Inhalt des längsten dt-Elements richtet? Mehr oder weniger, denn der Platzbedarf hängt nicht nur vom Inhalt, sondern auch von der verwendeten Schriftart ab

Und von der Sprache.

Wenn nach der Übersetzung nochmal Entwickler ranmüssen, um bspw. Breiten für andere Sprachen anzupassen, dann haben Designer/Entwickler im Vorfeld schon gepfuscht.

LLAP

[Jnnbo]

Hallo Gunnar,

Was soll passieren, wenn der Inhalt eines dt-Elements nicht in die vorgegebene Breite passt?

kann nicht passieren, da ich selber die Daten eintragen und ich weiß was alles kommt :)

Was soll passieren, wenn der Inhalt eines dd-Elements (die xxxxx) nicht in die restliche Zeilenlänge passt?

auch das kann nicht passieren, wie oben schon geschrieben trage ich die Inhalte selber ein und somit kann ich sollte es wirklich mal nicht passen direkt drauf reagieren.

[Matthias Apsel]

Hallo Jnnbo,

Was soll passieren, wenn der Inhalt eines dt-Elements nicht in die vorgegebene Breite passt?

kann nicht passieren, da ich selber die Daten eintragen und ich weiß was alles kommt :)

Was soll passieren, wenn der Inhalt eines dd-Elements (die xxxxx) nicht in die restliche Zeilenlänge passt?

auch das kann nicht passieren, wie oben schon geschrieben trage ich die Inhalte selber ein und somit kann ich sollte es wirklich mal nicht passen direkt drauf reagieren.

Naja, dann richtet ja min-width statt width erst recht keinen Schaden an.

Bis demnächst
Matthias

[Gunnar Bittersmann]

@@Matthias Apsel

Naja, dann richtet ja min-width statt width erst recht keinen Schaden an.

Weniger Schaden als width vielleicht.

Von „erst recht keinen“ kann keine Rede sein. Was, wenn der Wert von min-width größer ist als die zur Verfügunug stehende Breite (bspw. die Viewportbreite)?

LLAP

[Gunnar Bittersmann]

@@Jnnbo

Was soll passieren, wenn der Inhalt eines dt-Elements nicht in die vorgegebene Breite passt?

kann nicht passieren, da ich selber die Daten eintragen und ich weiß was alles kommt :)

Doch, das kann passieren. Wie ich schon sagte: „denn der Platzbedarf hängt nicht nur vom Inhalt, sondern auch von der verwendeten Schriftart ab – auf die der Webentwickler nicht 100%ige, also so gut wie keine Kontrolle hat.“

Bei Arial und Helvetica mag "Benutzername:" in 7em Breite reinpassen; bei Lucida Sans passt es nicht.

Was soll passieren, wenn der Inhalt eines dd-Elements (die xxxxx) nicht in die restliche Zeilenlänge passt?

auch das kann nicht passieren, wie oben schon geschrieben trage ich die Inhalte selber ein und somit kann ich sollte es wirklich mal nicht passen direkt drauf reagieren.

Kannst du nicht. Weil du gar nicht wissen kannst, ob es beim Nutzer passt. Ob es bei dir passt, hat so ziemlich gar nichts zu sagen.

Es ist nie eine gute Idee davon auszugehen, dass ein bestimmter Text eine gewisse Breite nicht überschreitet. Selbst wenn das in 99% der Fälle gutgehen mag, sollte man das letzte Prozent im Auge behalten. Dann muss es nicht wie geleckt aussehen, aber auch dann sollte es lesbar sein.

Also immer die Frage stellen: Was passiert, wenn der Text länger ist? Und „kann nicht passieren“ ist die falsche Antwort darauf.

LLAP

[Auge]

Hallo

ich verstelle gerade ein Mitarbeiter Datenblatt. Dieses ist so aufgebaut:

Name: xxx
Vorname: xxxx
Straße: xxxx

usw. Bin am Überlegen, wie ich dieses in HTML umsetzten soll.

Kommt drauf an.

Tabellarische Daten können auch heute noch in eine Tabelle gepackt werden, nur zählen solchen Daten auch dazu?

Ja und/oder nein. Wenn du die Ausgabe so, wie du oben zeigst, haben willst, ist die von meinen Vorpostern präferierte Definitionsliste die erste Wahl. Die Ausgabe kann aber genausogut ei9ne Tabelle ergeben.

Name  | Vorname  | Straße  
xxx   | xxxx     | xxxx  
yyy   | yyyyy    | yyyyyy  
zzzz  | zz       | zzz  

Wie du siehst, kann beides richtig sein. Die Doku enthält auch ein von Gunnar Bittersman entwickeltes Beispiel für die auch auf kleinere Displaygrößen angepasste Ausgabe einer Tabelle. Die sieht auf kleinen Displays doch wieder nach Liste aus. :-)

Oder lieber ein paar DIVS nehmen?

Nein, das nu überhaupt nicht.

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Definitionsliste

Noch so einer.

LLAP

[Christian Kruse]

Hallo Gunnar,

Definitionsliste

Noch so einer.

Daran erkennt man die alten Hasen ;)

LG,
CK

[Auge]

Hallo

Definitionsliste

Noch so einer.

Daran erkennt man die alten Hasen ;)

Neumodischer Schnickschnack. Irgendwer musste also aus einer Definition mit ihrer Beschreibung unbedingt die Beschreibung einer Definition machen. Großes Kino!

Wenn's nichts wichtigeres gibt …

Tschö, Auge

[Gunnar Bittersmann]

@@Auge

Neumodischer Schnickschnack. Irgendwer musste also aus einer Definition mit ihrer Beschreibung unbedingt die Beschreibung einer Definition machen. Großes Kino!

Ja!

Bei

<dl>
  <dt>Definitionsliste (<i lang="en">definition list</i>)</dt>
  <dd>eine Auflistung von Begriffen und ihren Erklärungen (Definitionen)</dd>
  <dt>Beschreibungsliste (<i lang="en">description list</i>)<dt>
  <dd>Eine allgemeine Liste von Name-Wert-Paaren</dd>
</dd>

werden in der Tat die Inhalte der dt-Elemente definiert durch die Inhalte der zugehörigen dd-Elemente.

Das ist bei

<dl>
  <dt>Name</dt>
  <dd>Gunnar Bittersmann</dd>
  <dt>Position<dt>
  <dd>Querulant</dd>
</dd>

nicht der Fall; weder wird der Begriff „Name“ durch den Namen einer Person definiert noch „Position“ durch deren Position. Das ist keine Definitionsliste.

Definitionslisten sind eine mögliche Anwendung von Beschreibungslisten. Und bei Weitem nicht die häufigste.

Die HTML5-Spec berichtigt die Benennung vorheriger HTML-Specs bzw. passt die Benennung des dl-Elements dessen tatsächlicher Verwendung an.

LLAP