Anfängerfrage HTML

[Nedo]

Hi, ich mach gerade 'ne kleine Doku für unsere Mitarbeiter in Form einer "Minihomepage" ^^

Mein Problem. Ich hätte ein Hintergrundbild, allerdings ist das viel größer als die meisten Monitore hier im Haus. Gibts eine Möglichkeit (im body, oder so), dass es das Bild wie auf dem Desktop streckt bzw. verkleinert, so dass es passt? :)

Wäre klasse ^^

[Coda]

Nein. Und die Idee ist sowieso schlecht.

[Nedo]

Nein. Und die Idee ist sowieso schlecht.
Wie schlecht die Idee ist, is mal egal, war auch nicht meine ^^

Aber gut, danke!

[creave]

Gibt ein Workaround über ein Table mit dem es hinzubekommen ist, aber wie Coda schon sagte, ist keine gute Idee. CSS 3 könnte das, falls es innerhalb dieses Jahrhunderts mal noch flächendeckend unterstützt werden sollte - aber selbst dann wärs keine gute Idee.

[mapel110]

Resizen oder schnibbeln mit nem Bildbearbeitungstool und gut ist.
Quer scrollen im Netz ist echt übel.

[Matrix316]

Er will ja nicht dass man Scrollen muss.

http://forum.de.selfhtml.org/archiv/2005/5/t108373/

<table width=100% border=0 cellspacing=0 cellpadding=0 style="table-layout: fixed;">
<tr>
<td><img src="unbenannt.png" width=100%></td>
</tr>
</table>

EDIT: Allerdings kein Hintergrundbild. ;) Müsste man dann irgendwie als Background machen, der wiederum in der Höhe nicht unbedingt dann dynamisch sich verändert.

[collapse]

Also wer heute noch fur das Layout Tables verwendet, dem ist echt nicht mehr zu helfen und ghoert aus der Webbranche verbannnt

[mapel110]

Also wer heute noch fur das Layout Tables verwendet, dem ist echt nicht mehr zu helfen und ghoert aus der Webbranche verbannnt
Warum?
Wenn ich die Daten auch noch in Excel brauche, gibts nichts besseres imo. Vorallem hat man dabei im Gegensatz zu CSV auch noch ein paar kleine Formatierungsmöglichkeiten im Voraus.

[Coda]

Da willst du auch eine Tabelle darstellen. Er meint normale Page-Layouts, und dafür ist es wirklich beschissen.

Ich will dir nicht zu Nahe treten, aber du hast noch viel zu lernen und kommentierst hier teilweise schon wie der absolute Profi...

[mapel110]

Aber für Page-Layouts reicht es doch auch. Damit lässt sich prima Seiteninhalt gliedern. Mit CSS-Ebenen geht einiges mehr, aber das ist auch aufwendiger. Was solls da noch geben?! Frames sollte man ja nicht mehr verwenden.

[Coda]

Aber für Page-Layouts reicht es doch auch.
Tut es schon, es ist aber extrem unflexibel und widerspricht der Trennung von Layout und Inhalt aufs Gröbste. Zudem ist das Rendering langsamer und der Code größer. Das macht man einfach nicht mehr.

[RMC]

und widerspricht der Trennung von Layout und Inhalt aufs Gröbste

Aha..wo denn genau?

[Coda]

Überall?!? WTF? Sag mal willst du trollen?

http://www.csszengarden.com/tr/deutsch/

[The_Invisible]

also weniger kopfzerbrechen habe ich bei tables in den verschiedenen browsern, was da sonst selbst mit validem (laut w3c) code oft für ein murks rauskommt ist echt nicht mehr schön.

aber ist schon richtig, tables sind fürs designen nicht gedacht, man hat sie eher dafür missbraucht.

mfg

[Coda]

So schwer ist es gar nicht mit Divs zu arbeiten. Das schlimmste daran ist halt IE6.

[Matrix316]

Also eine CSS Seite als Referenz zu nehmen, dass man CSS nehmen soll ist wie Microsoft zu fragen ob man Windows oder Linux als Hauptdesktopbetriebsystem nehmen soll. ;)

Es gibt genügend wirklich große Webseiten wo man durchaus sehr viel Tabellen als Layouthilfen findet. Warum soll ich mich mit Divs rumquälen, wenns Tabellen manchmal viel einfacher tun - und sogar fast immer funktionieren?! ;)

[Superguppy]

Weil Tabellen nicht sonderlich fein sind was Schriftarten skalieren und Braille-Displays angeht.

[Coda]

Also eine CSS Seite als Referenz zu nehmen, dass man CSS nehmen soll ist wie Microsoft zu fragen ob man Windows oder Linux als Hauptdesktopbetriebsystem nehmen soll. ;)
Vielleicht solltest du mal den Text auf der Seite lesen und kapieren um was es dort geht anstatt hier Dünnschiss abzulassen.

Es gibt genügend wirklich große Webseiten wo man durchaus sehr viel Tabellen als Layouthilfen findet. Warum soll ich mich mit Divs rumquälen, wenns Tabellen manchmal viel einfacher tun - und sogar fast immer funktionieren?! ;)
Weil es nicht einfacher ist, sondern die Leute einfach zu faul was neues zu lernen. Und zweitens ist es wie gesagt schlanker und schneller. Zudem wirst du spätestens beim ersten Redesign glücklich sein wenn du fast nichts am HTML ändern musst.

Zudem ist die Accessibility 1000x besser. Und da meine ich nicht nur Behinderte, sondern auch Stylesheets für Mobile-Devices und Print.

Es ist einfach nur komplette Blödheit ein größeres Projekt heute noch auf einem Tabellenlayout aufzubauen. Und meine Aussage, dass die Trennung von Layout und Inhalt bei Tabellen einfach nur beschissen - weil nicht vorhanden - ist, ist auch absolut richtig.

[RattuS]

Ich weiß nicht, in welcher Forum das Hintergrundbild als Quelle vorliegt, aber im Zweifelsfalle einfach auf minimale Größe resizen (512x384, sollte dann auch auf 640x480ern komplett sichtbar sein) und dann als Hintergrundbild zentrieren?

[Coda]

Ich entschuldige mich für meinen Ton vorher. War etwas angenervt wegen anderen Dingen. Die Aussage bleibt aber bestehen.

[del_4901]

Claude Elwood würde sich im Grabe umdrehen.

[RMC]

Überall?!? WTF? Sag mal willst du trollen?

http://www.csszengarden.com/tr/deutsch/

lol

Html-Templates können ebenso wie CSS als reines Layout fungieren. Daher versteh ich nicht warum du hier die Trennung von Layout/Content anführst.

Layout = CSS/Html. Inhalt = PHP,Perl,xScript etc...

[Coda]

Layout ist CSS und Inhalt ist HTML. Ich meinte die reine Clientseite. Und nein das ist nicht "lol" sondern die Richtung in der sich das ganze Web im Moment bewegt.

Es ist viel einfacher das CSS zu ändern um für Print, Mobile und Desktop die Seite zu haben anstatt am Server am Code rumpfuschen zu müssen. Genau das gleiche bei Layoutänderungen.

[RMC]

Layout ist CSS und Inhalt ist HTML. Ich meinte die reine Clientseite. Und nein das ist nicht "lol" sondern die Richtung in der sich das ganze Web im Moment bewegt.

Es ist viel einfacher das CSS zu ändern um für Print, Mobile und Desktop die Seite zu haben anstatt am Server am Code rumpfuschen zu müssen. Genau das gleiche bei Layoutänderungen.

Schon mal was von HTML Templates gehört?

[Coda]

Ja. Und jetzt? Das ist trotzdem nicht das gleiche.

Vor allem bringt's mir nix bei der Accessibility. Semantisches HTML ist auch noch für Blinde und ganz ohne CSS komplett strukturiert lesbar. Zudem wird deutlich weniger übertragen weil das Stylesheet gecached wird.

Ich hätte echt nicht gedacht, dass es noch Sturköpfe gibt auf der Welt bei denen das nicht durchgedrungen ist.

[RMC]

Du hast gemeint, ein Page-Layout (html) widerspricht der Trennung von Code und Design. Dem widerspreche ich. Html IST Design.

[Coda]

Nein eben nicht. HTML ist Markup und beschrieb am Anfang die Struktur des Dokuments, nicht das Design. Das wurde nur zwischendurch mal vergessen.

Es ist insofern auch böse für alles divs zu verwenden. Wenn man eine Überschrift setzt dann nimmt man <h1> und für die Unterüberschrift <h2>. Genauso wie es böse ist <br> für einen Paragraphen statt <p> zu verwenden.

Das hat ausschließlich positive Effekte. Man spart Bandbreite, hilft Behinderten beim lesen und hat es einfacher beim Wechsel des Designs.

[RMC]

Gut, anders formuliert, extra für dich: HTML ist nicht "Inhalt", und daher widerspricht es nicht der Trennung.

[Coda]

Auf was willst du eigentlich hinaus?

Schreib doch weiter deine archaischen Tabellen-Layouts die clientseitig alles in einen Haufen zusammenwerfen und das Austauschen von Designs zu einem Marathon durch den ganzen HTML-Template oder View-Mist machen.

Das ist mir sowas von egal. Fakt bleibt trotzdem, dass das veraltet ist und es von vernünftigen Menschen nicht mehr praktiziert wird. Und vielleicht solltest du auch mal paar Quellen lesen. Es wird immer von Trennung von Inhalt und Design geredet in diesem Zusammenhang. Was du dir da zusammendefinierst ist sowas von irrelevant in dieser Diskussion.

Web style sheets are a form of separation of presentation and content for web design in which the markup (i.e., HTML or XHTML) of a webpage contains the page's semantic content and structure, but does not define its visual layout (style). Instead, the style is defined in an external stylesheet file using a language such as CSS or XSL. This design approach is identified as a "separation" because it largely supersedes the antecedent methodology in which a page's markup defined both style and structure.

The philosophy underlying this methodology is a specific case of separation of concerns.

Aber auf Wikipedia steht natürlich nur Scheiße, gell?

[RMC]

Ich zitier dich nochmal, dann weißt du auch worum es mir geht ;)

und widerspricht der Trennung von Layout und Inhalt aufs Gröbste.

Coda, der einzige Fakt ist, dass der Inhalt einer Seite nicht vom Table-Layout stammt. Inhalt kommt von ganz anderen Quellen mkay? ;) CSS ist fürs Design zuständig, okay. HTML ist für die Struktur zuständig, okay. Aber der "Inhalt" und die damit verbundene von dir getätigte Aussage, hat damit genau nichts zu tun.

[Coda]

Mit "Inhalt" meine ich das ganze Markup. Genauso wie es Wikipedia und alle anderen die davon reden auch verstehen.

Inhalt ist schließlich auch z.B. das eine Zeile jetzt ein Heading ist, oder das ein neuer Paragraph anfängt. Das ist mit Tabellen-Layouts einfach nicht ausdrückbar. Stichwort "semantisches HTML".

[RMC]

Mit "Inhalt" meine ich das ganze Markup

Struktur ist für mich nicht Inhalt. Da wir hier geteilter Meinung sind, führt das
scheinbar zu nichts. Daher ist für mich hier EOD.

[Coda]

HTML ist eben nicht nur Struktur, das ist dein Problem. Es ist für einen Screenreader sehr wohl Inhalt ob das was kommt jetzt ein Heading ist oder nur ein Paragraph. Der Rest des Internets ist da scheinbar aber auch meiner Meinung.

Ich finde es auch immer wieder lustig wie du immer die Argumente aus den Zitaten weglässt. So macht man sich's natürlich einfach.

[Matrix316@Mittag]

Mit "Inhalt" meine ich das ganze Markup. Genauso wie es Wikipedia und alle anderen die davon reden auch verstehen.

Inhalt ist schließlich auch z.B. das eine Zeile jetzt ein Heading ist, oder das ein neuer Paragraph anfängt. Das ist mit Tabellen-Layouts einfach nicht ausdrückbar. Stichwort "semantisches HTML".


hmmm..........wat sachsten dazu: :naughty:



<table>

<tr>
<td style="background-color:Blue"><h1>Überschrift 1</h1>
<h2>Überschrift 1.1</h2>
<p>Paragraph 1</p>
<p>Paragraph 2</p>
<p>Paragraph 3</p>
<p>Paragraph 4</p>
</td>
<td style="background-color:Green"><h1>Überschrift 2</h1>
<h2>Überschrift 1.1</h2>
<p>Paragraph 5</p>
<p>Paragraph 6</p>
<p>Paragraph 7</p>
<p>Paragraph 8</p>
</td>
</tr>

<tr>
<td colspan="2" style=" background-color:Red; border-bottom-style:double; text-align:center">
<h1>Überschrift 3</h1>
<p>Absatz 9 und noch mehr Text</p>
<p>Absatz 10 und noch mehr Text</p>

</td>
</tr>
</table>

[Coda]

Das ist kein semantisches HTML, weil die Table da einfach nicht hingehört. Die Tabelle wird nicht verwendet um eine Tabelle darzustellen sondern um das Layout zu erzeugen.

http://phrogz.net/css/WhyTablesAreBadForLayout.html

Nur ein random-link den ich rausgefischt habe. Die Gründe die da aufgezählt werden reichen schon ewig aus um es bleiben zu lassen.

[Daltimo]

Richtig, weil da auch CSS enthalten ist, welches nur für das Layout gedacht ist.

Warum hat hier eigentlich noch keiner Phase 5 empfohlen, da braucht man sich das ganze nur mehr oder weniger zusammen klicken.

[mapel110]

Tables are usually more bytes of markup. DSL Anyone?
(Longer to download, and more bytes of traffic for the host.)
Tables are usually slower to layout for the browser. Jo, sind ja alle mit PDAs sonstigen 200 Mhz-Rechnern unterwegs im Web
(Takes longer for the user to see anything on the page.)
Tables usually prevent incremental rendering. Ahja, schlimm, wenn man 2 Sekunden länger warten muss.
(Takes longer for the user to see anything on the page.)
Tables may require you to chop single, logical images into multiple ones. Okay, lass ich gelten, aber Bilder auf einer Webseite mit tables als Nachteil anführen und bei anderen Punkten wieder den Speed mukieren ja ja ja...wie mans gerade braucht...
(This makes redesigns total hell, and also increases page load time [more http requests and more total bytes].)
Tables break text copying on some browsers. Der User soll nicht kopieren. Er soll immer wieder auf meine Seite kommen oder verlinken :P
(That's annoying to the user.)
Tables prevent certain layouts from working within them (like height:100% for child elements of <td>). 100% Height... Ist genau wie viel? Ich weiß es nicht und meist weiß es nicht mal der Browser.
(They limit what you can actually do in terms of layout.)
Once you know CSS, table-based layouts usually take more time to implement. Nö. Wenn ich für jeden Pfurz ne CSS-Ebene Anlegen muss, dauerts länger. Und ob ich weiß wie das geht...
(A little effort up-front learning CSS pays off heavily in the end.)
Tables are semantically incorrect markup for layout. Ah, das alles erschlagende Argument!!!
(They describe the presentation, not the content.)
Tables make life hell for those using screen readers. Barrierefrei ist toll. Den lass ich gelten.
(Not only do you get the other benefits of CSS, you're also helping out the blind/partially-sighted. This is a Good Thing.)
Tables lock you into the current design and make redesigns MUCH harder than semantic HTML+CSS. Ich schreib die Seite meist einmal, dann rühr ich sie nie wieder an. Für Seiten mit regelmäßigen Updates okay. Lass ich dann auch gelten.
(Have you seen CSS Zen Garden?)

[Crow1985]

Weil selbst der Mann ist.
Coda hat schon recht, auch wenn er es etwas hart ausdrückt, das W3C sieht das auch nicht mehr gern.

[Coda]

Kannst du das auch so posten dass man dazu antworten kann?

Nur mal zu dem Zeug am Anfang: Mich stört es sehr wohl, wenn der Browser 2s braucht um das Page-Layout zu rendern weil das ganze Tabellen-Murks ist. Und ja, das passiert auch auf einem Core 2 noch, nicht nur auf deinem 200 Mhz PDA. Und mobile Geräte sind immer mehr im kommen.

Und nein, Tabellen gehen nicht schneller von der Hand, wenn man CSS mal drauf hat und die Seite entsprechend strukturiert. Ich gebe zu dass das etwas Zeit braucht. Ich hab früher auch Tabellen verwendet, aber das ist nicht schneller. Vor allem wenn man nachträglich was am Layout ändern will. Da wirst wahnsinnig damit. Schau dir einfach mal das HTML von Zen Garden (http://www.csszengarden.com/) an und erzähl mir dann nochmal das hättest du mit Tables so schneller hinbekommen.

Für 08/15-Designs ohne Anspruch mögen Tables genügen, aber darüber will man auch irgendwann mal wegkommen.

http://www.hotdesign.com/seybold/

[beos]

Also - gerade bei dynamisch erzeugten Seiten hab ich immer das Problem, dass div Blöcke - selbst wenn sie die Eigenschaft "overflow = visible" besitzen nicht richtig "overflowen" (blöd ausgedrückt - ich weiß)...

So wird ein Block, der mit 100x100 px def. ist - und in dessen Innern 10 x 100 px breite große Blöcke erzeugt werden nie 1000 px breit - alle 10 Blöcke werden zwar angezeigt - der Hintergrund Block wird aber nicht 1000 px breit..

Erzeuge ich aber 10x100 px breite Tabellen wird der umschließende Block 1000 px breit und alles ist OK ....

Gibts da was Sinnvolleres :confused:

[Matrix316]

Nehmen wir mal an, ich hab ein Formular mit vielen Textfeldern und Labeln. Pack ich dann jedes Element in ein Div oder wie würde ich es mit CSS untereinander hinbekommen, so dass es nicht wie Kraut und Rüben aussieht? Also dass Textboxen und Labels immer bündig ausgerichtet sind?

[Coda]

http://www.alistapart.com/articles/prettyaccessibleforms

[mapel110]

Viel Text
Overflow hatte ich auch mal in Verwendung. Der IE6 hatte damit Probleme. In Firefox (1.5 iirc) damals gings und in Opera9 auch.
Müsste die Seite mal rauskramen und mit IE7 angucken..

@Coda
K, die Seite werd ich mir genauer anschauen, speziell dann, wenn die Funktionalität von meinem Projekt fertig ist und ich dafür das Layout machen werde.

Ich bin ja nicht unaufgeschlossen gegenüber CSS. Ich finds selbst toll. Aber ich verteufel auch nichts, was älter ist und funktioniert und seinen Zweck bestens erfüllt. Auch wenn das nicht Standard ist, ich glaub, der IHK bei der ich das Projekt präsentieren werde, hat noch weniger Ahnung als ich. Zumal ich von einem aus dem Prüfungsausschuss unterrichtet werde und der kann nur Cobol und hat von Objektorientierung noch nie was gehört. :D bzw. eigentlich ists ja traurig ;(

[DanMan]

Nehmen wir mal an, ich hab ein Formular mit vielen Textfeldern und Labeln. Pack ich dann jedes Element in ein Div oder wie würde ich es mit CSS untereinander hinbekommen, so dass es nicht wie Kraut und Rüben aussieht? Also dass Textboxen und Labels immer bündig ausgerichtet sind?
Bei solchen Formularen sehe ich Tabellen als legitim an. Die Daten haben tabellarischen Bezug zueinander, warum also nicht.

[Tiamat]

Es gibt sicher Dinge, die in einer Tabelle leichter umzusetzen sind, als dann in der Css Datei hundert positionierte ul oder li Klassen/Ids abwühlen zu müssen.
Aber für´s Layouten nehm ich mal abgesehen davon, dass fast jeder Webdesign-Guide propagiert Css zu benutzen, lieber Css.
Nichts kann schlimmer sein, als sich durch 100.000-Tabellenelemente zu wühlen, nur um darauf zu achten, ob <th><tr><td> und was weiß ich richtig geöffnet, richtig geschrieben und richtig geschlossen wurden ;D
Doch Css ist leider auch kein Wundermittel.
Es macht Spaß solange es funktioniert, aber bei Browserweichen und Inkompatiblitäten verliert man dann auch den Spaß dran.

Um auf das Problem zurückzukommen..
Also wenn du keine Lust haben solltest, das Bild mittels Photoprogramm auf eine Thumbnail-Größe zu reduzieren, kannst du dir´s mit Css recht einfach machen.

im Stylesheet:

.thumbnail {

border:none; // ich nehme an, du hast einen anderen Rahmen vorgesehen
width:250px;
height:250px;

}

in der HTML Datei:
<div id="bla">
<a href="pic.jpg"><img class="thumbnail" src="... " alt = "" /></a>
...
</div>

Es wird also ein Bild angezeigt der Größe(höhe und breite jeweils) 250px. Beim Daraufklicken erscheint dann dann Bild in Orginalgröße.
Ja es ist vermutlich stark gestaucht, mit den pixelangaben und dem vorgesehenen Platz auf der Homepage kannst du ja auch wenig rumexperimentieren. Aber wenn du der .thumbnail Klasse einen schönen Rahmen verpasst hast(also nicht mit Css) , kannst du das gut kachieren.
Gruß

[beos]

Overflow hatte ich auch mal in Verwendung. Der IE6 hatte damit Probleme. In Firefox (1.5 iirc) damals gings und in Opera9 auch.
Müsste die Seite mal rauskramen und mit IE7 angucken..


Hmm....bei mir funktioniert das in keinem einzigen Browser :confused:

Hier ein Bsp - die schwarze obox müßte größer werden - wird sie aber nicht...

Nehme ich statt den inneren Blöcken Tabellen wird sie es...



<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Unbenanntes Dokument</title>
<style type="text/css">
<!--
#obox {
position:relative;
background-color:#000000;
width:100px;
height:100px;
overflow: visible;
z-index:1;
}
#box {
position:relative;
background-color:#00FFFF;
margin-bottom:5px;
top:5px;
width:100px;
height:100px;
z-index:1;
}
-->
</style>
</head>

<body>
<div id="obox"><div id="box"></div><div id="box"></div><div id="box"></div><div id="box"></div><div id="box"></div></div>
</body>
</html>

[Coda]

Du hast schon recht. Die breite eines divs hängt nicht vom Inhalt ab.

[darph]

Hier ein Bsp - die schwarze obox müßte größer werden - wird sie aber nicht...


#obox {
width:100px;
overflow: visible;
}

Öhm. Nö.

overflow: visible heißt, daß der Inhalt sichtbar ist. Mehr nicht. In dem Moment, in dem du eine fixe Breite (oder Höhe, Jacke wie Hose) vorgibst, ist die Box auch nur genau so breit.

visible = Inhalt ragt aus dem Element so weit heraus, dass sein Inhalt auf jeden Fall komplett sichtbar ist.

Die ganze Thematik jetzt in Bezug auf die Höhe wurde in diesem Forum aber auch schon des Öfteren angesprochen. Also... wöchentlich oder so. Man suche mal nach "faux columns".

Du hast schon recht. Die breite eines divs hängt nicht vom Inhalt ab. Eben. Normalerweise ist eine Box so breit wie möglich. Wenn nicht, muß man die Breite explizit, absolut oder relativ zum Elter, angeben.

[beos]

Öhm. Nö.

overflow: visible heißt, daß der Inhalt sichtbar ist. Mehr nicht. In dem Moment, in dem du eine fixe Breite (oder Höhe, Jacke wie Hose) vorgibst, ist die Box auch nur genau so breit.


Hmm...wenn ich die inneren Blöcke durch 3 Tabellen ersetze wird der äußere Block vergrößert

http://img148.imageshack.us/img148/1724/clipboard02ls3.th.jpg (http://img148.imageshack.us/my.php?image=clipboard02ls3.jpg)