[plaatjes] breedte + hoogte opslaan in HTML van de post

[drm]

Ik heb niet erg goed gezocht, dus 't kan zijn dat deze al 's voorbij gekomen is.

Kan het geregeld worden dat van de plaatjes die in posts gezet worden even de hoogte en evt. de breedte ingelezen kan worden en opgeslagen in de html? Of dat er desnoods een default height meegegeven wordt als die niet in de RML meegegeven wordt? Ik kan me voorstellen dat dat eerste teveel verkeer gaat genereren, maar aan de andere kant hoeft 't alleen maar bij het posten van een bericht, en als er geen width en height opgegeven zijn

Het is namelijk om er gillend gek van te worden dat browsers al voor het renderen van een hele pagina naar een #anchor springen. Dat betekent dus dat je de anchor weer kwijt raakt als de plaatjes ingeladen worden die niet een hoogte meegekregen hebben in de HTML. Soms zoek je je dan echt helemaal de ***** naar een post terwijl die post-linkjes er natuurlijk niet voor niets zijn

[Erkens]

mja, ik denk dat zoiets een flinke serverload/traffic gaat veroorzaken.
Wat ik altijd doe in zo'n geval, ik wacht tot alles geladen is en ik druk op enter in de adres balk. zo springt hij naar de #anchor

[ACM]

Ik ga geen support inbouwen waarbij de plaatjes van gebruikers gecontroleerd worden op de grootte of iets van dien aard.
Dat levert idd nogal wat ongewenste serverload/traffic op en zeker als iemand een behoorlijk aantal erg grote plaatjes opgeeft een goede kans dat de complete posting niet verwerkt zal worden (of dat zal zo lijken, waarna de gebruiker tig keer op f5 ramt om het alsnog voor elkaar te krijgen...).

Een workaround is gewoon te wachten tot die pagina is ingeladen en dan in de adresbalk op enter te rammen, voor een "cached-reload".

[ Voor 15% gewijzigd door ACM op 06-08-2003 17:56 ]

[drm]

ACM:
Ik ga geen support inbouwen waarbij de plaatjes van gebruikers gecontroleerd worden op de grootte of iets van dien aard.

Daar was ik al bang voor

Dat levert idd nogal wat ongewenste serverload/traffic op en zeker als iemand een behoorlijk aantal erg grote plaatjes opgeeft een goede kans dat de complete posting niet verwerkt zal worden (of dat zal zo lijken, waarna de gebruiker tig keer op f5 ramt om het alsnog voor elkaar te krijgen...).

Indeed.

Een workaround is gewoon te wachten tot die pagina is ingeladen en dan in de adresbalk op enter te rammen, voor een "cached-reload".

Jep, maar wel vervelend

Misschien is het wat om een hoogte en een breedte bij een [img] tag voortaan te verplichten? Dat hij gewoon niet geparsed wordt als er geen hoogte- en breedte in staan, bijvoorbeeld?

Of een andere oplossing: (istie weer met z'n javascript)

JavaScript:

function reposition () {
   if ( location.hash.length > 1 && document.anchors ) {
      var anchorName = location.hash.replace('#', '');
      for ( a in document.anchors ) {
         if ( 
            document.anchors[a].name 
            && document.anchors[a].name == anchorName 
         ) {
            document.anchors[a].scrollIntoView ();
            return;
         }
      }
   }
}

Even wat geprutst, maar dit lijkt aardig te werken als je het in de onload van de body zet. De onload wordt pas aangeroepen als alle plaatjes geladen en gerenderd zijn. Het enige nadeel van de scrollIntoView () method is dat als er een horizontale scrollbar aanwezig is, hij de anchor ook horizontaal "into view" scrollt. Maar over het algemeen moet dat niet een heel probleem zijn, want in de meeste gevallen heb je geen horizontale scrollbar

[Verwijderd]

Je hoeft toch maar eenmalig de code te checken of er een height/width tag gebruikt wordt? (bij send/edit message). Eenmaal gezet hoeft er niet opnieuw gekeken te worden. En anders een fixed size van 60x40 opgeven voor tags die geen size gedefineert hebben - dat straft luie gebruikers vanzelf wel af

[ Voor 5% gewijzigd door Verwijderd op 07-08-2003 10:58 ]

[Erkens]

Verwijderd schreef op 07 August 2003 @ 10:56:
Je hoeft toch maar eenmalig de code te checken of er een height/width tag gebruikt wordt? Eenmaal gezet hoeft er niet opnieuw gekeken te worden. En anders een fixed size van 60x40 opgeven voor tags die geen size gedefineert hebben - dat straft luie gebruikers vanzelf wel af

nadeel hiervan is dat de users die dat topic willen lezen, een hoge proc. load krijgen omdat alle images verkleint moeten worden....

[drm]

Erkens:
nadeel hiervan is dat de users die dat topic willen lezen, een hoge proc. load krijgen omdat alle images verkleint moeten worden....

Ik kan me niet voorstellen dat die load veel hoger is dan het opnieuw renderen van een pagina omdat een plaatje niet past in zijn gereserveerde ruimte (wat doorgaans iets van 24x24 is als de hoogte en breedte niet opgegeven zijn).

Anyhoet: ACM zegt al niet te gaan beginnen aan hogere serverloads/meer traffic, dus da's makkelijk. Als er animo is om dat javascript dingetje in de templates te zetten, gaarne, en anders is het gewoon jammer.

[Verwijderd]

Erkens: Nope, wat jij bedoelt is de browser renderer die een hoge load geeft als je een 1600x1200 plaatje in een [ img = 600x400 ] tag plet... Ik bedoel iets anders, namelijk de width/height bij posten checken en in de [ img = x , y] tag zetten. Hierdoor wordt er juist niet resized en is het renderen juist sneller en de load lager.

Als je doelt op de 60x40 resizing: users hebben snel door dat ze dat niet bedoelen, en gaan het gauw veranderen - het is in ieder geval groot genoeg om te zien of de plaatjes het doen..


check de load van deze downsize rendering...

edit: waarom zouden gebruikers die gewoon een pagina willen lezen / snel bladeren een pagina 2x laden met wachttijd en workarounds gebruiken omdat anderen 'te lui zijn' om tags te zetten? Je kan het nl. ook omdraaien je stelling ACM... Bovendien heb ik al aangegeven dat er maar 1x naar de image heightxwidth gekeken hoeft te worden: bij POST'en van het bericht... Maar als de #anchor link opgelost kan worden met een javascript workaround ben ik wat dát betreft tevreden

[ Voor 71% gewijzigd door Verwijderd op 07-08-2003 11:23 ]

[ACM]

Waarom zou ik 'gestraft' moeten worden als ik een plaatje van 200x100 neerzet zonder de [img=, omdat ie toch wel past?

Ik vind dat toch net even iets _te_ erg ten koste van de gebruikersvriendelijkheid gaan, waar zoals zo vaak de goeden onder de kwaden moeten lijden.

Dat javascriptje is opzich wel leuk, is dat browser-"onafhankelijk"?

[ Voor 12% gewijzigd door ACM op 07-08-2003 11:12 ]

[drm]

ACM:
Dat javascriptje is opzich wel leuk, is dat browser-"onafhankelijk"?

Geen idee, ik heb niets getest, behalve IE en Mozilla. Maar daarvan weet ik wat ze ondersteunen, van andere browsers niet. Ik vermoed dat Opera 't keurig zou doen, en misschien ns4 zelfs nog wel. Bij NS4 zou eventueel de scrollIntoView() method niet bestaan.

Eventueel nog wat checks inbouwen zodat hij alles "heeft" wat hij nodig heeft:

JavaScript:

function reposition () {
   if ( 
      location.hash 
      && location.hash.length > 1 
      && document.anchors 
      && document.anchors.length 
   ) {
      var anchorName = location.hash.replace('#', '');
      for ( a in document.anchors ) {
         if ( 
            document.anchors[a].name 
            && document.anchors[a].name == anchorName 
         ) {
            if ( document.anchors[a].scrollIntoView ) {
               document.anchors[a].scrollIntoView ();
            }
            return;
         }
      }
   }
}

[crisp]

dat kan met javascript, vooralsnog hebben we besloten dat soort zaken niet te doen @ GoT