OMG thats a long post 
Agree with a lot of it though. Although, doesn't IE8 only pass acid2 when the browser sends a special header and requires the world to start adding new metatags if they want IE8 to use standards mode? IMO thats working backwards. It would kinda make sence is IE was the only browser to display things correctly and had to compensate for the quirks authors expected of others, but when its the least standards complient browser out there, setting it up so even if it does have better support, it simply won't use it is ludicrous. Just think what you'll need by the time people start getting acid 3 to work, a whole page full of M$ worship just to convince it to behave and play nice like the other kiddies?
HTML is and is culturally too lenient. You can use 5 html tags and the page work. As a result people do. Its not even easier, I taught myself to use valid xhtml and css layouts because it was damn easier than trying to teach myself off embedded tablular multi<head>ed monsters. When asked, I always define the difference between html and xhtml by saying xhtml is html done right. Yes, you should have to close tags. Yes, you should have a doctype and not keep switching cases; lowercase is fine. And perhaps if there wasn't a html5 and all the exciting new features like tags that you won't be able to use for 20 years were in an xhtml web applications dt, perhaps people would pay a little more attention to not writing crap, but evidently M$ disagrees, and would have us believe we should go to further and further lengths if we want valid standards-complient code to be displayed correctly.
Yup exactly. IE8 has Acid2 support now, which is indeed a monumental ring to my ears. CSS 3 rules, nice sig btw.
Did you know that in versions of Opera that some Wizziwig or some other editor doesn't work too well for some reason? Hmm. I might have a script blocked or something when I use Opera to test. I use those editors usually with blog systems most of the time anyway. I find it VERY annoying that no matter if you want or not, they rearrange attributes and stuff, and it ends up being a mess. I love throwing the stuff in as I know it, because like you I taught myself to use valid layouts because yes, it is easier to do it that way than use. Web standards aren't difficult to learn by any measure; perhaps just tedious is the word - to become familiar with CSS isn't all too difficult, you just have to get used to list-style, font-style, font-weight, font-family, font-variant or the shorthand and nicer-looking (imho) combination of those (example: font: italic 1.1em tahoma,sans-serif;), background-color, background-repeat, background-attachment, background-position, background-image, or the combination of those (example: background: #334499 url(somepath/eitherabsolute/or/relative/someimage.jpg) no-repeat fixed center; makes the background image, if available, repeats in _Neither_ x _Nor_ y as well as remaining fixed as you scroll and sets to center), and so on. I attempt to use CSS 1 for most things, so that it stays compatible even with older browsers.
Strangely (not sure if I mentioned this) IE uses (or used in past tense as IE8 arrives) this ActiveX javascript css addon monstrosity called expression, which basically adds javascript to css which I just think defeats web standards in yet another way. I mean, there is no doubt that it is a very powerful thing, but only for IE and thus not a standard (I keep to standards, except when it comes to the US education system and don't get me started on that, where standards are declared by those who aren't even involved in the field of education such as instruction or administration, etc). In the case of W3C standards, those folks, on the whole, know what they're talking about.
There is no doubt that the standards for the separation of markup and style is making things better. Xhtml 2.0 sounds to be pretty good. The object tag as well as the use of XML will benefit from it. X-Forms is not going to be quite as complicated as first was meant to look like. Its support will be through XML so compatibility, to some level, can still be maintained. That is cool!
That's all because of the "ideological" difference though. HTML was designed (and mainly interpreted) to render your site and that at all cost, so browsers will be very forgiving and as ingwe said, a site can look awesome in the browser even though the markup is screwed up royally. HTML is a presentational thing.
XML, however, was designed to precisely describe/store data, for no specific application. Because of this independence it always needs to be a 100% correct and if there is one tiny mistake, the whole thing should be reported as broken. So XML is a scientific thing.
Back in the day of Web 1.0 the HTML approach was enough because you had like 2 browsers, the whole thing was still new and most people didn't understand it anyway, so it had to be rather forgiving. But nowadays with all the different browsers and devices, this mentality just doesn't work out anymore. Now we need precision and correctness to make sure everything works everywhere.
Exactly, and in a way it was complacency; where designers knew the browsers would handle their code so they could put stuff in there like...
<nobr>
^ whoa, haven't seen that one since...a long time
<center>
^ good lord no
And of course the tag closing ones like...
<p>this is a line of stuff that does stuff
</a>
I've seen something like that; apparently there was supposed to be a link where no link was decided to be there after the fact and the ending for a was kept whilst there was no replacement end tag for p. But browsers can understand that as long as it isn't something like...
<a href="h-t-t-p://somesite.com title="Hello world">this is a hyperlink, but there's something not right about it is there?</a>
The rest would be somewhat messed up I'm thinking. The link would be "h-t-t-p://somesite.com title=" and it wouldn't recognize the close for the <a> before the internal text. h-t-t-p was formatted that way in this example so that somesite would turn up as a link on the forum.
I put the above into a code tester that's on my site and in Firefox it shows up as regular body text; when you hover over it, it has an underline but clicking doesn't lead anywhere, and that's apparently a browser failsafe for preventing such an error from fouling up the remainder of the markup and style.
So those methods still exist to prevent things from going wrong. Unfortunately those error prevention techniques led to a certain level of complacency and code that is, for all practical purposes, not very usable (seeing as how a link set up that way would be unusable).
If they wanted to remove iframe in HTML5, frankly I would be quite irritated to say the least. They left it in for the benefit of WYSIWYG editors, because we all know how shitty support for contentEditable is in browsers nowadays. If suddenly this draft would make it so that WYSIWYG editors are now useless, how many people with dynamic websites you would think would use it?
The recognition of these elements is purely for the benefit of JS scripts. It says so in the spec even. These elements are not meant to be used outside of javascript, and are thus effectively deprecated though will still be recognised by validators.
I'm thinking that WYSIWYG editors may change with time as well. At least I'd hope. Iframes would still be compatible in browsers, even if you compiled your code in Html 5 or Xhtml 2.0. It's just that I'm not sure if XML parsing would allow it. I think it would because XML parsing ignores the attributes, as long as they're quoted the right way and additionally that the elements are opened and closed properly. You'd get validation errors perhaps but iframe will still probably be in future browsers for a while. By the time it really becomes required for there not to be iframes, with object as its replacement, the current browsers will support new editors. The WYSIWYG editors you get with portal and forum software would be updated in that case to allow for this possibility.
An example of code from a WYSIWYG editor for iframe (not sure if it is relevant but currently the object tag in the js file for the editor is not available within it):
w('<iframe style="width:'+taWidth+'; height:'+taHeight+'; padding:2px; border:1px outset ButtonHighlight; background:Window; color:WindowText;" src="java script:;" id="whizzyWig" marginheight="0" marginwidth="0"></iframe><div style="margin-bottom:10px;"></div>'+"\n");Some fix for that would be available so that both could be used transitionally, and then in the future when iframes are definitely not allowed (that seems to be the way it's going), object will be the replacement.
When I learned html for the first time, there were a lot of frames, framesets, valigns, aligns, profuse use of tables that weren't exactly valid (tags not being closed), iframes, widths, borders, and all the other inline non-property (not in the style attribute) attributes. And now the style attribute is going out the window as well, and everything will be CSS as far as primary structure (Xhtml) and Xsl for Xml (in Xsl you can use the style attribute for the xml data by assigning the xsl stylesheet to the xml file so that instructions are received for the styles).
<iframe src="insertlinkhere" id="codetest" frameborder="0" width="100%" height="455" border="0">
Your browser does not support frames, but you may view this content
at <a href="insertlinkhere">insertlinkhere</a>
</iframe>
That's the way an iframe would refer to a source, for example, a php or html page, or whatever. Seems easier. In dynamic solutions though, object comes into play. One reason iframe has been used for so long is this: IE came out with an arbitrary "object" tag in 1997 before W3C officially released in dtd the actual object tag. IE's object thus now has different functionality than others browsers. For example, referencing an object in IE that's on a domain that is external to the object tag's file's location doesn't quite work. The Iframe works for IE. Either that or you use embed. Much of the Youtube bbcode out there for forums, including Invision, SMF, phpBB, vBulletin, etc, includes the object tag but also includes the embed for the flash video.
Next we have object as a comparison (in object, type is required). IE will display objects poorly, for instance, giving it an ugly bright border.
<object data="insertlinkhere" type="text/html" id="codetest" style="width: 100%; height: 455px; border: 0px;">
Your browser does not support objects, but you may view this content at <a href="insertlinkhere">insertlinkhere</a></object>
In place of src is data in this case. Type is the mime type of the content. If you're referencing a purely xhtml+xml page, the type attribute would be:
type="application/xhtml+xml"
Similar to application/xml except that xml can be included with xhtml. In this format, any one xml parsing error on your page, as we know, will disable any page with an xml error. If you're operating on a template that has application/xhtml+xml for every template that's pulled up, the chances are likely that somehow, somewhere, a page will be disabled. Even modern-day forums and portal software (especially portal software) is known for it (though not widely known). To reference the object with CSS so you don't have that style inline attribute, use css for the id "codetest" as such:
object#codetest{width: 100%; height: 455px; border: 0px;"The object element name in the css above doesn't need to be included since all Ids must be unique (classes can be repeated).
A lot of problems come in with PHP loops (while's, foreach's, etc). Spitting out markup inside, for example, a foreach loop, requires either that you define NO ids in there, or that the ids are dynamic. To define style for the content inside that, you have to do it with classes, or perhaps put a div before and close after the foreach statement so that...
echo '<div id="container_foreach1">';
foreach($message['body'] as $post)
{
echo '
<div class="post_body">
'.$post.'
</div>';
}
echo '</div>';For any subsidiary tag inside the div id "container_foreach1" you'll be able to define css for it that way like so...
/* Original post_body class */
post_body{ color: #bbb; background: #224488 url(images/bg_body.png) repeat fixed; font: normal 1em tahoma,sans-serif; padding: 0.7em; }
#container_foreach1 post_body{ color: #ff0000; background: #224488 url(images/bg_post.png) repeat scroll; font: 1em tahoma,sans-serif; padding: 1.25em; }This way, if the post_body is set differently in the foreach area, you don't have to redefine a new post_body_2 class or whatever.
I must admit, at first, going from Html to Xhtml some years ago was at first daunting. I was like, why the change? I found eventually that new learners would probably end up benefiting from it. Code is more organized and modular. It's like comparing Command and Conquer: Generals INI.big to Battle for Middle Earth II's INI.big files. In Generals, you had some files that contained most of the data. In Bfme2 you had tons of files that were each designed for a specific purpose, so that it would be 'easy' to find out what you're modding. But of course, when that many files are involved, it becomes difficult for modders to find what they're looking for. Textpad, for instance, can do a search all documents in a certain path and search subfolders or not search subfolders for the string you are looking for.
It's much of the same kind of transition. Except it's not all ini files. Most forums will have all kinds of files. You may have an htaccess file defining your url paths and redirections (in the case that you switched domains or renamed a file, or just want to make urls easier to read (make sure that when doing that by the way that no two pages link to the same exact thing or you'll pay for it because of Google's disapproval of duplicate content...I found it out the hard way when page rank went down a notch)). In most portal and forum setups of today, most files are PHP if you're using Apache. It might be ASP coding if you're using M$ (I love that way of spelling Micro$oft by the way, it's most accurate). So you have a general lack of html files around. You probably will have some .js files for your javascript, .xml for XML files, perhaps some Xsl files, or you include xml and xsl inside of php functions in source code of your firmware. You'll have your php files (mentioned before). And then you'll have all of your downloads and images (including css images).
So when you come to the fact that iframes are pretty much gone once you get to Xhtml 1.0 Strict, it seems pretty bad at first, but we can all live with a few validation errors here and there if a document is edited using WYSIWYG or some other editor that uses Iframe. But that's probably going to be fixed eventually. There are work-arounds for IE and Firefox so that IE uses Iframes still and Firefox (or other browsers like Safari, Netscape, Opera, etc) use Objects.
<!--[if IE]>insert iframe code here<![endif]-->
<!--[if !IE]> <!-->insert object code here<!--<![endif]-->
A scary work-around no doubt, but it works. Make sure to set the iframe to have frameborder="0" or it will have an ugly border (puke). To be honest, I'm irritated with the removal of iframe as well. In Xhtml 2.0, img tag is being removed in favor of object, where src or data is the image location and type is "image/jpeg or png or gif"
I ask that the readers beg my pardon for the length of this post, and for any disorganization that may have been involved.
Much of this can be found in the specs for the DTD (document type definitions) as well as the proposals W3C has made. CSS 3 is also looking pretty good. I can't wait to give Xhtml 2.0 and Html 5 a try.
Edited by Ingwe, 05 February 2008 - 10:45 AM.
