31:T6af,md`There are three big takeaways in this article, and this is the first: \`w\` descriptors and \`sizes\` are used to determine *resource densities*. Essentially, they evaluate down to dynamic [\`x\` descriptors](https://cloudfour.com/thinks/responsive-images-101-part-3-srcset-display-density/) that know about the \`\`’s responsive layout width, and adjust themselves accordingly. Takeaway #2: once the browser has those resource densities, it does the same thing that it would if we’d used static \`x\` descriptors, to start with. Namely: ✨*whatever it wants.*✨

🤷

I’m serious! [The spec says](https://www.w3.org/TR/2017/REC-html52-20171214/semantics-embedded-content.html#ref-for-image-source%E2%91%A0) that, having figured out these resource densities, browsers are free to pick whichever resource they please, and sets no standard to coordinate behavior amongst them. So, given the same viewport size and screen density, Chrome, Safari, Firefox, and Edge may very well each pick a different resource out of a given \`srcset\`. And that’s *expected behavior*. Heck, usually, Chrome won’t even agree with *itself* if you wiggle the viewport size back and forth. Why‽ Because there’s no absolute way to determine which resource is “best” for a particular user in a specific situation. It depends™, and it could depend on a whole lot of things. Intentionally un-specified behavior lets browsers provide innovative answers to an open-ended question. Unspecified behavior also makes \`srcset\` impossible to test. So the very-important takeaway for this takeaway is: **always use [RespImageLint](https://github.com/ausi/respimagelint).** *Always*. `32:T42d,html`

${ md` ### Note: A couple of examples of how browsers do things differently, to illustrate: First: Chrome loves to pick already-cached resources. So if we’re on a 2x screen and have 1.5x, 3x, and 6x resources to choose from, and the 6x resource is *already in the cache* – Chrome’s gonna pick it, and avoid loading *anything at all* over the network. Second: while Safari and Firefox will often pick the *smallest resource that’s big enough* to cover the layout width, on high-DPI screens Chrome goes for the *closest resource*. So, on a 2x screen, if we have 1.8x and 3x resources to choose from, Chrome will pick the 1.8x, while Safari and Firefox will avoid upscaling at any cost, and pick the 3x. Bonus hypothetical example! In theory, browsers could pick differently depending on network conditions. So, on a crap connection (or near the end of a data plan), they could choose to grab the tiniest resource no matter what. Seems like a great idea, but it’s been around for years and no browser has tried it yet, so 🤷‍. `}

`33:T46f,md` YMMV, but for me (despite containing the number “640” no less than four times, and two different \`max-width\`s that mean different things 😟) this is much easier to explain and understand than the previous two examples. Set an extrinsic layout width using CSS. Capture it in \`sizes\`. Done.

🏁

Okay, *phew!* To review: 1. Under the hood, \`x\` descriptors and \`sizes\` are used to calculate dynamic *resource densities*. 2. Once they have those resource densities, browsers… do whatever they want. So, test responsive images using [RespImageLint](https://ausi.github.io/respimagelint/) rather than your probably-flawed expectations about which resource “should” be loading. 3. One side effect of the resource density thing is that \`sizes\` ends up setting the intrinsic width of your image. That’s weird. So, override it with an explicit, extrinsic \`width\`.

🎉 The end 👏

`34:Ta38,style = html``35:T406,images = ({ 'tiny.png': exampleImage('tiny.png', 300), 'small.png': exampleImage('small.png', 600), 'medium.png': exampleImage('medium.png', 900), 'large.png': exampleImage('large.png', 1200), 'huge.png': exampleImage('huge.png', 1500), 'gargantuan.png': exampleImage('gargantuan.png', 1800), 'fallback.png': exampleImage('the fallback', 600), 'wat.png': `https://eric-cloudinary-res.cloudinary.com/w_300,h_200,b_rgb:${ colors.green.replace( '#', '' ) }/l_text:Roboto_48:${ encodeURIComponent( 'wat' ) },co_rgb:000000B0/_.jpg`, 'king_hippo.png': 'https://eric-cloudinary-res.cloudinary.com/image/upload/c_crop,w_64,h_90,x_125,y_487/king-hippo.png', 'training_tiny.png': 'https://eric-cloudinary-res.cloudinary.com/image/upload/q_auto,w_320/punch_out_night_training.png', 'training_small.png': 'https://eric-cloudinary-res.cloudinary.com/image/upload/q_auto,w_480/punch_out_night_training.png', 'training.png': 'https://eric-cloudinary-res.cloudinary.com/image/upload/q_auto/punch_out_night_training.png' })36:T8d8,parseSizes = function( sizes, viewportWidth ) { // an exceedingly quick, dirty, and limited media condition + length parser // media conditions are only true if they're min-width or max-width // vh units are not supported (among other things) const calcRegex = /calc$(.+?)$/, mediaConditionRegex = /$.+?\:.+?$/, // just grab everything in parens that includes a colon widthConditionRegex = /$\s*([minax]{3})-width:\s*(\d+[a-zA-Z\%]+)\s*$/, // that was a doozy // groups we get out of this: // 1. 'min' or 'max' width? // 2. the length (e.g. '800px') lengthRegex = /(\d+[a-zA-Z\%]+)/; // groups we get out of this: // 1. the number of the length (e.g. '800px') let layoutWidth = viewportWidth; // to return, default is 100vw const pairs = sizes.split(','); for ( let pair of pairs ) { let mediaCondition = pair.match( mediaConditionRegex ), widthCondition = pair.match( widthConditionRegex ), conditionIs = false; if ( widthCondition ) { let minOrMaxWidth = widthCondition[1], breakpointLength = pxLength( widthCondition[2], viewportWidth ); if ( ( minOrMaxWidth === 'max' && viewportWidth <= breakpointLength ) || ( minOrMaxWidth === 'min' && viewportWidth >= breakpointLength ) ) { conditionIs = true; } } if ( ( mediaCondition && conditionIs === true ) || !mediaCondition ) { let length = pair.replace( mediaConditionRegex, '' ), // strip the media condition matchedLength = length.match( lengthRegex ), matchedCalc = length.match( calcRegex ); // console.log(length, matchedLength, matchedCalc); if ( matchedCalc ) { // if it's a calc layoutWidth = parseCalc( matchedCalc[1], viewportWidth ); } else if ( matchedLength ) { // if it's a simple length layoutWidth = pxLength( matchedLength[1], viewportWidth ); } // else leave it at the default, 100vw break; } } return layoutWidth; }37:[] 2f:{"title":"w descriptors and sizes: Under the hood","cells":[{"id":0,"value":"md`# w descriptors and sizes: Under the hood`","pinned":false,"hidden":false,"mode":"ojs"},{"id":662,"value":"md`Consider a responsive image:`","pinned":false,"hidden":false,"mode":"ojs"},{"id":1227,"value":"html`\n\n\n\n`","pinned":true,"hidden":false,"mode":"ojs"},{"id":1338,"value":"md`What’s going on there?\n\nIf you’re not familiar with \\`srcset\\`, \\`w\\` descriptors, and \\`sizes\\`, the best, shortest guide to what you should put where when you’re just trying to put a dang image on a dang website might be [this one, from Jake Archibald](https://jakearchibald.com/2015/anatomy-of-responsive-images/#varying-size-and-density). Go! Read it!\n\nIf you already know your way around the whats and the whys of this markup, you might not know exactly *how* browsers use it to load images responsively. The mechanics are interesting, and have some confounding side effects.\n\nSo, let’s walk through a concrete (and interactive!) example. First, we’ll need a \\`srcset\\`:\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":98,"value":"srcset=\"tiny.jpg 400w, small.jpg 800w, medium.jpg 1200w, large.jpg 1600w\" // 👈 psst, hey! you can edit this! and the green boxes below will update to reflect your changes.","pinned":true,"hidden":false,"mode":"ojs"},{"id":829,"value":"md`This gives the browser the URLs of the available resources, and their *resource widths*.`","pinned":false,"hidden":false,"mode":"ojs"},{"id":698,"value":"{\n const table = html`\n

\n \n \n

`,\n toprow = table.querySelector('tr.top'),\n bottomrow = table.querySelector('tr.bottom');\n \n for (const resource of parsedSrcset) {\n let box = makeBox( resource.width ),\n w = makeWidth( resource.width, 'w', 'resource' );\n box.appendChild( w );\n toprow.appendChild( html`${ resource.url }` );\n bottomrow.appendChild( td( box ) );\n }\n \n return table;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":1959,"value":"md`Next, a \\`sizes\\`:`","pinned":false,"hidden":false,"mode":"ojs"},{"id":9,"value":"sizes=\"(min-width: 800px) 800px, 100vw\" // 👈 edit me! edit! me!","pinned":true,"hidden":false,"mode":"ojs"},{"id":1492,"value":" md`Browsers take this \\`sizes\\` and [resolve it against the viewport width](https://cloudfour.com/thinks/responsive-images-101-part-5-sizes/#how-does-the-browser-select-the-correct-sizes-value), to get an estimate of the \\`\\`’s *layout width*. In our case, that’s:`","pinned":false,"hidden":false,"mode":"ojs"},{"id":1122,"value":"{ const browser = html`\n

\n`,\n viewportWidthRuler = makeWidth( viewportWidth ),\n layoutWidthRuler = makeWidth( parsedSizes, 'px', 'layout' ),\n container = html`

`;\n layoutWidthRuler.style.borderRight = layoutWidthRuler.style.borderLeft = `1.5px solid ${colors.darkyellow}`;\n viewportWidthRuler.style.color = 'gray';\n container.appendChild(browser);\n browser.appendChild(layoutWidthRuler);\n browser.appendChild(viewportWidthRuler);\n return container;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":471,"value":"viewof viewportWidth = {\n \n const min = 320,\n max = 3000,\n initial = 1200,\n form = html`\n`;\n \n const update = ( () => {\n form.value = parseInt( form.r.value );\n } );\n\n form.r.addEventListener('input', update);\n update();\n return form;\n}\n ","pinned":false,"hidden":false,"mode":"ojs"},{"id":824,"value":"md`\n*Fiddle with this viewport width (👆) and see how the resolved \\`sizes\\` changes in response.*\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":831,"value":"md`Okay! So, now we’ve given the browser:\n\n1. a bunch of resources (and their resource widths) in \\`srcset\\`\n2. the (approximate) layout width that it needs to fill, in \\`sizes\\`.\n\nThe browser divides each resource width by the layout-width-to-fill, in order to determine each resource’s *resource density*:`","pinned":false,"hidden":false,"mode":"ojs"},{"id":196,"value":"{ \n const w = document.createElement('div'),\n t = document.createElement('table');\n w.classList.add('tableWrapper');\n w.appendChild(t);\n t.appendChild( html`resource width from srcset÷layout width from sizes=resource density` );\n for (const resource of parsedSrcset) {\n t.appendChild( tr(resource, parsedSizes) );\n }\n return w;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":737,"value":"$31","pinned":false,"hidden":false,"mode":"ojs"},{"id":1134,"value":"$32","pinned":false,"hidden":false,"mode":"ojs"},{"id":1576,"value":"md`\nOkay. One last takeaway (buckle up, though; it’s a a doozy).\n\nEvery article about \\`sizes\\` tells you that \\`sizes\\` is “just” a hint to the browser, which is only there to give the browser a rough idea of the layout size of the image before layout is complete. And that is a true and helpful description of what \\`sizes\\` does, and what it’s for. But it doesn’t prepare you for the fact that sometimes, when you change the \\`sizes\\` value of an image…\n`\n","pinned":false,"hidden":false,"mode":"ojs"},{"id":1582,"value":"viewof changingSizes = { \n const form = html`

\n\n\n

`,\n output = form.querySelector('code'),\n update = () => {\n form.value = output.innerHTML = form.sizes.value + 'px';\n };\n form.sizes.addEventListener( 'input', update );\n update();\n return form;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":1613,"value":"md`…it *changes the layout width of that image‽*`","pinned":false,"hidden":false,"mode":"ojs"},{"id":1580,"value":"wat = promisedImg( html`\n\n

\n\n` )","pinned":true,"hidden":false,"mode":"ojs"},{"id":1902,"value":"{ const changingDensity = ( Math.round( 10000 * ( parseInt( changingSizes ) / 300 ) ) / 10000 ) + 'x';\n return md`\n\nThis doesn’t make any sense, *unless* you know the true nature of \\`w\\` descriptors and \\`sizes\\`, which is: they reduce down to dynamic \\`x\\` descriptors.\n\nWeb developers expect browsers to adjust the layout size of an image resource, based on its density. A 2x resource *should* display at twice-the-density aka half-the-width of a 1x resource, right? And so it does.\n\nThe same thing’s happening here. Above, \\`wat.png\\` has a resource density of \\`${ changingSizes } ÷ 300w = ${ changingDensity }\\`, so the browser treats it as having an [intrinsic width](https://www.w3.org/TR/css-sizing-3/#intrinsic) of \\`300 pixels × ${ changingDensity } = ${ changingSizes }\\`. In effect, when we set a \\`sizes\\`, we’re also setting the image’s intrinsic width. \\`sizes\\`, an attribute that’s just supposed to *capture* the \\`\\`’s layout size ends up *setting* it.\n\n`\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":2290,"value":"wat.naturalWidth // note! Safari has a bug (https://bugs.webkit.org/show_bug.cgi?id=150443)","pinned":true,"hidden":false,"mode":"ojs"},{"id":2640,"value":"wat.naturalWidth === parseInt( wat.getAttribute('sizes') ) // If you’re on Safari, please pretend that this returns `true`","pinned":true,"hidden":false,"mode":"ojs"},{"id":2288,"value":"md`\n\n

🤯

\n\nThis trips up almost everyone, because we’ve all become used to relying on browsers’ intrinsic-sizing mechanisms to ensure that images never look upscaled and blurry. [The first, best-practice way](https://alistapart.com/article/fluid-images#section2) to size images fluidly within a responsive design was: \n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2001,"value":"html``","pinned":true,"hidden":false,"mode":"ojs"},{"id":2005,"value":"md`\n\n\\`w\\` and \\`sizes\\` determine resource density, which affects intrinsic width. Images with a \\`max-width\\`, \\`srcset\\`, and \\`w\\` descriptors are going to be scaled to either their ([extrinsic](https://www.w3.org/TR/css-sizing-3/#extrinsic)) \\`max-width\\` or their (intrinsic) \\`sizes\\` width – whichever’s smaller.\n\nThis can be suprising!\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":1994,"value":"html`\n\n $\"Do$ \n\n`","pinned":true,"hidden":false,"mode":"ojs"},{"id":2018,"value":"md`\nSo! If you *don’t* want upscaled images – what should you do?\n\nOne option: do [what WordPress does](https://github.com/ResponsiveImagesCG/wp-tevko-responsive-images/issues/34), and bake a never-upscale constraint into the \\`sizes\\` value:\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2037,"value":"html`\n\n

\n\n`","pinned":true,"hidden":false,"mode":"ojs"},{"id":2042,"value":"md`\n\nWhile that certainly works, it feels weird to me. The complicated ways that \\`sizes\\` blurs the line between content and layout [are already pretty awful](https://www.youtube.com/watch?v=LRs3AqGdoq4). Intentionally using \\`sizes\\` to *set* an \\`\\`’s layout width – rather than just capture it – feels especially awful.\n\nA better option: our old friend, the \\`\\` attribute.\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2254,"value":"imgWithAWidthAttribute = promisedImg( html`\n\n

\n\n` )","pinned":true,"hidden":false,"mode":"ojs"},{"id":2490,"value":"md`\n\n\\`\\` is a holdover from the days of \\`\\` tags and \\`BGCOLOR\\` attributes, when presentational HTML was the only way to style. When browsers began implementing CSS, they needed to figure out how all of the old, presentational HTML would interact with newfangled CSS. The concept of a [presentational hint](https://www.w3.org/TR/CSS2/cascade.html#preshint) was born. Browsers treat presentational HTML like CSS with absolutely no specificity, so that it’ll be overriden by anything.\n\nLet’s break down what’s happening for our \\`imgWithAWidthAttribute\\` example, above. Because the \\`\\` has \\`sizes=\"100vw\"\\`, the loaded resource has an intrinsic width of:\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2325,"value":"imgWithAWidthAttribute.naturalWidth // Here I must again note that Safari has a bug, and will report “64” rather than whatever `100vw` is in `px` for you right now. https://bugs.webkit.org/show_bug.cgi?id=150443","pinned":true,"hidden":false,"mode":"ojs"},{"id":2500,"value":"md`\n\nThis intrinsic width is overriden by the \\`width=\"64\"\\` attribut, which is equivalent to a (zero-specificity) \\`width: 64px;\\` rule in CSS.\n\nAnd then, if and when the image’s parent container is smaller than its \\`width=\"64\"\\`, the \\`max-width: 100%;\\` rule kicks in and overrides everything.\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2667,"value":"html`\n\n $\"A$ presentational hints (like width=64) > sizes lengths (sizes=100vw) > the actual width of the PNG (64 pixels, to be exact), when it comes to sizing this image.\" />\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2665,"value":"md`\n\nThus, we get what we wanted: an image that’s fluid only when scaled below its actual width, and never up-scales. I should probably use a slightly wider image to demo that – so here, resize this and see for yourself:\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2556,"value":"html`

\n\n $\"Night.$ \n\n

`","pinned":true,"hidden":false,"mode":"ojs"},{"id":2588,"value":"md`\n\nOld dog, new tricks; \\`\\` works.\n\nI myself personally? I like to set an ironclad \\`img { width: 100%; }\\` and live with some occasional upscaling. A blurry image is often better than a tiny one – especially for users with less-than-perfect eyesight. On the rare occasion that I do find myself really needing to make sure that a certain image doesn’t grow to fill its parent, I’ll limit it with an inline \\`max-width\\` – and then capture everything in \\`sizes\\`. Like this:\n\n`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2113,"value":"html`\n\n\n\n $\"Night.$ \n\n`","pinned":true,"hidden":false,"mode":"ojs"},{"id":1128,"value":"$33","pinned":false,"hidden":false,"mode":"ojs"},{"id":2541,"value":"html``","pinned":false,"hidden":false,"mode":"ojs"},{"id":727,"value":"html`

`","pinned":false,"hidden":false,"mode":"ojs"},{"id":647,"value":"md`## behind the curtain`","pinned":false,"hidden":false,"mode":"ojs"},{"id":231,"value":"$34","pinned":false,"hidden":false,"mode":"ojs"},{"id":1701,"value":"md`### config`","pinned":false,"hidden":false,"mode":"ojs"},{"id":284,"value":"scaleFactor = (1/5)","pinned":false,"hidden":false,"mode":"ojs"},{"id":1177,"value":"colors = ({ yellow: 'rgb(100%,87%,60%)', darkyellow: '#ecb366', pink: '#ffccf0', blue: '#d3effe', darkblue: '#5bacde', green: '#d9fbe4', g:'d9fbe4', darkgreen: '#7ddb90' })","pinned":false,"hidden":false,"mode":"ojs"},{"id":1723,"value":"$35","pinned":false,"hidden":false,"mode":"ojs"},{"id":1703,"value":"md`### state`","pinned":false,"hidden":false,"mode":"ojs"},{"id":76,"value":"parsedSizes = parseSizes( sizes, viewportWidth )","pinned":false,"hidden":false,"mode":"ojs"},{"id":100,"value":"parsedSrcset = srcset\n .split(',')\n .map( (urlAndW) => {\n const split = urlAndW.trim().split(/\\s/);\n return { url: split[0], width: parseInt( split[1] ) };\n } )","pinned":false,"hidden":false,"mode":"ojs"},{"id":1712,"value":"md`### functions`","pinned":false,"hidden":false,"mode":"ojs"},{"id":2460,"value":"promisedImg = function( img ) {\n return new Promise( ( resolve, reject ) => {\n img.addEventListener( 'load', () => { resolve( img ); } );\n });\n} ","pinned":false,"hidden":false,"mode":"ojs"},{"id":1725,"value":"exampleImage = function( name, w, aspectRatio=(2/3) ) {\n const h = Math.round( w * aspectRatio );\n return `https://eric-cloudinary-res.cloudinary.com/w_${ w },h_${ h },b_rgb:${ colors.green.replace( '#', '' ) }/l_text:Roboto_32:${ encodeURIComponent('You got:') },co_rgb:00000080,y_-64/l_text:Roboto_32:${ encodeURIComponent( `(which is ${ w } × ${ h })` ) },co_rgb:00000080,y_64/l_text:Roboto_85:${ encodeURIComponent( name ) },co_rgb:000000B0/_.jpg`\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":1195,"value":"arrowBackground = function(foregroundColor = 'black', backgroundColor = 'white') { /* left cap, right cap, center line */\n return `url(\"data:image/svg+xml;utf8,\"), \n url(\"data:image/svg+xml;utf8,\"),\n url(\"data:image/svg+xml;utf8,\");`;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":282,"value":"makeWidth = function( w, unit='px', className='' ) {\n\treturn html`

${w}${unit}

`\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":203,"value":"makeBox = function( width, className = '', aspectRatio = (2/3) ) {\n const w = width * scaleFactor,\n h = w * aspectRatio;\n return html`

`;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":397,"value":"td = function( content ) {\n const td = document.createElement( 'td' );\n if ( content.constructor === String ) {\n td.innerHTML = content;\n } else {\n td.appendChild( content );\n }\n return td;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":123,"value":"tr = function( resource, target_width ) {\n let row = document.createElement('tr');\n const name = html`${ resource.url }`,\n// box = makeBox( resource.width ),\n resourceWidth = makeWidth( resource.width, 'w', 'resource' ),\n targetWidth = makeWidth( target_width, 'px', 'layout' ),\n density = ( Math.round( 1000 * ( resource.width / target_width ) ) / 1000 ).toString() + 'x';\n// row.appendChild( td( box ) );\n row.appendChild( td( name ) );\n row.appendChild( td( resourceWidth ) );\n row.appendChild( td('÷') );\n row.appendChild( td( targetWidth ) );\n row.appendChild( td('=') );\n row.appendChild( td( density ) );\n return row;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":1026,"value":"parseCalc = function( expression, viewportWidth ) {\n // this is horrible\n // for one, eval! eval!!!!\n // for two, is super-dumb about units, doesn't complain about incompatible units\n // also, probably one million more bad things\n // should I TODO making it recursive or NOT DOING IT AT ALL\n // or I could roll it into pxLength...hm\n let lengthRegex = /(\\d+)([a-zA-Z\\%]+)/g;\n // groups we get out of this:\n // 1. the number of the length (e.g. '800')\n // 2. the unit of the length (e.g., 'px')\n let matches = expression.match(lengthRegex);\n let result = expression;\n matches.forEach( (match) => result = result.replace( match, pxLength( match, viewportWidth ) ) );\n return eval(result); // oh shit?\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":876,"value":"$36","pinned":false,"hidden":false,"mode":"ojs"},{"id":918,"value":"// adapted from a function by Martin Auswöger\n// https://github.com/ausi/cq-prolyfill/blob/master/cq-prolyfill.js#L1037\n// under MIT license:\n// https://github.com/ausi/cq-prolyfill/blob/master/LICENSE\n//\npxLength = function ( value, viewportWidth ) {\n \n var LENGTH_REGEXP = /^(-?(?:\\d*\\.)?\\d+)(em|ex|ch|rem|vh|vw|vmin|vmax|px|mm|cm|in|pt|pc)$/i;\n\n var FIXED_UNIT_MAP = {\n\t\t'px': 1,\n\t\t'pt': 16 / 12,\n\t\t'pc': 16,\n\t\t'in': 96,\n\t\t'cm': 96 / 2.54,\n\t\t'mm': 96 / 25.4,\n 'em': 16,\n 'rem': 16,\n 'ch': 8,\n 'ex': 8\n\t};\n\n\tvar length = value.match(LENGTH_REGEXP);\n\tif (!length) {\n\t\treturn parseFloat(value);\n\t}\n\tvalue = parseFloat(length[1]);\n\tvar unit = length[2].toLowerCase();\n\tif (FIXED_UNIT_MAP[unit]) {\n\t\treturn value * FIXED_UNIT_MAP[unit];\n\t}\n\tif (unit === 'vw') {\n\t\treturn value * viewportWidth / 100;\n\t}\n\treturn value;\n}","pinned":false,"hidden":false,"mode":"ojs"},{"id":998,"value":"// doesn't actually help much\n// units = require('units-css@0.4.0/dist/units.min.js')\n\n// also found this cool thing which I'm not using https://github.com/albell/parse-sizes","pinned":true,"hidden":false,"mode":"ojs"}],"files":"$W37","stdlib":"1","titling":"auto"}