Dean Edwards of IE7 fame, has an awesome javascript function called cssQuery. It allows you to select elements by css selectors. http://dean.edwards.name/my/

Posted by: Joe Theory

Thanks for your reply. So, looking at your sample with headings, I would like to explain a bit of my point of view. You're saying, that a h3 is a heading, this is true. It also specifies what has to be in it, but does it prevent you from adding _wrong_ data? It doesn't. You can put a hole paragraph within a heading and XHTML won't tell you that this is wrong (ok, it does from a logical point, but not from a practical). So, this is valid XHTML:

My very long, very stupid paragraph used as whatever it might be used. It might also be styled as a paragraph, but that really doesn't matter, doesn't it?

However, it is sementically wrong. But XHTML doesn't stop you doing this. And that is, what I meant. Another point to consider: form-elements aren't the same as other XHTML elements. They allow direct user input. Also it seems as if you have misunderstood my sample. The code I've shown won't create XHTML or something like that. It would add EventListeners to the structure and might change view properties. Thus I'm perfectly separating structure from behaviour. This also includes that someone with javascript disabled won't get hurt by it. When it comes to js-disabled user I'm one of those how try to don't hurt those user. The only purpose of Javascript is, to enhance the feel for those with JS enabled. Not realizing relevant elements with it. I'm just _modifying_ the structure with it, letting a functional version of it for those without JS. As an example: I've created a rich text editor for a CMS I've been working on. However, it only appears if the browser is able to work with it. The others get a textarea. So, I'm absolutly familiar with this thing. ;)

Posted by: R Cotton

2012-01-31T13:00:49+00:00

My very long, very stupid paragraph used as whatever it might be used. It might also be styled as a paragraph, but that really doesn't matter, doesn't it?

" But that is STILL a heading; the fact you've re-styled it to LOOK like a paragraph, and that you personally have decided the length makes it a "paragraph" in your mind, does not change the fact that it is IN FACT a heading... Recall, again, CSS may not be in effect, in which case it will render as a HEADING because the xhtml DOES carry structure information! And in the absence of anything better, that structure information will be used as presentation instructions; which means you must not go around redefining it on a whim!

Posted by: R Cotton

2012-01-31T13:00:49+00:00

Patrick, I seriously think you are confusing "what xml/xhtml supports/does" with "what a buggy/non-strict parser (browser) will let you get away with" You should form you mental abstractions of how things work based on the former, not the latter.

Posted by: Sebastian Redl

2012-01-31T13:00:49+00:00

Nice article. First, Patrick Gotthard, you are making a simple mistake here. You are saying that XHTML doesn't enforce the semantics of its content, even though it defines it. This is absolutely correct. You said: > So, having that said, does a modell know what > kind of data it is supposed to contain? I > don't think so. It just trusts on the > controller that prevents bad content from > being inserted. Well, in the case of XML dialects, it has already been shown that the model indeed knows what content it is supposed to contain. But, lacking the active capabilities, it cannot enforce this and must rely on the controller to enforce it. Given this view, it makes perfect sense to put a validate="..." attribute into the XHTML and read it out with JavaScript. Of course, in an ideal world we'd all be using XHTML 2.0 by now, where the Schema explicitely allows foreign attributes. Then we could just define them in a different namespace (if you're using any version of XHTML, you should do that anyway) and not mess with custom DTDs, which, among other things, mess up the validator's automatic charset detection. That said, there are some things in the article I disagree with. Mainly the thing about the class attribute: > However, the class attribute�s proper use is > defining CSS triggers. This is incorrect. The HTML standard says about class: --- The class attribute has several roles in HTML: * As a style sheet selector (when an author wishes to assign style information to a set of elements). * For general purpose processing by user agents. --- This "general purpose" processing very well includes behavioural hooks. But I do agree that class is not the right thing for everything. class="required" is all right (and you might want to style required elements differently anyway). class="maxlength:300" is not. class sorts elements into groups. That's all it should do. One more thing about events. I've developed a fairly complete group of functions that can be used to bind stuff to events. It supports the EventHandler functionality even for IE, meaning that you can bind an object that implements handleEvent (or whatever it's called) to an event instead of a function. This has big advantages if you want to carry information. I'll post it soon on my website.

Posted by: Patrick Gotthardt

2012-01-31T13:00:49+00:00

... all websites I made so far are valid XHTML 1.1 (no, thanks to IE I'm not sending the right content-type - lukily it is still only a "should be"- and not a "must be"-thing...). So, I'm familiar with webdesign. It's not required (or of any use) to explain the use of XHTML/CSS to me. Of course my work cannot be compared to what you guys do, but I'm pretty sure that I know what I'm doing. You won't see me using any not required element or anything not standard. > Given this view, it makes perfect sense to put a validate="..." attribute into the XHTML and read it out with JavaScript. If this would be possible - yes. But it isn't (you said it will be when XHTML 2.0 is supported? Sounds good - it's sad that this won't be supported for a long time... at least from IE). If you roll up with your own dialect of XHTML you're not using a standard (and this is the case when you create your own DTD). So, the result isn't a valid XHTML-page. Using what I suggested, the page would be absolutly valid XHTML and could contain this kind of additional functionality. If you take a look at what this article is about ("triggers" - or I would like to name them "Jump-In points" - for Javascripts) and then think about the solution the article has (create your own DTD and put a lot of your own self-made attributes in your side), then take also a look at where this would end. My suggestion: There would be people create an attribute for everything where they could need it. Just take a look at his first sample (the menu). Where would we end when we define an attribute for how the items are supposed to _behave_? We would end up with the same thing you've had (no, I haven't had this time - I started somewhere in 2002 with webdesign - and I'm happy about this) some years ago, using something that could be rendered on some ways by some browsers, but that wasn't a standard. This time you add an attribute for form-validation, the next time you add an element for something! What I want to say is quite simple, but maybe my english is so bad, that you're misunderstanding me... I will try to repeat it: Keep behaviour in the behaviour-part and don't put instructions on how something is supposed to _behave_ in the structure. From my point of view, the "class"- and "id"-attributes are structural as well. They help to identify the content of their elements (if they have good names). So, a link with a class "external" will not have that class because of instructions for the view, but for the structure. But things like form-validation / input-control (do you see that "control"? ;) ) are not part of the structure. And that is, what I wanted to say. Nothing else. An attribute "validate" is (just looking at the word) an instruction. Instructions are not part of a structure, or am I wrong when thinking that a structure itself is static? What does a "mask" say about an element? So, just to say it again, from my point of view an input-validation is part of the behaviour as instructions for it are. Therefor there is no need to put it into the structure. And creating a custom DTD when it is not required isn't worth this.

Posted by: None of your Business

2012-01-31T13:00:49+00:00

Well, if every Web designer now makes his own "standard" (that means: your own attributes in your own DTD) we are back again in 1996. With the small difference, that today not two browser manufacturers are writing the rules, but thousands of designers. If you use custom attributes there is no need for a Document Type Declaration or Document Type Definition in today's Web at all. Because you are not following existing standards (like HTML 4.01 or XHTML 1.0), there is not much need for validating to see if you follow those rules. Of course you might use custom DTDs in XML, but that is nothing that should be served in public on the Web. It might be fine on some XML applications on your intranet. When you want to publish on the Web, you have to follow standards like HTML 4.01, ISO-HTML, or XHTML 1.0. Otherwise we get a mess.

Posted by: None of your Business

2012-01-31T13:00:49+00:00

Posted by: Average Non-Programmer Idiot

2012-01-31T13:00:49+00:00

Respectfully... It seems absolutely snobbish to me to refer to people as idiots and not "real" programmers because of such minor things as people have pointed out. I happen to spend the majority of my time developing using HTML, CSS, and ECMAScript alongside other developers who program in primarily in JAVA. I constantly hear this pettiness about how I'm not a "real" programmer (even though I do program in C++ and JAVA). Some people seem to think that if you don't speak in the market speak given to you by some certification or didn't graduate with a CS degree that you are somehow less worthy of producing content then some others in the field. If there's an inconsistency in a term, something a laymen might interpret as the author expected but an "expert" would misinterpret, then do point it out. Or if there's an inaccuracy in the coding or a more efficient way, then do point those out also. It would be great though if the statements came with a little less of a judgemental tone and just a little less bickering happened. Treating each other like idiots isn't going to produce better sites or hone anyone's skills.