Gathering of Tweakers

Ik heb in 1 table 2 <form> tags, echter ik wil geen wit ruimte die gecreeerd word door de FORMS, het lukt wel om dit goed te krijgen, maar dan krijg ik het niet gevalideert als XHTML 1.0 Transitional.

In het kort heb ik zoiets:

HTML:

1 2 3 4 5 6 7 8 9 10 11 12

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

Ook het volgende -het opslitsen van 1 TABLE in twee word niet gevalideert:


HTML:

1 2 3 4 5 6 7 8 9 10 11 12 13 14

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

Ik wil dus dat het EN valideert als Valid XHTML 1.0 Transitional en geen witruitme krijgen tussen de 2 FORMS.

quote:

TNX! Zat ook al te denken om te kijken door het met stylesheets op te lossen, maar is er geen HTML manier hiervoor?

Euh? Het is niet '95 meer, weet je ;-). Verder is XHTML niet echt aan te raden, zeker niet als je er op zo'n manier over denkt ;-)

quote:

Anne schreef op maandag 24 januari 2005 @ 22:27:
[...]
Euh? Het is niet '95 meer, weet je ;-). Verder is XHTML niet echt aan te raden, zeker niet als je er op zo'n manier over denkt ;-)

Of juist wel... webstandaarden moeten toch gebruikt worden. Het meeste leer je van je doctype op XHTML 1.1 te zetten en keihard van je fouten leren.

quote:

Anne schreef op maandag 24 januari 2005 @ 22:27:
[...]
Euh? Het is niet '95 meer, weet je ;-). Verder is XHTML niet echt aan te raden, zeker niet als je er op zo'n manier over denkt ;-)

Waarom is XHTML niet aan te raden? Mijn bovenstaande vraag is omdat ik dat puur niet wist, je kan niet alles weten, toch?

Urk wijzigde dit bericht 24-01-2005 22:30 (3%)

quote:

Waarom is XHTML niet aan te raden? Mijn bovenstaande vraag is omdat ik dat puur niet wist, je kan niet alles weten, toch?

Maar als je gaat vragen of iets wat met layout te maken heeft op te lossen valt in HTML zit je er toch een beetje naast.

Over XHTML zijn diverse discussies gevoerd op dit forum. Maar check bijvoorbeeld: http://hixie.ch/advocacy/xhtml en http://www.mozilla.org/docs/web-developer/faq.html#accept

quote:

Anne schreef op maandag 24 januari 2005 @ 22:33:
[...]
Maar als je gaat vragen of iets wat met layout te maken heeft op te lossen valt in HTML zit je er toch een beetje naast.

Ben ik niet met je eens: alle TABLE tags zijn ook puur layout en om goed te kunnen rangschikken, dat je wellicht tegenwoordig ook TABLES kan bouwen met CSS i.p.v. HTML tags weet ik.

Als je XHTML afraad, wat zou je dan i.p.v. XHTML aanraden? Gewoon HTML 4?

quote:

Norm2782 schreef op maandag 24 januari 2005 @ 22:29:
[...] Of juist wel... webstandaarden moeten toch gebruikt worden. Het meeste leer je van je doctype op XHTML 1.1 te zetten en keihard van je fouten leren.

En dus gebruik je geen CSS, semantisch incorrecte pagina's en serveer je je XHTML maar op de verkeerde manier? .

quote:

Urk schreef op maandag 24 januari 2005 @ 22:46:
[...] Ben ik niet met je eens: alle TABLE tags zijn ook puur layout en om goed te kunnen rangschikken, dat je wellicht tegenwoordig ook TABLES kan bouwen met CSS i.p.v. HTML tags weet ik.

Ehm, <table> is voor tweedimensionele data, niet voor layout. Je zou je pagina met HTML structuur moeten geven en deze stylen met CSS. Dat je een tabel ook kan gebruiken voor layout is iets anders dan dat het ervoor is.

quote:

Als je XHTML afraad, wat zou je dan i.p.v. XHTML aanraden? Gewoon HTML 4?

4 Strict .

JHS wijzigde dit bericht 24-01-2005 22:49 (48%)

quote:

JHS schreef op maandag 24 januari 2005 @ 22:47:
[...]

En dus gebruik je geen CSS, semantisch incorrecte pagina's en serveer je je XHTML maar op de verkeerde manier? .

Hoezo? Wie zegt dat ik geen CSS en geen semantisch (jezus, wat een woord! ) incorrecte pagina's serveer?

Urk wijzigde dit bericht 24-01-2005 22:52 (3%)

quote:

Urk schreef op maandag 24 januari 2005 @ 22:46:

Ben ik niet met je eens: alle TABLE tags zijn ook puur layout en om goed te kunnen rangschikken...

Nee, tabellen zijn er om verbanden kunnen aan te geven tussen stukken data. Rijen, kolommen, de betekenis en scope van elke cel...
Bij een goed opgezette tabel is duidelijk wat een bepaalde cel voor data bevat, aangezien dat bijvoorbeeld wordt aangegeven in een rij of kolom heading.

quote:

Cheatah schreef op maandag 24 januari 2005 @ 23:07:
[...]

Nee, tabellen zijn er om verbanden kunnen aan te geven tussen stukken data. Rijen, kolommen, de betekenis en scope van elke cel...
Bij een goed opgezette tabel is duidelijk wat een bepaalde cel voor data bevat, aangezien dat bijvoorbeeld wordt aangegeven in een rij of kolom heading.

offtopic:
Overigens wordt ik het gebruik-geen-XHTML gebeuren een beetje zat. Er gaat doorgaans weinig mis als je XHTML met text/html serveert, het mag, het is niet ideaal, maar uiteindelijk maakt het weinig uit. Tuurlijk, het wordt gewoon als HTML 4.01 behandeld, maar dat gaat gewoon prima.
Ik raad meestal wél de XHTML syntax aan, puur omdat je geneigd bent er wat netter mee te werken. Dat iets niet ideaal is maakt het niet fout. De browser ontvangt een document, en behandelt het als HTML. Dat gaat prima omdat XHTML 1.0 is gemaakt met een stukje backward compatibility.
Ik had zelf ook veel liever gezien dat er wat meer mensen zelf die specificaties gingen lezen, en zelf gingen interpreteren, in plaats van elkaar napraten.

Hier ben ik het helemaal mee eens, zelfs over het eerste met betrekking tot de TABLES, je hebt helemaal gelijk.

quote:

Cheatah schreef op maandag 24 januari 2005 @ 23:07:
[...]

Nee, tabellen zijn er om verbanden kunnen aan te geven tussen stukken data. Rijen, kolommen, de betekenis en scope van elke cel...
Bij een goed opgezette tabel is duidelijk wat een bepaalde cel voor data bevat, aangezien dat bijvoorbeeld wordt aangegeven in een rij of kolom heading.

kleine toevoeging waar ik me zelf wel eens aan kan ergeren.

Dit betekent dus niet dat je het ALLEEN voor data hoeft te gebruiken.
ook design kan bestaan uit tabellen.
zie quote CSS 2.1

quote:

In a visual medium, CSS tables can also be used to achieve specific layouts. In this case, authors should not use table-related elements in the document language, but should apply the CSS to the relevant structural elements to achieve the desired layout.

Echter gezien bepaalde browsers CSS tabellen niet snappen, vind ik het soms geoorloofd om tabellen te gebruiken.

quote:

StratoS_V2.0 schreef op maandag 24 januari 2005 @ 23:45:

kleine toevoeging waar ik me zelf wel eens aan kan ergeren.

Dit betekent dus niet dat je het ALLEEN voor data hoeft te gebruiken.
ook design kan bestaan uit tabellen.
zie quote CSS 2.1

Daar staat dus keurig uitgelegd dat je geen HTML table elementen zou moeten gebruiken als je alleen uit bent op een tabel-achtige layout. Zie ook de HTML 4.01 specificatie over tabellen.

quote:

Echter gezien bepaalde browsers CSS tabellen niet snappen, vind ik het soms geoorloofd om tabellen te gebruiken.

Soms, maar niet vaak. Als je echt een lastig ontwerp hebt, en je wilt van het gezeur van de designer af, dan maak je het met een tabel. Maar dan moet je nog altijd heel goed beseffen wat je precies aan het doen bent.

quote:

offtopic:

Q:waarom zijn de specs van css van belang in een xhtml discussie?
A: omdat xhtml zegt dat css de stijl/layout beschrijft.

quote:

Cheatah schreef op maandag 24 januari 2005 @ 23:07:
[...]

[..]

offtopic:
Overigens wordt ik het gebruik-geen-XHTML gebeuren een beetje zat. Er gaat doorgaans weinig mis als je XHTML met text/html serveert, het mag, het is niet ideaal, maar uiteindelijk maakt het weinig uit. Tuurlijk, het wordt gewoon als HTML 4.01 behandeld, maar dat gaat gewoon prima.
Ik raad meestal wél de XHTML syntax aan, puur omdat je geneigd bent er wat netter mee te werken. Dat iets niet ideaal is maakt het niet fout. De browser ontvangt een document, en behandelt het als HTML. Dat gaat prima omdat XHTML 1.0 is gemaakt met een stukje backward compatibility.
Ik had zelf ook veel liever gezien dat er wat meer mensen zelf die specificaties gingen lezen, en zelf gingen interpreteren, in plaats van elkaar napraten.

en vervolgens, als iedereen xhtml doet in een niet-xhtml ondersteunende omgeving en wat exotischere js willen gaan toepassen gaat alles na wat debuggen waarschijnlijk goed, maar zodra je in wel in een xhtml odnersteunende omgeving zit loopt het fout, je domtree is anders (case sensitive) en bepaalde niet-dom dingen werken gewoon niet meer.

Ik maak liever de mensen nu bewust dan ze dalijk allemaal duidelijk te gaan maken dat ze er nooit een hol van hebben begrepen (precies een punt van Hixie ook)

edit: ik wil ook niet zeggen dat je geen xhtml moet gebruiken, maar weet wel waar je mee bezig bent. Mensen die xhtml 1.1 gebruiken hebben het gewoon niet begrepen en doen gewoon wat de meute doet. Als je xhtml 1.0 doet met text/html, mij best, maar weet wel dat je tagsoup serveert en weet ook de gevolgen ervan (die in de meeste gevallen idd gering zijn)

mophor wijzigde dit bericht 25-01-2005 19:12 (12%)

idd, browsers behandelen xhtml, wat geserveerd is als text/html als een zooitje text en proberen daar met een bende foutcorrectie erover html uit te filteren. Dit gebeurt met een andere parser dan een xml parser, namelijk een html (4) parser.

Je browser behandelt je xhtml dus gewoon als html, niets meer, niets minder, met wat gevolgen vandien. (onder andere dat je in je js een html 4 dom krijgt, geen xml dom)

een leuk voorbeeldje van die foutcorrectie is het negeren van alle /> afsluitingen, als een sgml parser deze correct zou behandelen, zou ie dit lezen als >&gt; en zou je dus overal > characters krijgen (hebben jullie Hixies artikel al gelezen )

js voorbeeldje:

JavaScript:

1 2 3 4

anAnchor = document.getElementById('foo'); //een anchor element bijvoobeeld if (anAnchor.tagName=='A') {   alert('ja het is een anchor'); }

dat werkt in tagsoup-html (html 4 & xhtml als text/html), maar niet in een xml dom. Daar zou die a juist een kleine letter moeten zijn (aangenomen dat je tag een kleine letter bevat). Zou je hier een kleine letter van maken, dan werkt het weer niet in de html dom, maar wel in de xml dom.

uit hixies artikel dus:

quote:

Appendix D: Footnotes
---------------------

[1] The term "handled as tag soup" refers to the fact that UAs
typically are very lenient in their error handling, and do not support
any of the "advanced" SGML features. For example, browsers treat the
string "<br/>" as "<br>" and not "<br>>", the latter being what
SGML says they should do. Similarly, real world UAs have no problem
dealing with content such as "<b> foo <i> bar </b> baz </i>" even
though according to the HTML4 spec that is meaningless.

en ook:
zoeken bij google naar 'tag soup'

mophor wijzigde dit bericht 25-01-2005 20:16 (65%)

quote:

mophor schreef op dinsdag 25 januari 2005 @ 20:07:
idd, browsers behandelen xhtml, wat geserveerd is als text/html als een zooitje text en proberen daar met een bende foutcorrectie erover html uit te filteren. Dit gebeurt met een andere parser dan een xml parser, namelijk een sgml parser.

Als je de XHTML syntax gebruikt dan hoeft de parser niet veel te raden. Dat er een parser wordt gebruikt die ranzige HTML kan lezen, wil niet zeggen dat alles wat die parser kan lezen ranzig is. XHTML is ontworpen om ook door die parsers gelezen te kunnen worden.

quote:

Je browser behandelt je xhtml dus gewoon als html, niets meer, niets minder, met wat gevolgen vandien. (onder andere dat je in je js een html 4 dom krijgt, geen xml dom)

HTML 4 DOM is nieuw voor me. Er is inderdaad zoiets als DOM HTML. Versie 1.0 was gemaakt met het oog op HTML 4.01 dat wel. Maar er is niet veel stuntwerk voor nodig om code te schrijven die gewoon werkt.

quote:

een leuk voorbeeldje van die foutcorrectie is het negeren van alle /> afsluitingen, als een sgml parser deze correct zou behandelen, zou ie dit lezen als >&gt; en zou je dus overal > characters krijgen (hebben jullie Hixies artikel al gelezen )

Ja, maar het interesseert mij niets wat Hixie ervan vindt. Ik ben prima in staat zelf een mening te vormen op basis van eigen ervaring.

En die ervaring vertelt mij dat ik nog nooit een serieuze browser dat /> fout heb zien doen.

Handige fix:

JavaScript:

1 2 3 4

anAnchor = document.getElementById('foo'); //een anchor element bijvoobeeld if (anAnchor.tagName.toLowerCase() == 'a') {   alert('ja het is een anchor'); }

dat werkt in tagsoup-html (html 4 & xhtml als text/html), maar niet in een xml dom. Daar zou die a juist een kleine letter moeten zijn (aangenomen dat je tag een kleine letter bevat). Zou je hier een kleine letter van maken, dan werkt het weer niet in de html dom, maar wel in de xml dom.[/quote]
Mijn versie werkt prima. Zo kun je je snippets gewoon overal inzetten.

Over Hixie:

quote:

<script> and <style> elements in XHTML sent as text/html have to be escaped using ridiculously complicated strings.

Daarom roep ik al jaren om de scripts en stylesheets in losse bestanden te zetten.

quote:

A CSS stylesheet written for an HTML4 document is interpreted slightly differently in an XHTML context (e.g. the <body> element is not magical in XHTML, tag names must be written in lowercase in XHTML). Thus documents change rendering when parsed as XHTML.

Dat valt wel mee als je gewoon weet hoe het zit. Ik gebruik altijd lowercase elementen en attributen, ook in de stylesheets, en ook zorg ik dat met DOM alles lowercase is.

quote:

A DOM-based script written for an HTML4 document has subtly different semantics in an XHTML context (e.g. element names are case insensitive and returned in uppercase in HTML4, case sensitive and always lowercase in XHTML; you have to use the namespace-aware methods in XHTML, but not in HTML4). BUT, if you send your documents as text/html, then they will use the HTML4 semantics DESPITE being XHTML! Thus, scripts are highly likely to break when the document is parsed as XHTML.

Het case probleem heb ik al uitgelegd, en namespace-aware methoden heb je niet nodig als je geen XML dialecten met elkaar gaat mixen. Als je weet wat je doet gaat er helemaal niks stuk.

quote:

Scripts that use document.write() will not work in XHTML contexts. (You have to use DOM Core methods.)

Dat is toch niet zo'n punt?

quote:

Current UAs are, for text/html content, HTML4 user agents (at best) and certainly not XHTML user agents. Therefore if you send them XHTML you are sending them content in a language which is not native to them, and instead relying on their error handling. Since this is not defined in any specification, it may vary from one user agent to the other.

XHTML is ontworpen om te kunnen worden geinterpreteerd door browsers die HTML 4 aankunnen. Iedereen die de laatste jaren een beetje heeft opgelet weet dat er met de (X)HTML zelf niet zoveel misgaat bij het parsen door de browsers die serieus genomen kunnen worden.

quote:

XHTML documents that use the "/>" notation, as in "<link />" have very different semantics when parsed as HTML4. So if there was to be a fully compliant HTML4 UA, it would be quite correct to show ">" characters all over the page.

Ik kan niet meer voor de geest halen of die /> in volgend de HTML beschrijving in SGML volledig is toegestaan, maar weet dat dit in elk geval niet misgaat.

Hij schrijft nog veel meer, maar de meeste argumenten zijn een beetje bij elkaar gezocht. Het is een zwak betoog, en ik hecht er totaal geen waarde aan.