SitePoint Sponsor

User Tag List

Page 1 of 2 12 LastLast
Results 1 to 25 of 31
  1. #1
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)

    CSS Selection of Elements By ID and CLASS with Special Characters

    I have been experimenting with a way to represent properties of an object in CSS. After reading some I learned that escaping can be used for special characters in ids and classes. I have tested the below and seems to be functioning, which is great. However, is there anything I might be overlooking (besides how convoluted it may look to most)?

    disclaimer: I know this won't work in IE6 considering the last class is the only one IE6 will recognize. Lets put that aside.

    I also wonder if jQuery will be alight with this. I'll have to test it out.

    Thanks

    HTML Code:
    <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
    <html>
    <head>
    	<meta http-equiv="content-type" content="text/html; charset=utf-8">
    	<title>Test Escaping Sepecial Characters for CSS Selectors</title>
    	
    	<style type="text/css">
    	.fapi\\element {
    		width: 200px;
    		height: 50px;
    	}
    	
    	.fapi\\widget\\select {
    		background-color: blue;
    	}
    	
    	.fapi\\widget\\textfield {
    		background-color: yellow;
    	}
    	
    	.mdtlv\\view\\listing {
    		width: 400px;
    		height: 500px;
    	}
    	
    	.mdtlv\\display\\list\:--mobile--default {
    		background-color: black;
    	}
    	
    	div[class^="mdtlv\\listing\\list"] {
    		background-color: #ccc;
    		width: 200px;
    		height: 50px;
    	}
    	
    	.obj\[prop\]\=value {
    		width: 300px;
    		height: 50px;
    		background-color: violet;
    	}
    	</style>
    	
    </head>
    <body>
    
    <div class="fapi\element fapi\widget\select fapi\name\test">
    </div>
    
    <div class="fapi\element fapi\widget\textfield fapi\name\test-txt">
    </div>
    
    <div class="mdtlv\view\listing mdtlv\display\list:--mobile--default">
    </div>
    
    <div class="mdtlv\listing\list:-mobile-default">
    </div>
    
    <div class="obj[prop]=value">
    </div>
    
    </body>
    </html>

  2. #2
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    So, if I read this correctly, you're trying to suggest namespaces in the class names. Interesting.

    If that, the problem I'm seeing is in your HTML. You should have something like this

    Code:
    <body>
      <div class="fapi">
        <p class="element"></p>
      </div>
    </body>
    to make it so, where divs would be the namespace containers.

    It's pretty interesting, I'm not sure you can relay the same namespaces meaning with HTML though, doing what you're doing.

    <hr>

    To note that in XML(XHTML) there is already support for namespaces.

    Code:
    <fapi:table>
      <fapi:tr>
        <fapi:td>Apples</fapi:td>
        <fapi:td>Bananas</fapi:td>
      </fapi:tr>
    </fapi:table>
    
    <mdtlv:table>
      <mdtlv:name>African Coffee Table</mdtlv:name>
      <mdtlv:width>80</mdtlv:width>
      <mdtlv:length>120</mdtlv:length>
    </mdtlv:table>
    <hr>

    There is also a CSS3 Namespaces Module: http://www.w3.org/TR/css3-namespace/.

    Code:
    @namespace "http://www.w3.org/1999/xhtml"; 
    @namespace svg "http://www.w3.org/2000/svg"; 
    
    svg|a { color: white; }
    where they use pipe instead of backslash.

    <hr>

    Your idea has merits. But it's seems a little overkill and more like something just for the sake of imitation than something designed to make things easier or clearer.

    The fact that you have to redundantly spell "fapi" namespace three times doesn't help, when a single classic "fapi" class would be more than enough.

  3. #3
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    oddz:
    you might find these posts interesting:
    http://mathiasbynens.be/notes/css-escapes

    http://mathiasbynens.be/notes/javascript-properties <--zalgo text++

  4. #4
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,282
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Hi,

    I may be missing the blindingly obvious but how is .fapi\\widget\\select any better than something like .fapi-widget-select or even .fapi_widget_select?

    you might find these posts interesting:
    http://mathiasbynens.be/notes/css-escapes
    Interesting links Mallory.

  5. #5
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by Paul
    Hi,

    I may be missing the blindingly obvious but how is .fapi\\widget\\select any better than something like .fapi-widget-select or even .fapi_widget_select?
    On Mathias' other page on id's he says http://mathiasbynens.be/notes/html5-id-class#comment-4
    As some people on Hacker News have pointed out, this is pretty damn useful:

    An <input> element with name="items[0][name]" can now finally have an id matching the name attribute. This would be invalid HTML 4.01, but valid HTML5: <input type="text" id="items[0][name]" name="items[0][name]">

    It might be useful for programmers in other languages, so they don't have to either come up with English names, less descriptive names ("id1"), transliterating words, or replacing letters with 'similar' ones ('O' or 'OE' for '')

  6. #6
    The CSS Clinic is open silver trophybronze trophy
    Paul O'B's Avatar
    Join Date
    Jan 2003
    Location
    Hampshire UK
    Posts
    40,282
    Mentioned
    179 Post(s)
    Tagged
    6 Thread(s)
    Quote Originally Posted by Stomme poes View Post
    Ok that makes it clearer -Thanks Mallory.

  7. #7
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    I decided to go with data attributes instead. Looking at this after a good nights sleep was just to convoluted for me.

  8. #8
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    You only wanted funny CSS names as JS hooks?

    I thought you wanted to just write neat looking code :)

  9. #9
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    However, is there anything I might be overlooking (besides how convoluted it may look to most)?
    Well, at least you are already aware of it's biggest problem.

    That said, what does this actually accomplish in terms of functionality just saying what thing ARE would? I'm reading and re-reading trying to figure out what this actually does that would be useful... Just what are you trying to accomplish other than adding massive convoluted names to things?!?

    Oh, and @StommePoes on the id thing; if you "need" them identical, you've missed the point of why ID and NAME are separate attributes. That really falls into another of the "herpaderp" bits I've come to expect from the HTML 5 crowd... who I increasingly think never bothered learning to write HTML in the first place before crapping out their spec.

  10. #10
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    This will be used to apply a generic set of styles to individual form elements generated by a form API. The thing is I find myself repeating a a lot of CSS between different applications to style forms and I would rather have a few extra wrappers than repetition of similar concepts across different applications. The hooks will be used to apply mobile friendly optimization to form elements like that of jQuery mobile though I do not actually want to incur the cost of using the library itself. Merely want to "borrow" how the library transforms form elements to make them more usable for mobile users given my existing work flow. To do that though I do need some extra, none semantic wrappers with meta data from the form element state. Though I think it is a small trade off for what will be gained. Also, it will provide a consistent means of customizing form elements using the available hooks when that needs to be done on an application by application basis.

    Example for those interested

  11. #11
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Well, your fancy styled radio buttons don't seem to work (though being WIP that's understandable if that's all that's wrong) -- a lot of fancy stuff that annoys me when it comes to forms... but most of all... and the page never seems to finish loading.... the 25k of carriage returns before it even gets to the doctype possibly being a contributing factor.... or an indicator of something disastrously wrong in the code generating it.

    ... 51k for 26 input and label pairings being a indicator you are REALLY over-thinking things here... especially when your labels could easily be broken into FIELDSETS by appearance, then have single class for each set off that.

    You seem to be trying to use massive nested NAME/ID to do semantic markup's job... as evidenced by all the DIV for nothing with made up fictional attributes and massive values. Lemme guess, Drupal? Another example of CMS code by people who didn't bother learning HTML first.

    Seriously, if making a form this is not sufficient reason to put a bullet in one's own head:
    Code:
    <div  data-fapi-mixin="birth_dateh" data-fapi-widget="selectgroup" data-fapi-layout="hbox">
    I don't know what is. I wrote code like that, I'd have to put myself down HARD. How to take something simple (FORMS) and turn it into a convoluted pointless inaccessible slow loading mess.

    Laundry list on how NOT to build a form.

    -- edit -- my bad, the radio buttons apparently only work if you click on the label -- that's cute... and annoying.

  12. #12
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by deathshadow60
    Well, your fancy styled radio buttons don't seem to work (though being WIP that's understandable if that's all that's wrong) -- a lot of fancy stuff that annoys me when it comes to forms... but most of all... and the page never seems to finish loading.... the 25k of carriage returns before it even gets to the doctype possibly being a contributing factor.... or an indicator of something disastrously wrong in the code generating it.
    This a work in progress so not all issues have been resolved. I just removed all the carriage returns. By default the system does not strip space it has to be turned on though I didn't consider it because this is more a proof of concept than anything. If you say the radio buttons aren't accessible than I will probably just show the actual radios. No biggie. I was merely attempting to replicate jQuery Mobile there.

    Quote Originally Posted by deathshadow60
    ... 51k for 26 input and label pairings being a indicator you are REALLY over-thinking things here... especially when your labels could easily be broken into FIELDSETS by appearance, then have single class for each set off that.
    I thought so at first to which is why having built the form API itself several months ago I did not initially do this. However, it has become clear after building several applications with it that there is a lot of repetition in CSS for forms. Repetition which I would like to eliminate and replace with a style sheet that gets me 75%+ of the way there without needing to write application side CSS.

    Quote Originally Posted by deathshadow60
    You seem to be trying to use massive nested NAME/ID to do semantic markup's job... as evidenced by all the DIV for nothing with made up fictional attributes and massive values. Lemme guess, Drupal? Another example of CMS code by people who didn't bother learning HTML first.
    The divs aren't for nothing. They provide a container that is necessary to store the state of individual form elements which is necessary to style the element correctly using CSS. Form elements need to styled differently based state. There is no way to do that without passing the state somehow to the HTML which I have decided to do using wrapping div(s) with data attributes which I can hook into using CSS.

    No, this is not Drupal. it is actually a custom build framework built on top of C and Oracle that runs a significant portion of my companies applications.

    Quote Originally Posted by deathshadow60
    I don't know what is. I wrote code like that, I'd have to put myself down HARD. How to take something simple (FORMS) and turn it into a convoluted pointless inaccessible slow loading mess.
    Alright... I can't really respond to that. If you think they are "simple" fine by me. I don't mind sacrificing a little to gain a lot in terms of maintaining SEVERAL existing sites. There just has to be a reason to do so and I believe I have a good reason though you may not considering you don't understand the complete scope of the problem so your looking at it only in terms of the mark-up itself. Which is fine but there are many other more important things to consider outside your realm of understanding.

    Off Topic:


    This is why I didn't give a context in the beginning because I knew that the idealist who don't have to deal with MAINTAINING highly dynamic, changing sites would be on alert and the thread would turn into a bash fest. w/e...

    Simply doing the best I can with what I have to work with.

  13. #13
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Here is the same form without the majority of wrappers. Your challenge is to achieve the EXACT SAME thing in a manor that can be REUSED across multiple forms. That is since you want to tell me how worthless the extra wrappers are and such.

    Form No Wrapping

  14. #14
    Non-Member bronze trophy
    Join Date
    Nov 2009
    Location
    Keene, NH
    Posts
    3,760
    Mentioned
    23 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    I was merely attempting to replicate jQuery Mobile there.
    Something I wouldn't try to replicate, but that's probably because it's never worked here for me on anything and just results in broken forms I can't fill out.

    Quote Originally Posted by oddz View Post
    The divs aren't for nothing. They provide a container that is necessary to store the state of individual form elements which is necessary to style the element correctly using CSS.
    That's the part I'm not getting -- what on earth are you doing that would require fictional made-up attributes that won't even exist or be resolved in most browsers? OR your massive string of classes for that matter?

    data-fapi-form -- what is this even supposed to do, other than waste the browsers' time?!?

    Even if you need the div for some strange styling hook reason, I'm not grasping why you need anything more than this:

    Code:
    <form
    	action="/forge"
    	method="post"
    	enctype="multipart/form-data"
    	id="formId"
    >
    	<fieldset>
    		<legend>Form Elements</legend>
    
    		<div class="inputText">
    			<label for="formId_textfield">Text Field</label>
    			<input
    				type="text"
    				name="textfield"
    				id="formId_textfield"
    				value=""
    			 />
    		</div>
    		
    		<div class="inputEmail">
    			<label for="formId_email">Email</label>
    			<input
    				type="email"
    				name="email"
    				id="formId_email"
    				value=""
    			/>
    		</div>
    		
    		<div class="inputSearch">
    			<label for="formId_search">Search</label>
    			<input
    				type="search"
    				name="search"
    				id="formId_search"
    				value=""
    			/>
    		</div>
    		
    		<div class="textArea">
    			<label for="formId_textArea">Text Area</label>
    			<textarea
    				name="textarea"
    				id="formId_textArea"
    				rows="20" cols="70"
    			></textarea>
    		</div>
    The ID being for the FOR attribute, not for styling, that's classes and or the parent form's ID job. that's what inheritance and sibling/child selectors are FOR. I mean if you're going to have that extra wrapper for little good reason, just nab all it's children off a class.

    that way you could nab them all site-wide with just the class

    .textField
    .textField input
    .textField label

    or per form:

    #formId .textField
    #formId .textField input
    #formId .textField label

    I'm not getting why you aren't just letting semantics and child selectors do the work, and instead are slapping all that extra stuff in there.

    I mean, take
    fapi\element fapi\widget\select fapi\name\test

    what is "fapi" -- the parent page? parent form? Why not just use the parent page or parent form... You've got this long string of stuff that natual page inheritance should be handling for you. It reeks of "lets slap a class on EVERYTHING" -- which is a really unsound method to sitebuilding... No matter what the turdpress folks tell you.

  15. #15
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    If you really want to get down to inner working of things here is a general summary.

    Each form element can be thought of as object since that is what it is server-side. Properties for that object will have a direct impact on how styling needs to be applied. Take for instance a text field. There are several types of text fields such as; email, url, etc. So data-fapi-widget is used so that a form element can be selected by widget type. Though specific to text types they are also flagged as data-fapi-textfield because at this point in time they are being styled the same. This means all that needs to be done to select all textfield is target form elements with an attribute data-fapi-textfield as possed to creating a list with the different types such as; data-fapi-widget=text,data-fapi-widget=email, data-fapi-widget=url, etc. There are many types of widgets provided by the form API textfield is merely the simplest. Also, some types need to expose additional information regarding state for styling reasons. How this is all accomplished is via using a wrapping div with data attributes that follow the pattern data-fapi-{propname} (for booleans) and data-fapi-{propname}=val for all other values.

    Now I know the traditional meaning of form element is the form control such as; the input itself for a textfield. However, in the form API context it is that form control and any other information related to it such as; label, description text and error string(s). Wrapping those elements with a division provides a consistent means of selecting errors, descriptions, labels, etc for a form element. Simply use "data-fapi-widget=email .description". As opposed to applying more classes to the supportive information for a form element or relying on element location using some form of sibling selectors. Granted I know that no descriptions or error strings exist in my example they are part of the form API and need to be handled appropriately in combination fir the controls themselves. Wrapping all associated information to the control like that of error strings displayed next to control and descriptions provides that mechanism in easy, reusable, consistent form for styling and js manipulation if need be.

    The data-fapi-form flag exist to turn on the generic styling. Though this has not been done in the CSS yet all generic form api styles will eventually start off with form[data-fapi-form] ... Thus when a form does not use require generic styles be applied the attribute can simply be omitted. So it pretty much will act as a flag for turning on and off generic form API styles and/or identifying forms managed by the server-side form API library.

    The fapi prefix is the name of the library that manages the forms. I am simply trying to reduce the possibility of name collisions. Also provide a means of easily seeing which attributes belong to the form api itself. If I were to removed it my attributes would end up being something like data-widget="" which could very well conflict with the name of an attribute for something else in the future. To prevent that fapi is prefixed to each property.

    What I hope to accomplish with this is having 90% of all form CSS being taken care of by generic styles supplied by the form library. As opposed to none which results in the needless repetition of similar presentation code across different applications that use the form API to build/manage forms of all kinds ie. data entry, search, registration, email, etc.

    The thing you have to understand in all this is that forms are being dynamically generated based on a configuration file and callback functions server-side when need be. Up to this point I have handled all the CSS manually on an application by application basis. After creating several sites using the form library I have come to the realization that it would be best to handle a portion of the CSS to both reduce repetition, provide centralized debug/change point and improve my efficiency when developing new sites/applications. I don't think a few extra attributes and wrappers compares to all the things that will gained by doing this.

    Initial I though it did which is why when I went in to add this functionality I made it a configuration option. So you can actually see the same exact form without just about all wrappers here. Though now I have come to a different realization having worked on many sites I have. So yeah…

  16. #16
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    The thing you have to understand in all this is that forms are being dynamically generated based on a configuration file and callback functions server-side when need be. Up to this point I have handled all the CSS manually on an application by application basis.
    The logical solution to me is to dynamically generate the CSS as well.

    As a note, if "data-fapi-" appears all over, it's obvious that it should either appear just once, or not at all. The same goes for "data-fapi-element", "data-fapi-widget", "data-fapi-name" etcetera. And what's the "frm-" prefix doing? Can it really be anything else, like "prg-"? And again, if it has to appear all over...

    All this can be solved by CSS inheritance.

    <hr>

    For me it's more obvious that every form is an object, not every element. An object just for one form element makes little sense. You're not actually implementing something new, say a new type of textfield, building methods and properties from the ground up, you're just "describing" extremely basic and severely small in number properties.

    <hr>

    It seems to me that you're trying to produce "mutants" from different with predefined styled form "objects". Frankenstein Forms. I'm pretty sure you're looking for different styled forms-as-a-whole instead.

    The way I see it: a form class, a style class, instantiate them, feed them basic form objects along with style objects and you get those different style form objects you're after.

    <hr>

    One example:
    Code:
    <div data-fapi-element data-fapi-widget="email" data-fapi-name="email" data-fapi-textfield><label for="frm-email">Email</label><input type="email" name="email" value="" id="frm-email"  class="email" /></div>
    "email" token appears 7 times, not counting the label content. I wish you could explain why it is necessary, I simply don't get it, server side or client side.

  17. #17
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by crusty
    what on earth are you doing that would require fictional made-up attributes that won't even exist or be resolved in most browsers?
    data-foo's aren't for browsers, they're pretty much purely for JS. Browsers ignore and that's fine.

    The "mobile" link oddz linked to is broken, however it's broken on a desktop browser and I'm not sure what the mobile context is... only touch?
    The checkboxes worked but couldn't move focus to the fonty-checks (bold italic etc) nor did the dropdowns drop down on focus. Maybe they don't have to work with focus though.
    what I'm thinking of, basically when building custom controls, you have to think of all the things the original/native/default interface offers. I have no idea if jQueryMobile works for keyboard/touch/trackpad/whatever on all form things or just the most common ones or what.

    Quote Originally Posted by mitică
    As a note, if "data-fapi-" appears all over, it's obvious that it should either appear just once, or not at all.
    I thought that was why oddz was adding wrappers (so the attribute was only needed once).

  18. #18
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by itmitică
    As a note, if "data-fapi-" appears all over, it's obvious that it should either appear just once, or not at all. The same goes for "data-fapi-element", "data-fapi-widget", "data-fapi-name" etcetera. And what's the "frm-" prefix doing? Can it really be anything else, like "prg-"? And again, if it has to appear all over...
    The data-fapi- prefix is used to avoid potential conflicts with other libraries. The frm- prefix for control names is used to avoid conflicts with other ids on the page. Regardless of a form controls name prefixing frm- pretty much eliminates the possibility for conflict. I'm not the only one working with this. So I am anticipating the possibility for conflict to avoid future issues for someone who may not have as good of an understanding as I do. If that means some extra characters I think the trade-off is worth it.

    Quote Originally Posted by itmitică
    For me it's more obvious that every form is an object, not every element. An object just for one form element makes little sense. You're not actually implementing something new, say a new type of textfield, building methods and properties from the ground up, you're just "describing" extremely basic and severely small in number properties.
    Actually there are simple and complex types. The textfield is by far the simplest. However, there is also linkedlist, selectgroup, radiogroup to name a few that are collection of form controls that make up a single widget. In those cases the widget type is required by CSS to style them correctly. In the future more will be added as needed. Also, widget type can change behavior. Take a text field and checkbox for instance. While value is supported on box they have different contexts. On the case of a text field the value is always passed but a value for a checkbox is not passed unless the checkbox is checked. While concepts may be similar implementations need to change based on how the form control will be represented to the user.

    Quote Originally Posted by itmitică
    It seems to me that you're trying to produce "mutants" from different with predefined styled form "objects". Frankenstein Forms. I'm pretty sure you're looking for different styled forms-as-a-whole instead.
    Permutations of different control combinations is what is being done. Some are a simple text field others are complex widgets like a linked list that dynamically reloads. The goal in all this is to find the best middle ground to support applying js/css hooks to the most complex widgets to simplest. The middle ground being the best balance of flexibility in terms of easily selecting form elements based on server-side derived properties and none semantic HTML.

    Also, every form element can contain associated information other than the title like description text but most importantly errors for the individual form element. So essentially all form elements regardless of complexity are decorated with that functionality.

    Quote Originally Posted by itmitică
    The way I see it: a form class, a style class, instantiate them, feed them basic form objects along with style objects and you get those different style form objects you're after.
    Very few forms are basic. This is just a proof of concept with the simplest of cases. Have you looked at the jQuery Mobile form gallery? If you had you would notice that I pretty much copied that form. The form shown here is just for testing all the different permutations and getting the styles applied. Once satisfied with what is here I will than begin the process of upgrading the existing applications to use the element wrapping and generic styling application.

    Quote Originally Posted by itmitică
    "email" token appears 7 times, not counting the label content. I wish you could explain why it is necessary, I simply don't get it, server side or client side.
    That is irrelevant considering the form element name could be anything. As a matter of fact I just changed it. All that matters is there is a hook to select the form element root wrapper by name, widget type or another server derived property for the object. Where name is the application defined name of the form element and widget type is a form API supplied class instance.

    Quote Originally Posted by Stomme poes
    data-foo's aren't for browsers, they're pretty much purely for JS. Browsers ignore and that's fine.
    Also, given the power of attribute selectors I think the method is worthy alternative to a bunch of classes. Looking at the CSS should reveal what is being done and how it can be applied to just about any form that needs to be created.

    Quote Originally Posted by Stomme poes
    The "mobile" link oddz linked to is broken, however it's broken on a desktop browser and I'm not sure what the mobile context is... only touch?
    Which link?

    This one is the one with form element enhancements:

    Form Mobile Theme

    This one is the same form without those enhancement that avoids wrappers but makes it just about impossible to create a generic set of styles based on object properties. Like I said above I would like to someone take the HTML from the below page and replicate what has been done in the previous link in a reusable form if they want to get their panties tangled about the extra elements.

    Form Bare Boned

    Other than that both those pages I am actively working on. So it may have been broken because of that. If you received a 404 than that would be because there was an error in the server-side code while changes where being made.

  19. #19
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    That is irrelevant considering the form element name could be anything. As a matter of fact I just changed it.
    If you changed it with another token, repeating seven times again, it's not much of a trade.

    <hr>


    Quote Originally Posted by oddz View Post
    Also, given the power of attribute selectors I think the method is worthy alternative to a bunch of classes. Looking at the CSS should reveal what is being done and how it can be applied to just about any form that needs to be created.
    I'm not sure either is good.

    You seem to do just a small part on server side and then move all logic to client side code: HTML, CSS.

    I state again: you should have a clean HTML, dynamically generated, along side a clean CSS, dynamically generated. As a metaphor, I'd say you're just using front-end crutches to justify the server side "lazy" action. Please don't take this the wrong way.

    <hr>

    Have I looked at jQuery Mobile? I didn't, but I'd say the same thing: it should hide all the complexity on the server side and dynamically generate clean HTML and CSS. Clean Javascript even.

    <hr>

    You have 111 occurrences for the "data-fapi-" token, in a 14 elements form. This is not right. No matter what way I look at it, there's no programming equivalent I could think of, desktop or mobile, scripting or compiling, that would ever need or involve such a tautology.

    The HTML code just screams "save me" to me. You need a better strategy. The server side main role is also this, to hide the complexity, to serve a good processed code. You definitely need to rethink this "system", it's something that I, personally, would feed it to hungry lions.

  20. #20
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by itmitică
    I state again: you should have a clean HTML, dynamically generated, along side a clean CSS, dynamically generated. As a metaphor, I'd say you're just using front-end crutches to justify the server side "lazy" action. Please don't take this the wrong way.
    Perhaps but have you looked at the form without the wrappers? It would be impossible to create a generic set of reusable styles without the extra mark-up. If you don't think so I challenge you. Take the HTML here and create a style sheet that provides the same presentation in a reusable form.

    Quote Originally Posted by itmitică
    Have I looked at jQuery Mobile? I didn't, but I'd say the same thing: it should hide all the complexity on the server side and dynamically generate clean HTML and CSS. Clean Javascript even.
    I don't really understand what your talking about. The CSS and JS isn't dynamic. A static style sheet has been created to account for the different permutations of form element based on various properties. Also, jQuery Mobile is all client-side enhancements using JavaScript and CSS. The library does not take any server-side liberties that is left to the developer.

    Quote Originally Posted by itmitică
    You have 111 occurrences for the "data-fapi-" token, in a 14 elements form. This is not right.
    If I remove the prefix if someone uses a library that makes reference to lets say data-widget (highly likely) than styles will be inherited that shouldn't be. Even worst JavaScript might be applied, make assumptions and break things. I am avoiding just about any potential for this to occur by using prefixes with the libraries name that is responsible for managing forms. If you have a better recommendation than let's hear it. Prefixing is the method that just about all the main stream libraries use to avoid potential naming conflicts or inheriting unwanted styles due to shared naming.

  21. #21
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by oddz View Post
    If you don't think so I challenge you. Take the HTML here and create a style sheet that provides the same presentation in a reusable form.
    It's not a challenge I'd run from, but you'd have to also hire/pay me.

    Quote Originally Posted by oddz View Post
    I don't really understand what your talking about. The CSS and JS isn't dynamic. A static style sheet has been created to account for the different permutations of form element based on various properties.
    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.

  22. #22
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by itmitică
    Which is the problem. You think you have to serve all the 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 for that request
    Step 2: Serve them up
    huh...

    I don't think you understand which is fine.

    Quote Originally Posted by itmitică
    It's not a challenge I'd run from, but you'd have to also hire/pay me.
    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.

  23. #23
    Non-Member
    Join Date
    Feb 2012
    Posts
    892
    Mentioned
    10 Post(s)
    Tagged
    0 Thread(s)
    OK. No harm done. Just my two cents.

    But I'd argue that you don't understand... yet.

  24. #24
    om nom nom nom Stomme poes's Avatar
    Join Date
    Aug 2007
    Location
    Netherlands
    Posts
    10,271
    Mentioned
    50 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by oddz
    Which link?
    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?

  25. #25
    SitePoint Wizard bronze trophy
    Join Date
    Jul 2006
    Location
    Augusta, Georgia, United States
    Posts
    4,139
    Mentioned
    16 Post(s)
    Tagged
    3 Thread(s)
    Quote Originally Posted by Stomme poes
    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.
    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.

    Quote Originally Posted by Stomme poes
    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).
    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.

    Quote Originally Posted by Stomme poes
    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.
    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.

    Quote Originally Posted by Stomme poes
    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.
    They are. Especially with the server-side technology I have to work with… (that is another story)
    The only code I hate more than my own is everyone else's.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •