htmlnewbie23 Posted November 15, 2007 Share Posted November 15, 2007 My webpages are html (and sometimes contain JS). In them I use <br /> instead of <br>, <hr /> instead of <hr> so that they may be ready for xhtml - even though they are now just html. I thought that was acceptable practice.But when I checked one of my pages I got the following validation errors:................NET-enabling start-tag requires SHORTTAG YES. <br />The sequence <FOO /> can be interpreted in at least two different ways, depending on the DOCTYPE of the document. For HMTL 4.01 Strict, the '/' terminates the tag <FOO (with an implied '>'). However, since many browsers don't interpret it this way, even in the presence of an HMTL 4.01 Strict DOCTYPE, it is best to avoid it completely in pure HTML documents and reserve its use solely for those written in XHTML...............Is it "NOT" OK to use <br /> and <hr /> in webpages that are<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> ?Thank you. Link to comment Share on other sites More sharing options...
Ingolme Posted November 15, 2007 Share Posted November 15, 2007 Closing a tag that way is for XHTML. In HTML it's not necessary to close <br> and <img> tags and those kinds. Link to comment Share on other sites More sharing options...
justsomeguy Posted November 15, 2007 Share Posted November 15, 2007 It's not about necessity, it's not even valid at all to use that notation in HTML. Browsers should render that incorrectly but they are forgiving. Don't include any type of XHTML anything in an HTML page. Don't try to add XHTML to HTML pages to be "ready" for XHTML. If you want to switch you will have to redo the code anyway. Or, you could be like me and several others and just stick to HTML until XHTML offers some benefit over HTML. Link to comment Share on other sites More sharing options...
Shonumi Posted November 15, 2007 Share Posted November 15, 2007 Or, you could be like me and several others and just stick to HTML until XHTML offers some benefit over HTML.What are you saying? Is the extra "X" not enough for you? Anyways, I see the point of view of people needing little to switch to XHTML when HTML is fine. I believe the stereotype as portrayed to tyros to web design is that HTML is broken and or depreciated. Which isn't true, it's mainly just bad code and browsers that give that image. I stick to XHTML becuase that's what I started out with, its natural now, and I like, as a preference, the well formed structure, as in all tags must close. In a sense, it's like XML. Why save my game data files in it when regular I/O with plain text files works just fine. Its well formed. But that's not enough for most people, and I tend to agree. Link to comment Share on other sites More sharing options...
justsomeguy Posted November 15, 2007 Share Posted November 15, 2007 Yeah, there's nothing wrong with HTML strict that can be fixed by using XHTML. Or, in other words, using XHTML doesn't solve any problems that I've had. Link to comment Share on other sites More sharing options...
boen_robot Posted November 16, 2007 Share Posted November 16, 2007 Yeah, there's nothing wrong with HTML strict that can be fixed by using XHTML. Or, in other words, using XHTML doesn't solve any problems that I've had.I've said it before, and I'll say it again - one benefit which XHTML (even the one served as text/html) allows you to do is process it with XML parsers, instead of for example regular expressions. True, there are also SGML parsers, but there are far few, and none are ever integrated into any language.You might not have the need to use XML tools over HTML documents yet, but who knows. You may need that one day. I guess you'll be migrating to XHTML when that day comes. Link to comment Share on other sites More sharing options...
Pollux Posted November 16, 2007 Share Posted November 16, 2007 The immediate benefits of XHTML aren't obvious but they do exist. boen_robot's point is a good one about XML parsers and because it's XML you can use XSLT to easily create different presentations of the same page for different uses, perhaps for mobile devices. But even if you won't ever want to use any of the XML bits theres still the advantage that using XHTML encourages good practices and because it's stricter it makes tracking down problems easier. It also makes it easier for other people to read your code. They're subtle advantages maybe but it can actually make cross-browser compatibility easier to achieve. HTML was never really designed, rather it grew. So XHTML and its recommendations of use which separate data and presentation are an attempt to make something tidier which will scale better. It's a good idea at some point to make the switch. Link to comment Share on other sites More sharing options...
justsomeguy Posted November 16, 2007 Share Posted November 16, 2007 I've said it before, and I'll say it again - one benefit which XHTML (even the one served as text/html) allows you to do is process it with XML parsers, instead of for example regular expressions.I can't imagine ever needing to parse one of my pages with an XML parser. The majority of the markup on the page is all layout and navigation stuff, I'm not interested in parsing that. If I want to get to the content then chances are it's stored in a database already. I'm talking reality here, not theory.you can use XSLT to easily create different presentations of the same page for different uses, perhaps for mobile devicesYou can use CSS for the same thing.theres still the advantage that using XHTML encourages good practices and because it's stricter it makes tracking down problems easierI've seen plenty and plenty of terrible XHTML sites, it doesn't encourage anything. I would take my valid strict HTML sites over a lot of the stuff online claiming to be XHTML any day. I don't use any different practices when writing the two languages other then putting a slash at the end of certain tags. I would also argue that it's no easier to track down an XHTML error then it is an HTML error.It also makes it easier for other people to read your code.No it doesn't, good code is good code. XHTML isn't any easier to read then HTML just because of it's virtue of being XHTML.HTML was never really designed, rather it grew.I wouldn't really say that, the first web pages were using a version of SGML but by the time Tim Berners-Lee submitted the RFC for HTML 2 in 1995 it was already being implemented by vendors.Like I'm saying, I just don't see where XHTML solves an existing problem. If you write good, strict, valid pages it doesn't matter what language you write them in, and it's no easier to write a strict and valid page in XHTML then it is in HTML (it might even be more difficult). I have HTML sites that separate content and presentation very well and are very easy to maintain, just as well it's very easy to create an XHTML page that doesn't have any of that and is a nightmare. Link to comment Share on other sites More sharing options...
boen_robot Posted November 16, 2007 Share Posted November 16, 2007 I can't imagine ever needing to parse one of my pages with an XML parser. The majority of the markup on the page is all layout and navigation stuff, I'm not interested in parsing that. If I want to get to the content then chances are it's stored in a database already. I'm talking reality here, not theory.What if you wanted the site to be usable by other applications i.e. encourange people taking data from it? There's always screenscrapping/regular expressions for invalid codes, and SGML parsers for valid HTML pages (the problems with SGML parsers being mentioned already). But you'll ease others with that task by having XHTML page instead.And the same goes for you - if you want, you can use XML tools (DOM, SimpleXML, XSLT... whatever feels good for you at that point) to read someone else's data, and embed it into a page of yours. The latter is probably a more likely scenario, but without XHTML, even that won't be possible... not with the same ease anyway. Link to comment Share on other sites More sharing options...
Pollux Posted November 18, 2007 Share Posted November 18, 2007 I don't really understand why you're arguing against this. you can use XSLT to easily create different presentations of the same page for different uses, perhaps for mobile devicesYou can use CSS for the same thing.That's not true. CSS can provide different styles, but XSLT will actually change the structure, reorder components and make decisions based upon the structure. It's impossible to achieve that with CSS.I've seen plenty and plenty of terrible XHTML sites, it doesn't encourage anything. I would take my valid strict HTML sites over a lot of the stuff online claiming to be XHTML any day. I don't use any different practices when writing the two languages other then putting a slash at the end of certain tags. I would also argue that it's no easier to track down an XHTML error then it is an HTML error.It's true that a well coded HTML site is better than a badly coded XHTML site, but that's not the point here. I'm sure you don't use any different approach because you probably follow good practice with HTML anyway. This point is most relevant for people learning (X)HTML. As with programming it's important to learn good practices, because you'll quickly get found out by bad practices when used on a large scale. XHTML encourages this, that's a good thing.It's easier to read someone elses XHTML because it's always going to be more similar to your own. This is simply because XHTML doesn't allow you so much freedom of coding style.The purpose for which HTML was originally developed is very different to how it's used now, so new features were tacked on. HTML would not exist how it does if it was known how it would come to be used. This is from the XHTML 1.0 W3C specification...HTML, as originally conceived, was to be a language for the exchange of scientific and other technical documents, suitable for use by non-document specialists. HTML addressed the problem of SGML complexity by specifying a small set of structural and semantic tags suitable for authoring relatively simple documents. In addition to simplifying the document structure, HTML added support for hypertext. Multimedia capabilities were added later.In a remarkably short space of time, HTML became wildly popular and rapidly outgrew its original purpose. Since HTML's inception, there has been rapid invention of new elements for use within HTML (as a standard) and for adapting HTML to vertical, highly specialized, markets. This plethora of new elements has led to interoperability problems for documents across different platforms....enter XHTML. XHTML just gives a basis to move forward on. The ultimate point with XHTML is that it's no more difficult to write than HTML and you get full XML support thrown in. I probably wouldn't bother rewriting existing sites, but theres no reason not to use it for new sites. Link to comment Share on other sites More sharing options...
croatiankid Posted November 18, 2007 Share Posted November 18, 2007 Can't you do all you can do with XHTML+XML with HTML+Programming+Database? Link to comment Share on other sites More sharing options...
justsomeguy Posted November 19, 2007 Share Posted November 19, 2007 What if you wanted the site to be usable by other applications i.e. encourange people taking data from it?Then I would provide a content-only API that people could use instead of expecting them to parse my layout and navigation.I don't really understand why you're arguing against this.That's OK, I don't understand why you're arguing for it.As with programming it's important to learn good practices, because you'll quickly get found out by bad practices when used on a large scale. XHTML encourages thisNo it doesn't, XHTML does not do anything more for the user with regard to learning or error checking then HTML does. Sure, an XML parser can tell if the document is well-formed or not, but a normal web browser that a normal person learning the language is using is not going to tell them anything, it's going to attempt to render their code the way it normally would with anything else and show them the result. If it looks right, then people are going to think their code is right, the same way with HTML....enter XHTML. XHTML just gives a basis to move forward on.Browser vendors will continue to add and support proprietary tags regardless of the language. Introducing XHTML is not going to cause browser vendors to stop supporting third-party things like <embed>, they are still going to support them and people are still going to use them. The problem is that vendors took the liberty to introduce things themselves that were not in the spec, it's not the spec's fault for that.Can't you do all you can do with XHTML+XML with HTML+Programming+Database?I've never encountered a situation where that is not the case. I've never seen something that can be solved by using XHTML or XML that cannot be solved using HTML. Link to comment Share on other sites More sharing options...
Guest FirefoxRocks Posted November 20, 2007 Share Posted November 20, 2007 I've never encountered a situation where that is not the case. I've never seen something that can be solved by using XHTML or XML that cannot be solved using HTML.Ok try solving this problem then:Use HTML to organize news coming from a few hundred different sources where you need to display the news files with the EXACT same layout (styling can vary a little). Thousands (possibly millions) of stories are coming in every day, and you need to build a system to organize it all. Would you prefer to use HTML or XML? Link to comment Share on other sites More sharing options...
Shonumi Posted November 20, 2007 Share Posted November 20, 2007 Trick question, as in its about preference not feasibility. Essentially, XML describes data and its structure. HTML present data within its own structure. In the end, you still are manipulating data. As for an exact solution (as I assume you can't only be using just HTML or XML alone), why not just retrieve some SQL data using PHP, and the PHP displays outputs it into HTML? SQL looks pretty organized to me, and the PHP script can be as strict as you like it to get a similar site layout. Do people forget a time before we had adopted XML? Or did I miss some other major point in your proposed problem? Data is data after all; all programmers use the same code but in different ways. Link to comment Share on other sites More sharing options...
justsomeguy Posted November 20, 2007 Share Posted November 20, 2007 Use HTML to organize news coming from a few hundred different sources where you need to display the news files with the EXACT same layout (styling can vary a little). Thousands (possibly millions) of stories are coming in every day, and you need to build a system to organize it all. Would you prefer to use HTML or XML?Neither, I would use a database. You're not talking about the format of the data that I'm retrieving, you're talking about the format of the data that I'm storing. Most likely when I retrieve the data it's going to come from a variety of sources - HTML, XHTML, RSS, XML, etc, and I need to be prepared to extract the content I want from any of those. But when I choose a format that I want to store all this content that I've spent time gathering from other sources, I'm going to index everything in a database that I can search through faster then XML files anyway, and enjoy the benefits of using a database management system that is optimized to handle the type of data that I'm storing. Link to comment Share on other sites More sharing options...
croatiankid Posted November 20, 2007 Share Posted November 20, 2007 Ok try solving this problem then:Use HTML to organize news coming from a few hundred different sources where you need to display the news files with the EXACT same layout (styling can vary a little). Thousands (possibly millions) of stories are coming in every day, and you need to build a system to organize it all. Would you prefer to use HTML or XML?HTML PHP (or Python) and a DB Link to comment Share on other sites More sharing options...
boen_robot Posted November 20, 2007 Share Posted November 20, 2007 Ok try solving this problem then:Use HTML to organize news coming from a few hundred different sources where you need to display the news files with the EXACT same layout (styling can vary a little). Thousands (possibly millions) of stories are coming in every day, and you need to build a system to organize it all. Would you prefer to use HTML or XML?Exactly how big must the page containing those news be? Thousands? I mean, if it is, it would take forever to load, regardless of how you generate it.Still, the approach I'd use is to connect only to the feeds I want to query with HEAD requests to check if there's anything new in an RSS feed of theirs (which is XML anyway). If there is, I GET it (I know, an extra request, but keeps bandwidth low when there's nothing new), process it (with XMLReader if I must keep memory really low, but considering the size of a single feed, I'd say DOM is OK too as long as you use only one instance), and then show it to the user, saving a local copy of the feed in the end, and if there isn't anything new, I process the local copy instead.If I really had to store thousands of feeds, I'd need a bigger HDD, regardless of whether I used DB or XML files. And whether I store the feeds into a DB or as XML files, there still is the overhead of parsing them, which could possibly be defeated if the RSS is transformed into SQL, rather than just having the RSS being injected in. How exactly that overhead is in comparrison to connecting to an SQL server and selecting a DB is another question. And how exactly is the convertion itself performed efficiently and instantly (instead of "cron"-ly) is an even more complex question.Now... what I was trying to say earlier was about screenscaping. If the site doesn't have a feed, or an API, how can you get a certain content you want, and that you know is always there? I sure can't think of any way not involving screenscrapping. Sure, like with any screensraping, any change in the source site will damage your app too, but if the site is written in XHTML, you can use a single XPath expression to select what you need. A change in the source site will likely only force you to adjust that single expression. If you want to use your own formatting, you can use XSLT to transform their presentational data into your own. For example, if the site uses <b/>, but you prefer <strong/>, you can easily map one into the other with XSLT.In comparrison, an HTML page can only be properly queried like that if parsed by an SGML parser that would convert it to XML. Later versions of PHP make that statement false though. A valid HTML page could be converted to XML with DOMDocument::loadHTMLFile(), but that doesn't change the situation for every other language out there. Other languages could only parse HTML pages (even valid ones) if they use regular expressions, and if the source site makes a change, everything you've done to select that node and it's contents will blow sky high, foring you to rewrite a complex regex, which is far harder to rewrite than a single XPath expression.To elaborate on that, how would you rewrite a selection for the contents of a <div/> with a certain ID to a <span/> with a certain class, contained somewhere inside a blockquote element with that same old ID? In XPath, it's as easy as turning "//div[@id=specia]" to "//blockquote[@id=special]//span[@class=theOne]". I couldn't possibly begin to image what's the situation with regular expressions. Link to comment Share on other sites More sharing options...
justsomeguy Posted November 20, 2007 Share Posted November 20, 2007 To elaborate on that, how would you rewrite a selection for the contents of a <div/> with a certain ID to a <span/> with a certain class, contained somewhere inside a blockquote element with that same old ID? In XPath, it's as easy as turning "//div[@id=specia]" to "//blockquote[@id=special]//span[@class=theOne]". I couldn't possibly begin to image what's the situation with regular expressions.Right, I understand your point, but I wouldn't save the markup to begin with. I would use a regular expression to get the content inside the div (since that's all I'm interested in), store that in a database, and when it's time to display it I'll stick it in however many blockquotes and spans I want. In practice it doesn't matter what the ID is because the ID is being used by the other site's Javascript or CSS, and I'll be using my own. So it doesn't matter what the ID is. If the ID matters I'll save that in the database along with the content.There are a ton of theoretical good uses for XHTML and XML, but very few in practice. Your sig says it all."Some people, when confronted with a problem, think 'I know, I'll use XML.' Now they have two problems." -- dirtsimple.org Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.