Not sure if this should apply as a feature request or a question if it's already possible.
The impression I got from the early videos of the app in use was that you could view the artboard at multiple sizes so you can design responsively. So I thought you'd be able to design an element, for instance a button, that had 16px type at screen sizes below 768 and then change to 18px above that. Is this something that's possible or would you need to write some media queries if that's even possible?
@toby_burkill We don't have "media queries" or any other kind of properties derived from conditional logic.
A few people have asked about this, so we'll have a blog post about our reasoning at some point.
In the mean time, here's what I said in the Kickstarter comments a month ago.
Ryan and I talked about responsive breakpoints (AKA media queries), but as a programmer I was pretty adamant that it doesn't scale well.
Once you chain a few booleans together, it becomes impossible to predict what should happen because you accidentally constructed an implicit 144 cell truth table or whatever --- at a certain point, you media query your way into a totally different design.
So we decided it was more important to be able to develop components and style classes so it'd be easy to share them between explicitly different designs.
AKA, don't come up with weird rules to show/hide elements so a desktop page turns into an Apple watch page --- instead, just start with two different artboards and share the components+styles that need to be shared.
Your design intent will be much more explicit.
Just chiming in on this one to express my thoughts on how this should work and what I have learnt in my early days as a digital designer.
@toby_burkill setting explicit font sizes is harmful to accessibility. People should be allowed to change the size of the fonts freely to accomodate themselves. This adds far more ways for the design to break other than simple changes we generally make to size in order to maintain aesthetic and a consistent hierarchy of content on larger viewports. To accomodate this as much as possible we need to design relative to the font size more than the viewport.
I can definitely see what Kevin and Ryan mean regarding "media queries" getting out of hand. This is the only way we have to manage various screen sizes so it is all we know. We are already used to designing multiple screens for various sizes in our design tools. I think we should keep it this way at present for the following two reasons.
1. It makes the communication of the design more explicit
You can see clearly when the design changes and what changes it has. Preventing the possibility of being able to make 10's - 100's of incremental changes at various breakpoints that could then be missed during the development stage.
2. It prevents over engineering the design
Having too much logic in the design tool can prevent iteration and moving on to development. Since we always have to deal with breakpoints in development I think it's better to leave it as an implementation detail rather than integrated part of the design tool.
Perhaps a happy middle ground could be swapping out artboards/screens based on viewport heights or widths when in live preview modes. (Given this little thought).
This is my deeper thoughts on creating responsive designs.
https://talk.subformapp.com/t/em-and-rem-support/607?u=wade
@kevin I disagree with the reasoning you quoted.
I design only web products, we have separate app designers and developers in house for that. So my perspective and needs are almost exclusively based on what's possible and needed for the web.
My job does not consist of only creating components and styles, but also creating a reliably working information hierarchy that talks to the user on his way down a page. Layout is what makes that possible.
If a complex page needs a radically different approach on a mobile device then I have to design that approach, and design it well. I need to be able to show our stakeholders, who have no idea about design, that the page collapses functionally and beautifully no matter the device they bring to the meeting. For example I need to be able to move form fields around on different screens, depending on the viewport width. That includes being able to show that to the stakeholders in a live prototype, before development. They themselves will scale their browsers, so my design better react well to whatever they try to test it.
If your vision of subform does not include designing responsive layouts than I erred in backing it. I can design adapting components in sketch, webflow and figma. Components in relation to each other is only possible in Antetype, Pinegrow and Webflow so far (and code of course).
A responsive design tool should be able to create output that mirrors current and future web products, and that includes breakpoints and layout flow.
I feel like I've opened a can of worms here as on one hand I completely get that if there is the ability to add an infinite number of break points (even though this wouldn't be best practise, someone potentially could) then this could cause issues like @kevin said for the developers looking at the design files and missing things. But then I also agree with some of @David points as I too purely work in web design so I saw this tool as being a way that clients and also developers can see how the pages change at different screen sizes more easily rather than waiting for them to build it and then having to tell them what needs changing. One of the biggest things I thought this app was going to allow users to do was rearrange the layout at different screen sizes like what happens in real life across multiple devices.
@Wade I understand accessibility is very important - after a year working in the UX at a bank I feel like I've had more than enough accessibility meetings to last me a life time 
- but if for instance you are designing a site that is more stylised and has for instance a wopping great 140px (or whatever unit of measurement) tall title on a landing page at wide screen sizes, it just isn't going to work at mobile at the same size so some degree of setting font size is needed.
@kevin you were talking about CAD application as a reference for Subform, but CAD apps do not prevent engineers to shoot their legs by limiting what’s possible. They provide them with tools and rely on them to be smart enough to use them. They are engineers after all.
Yes I agree font setting is necessary. I also see what you mean by a heavily stylised page. But I feel that the base font is the only necessary one to set and then all the rest should be relative. Which could be set per artboard.
As many users will be changing the font size. I feel it's also important to ensure there is enough flexibility in the design for varying 'base' font size. If people go too wild things it will most likely break regardless.
This is a pretty tough problem. There is plenty of trade offs and we need to assess every one.
I think instead of just saying create another artboard for a different sized design. We need to go deeper on the alternative to breakpoints. How can we effectively communicate those changes over varying screen sizes?
I too work exclusively with web. Only coming into the industry now and have my eye on progressive web apps, with wasm and AR around the corner the browser is the most universal platform we can build on.
I'm going to avoid the knotty mess of what-should-be and raise a possible workaround. Could sets of classes be used? Maybe a Mobile-button-padding class on one artboard that you switch out for a Tablet-button-padding class on another artboard. Admittedly, in Subform's current state, you'd have to do this element by element on your duplicated artboard.
I've considered this for testing out different styling concepts - how to save time building a light and a dark style for a UI.
The workaround you describe is already possible by making the container box a component, then set up multiple states as the breakpoints. You have to switch thinking from having the artboard as the boundary of your design to having the container box as the boundary. Classes do not carry the dimension and behaviour settings sadly.
This workaround turns the artboard into the canvas, and the grey area around it into the void, where no design can happen ;D