Scrollbar Iframe buiten iframe plaatsen

[Sgrovert]

Ik ben op zoek naar een manier om de (verticale) scrollbar van een iframe buiten het iframe te plaatsen.
Dit omdat het iframe precies evenbreed is als de content die erin staat. Op het moment dat de content echter langer is dan de lengte van het iframe, zet de browser er een scrolbar naast, waardoor de breedte van het iframe afneemt en de content niet meer past.

Is er een mogelijkheid om de scrollbar van de iframe rechts naast het iframe te plaatsen ipv erin?

[NMe]

Nee. Je zal ofwel het iframe breder moeten maken, ofwel de pagina die je inlaadt geen vaste breedte moeten geven maar bijvoorbeeld 100%.

[_Thanatos_]

Over het algemeen is het toch wel verstanding om dingen schaalbaar te maken. Je weet immers niet war voor scherm je bezoeker heeft. Als bouwer van een iframe weet je ook niet hoe breed de implementer(-website) is.

Je kunt trouwens wel de breedte van de scrollbar bij de breedte van de body optellen met dit:

Cascading Stylesheet:

body{
  margin-right: calc(100% - 100vw);
]

Maar dat is vast niet wat je wilt

[Onoffon]

Is het niet niet een idee om de standaard scrollbar te verbergen via de functie 'overflow' in CSS en dan een custom scrollbar toe te voegen?

[R4gnax]

_Thanatos_ schreef op woensdag 25 maart 2015 @ 17:28:
Je kunt trouwens wel de breedte van de scrollbar bij de breedte van de body optellen met dit:

Cascading Stylesheet:

body{
  margin-right: calc(100% - 100vw);
]

Dat werkt alleen als de overflow instelling op 'scroll' staat en niet op 'auto'. De breedte v/e 'auto' scrollbar telt volgens de specificatie mee voor de breedte v/h containing block waar de vw unit op gebaseerd is en wordt er expliciet niet vanaf getrokken.

Zie: http://www.w3.org/TR/css3-values/#viewport-relative-lengths

Onoffon schreef op donderdag 26 maart 2015 @ 13:09:
Is het niet niet een idee om de standaard scrollbar te verbergen via de functie 'overflow' in CSS en dan een custom scrollbar toe te voegen?

Alleen als je de standaard scroll compleet om zeep wilt helpen. Goede manier om de UX van je website te kelen.

[ Voor 30% gewijzigd door R4gnax op 26-03-2015 22:23 ]

[Onoffon]

Ik zei niet dat het een goed idee was...

Het is m.i. afhankelijk per situatie, het hoeft niet per definitie slecht te zijn.

[R4gnax]

Onoffon schreef op dinsdag 31 maart 2015 @ 14:19:
Het is m.i. afhankelijk per situatie, het hoeft niet per definitie slecht te zijn.

Je kunt het nooit 100% dekkend krijgen en het is onmogelijk om 100% de native functionaliteit na te bootsen voor alle platformen. Daarmee is het in de praktijk, voor een zo belangrijk UI component als het scrollen v/e venster eigenlijk wel per definitie slecht.

Waar jij op doelt is dat het alternatief gewoon nog slechter is.

[ Voor 7% gewijzigd door R4gnax op 31-03-2015 20:08 ]

[_Thanatos_]

R4gnax schreef op donderdag 26 maart 2015 @ 22:20:
[...]


Dat werkt alleen als de overflow instelling op 'scroll' staat en niet op 'auto'. De breedte v/e 'auto' scrollbar telt volgens de specificatie mee voor de breedte v/h containing block waar de vw unit op gebaseerd is en wordt er expliciet niet vanaf getrokken.

Ik heb een soortgelijke truuk al gebruikt om een site niet te laten "verspringen" tussen pagina's met en zonder scrollbar. 100% is nml 100% van de breedte van de body (exclusief scrollbar), en 100vw is 100% van de breedte van de viewport (inclusief scrollbar). Dus met het verschil tussen die twee units kun je aan de breedte van de scrollbar komen, zonder allerlei javascript-gerommel. Werkt altijd (want css) en dynamisch (want css), alleen niet op legacy browsers.

Just so you know

[Onoffon]

R4gnax schreef op dinsdag 31 maart 2015 @ 20:07:
[...]

Je kunt het nooit 100% dekkend krijgen en het is onmogelijk om 100% de native functionaliteit na te bootsen voor alle platformen. Daarmee is het in de praktijk, voor een zo belangrijk UI component als het scrollen v/e venster eigenlijk wel per definitie slecht.

Waar jij op doelt is dat het alternatief gewoon nog slechter is.

De TS is op zoek naar en ik quote: 'een manier om de (verticale) scrollbar van een iframe buiten het iframe te plaatsen', niet om 100% de native functionaliteit na te bootsen. Ik dacht juist dat javscript platformen zoals jquery cross-browser compatible waren?

Ik denk namelijk dat het wel kan om in elke browser een soort gelijke functionaliteit na te bouwen. Maar nogmaals zeg ik niet direct dat dit DE oplossing is, ik vind alleen dat je best buiten je kader mag denken i.p.v direct te zeggen dat het niet kan.

[R4gnax]

Onoffon schreef op woensdag 01 april 2015 @ 13:54:
[...]


De TS is op zoek naar en ik quote: 'een manier om de (verticale) scrollbar van een iframe buiten het iframe te plaatsen', niet om 100% de native functionaliteit na te bootsen. Ik dacht juist dat javscript platformen zoals jquery cross-browser compatible waren?

Ik denk namelijk dat het wel kan om in elke browser een soort gelijke functionaliteit na te bouwen. Maar nogmaals zeg ik niet direct dat dit DE oplossing is, ik vind alleen dat je best buiten je kader mag denken i.p.v direct te zeggen dat het niet kan.

jQuery is niet een platform. Het is een library die van de DOM APIs abstraheert en een in alle browsers min-of-meer gelijk werkende subset aanbiedt via een versimpelde API. Het trekt niet de verschillende mechanismen die in de browser zelf ingebakken zitten gelijk en het biedt je ook niet de mogelijkheid om deze verschillende instellingen uit te lezen.

Exact het scroll momentum cq. de scrollsnelheid cq. welke andere browser- of OS-afhankelijke constante of variable uitlezen om deze daarna te gebruiken voor een gekloonde scrollbar functionaliteit is simpelweg niet mogelijk.

Één van de allerbelangrijkste kernpunten van goede UX is dat je niet sodemietert met de bestaande verwachtingspatronen van een gebruiker. Daaronder valt dus ook hoe de scrollbalk reageert: hoe snel hoor je te scrollen als je het muiswiel gebruikt (belangrijk ivm overshoot en muscle memory); hoeveel momentum hoort een scroll te hebben (belangrijk zodat een gebruiker op tijd los laat, niet te hard een zwiep geeft, usw); hoort de browser v/d gebruiker überhaupt scroll-momentum te hebben. (desktop browsers hebben dat meestal niet en dat 'uitdrijven' is daar uitermate storend); etc. etc.

[ Voor 3% gewijzigd door R4gnax op 01-04-2015 15:02 ]

[Onoffon]

http://www.jqueryrain.com...crollbar-plugin-examples/

[R4gnax]

Onoffon schreef op donderdag 02 april 2015 @ 09:52:
http://www.jqueryrain.com...crollbar-plugin-examples/

En hiermee probeer je exact wat te bewijzen? Dat er een overvloed aan mensen is die allemaal hetzelfde slechte idee geimplementeerd hebben zonder over de usability na te denken?

[Onoffon]

Nee,

Dat de usability exact hetzelfde kan zijn als een normale scrollbar, zoals sommige voorbeelden laten zien.

Welk verschil behalve de lay-out zie jij tussen een jquery scrollbar en een browser scrollbar?

Toegegeven, er zitten tussen de voorbeelden een hoop die niet dezelfde usability hebben, maar ook zat die dit wel hebben, zoals:

http://www.simonbattersby...llbar_demo_13_anchors.htm

[ Voor 63% gewijzigd door Onoffon op 03-04-2015 10:02 ]

[R4gnax]

Onoffon schreef op vrijdag 03 april 2015 @ 09:57:
Toegegeven, er zitten tussen de voorbeelden een hoop die niet dezelfde usability hebben, maar ook zat die dit wel hebben, zoals:

http://www.simonbattersby...llbar_demo_13_anchors.htm

Bedankt voor het concrete tegenvoorbeeld.

De viewport scrollt daar namelijk niet vloeiend per pixel zoals normale viewports dat doen als je in Firefox de 'smooth scrolling' optie aan hebt staan (wat v.z.i.w. al sinds tijden de standaard is).

In plaats daarvan krijg je een 'spring X pixels per tik van het muiswiel' gedrag wat ongeveer (maar beslist niet exact) overeen komt met het niet-vloeiende stepped scrolling, want dat gedrag is in Windows namelijk geijkt op een aantal tekstregels hoogte wat onderhevig is aan zowel de em-grootte van de tekst als de DPI van het scherm en de gekozen scale factor.

Deze implementatie houdt er verder geen rekening mee dat de standaard stapgrootte in het Windows OS ingesteld kan zijn op een ander aantal witregels dan de standaard 3, waardoor de gekozen stapgroottte in pixels nog veel verder kan gaan afwijken van de standaard die een gebruiker zou verwachten.


Overigens is het niet mogelijk om juist deze gegevens uit te lezen via de browser, dus je kunt er gewoon nooit op anticiperen.

[ Voor 7% gewijzigd door R4gnax op 08-04-2015 17:54 ]

[n8n]

Scroll-hijacking is 1 van de meest evil design patterns in de hele applicatie-industrie. Doe het niet, nooit niet.