[mshtml] uppercase en quoted attributen

[Verwijderd]

K ben met een wysiwyg editor bezig, maakt gebruik van MsHtml, die IE componenten om een editor te bouwen.
Ik loop telkens alleen tegen het probleem dat bepaalde tags en attributen worden vervormd.

1. De volgorde van attributen binnen een rag word veranderd.
2. Tags worden in uppercase terug gegeven
3. In bepaalde attributen worden de quotes (die de inhoud ervan aangeven) weg gehaald

Een voorbeeld op msdn, met een editor: http://msdn.microsoft.com...html/refs/editRegions.htm

Voer dit in:
<input type="button" onclick="functieBlaat();" value="ga maar zoeken" id="submitknop" />
Je krijgt dit terug:
<INPUT id=submitknop onclick=functieBlaat(); type=button value="ga maar zoeken">

Is er een verklaring voor dat dit gebeurd (niet dat het standaard ie gedrag is, dat blijkt namelijk wel gewoon).
Ik wil weten wat de reden is dat dit gebeurd, en er eigenlijk macht op uit oefenen, zodat ik mijn tags gewoon behoud zoals ze zijn

[drm]

Je kunt er geen invloed op uitoefenen, het is namelijk MSHTML wat je terugkrijgt, en dat heeft nou eenmaal die vorm. Je kunt wel op een andere manier je HTML reproduceren, namelijk door recursief de dom-tree te doorlopen en zelf de html op te bouwen.

[Verwijderd]

Daar was ik al bang voor, dat je zoiets zou gaan zeggen. Ik heb alleen de tijd en zin niet om een complete re-render engine te gaan schrijven...
Of is dat nie helemaal wat je bedoeld ??

offtopic:
* By the way, bedankt voor je goede regEx tutorial

[Verwijderd]

Verwijderd schreef op woensdag 02 februari 2005 @ 17:48:
Daar was ik al bang voor, dat je zoiets zou gaan zeggen. Ik heb alleen de tijd en zin niet om een complete re-render engine te gaan schrijven...
Of is dat nie helemaal wat je bedoeld ??

offtopic:
* By the way, bedankt voor je goede regEx tutorial

No hard feelings, maar ik denk ook niet dat je dat kan

Wat drm bedoelt is dat je recursief door je DOM tree moet lopen, bij elke node de nodename opvragen alle attributen en zo zelf een string opbouwen die de HTML bevat. Je loopt dus door de tree, komt een element tegen, maakt de nodename lowercase, attributen lowercase, zet er mooi aanhalingstekens omheen etc etc.

Nu komt de grote maar:
Wanneer je nesting incorrect is, is je DOM tree corrupt, en kan je daar niet goed doorheenlopen .

HTML:

<b>woei<i>blaat</b>woei</i>

Bovenstaande stukje zorgt voor een mooi verneukte DOM tree, waar je dus niet doorheen kan lopen. Oplossing: HTML meuk opvragen, tokenizer schrijven, HTML netjes maken, String weergeven.
Die tokenizer wil je niet met RegEx doen, omdat je nogal wat problemen daarmee zult tegenkomen wanneer Tokens in attributen niet als entities zijn weergegeven;

code:

<div onclick="alert( 4 > 5 );">woei</div>

Veel Tokenizers die op regex gebaseerd zijn, zullen de > in het attribuut kenmerken als "einde element". Ik heb ooi een lange regex gemaakt met lookahead etc om dit toch op te lossen; 't was trager dan teken voor teken door je tekenreeks heenlopen omdat de regex engine de hele tijd heen en weer aan het hobbelen is

[ Voor 25% gewijzigd door Verwijderd op 02-02-2005 18:11 ]

[Verwijderd]

Wat is een tokenizer ??
K ben enigsinds nieuw met deze dingen ...

[Verwijderd]

Verwijderd schreef op woensdag 02 februari 2005 @ 18:07:
[...]

Nu komt de grote maar:
Wanneer je nesting incorrect is, is je DOM tree corrupt, en kan je daar niet goed doorheenlopen .

HTML:

<b>woei<i>blaat</b>woei</i>

dit is incorrecte HTML

code:

<div onclick="alert( 4 > 5 );">woei</div>

dit ook

de vraag is of je wel rotte html recht wil trekken. Hoewel het soms handig is ben ik er vaak voorstander van de gebruiker maar eens hard met z'n neus op de feiten te drukken:

"je html is rot, ik kan het niet parsen, vette pech, fix het eerst maar"

overigens krijg je uppercase nodeNames terug om dat de html DOM 2 spec zo is, met een XML dom heb je dat niet, want die is casesensitive

[ Voor 16% gewijzigd door Verwijderd op 02-02-2005 19:03 ]

[Verwijderd]

Die vlieger gaat natuurlijk niet op he Mophor. Kan je wel zeuren dat het incorrecte HTML is; zolang browsers het eten, zal je editor het ook moeten eten. Zo heel ingewikkeld is een tokenizer maken nou ook weer niet.

jurrieBurrie > ga eens *zoeken* wat een tokenizer is

[ Voor 15% gewijzigd door Verwijderd op 02-02-2005 19:27 ]

[Verwijderd]

Verwijderd schreef op woensdag 02 februari 2005 @ 19:00:

de vraag is of je wel rotte html recht wil trekken. Hoewel het soms handig is ben ik er vaak voorstander van de gebruiker maar eens hard met z'n neus op de feiten te drukken:

"je html is rot, ik kan het niet parsen, vette pech, fix het eerst maar"

Dat is de makkelijke optie. Stel je levert een product, en mensen krijgen als ze er de inhoud van een Word document in plakken een foutmelding:
Dit moet ik niet, lever maar correcte HTML aan.

Nee, zo werkt dat niet met WYSIWYG editors. Die zijn er voor mensen die zich niet met HTML of opmaakcode bezig willen zijn, ze willen alleen maar hun Word rommel in kunnen plakken. Dit is iets wat je gewoon zo goed mogelijk moet proberen op te lossen. En dat doe je deels door zo goed mogelijk de informatie te verwerken, en deels door voor te lichten wat wel en niet kan, en waarom dat zo is.

Dat is niet de makkelijkste oplossing voor de programmeur, maar het is de beste oplossing voor de klant.

Als God had gewild dat iedereen HTML kon gebruiken, had hij de mensen wel niet zo dom gemaakt

[Verwijderd]

ik ging er even vanuit dat het was om doot users zelf geproduceerde html te parsen,
maar is die world rommel dan echt zo erg (in: een rotte DOM)? ik heb me er nooit in verdiept, maar ik dacht dat word alleen een berg eigen namespaces en attributen erbij kwakte...

[drm]

mophor:
maar is die world rommel dan echt zo erg (in: een rotte DOM)? ik heb me er nooit in verdiept, maar ik dacht dat word alleen een berg eigen namespaces en attributen erbij kwakte...

't Komt wel eens voor dat ook Word de dom-tree upfux0rt. Het enige verschijnsel wat ik daarbij tegengekomen ben is dat textnodes zich gaan herhalen, heel maf is dat. Daar is een tijdje terug hier ook nog een topic over geweest, ik zal eens kijken of ik 't terug kan vinden...

edit:
Clay

Kan het topic niet meer vinden ...

[ Voor 8% gewijzigd door drm op 03-02-2005 10:30 ]

[Clay]

Verwijderd schreef op woensdag 02 februari 2005 @ 22:50:
ik ging er even vanuit dat het was om doot users zelf geproduceerde html te parsen,
maar is die world rommel dan echt zo erg (in: een rotte DOM)? ik heb me er nooit in verdiept, maar ik dacht dat word alleen een berg eigen namespaces en attributen erbij kwakte...

Rotte dom geloof ik idd niet, maar er staat wel ongelovelijke rommel tussen zoals:

code:

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
<v:shapetype id="_x0000_t75" stroked="f" filled="f" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t" o:spt="75" coordsize="21600,21600">
      <v:stroke joinstyle="miter"></v:stroke>
      <v:formulas>
         <v:f eqn="if lineDrawn pixelLineWidth 0"></v:f>
*knip*

maar dat is op zich natuurlijk makkelijk te trashen door alles met namespaces te filteren. Ik zou zelf trouwens ook botweg alle span, font, center etc. tags wegmikken, en inline styles ook. wysiwyg is leuk, maar zo'n ding moet markup poepen, geen style info bevatten imo dan.

edit:
drm

Ok blijkbaar kan een rotte dom ook genoeg redenen om een mooie htmltidy te schrijven

[ Voor 14% gewijzigd door Clay op 03-02-2005 09:56 ]

[Verwijderd]

ik vond mijn getElementsByRegEx(regex,prop) extensie op de DOM voor dit soort doeleinden eigenlijk wel handig , maar idd daar heb je niks aan als je DOM echt rot is.

Bovendien is het natuurlijk wel leuk om je eigen tokenizer te schrijven, hoewel een getElementsByRegEx schrijven ook wel leuk is. Die voorbeeld code van clay is natuurlijk gewoon keurige xml

[drm]

Ah! Found it.
[rml][ JS] Nesting correctie[/rml]

[Verwijderd]

drm schreef op donderdag 03 februari 2005 @ 11:24:
Ah! Found it.
[rml][ JS] Nesting correctie[/rml]

Ik heb uit ervaring ondervonden dat Nesting Correctie erg lastig is. De oplossingen in dat topic, werken redelijk. Het schrijven van een tokenizer die een array terouneert met alle node types en informatie is niet het probleem. De Nesting Correctie wel. Je moet namelijk een stack bijhouden, maar die stack moet ook nog weer intelligent zijn;

code:

<table>
  <tr>
    <td><b>niet afsluiten</td>
    <td>Bold of niet? ;)</td>
  </tr>
</table>

Ik zal het maar verklappen; de tekst in de tweede tabelcell is niet vet. Dus na sommige tags moet je items van de stack poppen. Kijken welke gepopt moeten worden, welke niet. Etc etc.
Een simpele stack parsert zou namelijk bij de eerst </td> eerst de B tag afsluiten, vervolgens de </td> neerplempen en daarna de <b> weer openen met als gevolg:

code:

<table>
  <tr>
    <td><b>niet afsluiten</b></td><b>
    <td>Bold of niet? ;)</td></b>
  </tr>
</table>

Niet echt wat je wilt. Daarom moet je een datastructuur verzinnen waar je alle uitzonderingen en regels in opgeeft. Leuke shit
Daarom heb ik besloten zelf geen nesting correctie pogen toe te voegen. De tokenizer maakt een array. Van die array maak ik een string en die plemp ik terug, nesting heeft maar pech. Maar zo lijkt de HTML iig fatsoenlijk.

[Clay]

De browsers zelf doen natuurlijk ook al wat aan correctie. Die eerste bold wordt b.v. gewoon voor de </td> afgesloten, en daarna niet meer geopend. Dat zou ook loos zijn dan kon een bold tag aan het begin van het document alles bold maken, hij zou immers nergens meer gesloten worden. Bij het 2e voorbeeld doen IE en FF alletwee wat anders; IE zet de 2e td tussen bold tags, en FF opent en sluit de bold tag meteen weer.

met een kort scriptje kan je ook checken wat browsers zelf met nesting doen:

HTML:

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

<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
    <title> Nest Test </title>
    <script type="text/javascript">
    function checkNesting(area) {
        var el = document.getElementById('checker');
        el.innerHTML = area.value;
        alert(el.innerHTML);
    }
    </script>
</head>
<body>  
    <form>
        <textarea style="width:400px;height:300px;"></textarea><input style="display:block" 
            type="button" value="check" onclick="checkNesting(this.previousSibling)" />
    </form>
    <div id="checker"></div>
</body>
</html>

Check b.v. ook het verschil tussen wat IE en FF doen met <b><p>

Het probleem van foute nesting is ook dat het op meerdere manieren te fixen is, er is niet 1 correct antwoord. Ik heb zelf dus wel een regex/stack parser/correctie gemaakt, en die draait op 2 hele simpele regels:

• Bij een andere sluittag dan verwacht wordt de verwachtte tussengevoegd, en niet meer geopend.
• Een sluittag die niet open was wordt zonder pardon getrasht. (kan een gevolg zijn van 1)

[ Voor 25% gewijzigd door Clay op 03-02-2005 13:31 ]

[Verwijderd]

K ben al een eindje op weg de goede richting in geloof ik.
Ik kom er alleen maar niet achter hoe ik alle gebruikte attributen uit een element kan uitlezen..
Gezocht, nog eens gezocht maar niets kunnen vinden ..
Hoe doe ik dat ?

[Verwijderd]

Node.attributes[];

[ Voor 70% gewijzigd door Verwijderd op 03-02-2005 13:41 ]