Display: block op een regel

[Verwijderd]

Beste,

Ik zit met een html probleempje dat maar niet wil lukken .

Ik heb de volgende html regels:
<b>Dirk:</b>  regel-1<br />
<b>Dirk:</b>  regel-2<br />
<b>Dirk:</b>  regel-3<br />
<b>Dirk:</b>  regel-4<br />

Nu kan men in deze tekstregels ook emoticons neerzetten. De html code van een willekeurige emoticon is: <span class="icons" id="icon_question"></span>

De daarbij behorende CSS code:
.icons {
display: block;
width: 15px;
height: 15px;
border: 0;
}

#icon_question {
background: url(../images/smilies/icon_question.gif) no-repeat top center;
}

Helaas komt dit blok niet op dezelfde regel, bijvoorbeeld:
<b>Dirk:</b>  regel
emoticon
-1<br />

Hoe krijg ik deze gegevens netjes op één regel?
Alvast bedankt!

[disjfa]

Geen display:block gebruiken! mischien gewoon plaatjes gebruiken voor smilies.

[Mayco]

display: block zorgt er toch net voor dat het op een nieuwe regel komt... je bedoeld display: inline..., maar standaard is dat bij images zo... gewoon wegdoen dus idd...

[Verwijderd]

Ik kan er wel display:inline van maken maar de span tag zelf is leeg en wordt dus 0x0px. Hierdoor wordt de achtergrond (smilie) dus niet meer getoond. Voor een span-tag kun je geen hoogte / breedte instellen dus dat is ook geen oplossing.

Een normale image tag is inderdaad makkelijker, echter cached Firefox deze images niet. De pagina wordt nogal vaak herladen (chat) waardoor dit niet praktisch is. CSS background-images cached Firefox wel goed :-).

Ik heb werkelijk van alles geprobeerd, van een tranparante 1x1px src tot aan de emoticons door middel van php met de juiste headers (cache-control: public) downloaden. Helaas lijkt een tag met een css-background de enige werkende manier, nu alleen de opmaak nog ;-).

[crisp]

cache-control: public is geen directive voor de client maar voor proxies en zegt verder niets over cachebaarheid zelf, daar moet je bijvoorbeeld max-age voor gebruiken (of Expires).

Los het probleem gewoon bij de bron op ipv dit soort workarounds...

[Kiphaas7]

offtopic:
is de <b> tag niet deprecated?

[Fuzzillogic]

Mayco schreef op woensdag 07 november 2007 @ 15:41:
display: block zorgt er toch net voor dat het op een nieuwe regel komt... je bedoeld display: inline..., maar standaard is dat bij images zo... gewoon wegdoen dus idd...

display: inline-block;

Maar dat werkt niet in.... Firefox! (Wel in IE, sort of, met wat gehack meen ik)

[Technicality]

Smileys/emoticons zij wezenlijke informatie en moet mijn inziens dan ook als zodanig behandeld worden: img-tag met een goede omschrijvende alt (zoals :) voor ).

[Verwijderd]

Display inline:block doet inderdaad precies wat ik bedoel, helaas werkt dit enkel in IE6 en IE7.

Aan "los het probleem bij de bron op" en "smileys zijn wezenlijke informatie" heb ik weinig, een chat waarbij bij iedere tekst regel de emoticons (in firefox) opnieuw worden geladen werkt gewoon niet fijn...

[Verwijderd]

is het niet gewoon makkelijker om de smileys in de front end te vervangen door de plaatjes? dus ongeparsed oversturen en bij de client vervangen met javascript oid?

[crisp]

Verwijderd schreef op woensdag 07 november 2007 @ 18:29:

Aan "los het probleem bij de bron op" en "smileys zijn wezenlijke informatie" heb ik weinig, een chat waarbij bij iedere tekst regel de emoticons (in firefox) opnieuw worden geladen werkt gewoon niet fijn...

Je probleem is dus dat je plaatjes niet gecached worden, maar in plaats van te gaan kijken waarom dat zo is ben je bezig met wazige work-arounds die zelf ook weer problemen opleveren...

[Mei]

Verwijderd schreef op woensdag 07 november 2007 @ 18:29:
Display inline:block doet inderdaad precies wat ik bedoel, helaas werkt dit enkel in IE6 en IE7.

Aan "los het probleem bij de bron op" en "smileys zijn wezenlijke informatie" heb ik weinig, een chat waarbij bij iedere tekst regel de emoticons (in firefox) opnieuw worden geladen werkt gewoon niet fijn...

With stupid^^ (Crisp dus)

Verder moet FF gewoon alles cachen. Ik denk dat jouw FF install dan toevallig wat anders dan normaal doet.

De handigste workaround was dan misschien nog wel het gebruiken van <img> tags geweest en ze dezelfde smiley als achter grond te geven. Dus <img src="smile.gif" style="background-image:url(smile.gif);" alt=":-)">. Maargoed, niet doen dus, gewoon ff kijken waarom jouw FF raar doet.

[Verwijderd]

@kage: bedankt voor je opmerking, dit wordt al clientside gedaan en dit lost het probleem niet op.

@crips / mei: firefox doet niet raar, de ajaxdata heeft de header no-cache waardoor de plaatjes dus niet gecaced worden. Een wordaround is dus vereist.

Bij <img src="smile.gif" style="background-image:url(smile.gif);" alt=":-)"> wordt smile.gif nog altijd geladen (door de src) waardoor je alsnog een knipperend effect hebt.

[Mei]

Ik ben nog niet zo ervaren met AJAX, maar kan je hem dan geen andere header meegeven? (lijkt me een logische oplossing...) Dan zal hij de rest van de data ook wel cachen...

Wat als je bij de client met JS alle afbeeldingen gaat vervangen? Je haalt ze dan gewoon via een harde HTTP request op. Extra mogelijkheid is dat smileys uitgezet kunnen worden als mensen ze niet willen zien.

Maar hoezo knipperen? De background-image en de src image worden gewoon over elkaar heen geladen.

Ik vraag me trouwens wel af wat die header met de afbeeldingen te maken hebt. Je stuurt de tekst met AJAX over naar de client, maar de afbeeldingen worden toch altijd met een ahrde HTTP request (of je nou gebruik maakt van JS om de smileys te parsen of niet) opgehaald, want dat gaat buiten AJAX om.

[Verwijderd]

Een andere header is geen oplossing, omdat de ajax data niet gecached mag worden. Als het een static pagina was, dan was er geen probleem. Maar de pagina wordt een x-aantal keer per minuut bijgewerkt, en de plaatjes worden dan (door de header) opnieuw geladen.

De enige wordaround hiervoor is met CSS, waar ik graag hulp bij zou hebben. De afweging waarom het zo moet heb ik allang gemaakt, toch bedankt ;-)

[crisp]

De request en de cachebaarheid van je Ajax data staat los van de requests en de cacheing headers van je images...
Ga eens in de weer met een HTTP sniffer en kijk eens naar de verschillende request en response headers...

[Coju]

display: inline-block; werkt niet in Firefox maar er is een work-around beschreven op http://www.alistapart.com/articles/prettyaccessibleforms Er is blijkbaar wel een Mozilla specifieke eigenschap die hetzelfde doet

[Verwijderd]

Verwijderd schreef op donderdag 08 november 2007 @ 09:37:
@crips / mei: firefox doet niet raar, de ajaxdata heeft de header no-cache waardoor de plaatjes dus niet gecaced worden. Een wordaround is dus vereist.

Ik neem aan dat het probleem dan bij IE ligt. Heb je misschien heeeel toevallig, de IE cache instellingen op "Every visit to page" staan?

[Verwijderd]

Mijn IE instellingen zijn default. Ik heb het probleem inmiddels opgelost door de smilies in een table tag (i.p.v. een span tag) te plaatsen en hier een css class aan te hangen.

Bedankt voor jullie inzet!

[Smoonshine]

Je kunt ook een display: block in combinatie met een float: left doen. De float zorgt ervoor dat de block elementen naast elkaar worden weergegeven. Dit loopt echter tot aan maximaal de breedte van de pagina, daarna worden de items op de volgende regel geplaatst.

[killercow]

Verwijderd schreef op donderdag 08 november 2007 @ 12:57:
Mijn IE instellingen zijn default. Ik heb het probleem inmiddels opgelost door de smilies in een table tag (i.p.v. een span tag) te plaatsen en hier een css class aan te hangen.

Bedankt voor jullie inzet!

Mag ik je feliciteren met de aller ranzigste web-oplossing sinds het ontstaan van cu2 profielen?

Naja, zelf weten, je komt vanzelf het volgende probleem tegen welk een direct resultaat is van deze bende.

[Castor385]

Is dit niet een kwestie van je webserver fatsoenlijk instellen?

[Verwijderd]

@Killercow: bedankt voor je nuttige inbreng, heb je ook een betere oplossing?

@Castor: nee, want de data zelf mag juist niet gecached worden :-).

[TeeDee]

Zoals reeds aangegeven: bekijk de headers eens?
Als de cacheing door Apache / IIS / Whatever goed verloopt zou je op je smile.gif netjes een 304 Not Modified moeten krijgen. Hierdoor zal elke browser het gifje uit de client-side cache halen.

Dus door nu met ranzigheid in de weer te gaan, (komt ie weer!) zou je het probleem bij de bron aan kunnen pakken.

[killercow]

Verwijderd schreef op donderdag 08 november 2007 @ 15:51:
@Killercow: bedankt voor je nuttige inbreng, heb je ook een betere oplossing?

@Castor: nee, want de data zelf mag juist niet gecached worden :-).

Tjah,

Volg de adviezen op die je gekregen hebt, Crisp ed zijn zogezegd grootheden wat webdev betreft, dus het lijkt misschien allemaal onzin wat ze zeggen, maar je kunt er meestal blind op varen dat ze geleik hebben.


Darnaast, heb je ajax wel helemaal begrepen?

De pagina wordt nogal vaak herladen (chat) waardoor dit niet praktisch is.

Want even later meld je dat ajax niet gecached mag worden, wat dus compleet 100% met het woord "herladen" botst.

[ Voor 21% gewijzigd door killercow op 08-11-2007 16:12 ]