Check alle échte Black Friday-deals Ook zo moe van nepaanbiedingen? Wij laten alleen échte deals zien

breedte's text / codeblock whoa's

Pagina: 1
Acties:
  • 27 views sinds 30-01-2008

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Deze posting:
[rml]EfBe in "[ SqlServer] welke columns bij resultset "[/rml]

Als ik die edit en ik klik 'bekijk bericht', dan is de text boven het codeblock en onder het codeblock niet even breed als het codeblock, maar gewoon even breed als elke posting zou moeten zijn. Echter na het posten van het bericht is dit niet meer zo en is de tekst boven en onder het codeblock even breed als het codeblock, wat de leesbaarheid niet bevorderd.

Ik heb hier al eerder over geklaagd, dat kon toen niet worden opgelost oid, maar wat ik me nu afvraag: waarom werkt het WEL bij de preview maar wordt dit weer de nek om gedraaid bij de final result? Is toch jammer, want het preview result is wat je wilt, niet het result wat nu als resultaat wordt opgeleverd.

Bug?

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Dat is vreemd...

In mozilla gebeurt het wel "goed" (in jouw ogen fout dus ;) ) maar in IE gaat het idd "fout"...
Ik geloof dat het een bug is dat het in IE "fout" gaat, maar zou werkelijk niet weten waarom :)

Er is trouwens wel een oplossing bedacht voor de te brede code-tags, het is alleen enigszins bewerkelijk het in te bouwen en was daardoor kwa prioriteit wat lager dan andere zaken die gedaan moesten worden.
Ik was nog van plan je het resultaat te sturen als het eenmaal af is, maar ben er nog nauwelijks aan toe gekomen :)

  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Ah, ik snap waar het aan ligt.
Dat is idd iets dat IE netter doet dan Mozilla zelfs.

Bij de edit/view message staat er en breedte in pixels opgegeven, Mozilla negeert dat voor de tekst als de tabel te breed wordt, IE niet.

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Ik snap niets van je antwoord. :)

In de preview werkt het wel, in de uiteindelijke view werkt het niet. Nu maak ik al heel wat jaren software, en ik ben dan geneigd te denken: de code in preview is anders dan in de final view. Aangezien de preview WEL de juiste resultaten oplevert en de uiteindelijke message in de thread NIET, is het dan niet zo dat de code die de preview regelt ANDERS is en wellicht de code die de uiteindelijke message in de thread verzorgt zou moeten vervangen?

je verhaal over dat het bewerkelijk is e.d. is dan ook wat verwarrend, want in de preview werkt het gewoon: de tekst is gewoon normale breedte en de spullen tussen de codetags zijn veel breder. Zo zou het moeten zijn. Echter deze 'view' is weer volkomen fucked up als je de op 'verstuur bericht' klikt, die kennelijk iets anders doet met de tekst en de html die daaruit rolt niet vergelijkbaar is met de html die rolt uit 'bekijk bericht'. Omdat de html die geleverd wordt door 'bekijk bericht' de html is die je wilt, snap ik niet waarom de knop 'verstuur bericht' dan iets anders doet en dat moeilijk te realiseren is, preview doet het nl. al.

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com


  • ACM
  • Registratie: Januari 2000
  • Niet online

ACM

Software Architect

Werkt hier

Right, ik snap ook niet heel veel van jouw opmerking nou :P

- De html-code van de message is in beide gevallen exact hetzelfde.
- Het enige wat idd verschilt in de twee gevallen is een stukje html-code om de message, dat alleen in IE dat verschil toont, in andere browsers niet.
- De ene zegt "width='100%'" voor een veld van een tabel, terwijl het veld een niveau hoger al de breedte 610px heeft gekregen. De andere zegt width='610px', ondanks dat het niveau erboven al op 610px staat.
IE toont die tweede dus anders, het beperkt de breedte van de tekst tot die 610px en de rest niet. Andere browsers vullen gewoon de tabel op zo breed als nodig en negeren de tekstbreedte apart te houden.

Welke van de twee volgens de specificatie is weet ik niet, maar wij willen graag oplossingen die in vrijwel alle gevallen werken ipv in een groot deel.
Daar hebben we ondertussen een oplossing voor, die in de ogen van een aantal mensen (mij inclusief) zelfs netter/eleganter is. :)
Echter is _die_ oplossing redelijk bewerkelijk.

Domweg die width=100% in width=610px veranderen is natuurlijk relatief simpel, maar lost het probleem maar deels op.

Hoe vaak je dus ook op edit/submit drukt, de html-code van de message zelf wordt er niet door verpest ofzo.

  • EfBe
  • Registratie: Januari 2000
  • Niet online
Maar als die HTML gelijk is voor preview als final, hoe kan het dan dat de message totaal verschillend wordt weergegeven? DAT snap ik dus niet. Ik heb het niet over andere browsers, ik gebruik dezelfde browser, IE6, voor zowel preview als final, en preview verschilt enorm met final (preview good, final bad :P).

Uit jouw verhaal maak ik op dat de html die de message html embed in de final view de handel vernaggeld? Wat raar zou zijn, want preview gebruikt hetzelfde raamwerk om de message heen, zo lijkt het.

Mijn vraag is dus: waarom kan hetgeen werkt in preview niet gebruikt worden voor de final versie? Iedereen toch blij?

Creator of: LLBLGen Pro | Camera mods for games
Photography portfolio: https://fransbouma.com

Pagina: 1

Dit topic is gesloten.