[IE6/7] UL onzichtbaar tot na selecteren

[Verwijderd]

Een erg raar probleem, waar ik geen verklaring voor heb. In Firefox en Opera werkt alles naar wens, maar in Internet Explorer (hoe verrassend) komt er iets onverwachts om de hoek kijken.

De unordered list is onzichtbaar, naar het lijkt, maar wordt wel zichtbaar zodra ik het deel van de pagina selecteer waar de list zou moeten staan. Je kunt dit in de praktijk zien op de ontwikkelpagina. De list hoort zichtbaar te zijn bovenaan de pagina, het lege vlak wat te zien is (of in Firefox of Opera is hij wel zichtbaar).

De code is als volgt (een deel er van althans):

Cascading Stylesheet:

#mainnav_header {
    padding: 10px;
}

    #mainnav_header ul {
        padding: 0;
        padding-bottom: 5px;
        margin: 0;
        
        border-bottom: #CCC 1px solid;
    }
    
    #mainnav_header li {
        display: inline;
        
        border: #CCC 1px solid;
        border-bottom: 0px;
        
        padding: 5px;
        padding-left: 0;
        padding-right: 0;
        
        margin: 0;
        margin-left: 5px;
        margin-right: 5px;
    }
    
        #mainnav_header li a {
            padding: 5px;                   
            padding-left: 25px;
            
            text-decoration: none;
        }
    
        #mainnav_header li.active {
            border-bottom: #FFF 1px solid;
        }

HTML:

<div id="mainnav_header">
    <ul>
        <li class="active"><a href="index.php">Dashboard</a></li>
        <li><a href="modules.php">Modules</a></li>
        <li><a href="configuration.php">Configuration</a></li>
    </ul>
</div>

Heeft iemand een idee waarom deze list onzichtbaar blijft (tot na het selecteren er van)?

[Pathogen]

Ik zie wel dat hij ook zichtbaar wordt na alt-tabben...

EDIT: en dat je borders in IE nogal moeite hebben. Probeer het eens zonder border definities in je CSS? Misschien houdt het verband.

En zet je header_wrapper eens op float:left?

[ Voor 66% gewijzigd door Pathogen op 05-03-2009 19:34 ]

[Verwijderd]

Thrackan schreef op donderdag 05 maart 2009 @ 19:29:
Ik zie wel dat hij ook zichtbaar wordt na alt-tabben...

Ik vind het echt idioot. Dit was me nog niet opgevallen...

EDIT: en dat je borders in IE nogal moeite hebben. Probeer het eens zonder border definities in je CSS? Misschien houdt het verband.

Ook na het weghalen van de borders (in de betreffende div) blijft het probleem bestaan.

En zet je header_wrapper eens op float:left?

Dan is hij inderdaad wel zichtbaar direct. Heb je hier ook een verklaring voor, een leermoment zeg maar?

IE heeft nu wel moeite met borders. Die gelijk maken in IE en Firefox, Opera etc. zal wel een crime worden.

[ Voor 23% gewijzigd door Verwijderd op 05-03-2009 19:38 ]

[Pathogen]

Tsja ik ben even wild in het rond aan het gokken op alles dat me opvalt in je CSS...
Er gebeuren in ieder geval rare dingen met je borders, hoewel dat niet de oorzaak van je probleem hoeft te zijn. Eens even verder graven.

Borders zijn ook een crime in multibrowser ontwikkeling. Ik hoop dat je nog haar hebt na dit avontuur
Vooral padding is vaak de boosdoener hiervan.

En nee, ik heb geen verklaring, ik zag alleen een lege wrapper. Probeer eens iets compleet nutteloos te definieren in die wrapper ipv je float en kijk of dat ook helpt?

[ Voor 42% gewijzigd door Pathogen op 05-03-2009 19:41 ]

[HendrikN]

Dit soort dingen gebeuren bij mij wel eens wanneer ik een element niet sluit.

Hmmz, probleem is dus al opgelost.

[ Voor 22% gewijzigd door HendrikN op 05-03-2009 19:43 ]

[Verwijderd]

Thrackan schreef op donderdag 05 maart 2009 @ 19:39:
Tsja ik ben even wild in het rond aan het gokken op alles dat me opvalt in je CSS...
Er gebeuren in ieder geval rare dingen met je borders, hoewel dat niet de oorzaak van je probleem hoeft te zijn. Eens even verder graven.

Ik denk niet de borders de oorzaak zijn. Ze blijven lastig inderdaad, maar ik vind het zo'n onverwacht gedrag, dat ik totaal niet kan plaatsen bij andere problemen (met borders) die ik ken.

Borders zijn een crime in multibrowser ontwikkeling. Ik hoop dat je nog haar hebt na dit avontuur
Vooral padding is vaak de boosdoener hiervan.

Padding zal inderdaad een probleem blijven tijdens het multibrowser-proof maken, maar dat durf ik wel aan.

En nee, ik heb geen verklaring, ik zag alleen een lege wrapper. Probeer eens iets compleet nutteloos te definieren in die wrapper ipv je float en kijk of dat ook helpt?

Helaas, het is echt nodig om 'm te laten floaten. Simpelweg iets anders definiëren is geen oplossing.

HendrikN, bedankt voor het meedenken! Elementen zijn goed afgesloten voor zover ik weet.

[ Voor 4% gewijzigd door Verwijderd op 05-03-2009 19:47 ]

[Pathogen]

Verwijderd schreef op donderdag 05 maart 2009 @ 19:46:
[...]
Ik denk niet de borders de oorzaak zijn. Ze blijven lastig inderdaad, maar ik vind het zo'n onverwacht gedrag, dat ik totaal niet kan plaatsen bij andere problemen (met borders) die ik ken.


[...]
Padding zal inderdaad een probleem blijven tijdens het multibrowser-proof maken, maar dat durf ik wel aan.


[...]
Helaas, het is echt nodig om 'm te laten floaten. Simpelweg iets anders definiëren is geen oplossing.

HendrikN, bedankt voor het meedenken! Elementen zijn goed afgesloten voor zover ik weet.

Het enige dat ik dan kan adviseren is om altijd de parent divs een float te geven, tenzij je het echt niet nodig hebt. Niet iedere browser is slim genoeg om daar doorheen te kijken zo te merken

Is overigens alweer een tijd geleden dat ik met webspul aan de slag ben geweest, valt me mee dat ik er nog uit kwam

[Verwijderd]

Ik merk nu ook dat de border(-top) van mijn footer, in IE7 dwars door alles heen staat. Begin nu steeds meer te denken dat het misschien toch een element is wat niet afgesloten is.

Nu eerst de padding en margin van de list nog maar eens nalopen. Ik heb het idee dat IE de padding iets anders implementeert en daarom mijn list om zeep helpt. Thanks voor alle info tot nu toe!

EDIT: Ook zonder de float in de parent div werkt het nu. Het heeft me wel op de goede weg geholpen! De enige problemen die ik nu heb zijn wat padding-zaken in de tabjes. De echte problemen zijn opgelost!

Iemand een tip over de padding-problemen zoals ze nu zichtbaar zijn op de de ontwikkel pagina? Hoe geef ik die tabjes in alle browsers dezelfde padding en dus hetzelfde uiterlijk?

[ Voor 36% gewijzigd door Verwijderd op 05-03-2009 20:16 ]

[m038]

Ah ik zie dat je hoofdprobleem al is opgelost, mooi.

Ik begin altijd met een doctype toe te voegen aan het document.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

Of bijvoorbeeld

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">

Dan los je het probleem op dat IE de padding anders behandelt dan in Firefox. Dat scheelt op dat gebied al een hoop gedoe.

[Verwijderd]

Bedankt voor de tip van de doctype's, dat had ik inderdaad nog niet gedaan. Bij deze XHTML 1.1 toegevoegd.

Het probleem blijft echter hetzelfde, om de complete tabjes klikbaar te maken geef ik de link (a-element) de padding van die ik de vorm van het tabje wil geven.

Cascading Stylesheet:

#mainnav_header li a {                  
    padding: 5px;
    padding-left: 25px;
    
    text-decoration: none;
}

De plaats waar de gebruiker op kan klikken wordt nu goed, in Firefox en consorten heeft het tabje niet de juiste vorm. Als ik dit compenseer door de li (het tabje zelf dus) ook de juiste padding te geven, is hij helemaal goed in Firefox, maar in Internet Explorer krijgt het tabje de dubbele waarde en wordt eens zo groot.

[robdejongNL]

Verwijderd schreef op donderdag 05 maart 2009 @ 20:30:
Bedankt voor de tip van de doctype's, dat had ik inderdaad nog niet gedaan. Bij deze XHTML 1.1 toegevoegd.

Het probleem blijft echter hetzelfde, om de complete tabjes klikbaar te maken geef ik de link (a-element) de padding van die ik de vorm van het tabje wil geven.

Cascading Stylesheet:

#mainnav_header li a {                  
    padding: 5px;
    padding-left: 25px;
    
    text-decoration: none;
}

De plaats waar de gebruiker op kan klikken wordt nu goed, in Firefox en consorten heeft het tabje niet de juiste vorm. Als ik dit compenseer door de li (het tabje zelf dus) ook de juiste padding te geven, is hij helemaal goed in Firefox, maar in Internet Explorer krijgt het tabje de dubbele waarde en wordt eens zo groot.

Hier gebruik ik normaliter

code:

display: block;

voor (op het A element welteverstaan).

je zou ook speciaal voor IE een stylesheet kunnen maken en werken met negatieve margin's en padding's maar dat is meestal niet zo'n succes.

[ Voor 22% gewijzigd door robdejongNL op 05-03-2009 20:36 ]

[Verwijderd]

Robjuh schreef op donderdag 05 maart 2009 @ 20:35:
Hier gebruik ik normaliter

code:

display: block;

voor (op het A element welteverstaan).

je zou ook speciaal voor IE een stylesheet kunnen maken en werken met negatieve margin's en padding's maar dat is meestal niet zo'n succes.

Een display: block; gaat niet werken, omdat de li's worden weergegeven met een display: inline;. Wanneer ik nu die twee combineer, zal de tweede niet meer werken en worden de li's op een vreemde manier onder elkaar getoond. Lijkt me wel een beetje raar, want ik pas die block toe op het a-element...

Een aparte stylesheet voor Internet Explorer is niet wenselijk in deze situatie. Het is vaak praktisch, maar strookt tegen mijn manier van denken en past totaal niet in dit project.

[ Voor 12% gewijzigd door Verwijderd op 05-03-2009 20:42 ]

[robdejongNL]

code:

display: inline-block;

werkt zowel op List-Item als a-element.

[Verwijderd]

Robjuh schreef op donderdag 05 maart 2009 @ 21:04:

code:

display: inline-block;

werkt zowel op List-Item als a-element.

Dus ik zou hier mee moeten combineren tussen de li en het a-element. Kan geen goede combinatie vinden!

De oplossing met binnen de li de definitie op display: inline; en geen enkele definitie van display binnen het a-element ziet er nog het beste uit. Hij werkt dan het beste in Firefox (qua ruimte om op te klikken, maar wordt het best getoond in Internet Explorer (qua uiterlijk van het tabje).

De definitie display: inline-block; zorgt er voor dat de blokken (de li's dus) op elkaar gestapeld worden, ongeacht de optie van de display-definitie binnen het a-element. Andersom zorgt het ook niet voor gunstige opties.

[Pkunk]

Bij rare problemen met IE moet ik altijd meteen aan haslayout denken.

[Daan]

Je moet de li's floaten en dan de li a's op display:block zetten.

[Verwijderd]

Daan schreef op donderdag 05 maart 2009 @ 22:05:
Je moet de li's floaten en dan de li a's op display:block zetten.

Held!

Is dit de enige oplossing, of moet het ook mogelijk zijn met de juiste waardes en dan met een display: inline?

[Pkunk]

Je zou hier eens een kijkje kunnen nemen, staat vast wel wat tussen:
http://css.maxdesign.com.au/listamatic/

[crisp]

Verwijderd schreef op donderdag 05 maart 2009 @ 20:30:
Bedankt voor de tip van de doctype's, dat had ik inderdaad nog niet gedaan. Bij deze XHTML 1.1 toegevoegd.

En waarom specifiek die doctype? Als je daar geen speciale reden voor hebt zou ik het gewoon bij een HTML4 doctype houden want XHTML is not for beginners

[Verwijderd]

crisp schreef op donderdag 05 maart 2009 @ 22:44:
En waarom specifiek die doctype? Als je daar geen speciale reden voor hebt zou ik het gewoon bij een HTML4 doctype houden want XHTML is not for beginners

Dat ik hier met een vraag kom, wil niet meteen zeggen dat ik een beginner ben.

Ik ben al jaren bezig met (X)HTML/CSS en PHP/MySQL. De reden waarom ik voor XHTML boven HTML koos en daarbij laat ik de keuze voor XHTML 1.1 specifiek nog even buiten beschouwing, is omdat ik erg goed voor het uiterlijk van mijn code ben. Als ik (om welke reden dan ook) HTML gebruik, schrijf ik altijd via de schrijfwijze van XHTML, denk hierbij aan bijvoorbeeld enkele tags afsluiten met / (<br />) bijvoorbeeld.

Maar dat is nog geen antwoord op de vraag; waarom XHTML boven HTML? Ik denk dat ik daar geen antwoord op heb. XHTML is (nog) in geen enkel opzicht 'beter' dan HTML door slechte XML ondersteuning van (vooral) Internet Explorer. Het is vooral een combinatie van het feit wat het lekkerst voelt en wat je jezelf aanleert.

Ik zou aan jou de vraag willen stellen; waarom moet ik geen XHTML gebruiken (buiten het artikel dat je linkt)?

[crisp]

Verwijderd schreef op donderdag 05 maart 2009 @ 22:59:
[...]
Ik zou aan jou de vraag willen stellen; waarom moet ik geen XHTML gebruiken (buiten het artikel dat je linkt)?

Die vraag heb ik al menigmaal beantwoord hier in het forum

Maar ik ben niet te beroerd om daar hier verder op in te gaan als je wilt hoor. Echter zou ik dan wel graag eerst een wedervraag willen stellen: waarvoor dient een DTD volgens jou? (en als opvolg vraag: wanneer is een document XHTML?)

[Verwijderd]

crisp schreef op donderdag 05 maart 2009 @ 23:11:
Echter zou ik dan wel graag eerst een wedervraag willen stellen: waarvoor dient een DTD volgens jou? (en als opvolg vraag: wanneer is een document XHTML?)

Natuurlijk, ik probeer het in enigsinds begrijpelijke taal uit te leggen, zonder technisch te worden;

1. Een DTD is om aan te geven van welke standaarden uitgegaan wordt in het document als informatie richting de browser, die aan de hand van het DTD bepalen hoe het document te behandelen.
2. Een document is XHTML wanneer het DTD dit aangeeft én het document aan alle voorwaarden en regels van die standaard voldoet.

Je kunt het zo uitgebreid lastig uitleggen als je wilt, maar hier komt het op neer.

[crisp]

Verwijderd schreef op donderdag 05 maart 2009 @ 23:19:
[...]
Natuurlijk, ik probeer het in enigsinds begrijpelijke taal uit te leggen, zonder technisch te worden;

1. Een DTD is om aan te geven van welke standaarden uitgegaan wordt in het document als informatie richting de browser, die aan de hand van het DTD bepalen hoe het document te behandelen.
2. Een document is XHTML wanneer het DTD dit aangeeft én het document aan alle voorwaarden en regels van die standaard voldoet.

Je kunt het zo uitgebreid lastig uitleggen als je wilt, maar hier komt het op neer.

Not quite my dear friend:

@1 - In real life is een DTD een waardeloos reliek, het is echter een noodzakelijk kwaad om een dergelijke talisman toe te voegen aan een document dat tot doel heeft geconsumeert te worden door een browser omdat deze anders op een non-standaard manier (aka quirksmode, aka old-IE compatible mode) verwerkt zal worden

@2 - It's all in the eyes of the beholder natuurlijk. Aangezien de voornaamste consumer van (X)HTML documenten meestal een browser is zou je ook kunnen stellen dat een document is zoals het gezien wordt door de consuming agent (daar wordt het immers ook meestal voor geschreven), en als die een html mimetype ziet zal het hem aan z'n k*nt roesten wat de DTD zegt en het gewoon als html verwerken, waarbij het eigenlijk maar goed is dat browsers nooit HTML(<=4) tot op de letter (als SGML-applicatie) hebben geimplementeerd, anders zou de XML-syntax voor vervelende bij-effecten zorgen

[Verwijderd]

crisp schreef op donderdag 05 maart 2009 @ 23:38:
@1 - In real life is een DTD een waardeloos reliek, het is echter een noodzakelijk kwaad om een dergelijke talisman toe te voegen aan een document dat tot doel heeft geconsumeert te worden door een browser omdat deze anders op een non-standaard manier (aka quirksmode, aka old-IE compatible mode) verwerkt zal worden

Maar zegt dit niet meer iets over de browsers van 'tegenwoordig' en niet iets over de DTD zelf?

@2 - It's all in the eyes of the beholder natuurlijk. Aangezien de voornaamste consumer van (X)HTML documenten meestal een browser is zou je ook kunnen stellen dat een document is zoals het gezien wordt door de consuming agent (daar wordt het immers ook meestal voor geschreven), en als die een html mimetype ziet zal het hem aan z'n k*nt roesten wat de DTD zegt en het gewoon als html verwerken, waarbij het eigenlijk maar goed is dat browsers nooit HTML(<=4) tot op de letter (als SGML-applicatie) hebben geimplementeerd, anders zou de XML-syntax voor vervelende bij-effecten zorgen

Nogmaals, dit zegt ook meer over browsers, dan over DTD's op zich. De browsers zijn wat mij betreft de kwaaie pier in dit verhaal en daarom maakt het geen hol uit wat voor DTD je boven je documentje zet.

Denk je dat met HTML 5 of toekomstige versies van XHTML de browsers gaan dwingen om hier verandering in gaan brengen en rekening te houden met de DTD? En wil je mijn andere vraag nog beantwoorden?

[crisp]

Verwijderd schreef op vrijdag 06 maart 2009 @ 00:40:
[...]
Maar zegt dit niet meer iets over de browsers van 'tegenwoordig' en niet iets over de DTD zelf?

Ja en nee DTD's zijn van oorsprong een validatie-mechanisme en zijn een SGML erfenis. Een consuming agent is echter geen validator, noch is het interessant om te weten volgens welk schema een document geschreven is. Van een consuming agent wordt verwacht dat hij alles kan verwerken (inclusief error-handling of correctie/recovery) en bij een formaat dat tracht altijd backwards-compatible te zijn is een parser gebaseerd op de laatste versie dus altijd afdoende - zodoende boeit een versienummer ook niet voor browsers - hooguit voor validators, maar ook dat is eigenlijk maar een wassen neus want je wilt dat ook toekomstige browsers je documenten kunnen verwerken, en browser implementeren niet per HTML versie een seperate parser.

[...]
Nogmaals, dit zegt ook meer over browsers, dan over DTD's op zich. De browsers zijn wat mij betreft de kwaaie pier in dit verhaal en daarom maakt het geen hol uit wat voor DTD je boven je documentje zet.

Browsers zijn geen kwade pier maar juist praktisch: een HTML5 parser is prima in staat HTML3 documenten te verwerken, ook zonder te weten dat het oorspronkelijk een HTML3 document was. Andersom is wellicht minder waar, maar wie gebruikt er nu nog een HTML3 parser

Dus versioning is voor browsers niet nodig. De keuze van de parser (een HTML of een XML parser) wordt verder bepaald door mimetype, en daarnaast is er nog quirksmode (legacy). Daarom is in HTML5 de doctype ook teruggebracht tot:

code:

<!doctype html>

en is een DTD voor XHTML5 (de XML serialisatie van HTML5) al helemaal niet meer noodzakelijk

Denk je dat met HTML 5 of toekomstige versies van XHTML de browsers gaan dwingen om hier verandering in gaan brengen en rekening te houden met de DTD?

Zie boven: nee dus. En XHTML2 is weer een heel ander verhaal; dat is namelijk niet backwards compatible met XHTML1.x en valt daardoor eigenlijk volledig buiten de boot (en geen enkele browservendor is voornemens het te implementeren).

En wil je mijn andere vraag nog beantwoorden?

Sure, maar ik probeer het kort te houden

In mijn optiek moet je de keuze voor een bepaalde DTD ook altijd kunnen beargumenteren. XHTML wordt vaak nog gezien als 'de opvolger' van HTML terwijl het primair eigenlijk niet meer of minder is dan de XML-serialisatie van HTML met als doel om het te kunnen gebruiken in combinatie met andere XML-applicaties zoals MathML en SVG. XHTML1.1 is dan weer een modularisatie van XHTML1.0 maar tbh maakt dat het juist weer extra complex met weinig toegevoegde waarde en schiet het daarmee z'n doel juist extra voorbij.

XHTML op het web is natuurlijk een treffend voorbeeld van hoe XHTML eigenlijk gefaald heeft: 99% van alle documenten met een XHTML DTD worden gewoon als text/html verstuurd en de meerderheid daarvan is niet wellformed, valideerd niet en/of zou indien geserveerd als application/xhtml+xml niet werken zoals bedoelt. Zowel parsers van bepaalde XML applicaties (RSS is een goed voorbeeld) zijn steeds meer lenient (HTML-like) geworden met betrekking tot error-handling (draconische error-handling hoort imo niet thuis in een opmaaktaal) als specificaties zelf die steeds minder strict een XML-mimetype voorschrijven (XHTML mimetype was voor XHTML1.1 vroeger een MUST, nu nog maar een SHOULD).

De vraag is dan nog, vooropgesteld dat je je documenten gewoon als text/html serveert en dus geen gebruik maakt van de XML-eigenschappen van XHTML, waarom je dan toch nog een XHTML DTD zou prefereren? In de praktijk blijkt dat toch uit te komen op een bepaalde syntax-voorkeur (wat uiteraard geheel subjectief is - en dingen als <script /> zijn dan nog steeds uit den boze dus uitzonderingen hou je toch). Ik bespaar me liever het typwerk en de loze bytes over de lijn

Het gevaar zit 'm er in dat mensen toch denken echt te weten wat XHTML is, maar als die kennis niet verder gaat dan de syntactische verschillen dan heb je het gewoon niet goed begrepen. Als morgen alle browsers documenten met een XHTML doctype echt als XHTML zouden behandelen dan is het internet grotendeels 'stuk'

Gelukkig lost HTML5 dat straks dus wel voor een deel op: nutteloze slashes worden daar door de parser gewoon genegeerd en ook niet als warning aangemerkt en de DTD is teruggebracht tot de essentie: een talisman die tegen een useragent zegt: 'ik ben een HTML document en ik wil op een standards-compliant manier gerendered worden'. Het embedden van MathML en SVG wordt daarin ook mogelijk gemaakt in de HTML serialisatie, en daarnaast biedt het ook de mogelijkheid tot een echte XML-serialisatie (XHTML5) - voor als je dat echt nodig hebt.

[Verwijderd]

crisp schreef op vrijdag 06 maart 2009 @ 01:49:
Het embedden van MathML en SVG wordt daarin ook mogelijk gemaakt in de HTML serialisatie, en daarnaast biedt het ook de mogelijkheid tot een echte XML-serialisatie (XHTML5) - voor als je dat echt nodig hebt.

Zal je zien dat een hele hoop mensen—om het op de XHTML5-manier te doen—de doctype weg zullen laten, closing short-tags gebruiken, en het dan toch als text/html gaan verzenden, voor de IE-compatibiliteit. Wat moet een browser dan doen? Quirks mode? Als alle browsers dat als quirks mode renderen zal het misschien wel gauw afgelopen zijn met dat "kijk mij trendy xhtml doen" gedoe.

[Verwijderd]

Even alles kort samenvatten; het is vooral onwetendheid wat de klok slaat voor wat betreft dit onderwerp. Ik merk dat crisp er duidelijk wat meer kaas van heeft gegeten dan menig figuur (die zich ontwikkelaar noemt) en de theorie goed door heeft. Tof dat je het even (helemaal) uit wil leggen!

Mijn keuze voor XHTML is vooral vanuit syntactisch oogpunt gemaakt, maar ik weet nu ook dat het voor documenten met een andere standaard vaak ook niet uit maakt. Ik vestig nu mijn hoop op de toekomst, misschien komt er ooit nog één goede standaard, die een einde maakt aan deze keuzes en ons ook weer een stukje helpt met het eenvoudiger maken van cross-browser compatibele websites.

[Verwijderd]

Verwijderd schreef op vrijdag 06 maart 2009 @ 02:12:

kijk mij trendy xhtml doen

Juist omdat het zo bekeken werd heeft het helemaal geen prioriteit gekregen en is het gefaald. Elke keer als Microsoft de kans had het goed te doen, hebben ze dat niet gedaan. De mensen die daarmee bezig waren interesseerde het kennelijk gewoon niet.

De browsers hadden gewoon alles stuk moeten maken en een instelling als "try to parse and render anyway" moeten implementeren om dit te omzeilen. Dat is simpel te maken, en toch heeft niemand het aangedurfd.

Eigenlijk ligt de oorzaak ook grotendeels bij bijvoorbeeld PHP. Er is zoveel aan scripts te vinden dat HTML rotzooi produceert, dat krijg je gewoon niet meer goed zonder stricte parsers te gebruiken.

Het zou mensen die "weten wat ze doen" afdwingen het ook op de juiste manier te doen. Maar juist omdat die mogelijkheid er niet is, wordt slordigheid niet afgestraft. Eigenlijk ben ik al jaren geleden afgehaakt. Ik heb er geen zin meer in me hier te druk om te maken. Het internet is de komende jaren nog altijd het domein van prutsers. Iedereen wil zijn crap op internet hebben, dus crap is wat er op internet komt. Een simpele kwestie van vraag en aanbod.

HTML5 zal net zo hard gaan falen als elk ander initiatief.

[HendrikN]

Verwijderd schreef op zaterdag 07 maart 2009 @ 17:33:
[...]

Eigenlijk ligt de oorzaak ook grotendeels bij bijvoorbeeld PHP. Er is zoveel aan scripts te vinden dat HTML rotzooi produceert, dat krijg je gewoon niet meer goed zonder stricte parsers te gebruiken.

Dat heeft er echt helemaal niks mee te maken, je kan met ASP of JSP dezelfde bagger produceren, het gaat er nog altijd om wie er letters aan elkaar knoopt op het toetsenbord.

[Verwijderd]

HendrikN schreef op zaterdag 07 maart 2009 @ 18:07:

Dat heeft er echt helemaal niks mee te maken, je kan met ASP of JSP dezelfde bagger produceren, het gaat er nog altijd om wie er letters aan elkaar knoopt op het toetsenbord.

Juist. Maar dat zeg ik ook

[crisp]

Verwijderd schreef op zaterdag 07 maart 2009 @ 17:33:
[...]

Juist omdat het zo bekeken werd heeft het helemaal geen prioriteit gekregen en is het gefaald. Elke keer als Microsoft de kans had het goed te doen, hebben ze dat niet gedaan. De mensen die daarmee bezig waren interesseerde het kennelijk gewoon niet.

De browsers hadden gewoon alles stuk moeten maken en een instelling als "try to parse and render anyway" moeten implementeren om dit te omzeilen. Dat is simpel te maken, en toch heeft niemand het aangedurfd.

Logisch; als je gebruikers gaat opzadelen met dergelijke nagging en een andere browser doet het (in de ogen van de gebruikers) wel 'goed' dan plaats je jezelf als browservendor uit de markt; logisch dus dat niemand het aandurft. Sterker nog, je ziet het tegenovergestelde gebeuren: RSS is daar een goed voorbeeld van want ook dat heeft als XML-applicatie jammerlijk gefaald op het web - toen bleek dat veel feeds mallformed waren of niet met het juiste mimetype verstuurd werden (text/plain is nog steeds commonplace) zijn steeds meer feed-applicatievendors error-recovery gaan inbouwen, en in feite is dat een win-win situatie (je hoeft niet duizenden feed-publishers te 'evangelizen' en gebruikers zullen jouw applicatie prefereren omdat het met meer feeds overweg kan).

Eigenlijk ligt de oorzaak ook grotendeels bij bijvoorbeeld PHP. Er is zoveel aan scripts te vinden dat HTML rotzooi produceert, dat krijg je gewoon niet meer goed zonder stricte parsers te gebruiken.

Niet alleen PHP natuurlijk maar zo'n beetje alles wat HTML kan produceren en dat op een 'tagsoup' manier doet, maar het heeft er wel voor gezorgt dat het web 'open' is voor zo'n beetje iedereen die ueberhaupt een editor kan openen of een applicatie kan opstarten. Een web dat alleen toegankelijk is voor programmeurs is ook maar saai...

Het zou mensen die "weten wat ze doen" afdwingen het ook op de juiste manier te doen. Maar juist omdat die mogelijkheid er niet is, wordt slordigheid niet afgestraft. Eigenlijk ben ik al jaren geleden afgehaakt. Ik heb er geen zin meer in me hier te druk om te maken. Het internet is de komende jaren nog altijd het domein van prutsers. Iedereen wil zijn crap op internet hebben, dus crap is wat er op internet komt. Een simpele kwestie van vraag en aanbod.

Afdwingen als in je eigen puristische visie opdringen aan de massa? Tsja, dat gaat inderdaad niet werken op een medium dat je juist open wilt houden voor zoveel mogelijk deelnemers. Dan maar crap met daarnaast een hoekje voor de mensen die wel weten hoe het moet. IRL heb je in alle facetten prutsers, amateurs en professionals; waarom zou je op het internet de eerste (en misschien ook de tweede) groep willen uitsluiten?

HTML5 zal net zo hard gaan falen als elk ander initiatief.

Dat denk ik niet. HTML5 onderschrijft dat HTML een toegankelijke opmaaktaal moet zijn en blijven, maar dat de meeste problemen met betrekking tot error-recovery voortkomen uit het feit dat dergelijke regels nooit eerder zijn gespecificeerd. Uniforme regels met betrekking tot dat laatste leidt tot interoperabiliteit op een groot vlak en de commitment van de grote browservendors zal enkel leiden tot een betere toegankelijkheid.