Javascript questions which don't deserve their own thread.

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.

biznatchio: Mar 31, 2001; Buglord

rotor posted:

yes the microsoft script editor, although "now" isn't really appropriate since it's been around since like 2004 or something

http://www.jonathanboutelle.com/mt/archives/2006/01/howto_debug_jav.html

The IE8 Developer Tools comes with a new debugger.

# ¿ Apr 23, 2009 03:37

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 09:55

biznatchio: Mar 31, 2001; Buglord

bobua posted:

was just really hoping having complete control of the browser would mitigate that. Guess not.

Having complete control of the browser does mitigate the problem, because you can always write and install a browser addin to allow printing to be scripted.

Having complete control of the browser means literally nothing if you're only talking about Javascript running on a webpage. The complete control part comes in all the stuff you can do outside the webpage's own sandbox.

See also Chrome's "--kiosk" and "--kiosk-printing" command line arguments. See here for more info.

biznatchio fucked around with this message at 01:13 on Dec 15, 2013

# ¿ Dec 15, 2013 01:09

biznatchio: Mar 31, 2001; Buglord

Fixed version: http://jsfiddle.net/LQMKn/

You need to declare the observable fields on the AppViewModel that you're binding to the value property of the textboxes so that the textboxes have somewhere to store the values entered into them; then in your addApp action read those observable fields' values (as plain strings) and pass them to your JobApp constructor (which then re-wraps the values as its own observable fields).

# ¿ Jan 23, 2014 06:40

biznatchio: Mar 31, 2001; Buglord

Remember when it was a big fad among Javascript 'developers' to not use semicolons because.... well, I guess because they wanted to be unique snowflakes?

That dumb movement died out awfully quickly.

# ¿ Sep 19, 2016 00:34

biznatchio: Mar 31, 2001; Buglord

Xom posted:

Is there a way to display an image at its actual resolution, ignoring the user's OS zoom and/or browser zoom, showing one image pixel per monitor pixel?

window.devicePixelRatio will give you the ratio of device pixels to CSS pixels. If you use that to scale the image's size, you can make it map image pixels directly to monitor pixels. Careful though, as the documentation mentions, this value can change (i.e., if the user moves the window between monitors of different DPI levels), and there's no event to tell you the value has changed.

# ¿ Mar 1, 2017 22:34

biznatchio: Mar 31, 2001; Buglord

Bruegels Fuckbooks posted:

Yeah, but the output image will still be scaled and have scaling artifacts unfortunately. It comes pretty close.

Not in my experience on desktop Google Chrome on a high DPI screen. I can't vouch for other browsers, but in that setup, if you use the devicePixelRatio to scale an image's size down via CSS to the proper screen size, it will display properly imagepixel-to-monitorpixel.

Example:

Raw Image:

Chrome on a High DPI display -- top image is a raw <img> element, bottom image sets CSS to the image's naturalWidth and naturalHeight divided by window.devicePixelRatio:

The scaled image is pixel perfect.

After zooming the browser to 110% and reloading, to make sure the devicePixelRatio wasn't a whole number:

The scaled image is still pixel perfect.

Code below:

code:

    <body>

        <div>Device Pixel Ratio: <span id="spnPixelRatio"></span>.
        <br>
        <br>
        Raw image: <img src="image.gif"/>
        <br>
        <br>
        Scaled image: <img src="image.gif" id="imgScaled"/>


        <script type="text/javascript">

        window.addEventListener("load", function () {
            var dpc = window.devicePixelRatio;

            document.getElementById("spnPixelRatio").innerText = dpc;

            var imgScaled = document.getElementById("imgScaled");
            imgScaled.style.width = (+imgScaled.naturalWidth / dpc) + "px";
            imgScaled.style.height = (+imgScaled.naturalHeight / dpc) + "px";
        });

        </script>
    </body>

edit: Also tried resizing by setting CSS zoom instead of width/height, the result also came out pixel perfect. Code:

code:

imgScaled.style.zoom = ((1 / dpc)*100) + "%";

biznatchio fucked around with this message at 11:23 on Mar 2, 2017

# ¿ Mar 2, 2017 11:06

biznatchio: Mar 31, 2001; Buglord

Canvas was where I originally noticed the behavior, actually. If the width and height attributes of the canvas are scaled by devicePixelRatio with respect to the element's DOM width and height, it'll also display pixel perfect.

# ¿ Mar 3, 2017 07:10

biznatchio: Mar 31, 2001; Buglord

netcat posted:

edit: one more google search reveals that there are problems when setting the canvas size via CSS since everything is drawn with a default size of 300x150. I'm setting the size to 100% with CSS so I guess this might be the problem. Guess I'll have to do a workaround.

There are two sizes you have to care about with canvas: the *canvas* size, which is specified via the canvas's width and height attributes/properties; and the *element* size, which is specified via CSS. If you want pixel-perfect rendering, make sure you set both properly, for instance:

code:

<canvas width="640" height="480" style="width: 640px; height: 480px;" />

code:

var c = document.createElement("canvas");
c.width = 640;
c.height = 480;
c.style.width = "640px";
c.style.height = "480px";

The situation gets a little more complicated if you want to take advantage of high DPI displays.

Oh, and when it comes to pixel-perfect drawing, take care that with some of the drawing primitives on a canvas you should offset your pixel coordinates by 0.5 because you want to specify the *center* of your target pixels rather than their corners.

# ¿ Jan 14, 2018 02:11

biznatchio: Mar 31, 2001; Buglord

Knifegrab posted:

Yeah I think I just shouldn't use async/await

The key is that you don't *have* to await on an async function call. Just move the self-contained bits you want to operate independently of each other into their own async functions, then fire them all off from a main function that doesn't await on any of them. For example, this kicks off three tasks that each have their own result handling; and all three tasks run concurrently and use await for their result handling.

# ¿ Sep 19, 2018 14:22

biznatchio: Mar 31, 2001; Buglord

Kraus posted:

Ah, yeah, that totally did it! Thanks!

What's funny, for golf purposes, these solutions are only better than the other depending on if you're counting spaces or not.

Ternary: 142 counting spaces, 132 not.

Or: 141 counting spaces, 133, not.

For real golf improvement you need to move some of the longer stuff out into variables and use a efficiently-named function to find elements, e.g.:

code:

d=document,q=d.querySelector.bind(d),para.className="yellow";q(".red")||(q("#success").style.display="block")

# ¿ Jan 30, 2019 03:16

biznatchio: Mar 31, 2001; Buglord

minato posted:

You don't even have to set style.display to anything, save 14 chars with
code:
(q("#success").style=0)

Huh, I didn't know that worked. Turns out you can do

code:

(q("#success").style++)

too. And since this eliminates the assignment operator, it also eliminates the need for the enclosing parenthesis resulting in another net loss of two more characters.

# ¿ Feb 2, 2019 06:30

biznatchio: Mar 31, 2001; Buglord

Jabor posted:

I mean, conceptually, I agree with the idea that modern CSS should be able to replace tables effectively. But then I see repeated failed attempts at replicating a pretty straightforward table-based layout and I get a bit suspicious as to whether it actually delivers on that idea.

I don't think I've ever seen a table that couldn't be replicated with CSS Grid, and trivially at that. But I'd be very curious to see an example to the contrary.

With the exception of borders. I don't think CSS has a good answer for what you can do with border-collapse on a table.

# ¿ Mar 10, 2021 16:59

biznatchio: Mar 31, 2001; Buglord

Combat Pretzel posted:

Also, is the Javascript Map just a flat key value store, or does it internally some hash map or binary tree things to aid performance?

Per the Javascript spec, Map must be implemented in some way to provide performance better than O(n) -- for instance, like a hashmap; but it doesn't specify *exactly* how it should be implemented to reach that goal:

quote:

Map object must be implemented using either hash tables or other mechanisms that, on average, provide access times that are sublinear on the number of elements in the collection. The data structures used in this Map objects specification is only intended to describe the required observable semantics of Map objects.

Map does have some other required behaviors that mean it's not just a hashmap under the covers (its required to retain the insertion order of items, for example); but regardless it should in all cases be better than abusing an object property list as a map instead.

biznatchio fucked around with this message at 16:19 on Mar 12, 2021

# ¿ Mar 12, 2021 16:16

biznatchio: Mar 31, 2001; Buglord

Doktor Avalanche posted:

would using the regular Date lib with only UTC avoid these kinds of mixups? that's what we do at my job.

In general yes... until someone does new Date('September 11, 2001') with the crazy expectation that it will act the same as new Date('2001-09-11').

The standard Javascript Date object is fundamentally flawed. The only advisable way to use it is delete globalThis.Date.

# ¿ Mar 20, 2024 07:20

biznatchio: Mar 31, 2001; Buglord

I would have answered a couple days ago but I was on the road, but this does what I think you were asking for. There's a resize handle on the blue container div to resize it to test the behavior.

# ¿ Apr 10, 2024 21:37

Adbot: ADBOT LOVES YOU

# ¿ Apr 29, 2024 09:55

biznatchio: Mar 31, 2001; Buglord

roomforthetuna posted:

Nice, thanks, that looks like it does the trick, even with nested grids involved. https://playcode.io/1831865

(Bit of weirdness in there, the chessboard-grid is somehow sometimes 1 pixel "down" relative to what should be its constraints. I guess the translate -50% operation does its math not quite the same as the left/top 50%, maybe resulting in rounding the other way.)

I do see that behavior at some zoom levels. It's a result of the layout calculations working on floating point pixels which get snapped to whole device pixels during rendering; and I don't think there's any good controls in CSS for avoiding it.

But it's easy enough to hack in some more precise custom layout logic instead; but it does require some Javascript.

edit: Or a more efficient, but more complex version.

biznatchio fucked around with this message at 04:08 on Apr 11, 2024

# ¿ Apr 11, 2024 03:26

The Something Awful Forums > Discussion > Serious Hardware/Software Crap > The Cavern of COBOL > Javascript questions which don't deserve their own thread.