Re: Form element dependencies

Hey,

Sorry for the late reply. I have started to work on the implementation.

 - change event does not fire when a radio button is deselected - you'll have to do it on your own (cycling the change event on all radio buttons with the same name, I guess)

Well, I'd bind onchange-listener to all of the radio buttons with the same $name, and check what get's activated.

 - browsers don't support the change event on option elements (IDK why), so the only viable way to do that is with a framework such as jQuery.

We can listen to changes in their parent select-element and check if the selected option the target.

. I used it with multiple IDs separated by whitespace, as an alternative: the element had to be enabled when any of its controllers was in activated state (checked radio/checkboxes, selected options), therefore it is @disabled only if all its controllers are off. Is it the intended behaviour or you'd suggest the opposite, that is, control enabled only when all its controllers are activated? (I would not suggest that)


There hasn't been any discussion about multiple dependencies, IIRC. Is there a need to support both cases (Logical AND/OR on all the dependencies states)?


On 08.04.2015 20:47, Andrea Rendine wrote:

Hi there! 

I was trying to put together a polyfill for this use case, but I'll have to set it aside for now, I hope you were luckier.

Just a couple of notes, even if I'm sure you already figured it out:

 - change event does not fire when a radio button is deselected - you'll have to do it on your own (cycling the change event on all radio buttons with the same name, I guess)

 - browsers don't support the change event on option elements (IDK why), so the only viable way to do that is with a framework such as jQuery.


There is also a request for anybody interested, so I'll send this to the mailing list, too.

My model used @for on controlled elements as stated above (no conflicts on <output> element, as it cannot be disabled on its own and I only focused on elements which can be disabled: 'fieldset','input','textarea','select','optgroup','option'). I used it with multiple IDs separated by whitespace, as an alternative: the element had to be enabled when any of its controllers was in activated state (checked radio/checkboxes, selected options), therefore it is @disabled only if all its controllers are off. Is it the intended behaviour or you'd suggest the opposite, that is, control enabled only when all its controllers are activated? (I would not suggest that)


2015-04-02 13:18 GMT+02:00 Andrea Rendine <master.skywalker.88@gmail.com>:

Good idea. 

Be ready to heavy criticism. In WHATWG you'll find some friction due to the difficulties UAs would have in implementing pretty much everything (this is somehow funny because a lot of what they define heavily impacts on performances).

I've written a lot in the last month to both WHATWG and W3 and I guess everybody can't bear other messages by me, but it doesn't matter, I'll support it anyway.

I hope for the best.


2015-04-02 11:42 GMT+02:00 sisbluesteel <sisbluesteel@aol.com>:

Okay,

I'm going to send the proposal to whatwg mailing list sometime soon. I'll use discussion done here as a reference and probably implement a light prototype in JS as well.

On April 2, 2015 5:23:34 AM EEST, Andrea Rendine <master.skywalker.88@gmail.com> wrote: 

Hey everybody! 

Has there been any evolution about this subject?

Days ago I sent a message but it never reached the list. In short:

The focus for dependency attribute and "directionality" is to choose ease of implementation or readability.

 - if @for is specified on the controller, then I think that it would be easier for user agents to identify the state change action.

 <controller@for> -> identify controlled (depending) element(s) -> controller state change -> toggle controlled element's state

 - on the other hand, specifying it on controlled elements (depending) makes the code more readable, I see an element and I know what controls it relies on.

It'd be also useful to know if there are custom scripts (plugins etc) which do it as of now and how they work.

These are some examples:

http://dstreet.github.io/dependsOn/ - here the relationship starts from controlled and the function specifies what elements the controlled relies upon

https://github.com/keyo/jQuery-Form-Dependency - more complex syntax, but same as above. The rule specifies what element's state to watch in order to enable/disable behaviors

http://www.alpacajs.org/releases/1.1.3/examples/components/dependency/dependency-field.html< /a> - same here, the depending elements are specified before the element to be watched.

Then it looks like community goes this way.


I'd suggest some other ways to propose this feature:

 - https://www.w3.org/community/webed/wiki/HTML5_form_additions (page or discussion), but I don't know how often it is watched

 - WHATWG mailing list (whatwg@whatwg.org), similar to this but regarding Web Hypertext Application Technology Working Group

 - https://wiki.whatwg.org/wiki/IRC WHATWG Freenode channel (requires more dedication)

 - WHATWG wiki proposals (https://wiki.whatwg.org/wiki/Feature_Proposals) - also worth noting this page for suggestions about proposing stuff: http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F


Yours respectfully and supportingly

Andrea


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.





-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.