substitute posted:

Everyone go view source on this poo poo. It's hilarious.

There's a hidden form field with a value that is over 100,000 columns.

Bastard posted:

Open DevTools, click on the gear icon, enable the "Disable cache (while DevTools is open)" option.

Chenghiz posted:

Work in an incognito tab. If you're working with offline web apps this is also nice for having a fresh cache for testing and development.

supermikhail posted:

I'm a moron.

substitute posted:

Everyone go view source on this poo poo. It's hilarious.

There's a hidden form field with a value that is over 100,000 columns.

supermikhail posted:

Chrome after a while stops reloading JavaScript and gets it from the cache which is annoying when I'm editing it (supposedly it's not just JavaScript, but this is what's annoying). How do you work this thing? (Right now I "Clear Browsing Data").

Munkeymon posted:

When dev tools is open, you can right-click on the reload button and select Empty Cache and Hard Reload

supermikhail posted:

Thank you!

kedo posted:

Hard reloads also have easy keyboard shortcuts in Chrome: Cmd + Shift + R on Mac, Ctrl + F5 on Windows.

Use shortcuts for everything if you're a real man.

Lexicon posted:

As a side project, I've decided to migrate my resume out of Apple Pages and into html - the idea being that I can version control it properly, etc. I'd like the CSS to roughly look like a paper resume at desktop device size, be appropriately responsive on mobile, and competently 'print to PDF' such that the resulting PDF looks like it came out of a word processor and not a web browser.

I know this is vague, but can anyone give me any pointers on getting started? The markup and responsive stuff will be easy enough, but I'm not sure how to tackle that third requirement.

Lexicon posted:

As a side project, I've decided to migrate my resume out of Apple Pages and into html - the idea being that I can version control it properly, etc. I'd like the CSS to roughly look like a paper resume at desktop device size, be appropriately responsive on mobile, and competently 'print to PDF' such that the resulting PDF looks like it came out of a word processor and not a web browser.

I know this is vague, but can anyone give me any pointers on getting started? The markup and responsive stuff will be easy enough, but I'm not sure how to tackle that third requirement.

Lumpy posted:

Make sure you have a 2nd stylesheet for media="print" and set sane pinter type sizes and hide stuff that doesn't make sense to print. Body copy at or near 11pt (note the points, not pixels for printers), headlines around 14-18pt, etc. Type should be larger on screen because it's read at about an outstretched arms length away, while print is read at "bent arm" length, so it's smaller. (An aside: this is why people use who 11/ 12 px type on the web should all be tarred and feathered.)

This is my print.css form my resume:

CSS code:

body { font-family:  palatino, georgia, serif;
   font-size: 12pt; width: 40em;  line-height: 1.4em;}
#header {display: none;}
#footer, #leftColumnWrapper { display:none;}
a {text-decoration: none;}
li { line-height: 1.4em; margin-bottom: 0.25em; 
    list-style-type: square; }
h1, h2 { font-family: helvetica; font-size: 14pt; color: #666;  }
h1 { font-size: 16pt;}

You can also try forcing page-breaks, but my experience is that it didn't work out so well. However, that was years ago, so things may be better now. Here's an article on the subject: http://css-tricks.com/almanac/properties/p/page-break/

Mister Chief posted:

Make a jsfiddle.

kedo posted:

Because your function name is different than what you're calling.

HTML code:

<td><input type="submit" name="Submit" value="Submit" onclick="returnvalidationForm();"/></td>

function validateForm()

Mister Chief posted:

lufty posted:

Thanks, it seems quite handy.
So I used jsfiddle to tidy it up, but the JScript still fails to check the forms?

EAT THE EGGS RICOLA posted:

... put it on jsfiddle, save it, and post a link so that we can look at it there.

lufty posted:

http://jsfiddle.net/X8q9L/

Fayez Butts posted:

It didn't work in your version. That's Helvetica Light.

Lumpy posted:

Exhibit A: validateForm()
Exhibit B: validationForm()

These things need to be the same.


Also, never, ever, ever, ever, ever put a RESET button on your form. People only click on those by mistake, and then will hate you and your site when the form empties out instead of submitting.

http://jsfiddle.net/Us486/1/


Once you fix that, you'll find out that the form submits no matter what. Look into the form's onsubmit handler, as that's what you need to use to prevent it from submitting based on client side validation.

lufty posted:

Why doesn't it recognise the fact that I've called the validateForm() function to check what is submitted?

lufty posted:

Why doesn't it recognise the fact that I've called the validateForm() function to check what is submitted?

Sulla-Marius 88 posted:

If I understand you correctly: because you don't replace the default event handler, you just add another one in. So on 'onclick' it processes your custom code, but it never blocks the original code (the 'process the form' code).

You can add an 'event' parameter to the function definition and then first thing inside it hit 'event.preventDefault()'.

And then if everything is okay you call the 'submit' on the form at the end of the javascript function.

Reality posted:

code:

<input type="submit" name="Submit" value="Submit" onclick="return validateForm()"/>

You forgot a "return" in your onclick

lufty posted:

solved, thanks anyway

edit:

wait now i can't submit anything

Sulla-Marius 88 posted:

e: Also w3schools is the worst website ever, from memory. For HTML/low-level javaascript stuff it might not be too bad because that's simple enough, but for PHP or anything else it's absolutely terrible, so be wary what you take from it.

kedo posted:

Indeed. http://www.w3fools.com/

e: Sadly this page used to be way longer as it detailed dozens of places where w3schools was providing incorrect information, but it appears they removed it. Still, w3schools is pretty terrible.

kedo posted:

Indeed. http://www.w3fools.com/

e: Sadly this page used to be way longer as it detailed dozens of places where w3schools was providing incorrect information, but it appears they removed it. Still, w3schools is pretty terrible.

ruden posted:

Reading about Angular and other JavaScript frameworks seems to indicate the current designs revolve around basically having your input/output exposed as an API and using Angular to pull in content, rather than have the server render a page for way request.

kedo posted:

Try playing around with antialiasing styles. For example:

CSS code:

font-smoothing: antialiased;

vs.

CSS code:

font-smoothing: subpixel-antialiased;

will make a huge difference. Your first screenshot is subpixel-antialiased. If you zoom in you'll see colored pixels on the sides of the letters. The second is grayscale antialiased.

This is what I tend to use for all my projects because I find that subpixel-antialiasing makes fonts weightier than they should be:

CSS code:

*, *:after, *:before {
	-webkit-font-smoothing:antialiased;
	-moz-font-smoothing:antialiased;
	-moz-osx-font-smoothing: grayscale;
	-o-font-smoothing:antialiased;
	font-smoothing:antialiased;
}

However if you want them to be thicker, add the "subpixel-" in there in front of all of 'em except the -moz-osx one. Firefox's default antialiasing on OS X is super-thick and looks like poo poo.