CSS Selection of Elements By ID and CLASS with Special Characters

HTML & CSS
1

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


<!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\\\	extfield {
		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\
ame\	est">
</div>

<div class="fapi\\element fapi\\widget\	extfield fapi\
ame\	est-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

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


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


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


@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

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

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

4

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

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

Ok that makes it clearer -Thanks Mallory.

7

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

8

You only wanted funny CSS names as JS hooks?

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

9

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

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

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:


<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

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.

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.

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.

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

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

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.

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:


<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
ame\ est

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

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

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:


<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

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=mitică]As a note, if “data-fapi-” appears all over, it’s obvious that it should either appear just once, or not at all.[/quote] I thought that was why oddz was adding wrappers (so the attribute was only needed once).

18

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.

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.

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.

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.

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.

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.

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

If you changed it with another token, repeating seven times again, it’s not much of a trade.

<hr>

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. :slight_smile:

<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

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.

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.

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.