P5.js: scrollbars with full-window canvas

[Spongman]

demo: https://codepen.io/Spongman/pen/ZrGoQz

a simple way to do a full-screen canvas is adding

createCanvas(windowWidth, windowHeight);

in your setup, (eg, https://p5js.org/reference/#/p5/windowWidth, https://p5js.org/reference/#/p5/windowResized) and

html, body { padding: 0; margin: 0; }

to your css styles.

however this doesn't work properly and results in unwanted scrollbars.

the problem is that the canvas element is inline, and every browser/OS combo i have tried adds scrollbars to the page even though the canvas element itself doesn't extend outside the window.

in the demo above, pressing the mouse button on the canvas changes the display css style of the canvas to block: thus removing the scrollbars.

some possible solutions:

• add block to the inline style for all createCanvas-created canvas elements. could be a breaking change for sketches containing non-canvas elements.
• update the docs to indicate that in order to remove the scrollbars you _need_ to add a css style to ensure those canvas elements are block. maybe we should add a .p5canvas class to those elements to make it easy to distinguish them from other user-created canvas elements on the page?

[limzykenneth]

Adding block to the created canvases would be a breaking change but I don't think it will break existing pages using older versions of p5.js so I wouldn't say it's a big problem. However, I kinda prefer to update the docs about this and definitely add the custom class to the canvases just because the behaviour is a bit more "default", but I may be wrong, it may be more intuitive to have the canvases block anyway.

[Spongman]

Another solution would be to check in createCanvas if the width&height are >= the window dimensions, if so, set the display: block css attribute. I cannot think of any situations where this would break existing sketches.

[Spongman]

i added a PR (#2624) that does this. not sure about the best place to adjust the docs to explain this, though.

[limzykenneth]

Hmm...it feels like soemthing that needs to be informed as earlier as possible but it doesn't quite fit into the Getting Started pages.

[lmccart]

if the sketch by default took up the whole window, I'd feel it made sense to make it "just work" out of the box, by checking the width/height and add display:block. since the default size is 100x100, and the windowWidth/windowHeight is a user choice, I suggest we just note the info in the docs about the css modifications to make. this aligns with our goal of not doing too much css styling behind the scenes. I was recently thinking it would be nice to add a note about using createCanvas(windowWidth, windowHeight); for fullscreen to the reference entry for createCanvas(), so I think it could fit well to add in that same paragraph info about using display:block.

[lmccart]

I've added this info here which is linked to from the reference entry for createCanvas.

[Spongman]

so no fix for this then? that's a shame, as it seems like setting the display style when the user explicitly makes the canvas large enough isn't that intrusive, certainly no more so that setting the canvas's width & height attributes & styles. is there a specific use-case that a display: inline full-screen canvas is satisfying?

[lmccart]

It's more about trying to avoid setting styling properties behind the scenes, and instead teaching the user how things work so if they move beyond this library they will have the knowledge to transition to the rest of the web intuitively. I think putting the information about how to do this in the docs goes toward this goal, and also makes it easy enough for the user to implement themselves.

[Spongman]

ok, i can see that. the manual test examples will need fixing, errr.. manually.

do we still want to add a css className to the p5.js canvas so users can distinguish it from other canvases in the document? if they need to add a canvas { display: block; } style to fix this then that might affect other canvases.

[lmccart]

I think they can add a classname using the addClass() method if they want. if they have a fullscreen canvas already on the page, it's probably not the most common use case that there would be multiple of them.

[limzykenneth]

I agree that setting styling behind the scenes may not be the best idea as that feels a bit too magical.

However, I think adding a default class to all p5 created canvases should be considered, not entirely because of this fullscreen canvas problem but rather for cases where multiple p5 canvases are on screen. Instead of either targeting all canvas element (which can cause compatibility issues) or assigning each one of them the same class (which adds some redundancy to the user's code base), having this class for p5 canvases can remove that redundancy and help working with the canvases in either JS or CSS. The only potential problem this may have is conflict with existing style rule for say p5Canvas class but I'm not sure that is a class name that would be commonly used outside of p5.js itself?

[lmccart]

I think that sounds reasonable and easy to add, if someone wants to submit a PR for that please feel free.

[meiamsome]

I think in the case of a fullscreen sketch it would be more logical to suggest the CSS change that would fix the issue is to add overflow: hidden to the body element seeing as they have to have margin and padding rules anyway:

html, body {
  margin: 0;
  padding: 0;
  overflow: hidden;
}

[Spongman]

i think

canvas {
  display: block;
}

is probably a more preferrable solution to this exact problem than

html, body {
  overflow: hidden;
}

since it specifically addresses the additional space added around the inline/inline-block element. but it's really a toss-up. this extra space around inline-block elements has been hounding web devs for years now, and there are countless solutions, none of which are really satisfactory in this situation.

i think, however, it's important for the default behavior to be success. i think it's useful to ask, in cases like these, what is the user's intent. for example, in this case, when they write createCanvas(windowWidth, windowHeight), are they more likely to be wanting a full-window, inline canvas with scrollbars so they can scroll to additional elements on the page? or do they intend for the canvas to be the only thing on the page? which is more common? which is the case that we should be optimizing usability for?

[chrisallick]

/* (reset) */
html,body,div,span,applet,object,iframe,h1,h2,h3,h4,h5,h6,p,blockquote,pre,a,abbr,acronym,address,big,cite,code,del,dfn,em,img,ins,kbd,q,s,samp,small,strike,strong,sub,sup,tt,var,b,u,i,center,dl,dt,dd,ol,ul,li,fieldset,form,label,legend,table,caption,tbody,tfoot,thead,tr,th,td,article,aside,canvas,details,embed,figure,figcaption,footer,header,hgroup,menu,nav,output,ruby,section,summary,time,mark,audio,video{ margin:0;   padding:0;  border:0;   font-size:100%; font:inherit;   vertical-align:baseline;}/*HTML5 display-role reset for older browsers */article,aside,details,figcaption,figure,footer,header,hgroup,menu,nav,section{display:block;}body{line-height:1;}ol,ul{list-style:none;}blockquote,q{  quotes:none;}blockquote:before,blockquote:after,q:before,q:after{   content:''; content:none;}table{    border-collapse:collapse;   border-spacing:0;}
a { text-decoration: none; color: #000000; }
input, textarea { margin: 0; padding: 0; }

html, body { width: 100%; height: 100%; }

canvas { display: block; }

/* clear */
.clear:after {
    content: "."; 
    display: block; 
    height: 0; 
    clear: both; 
    visibility: hidden;
}
.clear {display: inline-block;}
* html .clear {height: 1%;}
.clear {display: block;}

[timhae]

Sorry for the necrobump, I just wanted to mention that html, body { padding: 0; margin: 0; } should also be included in the wiki.

[lmccart]

@timhae would be you be up for editing it directly with what you had in mind? I can give you edit access