Just because it's not useful to you, it doesn't make it a buzzword. People's requirements differ wildly. A buzzword remains a buzzword no matter who is involved.
what's wrong with just converting it to a PDF once and uploading it to the webserver alongside the page with a download link pointing to it?
Because we might be talking about a thousand pages of content administered through an online CMS. No, copy-and-paste and print driver kludges are not a universal approach.
if I wanted the data as a PDF, I probably wouldn't have put it on a webpage to start with
Yes, because nobody ever wanted content in two different formats before, did they?
I think that you've dived into these specs and recommendations so deep that you've actually lost the ability to think about things from the practical viewpoint.
And I think you are scrabbling around with kludges and excuses because you can't deal with the fact that XML can be useful.
I ask for practical examples and I get a response consisting of nothing but acronyms starting with X. Buzzwords, whether you think so or not.
That's simply a lie. I gave you descriptions of actual functionality. You then proceeded to tell me that you don't want to do those things and you can do them in other ways. Tough. It's still functionality, practical examples of things you can do.
News to me. But, again, this might shock and dismay you, but I write websites in the real world.
Ahh, yes, the "real world" argument. Loosely translated, it means "I haven't seen it, so it doesn't exist".
I'm also a web developer, creating websites and web applications in the real world. You know how recently I was asked for existing web content, administered through a CMS, to be made available in PDF format? Last week. You know how recently I was working on something involving inline SVG? Last week. So all the work you can get is run-of-the-mill lowest-common denominator HTML crap. That doesn't mean there's nothing else out there.
It doesn't matter how shiny the feature is, if no browsers support it, then it's a waste of my time.
I've already pointed out that "no browsers support it" isn't true, yet you persist with this lie. If all you have to offer are more lies and excuses, don't bother replying.
Here in the real world, people use real browsers, not some ethereal prototype browser W3C wants them to use.
Real browsers like Firefox and Opera? Both of them have support for SVG and MathML.
I guess I'm just a total retard. But at least I'm not a total retard who's impressed with vapid buzzwords.
I gave you concrete examples of actual functionality and you know it. If you think that's "buzzwords", then you don't know the meaning of the word "buzzword". "Web 2.0" is a buzzword. Examples of how you can use XML are not buzzwords. But why am I bothering explaining? You know this, you just don't want to admit there's actual useful functionality that XML provides, so you are using nonsense "buzzword" arguments. You know you aren't making sense, I know you aren't making sense, so why bother keeping up the pretence?
You're supposed to be giving me *practical* examples. I could use a PDF print driver or copy-and-paste to do the same thing without the buzzwords.
I'm suggesting automatically providing web content as PDFs and you are suggesting print driver kludges and copy-and-paste as alternatives? I was right about you preferring to talk bollocks than admit you were wrong.
Except browsers don't support this, so what's the point?
You've totally lost track of the discussion now. We're talking about the justification for the W3C to develop XHTML in the first place. Browser support is irrelevant. In any case, you are wrong, there is browser support for MathML and SVG. It's not universal, but it certainly exists.
This is a waste of memory and time for the huge majority of people.
Memory how? MrNaz has already said it can be cached to disk. Time how? It doesn't have to download anything extra.
If Firefox can keep the contents of tabs I've already closed in memory, they can surely keep the source to the page I am currently viewing on disk.
A web developer will probably not use "view source" very much anyway. Try firebug. That's the way to go if you really want to understand a page. You'll rarely need "view source" after that.
That's simply not true. Firstly, I prefer view source to Firebug. Secondly, Firebug shows you the DOM, not the source. When you're trying to debug JavaScript that modifies the DOM, you often need to see the original source, not the DOM.
If IE tries to be compatible, not just pass one single test (Acid2), why it does so badly on Acid3?
Please try to keep up with the conversation. As has been explained many, many times in the comments here, Acid3 is deliberately constructed to highlight problems in popular browsers. All browsers do badly on Acid3, no matter how well they did with Acid2. There'd be no point in constructing an acid test that browsers did well on.
Passin a single test is not IMNSHO "delivered on".
No, it's not. The improved standards support, which you can verify for yourself, is "delivering on". The Acid2 test being passed is just an example of the improved standards support.
Face it, Microsoft is improving interoperability and support for standards with their work on Internet Explorer. Regardless of your opinion of them, you cannot deny this.
Okay, so how do you suggest I maximize the amount of text on the screen at any one time, while at the same time keeping lines fairly short?
Like the rest of my comment explained, most websites aren't just a single block of text. You don't normally have to make any special arrangement to keep lines short. Sidebars, adverts, etc. do that for you.
I could switch to 640x480, but that'd be a net loss: yeah, I'd get shorter lines, but I could get the same just by wrapping lines at 66 characters at my current resolution.
You completely missed my point. I was explaining one of the reasons why it was even less of a priority when the CSS specifications were being developed.
I think you're trying to argue against my suggestion for multi-column pages
No, I merely pointed out that you were going down the wrong path by thinking about it in terms of element types.
Yes, there may be some instances (like you've pointed out) where my solution doesn't have a problem to solve. Great. What about the other instances
For the second time, I don't have anything against columns. I'm merely pointing out that given the design constraints of the web, it wasn't idiotic for the W3C to not place a high priority on them.
are there anything wrong with my idea for those?
Well I don't like the fact in an n-column display, a reader would get to the end of the first column and be confronted with the start of the n+1 column. But I suppose you could get around that problem with heavy styling.
Why bother coming up with your own ideas though? Do you have anything against the W3C's CSS columns specification? Why don't you post your ideas to www-style?
Making 10 developers change their browser code is much easier than making 10,000 web developers change theirs.
If that were true, how do you explain the legions of web developers complaining about Internet Explorer's shortcomings? It's easier to get all the web developers in the world to change their code than it is to get one single browser vendor to change theirs.
Regardless of whether it is easier in the short-term or not, it's whether it's a good idea that matters. You can muddle through life bolting a piece at a time onto legacy systems until they are twisted out of all recognition and are impossible to maintain, or you can realise that sometimes a careful refactoring can save you a lot of time and grief in the long run. If you've ever maintained a large codebase over a number of years, you'll know this is inarguable. If you always go with what is easiest at any given moment, you dig yourself a hole that can be very hard to get out of.
More regular, but not necessarily more usable.
It's more usable. Something being regular doesn't necessarily make it more usable, but in the case of HTML versus XHTML, that does happen to be the case. Do you disagree? I posted examples earlier.
Yeah. So I can use XSLT to "transform documents" and I can embed data from other namespaces. And yet you haven't told me one actual benefit to it.
I'm sorry, you have been representing yourself as knowledgeable about web development. I assumed you'd know the applications of these technologies. XSLT is a functional template language for XML. You feed it an XML document and a template, and it transforms it according to the rules laid out in the template. For instance, you could dynamically transcode XHTML to OpenDocument format or PDF. Embedding data from other namespaces is an extension mechanism. You can mix and match element types from different document formats. For example, you can embed mathematical formulæ into XHTML by using MathML or vector graphics into XHTML by using SVG.
I missed the part where I'm supposed to change every web page I've ever maintained to XHTML to make someone else's job easier
This part of the argument was talking about the inclusion of <font> in HTML 5. Have you written any code in HTML 5 that uses <font> ? No? Then you don't have any code to change.
Right, I get it. The W3C are at fault for not prioritising a need that you admit doesn't exist. Right.
I didn't admit it didn't exist. There's no point to me replying to your untrue statement.
No, you didn't admit that. I showed that it was hugely exaggerated and you found a way to avoid admitting it by saying that it didn't matter whether it was true or not by making the ludicrous claim that mythical problems are as important as real problems. You know, I don't think you believe half the crap you are coming out with now, I think I've backed you into saying crazy shit because you can't admit when you are wrong.
So let me rephrase. It is ridiculous that you are criticising the W3C for not placing a high priority on a layout technique that you haven't shown a need for. It is ridiculous that you think the W3C are idiots for solving actual problems rather than chasing phantom problems and pandering to myths. It is ridiculous that you claim that problems that don't actually exist should be considered as important as real problems.
Maybe this is just me, but I'm pretty sure that deliberately halting development on your product is one of the best ways to sabotage its compatibility with future developments in the field. For people who aren't interested in splitting hairs, a choice to halt development is for all intents and purposes a CHOICE to avoid compatibility.
Please note the context of my comment. I wasn't pointing out Internet Explorer's improvements in standards support for the sake of it. Somebody claimed that the reason Internet Explorer 6 and 7 did worse than Internet Explorer 5.5 in the Acid3 test was because Microsoft deliberately sabotaged it. I pointed out that they actually improved standards support to debunk that conspiracy theory.
Microsoft halting development simply isn't relevant in this context. So they halted development. So compatibility suffered as a result. That doesn't mean the lower scores of Internet Explorer 6 and 7 are a result of that. They can't be the result of that — no development was happening, so how could the score move in any direction at all?
You claim that they "delivered" on a call for improved standards support, but if the page linked in this article is to be believed, that simply isn't the case.
You misunderstand the purpose of the Acid tests. They are deliberately constructed to highlight flaws in popular browsers. You can't really use the score to judge browsers in the way you are. You can use them as a gauge to see how well a vendor is addressing the issues over time, but the scores are pretty independent between browsers due to the selection of tests.
My guess, although somewhat naive from being based only on these numbers, is that all they did was fix the special cases that would allow them to pass Acid2, the fact of which is revealed by Acid3.
No, that's not even remotely the case. The Acid tests don't work that way. Most of what Acid3 tests is not closely related to what Acid2 tests. As for special-casing the code, feel free to download the Internet Explorer 8 beta and check for yourself.
Your further complaints about them aren't relevant to what I said, which is that Microsoft's and Netscape's actions were very different.
Yes they were.
Well then we've come full circle, because the reason I originally responded to you is because you were claiming the opposite:
Of course, Microsoft does that between IE 6 and IE 7 and it's a horrible crime against humanity, but when Netscape/Mozilla did it, it's all OK.
The simple fact of the matter is that the reasons behind the delay in releases for both browsers were very different, and you acknowledge that, so can I take it you are conceding that it's reasonable to judge them differently for their actions?
Either way it has to ship with the browser, so I don't understand the difference between that and what I said.
Well firstly, no it doesn't have to ship with the browser. Ever heard of transcoding proxies? Some mobile platforms use them. Secondly, including a compatibility filter to statically translate legacy content is an entirely different ballgame to structuring the browser around the legacy content because nobody took the initiative to do any better. Just because there's legacy content out there, it doesn't mean it has to rule the world.
they should know from the study of other Internet protocols that once something's out there on the Internet, it'll be out there until the end of time. Ignoring that fact, yes, that's stupid.
Legacy formats and protocols die all the time. That's not stupid, that's a fact. Where's the demand for Gopher? Active channels? VRML? The bajillion file formats rendered by plugins during the 90s?
Ok, the browser can do it in.6 milliseconds instead of.8 milliseconds. Big whoop.
What part of "it's not just about speed" didn't you understand? Do you understand that code to parse tag soup is hell to develop and maintain compared with parsing XML? That developers have to actually spend time on this? Just because you are at the other end of the pipe sending this crap instead of receiving it, it doesn't mean the problem goes away.
Now explain the benefit to me as a web developer or as an end-user.
As a web developer, you have a simpler, more regular markup language to use. You gain all the advantages of the XML toolchain, so you can use XSLT to transform documents, embed data from other namespaces, etc. End-users only gain indirectly. The easier things are for developers, the quicker they get features, the less overhead is passed on to them in prices, etc.
The W3C has never bothered to explain why I suddenly need to make my pages XML
Of course the W3C have provided rationales. If you've missed them, you are blind. There's a summary at the top of the XHTML 1 recommendation. I find it very hard to believe you would honestly think that the W3C have never given rationales without deliberate effort to bury your head in the sand.
And what's this about "suddenly"? The W3C have made a habit of providing upgrade paths and ways of dealing with legacy technology. When you characterise them as demanding immediate change, you are describing the opposite of their approach.
It's not consumed by people, it's consumed by computers. Computers can deal with that crap in a matter of milliseconds.
Computers need to have code written for them by people in order to consume it. It takes longer than milliseconds to write that code. Are you deliberately avoiding the point? I think I'm being pretty clear in pointing out that efficiency isn't the only fa
Yes. Just because you can easily guess that it's actually the same site served in two different ways, it doesn't mean it looks that way to a web browser. So far as HTTP is concerned, webstandards.org and www.webstandards.org are entirely different sites. The best practice method of making one site available through two hostnames is to have one canonical hostname and set the other to perform a redirect. Often this is overlooked, leading to problems like lower cache hit ratios, cross domain issues and various other annoyances. It's a mirror — an inadvertent and purposeless mirror, yes, but a mirror nonetheless.
But it was though. When you view the Acid test from the canonical address, there is no cross-domain request. When you view it from a mirror, there is. The fact that one of the mirrors happens to be webstandards.org is unimportant. That's not the publicised address for the test, it's an oversight that it's available from that URL at all. By making the unaltered HTML available on a host other than www.webstandards.org, the mirrors (including webstandards.org) are introducing a new factor into the test.
And by taking their ball and going home, Netscape was handing Microsoft the monopoly in this area.
I don't think continuing to develop their browser can truthfully be characterised as "taking their ball and going home", and I don't see what your point is. You tried to make out that Microsoft's and Netscape's actions were the same thing. I pointed out they weren't. Now you are attacking Netscape again. Why? What point are you trying to make? Or are you just looking for an excuse to bash Netscape? Your further complaints about them aren't relevant to what I said, which is that Microsoft's and Netscape's actions were very different.
Of course the validater is going to scream and whine at you for using it
Do you know what a validator is? No validator would "scream and whine at you" for using <font> if the DTD permits it, such as with a Transitional document type. The issue is not one of validity at all, but you sure seem to have a chip on your shoulder about validators. Once more, attacking something for apparently no reason. Why did you bring validators up?
The machines can't be simplier, because they still have to render HTML 4 pages anyway.
Circular logic. "Let's all use a complex document format because we all use a complex document format! Let's ignore planning for the future because the only thing that's important is what's happening right now!" Yes, with your attitude, we'll be stuck with HTML 4 for life. How inspiring.
There's no reason to believe, especially in 2008, that XHTML strict will catch on to the point where browsers can ditch HTML rendering.
Ditch? No. Factor out into legacy middleware to aid maintenance? Why not? And why are you judging the W3C's decisions in 1998 as if they had information available in 2008?
Since the difference between XML and HTML in the browser is on the order of milliseconds, why not save the human being writing the code some time by making it easier?
Yes, why not? XML is far easier and simpler than SGML. For instance, try asking an average web developer when quoting an attribute value is necessary in HTML and when it is necessary in XHTML. They will get the XHTML right, but not the HTML. Try asking them to count the elements in <table><tr><td></td></tr></table> for both HTML and XHTML. They'll get XHTML right and HTML wrong. HTML is full of special cases. XML simplified it significantly.
Are you familiar with how markup parsers work? It's not just the speed that matters. The complexity of the parsing code matters as well. Try comparing code to parse HTML with code to parse XHTML.
If you don't like the FONT tag in HTML5, well, don't use it.
That only helps producers of HTML 5. The people consuming it need to deal with that crap too.
This is an example of exactly what I'm talking about. The vertical space above-the-fold is many times more valuable than the space below-the-fold. (The "fold" being declared as the point below which the average user is required to scroll.) If the W3C spent 5 minutes talking to actual web designers or web developers, they'd know that
Or maybe they did just that and found out that the importance of the fold is hugely exaggerated. Blasting the Myth of the Fold:
Research debunking this myth is starting to pop up, and a great example of this is the report available on ClickTale.com3. In it, the researchers used their proprietary tracking software to measure the activity of 120,000 pages. Their r
why does CSS use this 'float' nonsense instead of the element layout models that have been used for GUI window layout for decades?
Because CSS was designed for documents, not GUIs. The idea is to "pour" the document into the canvas, and make adjustments to the flow as necessary, not to divide up the viewport and put things into it. It makes some things quite a bit simpler and more efficient, especially when you remember that a major design goal of CSS was to incorporate the user's own styles.
As it turns out, not many people were interested in the cascading part of Cascading Style Sheets, and the use of the web as an alternative application platform grew, so this approach doesn't look as sensible as it once did.
It's trivial to define a GUI window in any language and IDE that has one element span across the top of the window, one across the bottom, and three packed horizontally in the middle. That's your classic "Header,Footer,Left Nav,Right Ad,Middle Content" web page layout, and we've known how to make that adjust nicely to variable window sizes forever.
That's been trivial with CSS 2 for a decade using display: table. The only reason people turned to floats for things like that is because Internet Explorer doesn't support that part of CSS 2. Internet Explorer 8 will.
There; that took me all of 10 minutes to come up with a layout box model and multi-column style specification.
That's hardly a workable spec, it's more of an overview than a real specification.
Why is the W3C taking so long to figure out something useful?
This document has been a Working Draft in the CSS Working Group for several years. Multi-column layouts are traditionally used in print. On screen, multi-column layouts have been considered experimental, and implementation and use experience was deemed necessary in order to proceed. Several implementations have occurred over the past years, and this draft incorporates useful feedback from implementors as well as authors and users.
In other words, they fielded ideas, people went off and tried them out, and kept finding problems or coming up with better ideas. It's exactly what would happen if you tried to get people to implement your "spec".
Going from there straight to "no columns" is pulling a fast one, though
I didn't say anything about avoiding columns. I said they weren't a high priority.
The only way of doing both 66 chars/line and packing the screen is by having several lines be adjacent; that is, by doing columns.
You're neglecting to account for the fact that most websites aren't just paragraphs of text. They typically contain one or two sidebars, adverts, etc. The actual main content area of a website is usually significantly smaller. Even within the content area, horizontal whitespace is often necessary, for instance to indicate tree structures such as nested comments.
Furthermore, you're forgetting that the CSS 1 & 2 specifications were written between 1996-98. Screen resolutions were a lot smaller then. Switch to 640x480 and tell me that it's difficult to fill the screen with 66 character wide lines.
I'm toying with an idea for what I think I want: an option for a text block (p or div, no?)
No. You're talking about layout. The element type used for the content is irrelevant to that.
What a lot of people forget is that Safari uses the Webkit rendering engine which is also used in a variety of other browsers whose developers also contribute to it. The stable version of Konquerer 3.5.8 uses the same rendering engine and scores a 52 on the Acid 3 test, better than either Firefox or Opera. So Webkit is being updated and did, in fact, do better than Gecko or Presto for stable release versions when Acid 3 was published.
Actually, Webkit is a fork of KHTML (Konqueror's rendering engine) and the two codebases have diverged quite a bit. If you read the Safari weblog post regarding Acid3, you'll see that Webkit was missing support for some CSS 3 selectors that Konqueror supported. The Konqueror developers provided patches, which is why Safari improved support here, not because it already supported it in an unreleased version.
In my own personal experience every browser other than IE works just fine for rendering everything I create to the standards. There might be the occasional bug or edge case, but I never run across them.
There's plenty there. If Internet Explorer didn't exist, the bugs and different levels of support between the other browsers would be perceived as being huge, but because there's such an obvious extreme outlier, it skews the perception of them.
Netscape/Mozilla also "didn't care" for a long period of time... that multiple-year-long slog between Netscape 4 and Mozilla 6 during which they didn't release a browser whatsoever. Of course, Microsoft does that between IE 6 and IE 7 and it's a horrible crime against humanity, but when Netscape/Mozilla did it, it's all OK.
They aren't even remotely the same actions. Microsoft disbanded the Internet Explorer development team and assigned the developers to different projects. Netscape/Mozilla.org decided to invest extra time rewriting things to get a better end result. I personally think that was a bad investment, but that doesn't mean they killed the browser market and stopped development.
IE is IE because, at the time this code was being written, the "standard" was "what Netscape did."
Actually, Microsoft had a head-start with CSS because Netscape bet on JSSS. The W3C subsequently chose to reject JSSS in favour of CSS, meaning that while Microsoft released Internet Explorer 3 with preliminary CSS support, Netscape scrambled to transcode CSS to JSSS so that Netscape 4 had some kind of CSS support.
So far from the standard being "what Netscape did", it was actually the other way around. The reason why Microsoft is so far behind is entirely their own doing.
All I can say is that I hope HTML5 starts hitting browsers soon... HTML5 is the first Internet standard designed by people who know what people actually use the web for.
Ahh yes, HTML 5, complete with the <font> element type. Because they know what people actually use the web for.
It took THREE VERSIONS to come up with a layout idea that's been used in newspapers for books for literally centuries?!
Web pages have infinite vertical space. Newspapers and books don't. Horizontal space is at a premium for web pages. It's not as important for newspapers and books. Unsurprisingly, a layout strategy that trades horizontal space for vertical space isn't a high priority for a technology primarily aimed at web pages. I wouldn't say that web standards that actually prioritise the web are nothing but "idiocy", I'd say that's entirely sensible.
It's not an intentional part of the test, it's accidental, a side-effect of webstandards.org failing to canonicalise their hostnames. If you read the press release, it only refers to the www version and nowhere is the no-www version mentioned, nor is this issue brought up in the technical guide. If they were trying to include this in the test, they'd have picked a hostname foreign to both the www and no-www versions so that it failed reliably.
I don't think it's fair to count pre-beta software. I remember the quality of Mozilla 0.9 and I distinctly remember choosing Netscape 4 over it. Sure, it supported more CSS, but it was hardly an option for the average person. If it's important, consider my previous statement to be "best released browser around".
But if it's complex and frustrating to do, then I don't have to worry about my 12 year-old self competing with me.
If the ability to handle browser incompatibilities is the only thing that separates you from a twelve year-old, you probably don't deserve your job or its above-average pay scale. Competent developers don't fear competition from children.
Wait, so your argument is that it's only a standard if other people aren't allowed to participate, because they don't always agree with you?
I don't think coming to a consensus is "like if they weren't participating because the result will be a big soup", I think it's the whole point of authoring standards.
I guess it depends on when you consider the war to have ended, but the important point is that Internet Explorer 6 was indeed a marked improvement in standards support over Internet Explorer 5.5, so it's silly to say that it deliberately does worse in a test written the best part of a decade later. If Microsoft were trying to do worse with Internet Explorer 6, then they failed.
It is a problem, but it's not the hard-coding people seem to think it is. The problem is not that Internet Explorer 8 is checking for www.webstandards.org, the problem is that the mirrors that are failing are changing the test in a way that is important to Internet Explorer. Part of the test refers to a page that intentionally doesn't exist in order to check a fallback option. The trouble is that this page is referred to with an absolute URL, which means that when you simply copy the test to another host, it becomes a cross-domain issue.
Ian's pointing out that it's still a failure so it should be subject to the same fallback, which is correct, but the important point is that it's failing to load in a different way to how it would on the www.webstandards.org host because the mirrors didn't take the cross-domain issue into account. I expect the final version of Internet Explorer 8 to correct this problem, but it's not at all a case of Microsoft attempting to "cheat", just an unfortunate coincidence.
Since a lot of bodies don't have the time or manpower to make anything better (and even if they could, it would be quite a waste of time and money), they take what the W3C spits out and implement it.
That's not really true. Browser vendors participate in the W3C working groups that publish these specifications. They have an active role in creating them. Take a look at the acknowledgment section of the CSS 2 specification, for example.
This specification is the product of the W3C Working Group on Cascading Style Sheets and Formatting Properties. In addition to the editors of this specification, the members of the Working Group are: Brad Chase (Bitstream), Chris Wilson (Microsoft), Daniel Glazman (Electricité de France), Dave Raggett (W3C/HP), Ed Tecot (Microsoft), Jared Sorensen (Novell), Lauren Wood (SoftQuad), Laurie Anna Kaplan (Microsoft), Mike Wexler (Adobe), Murray Maloney (Grif), Powell Smith (IBM), Robert Stevahn (HP), Steve Byrne (JavaSoft), Steven Pemberton (CWI), Thom Phillabaum (Netscape), Douglas Rand (Silicon Graphics), Robert Pernett (Lotus), Dwayne Dicks (SoftQuad), and Sho Kuwamoto (Macromedia). We thank them for their continued efforts.
A number of invited experts to the Working Group have contributed: George Kersher, Glenn Rippel (Bitstream), Jeff Veen (HotWired), Markku T. Hakkinen (The Productivity Works), Martin Dürst (W3C, formerly Universität Zürich), Roy Platon (RAL), Todd Fahrner (Verso), Tim Boland (NIST), Eric Meyer (Case Western Reserve University), and Vincent Quint (W3C).
The section on Web Fonts was strongly shaped by Brad Chase (Bitstream) David Meltzer (Microsoft Typography) and Steve Zilles (Adobe). The following people have also contributed in various ways to the section pertaining to fonts: Alex Beamon (Apple), Ashok Saxena (Adobe), Ben Bauermeister (HP), Dave Raggett (W3C/HP), David Opstad (Apple), David Goldsmith (Apple), Ed Tecot (Microsoft), Erik van Blokland (LettError), François Yergeau (Alis), Gavin Nicol (Inso), Herbert van Zijl (Elsevier), Liam Quin, Misha Wolf (Reuters), Paul Haeberli (SGI), and the late Phil Karlton (Netscape).
The section on Paged Media was in large parts authored by Robert Stevahn (HP) and Stephen Waters (Microsoft).
Robert Stevahn (HP), Scott Furman (Netscape), and Scott Isaacs (Microsoft) were key contributors to CSS Positioning.
And of course, one of the four editors of the specification is Håkon Wium Lie, CTO of Opera.
So you see, far from the poor old browser vendors not having the resources to make anything better and passively reacting to anything the W3C says, you can see that the browser vendors are substantially the people who made the specifications.
wasn't IE 5.5 written with code which came over from IE5 for Mac, the first really well done major browser with nice CSS support?
No, it wasn't. Internet Explorer 5.x for Windows uses the Trident rendering engine. Internet Explorer 5.x for the Mac uses the Tasman rendering engine. They are totally different codebases.
which MS dumped when building IE6 for Win, because they could have their flagship internet browser rendering better on those other guy's OS and not their own.
Actually, in most ways, Internet Explorer 6 has better standards support than Internet Explorer 5.x for the Mac.
This might fit in well with Slashdot groupthink, but it doesn't fit in well with reality.
Back when Internet Explorer 6 was being developed, they were in direct competition with Netscape. Internet Explorer 6, when it was released was probably the best browser around when it came to supporting CSS. And you want us to believe that the explanation for 6 being worse than 5.5 in this test was deliberate sabotage by Microsoft?
They abandoned Internet Explorer development when they won the browser war. Sure, at that point you can make a case for them not wanting to be compatible. But at that point, they weren't developing Internet Explorer at all, so you can't use it as an explanation for Internet Explorer getting worse. And when Internet Explorer development was restarted, they were responding to a call for improved standards support,which they have delivered on.
I'm sorry, but deliberate sabotage is a ridiculous way of explaining this. Remember, the Acid tests are designed to trigger flaws in popular browsers. Of course it's going to target Internet Explorer 6 and 7 bugs over ancient versions. Internet Explorer 5.5 is no longer popular, so what's the point in ferreting out bugs for the Acid3 test? The real surprise is that people didn't expect this result.
Slashdot Mirror
Just because it's not useful to you, it doesn't make it a buzzword. People's requirements differ wildly. A buzzword remains a buzzword no matter who is involved.
Because we might be talking about a thousand pages of content administered through an online CMS. No, copy-and-paste and print driver kludges are not a universal approach.
Yes, because nobody ever wanted content in two different formats before, did they?
And I think you are scrabbling around with kludges and excuses because you can't deal with the fact that XML can be useful.
That's simply a lie. I gave you descriptions of actual functionality. You then proceeded to tell me that you don't want to do those things and you can do them in other ways. Tough. It's still functionality, practical examples of things you can do.
Ahh, yes, the "real world" argument. Loosely translated, it means "I haven't seen it, so it doesn't exist".
I'm also a web developer, creating websites and web applications in the real world. You know how recently I was asked for existing web content, administered through a CMS, to be made available in PDF format? Last week. You know how recently I was working on something involving inline SVG? Last week. So all the work you can get is run-of-the-mill lowest-common denominator HTML crap. That doesn't mean there's nothing else out there.
I've already pointed out that "no browsers support it" isn't true, yet you persist with this lie. If all you have to offer are more lies and excuses, don't bother replying.
Real browsers like Firefox and Opera? Both of them have support for SVG and MathML.
I gave you concrete examples of actual functionality and you know it. If you think that's "buzzwords", then you don't know the meaning of the word "buzzword". "Web 2.0" is a buzzword. Examples of how you can use XML are not buzzwords. But why am I bothering explaining? You know this, you just don't want to admit there's actual useful functionality that XML provides, so you are using nonsense "buzzword" arguments. You know you aren't making sense, I know you aren't making sense, so why bother keeping up the pretence?
I'm suggesting automatically providing web content as PDFs and you are suggesting print driver kludges and copy-and-paste as alternatives? I was right about you preferring to talk bollocks than admit you were wrong.
You've totally lost track of the discussion now. We're talking about the justification for the W3C to develop XHTML in the first place. Browser support is irrelevant. In any case, you are wrong, there is browser support for MathML and SVG. It's not universal, but it certainly exists.
Memory how? MrNaz has already said it can be cached to disk. Time how? It doesn't have to download anything extra.
If Firefox can keep the contents of tabs I've already closed in memory, they can surely keep the source to the page I am currently viewing on disk.
That's simply not true. Firstly, I prefer view source to Firebug. Secondly, Firebug shows you the DOM, not the source. When you're trying to debug JavaScript that modifies the DOM, you often need to see the original source, not the DOM.
Please try to keep up with the conversation. As has been explained many, many times in the comments here, Acid3 is deliberately constructed to highlight problems in popular browsers. All browsers do badly on Acid3, no matter how well they did with Acid2. There'd be no point in constructing an acid test that browsers did well on.
No, it's not. The improved standards support, which you can verify for yourself, is "delivering on". The Acid2 test being passed is just an example of the improved standards support.
If you are so concerned about tests, why not try the W3C CSS test suites? Or why don't you check out the 700 new tests that Microsoft is contributing?
Face it, Microsoft is improving interoperability and support for standards with their work on Internet Explorer. Regardless of your opinion of them, you cannot deny this.
Like the rest of my comment explained, most websites aren't just a single block of text. You don't normally have to make any special arrangement to keep lines short. Sidebars, adverts, etc. do that for you.
You completely missed my point. I was explaining one of the reasons why it was even less of a priority when the CSS specifications were being developed.
No, I merely pointed out that you were going down the wrong path by thinking about it in terms of element types.
For the second time, I don't have anything against columns. I'm merely pointing out that given the design constraints of the web, it wasn't idiotic for the W3C to not place a high priority on them.
Well I don't like the fact in an n-column display, a reader would get to the end of the first column and be confronted with the start of the n+1 column. But I suppose you could get around that problem with heavy styling.
Why bother coming up with your own ideas though? Do you have anything against the W3C's CSS columns specification? Why don't you post your ideas to www-style?
If that were true, how do you explain the legions of web developers complaining about Internet Explorer's shortcomings? It's easier to get all the web developers in the world to change their code than it is to get one single browser vendor to change theirs.
Regardless of whether it is easier in the short-term or not, it's whether it's a good idea that matters. You can muddle through life bolting a piece at a time onto legacy systems until they are twisted out of all recognition and are impossible to maintain, or you can realise that sometimes a careful refactoring can save you a lot of time and grief in the long run. If you've ever maintained a large codebase over a number of years, you'll know this is inarguable. If you always go with what is easiest at any given moment, you dig yourself a hole that can be very hard to get out of.
It's more usable. Something being regular doesn't necessarily make it more usable, but in the case of HTML versus XHTML, that does happen to be the case. Do you disagree? I posted examples earlier.
I'm sorry, you have been representing yourself as knowledgeable about web development. I assumed you'd know the applications of these technologies. XSLT is a functional template language for XML. You feed it an XML document and a template, and it transforms it according to the rules laid out in the template. For instance, you could dynamically transcode XHTML to OpenDocument format or PDF. Embedding data from other namespaces is an extension mechanism. You can mix and match element types from different document formats. For example, you can embed mathematical formulæ into XHTML by using MathML or vector graphics into XHTML by using SVG.
This part of the argument was talking about the inclusion of <font> in HTML 5. Have you written any code in HTML 5 that uses <font> ? No? Then you don't have any code to change.
No, you didn't admit that. I showed that it was hugely exaggerated and you found a way to avoid admitting it by saying that it didn't matter whether it was true or not by making the ludicrous claim that mythical problems are as important as real problems. You know, I don't think you believe half the crap you are coming out with now, I think I've backed you into saying crazy shit because you can't admit when you are wrong.
So let me rephrase. It is ridiculous that you are criticising the W3C for not placing a high priority on a layout technique that you haven't shown a need for. It is ridiculous that you think the W3C are idiots for solving actual problems rather than chasing phantom problems and pandering to myths. It is ridiculous that you claim that problems that don't actually exist should be considered as important as real problems.
Please note the context of my comment. I wasn't pointing out Internet Explorer's improvements in standards support for the sake of it. Somebody claimed that the reason Internet Explorer 6 and 7 did worse than Internet Explorer 5.5 in the Acid3 test was because Microsoft deliberately sabotaged it. I pointed out that they actually improved standards support to debunk that conspiracy theory.
Microsoft halting development simply isn't relevant in this context. So they halted development. So compatibility suffered as a result. That doesn't mean the lower scores of Internet Explorer 6 and 7 are a result of that. They can't be the result of that — no development was happening, so how could the score move in any direction at all?
You misunderstand the purpose of the Acid tests. They are deliberately constructed to highlight flaws in popular browsers. You can't really use the score to judge browsers in the way you are. You can use them as a gauge to see how well a vendor is addressing the issues over time, but the scores are pretty independent between browsers due to the selection of tests.
No, that's not even remotely the case. The Acid tests don't work that way. Most of what Acid3 tests is not closely related to what Acid2 tests. As for special-casing the code, feel free to download the Internet Explorer 8 beta and check for yourself.
Well then we've come full circle, because the reason I originally responded to you is because you were claiming the opposite:
The simple fact of the matter is that the reasons behind the delay in releases for both browsers were very different, and you acknowledge that, so can I take it you are conceding that it's reasonable to judge them differently for their actions?
Well firstly, no it doesn't have to ship with the browser. Ever heard of transcoding proxies? Some mobile platforms use them. Secondly, including a compatibility filter to statically translate legacy content is an entirely different ballgame to structuring the browser around the legacy content because nobody took the initiative to do any better. Just because there's legacy content out there, it doesn't mean it has to rule the world.
Legacy formats and protocols die all the time. That's not stupid, that's a fact. Where's the demand for Gopher? Active channels? VRML? The bajillion file formats rendered by plugins during the 90s?
What part of "it's not just about speed" didn't you understand? Do you understand that code to parse tag soup is hell to develop and maintain compared with parsing XML? That developers have to actually spend time on this? Just because you are at the other end of the pipe sending this crap instead of receiving it, it doesn't mean the problem goes away.
As a web developer, you have a simpler, more regular markup language to use. You gain all the advantages of the XML toolchain, so you can use XSLT to transform documents, embed data from other namespaces, etc. End-users only gain indirectly. The easier things are for developers, the quicker they get features, the less overhead is passed on to them in prices, etc.
Of course the W3C have provided rationales. If you've missed them, you are blind. There's a summary at the top of the XHTML 1 recommendation. I find it very hard to believe you would honestly think that the W3C have never given rationales without deliberate effort to bury your head in the sand.
And what's this about "suddenly"? The W3C have made a habit of providing upgrade paths and ways of dealing with legacy technology. When you characterise them as demanding immediate change, you are describing the opposite of their approach.
Computers need to have code written for them by people in order to consume it. It takes longer than milliseconds to write that code. Are you deliberately avoiding the point? I think I'm being pretty clear in pointing out that efficiency isn't the only fa
Yes. Just because you can easily guess that it's actually the same site served in two different ways, it doesn't mean it looks that way to a web browser. So far as HTTP is concerned, webstandards.org and www.webstandards.org are entirely different sites. The best practice method of making one site available through two hostnames is to have one canonical hostname and set the other to perform a redirect. Often this is overlooked, leading to problems like lower cache hit ratios, cross domain issues and various other annoyances. It's a mirror — an inadvertent and purposeless mirror, yes, but a mirror nonetheless.
But it was though. When you view the Acid test from the canonical address, there is no cross-domain request. When you view it from a mirror, there is. The fact that one of the mirrors happens to be webstandards.org is unimportant. That's not the publicised address for the test, it's an oversight that it's available from that URL at all. By making the unaltered HTML available on a host other than www.webstandards.org, the mirrors (including webstandards.org) are introducing a new factor into the test.
This is nonsense. The W3C gave you an easy way of doing exactly what you want a decade ago with CSS 2 tables.
Web standards aren't solely for the benefit of web developers, they are for the people implementing servers and clients as well.
I don't think continuing to develop their browser can truthfully be characterised as "taking their ball and going home", and I don't see what your point is. You tried to make out that Microsoft's and Netscape's actions were the same thing. I pointed out they weren't. Now you are attacking Netscape again. Why? What point are you trying to make? Or are you just looking for an excuse to bash Netscape? Your further complaints about them aren't relevant to what I said, which is that Microsoft's and Netscape's actions were very different.
Do you know what a validator is? No validator would "scream and whine at you" for using <font> if the DTD permits it, such as with a Transitional document type. The issue is not one of validity at all, but you sure seem to have a chip on your shoulder about validators. Once more, attacking something for apparently no reason. Why did you bring validators up?
Circular logic. "Let's all use a complex document format because we all use a complex document format! Let's ignore planning for the future because the only thing that's important is what's happening right now!" Yes, with your attitude, we'll be stuck with HTML 4 for life. How inspiring.
Ditch? No. Factor out into legacy middleware to aid maintenance? Why not? And why are you judging the W3C's decisions in 1998 as if they had information available in 2008?
Yes, why not? XML is far easier and simpler than SGML. For instance, try asking an average web developer when quoting an attribute value is necessary in HTML and when it is necessary in XHTML. They will get the XHTML right, but not the HTML. Try asking them to count the elements in <table><tr><td></td></tr></table> for both HTML and XHTML. They'll get XHTML right and HTML wrong. HTML is full of special cases. XML simplified it significantly.
Are you familiar with how markup parsers work? It's not just the speed that matters. The complexity of the parsing code matters as well. Try comparing code to parse HTML with code to parse XHTML.
That only helps producers of HTML 5. The people consuming it need to deal with that crap too.
Or maybe they did just that and found out that the importance of the fold is hugely exaggerated. Blasting the Myth of the Fold:
Because CSS was designed for documents, not GUIs. The idea is to "pour" the document into the canvas, and make adjustments to the flow as necessary, not to divide up the viewport and put things into it. It makes some things quite a bit simpler and more efficient, especially when you remember that a major design goal of CSS was to incorporate the user's own styles.
As it turns out, not many people were interested in the cascading part of Cascading Style Sheets, and the use of the web as an alternative application platform grew, so this approach doesn't look as sensible as it once did.
That's been trivial with CSS 2 for a decade using display: table. The only reason people turned to floats for things like that is because Internet Explorer doesn't support that part of CSS 2. Internet Explorer 8 will.
That's hardly a workable spec, it's more of an overview than a real specification.
It didn't occur to you to check the obvious place? Quote:
In other words, they fielded ideas, people went off and tried them out, and kept finding problems or coming up with better ideas. It's exactly what would happen if you tried to get people to implement your "spec".
I didn't say anything about avoiding columns. I said they weren't a high priority.
You're neglecting to account for the fact that most websites aren't just paragraphs of text. They typically contain one or two sidebars, adverts, etc. The actual main content area of a website is usually significantly smaller. Even within the content area, horizontal whitespace is often necessary, for instance to indicate tree structures such as nested comments.
Furthermore, you're forgetting that the CSS 1 & 2 specifications were written between 1996-98. Screen resolutions were a lot smaller then. Switch to 640x480 and tell me that it's difficult to fill the screen with 66 character wide lines.
No. You're talking about layout. The element type used for the content is irrelevant to that.
Actually, Webkit is a fork of KHTML (Konqueror's rendering engine) and the two codebases have diverged quite a bit. If you read the Safari weblog post regarding Acid3, you'll see that Webkit was missing support for some CSS 3 selectors that Konqueror supported. The Konqueror developers provided patches, which is why Safari improved support here, not because it already supported it in an unreleased version.
There's plenty there. If Internet Explorer didn't exist, the bugs and different levels of support between the other browsers would be perceived as being huge, but because there's such an obvious extreme outlier, it skews the perception of them.
They aren't even remotely the same actions. Microsoft disbanded the Internet Explorer development team and assigned the developers to different projects. Netscape/Mozilla.org decided to invest extra time rewriting things to get a better end result. I personally think that was a bad investment, but that doesn't mean they killed the browser market and stopped development.
Actually, Microsoft had a head-start with CSS because Netscape bet on JSSS. The W3C subsequently chose to reject JSSS in favour of CSS, meaning that while Microsoft released Internet Explorer 3 with preliminary CSS support, Netscape scrambled to transcode CSS to JSSS so that Netscape 4 had some kind of CSS support.
So far from the standard being "what Netscape did", it was actually the other way around. The reason why Microsoft is so far behind is entirely their own doing.
Ahh yes, HTML 5, complete with the <font> element type. Because they know what people actually use the web for.
Web pages have infinite vertical space. Newspapers and books don't. Horizontal space is at a premium for web pages. It's not as important for newspapers and books. Unsurprisingly, a layout strategy that trades horizontal space for vertical space isn't a high priority for a technology primarily aimed at web pages. I wouldn't say that web standards that actually prioritise the web are nothing but "idiocy", I'd say that's entirely sensible.
It's not an intentional part of the test, it's accidental, a side-effect of webstandards.org failing to canonicalise their hostnames. If you read the press release, it only refers to the www version and nowhere is the no-www version mentioned, nor is this issue brought up in the technical guide. If they were trying to include this in the test, they'd have picked a hostname foreign to both the www and no-www versions so that it failed reliably.
I don't think it's fair to count pre-beta software. I remember the quality of Mozilla 0.9 and I distinctly remember choosing Netscape 4 over it. Sure, it supported more CSS, but it was hardly an option for the average person. If it's important, consider my previous statement to be "best released browser around".
If the ability to handle browser incompatibilities is the only thing that separates you from a twelve year-old, you probably don't deserve your job or its above-average pay scale. Competent developers don't fear competition from children.
Wait, so your argument is that it's only a standard if other people aren't allowed to participate, because they don't always agree with you?
I don't think coming to a consensus is "like if they weren't participating because the result will be a big soup", I think it's the whole point of authoring standards.
I guess it depends on when you consider the war to have ended, but the important point is that Internet Explorer 6 was indeed a marked improvement in standards support over Internet Explorer 5.5, so it's silly to say that it deliberately does worse in a test written the best part of a decade later. If Microsoft were trying to do worse with Internet Explorer 6, then they failed.
It is a problem, but it's not the hard-coding people seem to think it is. The problem is not that Internet Explorer 8 is checking for www.webstandards.org, the problem is that the mirrors that are failing are changing the test in a way that is important to Internet Explorer. Part of the test refers to a page that intentionally doesn't exist in order to check a fallback option. The trouble is that this page is referred to with an absolute URL, which means that when you simply copy the test to another host, it becomes a cross-domain issue.
Ian's pointing out that it's still a failure so it should be subject to the same fallback, which is correct, but the important point is that it's failing to load in a different way to how it would on the www.webstandards.org host because the mirrors didn't take the cross-domain issue into account. I expect the final version of Internet Explorer 8 to correct this problem, but it's not at all a case of Microsoft attempting to "cheat", just an unfortunate coincidence.
That's not really true. Browser vendors participate in the W3C working groups that publish these specifications. They have an active role in creating them. Take a look at the acknowledgment section of the CSS 2 specification, for example.
And of course, one of the four editors of the specification is Håkon Wium Lie, CTO of Opera.
So you see, far from the poor old browser vendors not having the resources to make anything better and passively reacting to anything the W3C says, you can see that the browser vendors are substantially the people who made the specifications.
No, it wasn't. Internet Explorer 5.x for Windows uses the Trident rendering engine. Internet Explorer 5.x for the Mac uses the Tasman rendering engine. They are totally different codebases.
Actually, in most ways, Internet Explorer 6 has better standards support than Internet Explorer 5.x for the Mac.
This might fit in well with Slashdot groupthink, but it doesn't fit in well with reality.
Back when Internet Explorer 6 was being developed, they were in direct competition with Netscape. Internet Explorer 6, when it was released was probably the best browser around when it came to supporting CSS. And you want us to believe that the explanation for 6 being worse than 5.5 in this test was deliberate sabotage by Microsoft?
They abandoned Internet Explorer development when they won the browser war. Sure, at that point you can make a case for them not wanting to be compatible. But at that point, they weren't developing Internet Explorer at all, so you can't use it as an explanation for Internet Explorer getting worse. And when Internet Explorer development was restarted, they were responding to a call for improved standards support,which they have delivered on.
I'm sorry, but deliberate sabotage is a ridiculous way of explaining this. Remember, the Acid tests are designed to trigger flaws in popular browsers. Of course it's going to target Internet Explorer 6 and 7 bugs over ancient versions. Internet Explorer 5.5 is no longer popular, so what's the point in ferreting out bugs for the Acid3 test? The real surprise is that people didn't expect this result.