I'm sorry... javascript is a requirement on the modern web.
What makes you say that? Many websites use Javascript, very few rely on it. The majority of Javascript in use on the web is either rollovers or form validation, neither of which are essential (more relevent: neither of which are more important than security).
I have to disagree about Konquerer being the best browser because I've seen a ton of rendering problems. In fact, I would almost say it feels more like netscape 4 to me when I use it.
Hell no. It's not the best browser, but it's miles ahead of Internet Explorer, let alone Netscape 4. It actually supports almost all of CSS 2, for example, whereas Microsoft, who helped write the specification, don't even come close.
Oddly enough the Mac version (safari) doesn't seem to have as many rendering problems.
That's because the Apple team take the KHTML code, build it into Safari, run it through their QA process (fixing a lot of bugs along the way), and then release Safari & the source. The KHTML developers then take the changes bit-by-bit, and merge them back into KHTML where it makes sense to do so. Then the changes sit there until the next KDE release. It sounds like a pain in the neck, but I doubt working directly from KDE CVS is an option for Apple.
people who don't wear bullet proof vests aren't "as liable" as the people who shoot them.
That's a terrible analogy. When you get infected by a worm, it's not just your own welfare put at risk, as your computer then goes on to infect potentially thousands of other machines. A person is responsible for their own computer, and if they don't install updates that their vendor lists as critical, and other people get infected by that computer as a result, then it's not like somebody getting gunned down. They are part of the problem, not just an innocent victim. It's like getting shot, and then taking your revenge out by shooting a load of other people in the area yourself.
That would involve some pretty spectacular artificial intelligence. When authors of websites don't know what they are doing, and instead of marking up headings as such, they choose to put them in a different colour or something, how is a user-agent supposed to understand the change in context and relay that to the user where colour is not available, for instance?
It's a problem similar to optical character recognition, except you aren't just recognising a finite set of glyphs, but trying to extract meaning from a particular picture. In other words, it's a hell of a lot easier to kick up a fuss when somebody screws up a website (HTML starts out accessible for the most part) than inventing whole new AI techniques to cope with code monkey incompetence.
That was a quote from the CSS specification. HTML doesn't have properties or font size keywords. "Font tags" (you mean "font elements" or "the font element type") don't come into it.
The most sensible methodology is to write basic, meaningful HTML, and then use CSS, Javascript, images, etc where they will add to the value of the website where you can do so without constructing barriers for certain groups of people. For the most part, HTML is already accessible, and it takes screw-ups to make it inaccessible. Unfortunately, the types of screw-ups that make websites inaccessible are very common (things like leaving out alt attributes on images, trying to fix font sizes, etc).
As for it being aesthetically pleasing, accessible websites don't have to be boring, but if you have to choose one or the other (you rarely do), wouldn't it be better that somebody could actually use a website, rather than it being a pretty-looking, but ultimately useless toy?
Re: is just as useless in Lynx/Google
on
Core CSS (2nd ed.)
·
· Score: 2, Insightful
If this were XML, we could define an <error> or <important> tag
You mean element type, not tag, and it would be just as meaningless. The rest of the web doesn't know anything about your markup scheme. Throwing the magic word "XML" at it doesn't change this. <span class="error"> doesn't mean anything to any program outside your organisation, nor does <error>. The whole point of using a shared markup language like HTML is that eveybody understands what the markup means and can do useful stuff with it.
The example given in parent, , usually means "error" or "important," so using class="error" or class="important" is far more meaningful to the coder than a deprecated tag, and can be made meaningful in any manner to the general audience with CSS.
CSS is an optional component of the WWW; you are treating it as a required component. Using meaningless code and then being able to kludge a certain presentation so people can understand it is no better than using <font>.
The value of CSS is that you can use meaningful markup without worrying about the presentation. If you don't bother using meaningful markup, then you haven't progressed at all, and may in fact be taking a step backwards (for instance, some people start using <div class="heading"> elements and similar).
But proper structure and hierarchical markup with headers, paragraphs, and properly identified <div> blocks will work wonders: making clear to searchbots what text is important, and giving disabled users an easily-navigable nonvisual UI.
How is a search engine to know that things like <span class="important"> are important? They don't. They do, however, know that <em> elements mean emphasis, etc. The <div> and <span> element types should be used as a last resort, not in place of element types like <em>
I'd have to say that google deliberately alters certain rankings.
They have done in the past for legal reasons. They do not do so for editorial reasons. For instance:
Our search results are generated completely objectively and are independent of the beliefs and preferences of those who work at Google. Some people concerned about this issue have created online petitions to encourage us to remove particular links or otherwise adjust search results. Because of our objective and automated ranking system, Google cannot be influenced by these petitions. The only sites we omit are those we are legally compelled to remove or those maliciously attempting to manipulate our results.
By almost any measure of page rank google would have to be listed first, but it is not. This means that google deliberately lowered their rankings.
No, that is just one possibility. A far likelier reason would be that you don't know the Google ranking algorithm and so haven't taken into account important details.
The specificity of the four selectors are identical, so getting the order wrong frequently causes newbie authors to complain that their link styles aren't being applied. In this case, a conformant CSS implementation wouldn't render an activated link as the author would expect if the mouse happened to be over the link.
Re:CSS, oh how I love thee...
on
Core CSS (2nd ed.)
·
· Score: 2, Insightful
Ah, but <span class="error"> is far more semantic
No it isn't. It might be a bit more useful in site maintenance, but it means nothing to anybody outside of your organisation.
Replacing <font> with <span> is meaningless. Replacing it with an element type that actually means something, like <em> (emphasis) or <strong> (strong emphasis) would be productive. How useful is the meaningless <span> element type in situations where CSS is not used (Lynx, Google, etc)?
Re:What in God's name...?
on
Core CSS (2nd ed.)
·
· Score: 2, Insightful
According to MS, most (althought not all) of the extentions have been submitted to the W3C, so they should get off thier asses and add them to the spec so Mozilla devs can support them without feeling naughty.
Perhaps the people at Microsoft should have gotten off their asses and finished implementing the six year old CSS 2 specification that they co-authored before coming up with proprietary add-ons. As it is, there are huge chunks of CSS 2 support missing or botched in Internet Explorer.
Re:crap for layout - NOT! (well, not entirely)
on
Core CSS (2nd ed.)
·
· Score: 2, Informative
a word in favor of tables: they're NOT deprecated for tabular data, and DESPITE the "zealots'" insistence that they are inherently EVIL for layout, they ARE still "legal" there.
Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.
It seems pretty clear that <table> elements aren't legal for layout purposes, with or without quotes around the word "legal".
There are still issues: fonts are (render?) slightly larger in Moz 1.4 than in ie5.5 or 6.
This is the web; font sizes will vary depending on a whole range of factors and if you are expecting any particular size, then you are doing something wrong.
How are they going to convince set-top manufacturers to support their codec or conglomerates to broadcast it?
Firstly, it's a research project, not a product, so they don't have to convince anyone of anything. But given that it's an open-source project licensed under the GPL among others, I'd imagine the lack of license fees is quite appealing.
It's a Google spamming technique, exactly like spamming your meta tags full of keywords.
Exactly like it? I suppose so, seeing as neither work. Google treats underscores as part of words. If they had wanted to "spam" Google, they should have used dashes to separate the words. Google also ignores <meta> keywords, so both techniques are equally useless.
I think this stems mostly from the very first "Sneak Preview" of LindowsOS that came out two years ago. In that version, we didn't yet have the system in place to set up users, even though it was always planned.
[...]
It's true we don't force users to run as user, but we certainly do everything short of that. We have the user set up an Admin password during install, and then present them with an easy-to-use screen to set up Users. We even have a page, right during install, that discusses security with the user, and explains how to use passwords, set up users, understand the LindowsOS firewall, etc. to increase the security of their computer.
By default, LindowsOS ships with a very strict firewall in place and no open network services. For this reason, remote hacks to the average user are extremely unlikely.
IMHO it's all negated when they use others work without asking (while knowing the art wasn't made by them).
Do you think that the Linspire management can look at a presentation created by their artists and immediately spot when something has originated outside of the company? Or do you think that they told the artists that they had free reign to create business risk by infringing upon copyright?
What's probably happened is that the artist in question has lifted this artwork under the mistaken impression that he had permission (Linspire sponsor kdelook.org) or that he could get away with it. I don't see how you can blame the whole company for that.
At least I don't want to have them around.
That's fair enough, and it's perfectly reasonable for you to feel that way. But I was responding to the statement "I think everyone can acknowledge right now that we'd be better off without them, right?". It's not reasonable to state that everybody wants them to go away.
in essence, it was just as bad as if they'd called their distro "Tedora Core".
That one's been done to death. "Fedora" is not a generic term in the computer industry. "Windows" has been since before Microsoft dreamt up Microsoft Windows.
The only thing they put a quantitive amount on was the codeweavers thing.
Let me get this straight: you are complaining that you don't have a monetary value for the other things? Why is that important?
It doesn't say how many changes they have contributed to Mozilla or how much that "kids" theme cost. There is nothing "substantial" about any of that.
They are paying Daniel Glazman to work full-time on NVU, and all his work goes straight back into the Mozilla codebase. I suggest you look into how much work he's already done for Mozilla to gauge how valuable this is.
Why does it matter how much things like the kids theme costs anyway? Surely the value it brings to the open-source projects is the thing to look at? The open-source projects in question are happy to recieve such contributions. For instance:
Lindows, Inc. uses Mozilla in their Linspire distribution and invests substantially (through outsourcing to Mozdev Group Inc., other Mozilla consultants and through their own development efforts) to see the continued advancement of Mozilla, particularly in regards to usability.
How is it that Linspired contributed WINE, KDE, and Mozilla?
You mean contributed to WINE, KDE and Mozilla? It's all there on the page I linked to. If you are having trouble reading, I'll quote:
Lindows.com is the founder, maintainer, and lead sponsor for Nvu, a complete, easy-to-use Web Authoring System for Linux (such as FrontPage and Dreamweaver).
Lindows.com contributed nearly a half million dollars to CodeWeavers, other 3rd-party developers, and our own in-house engineers to help get Microsoft Office to run on Linux with WINE. 100% of all the code we developed, as well as any code we've paid to have developed and continue to develop, was contributed back to the open source WINE tree.
Lindows.com is a proud sponsor of the KDE League at the highest Corporate Affiliate level. All changes made to KDE are open source and the code is made available to be put in the main tree.
Lindows.com is the proud sponsor of KDE-look.org. KDE-look.org is the premier site on the web to obtain icons, wall papers, themes, etc. for KDE.
Lindows.com is a proud supporter of Mozilla. All changes made to Mozilla are open source and the code is made available to be put in the main tree.
Lindows.com paid for the development of a "kids" theme for KDE which was then contributed to all as open source.
Lindows.com sponsored the first wineCONF (http://lindows.com/wineconf) conference for WINE. (Video from the last conference, held at our offices in San Diego.) Additionally, we paid for the costs to have dozens of WINE developers from all over the world travel to this event.
Lindows.com contributes all changes to Mozilla, Nvu, KDE, WINE, Debian, etc. back to these projects as well as making the source code available. (http://lindows.com/licensing).
That looks like pretty substantial contribution to me. Yeah, they must really be assholes to give us all that!
If you want to throw away the things that they've contributed to the Linux kernel, WINE, KDE, Mozilla, etc, then fine, but don't presume to speak for the rest of us.
As it stands, Mozilla is the best browser for rendering complex/semi-complex css, whereas IE 6 is not too far off. Konqueror on the other hand has trouble with even fairly simple css..
That's rubbish.
Konqueror supports child selectors. Internet Explorer does not.
Konqueror supports adjacent sibling selectors. Internet Explorer does not.
Konqueror supports attribute selectors. Internet Explorer does not.
Konqueror supports the:first-child pseudo-class. Internet Explorer does not.
Konqueror supports the:hover pseudo-class on element types other than <a>. Internet Explorer does not.
Konqueror supports generated content. Internet Explorer does not.
Konqueror complies with the defined CSS error handling. Internet Explorer does not.
Konqueror uses the established '-ua-' prefix for proprietary extensions to CSS. Internet Explorer does not.
Konqueror supports the CSS table model. Internet Explorer does not.
There are whole sections of CSS that just aren't implemented in Internet Explorer. That's not even mentioning Internet Explorer's problems with PNG, HTTP and HTML, or its bugs that cause entire sections of a page to disappear and reappear for no good reason.
For an example of Konq's bad CSS rendering, take a look at this page in all three browsers:
You mean "for an example of Konq's failure to guess at what an author meant when he introduced errors into the page...", don't you? In any case, I can come up with any number of different examples of how a page will break on Internet Explorer but not Konqueror or another browser that complies with the specifications, it's just that you won't find too many of them in the wild, because authors are forced to work around Internet Explorer's deficiencies due to its massive market share.
Konqueror IS half-assed. It doesn't even have type-ahead find.
Konqueror got "find as you type" ("type-ahead find" is the old name for this feature) last month. And what do you mean "it doesn't even have type-ahead find"? It's not a common feature, the majority of end-users don't even know it exists, and it's not exactly a revolutionary step forward for the web. You are talking about it as if it's something as basic as bookmarks.
And I don't even want to get started on its crummy rendering.
Its rendering engine is far better than Internet Explorer's, which is by far the most common browser, so simply writing Konqueror off as "crummy" without giving any specific reasons sounds like an ill-informed rant.
Slashdot Mirror
What makes you say that? Many websites use Javascript, very few rely on it. The majority of Javascript in use on the web is either rollovers or form validation, neither of which are essential (more relevent: neither of which are more important than security).
In fact, CERT advise users to switch off client-side scripting.
Hell no. It's not the best browser, but it's miles ahead of Internet Explorer, let alone Netscape 4. It actually supports almost all of CSS 2, for example, whereas Microsoft, who helped write the specification, don't even come close.
That's because the Apple team take the KHTML code, build it into Safari, run it through their QA process (fixing a lot of bugs along the way), and then release Safari & the source. The KHTML developers then take the changes bit-by-bit, and merge them back into KHTML where it makes sense to do so. Then the changes sit there until the next KDE release. It sounds like a pain in the neck, but I doubt working directly from KDE CVS is an option for Apple.
Tools | Options | General | Accessibility. Tick the "Ignore font sizes specified on web pages" box.
That's a terrible analogy. When you get infected by a worm, it's not just your own welfare put at risk, as your computer then goes on to infect potentially thousands of other machines. A person is responsible for their own computer, and if they don't install updates that their vendor lists as critical, and other people get infected by that computer as a result, then it's not like somebody getting gunned down. They are part of the problem, not just an innocent victim. It's like getting shot, and then taking your revenge out by shooting a load of other people in the area yourself.
You might be interested in KaXUL, a KDE version of XUL (and yes, it is a horrible name).
That would involve some pretty spectacular artificial intelligence. When authors of websites don't know what they are doing, and instead of marking up headings as such, they choose to put them in a different colour or something, how is a user-agent supposed to understand the change in context and relay that to the user where colour is not available, for instance?
It's a problem similar to optical character recognition, except you aren't just recognising a finite set of glyphs, but trying to extract meaning from a particular picture. In other words, it's a hell of a lot easier to kick up a fuss when somebody screws up a website (HTML starts out accessible for the most part) than inventing whole new AI techniques to cope with code monkey incompetence.
That was a quote from the CSS specification. HTML doesn't have properties or font size keywords. "Font tags" (you mean "font elements" or "the font element type") don't come into it.
The W3C (the people behind the HTML, HTTP and CSS specifications) have published the Web Content Accessibility Guidelines for exactly this situation.
The most sensible methodology is to write basic, meaningful HTML, and then use CSS, Javascript, images, etc where they will add to the value of the website where you can do so without constructing barriers for certain groups of people. For the most part, HTML is already accessible, and it takes screw-ups to make it inaccessible. Unfortunately, the types of screw-ups that make websites inaccessible are very common (things like leaving out alt attributes on images, trying to fix font sizes, etc).
As for it being aesthetically pleasing, accessible websites don't have to be boring, but if you have to choose one or the other (you rarely do), wouldn't it be better that somebody could actually use a website, rather than it being a pretty-looking, but ultimately useless toy?
You mean element type, not tag, and it would be just as meaningless. The rest of the web doesn't know anything about your markup scheme. Throwing the magic word "XML" at it doesn't change this. <span class="error"> doesn't mean anything to any program outside your organisation, nor does <error>. The whole point of using a shared markup language like HTML is that eveybody understands what the markup means and can do useful stuff with it.
CSS is an optional component of the WWW; you are treating it as a required component. Using meaningless code and then being able to kludge a certain presentation so people can understand it is no better than using <font>.
The value of CSS is that you can use meaningful markup without worrying about the presentation. If you don't bother using meaningful markup, then you haven't progressed at all, and may in fact be taking a step backwards (for instance, some people start using <div class="heading"> elements and similar).
How is a search engine to know that things like <span class="important"> are important? They don't. They do, however, know that <em> elements mean emphasis, etc. The <div> and <span> element types should be used as a last resort, not in place of element types like <em>
They have done in the past for legal reasons. They do not do so for editorial reasons. For instance:
(From google.com/explanation).
No, that is just one possibility. A far likelier reason would be that you don't know the Google ranking algorithm and so haven't taken into account important details.
The specificity of the four selectors are identical, so getting the order wrong frequently causes newbie authors to complain that their link styles aren't being applied. In this case, a conformant CSS implementation wouldn't render an activated link as the author would expect if the mouse happened to be over the link.
No it isn't. It might be a bit more useful in site maintenance, but it means nothing to anybody outside of your organisation.
Replacing <font> with <span> is meaningless. Replacing it with an element type that actually means something, like <em> (emphasis) or <strong> (strong emphasis) would be productive. How useful is the meaningless <span> element type in situations where CSS is not used (Lynx, Google, etc)?
Perhaps the people at Microsoft should have gotten off their asses and finished implementing the six year old CSS 2 specification that they co-authored before coming up with proprietary add-ons. As it is, there are huge chunks of CSS 2 support missing or botched in Internet Explorer.
The HTML 4.01 specification directly contradicts you:
It seems pretty clear that <table> elements aren't legal for layout purposes, with or without quotes around the word "legal".
This is the web; font sizes will vary depending on a whole range of factors and if you are expecting any particular size, then you are doing something wrong.
That's irrelevent, as porting Theora to Windows is almost certainly much easier than coming up with a whole new codec.
Firstly, it's a research project, not a product, so they don't have to convince anyone of anything. But given that it's an open-source project licensed under the GPL among others, I'd imagine the lack of license fees is quite appealing.
Exactly like it? I suppose so, seeing as neither work. Google treats underscores as part of words. If they had wanted to "spam" Google, they should have used dashes to separate the words. Google also ignores <meta> keywords, so both techniques are equally useless.
That was only the case in the initia; sneak preview. From an interview with the president of Lindows:
Do you think that the Linspire management can look at a presentation created by their artists and immediately spot when something has originated outside of the company? Or do you think that they told the artists that they had free reign to create business risk by infringing upon copyright?
What's probably happened is that the artist in question has lifted this artwork under the mistaken impression that he had permission (Linspire sponsor kdelook.org) or that he could get away with it. I don't see how you can blame the whole company for that.
That's fair enough, and it's perfectly reasonable for you to feel that way. But I was responding to the statement "I think everyone can acknowledge right now that we'd be better off without them, right?". It's not reasonable to state that everybody wants them to go away.
That one's been done to death. "Fedora" is not a generic term in the computer industry. "Windows" has been since before Microsoft dreamt up Microsoft Windows.
Let me get this straight: you are complaining that you don't have a monetary value for the other things? Why is that important?
They are paying Daniel Glazman to work full-time on NVU, and all his work goes straight back into the Mozilla codebase. I suggest you look into how much work he's already done for Mozilla to gauge how valuable this is.
Why does it matter how much things like the kids theme costs anyway? Surely the value it brings to the open-source projects is the thing to look at? The open-source projects in question are happy to recieve such contributions. For instance:
That's straight from mozdev.org.
You mean contributed to WINE, KDE and Mozilla? It's all there on the page I linked to. If you are having trouble reading, I'll quote:
That looks like pretty substantial contribution to me. Yeah, they must really be assholes to give us all that!
I think everyone can acknowledge right now that we'd be better off without them, right?
Absolutely not. They sponsor many websites and open source projects.
If you want to throw away the things that they've contributed to the Linux kernel, WINE, KDE, Mozilla, etc, then fine, but don't presume to speak for the rest of us.
That's rubbish.
There are whole sections of CSS that just aren't implemented in Internet Explorer. That's not even mentioning Internet Explorer's problems with PNG, HTTP and HTML, or its bugs that cause entire sections of a page to disappear and reappear for no good reason.
You mean "for an example of Konq's failure to guess at what an author meant when he introduced errors into the page...", don't you? In any case, I can come up with any number of different examples of how a page will break on Internet Explorer but not Konqueror or another browser that complies with the specifications, it's just that you won't find too many of them in the wild, because authors are forced to work around Internet Explorer's deficiencies due to its massive market share.
Konqueror got "find as you type" ("type-ahead find" is the old name for this feature) last month. And what do you mean "it doesn't even have type-ahead find"? It's not a common feature, the majority of end-users don't even know it exists, and it's not exactly a revolutionary step forward for the web. You are talking about it as if it's something as basic as bookmarks.
Its rendering engine is far better than Internet Explorer's, which is by far the most common browser, so simply writing Konqueror off as "crummy" without giving any specific reasons sounds like an ill-informed rant.
These are end users. Configure your systems to shut down cleanly when they press the off switch. Have a look in /etc/acpi to find out how to do this.