css styles html tags binnen div houden

[mookie]

Beetje rare titel maar kan het niet echt beter verwoorden.

Via "php ews" maak ik verbinding met onze interne exchange server en haal b.v. een lijstje van de laatste 20 emails op en laat dan, ongeveer net als in outlook, de afzender, onderwerp, ontvangstdatum etc zien.

Nu wil ik graag dat als men op een regel klikt dat er in een aparte div de email body wordt geladen via ajax.
Dit werkt ook prima, echter zit er wel eens een mailtje tussen met wat CSS die elementen styled die ik ook al in mijn pagina heb (gewoon stylen van <p> elementen bijvoorbeeld).
Of een mail waar gewoon een <font> html tag inzit.
Als oma dan een mail met lettergrootte 48 heeft verstuurd zodat ze het makkelijk kan lezen en ik open die in mijn div dan krijgt de tekst in mijn eigen pagina ook die enorme lettergrootte (of nog beter, comic sans lettertypes en dergelijken)

Ik kan de body van de email, alvorens hem in de div te laden, wel ontdoen van alle CSS opmaak maar dat heeft ook weer nadelen, want ik wil graag dat de email eruit blijft zien zoals hij is.

Is er een manier om die CSS opmaak binnen die DIV te houden?

Ik heb al gekeken naar <style scoped> maar dat werkt volgens mij alleen standaard in firefox.
In ieder geval niet binnen IE en Chrome zonder truukjes.

Ik zou het in een iframe kunnen plaatsen maar ben zelf niet zo'n fan van iframes.
Ik wil ook niet nog een extra pagina openen waar dan enkel die email in te zien is, het moet allemaal binnen dezelfde pagina blijven.

Ik weet niet meer waar ik op moet zoeken, welke zoekwoorden ik zou moeten gebruiken...
Iemand tips?

[RobIII]

Al eens een iframe geprobeerd?

[mookie]

iframe ja... ik snap niet waarom dat uitgebannen zou moeten worden.
ipv innerhtml van een DIV verander ik nu gewoon de src van een iframe.

Werkt wel lekker en alle opmaak die ik erin duw heeft inderdaad geen gevolgen meer voor mijn hoofdpagina.

Zijn er eigenlijk redenen om geen iframe te gebruiken?

[RobIII]

mookie schreef op vrijdag 12 september 2014 @ 22:49:
Zijn er eigenlijk redenen om geen iframe te gebruiken?

Ongeveer tweemiljoenmiljard. Maar dit geval is er daar géén van; dit is nou nét waar 't voor bedoeld is:

quote: https://developer.mozilla...s/Web/HTML/Element/iframe

The HTML <iframe> Element (or HTML inline frame element) represents a nested browsing context, effectively embedding another HTML page into the current page.

quote: http://www.w3.org/TR/html...0.html#the-iframe-element

The iframe element represents a nested browsing context.

quote: http://www.w3.org/TR/html...l#nested-browsing-context

Certain elements (for example, iframe elements) can instantiate further browsing contexts.

[ Voor 52% gewijzigd door RobIII op 12-09-2014 22:56 ]

[Anoniem: 619871]

Zou je dit niet op kunnen lossen met bijvoorbeeld jquery om die div te stylen wanneer die geladen wordt? Of denk ik nu te makkelijk?

[RobIII]

Anoniem: 619871 schreef op zaterdag 13 september 2014 @ 00:10:
Zou je dit niet op kunnen lossen met bijvoorbeeld jquery om die div te stylen wanneer die geladen wordt? Of denk ik nu te makkelijk?

Je denkt te makkelijk
Nog even los van de stijl wil je überhaupt dat die "meuk" (want: je kunt wel God-knows-what toegemailed krijgen) in een eigen context geladen wordt zodat evt. scripts en andere enge zaken niet bij je cookies etc. kunnen. Gewoon kwestie van sandboxen.

[Barryvdh]

Je zult je output toch moeten controleren /sanitizen, want ook in je iframe wil je geen scripts ed. draaien.

Als je perse geen iframe zou willen gebruiken zou je ook je css kunnen inlinen, bijv met https://github.com/tijsverkoyen/CssToInlineStyles

[RobIII]

Barryvdh schreef op zaterdag 13 september 2014 @ 10:24:
Je zult je output toch moeten controleren /sanitizen, want ook in je iframe wil je geen scripts ed. draaien

Maar dat krijg je nooit waterdicht en dan is zo'n barrière van een iframe wél zo fijn. Ik zie sowieso het probleem niet; ja (i)frames zijn k*t (dat is er jarenlang, terecht, ingeslagen) maar dan moet je wél even in achterhoofd houden dat dat hele andere redenen had. Dit is nou juist waar een iframe voor bedoeld is. Maar ja, Pavlov was zo gek nog niet klaarblijkelijk...

[Barryvdh]

RobIII schreef op zaterdag 13 september 2014 @ 14:37:
[...]

Maar dat krijg je nooit waterdicht en dan is zo'n barrière van een iframe wél zo fijn. Ik zie sowieso het probleem niet; ja (i)frames zijn k*t (dat is er jarenlang, terecht, ingeslagen) maar dan moet je wél even in achterhoofd houden dat dat hele andere redenen had. Dit is nou juist waar een iframe voor bedoeld is. Maar ja, Pavlov was zo gek nog niet klaarblijkelijk...

Ik zeg ook niet dat hij geen iframes moet gebruiken, of dat iframes slecht zijn. (Volgens mij waren het vooral frames die slecht zijn, niet iframes, maar waarschijnlijk verwarren mensen die met frames).
Ik geef alleen aan dat als hij geen iframes wil gebruiken, hij zoiets zou kunnen doen.

En controleren/sanitizen moet je sowieso bedoelde ik alleen maar te zeggen, of je nu met iframes werkt of met iets anders. Een iframe heeft toch ook toegang tot cookies van dat domein en het parent document, tenzij het van een ander domein is toch? En anders wil je alsnog niet dat er random javascript wordt uitgevoerd.
Er zijn wel tools die het redelijk betrouwbaar zouden moeten maken, bijv. https://github.com/ezyang/htmlpurifier (zelf geen ervaring mee).

[Gomez12]

In principe zou ik gewoon alles strippen behalve een paar dingen die je kan whitelisten.

Hier is al menig webmail client mee op zijn muil gegaan vanwege xss etc.

Of je kan het ook in een iframe stouwen, maar zorg dan wel dat de target van de iframe een ander domein heeft.

[RobIII]

Toevallig vandaag "in het nieuws":

[q=http://blog.stackoverflow.com/2014/09/introducing-runnable-javascript-css-and-html-code-snippets/]
Introducing Runnable JavaScript, CSS, and HTML Code Snippets
[...]
Are Stack Snippets Safe?

Yes, as much as the web in general is safe. You are not in any more danger than you are when browsing any site with JavaScript enabled. With that said, the snippets are running client code in your browser, and you should always exercise caution when running code contributed by another user.

We isolate snippets from our sites to block access to your private Stack Exchange data:

• We use HTML5 sandboxed iframes in order to prevent many forms of malicious attack.
• We render the Snippets on an external domain (stacksnippets.net) in order to ensure that the same-origin policy is not in effect and to keep the snippets from accessing your logged-in session or cookies.
• [...]

[Mr. Awesome]

En als je nou in je eigen CSS-files bij elk element (al dan niet dmv een script en/of framework) !important toevoegt? Dan hoef je niet bang te zijn dat de e-mail CSS de pagina-CSS override.

E: Hm, volgens mij denk ik te simpel of snap ik je probleem toch niet helemaal.

[ Voor 18% gewijzigd door Mr. Awesome op 17-09-2014 15:07 ]

[RobIII]

hyptonize schreef op woensdag 17 september 2014 @ 15:06:
En als je nou in je eigen CSS-files bij elk element (al dan niet dmv een script en/of framework) !important toevoegt? Dan hoef je niet bang te zijn dat de e-mail CSS de pagina-CSS override.

Dan heb je nog altijd dat "de andere kant" ook gewoon !important erachter vlamt en ben je weer terug bij af. Dat wordt gewoon een deze-vuist-op-deze-vuist spelletje dat je nooit wint.

[ Voor 7% gewijzigd door RobIII op 17-09-2014 15:08 ]

[xehbit]

Al eens naar Shadow DOM gekeken, volgens mij is dit wat je zoekt.
http://www.html5rocks.com.../webcomponents/shadowdom/

[Gomez12]

Dragon707 schreef op woensdag 17 september 2014 @ 16:34:
Al eens naar Shadow DOM gekeken, volgens mij is dit wat je zoekt.
http://www.html5rocks.com.../webcomponents/shadowdom/

Het probleem veelal met deze dingen is dat het weinig gebruikte en dus "weinig" geteste features zijn.

En dat de spammers veelal die features beter getest hebben dan de reguliere developers en dat de spammers dus ook alle bugs etc weten en die ook 100% benutten.
Dus dan zit jij te testen in chrome en heb je geen spam-mailtje staan en je gebruiker gaat in firefox / ie je pagina bekijken en krijgt wel een spam-mailtje binnen.

Regulier cross-browser on-the-edge bouwen is al een uitdaging, maar als het alternatief ook nog eens is geen fallback maar gewoon ongewenst gedrag dan heb je helemaal feest.

En als ik even snel hier kijk : http://caniuse.com/#feat=shadowdom dan wordt ik niet echt enthousiast over de mensen die je ermee zou kunnen bereiken. Voor mij is het missende gedeelte te groot, wat regulier niet zo'n probleem zou zijn omdat ik het alleen zou gebruiken als "opsmuk" maar hier wil je je layoutbewaking en de bruikbaarheid van je app af laten hangen van die support.

[reshi]

Je zegt "het moet allemaal binnen dezelfde pagina blijven", wat als je de mail opent in een popup venster bovenop de pagina? Kunnen mensen de mail lezen met de opmaak die mee gegeven wordt in de mail (iframe) en op het moment dat de "popup" gesloten wordt is men weer terug op de pagina. Dit zou je dan zelfs nog zo kunnen maken dat de popup niet de hele pagina in beslag neemt en zelfs nog een transparante achtergrond heeft waar je de achterliggende site door kan zien.

iets zoals:
http://dinbror.dk/bpopup/
of
http://www.jacklmoore.com/colorbox/example1/ en dan voorbeeld "Outside Webpage (Iframe)"

[RobIII]

Waarom zou je een popup gebruiken? UI en UX -technisch is dat nog een trapje erger dan ruk

[Tunaflish]

Correct me if I'm wrong, maar zoals ik het nu begrijp wil je dat een stuk html wordt opgemaakt met css apart voor de content, die in die html is opgegeven. Dan geef je toch gewoon een uniek ID mee aan de body van die html en in je css dat id plaatsen voor alle selectors?

Werkt niet als je de inhoud van die html niet kunt wijzigen, maar als dat wel kan lijkt dit me de makkelijkste oplossing.

[RobIII]

Tunaflish schreef op dinsdag 23 september 2014 @ 16:06:
Correct me if I'm wrong, maar zoals ik het nu begrijp wil je dat een stuk html wordt opgemaakt met css apart voor de content, die in die html is opgegeven. Dan geef je toch gewoon een uniek ID mee aan de body van die html en in je css dat id plaatsen voor alle selectors?

Werkt niet als je de inhoud van die html niet kunt wijzigen, maar als dat wel kan lijkt dit me de makkelijkste oplossing.

Als er in die "mail CSS" iets staat als:

Cascading Stylesheet:

p { color: red }

Dan worden je "eigen" paragraphs ook rood, ongeacht of je een ID hangt aan de "div" waar de mail in staat:

HTML:

<!doctype html>
<html>
...
<body id="myid">
  <p>Bla blah bla</p>
  ...

  <div id="emailcontent">
    ...mailcontents here...
  </div>
</body>
</html>

[ Voor 6% gewijzigd door RobIII op 23-09-2014 16:50 ]

[Tunaflish]

RobIII schreef op dinsdag 23 september 2014 @ 16:49:
[...]

Als er in die "mail CSS" iets staat als:

Cascading Stylesheet:

p { color: red }

Dan worden je "eigen" paragraphs ook rood, ongeacht of je een ID hangt aan de "div" waar de mail in staat:

HTML:

<!doctype html>
<html>
...
<body id="myid">
  <p>Bla blah bla</p>
  ...

  <div id="emailcontent">
    ...mailcontents here...
  </div>
</body>
</html>

Klopt, dus zorg je dat in de css van de mail overal die #emailcontent voor staat, dus dit:

Cascading Stylesheet:

#emailcontent p {color: blue ;}

Betekent inderdaad wel dat als er in de css van die mail niks over de kleur van paragraphs wordt gezegd, dat het dan alsnog rood wordt, maar je kunt in je eigen css natuurlijk al defaults aangeven.

[ Voor 14% gewijzigd door Tunaflish op 23-09-2014 21:09 . Reden: Kleine toevoeging ]

[RobIII]

Tunaflish schreef op dinsdag 23 september 2014 @ 21:06:
[...]

Klopt, dus zorg je dat in de css van de mail overal die #emailcontent voor staat, dus dit:

Cascading Stylesheet:

#emailcontent p {color: blue ;}

...wat weer betekent dat je CSS moet gaan parsen etc. etc. En dan loop je geheid een keer tegen een "edge case" aan die er wel doorheen komt. Ik zie wer-ke-lijk waar niet waarom je (lees: men) zo moeilijk zou doen als je 't gewoon in een iFrame kunt flikkeren en be done with it. Maar goed, ik ben dan ook lui

[ Voor 8% gewijzigd door RobIII op 23-09-2014 21:29 ]

[Tunaflish]

Tsja, als je geen iframe wil zul je moeilijk moeten doen inderdaad

[mookie]

Nou nou, ik ben verrast door alle reacties...
Ik was al blij als uberhaupt 1 persoon zou reageren

Maar, inderdaad liever geen iframe, maar liever een iframe dan al het andere wat wordt voorgesteld of wat ik zelf heb kunnen vinden.
Mijn eigen CSS aanpassen, of de CSS uit de email body is gewoon een hel en praktisch nooit waterdicht te krijgen.
De iframe oplossing werkte binnen 5 minuten en voegt meteen wat sandbox functionaliteit toe.

Enige nadeel is dat ik een iframe praktisch niet goed dynamisch kan resizen in mijn eigen hoofd pagina.
Er bestaat geen volledige auto resize (height:auto ofzoiets) voor en truukjes met javascript ben ik niet zo weg van.
Is ook van ondergeschikt belang in dit geval dus ik laat het zo.

De bedoeling van dit stukje is ook niet om een webmail client te maken.
Ik had een manier nodig om uit een email
- of de body met opmaak
- of alle of enkele attachments
- of de body met opmaak en alle attachments
snel op te kunnen slaan in een document/feedback beheer systeem.

Nu gebeurt dat al, maar dan met een hoop knip en plak werk en tussentijds even tijdelijk ergens opslaan en dan uploaden via een files form.
Ik wist niet eens dat het daarvoor en op die manier gebruikt werd maar toen ik het zag bedacht ik me dat dat makkelijker moest kunnen.

En naast alle emails die in vrolijke lettertypes geschreven zijn zat er ook nog content met b.v. courier lettertype tussen zodat je wat tabular data had die zonder styling toch mooi onder elkaar bleef staan.
Derhalve dat de opmaak intact moet blijven.

Iframe is daarom in dit geval perfect.
Koste me haast geen inspanning, behoud de opmaak perfect, voegt zelfs een beetje sandbox functionaliteit toe en houd de interface voor de gebruiker snel en simpel zonder veel klikwerk of vensters/tabbladen die voorbij vliegen.

Maar bedankt allemaal voor het meedenken.

[gitaarwerk]

Iframe is inderdaad beste oplossing. Het is niet vies als je inderdaad wilt sandboxen. Zoals RobIII zegt, is het hiervoor perfect. Gooi er een klein beetje JS / HTML tegenaan en laat je iframe uitvullen, en dan kan je al een hoop mail.

[R4gnax]

mookie schreef op woensdag 24 september 2014 @ 23:41:
Enige nadeel is dat ik een iframe praktisch niet goed dynamisch kan resizen in mijn eigen hoofd pagina.
Er bestaat geen volledige auto resize (height:auto ofzoiets) voor en truukjes met javascript ben ik niet zo weg van.

Och, window.parent.postMessage de gewijzigde hoogte meegeven en in je hoofdpagina het message event afvangen en verwerken is nou niet echt smerig hoor. Kan gewoon cross-origin en je kunt het zo inrichten dat je alleen berichten van een specifiek, veilig domein verwerkt wanneer je berichten ontvangt.