I created a webpage in Hype (at 1200px) and now, its responsive layout (420px). I needed to add another element and use JS to hide and show an element based on certain conditions. So, I added the element in 420px layout, set the element ID, used JS and I was done, until I switched to1200px to edit its layout in that breakpoint, but, saw that the element wasn’t there. I went ahead and created the element again in 1200px, but, now, I can’t use the same element ID. I don’t have much problems in assigning another element ID and modifying the JS, but, I feel that this should not be like this? Any way around it?
In this situation, it’s best to use classes to identify multiple elements. Since elements in layouts are unique dom Elements you’ll need to give them a class. Here’s an example:
Yeah, that’s a workaround. But, since adding a new layout keeps all the elements present at that time, I thought, when adding a new element to the existing breakpoint, should get added to all the breakpoints, because we can anyways hide them if we don’t need them.
Thanks for the solution, anyways.
Am I understanding this correctly? Say I have two breakpoints and I happened to have changed the text on one of the breakpoints, would defining a class for two text elements (with the same name) keep them in sync? if not, what is the current workaround? @jonathan Wouldn’t It be a nice feature request to have text elements synced across all of the breakpoints. Update: I see that @Nigel already inquired about this feature request.
The reason why this was brought up is because I’ve misspelled a word after I’ve already created the breakpoint (and modified the second breakpoint to degree that going back and recreating another one from the original is not an option). I’d think breakpoints should sync when it comes to text changes at least?
Just put the text in symbols.
What if its part of the sentence, and its smaller somewhere in other breakpoints? I guess ill have to use find and replace I thought it was missing in hype. But then again does it work in this instance with breakpoints? Update: Just tried it doesn’t really work as intended in this scenario.
I know we’re just talking about “workarounds” but it feel like converting to a symbol might just complicate the scenario especially if you never intended on using a symbol in the first place, not in this fashion to say the least.
In general this problem arises because Hype branches Layout at Breakpoints rather than using the “traditional” reflowing most relative positioned Designs use these days. This has some advantage to design explicitly but introduces data redundancy.
Hype DataFill 1.1 works but requires setting content via JS. It would work even better if we had dataset panels on scenes and or at least on the document panel (had this discussion with @jonathan) .
Maybe Hype DataFill 1.2 could offer setting data without the need of dataset values as a source rather linking classes directly to a data store.
I agree there exists a space where an element should be able to have certain properties synced with other elements. We had some mockups when doing symbols in v3 for this idea, but felt the designs we came up with at the time were overly complex. It definitely deserves revisiting now that we have more knowledge on what is most important to sync over. Thanks!
As the symbols are in fact separate branches syncing stuff is running on the conceptual layer of the viewer actually not knowing that. So, in the spirit of already existing permanent symbols that are actually pushed around from scene to scene (layout to layout) while keeping state …if some “magic” is employed please make it optional or at least transparent to developers. Nobody want’s Microsoft Clippy back
Additionally, I think many of these problems could also be solved in extending the layout engine and allowing a group container to handle its children with relative layout (one layer deep) or some other approach along these lines. Hence, the ability to choose the way responsive is handled: Branches or regular reflows on breakpoints.