I don't consider Opera 8 weak on JS, though it has been the case with earlier versions of Opera.
It certainly has an XML parser, has had since Opera 4. Since it uses XML for many of the formats it support, like WML, SVG, and XHTML+Voice it would have to. It could style and link XML since version 4 and supported namespaces since version 5. However it does not support client-side XSLT.
No, it hasn't been removed. It has got an icon of its own (the trash can). Personally I prefer the option to have a Window menu and then the closed windows reside in that menu too, just like in Opera 7.
A quick Google search reveals this Q42004 presentation that apparently shows them not doing so hot, and I think that maybe the advancement of Mozilla/Firefox has bitten into at least a small portion of their market.
Actually Opera Software is doing well, on desktop too. The desktop revenues last year increased with 43%, and 88% year on year for Q4 2004, which was the quarter when FireFox 1.0 was released. Those are not numbers of a struggling company. In fact all browsers benefit from an awareness that there are alternatives to Internet Explorer.
Yes, and furthermore browser incompatibilities would be irrelevant in a XSL vs CSS discussion anyway. Incompatibilities, in the sense of two browsers rendering the same document differently, isn't resolved by XSLT. The outcome of XSLT would be another document, usually (X)HTML, and surprise! browsers render that document differently.
If the outcome is to be presented by browsers you will always be dependent on those browsers, the number of transformation steps you have done before rendering won't help. (X)HTML has had very few if any rendering requirements. CSS is more stringent. If two browsers differ you can usually tell if one (or both) browsers are wrong. Wrong is contextual however, it may well look different on a phone than with a printout with a user style sheet.
First, of course it is a question of definition what is meant to implement CSS, level 1 or level 2. I would say though that Mozilla and Opera 4 supports CSS1. There are a couple issues before full CSS1 support can be crossed off as a done deal (Netscape 4.* sucks though). The remaining few issues may annoy, but won't break any reasonable design.
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.
I have no particular opinion on the proposed new TLDs,.banc seems reasonable,.shop a little more dubious (unless there is a sensible second-level domain system). But I strongly disagree in that it won't do anything beneficial.
Sure, banks and FIs have already their names and variations registered, but there are hundreds of TLD times hundreds of variations, not even the biggest of institutions can cover all of these. If.banc can be maintained by a reliable international financial institution with an authorative list of acceptable applicants (and no, NSI is not the first institution that springs to mind),.banc will have higher value than.com which is free-for-all.
.com is bloated and oversubscribed, with the consequences of DNS slowdowns and the registration of ever more contrieved names. Usenet was in the exact same situation 20 years ago. They used a radical solution that is hard to repeat today, they changed the existing names, forcing them into subdomains. Any other change won't help in the short term, and as long as multiple registrations and a dread of subdomains is the rule, inefficiency is the inevitable result. Most good short names (known companies, evocative English words) are already gone, and your option is either a-very-long-n-contrieved-name.com or shortname.lingerie.shop. You would register both, but most likely you'd use the second in your ads.
Generally, it is useful to separate between TLTLDs and TLTLDs (two letter top level domains and three letter top level domains). The two letter domains (country codes) generally do well, even if some of them are underused (.us) and other overused for other purposes (.tm,.tv,.md), and others may be so in the far-out future (.ai and.et;.sf is vacant as Finland use.fi). There are a couple hundred of these, but there is an established standard maintaining them.
The three (and soon four+) letter domains are more ad hoc. Some of these (.gov and also.edu) are US only, others (.com,.net,.org) are used internationally, one (.int) is only used by international organisations. TLDs with clear rules for which entities belong and which don't belong in that domain, and preferably with a predictable subdomain-structure and naming conventions should have an advantage.
Slashdot Mirror
I don't consider Opera 8 weak on JS, though it has been the case with earlier versions of Opera.
It certainly has an XML parser, has had since Opera 4. Since it uses XML for many of the formats it support, like WML, SVG, and XHTML+Voice it would have to. It could style and link XML since version 4 and supported namespaces since version 5. However it does not support client-side XSLT.
No, it hasn't been removed. It has got an icon of its own (the trash can). Personally I prefer the option to have a Window menu and then the closed windows reside in that menu too, just like in Opera 7.
Actually Opera Software is doing well, on desktop too. The desktop revenues last year increased with 43%, and 88% year on year for Q4 2004, which was the quarter when FireFox 1.0 was released. Those are not numbers of a struggling company. In fact all browsers benefit from an awareness that there are alternatives to Internet Explorer.
Yes, and furthermore browser incompatibilities would be irrelevant in a XSL vs CSS discussion anyway. Incompatibilities, in the sense of two browsers rendering the same document differently, isn't resolved by XSLT. The outcome of XSLT would be another document, usually (X)HTML, and surprise! browsers render that document differently.
If the outcome is to be presented by browsers you will always be dependent on those browsers, the number of transformation steps you have done before rendering won't help. (X)HTML has had very few if any rendering requirements. CSS is more stringent. If two browsers differ you can usually tell if one (or both) browsers are wrong. Wrong is contextual however, it may well look different on a phone than with a printout with a user style sheet.
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.
My thoughts too. NeXT is like a biological virus (err, ViRUS) that invaded its host apple and after a dormant stage may become virulent again.
Even from a Forbes viewpoint, being bought out is on average more often a winning strategy than buying someone out.
I have no particular opinion on the proposed new TLDs, .banc seems reasonable, .shop a little more dubious (unless there is a sensible second-level domain system). But I strongly disagree in that it won't do anything beneficial.
Generally, it is useful to separate between TLTLDs and TLTLDs (two letter top level domains and three letter top level domains). The two letter domains (country codes) generally do well, even if some of them are underused (.us) and other overused for other purposes (.tm, .tv, .md), and others may be so in the far-out future (.ai and .et; .sf is vacant as Finland use .fi). There are a couple hundred of these, but there is an established standard maintaining them.
The three (and soon four+) letter domains are more ad hoc. Some of these (.gov and also .edu) are US only, others (.com, .net, .org) are used internationally, one (.int) is only used by international organisations. TLDs with clear rules for which entities belong and which don't belong in that domain, and preferably with a predictable subdomain-structure and naming conventions should have an advantage.
There is a .ms top level domain, it it the country code for Montserrat.