I made this request before but it was hidden in the beta subforum. I am reposting it as it’s own thread so other community members can join in with support for this request or at least read about it.
I really think Hype 4 should have a dataset feature as one could use the dataset to pass parameters to functions and symbols without miss-using the alt tag etc. and they would mostly be found directly under element.dataset (click handler etc.). Also they validate against W3C and are pretty versitile in managing that extra parameters one needs for reusable symbols and code. See https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/dataset
Link to Mockup: https://screen.maxziebell.de/DatasetsInGUI-full.png
@Photics I thought about the proposal to open up the whole attributes on any given element through a key/value panel vs. just dedicated fields (class, id) and a potential dataset interface. Opening up general access to the whole elements attributes (key/value panel) sounds cool for pro users but has lot’s of potential risks for newbies. I made a pro/contra list to wrap my head around it …
Opening up key/value to users on Attribute level
Pro
Full access to any potential attribute (also many hype current doesn’t support)
Contra
Potential conflict with attributes Hype currently already has fields for
Longform on dataset (for example data-max-value)
Invites to miss use of attributes (non validates names etc.)
Dataset as it’s own panel and any new attribute has a field
Pro
Simple interface (newbies)
Keep non conform attributes and error sources out of Hype
Shortform on dataset duo to dedicated panel (for example maxValue)
Contra
Limited access to the attributes (for pros)
I personally am still not fully siding on either side. It’s rather a list of thoughts I had.
One thought I had was if a UI was introduced then it would be good if we could select more than one element and set the same attributes on all selected in one go…
Also would be nice but then panel would have to be context sensitive. As ID must be disabled on a multi-select if you want to avoid miss configuration. Also ALT and Tab-Index would probably need deactivation (disabled status).
Is that not the norm for other properties and selections already. If you do not change the above properties at the same time then you get no conflict?
Nothing needs to be disabled from my understanding !
Yes, true. As you said it I tried it and there is a dialog. It was more a “how it should be done” thought and Hype go measures in place. So it should work for any new field. Thats nice!
I’m not really concerned with the risk to newbies. They can edit their own HTML and JavaScript, so where’s the problem if they can add some custom attributes? If it is a concern, make it a feature in Hype Pro.
True, but as I said it's more of my current thought then anything I got a very hard opinion on … anyways it's up to Tumult and this thread will only mostly inform them of some opinions/wishes from the "community".
The risks (I mentioned/was thinking about above) are not only with the newbies because of complexity but with the conflicts with the runtime. If you look at 3.2 Elements — HTML5 there a many attributes that are handled by Hype and if you have access on overriding them they might create unforeseeable conflicts.
As a "pro" I love open access and smuggling a "onclick" or any other spec approved attribute in there but it also opens a can of worms (support, validation etc.).
Maybe then that's a route … (if Tumult/Jonathan want's to allow full access)
While I can’t make promises until after we’ve shipped something, I’d personally want to give users the ability to set any attribute. There’d probably be a few safeguards in place to avoid stomping on what Hype’s runtime will set and make sure the syntax won’t lead to runtime errors.
it is in the beta, folks!