CSS Selection of Elements By ID and CLASS with Special Characters

**oddz** · Apr 12, 2012 20:56

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>

**itmitică** · Apr 12, 2012 23:01

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.

**Stomme poes** · Apr 13, 2012 02:17

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

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

**Paul O'B** · Apr 14, 2012 06:25

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.

**Stomme poes** · Apr 15, 2012 03:42

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 'Ø')

**Paul O'B** · Apr 15, 2012 06:54

Originally Posted by Stomme poes

On Mathias' other page on id's he says http://mathiasbynens.be/notes/html5-id-class#comment-4

Ok that makes it clearer -Thanks Mallory.

**oddz** · Apr 16, 2012 21:16

I decided to go with data attributes instead. Looking at this after a good nights sleep was just to convoluted for me.

**Stomme poes** · Apr 17, 2012 02:56

You only wanted funny CSS names as JS hooks?

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

**deathshadow60** · Apr 17, 2012 07:01

Originally Posted by oddz

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.

**oddz** · Apr 17, 2012 07:37

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

**deathshadow60** · Apr 17, 2012 09:07

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.

**oddz** · Apr 17, 2012 09:27

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.

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.

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.

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.

**oddz** · Apr 17, 2012 09:55

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

**deathshadow60** · Apr 17, 2012 10:08

Originally Posted by oddz

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.

Originally Posted by oddz

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.

**oddz** · Apr 17, 2012 10:44

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…

**itmitică** · Apr 17, 2012 11:52

Originally Posted by oddz

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.

**Stomme poes** · Apr 17, 2012 14:01

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.

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).

**oddz** · Apr 17, 2012 14:05

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.

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.

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.

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.

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.

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.

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.

**itmitică** · Apr 17, 2012 14:32

Originally Posted by oddz

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>

Originally Posted by oddz

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.

**oddz** · Apr 17, 2012 14:47

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.

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.

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.

**itmitică** · Apr 17, 2012 14:53

Originally Posted by oddz

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.

Originally Posted by oddz

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.

**oddz** · Apr 17, 2012 15:00

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.

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.

**itmitică** · Apr 17, 2012 15:03

OK. No harm done. Just my two cents.

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

**Stomme poes** · Apr 18, 2012 00:50

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?

**oddz** · Apr 21, 2012 12:51

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.

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.

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.

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)

User Tag List

Thread: CSS Selection of Elements By ID and CLASS with Special Characters

Thread Tools

Display

CSS Selection of Elements By ID and CLASS with Special Characters

Bookmarks

Bookmarks

Posting Permissions