the classic "why are you trying to use two columns? two columns are evil" religious zealots
I don't think I've ever seen anybody say this. Example?
all their pages look really dull and boring.
In actual fact, their pages don't look boring at all. Your default browser setup looks boring.
Remember, a web design doesn't look like anything until it is realised with the combination of hardware, browser defaults and personal settings. If you think a site that uses your preferences looks boring, then your preferences are to blame.
Re:Bet there still isn't a decent "Stop!" button
on
HTML V5 and XHTML V2
·
· Score: 4, Insightful
even if your site's filtering is insufficient (doesn't account for a problem in a new tag
Why would your site let through new tags that it doesn't recognise? Use a whitelist.
the browser interprets things differently/incorrectly
This only usually occurs if you let through malformed HTML. Use tidy or similar to ensure you only emit valid HTML. Not to mention the fact that the whole problem is caused by lax parsing — something the W3C has been trying to get people to give up on with the parsing requirements for XML.
safe-html = a subset of html that we can be confident that popular browsers can render without being exploited e.g. <em> , <p> ).
You could define such a subset using the modularised XHTML 1.1 or your own DTD.
Before anyone brings it up, YES we must still attempt to filter stuff out (use libraries etc), the proposed tags are to be a safety net. Defense in depth.
Yes, but it won't be actually used that way. If browsers went to the trouble of actually implementing this extra layer of redundancy, all the people with lax security measures would simply use that as an alternative and all the people who take security seriously will use it, despite it not being necessary. I think the cumulative effect would be to make the web less secure.
Oh wow, you called me a pedantic dick, and then said the magical "face it" phrase that automatically wins all arguments. I guess I know when I'm beaten.
No, you twice responded to my comments in this thread while losing track of context and then you didn't seem to be aware of the use of the word "politics" in the wider sense, so it was perfectly reasonable of me to establish whether I needed to phrase myself differently. Lots of non-native speakers post on Slashdot, so you can't always rely on idioms like "office politics". At no point did I suggest that your argument was invalidated by this, so it simply cannot be an ad hominem attack.
ass.
So you've dodged the rest of my comment, and are now calling me names. Please apologise and address the part of my comment that wasn't about language, or I don't see the point in "bringing this back on track".
I wouldn't go that far... there are times when positioned/floated divs are more convenient/more powerful than a table-based layout.
No, you are missing the point. You can position and float any element type. The <div> element type does absolutely nothing for you with regard to layout.
that's the term everybody else understands and uses.
That's the term a lot of people who don't understand HTML use. The term "CSS layout" is far more widely used amongst people who understand HTML in my experience. When I see "div layout" I automatically assume "newbie" because experience has taught me that it's virtually always true. Six or seven years ago, this was different, when CSS layouts were first becoming feasible and it was new ground for most people, but for a long time now, it's been a very reliable indicator as to whether somebody knows what they are talking about.
Suggesting that I need to say things like, "a proper website would put that content in a div to lay it out-- or maybe a span if it's inline, and also that span or div (or maybe a paragraph) should have a class describing what kind of thing it is, or maybe it actually is a table."
If you aren't going to argue honestly, then don't bother responding. You know this is a straw man. You know I didn't suggest anything like this as an alternative to "div layout". You know I referred to the term "CSS layout" as the proper alternative to "div layout". So by completely mischaracterising my argument all you are doing is showing that you don't have a real point and really did just want to call me names.
In short, you're being condescending because you're assuming that the poster doesn't understand the topic just because they're using different terminology than you are.
Read the thread. "I laid out all of my stuff using table cells. What should I use if I can't use those?" "Divs styled by CSS". That is something somebody who does not understand HTML would say. It is bad advice. It is not mere terminology. It's simply wrong.
I'm not being a jerk to prove how smart I am, I'm not being nasty, I'm trying to explain a fundamental flaw in the way many people understand HTML.
If you disagree with anything I am saying, then by all means explain why. But don't just call me names while ignoring the technical matters. That is being a jerk.
Completely disagree. I think it's fair to say "here's the markup spec for embedding video and, btw, you must support , but you may support others."
Whether you think it's fair or not, the fact remains that it's completely irrelevant to HTML. HTML works the same regardless of what codec is in use. Please acknowledge that.
I just can't understand why you don't think this would be a *good thing*
I already explained once. The video codec is orthogonal to every aspect of HTML. It's simply irrelevant to HTML. Now you think that it's not irrelevant in general, and I agree with that, but that doesn't mean you should be trying to force it into somewhere it doesn't fit.
To me it's a practical issue and has nothing to do with politics whatsoever. Not sure how you even pull politics into this.
What do you mean? This is obviously a political issue. Just a guess, are you a non-native speaker of English, and do you think that "politics" is always about what the government does? "Politics" means a lot more than that. Are you familiar with the phrase "office politics"?
No, it's not pedantry. This isn't merely a case of wrong terminology, it's a sign that a developer is looking at something in a completely upside-down way.
most people will call the latter "div layouts" just because it's easier to understand
"Div layouts" is not easier to understand than "CSS layouts".
"I laid out all of my stuff using table cells. What should I use if I can't use those?" "Divs styled by CSS"
If you tell people to replace layout tables with divs, then you don't understand HTML. You replace layout tables with the most appropriate element type available.
I'm going to lay out my page using CSS regardless, so if not divs then what?
I'm not telling you not to use divs. I'm telling you that you are confusing content and presentation. What element types you use is not a layout issue.
I don't think that including a standard image/audio/video format that must be supported makes the spec much bigger than it already is.
There is always "just one little thing more" to put in. If you add in pointless little recommendations like this, you open the floodgates to a million other little things too, which are every bit as important/unimportant as the video codec, every bit as contentious, and just as unnecessary for an HTML specification.
I disagree with you that this is an orthogonal concept. I think it sits right smack dab in the middle of the problem. HTML may have been just a markup language, but it has become media. And the whole point of HTML is to present a document to you. You can't argue that images/video/audio aren't part of today's web documents
I'm not arguing that. Video embedding obviously isn't orthogonal to the markup. The mechanism for embedding video in a document is the same regardless of exactly which codec is used. It's the choice of codec that is orthogonal to the markup. The markup, the DOM, the browser, it's all the same regardless of whether it's an 80s-era video codec being used or a 2010-era video codec being used, it's all the same whether it's a patented, secret codec or a completely Free codec. The choice of codec has absolutely no relevance to the markup, so trying to force what is a political issue into the HTML 5 specification when there is no technical necessity for it being there is just wrong.
For an AJAX project, the ability to work with javascript disabled is a moot point--thus invalidating your event handler argument.
Did you read past the first few words? I gave examples of opening links in a new tab or window. This is a problem for javascript: links regardless of whether Javascript is switched on or off.
In any case, why is the ability to work with JavaScript disabled a moot point just because Ajax is used? Just because you use Ajax, it doesn't mean that you need to give up on situations where JavaScript is disabled.
You seem to be completely unaware of the fact that clients pay for the way the page/app LOOKS
We're talking about how well a developer understands HTML, your tangent about what clients pay for is irrelevant to that.
I have not said otherwise. Please pay attention to what I say rather than attempting to read between the lines.
For example, you're building a page with two columns, perhaps for a nav sidebar and a main content area. You have two separate components to your page, but they don't have any semantic meaning other than being blocks to put stuff (that is, they're not tabular data, list data, paragraphs, headings, etc). In that case, a div (short for "division", as in "page division" or something logically separate from other bits on the page) is absolutely correct to use.
Yes, and what was the motivation for using <div> elements? If it was because you have two separate components without a more appropriate element type to describe them, then that's a structural issue, not a layout issue. If it was because you are building a page with two columns, then you are screwing up and don't understand HTML. Either way, saying that "divs are better for layout" is not a sensible thing to say.
All AJAX apps essentially require that you do not hold your own data -- it's held by the application provider.
You're referring to software as a service, not Ajax. An application ran as a service by an outside vendor can hold your data hostage, whether or not it uses Ajax, and an application running within your organisation doesn't, whether or not it uses Ajax. The key is who runs the application, not whether it uses Ajax.
I strongly disagree that divs over tables for layout is idiocy.
It is idiocy because it shows a complete lack of understanding of the separation of content and presentation. <div> elements are content, not presentation.
Saying that <div> elements are for layout is exactly the same mistake as saying that tables are for layout. The consequences are less severe because the <div> element type has almost no associated semantics to pervert, but it's still the same mistake.
How else would you like people to make clickable text that executes a JavaScript method, and how would it be better than that approach?
Add an event handler to a normal <a> element with a proper href attribute. It works when JavaScript is switched off, it works when your event handler has an error, it works when you try to open something in a new tab or window, it works when the browser doesn't support whatever it is you are trying to do in your event handler, it just plain works.
DIVs are better than tables for layout.
No, they aren't. They are absolutely useless for layout.
They let the designer create more elaborate layouts more efficiently than tables, but they also make even simple layouts much more consistent and easy to implement.
You have confused the <div> element type with CSS. They are totally different things.
This is not pedantry. If you are thinking that layout is somehow achieved with <div> elements, then you are looking at things completely upside-down. You use the most appropriate element type for the information at hand, whether that's a table, a list, a paragraph, or whatever. You then arrange those elements with CSS. The particular element types you've used are not relevant to the layout. If you think <div> elements are in any way interesting for layout purposes, then you don't understand how the whole picture fits together.
No. Firstly, that's not an analogous situation. GIF, JPEG and PNG are ubiquitous. Theora is an extreme minority and Vorbis not much better. The closest match would be MPEG-1.
Secondly, I don't particularly feel that GIF, JPEG and PNG needed to be mentioned either. I'm pointing out that recognising them as examples of formats is an entirely different matter to saying that vendors should implement them, not approving their mention in the first place.
On what timeline will AJAX skills become commoditized like HTML skills became?
It seems to me that developers that can write decent HTML are still an extreme minority. I still see href="javascript:", "<div> s are better than tables for layout", a chronic amount of invalid code, and all kinds of other idiocy all the time. Sure, if you want monkeys to throw tag soup all over the place it's not hard to find them, but that doesn't mean they know what they are doing or that it's easy to find people who actually understand HTML.
You need to read what I said. I know this is the world we live in
I didn't say you didn't. Seriously, go back and read the thread, you keep responding to sentences individually and taking them out of the context of the thread. It went like this:
Ignorant Aardvark doesn't realise this is how things are.
I explain it is, and give lack of JPEG 2000 support in Firefox as an example of that.
You misinterpret my mention of that format as a complaint that it isn't supported.
I point out you are misinterpreting it and explain that I was correcting Ignorant Aardvark.
I am not trying to explain to you that the world is this way. I was explaining it to Ignorant Aardvark, and you misinterpreted something I said, so I explained why I said it.
W3C *should* specify a required (image/audio/video) format that everyone must support.
But why must this be in the HTML specification? HTML is a markup language, its specification should concern itself with markup, not codecs.
And why should it be the W3C that does this? There are other standards organisations, ones more experienced with video and audio.
Times change and I think the HTML spec should grow with the times.
So you think that anything useful, no matter what it is, should be crammed into one behemoth specification? No. That's ludicrous. It goes against established principles of the web architecture. Specifically, orthogonal abstractions benefit from orthogonal specifications.. I quote:
Experience demonstrates that problems arise where orthogonal concepts occur in a single specification.
Slashdot Mirror
I don't think I've ever seen anybody say this. Example?
In actual fact, their pages don't look boring at all. Your default browser setup looks boring.
Remember, a web design doesn't look like anything until it is realised with the combination of hardware, browser defaults and personal settings. If you think a site that uses your preferences looks boring, then your preferences are to blame.
Why would your site let through new tags that it doesn't recognise? Use a whitelist.
This only usually occurs if you let through malformed HTML. Use tidy or similar to ensure you only emit valid HTML. Not to mention the fact that the whole problem is caused by lax parsing — something the W3C has been trying to get people to give up on with the parsing requirements for XML.
You could define such a subset using the modularised XHTML 1.1 or your own DTD.
Yes, but it won't be actually used that way. If browsers went to the trouble of actually implementing this extra layer of redundancy, all the people with lax security measures would simply use that as an alternative and all the people who take security seriously will use it, despite it not being necessary. I think the cumulative effect would be to make the web less secure.
If knols are units of information, then I would imagine that a negative amount of knols is misinformation.
If you've dragged this thread down to the name-calling level and you refuse to debate maturely, then there's no point continuing any further. Goodbye.
Oh wow, you called me a pedantic dick, and then said the magical "face it" phrase that automatically wins all arguments. I guess I know when I'm beaten.
More discussion here.
No, I didn't say the contrapositive. The contrapositive would be "divs are worse for layout than tables".
It depends on the content.
No, you twice responded to my comments in this thread while losing track of context and then you didn't seem to be aware of the use of the word "politics" in the wider sense, so it was perfectly reasonable of me to establish whether I needed to phrase myself differently. Lots of non-native speakers post on Slashdot, so you can't always rely on idioms like "office politics". At no point did I suggest that your argument was invalidated by this, so it simply cannot be an ad hominem attack.
So you've dodged the rest of my comment, and are now calling me names. Please apologise and address the part of my comment that wasn't about language, or I don't see the point in "bringing this back on track".
No, you are missing the point. You can position and float any element type. The <div> element type does absolutely nothing for you with regard to layout.
That's the term a lot of people who don't understand HTML use. The term "CSS layout" is far more widely used amongst people who understand HTML in my experience. When I see "div layout" I automatically assume "newbie" because experience has taught me that it's virtually always true. Six or seven years ago, this was different, when CSS layouts were first becoming feasible and it was new ground for most people, but for a long time now, it's been a very reliable indicator as to whether somebody knows what they are talking about.
If you aren't going to argue honestly, then don't bother responding. You know this is a straw man. You know I didn't suggest anything like this as an alternative to "div layout". You know I referred to the term "CSS layout" as the proper alternative to "div layout". So by completely mischaracterising my argument all you are doing is showing that you don't have a real point and really did just want to call me names.
Read the thread. "I laid out all of my stuff using table cells. What should I use if I can't use those?" "Divs styled by CSS". That is something somebody who does not understand HTML would say. It is bad advice. It is not mere terminology. It's simply wrong.
I'm not being a jerk to prove how smart I am, I'm not being nasty, I'm trying to explain a fundamental flaw in the way many people understand HTML.
If you disagree with anything I am saying, then by all means explain why. But don't just call me names while ignoring the technical matters. That is being a jerk.
Whether you think it's fair or not, the fact remains that it's completely irrelevant to HTML. HTML works the same regardless of what codec is in use. Please acknowledge that.
I already explained once. The video codec is orthogonal to every aspect of HTML. It's simply irrelevant to HTML. Now you think that it's not irrelevant in general, and I agree with that, but that doesn't mean you should be trying to force it into somewhere it doesn't fit.
What do you mean? This is obviously a political issue. Just a guess, are you a non-native speaker of English, and do you think that "politics" is always about what the government does? "Politics" means a lot more than that. Are you familiar with the phrase "office politics"?
CSS.
No, it's not pedantry. This isn't merely a case of wrong terminology, it's a sign that a developer is looking at something in a completely upside-down way.
"Div layouts" is not easier to understand than "CSS layouts".
If you tell people to replace layout tables with divs, then you don't understand HTML. You replace layout tables with the most appropriate element type available.
I'm not telling you not to use divs. I'm telling you that you are confusing content and presentation. What element types you use is not a layout issue.
There is always "just one little thing more" to put in. If you add in pointless little recommendations like this, you open the floodgates to a million other little things too, which are every bit as important/unimportant as the video codec, every bit as contentious, and just as unnecessary for an HTML specification.
I'm not arguing that. Video embedding obviously isn't orthogonal to the markup. The mechanism for embedding video in a document is the same regardless of exactly which codec is used. It's the choice of codec that is orthogonal to the markup. The markup, the DOM, the browser, it's all the same regardless of whether it's an 80s-era video codec being used or a 2010-era video codec being used, it's all the same whether it's a patented, secret codec or a completely Free codec. The choice of codec has absolutely no relevance to the markup, so trying to force what is a political issue into the HTML 5 specification when there is no technical necessity for it being there is just wrong.
Did you read past the first few words? I gave examples of opening links in a new tab or window. This is a problem for javascript: links regardless of whether Javascript is switched on or off.
In any case, why is the ability to work with JavaScript disabled a moot point just because Ajax is used? Just because you use Ajax, it doesn't mean that you need to give up on situations where JavaScript is disabled.
We're talking about how well a developer understands HTML, your tangent about what clients pay for is irrelevant to that.
I have not said otherwise. Please pay attention to what I say rather than attempting to read between the lines.
Yes, and what was the motivation for using <div> elements? If it was because you have two separate components without a more appropriate element type to describe them, then that's a structural issue, not a layout issue. If it was because you are building a page with two columns, then you are screwing up and don't understand HTML. Either way, saying that "divs are better for layout" is not a sensible thing to say.
You're referring to software as a service, not Ajax. An application ran as a service by an outside vendor can hold your data hostage, whether or not it uses Ajax, and an application running within your organisation doesn't, whether or not it uses Ajax. The key is who runs the application, not whether it uses Ajax.
It is idiocy because it shows a complete lack of understanding of the separation of content and presentation. <div> elements are content, not presentation.
Saying that <div> elements are for layout is exactly the same mistake as saying that tables are for layout. The consequences are less severe because the <div> element type has almost no associated semantics to pervert, but it's still the same mistake.
I never said they were.
Add an event handler to a normal <a> element with a proper href attribute. It works when JavaScript is switched off, it works when your event handler has an error, it works when you try to open something in a new tab or window, it works when the browser doesn't support whatever it is you are trying to do in your event handler, it just plain works.
No, they aren't. They are absolutely useless for layout.
You have confused the <div> element type with CSS. They are totally different things.
This is not pedantry. If you are thinking that layout is somehow achieved with <div> elements, then you are looking at things completely upside-down. You use the most appropriate element type for the information at hand, whether that's a table, a list, a paragraph, or whatever. You then arrange those elements with CSS. The particular element types you've used are not relevant to the layout. If you think <div> elements are in any way interesting for layout purposes, then you don't understand how the whole picture fits together.
No. Firstly, that's not an analogous situation. GIF, JPEG and PNG are ubiquitous. Theora is an extreme minority and Vorbis not much better. The closest match would be MPEG-1.
Secondly, I don't particularly feel that GIF, JPEG and PNG needed to be mentioned either. I'm pointing out that recognising them as examples of formats is an entirely different matter to saying that vendors should implement them, not approving their mention in the first place.
It seems to me that developers that can write decent HTML are still an extreme minority. I still see href="javascript:", "<div> s are better than tables for layout", a chronic amount of invalid code, and all kinds of other idiocy all the time. Sure, if you want monkeys to throw tag soup all over the place it's not hard to find them, but that doesn't mean they know what they are doing or that it's easy to find people who actually understand HTML.
I didn't say you didn't. Seriously, go back and read the thread, you keep responding to sentences individually and taking them out of the context of the thread. It went like this:
I am not trying to explain to you that the world is this way. I was explaining it to Ignorant Aardvark, and you misinterpreted something I said, so I explained why I said it.
But why must this be in the HTML specification? HTML is a markup language, its specification should concern itself with markup, not codecs.
And why should it be the W3C that does this? There are other standards organisations, ones more experienced with video and audio.
So you think that anything useful, no matter what it is, should be crammed into one behemoth specification? No. That's ludicrous. It goes against established principles of the web architecture. Specifically, orthogonal abstractions benefit from orthogonal specifications.. I quote: