Please give me good reasons why this is forbidden -- other than IE the party pooper, and other than "they might invent a tag with that identifier one day":
Of course I would never use it for stuff I do for other people. that's a given. but when it comes to myself, well, I'd be the one taking the risk... and I just earlier had to think about how not long ago, everybody (including me) "properly closed" their br tags, just to validate - and for what? To now forget that ever happened. Heh.
Not saying this also applies here, but still, just doing what's right for the sake of some vague notion of doing what's right is not enough to stop me from at least seriously considering the potential uses of this... (I'm thinking mostly CSS/HTML complexity/size, but also fun and rock'n'roll, plus a way to give IE the finger :D)
[edit: And at the very least, kind of owe it to myself to make a website with no classes, no ID's, just tags! And make it real pretty too, so that people actually want to look at how it's made, bwahaha. Hmm I'm sorry, It's late/early here, I need to go to bed :P]
To be honest, I had no idea that this was even possible - it's a very cool idea. I'm sure there are accessibility issues there (screen readers and what not), though I could not cite them for you.
Yes, of course if you make up your own tags for just about everything, that would suck (as tempting as it would be to use "bq" instead of "blockquote", seeing how there is "q"...) I pay too little attention to accessibility anyway (who doesn't :/ ), but I don't want to make it worse for no good reason.
But what about d instead of div? and s instead of span? those have no semantical meaning anyway, right? so why use 13 or 11 characters where you could use 7... times a billion! It's mostly because I'm playing around with making my own CMS, so these things "pay off (a little) in bulk", and it's at least thinkable to change back again without dying inside. Otherwise I wouldn't bother, but I love shaving bytes off here and there :D
my god, do you want to set us back 20 years? Do you work for Microsoft? There are specifications for a reason - abide by them. There exists a language for what you want to do - XML
Regarding you're closing of elements: it was thought that the future of html resided in xml and so xhtml was born. It, as you know, required stricter syntax (which I think was a good thing). So you choose to use xhtml, while you could have stayed with html 4.01, but xhtml is dead now and won't be resuscitated. html5 is backwards compatible, so if you used self closing elements you can continue to do so, or if you wish, not do so.
But please, code with standards in mind. We (as a collective group of developers) have finally reached a point where the playing field is near level and not full of radioactive crud all for the sake of browser dominance. The future finally looks bright and you want to start making things up...
@joshuanhibbert well, then it should also be possible to extend such shims for custom elements :D
Although I'm *really* liking the idea of just saying bye to IE-(specific stuff) for good (for my own stuff, naturally), because it saves soooo much hackish BS which ruins the whole quest for elegance. So currently my plan is to make it look bearable in IE, no further effort/hacks, and completely ignore it javascript-wise when it comes to admin stuff, admins need to use real browsers.
And that means? I make websites, not browsers, I don't invent tags for others to use, either. So --- lol? I'm not setting standards for anybody, I make my own website.. Microsoft, heh. If my website breaks, because "d" and "s" suddenly get a meaning (very likely, yes?), that's my loss. And yes, I knew about XML, but my point is, it never mattered. It mattered for strict validation, not ever for rendering. Well, in some cases, but people simply blindly did it. So if "abide by the standard" is just another wording for "they might invent a tag with that name some day", then read the first post. I'd take that risk :P
Don't worry... I know my stuff well enough to simply do what I wanna do. And I'm aware it's an, uhh, offensive question for some, and I can see why. But still... when for example about everyone uses jquery instead of learning javascript, that's fine, but when I use d instead of div for my own little site, I'm Microsoft? That doesn't offend me, I find that funny ^^
"In terms of accessibility this would be horrific"
... that makes no sense to me, sorry! How is a div or a span "accessible", or different in even just *one* aspect from a made up tag like "d" ? They contain zero semantics to begin with, any meaning they might have they get from CSS humans make.
Yet I have to admit, I am really hard pressed to find a good use for this, lol. replacing all div's by d on a normal page results in zero gain, just about anything else I could change would have a more drastic effect. But for example <clr></clr> instead of <div class="clr"></div> = tempting! Or maybe "cl_" because that doesn't seem likely to ever become an official tag.
You see, there IS no official tag for clearing, and when you come across class="clear" in a document, you are not supposed to assume any semantical meaning. So what's the problem? What is the difference between <div class="some_class_you_never_heard_of"> and <some_tag_you_never_heard_of> ? Both are semantically void. That is the bottomline.
HTML5 doesn't have self-closing tags now because "it's not XML" or something. Great. Instead of simply making certain tags empty, and allowing that short syntax for tags that need to be closed... bleh! Now, I don't want to be ungrateful, when I read the w3 specs I am often amazed at the detail, my hat truly is off to these people that they can agree on ANYTHING, much less so much useful stuff. But that doesn't mean everything makes sense to my little head. So as long as I can get away with it, why not make my own website as *I* want it? If it's unaccessible, the web will cope :P
What exactly do you think making your own stylesheet lego blocks is, in a way? Anyone doing anything remotely interesting is inventing their own conventions for things on a small scale. So call that HTML5+J or something... your browser understands it, it's just that you don't :P
"but don't screw the one that works ;]"
Dude, winking smileys do not replace a clueful argument, and you don't seem to have one. How is the HTML bastardization I come up with affecting how others make their website, or the standard? Not at all. To compare this to Microsoft having a monopoly with a crappy browser -- wow.
And people "like me" set stuff back? Because I think for myself and make wacky stuff for myself? LMAO!!! Yeah, of course ^^ If those are your arguments, they are actually FOR doing it, I thought you might want to know that.
I never learned flash, cuz it's Adobe. The same goes for MS stuff. Right now I am getting into javascript and try to avoid jquery et al for as long as I can, maybe forever. No minifying, either.
How many of you guys can say that? "use jquery, use the CDN", yay new interwebs. And because I am even just *considering* to use d instead of div, I get clearly identified as some who sets stuff back? This seriously makes me want to do this. If this is enough to bring out the mindlessness, bring out the mindlessness, where I can burn it easily.
@Johann - perhaps this thread has gone a little sideways, but for the most part it seems like you have made your mind up already! If accessibility, SEO, and IE aren't a priority for personal projects - then go for it! It would certainly be an interesting experiment at the very least.
I don't mean to criticize and I'm not attacking you, but I'm finding this thread outrageous. My comments of '20 years ago' and 'work for Microsoft' were not arbitrary insults, but realistic references to when browsers were in their infancy and how MS thought they could do whatever they wanted and not follow the specs (that they even took part in creating), like you're implying here. It's funny how you bash IE, but wish to ignore the specs and standards (only with code, not rendering).
I'd like to address some things and then I'll keep my peace. I think you're very naive in these matters and when I use the word naive, it's not an insult. I can appreciate what you're trying to do and it's good that you're thinking outside the box, but this really doesn't make any sense. You make mention of reading the specs and that is commendable.
The opening post doesn't state that this is just for your own personal site, which I personally think still doesn't justify it, but I regress. You later state such and obviously you're free to do whatever you want, but I think the replies are based on the idea that others would follow your practices. This whole concept is built on a bad premise anyway - that error handling by all browsers will be the same. But guess what? The same specs that you wish to ignore don't specify how error handling is to be done. So at any time, browsers can do different things with your error filled code (error handling, for the first time, will be a part of html5, but that part of the standard won't be complete for a long time).
There does exist a way to create your own elements. You can use XML or you can create your own DTD. Your first reply to me makes it seem as if you think XML is dead - it's not, it's very much alive. Xhtml is dead (although will be supported for years to come), but it wasn't followed blindly - yes browsers rendered it without closing tags and invalid code, but again you're relying on error handling. Not a good way to do things. I don't think creating your own entire DTD would save you the precious bytes you're looking to shave. You're correct, 'd_l is shorter than div style="float:left;"', but how does a browser know what to do with a d_l without the DTD and base stylesheet? You'd need to create those. And while we're on this specific topic, your 'd_l' is truly only replacing 'div' - the inline styling shouldn't be there in the first place. They both need styling.
How is a div or a span "accessible", or different in even just *one* aspect from a made up tag like "d" ? They contain zero semantics to begin with, any meaning they might have they get from CSS humans make. They get zero meaning from CSS. You've picked the only two non-semantic elements in html. They exist for structure only and have come to be because developers and spec writers saw the need for structure within html. Pick a different element, say 'input' to 'in' or 'legend' to 'l' etc. and now hardware used to help people with visual, hearing, and mobility impairments, hardware that adheres to the specs, fails. Further, search engines and other computer devices will not be able to understand your code. Sure it might not be a concern to you with your site, but again this discussion isn't really about what testing you want to do, but why creating your own elements is a bad idea.
You then give the example of a <clr></clr> to replace <div class="clr"></div>. Well first, I advocate all the time to never use empty elements. There are a half dozen ways to clear or contain a float - there's simply no reason to use the empty div (or clr). And even if you created that element, how's the browser know to clear it? You need to style it - and what did you save? Now you're going even a step further and introducing styling tags into the markup language. Something we've eradicated over the years and for good reason.
HTML5 doesn't have self-closing tags now because "it's not XML" or something. Great. Instead of simply making certain tags empty, and allowing that short syntax for tags that need to be closed... bleh! As I said in a previous post, html5 is backwards compatible. It allows for self-closing tags. You're free to use them or not. Your statement doesn't make any sense anyway - you're complaining that html5 took away the self-closing tags and doesn't allow for the shorter self closing tag. But those tags don't need to be closed - they're even shorter not closed!
"if you want, invent your own language why not" - What exactly do you think making your own stylesheet lego blocks is? I don't see how creating a stylesheet in any way resembles creating a new (markup) language. People creating stylesheets that style or define 'anything remotely interesting' are not creating their own conventions - they're following an existing set of specifications.
You mention you're learning javascript and want to steer clear of jquery and that most everyone is using it mindlessly (and I agree to a point, along with resets, and html5 boilerplate, and grid systems, etc.). Learning javascript first is an excellent decision. But it won't be long before you discover that any javascript coder will create and use a library - whether their own or pre-built. That's all jquery is - a javascript library (and damn good one at that). You also mention that you won't minify either, but isnt that the whole reason you want to create new elements in the first place? To save a few bytes? I truly don't see the correlation between using a javascript library and making up new elements.
And that is all from me. I am sorry if I offended you in either of my posts - that was not my intention.
"how MS thought they could do whatever they wanted and not follow the specs (that they even took part in creating), like you're implying here"
This is not at all the same though. Microsoft, by what they did or didn't do, effectively set the standards for others. Microsoft thought they could do what they want to others, I think I can do what I want to my own website. The assumption that others might follow my "example" is just that, an assumption. Just like I would assume unknown tags to be handled as they are handled now. I'd say that's a wash at most.
You've picked the only two non-semantic elements in html. They exist for structure only and have come to be because developers and spec writers saw the need for structure within html. Pick a different element, say 'input' to 'in' or 'legend' to 'l' etc.
That makes no sense. I can't redefine those tags, can I? I can just create "new empty ones", like div and span, that are void of meaning. I "picked" those two because they are the only two that behave in the same way... and you're saying they are the ones I shouldn't pick for comparison? Well nope.
Well first, I advocate all the time to never use empty elements. There are a half dozen ways to clear or contain a float - there's simply no reason to use the empty div (or clr).
You have several floating elements. Some or none might be printed, so you wouldn't know which one to put the clearfix on without complicating rather simple code just for that. So either you make a class for a float-group and apply the clearfix to the :last-child, OR you put the empty clearing tag there. If there are other ways, I simply haven't come across them yet.
Now you're going even a step further and introducing styling tags into the markup language. Something we've eradicated over the years and for good reason.
Well, you say that, I totally disagree. Classes for styling purposes on container div's and styling tags are essentially the same. Of course you need to still style them -- but instead of styling something with a class, you style a tag. And by the way, with long names that takes up more space than using a class...
"I don't see how creating a stylesheet in any way resembles creating a new (markup) language."
And I don't see how that is creating a new markup language. I ask, again, what semantically different between [div class="something"] and [something]? In both cases, the meaning is in the CSS. http://en.wikipedia.org/wiki/Span_and_div
"However, as span and div have no innate semantic meaning besides the logical grouping of the content, they can be used to specify non-standard presentation or behaviour without superfluous semantic meaning."
You say "new tags" create new semantic meaning, but I disagree. They too simply group content, and just like it's enough for the webite to know the meaning of classes, the same would apply to made up tags.
I still haven't been able to think of one good use for making up tags, by the way. Most stuff has classes anyway, and my class names are economic enough, so mixing classes is shorter as well as more readable than nesting tags :P
This is from the HTML 2.0 specs, I have no clue how this applies today, but it's the best I could find so far:
4.2.1. Undeclared Markup Error Handling
To facilitate experimentation and interoperability between implementations of various versions of HTML, the installed base of HTML user agents supports a superset of the HTML 2.0 language by reducing it to HTML 2.0: markup in the form of a start-tag or end- tag, whose generic identifier is not declared is mapped to nothing during tokenization. Undeclared attributes are treated similarly. The entire attribute specification of an unknown attribute (i.e., the unknown attribute and its value, if any) should be ignored.
In other words, you cannot ever depend on browsers styling unknowing tags, you could even say IE is doing it right, which is offensive but true :P
"You also mention that you won't minify either, but isnt that the whole reason you want to create new elements in the first place? To save a few bytes?"
Well, actually I do compress stuff where I can, and I wouldn't even mind minifying serverside, though I'd provide cookie preferences to get it unminified. But sure, of course it was silly to "brag" about not minifying (which is effectively obfuscation -- all the descriptive variable names, *poof*!), and I don't even mean to diss jquery, I'd use it without hesitation on a big project - but still, I can't "create new elements" other than making a browser a lot of people use, or being a part of the w3c efforts etc. Your comparison with semantic elements does not apply. Everybody is making "new (functional) elements" by combining classes and id's and javascript, anyway, just like we use tags without meaning to give them meaning via stylesheets.
I brought up jquery because many people are happily jumping into black boxes just to get the same shiny effects others have. In the case of jquery that's fine, because you at least still can get it unminified, but the point is, in practice that ain't happening. They're just making it easier, yes, kinda like I'd be making it easier for myself, and harder for nobody else -- so how is that "being Microsoft"? How is it "creating new elements" and "destroying what everybody worked so hard for"? I can totally see how it's a waste of time to talk about it, much less do it, but come on, get some perspective..
What I would be doing is use what browser are allowing for, style unknown elements, which is in violation of the specs -- and it would work fine in those browsers as long as they do that, and as long nothing else changes. There is no semantic difference between [div class="some_class_you_need_the_stylesheet_to_understand_the_meaning_of"] and [some_tag_you_need_the_stylesheet_to_understand_the_meaning_of]. But it was silly bring it up I guess. I was asking for good reasons not to do it, so far I got strawmen mostly, and the only real reasons I can see is IE and that browsers might change error handling in the future. I think I can deal with both, should I ever find a good reason to use it. Thanks for the input and sorry for asking.
@Johann Don't be sorry for asking at all. Just remember not to take any responses personally, they are only opinions. I think it was a great question and I have learnt from it, so I'm certainly glad you asked it.
A final thought, if you are doing to it save space, but then need to use JavaScript to create the DOM elements, well it probably isn't saving any space.
@joshuanhibbert Well, to be honest, I'm not really doing it (yet)... I seriously found no good reason for it yet, and no reason to look real hard for one, either. But I'll keep it in mind, and should I ever have to generate so many div's (with classes and a few chars in them each) programmatically that using "dX" instead would save a reasonable amount of bytes, I'd do it. Hah! :P
And I don't feel offended as much as I worry about being offensive. It's not a topic ranting a lot over I think. I just like to question everything every now and then ^^
oops, edit:
"A final thought, if you are doing to it save space, but then need to use JavaScript to create the DOM elements, well it probably isn't saving any space."
You mean the shim taking up more space? As I said, just about anything else I could optimize would save more, I know that ^^ It's a rather theoretical question really.
"Have you had a look at haml?"
Well, it's ruby so that's right out for me/my webhost :P
remember that Google will read your content - and tags tell it what you are declaring as important... H1, H2 strong, em all of them paint a picture Google reads to pick up on keywords. Having none-standard tags will obviously hinder that, as it would be basically a different language to Google.
I've actually played around with this idea as well. On top of making tags that didn't exist, I also added attributes and what not to further customize or 'brand' my page. For example
There doesn't always have to be content in the tags as well -- considering I'm sure everyone here has used empty div's before. The reason I didn't go past the 'toying around' phase was because I wanted my site to be crawlable and there are some necessary tags like Title that I couldn't live without. My logic was to go big or go home. Well, I went home instead. I say have fun with it. Rules were meant to be broken right?
The main reason creating your own elements is discouraged is similar to the reason you don't make up your own words in any language: not everyone will understand you. Of course, you can use CSS (and some JS to make IE behave), and browsers will display your new tags as you tell them, but other user agents won't have a clue what you're talking about.
It may seem like <div> doesn't have any meaning, but it actually does; it means this content is separate from other content — a division. Maybe that isn't an important meaning to you, but to HTML parsers, it could be a reliable way to group and separate content. In fact, all HTML elements have meaning, some are just more obvious than others.
As you say, this is for your own personal stuff, so if it works for you, and you don't care if it only makes sense to people viewing it in a browser, then by all means proceed. Just make sure that you don't go spreading it around and recommending it to others. Most standards advocates have tried very hard to encourage a standard set of Web languages to make our lives easier, so they don't take kindly to someone that wants to mess that up.
"The main reason creating your own elements is discouraged is similar to the reason you don't make up your own words in any language: not everyone will understand you. Of course, you can use CSS (and some JS to make IE behave), and browsers will display your new tags as you tell them, but other user agents won't have a clue what you're talking about."
The same goes for spans and divs. They make no sense without the stylesheet, other than grouping content which all tags do.
"It may seem like doesn't have any meaning, but it actually does; it means this content is separate from other content — a division."
ehm. That goes for most tags, and all unknown ones. It's what the DOM does, make pretty node trees. What you said about the div goes for a, span, h#, all of them. They are "a division"...
Look, I do realize that if I wanted to save bandwith etc., I might as well send json and construct the HTML on the client via javascript. "Making up tags" is just a thing that is possible, but useless... However, I don't get anything out of being talked to like a baby ^^
"Maybe that isn't an important meaning to you, but to HTML parsers, it could be a reliable way to group and separate content. "
Not only does it matter to me, it's a given, and goes for all tags. What you are talking about is moot.
"Just make sure that you don't go spreading it around and recommending it to others."
lol? How about, unless you actually have a good answer to even ONE of my questions, you don't worry your head about what I might or might not do? Maybe consider it separation of theoretical questions and practical advice, and ask yourself, can you do it? Can you discuss something theoretically without thinking the sky is falling?
"Most standards advocates have tried very hard to encourage a standard set of Web languages to make our lives easier, so they don't take kindly to someone that wants to mess that up."
I "want to mess that up"? Hahah. I'm asking a question -- which makes movies play in people's heads, yeah, but that's not my concern. My concern is what I'm actually doing, which when it comes to making up tags didn't go farther than jsfiddle. Saying "div is a division", ignoring that this goes for all tags, is just FUD. That's not upholding any standard. I at least try to actually know the rules I'm breaking.
You had to make it seem that way I guess, but ultimately you cannot answer either what the difference (semantically and in practice) between div's with classes and made up tags is. You claim div tags have meaning even the W3C doesn't seem to be aware of, and then I'm the one messing stuff up? Awww. ^^
Well, I'm not the one arguing for something to be used, am I ;) Or the one making up stuff about semantic meanings of tags they don't have... haha.
Also, take a look at the wikipedia main page. Turn off stylesheets. Tada, still looks neat thanks to using a table. And no, I don't use tables myself for layout, but when you, uhhh, need to put stuff in tables, they are perfect -- yet some people seem to think it's "better" not to use them, so they make something awkward with proportionally sized floats and what not: more HTML, more CSS, *still* doesn't behave like a table....that's exactly the mindlessness I will have zero to do with :P
In practice, they are used to list a lot of stuff with everything still being aligned, properly. Which of course only makes sense for tabular data... which 99% of the data on the web is though, it's just that usually we have no use to display them that way.
Consider this thread: is it a table, or a list? Maybe that's MySQL speaking, but in my mind, that's a table that doesn't look like one. Each post has author, content, permalink, etc. When each listed iten has the same fields as the others, that's a table, a spreadsheet, whatever you want to call it, and however you want to dress it up.
People see differences where there aren't any real ones. If instead of nesting divs you use unordered list items that get coerced into not looking like the bulleted lists they were "supposed to be", you're not adding one shred of information. Children are grouped by the parent they belong to. All of them, always. Essentially, that's using ul and li instead of having to give divs classes, or the selectors having to taking more descendants into account. Nothing semantic about it at all, and that people would flame me for pointing that out, doesn't make them correct. A lot of this posing around semantics is built on sand, really. A lot of stuff has good reasons, yeah, but people don't seem to know them. And if you mistake my refuting of BS as advocating making up tags (see your table guy analogy), that's yours ^^
Sure, there are a billion ways to center stuff, and I might yet find a nicer one. But I was actually lying before: until I found out about the values for the display property, I did use tables for layout, that is, to get stuff to actually center. (I still have loads of that around, and will change it when I come across it -- but until then I consider that bait for people who obsess about things that don't actually matter :P)
And none of the "cleaner" ways are actually remotely clean, even the ones that don't work in IE... as always, doing just what you're supposed to do doesn't get you very far: you can have a semantic, clean site, or a good looking one. That is rapidly changing, but to pretend the web is semantic more than not is hilarious to me, sorry.
"I feel you, man. I know what it's like when you're wrong but you wanna be right."
Heh, the irony. Weak ad-hominems don't make arguments, and so far that's the arguments I get. And flat out incorrect statements about semantics, which I refuted -- care to refute that in turn? No? So why comment, with that table guy bs for example? Heh... I know what it feels like, awww... alas, arguments you don't really seem to have.
And I hate to break it to you: tables do exist for layout. They exist to make tables of data look in a way that things are spatially related to which they are logically related to, without having to have any knowledge of the dimensions of the cells before hand. Sure, they are abused to layout on top of that, but the reason they came to exist IS layout (of tabular data). And they do what they do just fine, other elements don't.
I've seen phpBB skins that use definition lists for thread title, post count etc. It's just silly. That is tabular data, and recreating it without tables doesn't work half as well... but I bet you, someone felt as if they were being very semantic when they did that :P Prolly even mentioned to someone that they're now "not using tables for layout" anymore, heh. Whatever makes people happy I guess, but I find it hard to keep a straight face with some of that stuff.
Browsers often display invalid HTML as valid HTML just fine. The only problem with this is that the browsers don't know what to do with it. So unexpected behavior will probably occur.
HTML is a spec that helps things display consistently across browsers, so follow it or don't. Use javascript to make your markup work, or don't. It's just a matter of doing things they way they should be done for consistency.
I've got an idea for you, Johann. You know what I'm sick of? Closing tags. Why don't you write a script that would turn this:
<div> <span> Foo </> </>
Into this:
<div> <span> Foo </span> </div>
I mean, it's less HTML right? The script can work across all browsers.
Actually... Why Have all that unnecessary junk. Lets make the script turn this:
div{ span{ Foo } }
Into this:
<div> <span> Foo </span> </div>
It will be horrible for accessibility, but whatever, less bytes = #winning, amirite?
You know what, Johann, I have a serious question to ask you. And this question is as sincere as your OP: Why not create a script, that turns this:
That way you can have your cake and eat it too. Develop with custom tags, output valid HTML. You can create an ant built or something that would turn that into actual HTML. Great for accessibility and great for you. (I'm not saying only use divs, you can create rules to make lists, etc. You get what I mean: HTML out of your own markup - Example: Less)
HTML is HTML. People aren't complaining that javascript should just BE jQuery, they make javascript work for them and jQuery emerged.
So stop complaining about the HTML standard and use it to work for you.
Apparently, I touched a nerve. If I offended you or sounded condescending, I apologize; that wasn't my intent. I do think that you have a misunderstanding of some concepts, though.
First of all, a div is a literal "division" of content — not all tags carry that meaning, even if they do separate content from other content. Here's an example:
Just because div has been often abused and used strictly for styling or scripting, doesn't mean that it doesn't have meaning, even if that meaning may be obscure to many people. HTML 5 is trying to remedy that and actually has changed the role of div, but it's not a perfect process, and will take some trial and error. Still, nit-picking about tags such as <div> and <span> doesn't change the overall argument that the reason you don't make up tags is that not all technologies will understand what you mean. I'm not sure how I could have made that point clearer. It appears that that isn't very important to you, and at this point, I doubt you'll change your mind.
If all you're looking for is what you call "practical advice," then you're not likely to find any, because I assume you mean standard, run-of-the-mill websites, when you refer to "practical." The Web will continue to evolve beyond our current browsers and semantics in markup will become more important. The reason I say "don't mess that up," is because you'd be holding that process back. Of course, you're free to do what you think is best for your own projects from a "practical" view, but we "theoretical" people would appreciate it if you didn't downplay the importance of standard elements.
"So stop complaining about the HTML standard and use it to work for you."
Heh. I'm not complaining, I'm just responding to strawmen, and why not. If you make assumptions about me, why wouldn't I feel entitled to respond? See how that works? I asked rather simple questions. So far none of you has been able to answer what the semantical difference is between div="classname" and classname. Because there is none.
Oh, and I wouldn't expect browsers to do *anything* with void tags other than nest and style them -- though the specs seem to suggest they should be completely ignored.
"Just because div has been often abused and used strictly for styling or scripting, doesn't mean that it doesn't have meaning, even if that meaning may be obscure to many people."
Look, either you flat out state the semantic meaning, or you save me repeating that. Or maybe address what I and others said about their actual semantic meaning. Obscure, lol. Ad-hominem city this is.
First of all, a div is a literal "division" of content — not all tags carry that meaning, even if they do separate content from other content. Here's an example:
Huh. In your example, tags do indeed separate content from other content -- heading from paragraph for example.
HTML 5 is trying to remedy that and actually has changed the role of div
"You should use [div] when there is no other more semantically appropriate element that suits your purpose. Its most common use will likely be for stylistic purposes — i.e., wrapping some semantically marked-up content in a CSS-styled container."
Nothing changed. Nothing semantical about a div, nothing semantical about an unkown tag. The only difference is, being able to use unknown tags is using browser behaviour, not standards, and is therefore risky. But semantically? lol!
"but we "theoretical" people would appreciate it if you didn't downplay the importance of standard elements."
Right. Where I am doing the above? I simply said div and span are void of semantic meaning. That's a fact, ask the w3c if you don't believe me. They group content, which all nestable tags do. In other words, they do nothing. Now THAT is what I call actually paying attention to theory, instead of just mindlessly repeating. "tables should never be used for layout", haha.
@Johann - I feel like you're throwing a temper tantrum if someone disagrees with you. You're simply a repeat of the "table guy", not because of what he said but the way he said it. People are being negative with you because you're being argumentative and it shows by you knowing exactly what I meant by "layout". At this point you're just trolling with your rhetoric.
http://jsfiddle.net/FhqKg/
And no, I'm not trolling, I'm seriously asking. Feel free to flame me, I probably deserve it for being a reckless fool, but it's a honest question :)
Not saying this also applies here, but still, just doing what's right for the sake of some vague notion of doing what's right is not enough to stop me from at least seriously considering the potential uses of this... (I'm thinking mostly CSS/HTML complexity/size, but also fun and rock'n'roll, plus a way to give IE the finger :D)
[edit: And at the very least, kind of owe it to myself to make a website with no classes, no ID's, just tags! And make it real pretty too, so that people actually want to look at how it's made, bwahaha. Hmm I'm sorry, It's late/early here, I need to go to bed :P]
But what about d instead of div? and s instead of span? those have no semantical meaning anyway, right? so why use 13 or 11 characters where you could use 7... times a billion! It's mostly because I'm playing around with making my own CMS, so these things "pay off (a little) in bulk", and it's at least thinkable to change back again without dying inside. Otherwise I wouldn't bother, but I love shaving bytes off here and there :D
There are specifications for a reason - abide by them. There exists a language for what you want to do - XML
Regarding you're closing of elements: it was thought that the future of html resided in xml and so xhtml was born. It, as you know, required stricter syntax (which I think was a good thing). So you choose to use xhtml, while you could have stayed with html 4.01, but xhtml is dead now and won't be resuscitated. html5 is backwards compatible, so if you used self closing elements you can continue to do so, or if you wish, not do so.
But please, code with standards in mind. We (as a collective group of developers) have finally reached a point where the playing field is near level and not full of radioactive crud all for the sake of browser dominance. The future finally looks bright and you want to start making things up...
Although I'm *really* liking the idea of just saying bye to IE-(specific stuff) for good (for my own stuff, naturally), because it saves soooo much hackish BS which ruins the whole quest for elegance. So currently my plan is to make it look bearable in IE, no further effort/hacks, and completely ignore it javascript-wise when it comes to admin stuff, admins need to use real browsers.
And that means? I make websites, not browsers, I don't invent tags for others to use, either. So --- lol? I'm not setting standards for anybody, I make my own website.. Microsoft, heh. If my website breaks, because "d" and "s" suddenly get a meaning (very likely, yes?), that's my loss. And yes, I knew about XML, but my point is, it never mattered. It mattered for strict validation, not ever for rendering. Well, in some cases, but people simply blindly did it. So if "abide by the standard" is just another wording for "they might invent a tag with that name some day", then read the first post. I'd take that risk :P
Because d_l is shorter than div style="float:left;" (or even div class="fleft" as I have it now *),
if you want, invent your own language why not
but don't screw the one that works ;]
He was just asking, being curious.
It might be wrong, but seriously, play it cool. He actually makes a fair point, in a sense. My argument would be, where would you draw the line?
You do need some "structure" and "standards". Helps people learn more than anything. Also accessibility is a big issue here.
"In terms of accessibility this would be horrific"
... that makes no sense to me, sorry! How is a div or a span "accessible", or different in even just *one* aspect from a made up tag like "d" ? They contain zero semantics to begin with, any meaning they might have they get from CSS humans make.
Yet I have to admit, I am really hard pressed to find a good use for this, lol. replacing all div's by d on a normal page results in zero gain, just about anything else I could change would have a more drastic effect. But for example <clr></clr> instead of <div class="clr"></div> = tempting! Or maybe "cl_" because that doesn't seem likely to ever become an official tag.
You see, there IS no official tag for clearing, and when you come across class="clear" in a document, you are not supposed to assume any semantical meaning. So what's the problem? What is the difference between <div class="some_class_you_never_heard_of"> and <some_tag_you_never_heard_of> ? Both are semantically void. That is the bottomline.
HTML5 doesn't have self-closing tags now because "it's not XML" or something. Great. Instead of simply making certain tags empty, and allowing that short syntax for tags that need to be closed... bleh! Now, I don't want to be ungrateful, when I read the w3 specs I am often amazed at the detail, my hat truly is off to these people that they can agree on ANYTHING, much less so much useful stuff. But that doesn't mean everything makes sense to my little head. So as long as I can get away with it, why not make my own website as *I* want it? If it's unaccessible, the web will cope :P
"if you want, invent your own language why not"
What exactly do you think making your own stylesheet lego blocks is, in a way? Anyone doing anything remotely interesting is inventing their own conventions for things on a small scale. So call that HTML5+J or something... your browser understands it, it's just that you don't :P
"but don't screw the one that works ;]"
Dude, winking smileys do not replace a clueful argument, and you don't seem to have one. How is the HTML bastardization I come up with affecting how others make their website, or the standard? Not at all. To compare this to Microsoft having a monopoly with a crappy browser -- wow.
And people "like me" set stuff back? Because I think for myself and make wacky stuff for myself? LMAO!!! Yeah, of course ^^ If those are your arguments, they are actually FOR doing it, I thought you might want to know that.
I never learned flash, cuz it's Adobe. The same goes for MS stuff. Right now I am getting into javascript and try to avoid jquery et al for as long as I can, maybe forever. No minifying, either.
How many of you guys can say that? "use jquery, use the CDN", yay new interwebs. And because I am even just *considering* to use d instead of div, I get clearly identified as some who sets stuff back? This seriously makes me want to do this. If this is enough to bring out the mindlessness, bring out the mindlessness, where I can burn it easily.
I don't mean to criticize and I'm not attacking you, but I'm finding this thread outrageous. My comments of '20 years ago' and 'work for Microsoft' were not arbitrary insults, but realistic references to when browsers were in their infancy and how MS thought they could do whatever they wanted and not follow the specs (that they even took part in creating), like you're implying here. It's funny how you bash IE, but wish to ignore the specs and standards (only with code, not rendering).
I'd like to address some things and then I'll keep my peace. I think you're very naive in these matters and when I use the word naive, it's not an insult. I can appreciate what you're trying to do and it's good that you're thinking outside the box, but this really doesn't make any sense. You make mention of reading the specs and that is commendable.
The opening post doesn't state that this is just for your own personal site, which I personally think still doesn't justify it, but I regress. You later state such and obviously you're free to do whatever you want, but I think the replies are based on the idea that others would follow your practices. This whole concept is built on a bad premise anyway - that error handling by all browsers will be the same. But guess what? The same specs that you wish to ignore don't specify how error handling is to be done. So at any time, browsers can do different things with your error filled code (error handling, for the first time, will be a part of html5, but that part of the standard won't be complete for a long time).
There does exist a way to create your own elements. You can use XML or you can create your own DTD. Your first reply to me makes it seem as if you think XML is dead - it's not, it's very much alive. Xhtml is dead (although will be supported for years to come), but it wasn't followed blindly - yes browsers rendered it without closing tags and invalid code, but again you're relying on error handling. Not a good way to do things. I don't think creating your own entire DTD would save you the precious bytes you're looking to shave. You're correct, 'd_l is shorter than div style="float:left;"', but how does a browser know what to do with a d_l without the DTD and base stylesheet? You'd need to create those. And while we're on this specific topic, your 'd_l' is truly only replacing 'div' - the inline styling shouldn't be there in the first place. They both need styling.
How is a div or a span "accessible", or different in even just *one* aspect from a made up tag like "d" ? They contain zero semantics to begin with, any meaning they might have they get from CSS humans make. They get zero meaning from CSS. You've picked the only two non-semantic elements in html. They exist for structure only and have come to be because developers and spec writers saw the need for structure within html. Pick a different element, say 'input' to 'in' or 'legend' to 'l' etc. and now hardware used to help people with visual, hearing, and mobility impairments, hardware that adheres to the specs, fails. Further, search engines and other computer devices will not be able to understand your code. Sure it might not be a concern to you with your site, but again this discussion isn't really about what testing you want to do, but why creating your own elements is a bad idea.
You then give the example of a <clr></clr> to replace <div class="clr"></div>. Well first, I advocate all the time to never use empty elements. There are a half dozen ways to clear or contain a float - there's simply no reason to use the empty div (or clr). And even if you created that element, how's the browser know to clear it? You need to style it - and what did you save? Now you're going even a step further and introducing styling tags into the markup language. Something we've eradicated over the years and for good reason.
HTML5 doesn't have self-closing tags now because "it's not XML" or something. Great. Instead of simply making certain tags empty, and allowing that short syntax for tags that need to be closed... bleh! As I said in a previous post, html5 is backwards compatible. It allows for self-closing tags. You're free to use them or not. Your statement doesn't make any sense anyway - you're complaining that html5 took away the self-closing tags and doesn't allow for the shorter self closing tag. But those tags don't need to be closed - they're even shorter not closed!
"if you want, invent your own language why not" - What exactly do you think making your own stylesheet lego blocks is?
I don't see how creating a stylesheet in any way resembles creating a new (markup) language. People creating stylesheets that style or define 'anything remotely interesting' are not creating their own conventions - they're following an existing set of specifications.
You mention you're learning javascript and want to steer clear of jquery and that most everyone is using it mindlessly (and I agree to a point, along with resets, and html5 boilerplate, and grid systems, etc.). Learning javascript first is an excellent decision. But it won't be long before you discover that any javascript coder will create and use a library - whether their own or pre-built. That's all jquery is - a javascript library (and damn good one at that). You also mention that you won't minify either, but isnt that the whole reason you want to create new elements in the first place? To save a few bytes? I truly don't see the correlation between using a javascript library and making up new elements.
And that is all from me. I am sorry if I offended you in either of my posts - that was not my intention.
But I would have to agree with that being said.
This is not at all the same though. Microsoft, by what they did or didn't do, effectively set the standards for others. Microsoft thought they could do what they want to others, I think I can do what I want to my own website. The assumption that others might follow my "example" is just that, an assumption. Just like I would assume unknown tags to be handled as they are handled now. I'd say that's a wash at most.
You've picked the only two non-semantic elements in html. They exist for structure only and have come to be because developers and spec writers saw the need for structure within html. Pick a different element, say 'input' to 'in' or 'legend' to 'l' etc.
That makes no sense. I can't redefine those tags, can I? I can just create "new empty ones", like div and span, that are void of meaning. I "picked" those two because they are the only two that behave in the same way... and you're saying they are the ones I shouldn't pick for comparison? Well nope.
Well first, I advocate all the time to never use empty elements. There are a half dozen ways to clear or contain a float - there's simply no reason to use the empty div (or clr).
You have several floating elements. Some or none might be printed, so you wouldn't know which one to put the clearfix on without complicating rather simple code just for that. So either you make a class for a float-group and apply the clearfix to the :last-child, OR you put the empty clearing tag there. If there are other ways, I simply haven't come across them yet.
Now you're going even a step further and introducing styling tags into the markup language. Something we've eradicated over the years and for good reason.
Well, you say that, I totally disagree. Classes for styling purposes on container div's and styling tags are essentially the same. Of course you need to still style them -- but instead of styling something with a class, you style a tag. And by the way, with long names that takes up more space than using a class...
"I don't see how creating a stylesheet in any way resembles creating a new (markup) language."
And I don't see how that is creating a new markup language. I ask, again, what semantically different between [div class="something"] and [something]? In both cases, the meaning is in the CSS. http://en.wikipedia.org/wiki/Span_and_div
"However, as span and div have no innate semantic meaning besides the logical grouping of the content, they can be used to specify non-standard presentation or behaviour without superfluous semantic meaning."
You say "new tags" create new semantic meaning, but I disagree. They too simply group content, and just like it's enough for the webite to know the meaning of classes, the same would apply to made up tags.
I still haven't been able to think of one good use for making up tags, by the way. Most stuff has classes anyway, and my class names are economic enough, so mixing classes is shorter as well as more readable than nesting tags :P
This is from the HTML 2.0 specs, I have no clue how this applies today, but it's the best I could find so far:
4.2.1. Undeclared Markup Error Handling
To facilitate experimentation and interoperability between
implementations of various versions of HTML, the installed base of
HTML user agents supports a superset of the HTML 2.0 language by
reducing it to HTML 2.0: markup in the form of a start-tag or end-
tag, whose generic identifier is not declared is mapped to nothing
during tokenization. Undeclared attributes are treated similarly. The
entire attribute specification of an unknown attribute (i.e., the
unknown attribute and its value, if any) should be ignored.
In other words, you cannot ever depend on browsers styling unknowing tags, you could even say IE is doing it right, which is offensive but true :P
"You also mention that you won't minify either, but isnt that the whole reason you want to create new elements in the first place? To save a few bytes?"
Well, actually I do compress stuff where I can, and I wouldn't even mind minifying serverside, though I'd provide cookie preferences to get it unminified. But sure, of course it was silly to "brag" about not minifying (which is effectively obfuscation -- all the descriptive variable names, *poof*!), and I don't even mean to diss jquery, I'd use it without hesitation on a big project - but still, I can't "create new elements" other than making a browser a lot of people use, or being a part of the w3c efforts etc. Your comparison with semantic elements does not apply. Everybody is making "new (functional) elements" by combining classes and id's and javascript, anyway, just like we use tags without meaning to give them meaning via stylesheets.
I brought up jquery because many people are happily jumping into black boxes just to get the same shiny effects others have. In the case of jquery that's fine, because you at least still can get it unminified, but the point is, in practice that ain't happening. They're just making it easier, yes, kinda like I'd be making it easier for myself, and harder for nobody else -- so how is that "being Microsoft"? How is it "creating new elements" and "destroying what everybody worked so hard for"? I can totally see how it's a waste of time to talk about it, much less do it, but come on, get some perspective..
What I would be doing is use what browser are allowing for, style unknown elements, which is in violation of the specs -- and it would work fine in those browsers as long as they do that, and as long nothing else changes. There is no semantic difference between [div class="some_class_you_need_the_stylesheet_to_understand_the_meaning_of"] and [some_tag_you_need_the_stylesheet_to_understand_the_meaning_of]. But it was silly bring it up I guess. I was asking for good reasons not to do it, so far I got strawmen mostly, and the only real reasons I can see is IE and that browsers might change error handling in the future. I think I can deal with both, should I ever find a good reason to use it. Thanks for the input and sorry for asking.
A final thought, if you are doing to it save space, but then need to use JavaScript to create the DOM elements, well it probably isn't saving any space.
Have you had a look at haml? http://haml-lang.com/
And I don't feel offended as much as I worry about being offensive. It's not a topic ranting a lot over I think. I just like to question everything every now and then ^^
oops, edit:
"A final thought, if you are doing to it save space, but then need to use JavaScript to create the DOM elements, well it probably isn't saving any space."
You mean the shim taking up more space? As I said, just about anything else I could optimize would save more, I know that ^^ It's a rather theoretical question really.
"Have you had a look at haml?"
Well, it's ruby so that's right out for me/my webhost :P
There doesn't always have to be content in the tags as well -- considering I'm sure everyone here has used empty div's before. The reason I didn't go past the 'toying around' phase was because I wanted my site to be crawlable and there are some necessary tags like Title that I couldn't live without. My logic was to go big or go home. Well, I went home instead. I say have fun with it. Rules were meant to be broken right?
It may seem like <div> doesn't have any meaning, but it actually does; it means this content is separate from other content — a division. Maybe that isn't an important meaning to you, but to HTML parsers, it could be a reliable way to group and separate content. In fact, all HTML elements have meaning, some are just more obvious than others.
As you say, this is for your own personal stuff, so if it works for you, and you don't care if it only makes sense to people viewing it in a browser, then by all means proceed. Just make sure that you don't go spreading it around and recommending it to others. Most standards advocates have tried very hard to encourage a standard set of Web languages to make our lives easier, so they don't take kindly to someone that wants to mess that up.
"On top of making tags that didn't exist, I also added attributes"
well, there's data-xyz for that now. which is not even *supposed* to make sense to anything beyond the site they are used on.
@thomas
"The main reason creating your own elements is discouraged is similar to the reason you don't make up your own words in any language: not everyone will understand you. Of course, you can use CSS (and some JS to make IE behave), and browsers will display your new tags as you tell them, but other user agents won't have a clue what you're talking about."
The same goes for spans and divs. They make no sense without the stylesheet, other than grouping content which all tags do.
"It may seem like doesn't have any meaning, but it actually does; it means this content is separate from other content — a division."
ehm. That goes for most tags, and all unknown ones. It's what the DOM does, make pretty node trees. What you said about the div goes for a, span, h#, all of them. They are "a division"...
Look, I do realize that if I wanted to save bandwith etc., I might as well send json and construct the HTML on the client via javascript. "Making up tags" is just a thing that is possible, but useless... However, I don't get anything out of being talked to like a baby ^^
"Maybe that isn't an important meaning to you, but to HTML parsers, it could be a reliable way to group and separate content. "
Not only does it matter to me, it's a given, and goes for all tags. What you are talking about is moot.
"Just make sure that you don't go spreading it around and recommending it to others."
lol? How about, unless you actually have a good answer to even ONE of my questions, you don't worry your head about what I might or might not do? Maybe consider it separation of theoretical questions and practical advice, and ask yourself, can you do it? Can you discuss something theoretically without thinking the sky is falling?
"Most standards advocates have tried very hard to encourage a standard set of Web languages to make our lives easier, so they don't take kindly to someone that wants to mess that up."
I "want to mess that up"? Hahah. I'm asking a question -- which makes movies play in people's heads, yeah, but that's not my concern. My concern is what I'm actually doing, which when it comes to making up tags didn't go farther than jsfiddle. Saying "div is a division", ignoring that this goes for all tags, is just FUD. That's not upholding any standard. I at least try to actually know the rules I'm breaking.
You had to make it seem that way I guess, but ultimately you cannot answer either what the difference (semantically and in practice) between div's with classes and made up tags is. You claim div tags have meaning even the W3C doesn't seem to be aware of, and then I'm the one messing stuff up? Awww. ^^
edit: "the table guy" is probably someone who never uses tables, but asked a question about them, lol?
Also, take a look at the wikipedia main page. Turn off stylesheets. Tada, still looks neat thanks to using a table. And no, I don't use tables myself for layout, but when you, uhhh, need to put stuff in tables, they are perfect -- yet some people seem to think it's "better" not to use them, so they make something awkward with proportionally sized floats and what not: more HTML, more CSS, *still* doesn't behave like a table....that's exactly the mindlessness I will have zero to do with :P
Consider this thread: is it a table, or a list? Maybe that's MySQL speaking, but in my mind, that's a table that doesn't look like one. Each post has author, content, permalink, etc. When each listed iten has the same fields as the others, that's a table, a spreadsheet, whatever you want to call it, and however you want to dress it up.
People see differences where there aren't any real ones. If instead of nesting divs you use unordered list items that get coerced into not looking like the bulleted lists they were "supposed to be", you're not adding one shred of information. Children are grouped by the parent they belong to. All of them, always. Essentially, that's using ul and li instead of having to give divs classes, or the selectors having to taking more descendants into account. Nothing semantic about it at all, and that people would flame me for pointing that out, doesn't make them correct. A lot of this posing around semantics is built on sand, really. A lot of stuff has good reasons, yeah, but people don't seem to know them. And if you mistake my refuting of BS as advocating making up tags (see your table guy analogy), that's yours ^^
also:
http://jsfiddle.net/NbpWe/
Sure, there are a billion ways to center stuff, and I might yet find a nicer one. But I was actually lying before: until I found out about the values for the display property, I did use tables for layout, that is, to get stuff to actually center. (I still have loads of that around, and will change it when I come across it -- but until then I consider that bait for people who obsess about things that don't actually matter :P)
And none of the "cleaner" ways are actually remotely clean, even the ones that don't work in IE... as always, doing just what you're supposed to do doesn't get you very far: you can have a semantic, clean site, or a good looking one. That is rapidly changing, but to pretend the web is semantic more than not is hilarious to me, sorry.
I catched that alright. Go figure :P
Johann - . I feel you, man. I know what it's like when you're wrong but you wanna be right.
"I feel you, man. I know what it's like when you're wrong but you wanna be right."
Heh, the irony. Weak ad-hominems don't make arguments, and so far that's the arguments I get. And flat out incorrect statements about semantics, which I refuted -- care to refute that in turn? No? So why comment, with that table guy bs for example? Heh... I know what it feels like, awww... alas, arguments you don't really seem to have.
And I hate to break it to you: tables do exist for layout. They exist to make tables of data look in a way that things are spatially related to which they are logically related to, without having to have any knowledge of the dimensions of the cells before hand. Sure, they are abused to layout on top of that, but the reason they came to exist IS layout (of tabular data). And they do what they do just fine, other elements don't.
I've seen phpBB skins that use definition lists for thread title, post count etc. It's just silly. That is tabular data, and recreating it without tables doesn't work half as well... but I bet you, someone felt as if they were being very semantic when they did that :P Prolly even mentioned to someone that they're now "not using tables for layout" anymore, heh. Whatever makes people happy I guess, but I find it hard to keep a straight face with some of that stuff.
HTML is a spec that helps things display consistently across browsers, so follow it or don't. Use javascript to make your markup work, or don't. It's just a matter of doing things they way they should be done for consistency.
I've got an idea for you, Johann. You know what I'm sick of? Closing tags. Why don't you write a script that would turn this:
Into this:
I mean, it's less HTML right? The script can work across all browsers.
Actually... Why Have all that unnecessary junk. Lets make the script turn this:
Into this:
It will be horrible for accessibility, but whatever, less bytes = #winning, amirite?
You know what, Johann, I have a serious question to ask you. And this question is as sincere as your OP:
Why not create a script, that turns this:
Into this:
That way you can have your cake and eat it too. Develop with custom tags, output valid HTML. You can create an ant built or something that would turn that into actual HTML. Great for accessibility and great for you. (I'm not saying only use divs, you can create rules to make lists, etc. You get what I mean: HTML out of your own markup - Example: Less)
HTML is HTML. People aren't complaining that javascript should just BE jQuery, they make javascript work for them and jQuery emerged.
So stop complaining about the HTML standard and use it to work for you.
Apparently, I touched a nerve. If I offended you or sounded condescending, I apologize; that wasn't my intent. I do think that you have a misunderstanding of some concepts, though.
First of all, a div is a literal "division" of content — not all tags carry that meaning, even if they do separate content from other content. Here's an example:
Just because div has been often abused and used strictly for styling or scripting, doesn't mean that it doesn't have meaning, even if that meaning may be obscure to many people. HTML 5 is trying to remedy that and actually has changed the role of div, but it's not a perfect process, and will take some trial and error. Still, nit-picking about tags such as <div> and <span> doesn't change the overall argument that the reason you don't make up tags is that not all technologies will understand what you mean. I'm not sure how I could have made that point clearer. It appears that that isn't very important to you, and at this point, I doubt you'll change your mind.
If all you're looking for is what you call "practical advice," then you're not likely to find any, because I assume you mean standard, run-of-the-mill websites, when you refer to "practical." The Web will continue to evolve beyond our current browsers and semantics in markup will become more important. The reason I say "don't mess that up," is because you'd be holding that process back. Of course, you're free to do what you think is best for your own projects from a "practical" view, but we "theoretical" people would appreciate it if you didn't downplay the importance of standard elements.
"So stop complaining about the HTML standard and use it to work for you."
Heh. I'm not complaining, I'm just responding to strawmen, and why not. If you make assumptions about me, why wouldn't I feel entitled to respond? See how that works? I asked rather simple questions. So far none of you has been able to answer what the semantical difference is between div="classname" and classname. Because there is none.
Oh, and I wouldn't expect browsers to do *anything* with void tags other than nest and style them -- though the specs seem to suggest they should be completely ignored.
"Just because div has been often abused and used strictly for styling or scripting, doesn't mean that it doesn't have meaning, even if that meaning may be obscure to many people."
Look, either you flat out state the semantic meaning, or you save me repeating that. Or maybe address what I and others said about their actual semantic meaning. Obscure, lol. Ad-hominem city this is.
@thomas
First of all, a div is a literal "division" of content — not all tags carry that meaning, even if they do separate content from other content. Here's an example:
Huh. In your example, tags do indeed separate content from other content -- heading from paragraph for example.
HTML 5 is trying to remedy that and actually has changed the role of div
Has it? So what changed?
http://html5doctor.com/you-can-still-use-div/
"You should use [div] when there is no other more semantically appropriate element that suits your purpose. Its most common use will likely be for stylistic purposes — i.e., wrapping some semantically marked-up content in a CSS-styled container."
Nothing changed. Nothing semantical about a div, nothing semantical about an unkown tag. The only difference is, being able to use unknown tags is using browser behaviour, not standards, and is therefore risky. But semantically? lol!
"but we "theoretical" people would appreciate it if you didn't downplay the importance of standard elements."
Right. Where I am doing the above? I simply said div and span are void of semantic meaning. That's a fact, ask the w3c if you don't believe me. They group content, which all nestable tags do. In other words, they do nothing. Now THAT is what I call actually paying attention to theory, instead of just mindlessly repeating. "tables should never be used for layout", haha.
Indeed...he can't be convinced and apparently doesn't want to be..so further discussion is pointless.