huidige status wysiwyg ondersteuning

[Verwijderd]

Tegenwoordig werkt de contentEditable zowel in IE als in Mozilla (of beter: Gecko-browsers). Ik vraag mij af: gebruiken ze hetzelfde model, dus hebben de heren bij Mozilla de MS implementatie en API nagebouwd, of zijn het twee compleet verschillende oplossingen?

[faabman]

kijk daarvoor maar eens op onderstaande URL

http://www.mozilla.org/editor/midas-spec.html

[Verwijderd]

Ok, dus zo te zien hebben ze dezelfde werking als het component van IE. Wat me opvalt is dat de documentatie bij Mozilla wel een stuk beter is, want wat ik op msdn vond liet nog veel te wensen over.

Maar die van Mozilla genereert betere html dan die van IE zo te zien.

[faabman]

Verwijderd schreef op maandag 20 december 2004 @ 00:29:
Ok, dus zo te zien hebben ze dezelfde werking als het component van IE. Wat me opvalt is dat de documentatie bij Mozilla wel een stuk beter is, want wat ik op msdn vond liet nog veel te wensen over.

hoezo is de documentatie van mozilla veel beter?? Download dan maar eens de volledige SDK van MS, dan zul je zien dat die vele malen uitgebreider is als hetgeen door mozilla wordt geboden...

oww, en mozilla heeft op een aantal (imo essentiele punten) een heel andere werking als I.E., maar, daarover kun je op de volgende pagina genoeg informatie vinden...

http://www.mozilla.org/editor/ie2midas.html

[bgever]

Bedenk wel dat die WYSIWYG edit componenten die jij beschrijft geen XHTML ondersteunen. Als je nog gewoon het HTML werkt is dat natuurlijk geen probleem, maar als je een WYSIWYG editor voor XHTML zoekt ben je wel even bezig. Je kunt er natuurlijk wel filters overheen gooien die de HTML proberen op te lappen naar XHTML, maar dit gaat in veel gevallen niet mooi, en is te betwijfelen wat dan nog het voordeel van het XHTML is...

Toch is er een heel leuke WYSIWYG XHTML Editor gemaakt die sinds kort werkt in IE én Mozilla (met het nieuwe component API). Deze editor maakt mooie XHTML code, en heeft daarbij een mooie interface. De lite versie is freeware, dus zie dit niet als spam.

[Fuzzillogic]

Voor m'n eigen CMSje gebruik ik TinyMCE. Lekker makkelijk & compleet. Werkt prima in Gecko en IE zonder gedoe.

[Woudloper]

oikoyama schreef op maandag 20 december 2004 @ 10:59:
Toch is er een heel leuke WYSIWYG XHTML Editor gemaakt die sinds kort werkt in IE én Mozilla (met het nieuwe component API). Deze editor maakt mooie XHTML code, en heeft daarbij een mooie interface. De lite versie is freeware, dus zie dit niet als spam.

Er bestaan hiervoor ook de nodige open source varianten. Bijvoorbeeld: FCK Editor. Verder staan er hier op GoT de nodige topics over het omzetten van wysiwyg html naar XHTML...

[crisp]

oikoyama schreef op maandag 20 december 2004 @ 10:59:
Bedenk wel dat die WYSIWYG edit componenten die jij beschrijft geen XHTML ondersteunen. Als je nog gewoon het HTML werkt is dat natuurlijk geen probleem, maar als je een WYSIWYG editor voor XHTML zoekt ben je wel even bezig. Je kunt er natuurlijk wel filters overheen gooien die de HTML proberen op te lappen naar XHTML, maar dit gaat in veel gevallen niet mooi, en is te betwijfelen wat dan nog het voordeel van het XHTML is...
[...]

Wat is het voordeel van XHTML dan boven HTML voor normale websites?

[Thijsmans]

Wat is een normale site?

XHtml is toch een soort 'opstapje' tussen Html en XML, zodat de migratie tussen deze twee makkelijker wordt? Met andere woorden: als je niet van plan bent ooit de site te veranderen in XML, heeft Xhtml ook geen zin. Toch?

[crisp]

Nette HTML is met een paar simpele ingrepen ook well-formed te maken, dus dat is het probleem niet. Verder is er syntactisch weinig verschil tussen HTML en XHTML.
Voor nette en semantisch correcte code heb je geen XHTML nodig. Sterker nog: XHTML zonder xml+xhtml mimetype is geen XHTML maar gewoon tagsoup en wordt door browsers ook zo behandeld, en zolang je text/html als mimetype blijft gebruiken kan je niet eens gebruik maken van de voordelen die XHTML biedt en hou je dus alleen de nadelen over.

Maar goed, ik was eigenlijk alleen benieuwd naar de argumentatie van oikoyama

Uiteraard is een XHTML-compliant CMS wel degelijk een voorwaarde als je daar ooit iets mee wilt gaan doen. Een beetje kip-ei verhaal natuurlijk, maar een CMS dat nette HTML kan afleveren is natuurlijk eenvoudig XHTML-compliant te maken

[ Voor 18% gewijzigd door crisp op 20-12-2004 12:03 ]

[Verwijderd]

Zoals Crisp al aangegeven heeft, heeft XHTML geen enkel voordeel boven HTML. Het gebruik van XStandard is niet nodig. Ik vind het bovendien jammer dat XStandard een plugin is. De verschillen tussen Gecko en IE zijn behoorlijk groot.
Het grootste voordeel van Gecko vind ik de goede implementatie van Range object. De implementatie van IE laat nogal te wensen over; bewerkingen op de range en/of selection gaat moeilijk en sommige dingen zijn gewoon onmogelijk.
De verschillen tussen Gecko en IE zijn behoorlijk groot, maar niet zo groot dat het onmogelijk is een editor te schrijven die in beide browsers werkt. Er zijn genoeg editors te vinden die in Gecko en IE (redelijk) werken. Als je een goede API schrijft die achter de schermen de browser verschillen voor z'n rekening neemt, dan is het eigenlijk zeer eenvoudig een editor te schrijven.

[ Voor 13% gewijzigd door Verwijderd op 20-12-2004 12:20 ]

[Clay]

faabman
hoezo is de documentatie van mozilla veel beter?? Download dan maar eens de volledige SDK van MS, dan zul je zien dat die vele malen uitgebreider is als hetgeen door mozilla wordt geboden...

Zoals Quist al aangeeft kan je met het range object (en trouwens ook de rest van de editable implementatie) voor moz toch wel een stuk meer dan in IE. Zo is het in IE niet mogelijk om vast te stellen dat het beginpunt van je selectie uit een ander element komt dan het eindpunt van je selectie, om maar iets te noemen...

Verder is het inderdaad niet makkelijk om die krengen goed werkend te krijgen. Pasten uit word, foute nesting, xhtml of niet 't is allemaal wel te maken, maar het kost wat moeite.

edit:
ranten!

Het probleem van wysiwyg editors is ook dat html daar helemaal niet voor bedoeld is natuurlijk. Markup en presentatie dienen gescheiden te worden; een wysiwyg editor die zich daar aan houdt mag dus eigenlijk geen fonts of kleuren aanbieden; hoogstens wat classes en markup types (paragraph, lists ...), maar dat spreekt het hele wysiwyg principe weer tegen

[ Voor 22% gewijzigd door Clay op 20-12-2004 12:48 ]

[X-Lars]

Prammenhanger schreef op maandag 20 december 2004 @ 11:48:
Wat is een normale site?

XHtml is toch een soort 'opstapje' tussen Html en XML, zodat de migratie tussen deze twee makkelijker wordt? Met andere woorden: als je niet van plan bent ooit de site te veranderen in XML, heeft Xhtml ook geen zin. Toch?

offtopic:
Er wordt weleens verondersteld dat XHTML de tussenstap is van HTML naar XML, maar dat lijkt me niet juist. XHTML heeft meer ten doel om de krachten van HTML en XML te bundelen.

[bgever]

crisp schreef op maandag 20 december 2004 @ 12:01:
Maar goed, ik was eigenlijk alleen benieuwd naar de argumentatie van oikoyama

Allereerst moet je wel begrijpen dat ik niet zeg dat je XHTML moet gebruiken. Ik zeg alleen dat als je XHTML gebruikt, het wat lastiger wordt om een goede editor te vinden. De engines die achter die editors werken zijn namelijk op HTML gebaseerd, (zoals het MSHTML component in IE), en daarom kunnen ze niet altijd goed als XHTML editor functioneren. Ze maken dan gebruik van oplapmiddelen die niet altijd willen werken...

Ik wil eigenlijk niet weer op die XHTML vs HTML discussie in gaan, maar gezien dat toch al gebeurt... Ik heb voor XHTML gekozen, omdat ik het logischer vind. Data gescheiden van opmaak, logischere tags, geen onzin (<center> tag bijv.) er in.
Tuurlijk, het is mogelijk om met HTML symantische documenten te maken, maar is HTML daar initieel voor bedoeld? Nee, maar XHTML wel. Dat is in XHTML met CSS min of meer "verplicht". Daarom gebruik ik dat ook.
En dat mimetype. Altijd grappig die discussie. Yep, het ís geen XHTML, maar een browser geeft het wel weer, en kan er mee overweg. Sterker nog, het is zo ontworpen dat het nog werkt met text/html. Maar het is mijn doel dat de browser het document als XML te behandelt, dus voor mij is er geen probleem. Dat ik dan niet de XML functie van XHTML gebruik (in browsers), is mijn keuze. Maar het is ook in feite HTML + XML, dus dat mag ik ook.
Ik kan wel een XHTML document laten inlezen door een XML parser, en het dan wel gebruiken als XML. Dat vind ik er prettig aan. En daarom gebruik ik het ook. Ik kan mijn sites in de toekomst op die manier gebruiken.
Met andere woorden: ik laat browsers mijn webpagina's als HTML inlezen, en houd data van opmaak gescheiden. En XML parsers laat ik mijn webpagina's als XML inlezen. De voordelen van beide werelden!

[X-Lars]

Wat je bedoelt met "Dat is in XHTML met CSS min of meer "verplicht"" is in HTML 4(.01) Strict ook zo. En over dat MIME type etc.: zo makkelijk kom je er niet vanaf

[bgever]

X-Lars schreef op maandag 20 december 2004 @ 13:07:
Wat je bedoelt met "Dat is in XHTML met CSS min of meer "verplicht"" is in HTML 4(.01) Strict ook zo. En over dat MIME type etc.: zo makkelijk kom je er niet vanaf

In HTML bestaat de FONT tag. In XHTML bestaat deze niet, en moet via CSS. Dat bedoel ik dus (als voorbeeld) met verplicht. In XHTML is opmaak in de code minder mogelijk. Minder, omdat bijv. <small> natuurlijk ook als opmaak kan worden gezien... Maar als je dat element symantisch gebruikt ipv opmaak, is dat argument ook ondoorgrond...

En verder voldoen mijn XHTML documenten allemaal aan de eisen in dat artikel. Gewoon geen CSS en JS in je doc zetten, maar externe bestanden gebruiken, net zoals het aangeraden wordt. Enkel dat je enkele tags moet sluiten (<br />) daar kan ik niets aan doen. Maar is dit nu dé reden om het niet meer te gebruiken? Het werkt gewoon goed... Ik vind de XML voordelen wegen bovenop de nadelen.

(Yes, I said _most_ authors. If you are one of the few authors who understands how to avoid the issues raised in this document and does validate all their markup, then this document probably does not apply to you -- see Appendix B.)

Ik reken me dan ook tot deze auteurs...

[X-Lars]

oikoyama schreef op maandag 20 december 2004 @ 13:35:
[...]
In HTML bestaat de FONT tag. [...]

Daarom zeg ik ook HTML 4.01 Strict

[pietje63]

Om nog maar een alternatief te tonen: htmlarea: http://www.dynarch.com/projects/htmlarea/

Levert onder mozilla nette html achter, onder ie wat minder. Heb zelf een versie wat uitgebreid die de html opschoon (tabellen netjes onder elkaar enzo) en wat extra functionaliteit (uploaden images, bestanden, en dit alles aangepast aan mijn eigen CMS).

Het werkt allemaal op zich prima, maar het staat nog een beetje in de kinderschoenen. In mijn geval vind ik nog het grootste probleem dat het script eigenlijk een textbox vervangt door al dit moois, als er echter een textbox staat in het stuk dat hij moet vervangen gaat het verkeerd... Verder zitten er nog meer van dat soort haken en ogen aan. Soms problemen met dat de output opeens onderstreept is ofzo, en niet meer te veranderen. Niet helemaal fool-proof maar voor niet complexe pagina's prima.

Ik verwacht dan ook dat dit soort ritch-text-editers binnenkort standaard (of als optie) in verschillende fora zitten..

(hotmail was trouwens een van de eerste sites waarbij ik dit gezien heb)

[ Voor 5% gewijzigd door pietje63 op 20-12-2004 13:50 ]

[Verwijderd]

pietje63 schreef op maandag 20 december 2004 @ 13:49:
Om nog maar een alternatief te tonen: htmlarea: http://www.dynarch.com/projects/htmlarea/

Als ik van twee editors wel echt de rillingen krijg dan zijn het HTMLArea en FCKEditor. Allebei gratis, maar geen reele optie wanneer het gaat om business oplossingen. Ze zijn beiden erg buggy...
In de wysiwyg editor branche is het helaas nog zo dat kwaliteit geld kost. Er is een aantal goede editors, maar die kosten geld.

Ik wil nog een vraag stellen aan TS > wat bedoel je met ondersteuning? Bestaande pakketten of de ondersteuning van de functionaliteit zodat je zelf een editor in elkaar kan zetten?

[B-Man]

Zijn er overigens nog meer oplossingen zoals XStandard te krijgen, die niet javascript-based zijn, maar echt separate componenten?

[Verwijderd]

Vast wel iets over te vinden op Google. Maar ik snap niet helemaal waarom je expliciet naar plugins zoekt en geen javascripts. Misschien kan daar nog een leuke discussie uit voortvloeien...

[Verwijderd]

In HTML bestaat de FONT tag. In XHTML bestaat deze niet,

Onzin.

en moet via CSS. Dat bedoel ik dus (als voorbeeld) met verplicht.

Fout voorbeeld.

In XHTML is opmaak in de code minder mogelijk.

Onzin.

Minder, omdat bijv. <small> natuurlijk ook als opmaak kan worden gezien...

Het STYLE attribute, maar ook dingen als het BACKGROUND attribute lijken mij redelijk presentatie gericht.

Maar als je dat element symantisch gebruikt ipv opmaak, is dat argument ook ondoorgrond...

?! SMALL semantisch gebruiken?

En verder voldoen mijn XHTML documenten allemaal aan de eisen in dat artikel.

Dus Internet Explorer download jouw web pagina in plaats van hem te tonen?

Gewoon geen CSS en JS in je doc zetten, maar externe bestanden gebruiken, net zoals het aangeraden wordt.

En dat geld specifiek voor XHTML sinds?

Enkel dat je enkele tags moet sluiten (<br />) daar kan ik niets aan doen. Maar is dit nu dé reden om het niet meer te gebruiken?

Eerder dat Internet Explorer vraagt om het te downloaden. Dat lijkt me een goede reden. Een andere reden is dat XHTML vaak gegenereerd wordt zonder XML tools, zoals XSLT, te gebruiken waardoor je tegen een "yellow screen of death" kunt aanlopen.

Het werkt gewoon goed...

Is dit een argument of een mening gebaseerd op foutieve feiten?

Ik vind de XML voordelen wegen bovenop de nadelen.

Alleen gebruik je het volgens mij als HTML.

Zie ook de Mozilla Web Author FAQ. Om is een stukje te quoten:

quote: http://www.mozilla.org/docs/web-developer/faq.html

However, if you are using the usual HTML features (no MathML) and are serving your content as text/html to other browsers, there is no need to serve application/xhtml+xml to Mozilla. In fact, doing so would deprive the Mozilla users of incremental display, because incremental loading of XML documents has not been implemented yet. Serving valid HTML 4.01 as text/html ensures the widest browser and search engine support.

There is a fad of serving text/html to IE but serving the same markup with no added value as application/xhtml+xml to Mozilla. This is usually done without a mechanism that would ensure the well-formedness of the served documents. Mechanisms that ensure well-formed output include serializing from a document tree object model (eg. DOM) and XSLT transformations that do not disable output escaping. When XHTML output has been retrofited to a content management system that was not designed for XML from the ground up, the system usually ends up discriminating Mozilla users by serving tag soup labeled as XML to Mozilla (leading to a parse error) and serving the same soup labeled as tag soup to IE (not leading to a parse error).

[bgever]

Verwijderd schreef op zaterdag 25 december 2004 @ 20:45:
[...]
Onzin.

Excuus: in XHTML 1.0 Strict bestaat FONT niet...

[...]
Het STYLE attribute, maar ook dingen als het BACKGROUND attribute lijken mij redelijk presentatie gericht.

Waar lees jij dat ik zeg dat dit niet mogelijk is? Ik heb het over tags als FONT, en CENTER, maar door mijn onduidelijkheid in het begin kan ik je wel begrijpen.

?! SMALL semantisch gebruiken?

De kleine lettertjes (figuurlijk) van een document kun je hier ook onder vatten. Maargoed, misschien is dit wel iets te vergezocht...

Dus Internet Explorer download jouw web pagina in plaats van hem te tonen?

Nee. Nooit last van gehad. Zal wel komen doordat ik alles als text/html verstuur...

[...]
En dat geld specifiek voor XHTML sinds?

Ik begrijp je vraag niet. Licht je nader toe...

Is dit een argument of een mening gebaseerd op foutieve feiten?

Een mening. Nee, als het wel goed had gewerkt, dan had ik alles netjes gedaan zoals het volgens het W3C moest. Maar op de wijze waarop ik het nu doe, krijg ik geen ander resultaat. Nee, goed is anders, daar geef ik je gelijk in.

Alleen gebruik je het volgens mij als HTML.

Klopt, in een browser wel ja. Maar dat zeg ik toch ook? Enkel als ik het door een XML parser laat laden, kan ik het wél als XML gebruiken...

Zie ook de Mozilla Web Author FAQ.

Interessant, maar Mozilla krijgt ook mijn XHTML pagina's in text/html voor zijn kiezen, en moet het net zo als HTML behandelen als IE. Ik gebruik niet de XML features van XHTML in een browser. Is dat zo lastig te accepteren?

XHTML is zo ontworpen dat het ook werkt in browsers die eigenlijk niet XHTML ondersteunen, en het dus als HTML zien. En zo maak ik er ook gebruik van. De XML functionaliteit gebruik ik in browsers niet. Maar ik maak de documenten wél XML valid, zodat ze óók door een XML parser te lezen zijn. Tegen de tijd dat de meest gangbare browsers XHTML werkelijk ondersteunen, dan pas laat ik de browsers mijn XHTML als XML inlezen...
Waarom? Omdat ik zo gemakkelijker de overstap kan maken (want in feite heb ik dat nog niet gedaan, al zijn mijn docs XHTML), documenten ook kan inlezen door een XML parser, en ik de XML structuur logischer vind.

[Verwijderd]

oikoyama schreef op maandag 27 december 2004 @ 13:30:

[...]
Nee. Nooit last van gehad. Zal wel komen doordat ik alles als text/html verstuur...

Om Anne voor te zijn... Wanneer je je document niet verstuurt met het application/xhtml+xml mime-type, dan is het geen XHTML, maar HTML tagsoup.
In de search hier op GoT zijn daar talloze discussies over gevoerd.

offtopic:
/me vindt het wel redelijk offtopic gaan
Misschien splitsen en het topic noemen: yaxt; yet another xhtml topic

[Spruit_elf]

X-Lars schreef op maandag 20 december 2004 @ 13:07:
Wat je bedoelt met "Dat is in XHTML met CSS min of meer "verplicht"" is in HTML 4(.01) Strict ook zo. En over dat MIME type etc.: zo makkelijk kom je er niet vanaf

xhtml is juist bedoelt om nieuwe browsers xml te serveren en oude html aan oude browser.
het is BS dat je xhtml neit mag serveren met een text/html doctype
http://www.w3.org/TR/xhtml1/#media
zolang je je maar houd aan deze regels,
http://www.w3.org/TR/xhtml1/#guidelines

ik mag er toch van uit gaan dat mensen met ene beetje kennis van zaken dit soort dingen volgen,.
ik heb nog nooit meegemaakt bij mijn eigen sites dat ze perfect werkten in text/html en ineens niet meer in application/xhtml+xml
das gewoon een kwestie van opletten wat je doet

[Verwijderd]

Excuus: in XHTML 1.0 Strict bestaat FONT niet...

En waar werd XHTML 1.0 Strict genoemd? Want als we het op die manier gaan vergelijken moeten ook we HTML 4.01 Strict nemen.

Nee. Nooit last van gehad. Zal wel komen doordat ik alles als text/html verstuur...

Zie antwoord Quist. Zie ook [url=http://www.mozilla.org/docs/web-developer/faq.html#accept]Should I serve application/xhtml+xml to Mozilla?[/quote] (en of het gebruik van XHTML dus daadwerkelijk nuttig is).

Ik begrijp je vraag niet. Licht je nader toe...

De voordelen die jij noemt zijn ook van toepassing op HTML. En aangezien je dus text/html gebruikt zijn ze wellicht alleen maar van toepassing op text/html aangezien er bij XHTML andere dingen gebeuren bij bepaalde CSS declaraties en ook andere dingen met javascript.

Interessant, maar Mozilla krijgt ook mijn XHTML pagina's in text/html voor zijn kiezen, en moet het net zo als HTML behandelen als IE. Ik gebruik niet de XML features van XHTML in een browser. Is dat zo lastig te accepteren?

Het komt er gewoon op neer dat je geen XHTML gebruikt.

XHTML is zo ontworpen dat het ook werkt in browsers die eigenlijk niet XHTML ondersteunen, en het dus als HTML zien. En zo maak ik er ook gebruik van.

Als er ooit een browser was geweest die HTML volledig ondersteund had kon jij nu geen XHTML gebruiken. Daarnaast is XHTML ontworpen voor toepassingen binnen XML. Door middel van XHTML kun je de semantiek van diverse HTML elementen in XML context gebruiken.

Waarom? Omdat ik zo gemakkelijker de overstap kan maken (want in feite heb ik dat nog niet gedaan, al zijn mijn docs XHTML), documenten ook kan inlezen door een XML parser, en ik de XML structuur logischer vind.

Waarom dan niet XHTML op de server en HTML naar de client sturen? Zodat je er zeker van bent dat iedere browser het begrijpt? Of jas je verschillende onderdelen bij elkaar met PHP includes, want in dat geval kun je het beter helemaal links laten liggen.

Verder zie ik dat je ISO-8859-1 gebruikt, houd je er rekening mee dat een aantal karakters uit dit coderingsformaat niet gebruikt kunnen worden in een XML omgeving?

[Verwijderd]

das gewoon een kwestie van opletten wat je doet

Dus je houdt rekening met het verschil van het behandelen van de 'background' property toegepast op het BODY element? Het niet werken van 'overflow' zoals je gedacht had en 'document.write' dat ermee stopt? Je karakters zijn altijd perfect gecodeerd in UTF-8 en je pagina's zijn nooit voor uur ill-formed?

Ik geloof er weinig van.

[Spruit_elf]

Verwijderd schreef op maandag 27 december 2004 @ 19:35:
[...]
Dus je houdt rekening met het verschil van het behandelen van de 'background' property toegepast op het BODY element? Het niet werken van 'overflow' zoals je gedacht had en 'document.write' dat ermee stopt? Je karakters zijn altijd perfect gecodeerd in UTF-8 en je pagina's zijn nooit voor uur ill-formed?

Ik geloof er weinig van.

jah dat van die background property wist ik en daar houd ik ook rekening mee, en zelfs als ik dat niet doe is dat snel te verhelpen

overflow gebruik ik nauwelijks, ik ben dat probleem dan ook nooit tegengekomen, heb je daar meer info over?

javascript vermijd ik zoizo al zoveel mogelijk omdat ik a er niet goed in ben, en b omdat het niet/nauwelijks gestandariseerd is en je dus voor elke pagina en elke browser een nieuw script moet maken ongeveer, dat probleem heb ik dus ook niet. bovendien ben ik geen fan van document.write

jah ik gebruik utf-8 standaard, ik meot eerlijk zeggen dat ik niet van plan ben om op oudere browsers te gaan letten.

en jah ik valideer mijn paginas altijd.

Verwijderd schreef op maandag 27 december 2004 @ 14:56:
[...]


Om Anne voor te zijn... Wanneer je je document niet verstuurt met het application/xhtml+xml mime-type, dan is het geen XHTML, maar HTML tagsoup.
In de search hier op GoT zijn daar talloze discussies over gevoerd.

het is true dat een xhtml document niet helemaal valideert als html4.01, maar dat verschil zit praktisch in de extra attributen die xhtml heeft in het html element. echter volgens de regels moet een html4.01 UA attributen negeren die hij neit herkend, ofterwijl hij moet ze negeren en dus word het niets anders dan html4.01

[ Voor 4% gewijzigd door Spruit_elf op 27-12-2004 20:20 ]

[Verwijderd]

mrcactus, ooit gehoord van de shorttag NET feature van SGML welke van toepassing is op HTML? Het komt hier op neer:

code:

<br />

behoort op deze wijze geinterpreteerd te worden in een HTML (text/html) omgeving:

code:

<br>&gt;

Dat lijkt mij een significant verschil in het parsen, daarnaast heeft het gebruik van XHTML als je het toch als text/html verstuurd 0,0% voordeel.

Over 'overflow'. In XML omgeving wordt het niet naar de viewport overgedragen, zowel niet van het HTML als van het BODY element. Zie deze regel:

quote: http://www.w3.org/TR/2004...0225/visufx.html#overflow

HTML UAs may apply the overflow property from the BODY or HTML elements to the viewport.

(Hoewel er MAY staat, heeft zo goed als elke UA dit geimplementeerd.)

[Spruit_elf]

Verwijderd schreef op maandag 27 december 2004 @ 20:38:
mrcactus, ooit gehoord van de shorttag NET feature van SGML welke van toepassing is op HTML? Het komt hier op neer:

code:

<br />

behoort op deze wijze geinterpreteerd te worden in een HTML (text/html) omgeving:

code:

<br>&gt;

Dat lijkt mij een significant verschil in het parsen, daarnaast heeft het gebruik van XHTML als je het toch als text/html verstuurd 0,0% voordeel.

Over 'overflow'. In XML omgeving wordt het niet naar de viewport overgedragen, zowel niet van het HTML als van het BODY element. Zie deze regel:
[...]
(Hoewel er MAY staat, heeft zo goed als elke UA dit geimplementeerd.)

jah dat ken ik, door de w3c validator wordt dat overigens wel als correct html gezien en niet als

code:

<br>&gt;

met uitzondering van de meta tags, waar het weer niet zo is.

ok je hebt gelijk het is niet helemaal correct, maar correct genoeg om prima te werken, en nu we toch in een tijd zitten waar geen enkele standaard perfect word ondersteund, vind ik het eerlijk gezegd beter om nu alvast in xhtml mijn sites te maken( rekening houdend met de verschillen/guidelines) en dan als IE ooit xhtml support heeft, alleen mijn mimetype te hoeven veranderen.
en ik ben het eens met de mensen boven mij dat xhtml toch wel een aantal voordelen bied zoals bijvoorbeeld het verplicht well-formed maken (voor mezelf makkelijker en duidelijker)
en xml mogelijkheden(dan wel bij het maken van documenten, dan wel serverside)

[ Voor 4% gewijzigd door Spruit_elf op 27-12-2004 21:06 ]

[Verwijderd]

mrcactus schreef op maandag 27 december 2004 @ 21:04:
...knip...
en ik ben het eens met de mensen boven mij dat xhtml toch wel een aantal voordelen bied zoals bijvoorbeeld het verplicht well-formed maken (voor mezelf makkelijker en duidelijker)
en xml mogelijkheden(dan wel bij het maken van documenten, dan wel serverside)

Dat het well-formed in HTML geen verplichting is, wil toch niet zeggen dat je je er niet aan mag houden? Je kan een HTML document ook netjes opmaken...
UA's zijn nou eenmaal geoptimaliseerd voor nette HTML en geen XHTML. Zoals in vele discussies al naar boven is gekomen, biedt XHTML (nog) geen voordeel boven HTML.

[Verwijderd]

jah dat ken ik, door de w3c validator wordt dat overigens wel als correct html gezien en niet als

code:

<br>&gt;

Je snapt het dus blijkbaar niet. Het is correcte HTML en wordt door browsers behandelt als het ware <br>&gt; (als ze de standaard zouden volgen)

[ Voor 12% gewijzigd door Verwijderd op 27-12-2004 21:13 ]

[Spruit_elf]

Verwijderd schreef op maandag 27 december 2004 @ 21:13:
[...]
Je snapt het dus blijkbaar niet. Het is correcte HTML en wordt door browsers behandelt als het ware <br>&gt; (als ze de standaard zouden volgen)

jah dat had ik al begrepen, je hebt idd gelijk, ik meende dat de validator <br /> ook als zo herkende , maar daar kan ik niets over zeggen, want de parse tree van de validator die overigens die > niet laat zien behandelt het waarschijnlijk als xml aangezien die er <br></br> van maakt(wat volgens mij correct is)

Verwijderd schreef op maandag 27 december 2004 @ 21:10:
[...]


Dat het well-formed in HTML geen verplichting is, wil toch niet zeggen dat je je er niet aan mag houden? Je kan een HTML document ook netjes opmaken...

helemaal waar, maar dat laat mij nog wel met het punt van tags als <br> die geen close tag hebben, mischien ligt het aan mij, maar ik het nu eenmaal logischer en duidelijker als alle tags een eind hebben, het liefst zou ik zelfs <br></br> willen doen, maar dat gaat helemaal neit werken helaas. xml denkt makkelijker voor mij. bovendien kan ik dan via xml weer snel zien of ik geen fouten heb gemaakt

overigens gebruik ik de <br /> tag alleen bij hoge uitzondering. aangezien je het meeste prima met margins, <p></p> en <ul> kan doen

[ Voor 43% gewijzigd door Spruit_elf op 27-12-2004 21:32 ]

[bgever]

Verwijderd schreef op maandag 27 december 2004 @ 19:33:
[...]
En waar werd XHTML 1.0 Strict genoemd? Want als we het op die manier gaan vergelijken moeten ook we HTML 4.01 Strict nemen.

Vandaar ook mijn excuus...

[...]
Het komt er gewoon op neer dat je geen XHTML gebruikt.

Juist, maar deze websites zijn wel eenvoudig om te schakelen naar XHTML als dit door de browsers goed ondersteund wordt...

Waarom dan niet XHTML op de server en HTML naar de client sturen? Zodat je er zeker van bent dat iedere browser het begrijpt? Of jas je verschillende onderdelen bij elkaar met PHP includes, want in dat geval kun je het beter helemaal links laten liggen.

Juist, en tot die conclusie kwam ik na jouw post ook. En dat is ook de reden waarom ik je (in een e-mail) aangaf, dat ik voortaan maar HTML 4.01 Strict gebruik, omdat het op dit moment toch geen nut heeft, en alleen maar méér rompslomp meebrengt.
Daarbij zie ik het somber in, zal er over 2 jaar al goede XHTML ondersteuning zijn? Ik ben bang van niet...
En om dan weer even ontopic te komen: de huidige wysiwyg editors kunnen wel XHTML compatible worden, maar wat heb je er aan als de browsers dat nog niet zijn?

Verder zie ik dat je ISO-8859-1 gebruikt, houd je er rekening mee dat een aantal karakters uit dit coderingsformaat niet gebruikt kunnen worden in een XML omgeving?

Ja hoor.

[Verwijderd]

maar daar kan ik niets over zeggen, want de parse tree van de validator die overigens die > niet laat zien behandelt het waarschijnlijk als xml aangezien die er <br></br> van maakt(wat volgens mij correct is)

De validator is een SGML parser waarin is gehackt voor wat XML ondersteuning. Hij heeft dan ook een aantal limitaties.

En een XML parser zou er <br/> van maken, niet <br></br>.

helemaal waar, maar dat laat mij nog wel met het punt van tags als <br> die geen close tag hebben, mischien ligt het aan mij, maar ik het nu eenmaal logischer en duidelijker als alle tags een eind hebben, het liefst zou ik zelfs <br></br> willen doen, maar dat gaat helemaal neit werken helaas. xml denkt makkelijker voor mij. bovendien kan ik dan via xml weer snel zien of ik geen fouten heb gemaakt

Wat heeft dit te maken met hetgeen je naar de browser stuurt?

overigens gebruik ik de <br /> tag alleen bij hoge uitzondering. aangezien je het meeste prima met margins, <p></p> en <ul> kan doen

Het blijft een feit dat je invalid HTML stuurt naar de browser. Ongeacht welk truucje je bedenkt. Daarnaast raad onder andere Mozilla het gebruik van XHTML af als je het niet echt nodig hebt.

[Verwijderd]

Daarbij zie ik het somber in, zal er over 2 jaar al goede XHTML ondersteuning zijn? Ik ben bang van niet...

Ik zet in op 10 jaar. En als ze tegen die tijd nog steeds geen incremental rendering hebben (in elke frieking browser) blijft het nutteloos.

[crisp]

mrcactus schreef op maandag 27 december 2004 @ 20:20:
[...]
javascript vermijd ik zoizo al zoveel mogelijk omdat ik a er niet goed in ben, en b omdat het niet/nauwelijks gestandariseerd is en je dus voor elke pagina en elke browser een nieuw script moet maken ongeveer, dat probleem heb ik dus ook niet. bovendien ben ik geen fan van document.write

Javascript is juist wel gestandardiseerd (de standaard heet ECMA fyi), en met de komst van het DOM object model is zelfs de browser-implementatie ervan voor het grootste deel gestandardiseerd, dus a) is je enige excuus

[Spruit_elf]

crisp schreef op maandag 27 december 2004 @ 23:29:
[...]

Javascript is juist wel gestandardiseerd (de standaard heet ECMA fyi), en met de komst van het DOM object model is zelfs de browser-implementatie ervan voor het grootste deel gestandardiseerd, dus a) is je enige excuus

ik merk anders nog grote verschillen, waar ik als ik iets van css gebruik wat neit werkt in een browser, meestal maar een klein extratje mis, moet ik bij javascript per browser andere dingen gebruiken, omdat ander het hele script ineens niet meer werkt
this.target in mozilla en this.srcElement in IE en zo is het rijtje nog langer.
mischien is de standaard er wel, maar de implementatie is igg nog neit fantastis

Verwijderd schreef op maandag 27 december 2004 @ 23:16:
Wat heeft dit te maken met hetgeen je naar de browser stuurt?

afgezien dat html4 parsers <br></br> niet accepteren niet veel, maar het is een beetje onzin om eerst een document in xml regels te gaan maken en het vervolgens te converteren naar html4, vooral als dat neit echt nodig is omdat(als je je aan de guidelines houd) hij het toch correct rendert

Het blijft een feit dat je invalid HTML stuurt naar de browser. Ongeacht welk truucje je bedenkt. Daarnaast raad onder andere Mozilla het gebruik van XHTML af als je het niet echt nodig hebt.

hier zeggen ze dat je xhtml idd niet als application/xhtml+xml naar alleen mozilla meot sturen als je het niet nodig hebt voor mathML ofzo, ze zeggen niets over het xhtml schrijven en vervolgens als text/html serveren. wederom, dat kan volgens mij prima(als je je aan de guidelines houd) aangezien het daarvoor bedoeld is. en doordat je je paginas dan al in een xml compatible vorm hebt kan je zodra je wilt overschakelen.
mathML gebruiken bijvoorbeeld