Slashdot Mirror

The reason for the "bad" web page is to stay backwards compatible, they want their pages to be viewed by as many as possible, and easily viewed in any browser, including text browsers such as lynx. If you check out the source, you'll notice that they are using HTML 2.0, which most of the existing browsers support.

W3C has some info about HTML 2 if anyone is interested.

Perhaps you're unaware of the PNG pHYs chunk, then, which lets you specify the physical resolution of the image.

>To put it another way: It's the page designer's fault for creating overly complex pages.
That's not so simple. Most of times, stupid HTML code is created by WYSIWYG editor, the worst of all being Word (go look at the source code of this example site, if you dare). For a truly better HTML, we need to force the include of a low-speed connection emulator in all HTML editor like Frontpage or Dreamweaver. It would be a very simple navigator, strictly conforming to the standard, and loading the page in memory at about 1.5 kilobyte per seconds. With sometimes random stalled waitings, and, once it's finished loading, it would also output a list of errors like those produced by the official validator. I think the world will be brighter with that.

For those of you able to read French, I wrote a year ago a Strict Code of Internet Ethic who ban unecessary use of images, cookies, applets, etc; and which insist on the necessity to conform to HTML standards. Yeah, except the title, it's in French, not in English.

I just don't have the time or patience to test "oddball" platforms like WebTV, Lynx, Konquerer, etc.

validator.w3.org

Not text files, but text editors. You can start with a text file, insert a couple of html tags here and there, and use htmltidy to format it properly into strictly standards compliant html. It's good for all uses.

A comment about the first point: "the XML parser can, and will validate most syntatical and grammerical errors, but it *cannot* check invalid values". I agree this is a major problem with DTDs, which is why XML Schemas make so much sense. Check out the Primer for more info. It's not a silver bullet, but it's a heck of a lot better than DTDs (although they do have their place)

A comment about the first point: "the XML parser can, and will validate most syntatical and grammerical errors, but it *cannot* check invalid values". I agree this is a major problem with DTDs, which is why XML Schemas make so much sense. Check out the Primer for more info. It's not a silver bullet, but it's a heck of a lot better than DTDs (although they do have their place)

The problem is that in mandating that every single construction be inserted in a way that maintains the document status as "valid HTML," this leaves the problem that the UI has to build pages as a sort of "tree" into which you insert nodes. It may look "WYSIWYG," but the input side is hairy to actually use.

I mostly compose web material by writing DocBook which then transforms to HTML; that provides quite decent guarantees of well-formedness and validity. Mind you, I start with something that may not be valid SGML.

It seems to me that a more usable approach, if composing HTML, is to write it however you like, perhaps a tad messy, and then use tools like Dave Raggett's HTML Tidy utility.

Amaya is well and interesting; I suspect that it is only of practical interest to people that are working specifically on HTML standardization, and of limited interest to anyone else.

I am viewing /. on Amaya right now and I must say that it looks awful compared to its usual Netscape apperance. I checked a bunch of other sites (most notably altavista and netscape which look absolutely abysmal, and slashdot and Yahoo!, which looks quite poorly coded). Even the w3c's website looks a little different. I think webmasters who are a little to liberal in their coding practices need to re-evaluate the ease of producing nice, clean HTML. Of course, I am a guilty party as well, but this seems to be a serious and widespread problem.

----------------------------------------------

If anyone is a bit unsure of what a DTD is, you may be interested to see how Slashdot (and the Slash code in general) use XML and DTDs.

Slashdot (again, Slash if it's setup to) produces all headlines in a convienient, machine-readable format. It can be found at www.slashdot.org/slashdot.xml .

At the same time, the DTD for this file (called 'Backslash' and can be found at www.slashdot.org/backslash.dtd) essentially describes to an XML parser what is and what is not allowed in the file. It essential defines what constitutes a "valid" document; it is valid meaning that when compared against the DTD, it conforms to the defintion.

"Well-formed" is another XML term which means it at least is formatted correctly accordingly to the XML definition (for example, single tag elements end in a backslash.)

If you're interested in learning about XML and this DTD stuff, as well as all the latest proposals that are meant to replace DTDs (such as XML Schema's), check out the official W3C site at www.w3.org/XML/.

If anyone is a bit unsure of what a DTD is, you may be interested to see how Slashdot (and the Slash code in general) use XML and DTDs.

Slashdot (again, Slash if it's setup to) produces all headlines in a convienient, machine-readable format. It can be found at www.slashdot.org/slashdot.xml .

At the same time, the DTD for this file (called 'Backslash' and can be found at www.slashdot.org/backslash.dtd) essentially describes to an XML parser what is and what is not allowed in the file. It essential defines what constitutes a "valid" document; it is valid meaning that when compared against the DTD, it conforms to the defintion.

"Well-formed" is another XML term which means it at least is formatted correctly accordingly to the XML definition (for example, single tag elements end in a backslash.)

If you're interested in learning about XML and this DTD stuff, as well as all the latest proposals that are meant to replace DTDs (such as XML Schema's), check out the official W3C site at www.w3.org/XML/.

To answer some bonehead who started trashing XSL as a useless standard, I think he should take a close look at the official XSL-Transformation specification to understand all the benefits XSL brings to building global and device-independent web applications.

Now I do think XSL-T should be renamed to something else do emphasize its transformation abilities rather than tagging it as a mere "styling language".

I think styling should remain the job of CSS, that various flavors of CSS should be developed for each mainstream markup language suited for a given set of platforms and user-agents. I think a basic platform/user-agent-specific markup language should define elements of formatting and structuration of information and a custom-fitted version of CSS should be developed to allow developers to define more precise elements of style like font sizes, faces, colors, backgrounds and such.

And I think XSL-T should be renamed "eXtensible Markup Transformation Language".

bleh.

If you are working on a new project use XML Schema rather than DTDs. DTDs are a hangover from the days of SGML and do not allow you much control on the content of your documents.

If you use XML Schema then you can specify exactly the format and content of your fields and validate the document much more precisely than just PCDATA / CDATA permits.

Go and have a look at the W3C site before you commit yourself, it is an easy change at the start of a project but will be much harder later.

Description of XML schema can be found at http://www.w3.org/XML/Schema .

Letting ICANN do it is even worse. We should not set a precedent by letting ICANN censor broad swaths of the namespace for private users who are adults. ICANN is nonrepresentative, and can't be trusted. (Although, slimy as the unelected part of the ICANN board is, it's to their credit that they said "no thanks" to this kind of censorship power.)

What about PICS? PICS isn't broken, so why fix it? Let librarians turn on PICS for kid websurfers. Problem solved.

--

Amaya is surely buggy as hell. It's image rendering seems to cause random lines nearby images, align images slightly wrong and css support is far from correct. For example see w3.org/Style with Amaya and Mozilla or IE5.5 (which renders some of it incorrectly though). I wonder if the page is really supposed to look like it. Also it seems to fail even the first test of CSS Test Suite. Thanks but I think I will continue to check my web pages with validator.w3.org, Mozilla and IE5.5.
_________________________

Amaya is surely buggy as hell. It's image rendering seems to cause random lines nearby images, align images slightly wrong and css support is far from correct. For example see w3.org/Style with Amaya and Mozilla or IE5.5 (which renders some of it incorrectly though). I wonder if the page is really supposed to look like it. Also it seems to fail even the first test of CSS Test Suite. Thanks but I think I will continue to check my web pages with validator.w3.org, Mozilla and IE5.5.
_________________________

Amaya is surely buggy as hell. It's image rendering seems to cause random lines nearby images, align images slightly wrong and css support is far from correct. For example see w3.org/Style with Amaya and Mozilla or IE5.5 (which renders some of it incorrectly though). I wonder if the page is really supposed to look like it. Also it seems to fail even the first test of CSS Test Suite. Thanks but I think I will continue to check my web pages with validator.w3.org, Mozilla and IE5.5.
_________________________

Amaya is surely buggy as hell. It's image rendering seems to cause random lines nearby images, align images slightly wrong and css support is far from correct. For example see w3.org/Style with Amaya and Mozilla or IE5.5 (which renders some of it incorrectly though). I wonder if the page is really supposed to look like it. Also it seems to fail even the first test of CSS Test Suite. Thanks but I think I will continue to check my web pages with validator.w3.org, Mozilla and IE5.5.
_________________________

Definitely/A& gt; slashdot.

Your way of creating standards kills brilliance. There are a few people out there who are really brilliant, but nobody is capable of seeing it, so they're not scratching itches. Then, you've got a few idiots coming along trying to convince everybody that they actually have a good product, and since nobody understands brilliance even when it's before their eyes, well, the result is apparent, two identical sucky browsers.

I can't believe I missed out XSL Transformations and XML Query!

I can't believe I missed out XSL Transformations and XML Query!

The market has made the W3C irrelevant. Users and developers fo theWeb don't care what the W3C has to say, it's all about market share and ease of use.

That is untrue because everyone wants to get onto the XML bandwagon. XML, and all the accompanying technologies (such as XML Schema and XML Linking) provide a standard, open way of storing and manipulating data which is far more powerful than, say, SQL. IE-only web pages may work today, but most organisations who want to do any serious content management are at least considering XML-based systems for the future, and so XHTML-compliant web pages will be a no-brainer once browsers start to support XHTML fairly well (which is basically true of IE 5.5 and Netscape 6).

Not long ago I would have agreed with your view that the W3C was becoming irrelevant. However, the stunt they have pulled with XML is extremely nice - pulling people towards a powerful open standard because it is powerful, open and standard :-)

The market has made the W3C irrelevant. Users and developers fo theWeb don't care what the W3C has to say, it's all about market share and ease of use.

That is untrue because everyone wants to get onto the XML bandwagon. XML, and all the accompanying technologies (such as XML Schema and XML Linking) provide a standard, open way of storing and manipulating data which is far more powerful than, say, SQL. IE-only web pages may work today, but most organisations who want to do any serious content management are at least considering XML-based systems for the future, and so XHTML-compliant web pages will be a no-brainer once browsers start to support XHTML fairly well (which is basically true of IE 5.5 and Netscape 6).

Not long ago I would have agreed with your view that the W3C was becoming irrelevant. However, the stunt they have pulled with XML is extremely nice - pulling people towards a powerful open standard because it is powerful, open and standard :-)

The market has made the W3C irrelevant. Users and developers fo theWeb don't care what the W3C has to say, it's all about market share and ease of use.

That is untrue because everyone wants to get onto the XML bandwagon. XML, and all the accompanying technologies (such as XML Schema and XML Linking) provide a standard, open way of storing and manipulating data which is far more powerful than, say, SQL. IE-only web pages may work today, but most organisations who want to do any serious content management are at least considering XML-based systems for the future, and so XHTML-compliant web pages will be a no-brainer once browsers start to support XHTML fairly well (which is basically true of IE 5.5 and Netscape 6).

Not long ago I would have agreed with your view that the W3C was becoming irrelevant. However, the stunt they have pulled with XML is extremely nice - pulling people towards a powerful open standard because it is powerful, open and standard :-)

If your page looks depends on images and only images you can use are bitmap ones you have to stick with pixels. Unless of course browsers had decent image scaling build in. I would love to design page layouts simply by looking specs in the w3.org and it would work in any browser on any platform. Unfortunately, majority never updates their browsers.

In the end, there is so many broken browsers and pages out there one should have browser that threats pixels as defined distance. That way one could define that "pixel" is 0.5 mm and be done with it - no matter how big or small his/her screen resolution is. In fact Opera seems to have something like this already (at least it scales images) - in the future others too. I can only hope.
_________________________

Indeed, even the specification site admits that "MathML is not primarily intended for direct use by authors. While MathML is human-readable, in all but the simplest cases it is too verbose and error-prone for hand generation." This means: people will not write their publications in MathML. They will write their publications in TeX/LaTeX or some other program and publish the result as MathML.

From an authorship standpoint, MathML has the following serious shortcomings with respect to TeX/LaTeX:

• No support for macros or functions
• No support for internal citations (you can't cite a previous theorem as an abstract object; you have to cite it by its number, and keeping track of numbers by hand sucks)
• Lack of outside bibliographic database integration
• Doesn't look good on paper (no web browser can begin to match the years of thought that went into TeX's typesetting engine--kerning, ligatures, n-cubed optimal hyphenation, etc.)

<cn type="complex">3<sep/>4</cn>

A couple of guys with pet peeves that didn't make the cut whining doesn't make "heavy criticism". Sure it's easy to have a superior browser if you never release it. Saying Mozilla is better than Netscape is mainly missing the point: Netscape shipping products is (mainly) what pays for continued Mozilla development. They complement one another. Mozilla will chug away indefinitely, (generally) improving slowly day by day. But it doesn't improve that fast: delaying the ship by a month would have made a better browser, no doubt. But then so would delaying by another, and another...

Looking back on the complaints, they look kind of silly: trying to stop the ship only a few days before release because the development team were only taking showstopper bugs. That's what you do when you're about two days away from shipping, guys.

Have a look at the W3C's CSS test pages. Where was the petition not to ship IE until it had proper CSS support? Sure, NN6 isn't perfect either but it does a hell of a lot better than IE; it's unreasonable to expect 100% quality before release.

You forgot about:
Slashdot

Check out two of my favorites:
Here
and here

Check out two of my favorites:
Here
and here

The REAL jabber has the /. user id: 13196

Programming for Netscape? See this. If you're good, I don't see a problem. If you mean "writing HTML" take a look at: http://www.w3.org/! Stick to the rules dude! Keep all f*cked up new "techniques" away from the web.

Just because you are using a non MS product browser doesn't mean the errors are Microsoft's fault. Try the following links to see who is compliant

Netscape
Microsoft
; Red Hat
Oracle
IBM
Apache

Just because you are using a non MS product browser doesn't mean the errors are Microsoft's fault. Try the following links to see who is compliant

Netscape
Microsoft
; Red Hat
Oracle
IBM
Apache

Just because you are using a non MS product browser doesn't mean the errors are Microsoft's fault. Try the following links to see who is compliant

Netscape
Microsoft
; Red Hat
Oracle
IBM
Apache

Just because you are using a non MS product browser doesn't mean the errors are Microsoft's fault. Try the following links to see who is compliant

Netscape
Microsoft
; Red Hat
Oracle
IBM
Apache

Just because you are using a non MS product browser doesn't mean the errors are Microsoft's fault. Try the following links to see who is compliant

Netscape
Microsoft
; Red Hat
Oracle
IBM
Apache

Just because you are using a non MS product browser doesn't mean the errors are Microsoft's fault. Try the following links to see who is compliant

Netscape
Microsoft
; Red Hat
Oracle
IBM
Apache

You mean the "nonstandard proprietary HTML qualifier" onload as documented in the html specs?

XSL/XSS/XML/XSLT/DTD are all required in order to make the solution work at full strength. It's a big learning curve and many people aren't comfortable with it. It's not easy to begin with and having to do it on the fly is even worse.

Secondly, it uses a lot of really new technology and not all the kinks have been worked out yet. There are engines like Cocoon, etc that you can use, but that can make things even more difficult. I am a HUGE proponent of things like XML, Java, and LDAP. I have been preaching Java to people for 6 years and my friends are FINALLY starting to listen to me. Write it one time, run it anywhere. No more porting to new hardware!

I am also preaching about XML et al, but at the same time you have to use the appropriate tool for the job. You don't use a tactical nuke to kill a mosquito and you don't use XML for small things because the coding is so intensive.

I suggest you visit the W3C and read about what's been going on and what's coming in the world of XML. When in doubt, go to the source. In this case, the folks that write the standards.

No.

Microsoft fails. Pretty severe failures, at that.

All the others work, though.

What really worries me is that apparently the new TLD "owners" are going to be free to act as censors. As reported in the most recent Newsweek, the frontrunner in applications for a new ".kids" TLD says they're going to reject any sites that don't meet societal norms for children. Since a TLD is a global resource, this seems to beg the question of whose norms they're talking about. Are we ready for a ".god" TLD owned and censored by Christian fundamentalists? We've got PICS for proecting kids from porn, so why do we need to add new censorship mechanisms to the web?

How ironic is that.

Well, slashdot won't let me post the link. It keeps inserting spaces. Anyway, just plug http://www.uwink.com/netscape/4_5/i nde x.html into http://validator.w3.org

The site looks like crap, even on the "just for Netscape 4.5" version.

They have a bad case of the bad HTML.

Why is it so hard to write valid HTML?

CSS2, unlike CSS1, is a huge standard. Full compliance is hard. Mozilla is almost there, followed by Opera, and IE not far behind. Even if most of CSS2 is implemented, the parts that are not are enough to make a web designer's job more difficult.

CSS level 3 is slated to be even huger, but at least it has the decency to be modularized, and you don't have to implement all modules.

CSS Mobile Profile breaks rank from the modularization in making a CSS2 light. The working draft is a clean subset of CSS2, if you support CSS2, you support this draft (as CSS level 1 and 2 were made with handheld devices in mind too). All it does is to say that it is OK for a handheld device not to support this and this and this CSS property.

This is a bit of a non-event really, the title "Mobile Profile" makes you think that this is related to CC/PP capability negotiation, while in practice it is CSS2 with the hard bits left out.

CSS2, unlike CSS1, is a huge standard. Full compliance is hard. Mozilla is almost there, followed by Opera, and IE not far behind. Even if most of CSS2 is implemented, the parts that are not are enough to make a web designer's job more difficult.

CSS level 3 is slated to be even huger, but at least it has the decency to be modularized, and you don't have to implement all modules.

CSS Mobile Profile breaks rank from the modularization in making a CSS2 light. The working draft is a clean subset of CSS2, if you support CSS2, you support this draft (as CSS level 1 and 2 were made with handheld devices in mind too). All it does is to say that it is OK for a handheld device not to support this and this and this CSS property.

This is a bit of a non-event really, the title "Mobile Profile" makes you think that this is related to CC/PP capability negotiation, while in practice it is CSS2 with the hard bits left out.

As it turns out, that's not a problem: most cellphone browsers wind up first sending a request to a special WAP server, which is connected to the internet, and from there on out everything is normal HTTP. Presumably, one would have this server pick up some of the parsing.

And hey, I think XML is pretty cool - last year, my summer job was all about XML. Although the idea was to take an XML document you knew nothing about and allow people to do intelligent searches on the thing. Head on over to xfront.org for more information about this.

Actually, XML has one cool use - suppose that Slashdot generated the comments and all the pages in XML. So there would be a <comment> tag and so-on. Then, using XSLT you transform the XML document into HTML. That way, if you ever wanted to change the look, you just edit the XSLT, and everything changes to the new look. Unfortunately, that requires XML and XSLT parsers to be on the client-side. (Or you can do it server-side and watch Slashdot be crushed under the load.)

When you get right down to it, XML is really just the SGML spec reimplemented with certain pieces removed. The pieces they removed actually makes it easier to parse - but there's no way to understand what an XML document actually means. (Which was what I was supposed to solve.) XML Schemas are supposed to help this in some way. The thing XML is really useful for, though, is simply having a standardized way of formatting data, so any parser can read it in. Then an application needs to know enough about the document to determine what it means. In that way, XML is really just a flat-file database, which happens to look like SGML.

As it turns out, that's not a problem: most cellphone browsers wind up first sending a request to a special WAP server, which is connected to the internet, and from there on out everything is normal HTTP. Presumably, one would have this server pick up some of the parsing.

And hey, I think XML is pretty cool - last year, my summer job was all about XML. Although the idea was to take an XML document you knew nothing about and allow people to do intelligent searches on the thing. Head on over to xfront.org for more information about this.

Actually, XML has one cool use - suppose that Slashdot generated the comments and all the pages in XML. So there would be a <comment> tag and so-on. Then, using XSLT you transform the XML document into HTML. That way, if you ever wanted to change the look, you just edit the XSLT, and everything changes to the new look. Unfortunately, that requires XML and XSLT parsers to be on the client-side. (Or you can do it server-side and watch Slashdot be crushed under the load.)

When you get right down to it, XML is really just the SGML spec reimplemented with certain pieces removed. The pieces they removed actually makes it easier to parse - but there's no way to understand what an XML document actually means. (Which was what I was supposed to solve.) XML Schemas are supposed to help this in some way. The thing XML is really useful for, though, is simply having a standardized way of formatting data, so any parser can read it in. Then an application needs to know enough about the document to determine what it means. In that way, XML is really just a flat-file database, which happens to look like SGML.

We can credit W3C for being forward-looking, but I expect that CSSMP will go the way of WAP.

Perhaps not. I believe the point of this newly crafted subset of CSS2 is to provide a stable reference for useful functions that ought to be in mobile devices (meaning ultra-portable devices with limited display capabilities, and not meaning laptops which might have better display capabilities than many quite old desktop computer layouts with small VGA monitors which are still in use throughout the world).

This area is of keen interest to me, and after the long agony with simple HTML 3.2/4.0[1]+ and with CSS1 through the still not-quite-totally-there CSS2, any way to avoid any more standards wrangling will come as a great relief to those of us who have to actually do this stuff for a living. I'd imagine that XSLT 1.0+ engines will do much of the actual work, and it really helps to be able to more or less reuse all that existing work with a near-exact subset of CSS2.

Anyways, I'm back (in a few minutes, after a little more procrastination) to figuring out how to most efficiently split up parts of (simple for now) XML documents for later Java/Python XML/XSLT processing, while allowing simpler, more immediate PHP 4.0+ XML processing. Argh ....