BR tag usage: with or without /

Come again? IE has never given me trouble with pages that are xhtml strict, just because of them being xhtml. It doesn't like png files ( although 7 is much better in this respect ), box rendering, and plenty of other web standards, but it's never given me trouble only because a page is xhtml.

Maybe you thought I was suggesting to run the xslt in the browser ... if you're building static pages, I think transforms blow Dreamweaver away. Do the transform locally, and then upload the new pages that were output. I wouldn't depend on browser support for xslt because Safari doesn't have any.

 

Use <br> in your site and try to validate it in w3c, and it will be recognized as an error because most of the single declaration tags have a slash before closing it.

I have a site that is w3c valid and I have validated it for so many times. Other SEO experts knew that and I don't think that your so-called "SEO-experts" came from a different planet, but I think you are.

 

Search engines are not validation or grammer nazis, all they do is crawl sites to index text content. They'll gobble up content that's marked up with the messiest HTML code that a two year old can throw at it just as well as the neatest clean, minimal, semantic and valid markup.

They simply don't care about the things that we do. Same with our human visitors. They don't care if code is valid. All they care is whether the site "works" or not and is relevant to what they're looking for.

 

IE doesn't give you any problems because you are not serving your XHTML as XHTML. I assume you are using the text/html mime type so as far as IE is concerned, your page is just an ordinary messy HTML page subject to error handling, regardless of whether you know it is perfectly valid. If you point out the doctype, don't bother, IE won't make any decisions based on that other than to decide to render you site in standards mode instead of quirks mode.

By "tag-level changes", I thought you were talking about XSLT after the page has loaded using JavaScript to make on-the-fly changes to the DOM. Failing that, I figured you meant that but for the initial page load instead. Anyway, just because some browsers may not have support, it doesn't rule out XSLT on the client side. I use it and it is not much effort to provide a cached XHTML page created using server side XSLT to UAs that don't support XSLT.

So know that I realise you are using XSLT only to provide the XHTML output you use to store static/cached content for your site, what does well formed xhtml have to do with anything? I assume you are using XSLT to transform content in XML format. Unless you are transforming between a base XHTML page to another format of one, possibly to make different versions for web, print, mobile devices etc.? A waste of effort in my opinion, as transforming an XML page is much easier and has many more advantages.

If search engines cared about valid HTML like the W3 validator does, Google's index for one would reduce from billions of pages to, I'll guess, thousands.

 

I use '<br>' on my sites and it's perfectly valid, because I use HTML 4.01 Strict. Search robots don't give a FUCK if you use <br> or <br /> and you need to realize that there are different doctypes other than XHTML and learn why people use them (*cough* like the wrong mime type for xhtml).

These so called "SEO Experts" need to stop coming up with these bullshit theories and learn how to code before advertising themselves. And people like you need to stop listening to them (much like people need to stop listening to religious nuts and find out the truth for yourself)

 

Ok soulscratch. Give deathshadow his bully pulpit back.

 

I too was confused about <br/> tag and thinking to start a thread but now i am clear about it that alway use <br/> and there is no major difference between br and br/, both preform same task...
thanks All

 

There is a difference, actually. Syntax. <br> is for HTML (HTML 4.01), while <br /> is for XHTML (even if you serve it as HTML).

It's like comparing American English with International English. Americans use "color" while the rest of the world uses "colour" for example.

 

Easy on the words soulscratch, moderators might see your words and ban you instantly. We're just talking about the difference of <br> and <br/> here, because we're not just talking about the validity of the tag, we are also talking about the search engine friendliness of the site. Just in my opinion, we have different opinions here. XHTML sites for me are more SE friendly.

 

It makes no difference whether the site is served real xhtml (application/xhtml+xml) with xhtml doctype, fake xhtml (text/html) with xhtml doctype, or html (text/html) with (duh) html doctype... I think what you're trying to say is that most newer sites that are done in xhtml (code is cleaner) are more friendly than sites done by some programmer with bloated tables (mostly without even a doctype or just html 4 transitional) which is probably true (I'm no "SEO Expert" though) since there's less useless elements (<tr>'s and <td>'s all over the place).

What I'm trying to say is that you can have the same clean code (using an HTML 4 doctype such as STRICT where '<br>' is valid) and that would be just as friendly as an XHTML one.

If a moderator wants to ban me for my attitude towards self proclaimed "experts", then I'll just move onto a different forum where hopefully there are less of these "experts" because this place is SWARMING with them.

 

Yeah, <br> is for HTML, I have seen most of the "Search engine friendly" directories/sites with W3C buttons with them. I wonder why they call it Search Engine Friendly, but all I know that only CSS are search engine friendly even though they are in HTML.

 

I tried both <br> and <br/> and both validate just fine with html strict

 

W3C buttons are a waste of bandwidth, IMO. You can still have crappy ass code (unsemantic and such) and still have your site validate.

 

Which is why the only site I'd ever put them on is something designed to generate CSS or HTML via forms or some such.

 

Well formed means <meta name="x" content="y" /> instead of <meta ...>, ignoring rules like you can't put a table row directly inside a list item. What well formed has to do with anything is that Microsoft's XML DOM throws an exception and returns nothing if you try to pass it markup with <hr> with no closure. I'm working on my own DOM that will process a sloppier document and guess at intent, but in the meantime....

 

Which means jack in terms of web design since IE (even IE7) doesn't parse XHTML as XML, even when you give it the right mime-type... but then I consider using XSLT with web pages one of the most retarded combinations to come along in ages - mostly because the pages I have seen done that way are total crap requiring three to four times the manpower to maintain them than should be needed. (see opera.com)

... and that is EXACTLY the type of thinking that led to the bullshit headaches we have today. Browsers and parsing engines going overboard trying to hide BLATENT ERRORS, BAD CODE and MISTAKES, resulting in coders relying more on the error correcting behavior than on writing VALID CODE in the first damned place.

When there's an error, I firmly believe that browsers, editors, and anything else parsing code should throw an error and STOP EXECUTING - forcing the developer to actually (excuse me while I blaspheme) FIX THE ERROR. (god noes, you mean we might have to write valid code?!?)

You see it all the time on these forums - people asking why their buggy bloated invalid crap code doesn't work in ______ browser. Because they are relying on tools that create crap code (dreamweaver, frontpage), browsers that ignore errors or throw error conditions different from the specification (IE, FF), other people's crap templates that rarely if ever validate much less work cross browser (Joomla, Wordpress) - most of which could have been avoided if the damned browsers just said "WRONG - FIX THE ***ING CODE" instead of doing their damnedest to hide the fact that 90%+ of the coders out there have no ****ing clue what they are doing - much less doing wrong.

See all the HTML, Javascript, PHP and ASP coders that wouldn't last five seconds in a compiled language.

 

I doubt anyone disagrees, except for those that have almost no faith in most of the hacks that call themselves developers out there who will contribute to a large number of pages with errors on them. So of course that is the way to go, but due to the current state of the web, that is not a practical move, and it will ideally be phased out over many years.

One possible move is to use the information bar on invalid pages to inform the user that this site does not use valid code. Surely that will get the message to more people and deter them from slacking off with their code. Or instead of an information bar, an alert box or something - an "in your face" message effectively saying that if you are going to piss off other developers who take the time to write proper code, we are going to give your code and the users of web sites with your code this ugly notice. Um... ok, I got carried away.

Which means jack in terms of web design since IE (even IE7) doesn't parse XHTML as XML, even when you give it the right mime-type... but then I consider using XSLT with web pages one of the most retarded combinations to come along in ages - mostly because the pages I have seen done that way are total crap requiring three to four times the manpower to maintain them than should be needed. (see opera.com)

Can't wait to see these same people sooking again with "why am i getting this parsing error!?" and the like.

Exactly. As for XSLT, it can be done efficiently, but yes, most implementations and examples are crap. I think this is because they are written by people who haven't had much experience and find themselves coding templates that aren't generic, do not derive, and as you said, end up in extra work needed. Ironic really as one of the great advantages I have found with web sites using XSLT is that once the base implementation is done, extending and maintenance involve less work than with conventional web sites. I am finishing up on the revamp of my site which will use XSLT and hope this will be a better example and show the practicality of it.

What about it? Does it use XSLT somewhere on it that I am missing? If so, please tell me as I'm building a list of real world XSLT implementations in web apps.

 

They use it SERVER SIDE (even WORSE) - and to put icing on the cake, their site designers don't even understand the server side parser enough to make it remove the XML prolog - so all of their stylesheets are set up to hack around IE being in quirks mode. (UHG) - great when you are trying to skin one of their blogs... Though skinning Opera blogs is STILL better than the crap blogs like Xanga or MySpace vomit up then try to claim is HTML.

Something I find quite amusing that one of the most standards compliant and well coded browsers out there, with extra emphasis on accessability - has one of the most poorly coded non-standards non-alternative browser websites backed by a wierd mix of early 90's style perl and server side XSLT. (I only know about the perl because their servers broke last week and was showing source )

Much less the total /FAIL/ for using 8 to 10px font sizes. (but that's another subject entirely)

 

I vote for kathy

Take a look at the old templates blogger used for example...

all brs where <br/>

 

Can we please let this thread die?