Hi ralphc-nyc, the way I do it is to determine the width of individual elements by working forward from wireframe sketches. I work out the scale of the wireframes themselves based on user research about the types of devices the audience prominently uses, and then I design for an appropriate range between any necessary breakpoints. Noting their devices during interviews or site visits, checking Google Analytics for device and resolution metrics, reading secondary research about the way things are moving, and comparing to where the client wants to head.
My wireframes are very sketchy and measuring them isn't really going to give any meaningful numbers. But it does allow me to start setting up columns and baseline grids for consistency and content reflow across adaptive designs. Lots of iterations and testing. I can plan how things squeeze/stretch with the adaptive layouts, and what those percentages and constraints are in the "final" design. At some point I'll jump into a digital tool like Balsamiq, Axure or Sketch and refine the design.
Once I've got an understanding for how the layout works, I sit down again with the front-end developer and crunch through all the measurements they need for slicing the design into a digital prototype. Skype and Axure are great for this as they give you measurements pretty easily.
It's less about specific element sizes, and more about placement and prominence within a defined range. Specific pixel dimensions are a bit restrictive, so I tend to refer to the number of columns the element uses, also specifying margins and gutters and baseline grid. If you're designing for a very specific screen size, you can allow for screen density by working in scaleable pixels (sp) for fonts or density pixels (dp). For example, Google's Material design language [references elements in this way. They also have a good model for approaching column based design(https://www.google.com/design/spec/layout/units-measurements.html#units-measurements-designing-layouts-for-dp).