He wasn't knighted, but he got the OBE award in 1945, which is one step below a knighthood. http://en.wikipedia.org/wiki/Alan_Turing#Hut_8_and_Naval_Enigma Now, he obviously should have been knighted for his work and given time he probably would have been. Regrettably he wasn't given that time.
Re:Sounds like a few people are confused...
on
XHTML 2 Cancelled
·
· Score: 1
Making *valid code* makes for a more predictable browsing experience and also lowers memory requirement, whether you use HTML or XML. At the time I worked for a browser company using XML actually made matters worse, and I would be surprised if that isn't still the case. It should be easy to make a test in every browser, my expected result is that a document serialised with XML (served with application/xhtml+xml) will need more processing power and take notably longer to render than one served as text/html. If you want to slow down your web page, serve it as XHTML.
Yes, all of these had typographic conventions long before the formalisation of HTML. But does this mean that they don't have semantic meaning? You should ask yourself why these conventions are there. There is a deep difference between an ordered and an unordered list, whether there are many processes to take advantage of this difference is a different question.
The case for 'i' is interesting. I have always been a strong proponent for the 'i' element, in part because it describes something ("alternate voice or mood" is a fair stab of what that something is), and in part because it would be a disaster for semantic markup if it had been removed. If you want to mark up something that in traditional typography is marked up with italics that has a specific semantic meaning like 'em', use 'em'. Otherwise use 'i'.
If 'i' was removed from the spec, the nearest semantic element would be used instead. Thus you get 'em' used to mark up text that clearly isn't meant to be emphasised. A far greater problem for semantic markup than not using the semantic element when you can (e.g. not using 'em' for emphasised text) is to inappropriately use that element (e.g. using 'em' for something not meant to be emphasised text).
Italic is sometimes used for text decoration, e.g. for some aesthetic reason every other paragraph is italicised. In this case italic has no semantic value, and a style sheet should be used instead (with CSS3 Selectors this could be done without polluting the markup at all).
Finally there is a great value in imprecision, but that is a story for later.
True; Strict is stricter than Transitional
on
XHTML 2 Cancelled
·
· Score: 1
You are confusing serialisation with strictness or restrictiveness. The vocabulary of the three versions of HTML4 and of XHTML1 are virtually identical (there are actually a few minor differences between HTML4 and XHTML1 for technical reasons). HTML4 Strict/XHTML1 Strict are stricter than HTML4 Transitional/XHTML1 Transitional. A valid document in HTML4 Strict (or XHTML1 Strict) will be valid in HTML4 Transitional (or XHTML1 Strict), but the reverse need not be the case. The serialisations follow different rules, which has consequence in how the elements are represented. This is the same with HTML5, which also has two serialisations, one using a clearly defined HTML syntax (instead of a conceptual SGML syntax), and the other using an XML syntax (called XHTML5).
The ownership structure of Symbian is different now. It is half-owned by Nokia, with Ericsson and Sony-Ericsson being next in line.
Microsoft is not less of a threat in this segment, smartphones, i.e. phones with an open operating system, than it has been. It is solidly in the second position. Linux-based phones are slowly growing as well, having a greater market share on phones than on PCs (but far lower than on servers). iPhone is a marginal player, but that may change in time. All of it depends on what is meant by smartphone of course, and the vast majority of phones still use closed proprietary systems, smartphones is still a niche market. There are also different markets. The phone market in America is very different from the one in Europe which is very different from the one in East Asia. The developing world has some surprises in store as well.
I would give the Anonymous Symbian some credit, making a good phone is different from making a good embedded device, and it takes time to get this right. The selling point of the iPhone is not that it is a great phone, but that other aspects of it is great. Windows Mobile used to be horrible, but it has improved in time. This initiative might not make the killer phone on first attempt either, but chances are that there might be a second one.
All in all there seems to be more competition coming in as this phone niche is becoming more mainstream, which should be good for all of us.
That discussion doesn't really belong here, but in a web design thread. But apart from cheating (treating the test page specifically), which would be easy to spot, taking time to make Acid2 work means taking time to make the CSS implementation work, there is no "quick fix" to Acid2.
Acid2 doesn't cover everything, far from it, but a poor CSS implementation won't pass Acid2 so if an implementation passes Acid2 it must be a good one. Additional tests will be needed to see if it is a great one. It will be much easier to design pages that work for browsers that pass Acid2 than it will for browsers that don't. Not passing comes in degrees of course, Firefox does better than IE that does better than Netscape 4.
This has some relevance to Geir. Before there was an Acid2 test there was an CSS Acid test, created by Todd Fahrner. When it was written and a long time after none of the browsers came close to pass this test, Geir's CSS implementation did. There is no talk about it today because every modern browser, IE included, pass it today. Hopefully the day will come soon when nobody is going to talk about Acid2 either.
In a way he was. He never was much for self-aggrandizement, so outside Opera and a select few other circles people didn't know who he was as a programmer or as a person. But his work had an impact beyond Opera. We do need the people who talk, but we also need the people who do.
One of the extra services that comes with a Thinkpad. If Windows fails to boot up, you still get the rescue system. This can be considered an embedded environment, something Opera excels at. Opera is not used as a traditional web browser here, but as a tool to help the user get the Thinkpad running again.
The often high cost is a problem, probably the biggest one for the mobile web right now. But this is changing, operators realize that they will make more money by lowering their prices (so that people will actually use their services) than by keeping them at the current rate. If they don't, their competitors will.
Here in the Czech Republic I can get unlimited GPRS for about £20/month, which I find quite acceptable considering a few years back I would have to pay about the same amount for a couple MB of data, and I know that in the future it will be cheaper or better bandwidth for the same price.
Our smallest client is smaller than that, at 55KB (though the full-featured Opera Mini client is just below 100KB).
The reason why we need them so small is that size matters when on phones and embedded devices, and as phones get more powerful there are other devices coming in on the low end. As these devices not only come with little memory but also usually very slow processors (to save both money and battery), speed matters too. Thus we optimise for speed and memory, and we optimise pretty hard.
A major development is the addition of XSLT support using a native XSLTProcessor object just like Mozilla. This is significant because Opera has been strongly opposing XSLT for a long time now. Web developers using XSLT for the presentation layer would find this news heartening.
That isn't quite true. We have been sceptical to XSL-FO, and we still are, but have been neutral/pragmatic on XSLT. Server-side Opera.com has been using XSLT for years and I think there should be different best practices client-side and server-side and I don't think the usecase for client-side XSLT is reducing server load, but when it is used for the benefit of the user it can be a good idea.
Ok, so that was kind of trollish, but honestly... I can't stand Opera's cookie management.
I agree. This is one part of Opera that I have thought was needlessly cumbersome. This is improving though, as can be seen with this Technical Preview.
The equivalent technology is called User JavaScript with Opera. Greasemonkey scripts can be run in Opera, a tutorial has more detail. You can also run User JavaScript, which you could find for instance on the userjs.org site.
I've never understood web standards. If most browswers don't follow them, (as aparent that IE, Firefox, and Opera each failed to render the acid2 face test properly) then whose standards are they? Wouldn't the 'standards' be the most popular useage of code?
The point of an acid test is that is should be hard, something to strive for. The idea is that if you have passed this test you likely have a good implementation of CSS. It is possible to fail the acid test and be good in other aspects of the standard, or pass it and still be deficient, but it should give a good indicator. It is worth noting that every modern browser passes the first acid test, but it was considered a challenge at the day. IE didn't pass it before version 6.
The focus of the CSS Working Group in the W3C has the last five years changed focus from more features (CSS3) to more universally consistent presentation (CSS2.1). I believe this is a good move, and the Acid2 test should be viewed in that light. Opera intends to support CSS 2.1 and I presume that is the case with Firefox and Konqueror too, and we all change our implementations in tune with how CSS2.1 develops. IE is definitely far behind, but should be commended for moving in the right direction.
At some point Opera, FF, and Konqueror/Safari should render CSS2.1 more similar to each other than they would do to their own older versions, and hopefully not differ in any meaningful way. Whether IE one day is going to turn this gang of three into a gang of four remains to be seen, it won't happen with IE7, but hopefully the development won't stop there.
The operator support that is needed for Opera Mini and other web applications is an Internet (not WAP) access point. This is effectively the name of the Internet server the phone must connect to. Getting this configuration can be easy or hard depending on the operator and the age of the phone. If you don't have it built-in many operators can just send a SMS message to your phone to install it. If you get no useful help from the operator this incomplete list of known access points in the world might help. You also need a plan that allows for Internet data.
Latency is definitely one of the constraining factors for mobile devices, but it isn't the predominant one. Bandwidth and slow processors (fast processors are not only expensive they consume batteries, and long battery life is essential for a phone) are more likely to slow down mobile web browsing. Even so it is a good idea to consider latency, e.g. avoid having one style sheet calling another one as that would mean three sequential roundtrips to be able to style the page.
AJAX-like techniques can both alleviate and aggravate the problem. You don't want to expose the user to server roundtrips in response to user interaction.
The best payoff is in small, efficient code. Getting rid of those deeply nested tables and other superfluous markup reduces page size (and thus bandwidth and processing) but also creates more responsive pages on normal PCs as well as on mobile devices. And as memory is the greatest constraint for the vast majority of phones less code means less memory use, with dramatic better useability as a result.
You evidently haven't used Pocket IE, where "a little strange" would be the least of your problems. Pocket IE is even more technologically behind than IE for Windows is. Opera isn't just more advanced, it is far better at adapting the web page to the phone.
Opera has supported XML since version 4 (2000), and XML namespaces since version 5.11 (2001) though there are a couple missing namespace related features like CSS3 selection of namespaced attributes that are forthcoming. SVG is moving from extended SVGT profile in Opera 8 to SVGB in Opera 9. Personally I think SVG Fast is more interesting than SVG Full but we'll see what happens in the future. MathML isn't currently on the roadmap. We have supported XML Events since Opera 8, XML ID is coming with Opera 9. XLink simple links is supported, but I think that is a much inferiour solution to CSS linking. XPath is coming up in Opera 9, as is XSLT but we have absolutely no desire to support XSL-FO.
But we don't encourage browser sniffing, object detection is a much better method to give the right content to browsers. Instead of "If your name is John cut my hair" do "If you're a hairdresser cut my hair".
If you do browser detection check for version number and be prepared that browser sniffing is a high maintenance technique. Browsers constantly change and every browser sniffing script will become obsolete, doing more harm than good in the long run.
We lost screen reader integration capabilities in Opera 7 (fully at 7.1) with the change of rendering engine. We are working on getting it back but it won't happen for Opera 9.0. If you have suggestions or proposals for where we could do better please drop by our accessibility forum.
Opera never used Cydoor or anyone else's software for the ad banner, and wasn't spyware with version 5 either. We spent a lot of effort to make sure of that. The entire architecture was our own. Cydoor was just an ad provider.
Opera uses single-key browsing, so that you can get where you want using a single key instead of a key combination. Not only is that easier and more accessible, it is faster. Apart from the other shortcuts mentioned here are a couple more:
Z/X: Back/forth in history 1/2: Next/previous window Space: Not only does it go down a screenful, at the end of a page it goes to the next page (as in Fast Forward)
"I can't download 8 (servers are too slow) but I can tell you that not using the features you don't like is easier said than done."
With Opera 8 you won't even see the features you don't use. This really was the case with Opera 7 too, but the system that allowed for the extreme customisations you can do was brand new and you had to be a power-user to make things as simple for you as you would want to. With Opera 8 it works out of the box.
Both the extensions system that FF uses and the integrated system the Opera uses have their advantages. The former allows for new functionality fast, the latter for better consistency/testing. Both systems can grow with your needs. You don't have to be confronted with everything Opera can do any more than you have to with Firefox.
Re:Would be nice to get XSLT support
on
Opera 8 Released
·
· Score: 1
"Good point about mobile devices, however you could still do the transformation on the client for browsers and on the server for mobile devices and save processing power."
Do you? This is the argument for client-side XSLT I don't like, "If the XSLT transformation sheet is too inefficient to run on the server, well then shift it to the client." The upshot of this is just to make browsing slower.
Server-side XSLT solutions benefit from many clients asking for essentially the same document that can be cached so the response which can be very fast. For the browser each request will be new and unique and it will have to do the processing every time. Furthermore XSLT is not optimised for incremental rendering (you show what you've got while you work on the rest), which is what fast browsers do. Server-side XSLT may be resource intensive but need not be noticeable to the user, client-side XSLT will always have a performance hit.
Slashdot Mirror
He wasn't knighted, but he got the OBE award in 1945, which is one step below a knighthood. http://en.wikipedia.org/wiki/Alan_Turing#Hut_8_and_Naval_Enigma Now, he obviously should have been knighted for his work and given time he probably would have been. Regrettably he wasn't given that time.
Making *valid code* makes for a more predictable browsing experience and also lowers memory requirement, whether you use HTML or XML. At the time I worked for a browser company using XML actually made matters worse, and I would be surprised if that isn't still the case. It should be easy to make a test in every browser, my expected result is that a document serialised with XML (served with application/xhtml+xml) will need more processing power and take notably longer to render than one served as text/html. If you want to slow down your web page, serve it as XHTML.
Yes, all of these had typographic conventions long before the formalisation of HTML. But does this mean that they don't have semantic meaning? You should ask yourself why these conventions are there. There is a deep difference between an ordered and an unordered list, whether there are many processes to take advantage of this difference is a different question.
The case for 'i' is interesting. I have always been a strong proponent for the 'i' element, in part because it describes something ("alternate voice or mood" is a fair stab of what that something is), and in part because it would be a disaster for semantic markup if it had been removed. If you want to mark up something that in traditional typography is marked up with italics that has a specific semantic meaning like 'em', use 'em'. Otherwise use 'i'.
If 'i' was removed from the spec, the nearest semantic element would be used instead. Thus you get 'em' used to mark up text that clearly isn't meant to be emphasised. A far greater problem for semantic markup than not using the semantic element when you can (e.g. not using 'em' for emphasised text) is to inappropriately use that element (e.g. using 'em' for something not meant to be emphasised text).
Italic is sometimes used for text decoration, e.g. for some aesthetic reason every other paragraph is italicised. In this case italic has no semantic value, and a style sheet should be used instead (with CSS3 Selectors this could be done without polluting the markup at all).
Finally there is a great value in imprecision, but that is a story for later.
You are confusing serialisation with strictness or restrictiveness. The vocabulary of the three versions of HTML4 and of XHTML1 are virtually identical (there are actually a few minor differences between HTML4 and XHTML1 for technical reasons). HTML4 Strict/XHTML1 Strict are stricter than HTML4 Transitional/XHTML1 Transitional. A valid document in HTML4 Strict (or XHTML1 Strict) will be valid in HTML4 Transitional (or XHTML1 Strict), but the reverse need not be the case. The serialisations follow different rules, which has consequence in how the elements are represented. This is the same with HTML5, which also has two serialisations, one using a clearly defined HTML syntax (instead of a conceptual SGML syntax), and the other using an XML syntax (called XHTML5).
Yes, that is why strong is wrong .
The ownership structure of Symbian is different now. It is half-owned by Nokia, with Ericsson and Sony-Ericsson being next in line.
Microsoft is not less of a threat in this segment, smartphones, i.e. phones with an open operating system, than it has been. It is solidly in the second position. Linux-based phones are slowly growing as well, having a greater market share on phones than on PCs (but far lower than on servers). iPhone is a marginal player, but that may change in time. All of it depends on what is meant by smartphone of course, and the vast majority of phones still use closed proprietary systems, smartphones is still a niche market. There are also different markets. The phone market in America is very different from the one in Europe which is very different from the one in East Asia. The developing world has some surprises in store as well.
I would give the Anonymous Symbian some credit, making a good phone is different from making a good embedded device, and it takes time to get this right. The selling point of the iPhone is not that it is a great phone, but that other aspects of it is great. Windows Mobile used to be horrible, but it has improved in time. This initiative might not make the killer phone on first attempt either, but chances are that there might be a second one.
All in all there seems to be more competition coming in as this phone niche is becoming more mainstream, which should be good for all of us.
That discussion doesn't really belong here, but in a web design thread. But apart from cheating (treating the test page specifically), which would be easy to spot, taking time to make Acid2 work means taking time to make the CSS implementation work, there is no "quick fix" to Acid2.
Acid2 doesn't cover everything, far from it, but a poor CSS implementation won't pass Acid2 so if an implementation passes Acid2 it must be a good one. Additional tests will be needed to see if it is a great one. It will be much easier to design pages that work for browsers that pass Acid2 than it will for browsers that don't. Not passing comes in degrees of course, Firefox does better than IE that does better than Netscape 4.
This has some relevance to Geir. Before there was an Acid2 test there was an CSS Acid test, created by Todd Fahrner. When it was written and a long time after none of the browsers came close to pass this test, Geir's CSS implementation did. There is no talk about it today because every modern browser, IE included, pass it today. Hopefully the day will come soon when nobody is going to talk about Acid2 either.
In a way he was. He never was much for self-aggrandizement, so outside Opera and a select few other circles people didn't know who he was as a programmer or as a person. But his work had an impact beyond Opera. We do need the people who talk, but we also need the people who do.
One of the extra services that comes with a Thinkpad. If Windows fails to boot up, you still get the rescue system. This can be considered an embedded environment, something Opera excels at. Opera is not used as a traditional web browser here, but as a tool to help the user get the Thinkpad running again.
The often high cost is a problem, probably the biggest one for the mobile web right now. But this is changing, operators realize that they will make more money by lowering their prices (so that people will actually use their services) than by keeping them at the current rate. If they don't, their competitors will.
Here in the Czech Republic I can get unlimited GPRS for about £20/month, which I find quite acceptable considering a few years back I would have to pay about the same amount for a couple MB of data, and I know that in the future it will be cheaper or better bandwidth for the same price.
The reason why we need them so small is that size matters when on phones and embedded devices, and as phones get more powerful there are other devices coming in on the low end. As these devices not only come with little memory but also usually very slow processors (to save both money and battery), speed matters too. Thus we optimise for speed and memory, and we optimise pretty hard.
That isn't quite true. We have been sceptical to XSL-FO, and we still are, but have been neutral/pragmatic on XSLT. Server-side Opera.com has been using XSLT for years and I think there should be different best practices client-side and server-side and I don't think the usecase for client-side XSLT is reducing server load, but when it is used for the benefit of the user it can be a good idea.
The equivalent technology is called User JavaScript with Opera. Greasemonkey scripts can be run in Opera, a tutorial has more detail. You can also run User JavaScript, which you could find for instance on the userjs.org site.
The point of an acid test is that is should be hard, something to strive for. The idea is that if you have passed this test you likely have a good implementation of CSS. It is possible to fail the acid test and be good in other aspects of the standard, or pass it and still be deficient, but it should give a good indicator. It is worth noting that every modern browser passes the first acid test, but it was considered a challenge at the day. IE didn't pass it before version 6.
The focus of the CSS Working Group in the W3C has the last five years changed focus from more features (CSS3) to more universally consistent presentation (CSS2.1). I believe this is a good move, and the Acid2 test should be viewed in that light. Opera intends to support CSS 2.1 and I presume that is the case with Firefox and Konqueror too, and we all change our implementations in tune with how CSS2.1 develops. IE is definitely far behind, but should be commended for moving in the right direction.
At some point Opera, FF, and Konqueror/Safari should render CSS2.1 more similar to each other than they would do to their own older versions, and hopefully not differ in any meaningful way. Whether IE one day is going to turn this gang of three into a gang of four remains to be seen, it won't happen with IE7, but hopefully the development won't stop there.
Jonny Axelsson, Opera Software
The operator support that is needed for Opera Mini and other web applications is an Internet (not WAP) access point. This is effectively the name of the Internet server the phone must connect to. Getting this configuration can be easy or hard depending on the operator and the age of the phone. If you don't have it built-in many operators can just send a SMS message to your phone to install it. If you get no useful help from the operator this incomplete list of known access points in the world might help. You also need a plan that allows for Internet data.
Latency is definitely one of the constraining factors for mobile devices, but it isn't the predominant one. Bandwidth and slow processors (fast processors are not only expensive they consume batteries, and long battery life is essential for a phone) are more likely to slow down mobile web browsing. Even so it is a good idea to consider latency, e.g. avoid having one style sheet calling another one as that would mean three sequential roundtrips to be able to style the page.
AJAX-like techniques can both alleviate and aggravate the problem. You don't want to expose the user to server roundtrips in response to user interaction.
The best payoff is in small, efficient code. Getting rid of those deeply nested tables and other superfluous markup reduces page size (and thus bandwidth and processing) but also creates more responsive pages on normal PCs as well as on mobile devices. And as memory is the greatest constraint for the vast majority of phones less code means less memory use, with dramatic better useability as a result.
You evidently haven't used Pocket IE, where "a little strange" would be the least of your problems. Pocket IE is even more technologically behind than IE for Windows is. Opera isn't just more advanced, it is far better at adapting the web page to the phone.
Opera has supported XML since version 4 (2000), and XML namespaces since version 5.11 (2001) though there are a couple missing namespace related features like CSS3 selection of namespaced attributes that are forthcoming. SVG is moving from extended SVGT profile in Opera 8 to SVGB in Opera 9. Personally I think SVG Fast is more interesting than SVG Full but we'll see what happens in the future. MathML isn't currently on the roadmap. We have supported XML Events since Opera 8, XML ID is coming with Opera 9. XLink simple links is supported, but I think that is a much inferiour solution to CSS linking. XPath is coming up in Opera 9, as is XSLT but we have absolutely no desire to support XSL-FO.
This article on Opera's UA string should give the information you need.
But we don't encourage browser sniffing, object detection is a much better method to give the right content to browsers. Instead of "If your name is John cut my hair" do "If you're a hairdresser cut my hair".
If you do browser detection check for version number and be prepared that browser sniffing is a high maintenance technique. Browsers constantly change and every browser sniffing script will become obsolete, doing more harm than good in the long run.
We lost screen reader integration capabilities in Opera 7 (fully at 7.1) with the change of rendering engine. We are working on getting it back but it won't happen for Opera 9.0. If you have suggestions or proposals for where we could do better please drop by our accessibility forum.
Opera never used Cydoor or anyone else's software for the ad banner, and wasn't spyware with version 5 either. We spent a lot of effort to make sure of that. The entire architecture was our own. Cydoor was just an ad provider.
Jonny Axelsson, Opera Software
Opera uses single-key browsing, so that you can get where you want using a single key instead of a key combination. Not only is that easier and more accessible, it is faster. Apart from the other shortcuts mentioned here are a couple more:
Z/X: Back/forth in history
1/2: Next/previous window
Space: Not only does it go down a screenful, at the end of a page it goes to the next page (as in Fast Forward)
"I can't download 8 (servers are too slow) but I can tell you that not using the features you don't like is easier said than done."
With Opera 8 you won't even see the features you don't use. This really was the case with Opera 7 too, but the system that allowed for the extreme customisations you can do was brand new and you had to be a power-user to make things as simple for you as you would want to. With Opera 8 it works out of the box.
Both the extensions system that FF uses and the integrated system the Opera uses have their advantages. The former allows for new functionality fast, the latter for better consistency/testing. Both systems can grow with your needs. You don't have to be confronted with everything Opera can do any more than you have to with Firefox.
"Good point about mobile devices, however you could still do the transformation on the client for browsers and on the server for mobile devices and save processing power."
Do you? This is the argument for client-side XSLT I don't like, "If the XSLT transformation sheet is too inefficient to run on the server, well then shift it to the client." The upshot of this is just to make browsing slower.
Server-side XSLT solutions benefit from many clients asking for essentially the same document that can be cached so the response which can be very fast. For the browser each request will be new and unique and it will have to do the processing every time. Furthermore XSLT is not optimised for incremental rendering (you show what you've got while you work on the rest), which is what fast browsers do. Server-side XSLT may be resource intensive but need not be noticeable to the user, client-side XSLT will always have a performance hit.