It’s not a challenge I’d run from, but you’d have to also hire/pay me.
Which is the problem. You think you have to serve all the bulky CSS, when, in fact, you only need to serve the CSS/JS relevant to your dynamically generated markup.
Step 0: Get the request at server side
Step 1: Dynamically generate at server side both HTML and relevant CSS/JS for that request
Step 2: Serve them up
Think PHP. Think Ruby. Think LESS even. Think whatever you want. But think server side. And dynamic CSS.
Conclusion: do a proper server side job before even thinking about touching the client side.
Don’t comment about it than until you can put your money where your mouth is.
That goes for everyone. No offense meant by that but I am getting sick of hearing what I want to achieve can be accomplished without the extra mark-up. Yet no one is actually able to do so. I have spent quit a bit of time thinking this through and if I could achieve the goals without the extra wrappers I would. I hate extra mark-up as much as the next person but the there are just to many advantages to be an idealist here. At least from where I stand.
Sorry, the first thing you linked to in the thread, with the styles, I tried keyboarding around in. I couldn’t access maybe half of the elements, but again, you may not be targeting keyboard? Also not sure about phones with no full keyboard but well arrow keys. Some of them I could tab to with Javascript on, but I can’t see that I’m on that element and arrow keys forced me to choose the first option, after tabbing and shift-tabbing around.
Later you linked to the same form without any styles and stuff the nowrapping one. This one responded normally for me (with keyboard, I could access all the elements and focus styles showed me where I was).
The only reason I even bothered checking is because in general jQuery/other libraries in combination with styling form controls means someone forgot to build in things like the typing of a letter to jump to the select option or letting up/down arrows and spacebar work and other similar built-in stuff the native-but-ugly controls have. You might have added those things in, and if you did congrats, because that’s a lot of extra coding others don’t do (but should). And again most importantly I’m looking at your links on a desktop browser, not a mobile and I’m guessing you’re focussing on iOS and Android specifically.
Forms are complicated things with lots of OS- and Desktop-environment-influenced behaviours and styles so I agree it’s not easy to do something like this well.
Are the new JS API thingies like querySelector and querySelectorAll able to work on these pages or is support still not up to it yet?
You are correct that keyboard is not a concern because the modifications are for mobile only. I don’t really see a need in changing form element default appearance on desktop except for perhaps minor color or border styles to match site branding. Though that would be handled application side rather than a generic style sheet for form controls.
That is the example of the quality of mark-up output by the form API as it stands. The initial intensions where to not provide any wrapping divs for controls exact for those in a separate application side form template which the rendered controls get injected. However, that method makes it impossible to defined generic styles for combination of elements that make up a form control. Those being anything from multiple form controls for complex elements to the description, error string and label(s). No wrapper makes it painfully inconsistent and unreliable to select those things given all the different permutations that exist.
At this point in time this is merely all a prototype. Pretty much playing around to see if it is even possible and worthwhile given the sacrifices that need to move it to production. I hadn’t even considered the extra code to make the controls accessible to all. Though it will something I look into now that you mention it I continue with this. This is a mobile specific set of enhancements. In the future I would consider desktop but that would be more layout oriented than changing default presentation of form controls themselves. At least I would think. Not as important as mobile stuff because mobile has been my primary concern as of late.
They are. Especially with the server-side technology I have to work with… (that is another story)
So I think the consensus here seems to be that the repetitive data-fapi- prefix adds a lot of extra mark-up for little in return besides for avoiding conflicts imposed by other third part extensions.
The only problem I have with this is that any third party CSS that uses selectors .element, .textfield, etc without a more specific context would be applied. This would not be good. Which is why the initial data-api- prefix was applied. I will admit though the multiple class method is a lot less mark-up.
I guess the solution to preventing similar selector conflicts would be to add the prefix back in like this:
Still less mark-up than data attributes, more than without prefixing but just about eliminates the possibility of CSS selector conflicts brought about by third party extensions when used. This is the method jquery ui seems to use to prevent the same problem. Though the prefix for it is slightly less characters ui-.
I’d try to reduce the number of classes too. If in my code a DIV wrapping a LABEL and INPUT was getting four separate classes, I’d assume there was something completely wrong with the entire page and methodology.
I took most of the advice and eliminated the data attributes for multiple classes without prefixes. There isn’t anything that can be done about the wrappers though given my number one goal in all this. I think one or two extra divs per element is a small price to pay to *never write application side CSS for mobile forms again. Not to mention eliminating the repetition of similar form CSS across several independent applications.
I don’t really see how it would be possible to reduce anything else at this point and achieve my goals.
The element class flag is used to select the root wrapper for a element/control(s).
The widget-[name] class is important because different widgets require different styles think: radio, radiogroup, checkbox, checkboxgroup, select, textfields, linkedlist, autocomplete. etc. The widget hook makes it possible to apply widget specific styles in a generic manor to the proper form element.
The layout-[name] class is used to layout a complex widget differently. A complex widget is one which has widgets nested inside it. This is the case with a linked list, checkboxgroup and radiogroup. In those cases the controls can either be arranged in a horizontal or vertical manor. Perhaps in time others will be introduced as well though those are the ones I have anticipated for now.
The textfield class flag is used to easily style all text fields types such as; email, search, text, etc. Without it I would have to define all the different permutations in a CSS selector. I think the advantages of having a single flag/indicator far outweighs the disadvantages.
The mixin flag could perhaps be removed. That is more or less something that is specific to the way the form element was derived server-side. Whether it has been programatically configured or not (think XML file with the form element configuration).
I did happen to leave the name of the form element as a data attribute. That is because names can contain special characters and it seems better to isolate them from the class list. The only reason these exist is so that when there comes a time application CSS is required for a specific element it can easily be selected in JS or CSS in a consistent manor across all applications that use the form API.
Selected by WHAT? What are you using to hook those? Of course, if you want to hook the root wrapper and know the child in js, isn’t that parentNode’s job? Since you’re in a form and shouldn’t have a lot of DIV to begin with, couldn’t that be the DIV tag’s job? (again, NOT that I’m seeing a lot of point to the DIV either)
the only one I really see a point to…
Isn’t that a fieldset’s job?
Which is different from your ‘widget’ type how exactly?!? Redundant at best. Either that or this one serves a purpose and the widget one does not…
Especially since if all you’re thinking is CSS, just say them together ONCE CSS side (email,search,text) instead of each and every time in the HTML. That’s one of the entire reasons to use CSS in the first place – to say things once in the CSS instead of multiple times in the markup.
The div needs to exist because in some cases the mark-up *could look like the below.
<div class="element widget-email">
<label for="xxx"></label>
<input type="email" name="xxx" id="xxx">
<div class="description">Form element description string ot mark-up</div>
<div class="error">Error message string or mark-up</div>
</div>
Without a wrapper there would be no good way to target individual descriptions or errors messages.
I think that is a matter of opinion not to mention would break consistency and make things more complex to understand. Either way though some type of class would need to exist to determine the type of layout regardless of the wrapping element. Considering CSS rules are written to change the CSS for widgets based on the type of layout such as; vertical or horizontal.
Well… right now the CSS rule(s) that apply to textfield types is simple as:
Everything seems simpler with a single flag to target all widgets that are derived from a standard text input. The texfield flag will only be applied to widgets that are derived from a single, text field type.
The textfield flag allows me to do just that. Say it once in the CSS rather than repeat every single widget type that is derived from a simple text field (input) type.