Jump to content
MSFN is made available via donations, subscriptions and advertising revenue. The use of ad-blocking software hurts the site. Please disable ad-blocking software or set an exception for MSFN. ×

Message From YouTube About IE 6 Browser [Solved]


Recommended Posts

No, I actually have have been around for a few years or more ... I've posted before asking for help on a few things and always someone ( or several people ) would have the answer I needed but I never remember anything going more than one page. I feel like I posted something "important" this time, ... 7 pages so far. I had no idea what that simple question would lead too, it's all very interesting, just wish I understood most of it but I don't do web pages and such, but I do understand much more about IE6 and all the problems the browser has.

Edited by duffy98
Link to post
Share on other sites

My choice to obey laws or not is not a part of this, please don't attempt character assassination.

It was an analogy.

since XHTML CAN be interpretted as tag soup, it can degrade fairly gracefully on old browsers while at the same time performing better in browsers that do interpret it like XML

A page being interpreted as tag soup does not degrade gracefully. It gets rendered inconsistently. Considering that 99% of the XHTML pages out there are not sent as application/xhtml+xml, it won't get interpreted as XML either.

Interoperability is a game if it's not your job.

*rolls eyes*

The browser wars fueled rapid innovation, thinking outside the box, and what you consider presentational clutter I consider brilliant work-arounds.

More like nasty hacks. Seriously, did you like visiting a site only to be denied entry because you weren't using their favourite web browser? Or getting a page that looked really bad for the same reason? How about all the deprecated code (especially JavaScript) that is still floated around the web like a cancer for no reason?

A headache to maintain, but the burden was on the developer, not the person viewing it, and those developers decided appearance was what mattered most.

You mean it was fine to create a headache for developers and present bloated web pages to users who were on dial-up, making it longer for them to view the pages?

Let me know when the web is using HTML5.

It already is.

The difference is, in terms of standards compliance, XHTML 1.0 Strict (forgetting any transitional doctype, be it HTML or XHTML) requires it. HTML does not - there is a margin for coding inconsistencies (not necessarily errors, but inconsistencies) in HTML that does not exist in XHTML.

The only difference between the two is that you have to close every element in XHTML if it's sent with the proper MIME type. That you don't have to in HTML does not mean it doesn't require standards compliance. Or are you referring to something else?

By the way, half of that article you linked is hyperbole with misinformation. For instance, it says:

So Ian Hickson, XHTML’s biggest critic, fathered HTML 5, an action-oriented toddler specification that won’t reach adulthood until 2022, although some of it can be used today.

If you bother to read the spec, you'll see that 2022 is jokingly referred to be the year when IE supports HTML5.

The dogma exists because instead of focusing on semantically rich web pages, people pick up XHTML, praise its draconian error handling that forces well-formedness, and then serve it with the wrong MIME type so it's essentially HTML4 with some invalid attributes and weird forward slashes. It completely misses the point.

Then there's also the fact that server XHTML with the proper MIME type has its own share of problems.

Edited by BenoitRen
Link to post
Share on other sites
The difference is, in terms of standards compliance, XHTML 1.0 Strict (forgetting any transitional doctype, be it HTML or XHTML) requires it. HTML does not - there is a margin for coding inconsistencies (not necessarily errors, but inconsistencies) in HTML that does not exist in XHTML.

The only difference between the two is that you have to close every element in XHTML if it's sent with the proper MIME type.

It is not the only difference. For example, elements and attributes have to be lowercase in XHTML. In HTML, you can have one or the other or both. And you're wrong regarding the condition that it be sent with the proper MIME type. The W3C Validator faults uppercase element and attributes names, and unclosed elements, regardless of whether the page is served as text or XHTML.

That you don't have to in HTML does not mean it doesn't require standards compliance. Or are you referring to something else?

You misunderstand and make an incorrect attribution to me. Of course (and this was my point), HTML does not require the degree of well-formedness of XHTML to be standards-compliant. It can mix cases, for example, and yet still be 100% compliant.

I code standards-compliant sites using both HTML and XHTML, and on the whole do not see that one deserves my loyalty over the other. My concern is with building accessible, standards-compliant, semantically- and (where possible) economically-coded sites.

By the way, half of that article you linked is hyperbole with misinformation. For instance, it says:
So Ian Hickson, XHTML’s biggest critic, fathered HTML 5, an action-oriented toddler specification that won’t reach adulthood until 2022, although some of it can be used today.

If you bother to read the spec, you'll see that 2022 is jokingly referred to be the year when IE supports HTML5.

I don't wholly endorse the article I linked to. Indeed, neither does it's author (it would seem). Perhaps you've read the comments in which he and Ian Hickson lend some clarity to the 2022 date. The thrust of the article is sound though - that XHTML 1 is a perfectly stable, mature, and usable standard. Perhaps I should have made the context the article was written in clearer.

No doubt you've read the XHTML 5 spec, then. Maybe you'll be happy to learn that the author of the article I linked to - Jeffrey Zeldman, along with a few friends - has since warmed to XHTML 5:

http://www.zeldman.com/superfriends/

The dogma exists because instead of focusing on semantically rich web pages, people pick up XHTML, praise its draconian error handling that forces well-formedness, and then serve it with the wrong MIME type so it's essentially HTML4 with some invalid attributes and weird forward slashes. It completely misses the point.

I'm really glad that I don't share your agitation with serving XHTML as text. While you do have a point regarding the MIME type, I think such agitation misses a larger point (although, actually, I can't pretend that I really know what the effective consequences of your point are. Please explain if you have the time). Could you explain your assertion that using XHTML instead of HTML means that a developer is focusing less on semantically-rich web pages?

HTML vs XHTML is a trifle. Compliant and semantic code is far more important.

Edited by bristols
Link to post
Share on other sites
This is wrong. We have agreed on standards for a reason.

Who We?

Those who decide of the standards on the internet are the authors of the 1 or 2 web browsers used for viewing more than 55% of the internet.

When IE6 was top #1 browser, the geniuses who coded this crap set the web standards. Now it's not IE6 anymore so the standards have changed.

When Firefox will cover 60% of the internet audiance, it will be the king of the web standards. LTIC (last time I checked), it was still IE7/8 deciding of what pass as a valid html code or not (thought statistics differ).

Soon it might be Firefox or still IE. Later it might be something else.

But it will never be a conference of "professionals".

Webdevelopers, I imagine, will do code that is compatible for 90% of users, standard or not.

IMO, XHTML or HTML is a stpid debate. HTML is fine and it should stay so. It's not necessary to lose our head about yet another format and yet another sublanguage. It's enough complicated like that.

Poeple should use what fits them best.

Edited by Fredledingue
Link to post
Share on other sites
And you're wrong regarding the condition that it be sent with the proper MIME type. The W3C Validator faults uppercase element and attributes names, and unclosed elements, regardless of whether the page is served as text or XHTML.

You said XHTML requires standards compliance, and HTML doesn't. I assumed that you were talking about the check for well-formedness by the web browser upon parsing an XHTML document, which is only done when sent with the proper MIME type.

If you're not talking about that, how does XHTML require standards compliance and HTML doesn't? All XHTML is, is HTML 4.01 formulated as XML. They have the same rules for standards compliance, except that XHTML adds XML rules as well (close every element, everything lower-case).

I code standards-compliant sites using both HTML and XHTML, and on the whole do not see that one deserves my loyalty over the other.

All web browsers support HTML 4.01. Not all web browsers support XHTML, and the parsers of those that do are less tested than their HTML parser. This is why I think it makes sense to choose HTML 4.01 over XHTML 1.0.

Perhaps you've read the comments in which he and Ian Hickson lend some clarity to the 2022 date.

Nah. This point has come up before on another message board.

The thrust of the article is sound though - that XHTML 1 is a perfectly stable, mature, and usable standard.

The problem is that it's not quite usable. See above.

Could you explain your assertion that using XHTML instead of HTML means that a developer is focusing less on semantically-rich web pages?

Almost every web developer that uses XHTML that I've come across goes on about how XHTML forces well-formedness. The web pages they create show that they have little attention for the semantics. Of course, without the proper MIME type, well-formedness is not forced, XML features are not enabled, and they're just writing HTML 4.01.

What many also don't realise is that in XHTML not everything is the same. You can't just embed some JavaScript in your web page, because the data type of the script element is not CDATA. The DOM is a little different as well, so JavaScript needs to be modified.

HTML vs XHTML is a trifle. Compliant and semantic code is far more important.

In the end, this is true.

Those who decide of the standards on the internet are the authors of the 1 or 2 web browsers used for viewing more than 55% of the internet.

Fredledingue, please inform yourself instead of making misinformed posts again and again. You can start at the W3 Consortium's website.

Link to post
Share on other sites

Why is there such a debate over this? If you don't want to upgrade, don't. The web will move on without you. Keep using whatever browser you prefer until it won't work anymore. All this discussion of the details is a waste of time. The sites that have decided not to support ancient browsers anymore aren't going to change their mind because you think they should, so move forward or stay behind.

Link to post
Share on other sites
Why is there such a debate over this? If you don't want to upgrade, don't. The web will move on without you. Keep using whatever browser you prefer until it won't work anymore. All this discussion of the details is a waste of time. The sites that have decided not to support ancient browsers anymore aren't going to change their mind because you think they should, so move forward or stay behind.

QFT. This applies to not only browser but OS wars. However, there is still the issue that older code made to work with IE6 and worked perfectly, does not work with newer browsers. For example, IE6 properly renders CSS 1.0 and no browsers since have been able to do so. So, at least, in my mind, IE6 has some development use.

Link to post
Share on other sites
Why is there such a debate over this? If you don't want to upgrade, don't. The web will move on without you. Keep using whatever browser you prefer until it won't work anymore. All this discussion of the details is a waste of time. The sites that have decided not to support ancient browsers anymore aren't going to change their mind because you think they should, so move forward or stay behind.

QFT. This applies to not only browser but OS wars. However, there is still the issue that older code made to work with IE6 and worked perfectly, does not work with newer browsers. For example, IE6 properly renders CSS 1.0 and no browsers since have been able to do so. So, at least, in my mind, IE6 has some development use.

Why develop for an outdated browser using an outdated standard?

Link to post
Share on other sites
You said XHTML requires standards compliance, and HTML doesn't. I assumed that you were talking about the check for well-formedness by the web browser upon parsing an XHTML document, which is only done when sent with the proper MIME type.

If you're not talking about that, how does XHTML require standards compliance and HTML doesn't?

For the second time: no, I did not say that, and I certainly do not mean that. You have (I guess) misunderstood. Please go back and re-read.

Link to post
Share on other sites
Why is there such a debate over this? If you don't want to upgrade, don't. The web will move on without you. Keep using whatever browser you prefer until it won't work anymore. All this discussion of the details is a waste of time. The sites that have decided not to support ancient browsers anymore aren't going to change their mind because you think they should, so move forward or stay behind.

QFT. This applies to not only browser but OS wars. However, there is still the issue that older code made to work with IE6 and worked perfectly, does not work with newer browsers. For example, IE6 properly renders CSS 1.0 and no browsers since have been able to do so. So, at least, in my mind, IE6 has some development use.

Why develop for an outdated browser using an outdated standard?

CSS 1.0 is the current standard. Note that Drafts and RFCs are not final versions.

Link to post
Share on other sites
For example, IE6 properly renders CSS 1.0 and no browsers since have been able to do so.

Please elaborate on this. As far as I know IE6 completely supports CSS 1.0 only if you count some proprietary features.

You said XHTML requires standards compliance, and HTML doesn't. I assumed that you were talking about the check for well-formedness by the web browser upon parsing an XHTML document, which is only done when sent with the proper MIME type.

If you're not talking about that, how does XHTML require standards compliance and HTML doesn't?

For the second time: no, I did not say that, and I certainly do not mean that. You have (I guess) misunderstood. Please go back and re-read.

I'm royally confused. What else did you mean by this?

He's correct that you can choose to be as strict in HTML as you are in XHTML. Of course you can. The difference is, in terms of standards compliance, XHTML 1.0 Strict (forgetting any transitional doctype, be it HTML or XHTML) requires it. HTML does not - there is a margin for coding inconsistencies (not necessarily errors, but inconsistencies) in HTML that does not exist in XHTML.
Link to post
Share on other sites

Benoit,

The processors in our machines don't care about the code we are using, they don't feel pain or make noral judgement. Nor do they decide what punishment for our sins of bad coding habits.

I maintain that web standards are decided ultimately by those who make web browsers. If tomorrow I make a browser that is used by 90% of poeple, I will decide what standards are and the W3C will only have to bend and acknowledge the truth. My truth.

The W3C is an organisation by fact, only proposing recommandations. And it happens that they are respected and have an influence etc. But they don't "set the standards".

Link to post
Share on other sites
For example, IE6 properly renders CSS 1.0 and no browsers since have been able to do so.

Please elaborate on this. As far as I know IE6 completely supports CSS 1.0 only if you count some proprietary features.

Its an issue found in practice. Refer to this:

http://www.msfn.org/board/fix-display-issue-t137717.html

Which is about my old website design, which was a CMS I wrote myself before IE7 came out. It worked fine but unfortunately IE7 came out before it was completed. :angry:

Link to post
Share on other sites
The processors in our machines don't care about the code we are using, they don't feel pain or make noral judgement. Nor do they decide what punishment for our sins of bad coding habits.

This is completely irrelevant.

I maintain that web standards are decided ultimately by those who make web browsers.

You can repeat this all you want. It's still nonsense.

If tomorrow I make a browser that is used by 90% of poeple, I will decide what standards are and the W3C will only have to bend and acknowledge the truth. My truth.

History disagrees with you. The W3C did not bend in any way when IE had a large majority of the market share. In fact, IE bended to the W3C.

Link to post
Share on other sites
This is completely irrelevant.
I refered to ether some code to make a webpage IE6- compliant was ugly hack or brillant workaround[sic].

You were making a moral evaluation on a piece of code. There not ugly or beautiful codes, nor good or bad.

Only codes that work and other that don't.

History disagrees with you. The W3C did not bend in any way when IE had a large majority of the market share. In fact, IE bended to the W3C.

True the W3C didn't bend but more exactely it was M$ finaly getting a look at the largely FireFox-based W3C recommandations as their browser market share shrank rapidly.

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...