Are you mad? Safari's CSS support is second only to Mozilla, as is their Javascript/DOM support. I know this because I've built an in browser, live CSS editor and tested it extensively across most all the various browsers.
I can even name areas where Safari's DOM handling surpasses Mozilla (although I can name more where it doesn't), and a few CSS instances where Safari beats Mozilla too (although again, more where Mozilla wins).
Opera is up there in CSS, but falls down in some DOM areas, and IE isn't in the race at all. To claim that *any* browser is "far more CSS compliant than Safari" is stretching the truth well beyond breaking point, and the only one you can probably honestly claim that does beat it is Mozilla.
Every time we've made the browser more invisible, we've been hit by security nightmares like phishing. I think it makes a lot of sense to clearly mark remote applications as remote and to show their URI and so forth.
Fair point.
We care if it's implementable in IE6 because authors don't seem to want to do anything if it doesn't work in IE6.
I see that as a problem with web sites, not applications (to a degree). I may be being unduely idealistic here, but I feel as though web applications should, and will be held to a different standard, and not be expected to work in every possible browser. As I've said elsewhere, a brochure can't have system requirements, but an application can.
I'm developing an application built on pretty much the same technologies, minus a few of the extra complexities (instead of going for native XML, I've opted for native XHTML, butchered to feel a bit more like XML).
Safari isn't a Gecko variant, it's a KHTML variant. The only browser I've had to drop support for is IE because it's too far behind the curve. For the supported browsers, I've got one single client codebase that functions identically across the board. This is possible with the standards support the actively developed browsers currently have.
Although I do agree with your conclusions. Getting the current round of actively developed browsers to treat the current standards as strictly identical as possible would be the win for me as a developer *right now*.
From there I'd like to see them all settle on a next generation interface description markup/declarative language, and have them all implement that. IE be damned; Microsoft have already made it abundantly clear that they're going to go their own way, so let them them, and forget about trying to group IE in as part of the target platforms.
Why do you even care whether these are implemented or implementable in IE? When it comes to web applications, the browser is irrelevant. The browser should be an all but invisible "web application runtime engine". You're not going to be able to twist IE's arm into becoming that, without having to sacrifice functionality. This all sounds like butchery of potential to me.
What interests me though, other than bickering over direction, is where Apple are going to lay their chips.
Drag and drop already is possible within current browser standards. The event model and display model is there. Of course, you're locked within the single window/frame.
Although, as a web application developer, I'm reasonably disappointed in what WHATWG has to say. You're trying to push web applications into the pigeonhole they're stuck in now, which is in the browser. Let them move outside the browser. Let the standards grow away from "web pages". Backwards compatibility with HTML is a crippling diversion of effort in my opinion.
Forget the market share issues. Forget about backwards compatibility with Internet Explorer. We're talking applications here, not web pages. Applications are held to a different standard than web pages. You can't have system requirements on a brochure, so web pages have to be viewable everywhere. The same is not true for applications. Move on.
I never even brought up XAML in relation to Apple. So after attacking me and saying I didn't have a grasp on Apple, you've now come out and agreed with me that Apple will implement the new standards, then tried to twist it into a "but they will *also* license Avalon later on!".
So what? who cares if they license Avalon? As long as they're supporting the standards, which is the issue which you originally attacked me on, but now agree with.
Having said that, I still say you're living in fairy land, and have no grasp of how these technologies fit together, or what Avalon really is. Apple will likely have very little interest in licensing and implementing Avalon into OS X. It still remains to be seen as to whether they're even going to support any of.NET, and I'm sure their strong bond with Java doesn't bode well on that front.
I'd be hard pressed to imagine Apple making.NET support announcements at the upcoming WWDC, considering the strong Sun and Java presence that is going to be there, what with JavaOne in the next room and all.
I'm happy to stake my personal credibility on the prediction that Apple will behave and MS will license Avalon to them.
If I were a cruel man, I'd note that down and remind you of it in a few years time. Although you may get your chance to feel a fool sooner than that, with Apple's WWDC coming up later this month, and the potential for announcements along these lines at that event.
What rendering engine is Apple's web browser based on? KHTML, from the KDE project. Who is the lead programmer on Apple's web browser project? David Hyatt, previously from the Mozilla project, and someone whose name features prominently on the XUL specification (which is expected to play a large part in this new Web Forms 2 specification).
And even if Apple themselves don't dedicated developers to implement these new standards into KHTML, then you can bet the KDE project will, and thus Apple will inherit that functionality.
Just because Apple and Microsoft have a comfortable working relationship, doesn't mean they walk hand in hand down the same standards path.
Oh, I don't suppose you have any idea what other event is coinciding with Apple's WWDC, at the same location on the same dates? Sun's JavaOne. There's even talk of shared passes. And why is that? Because Apple never dove into.NET, they dove into Java, head first then full body following. OS X has the smoothest Java integration of any operating system on the market.
A site may say, oh, you need a newer browser to view this properly.
As a web developer, can I just note that no company in their right minds would do this while Internet Explorer still controls 95%ish of the surfing public.
We're not talking about web sites here, we're talking about web applications. When you go hunting for an application to do task X, and you find one but there isn't a version for your OS platform, you don't throw up your arms in rage, accusing them of crimes against humanity.
Just because we're talking about advancements in web technologies, doesn't mean we're still talking about websites as we know them now. Hell, we may as well not even be talking about web browsers.
The direction things are going in is towards "web application runtimes", like say a Gecko runtime engine that doesn't double as a web browser, but does run applications over the internet based on next generation web technologies.
If you look at what Microsoft are talking about with XAML and associated technologies, they're not talking about something implemented in a web browser or as a web browser, and largely neither are the Mozilla folks when they talk about XUL.
If Mozilla, Opera, and Apple get in on the act, that will be enough.
This new standard isn't the same as the rest of the web. In most cases it will be targeted and used largely for web applications, not web sites.
If you build a web site you have commercial pressure to ensure that it will be viewable in as many browsers and on as many platforms as possible. You can't have system requirements on a brochure.
If you build an application, people don't by default expect it to function on all platforms and browsers. People develop applications largely for single platforms, so that sort of focus can carry over reasonably smoothly to web applications.
Having said that, if it's implemented by all the above mentioned companies/browsers, then your application will gain immediate cross platform support, with users even having a choice of browser platform within their chosen OS platform.
I'm not talking about the current generation of web applications here, the likes of web mail (Hotmail, GMail, etc). I'm talking about the next generation, where the application looks and feels much closer to what we traditionally consider to be an application. That's where these standards are going. They won't feel like the web we know now, and won't be treated in the same manner.
So Microsoft can go off and do their own thing, and that's fine. As long as the other platforms have their equivalent technology, web application developers won't be left out in the cold if they want to build cross platform applications.
I'm talking about client side rules. ie the rules you find under Preferences -> Rules. These have a specific limitation that they're incapable of moving messages between IMAP folders.
Yes you can do server side rules, and on occasion I do, as I run my own mail server (qmail + courier-imap, using Maildir). But for convenience sake, it's nice to be able to quickly throw together rules on the client side, which is impossible with Mail.app, due to this limitation.
Perhaps I need to create a junk folder on the server myself first...
You do. Select the new folder, then Mailbox (menubar) -> Use this folder for -> Junk. Same process for when you want to store your Sent or Trash on the remote server.
Although I can't actually confirm that this works for the Junk folder. I only keep my Sent folder on the server. But the option is there for the Junk folder, so I assume it must work.
From a self taught coder's perspective, I would have to agree.
I am constantly aware of the limitations of my mathematical knowledge. When I add new functionality to my programs, I work it out in my head or on paper, write that solution into code, then sit back and look at it and realise that there's a better way. The problem is I don't have the training to know how to get to that better way.
There's a lot about programming that you can learn online. But there's also a whole lot more that you can't find online until you even know what it is you're looking for.
It's always in the back of my mind that someday I'd like to go back to school and fill in the gaps. In the meantime, all I can do is make the best of what I know, and try and slowly fill in the gaps via the resources the internet provides.
Of course this is where having knowledgeable friends comes in handy:)
Me: "So I worked out how to make that bit..." Friend: "Wow. Why don't you just do [thing]?" Me: "Uhh, right. Yes. Good thinking."/scurries off to read up on new [thing]/
I've yet to see Poison return better results or download faster than the single network Acquisition. As far as I'm concerned, it's all hype and no substance.
Best in the business my arse. You get what you pay for when you pick out a host with some of the cheapest server prices in the industry. Their customer service record has always been fragile, and you don't have to throw the stone far to find disastisfied customer reports.
Since my time with them I've found several other much more reputable hosts in a similar to slightly more expensive price range. EV1 (formerly Rackshack) are gutter hosting, and I'd strongly advise all to avoid them.
Careful where you wave that moron tag. It's looking suspiciously like a rock in a glasshouse.
What you've described is the basic economics of broadband *everywhere*. There will always be a tiny percentage of hardcore users who consume the bulk of a flatrate offering.
Telecom's strangle hold on the local loop is undisputedly why we're suffering from lack of service here. The affect of severely limited competition means that Telecom is under no pressure to improve their offerings. Physical location and international connectivity also play a part.
Until we see real competition here, we're going to continue seeing sub par offerings. A small percentage of people taking full advantage of flatrate offerings has no bearing on the matter.
"If you adhere to the standards it will work just fine in Mozilla. It might work in IE, but quite probably won't if you're doing any CSS2 or some CSS1. IE plains sucks when it comes to standards support."
That's just plain not true (well, unless you're targetting an IE lower than 5.5). Set your DTD to one of the stricts, use the standards, and you're fine.
There are minimal issues that might arise, and for all of them there are work arounds that won't excessively muddy your markup or force you to drop the use a supported feature.
For a lot of those things to happen, there must have been other indicators on top of the chest pain. But wouldn't you rather the doctors went the extra length to ensure you're not going to topple over once you walk out the door?
In a situation like that, I would be more inclined to point the finger at the lack of government subsidisation than at doctors overstepping the mark. Had I gone through a similar process in my city I might have ended up with something around a $100 bill plus medication costs.
Don't be naive. Cutting spending on space programs won't magically funnel more money into social programs.
Social spending is heavily weighted by the left or right leaning of the ruling party, and has little connection to the size of space exploration budgets.
Anyway, if you're American, then you'd be more likely to see the space program funding being shifted into the military budget.
We've been writing books about it, making movies about it, saying we're going to grow up to do it, dreaming about it for so long now that turning around and saying we're not going to do it is impossible.
Logic doesn't come into it. It's an over powering human desire to explore, discover and just generally do cool shit.
I've been testing a solution like this for the past few months.
1. There's a few useful pages out there, but really all you need to do is get slapd installed and running, then point Outlook's severely broken LDAP functionality at it. Outlook uses standard schemas, so there's no need for any changes or additions there.
2. It will work from both Outlook and Outlook Express. Possibly better from OE, although I haven't spent much time with it.
3. You can't edit address book entries from either Outlook or Outlook Express to my knowledge, without using a third party LDAP plugin. We've ended up developing our own web based LDAP editor, and left only lookups to Outlook itself.
But as I said, Outlook's LDAP functionality is pretty brain dead. If you're going to be having the LDAP database as the users' primary address book, I'd look into third party LDAP plugins for Outlook.
Slashdot Mirror
Are you mad? Safari's CSS support is second only to Mozilla, as is their Javascript/DOM support. I know this because I've built an in browser, live CSS editor and tested it extensively across most all the various browsers.
I can even name areas where Safari's DOM handling surpasses Mozilla (although I can name more where it doesn't), and a few CSS instances where Safari beats Mozilla too (although again, more where Mozilla wins).
Opera is up there in CSS, but falls down in some DOM areas, and IE isn't in the race at all. To claim that *any* browser is "far more CSS compliant than Safari" is stretching the truth well beyond breaking point, and the only one you can probably honestly claim that does beat it is Mozilla.
Fair enough. I guess I'm just looking for the wrong things in WHATWG, or wrongly seeing it as an attempt to solve a problem that it's not.
:)
Again, I apologise if I've come across as antagonistic. Too much coffee, and too much interest in the subject matter
Every time we've made the browser more invisible, we've been hit by security nightmares like phishing. I think it makes a lot of sense to clearly mark remote applications as remote and to show their URI and so forth.
Fair point.
We care if it's implementable in IE6 because authors don't seem to want to do anything if it doesn't work in IE6.
I see that as a problem with web sites, not applications (to a degree). I may be being unduely idealistic here, but I feel as though web applications should, and will be held to a different standard, and not be expected to work in every possible browser. As I've said elsewhere, a brochure can't have system requirements, but an application can.
I'm developing an application built on pretty much the same technologies, minus a few of the extra complexities (instead of going for native XML, I've opted for native XHTML, butchered to feel a bit more like XML).
Safari isn't a Gecko variant, it's a KHTML variant. The only browser I've had to drop support for is IE because it's too far behind the curve. For the supported browsers, I've got one single client codebase that functions identically across the board. This is possible with the standards support the actively developed browsers currently have.
Although I do agree with your conclusions. Getting the current round of actively developed browsers to treat the current standards as strictly identical as possible would be the win for me as a developer *right now*.
From there I'd like to see them all settle on a next generation interface description markup/declarative language, and have them all implement that. IE be damned; Microsoft have already made it abundantly clear that they're going to go their own way, so let them them, and forget about trying to group IE in as part of the target platforms.
Why do you even care whether these are implemented or implementable in IE? When it comes to web applications, the browser is irrelevant. The browser should be an all but invisible "web application runtime engine". You're not going to be able to twist IE's arm into becoming that, without having to sacrifice functionality. This all sounds like butchery of potential to me.
What interests me though, other than bickering over direction, is where Apple are going to lay their chips.
Drag and drop already is possible within current browser standards. The event model and display model is there. Of course, you're locked within the single window/frame.
Although, as a web application developer, I'm reasonably disappointed in what WHATWG has to say. You're trying to push web applications into the pigeonhole they're stuck in now, which is in the browser. Let them move outside the browser. Let the standards grow away from "web pages". Backwards compatibility with HTML is a crippling diversion of effort in my opinion.
Forget the market share issues. Forget about backwards compatibility with Internet Explorer. We're talking applications here, not web pages. Applications are held to a different standard than web pages. You can't have system requirements on a brochure, so web pages have to be viewable everywhere. The same is not true for applications. Move on.
What a load of bullshit.
Backpeddler.
.NET, and I'm sure their strong bond with Java doesn't bode well on that front.
.NET support announcements at the upcoming WWDC, considering the strong Sun and Java presence that is going to be there, what with JavaOne in the next room and all.
I never even brought up XAML in relation to Apple. So after attacking me and saying I didn't have a grasp on Apple, you've now come out and agreed with me that Apple will implement the new standards, then tried to twist it into a "but they will *also* license Avalon later on!".
So what? who cares if they license Avalon? As long as they're supporting the standards, which is the issue which you originally attacked me on, but now agree with.
Having said that, I still say you're living in fairy land, and have no grasp of how these technologies fit together, or what Avalon really is. Apple will likely have very little interest in licensing and implementing Avalon into OS X. It still remains to be seen as to whether they're even going to support any of
I'd be hard pressed to imagine Apple making
That's a fancy fairy tale you've concocted there.
.NET, they dove into Java, head first then full body following. OS X has the smoothest Java integration of any operating system on the market.
.NET and XAML simply aren't on Apple's radar.
I'm happy to stake my personal credibility on the prediction that Apple will behave and MS will license Avalon to them.
If I were a cruel man, I'd note that down and remind you of it in a few years time. Although you may get your chance to feel a fool sooner than that, with Apple's WWDC coming up later this month, and the potential for announcements along these lines at that event.
What rendering engine is Apple's web browser based on? KHTML, from the KDE project. Who is the lead programmer on Apple's web browser project? David Hyatt, previously from the Mozilla project, and someone whose name features prominently on the XUL specification (which is expected to play a large part in this new Web Forms 2 specification).
And even if Apple themselves don't dedicated developers to implement these new standards into KHTML, then you can bet the KDE project will, and thus Apple will inherit that functionality.
Just because Apple and Microsoft have a comfortable working relationship, doesn't mean they walk hand in hand down the same standards path.
Oh, I don't suppose you have any idea what other event is coinciding with Apple's WWDC, at the same location on the same dates? Sun's JavaOne. There's even talk of shared passes. And why is that? Because Apple never dove into
-
Do your homework.
We're not talking about web sites here, we're talking about web applications. When you go hunting for an application to do task X, and you find one but there isn't a version for your OS platform, you don't throw up your arms in rage, accusing them of crimes against humanity.
Just because we're talking about advancements in web technologies, doesn't mean we're still talking about websites as we know them now. Hell, we may as well not even be talking about web browsers.
The direction things are going in is towards "web application runtimes", like say a Gecko runtime engine that doesn't double as a web browser, but does run applications over the internet based on next generation web technologies.
If you look at what Microsoft are talking about with XAML and associated technologies, they're not talking about something implemented in a web browser or as a web browser, and largely neither are the Mozilla folks when they talk about XUL.
If Mozilla, Opera, and Apple get in on the act, that will be enough.
This new standard isn't the same as the rest of the web. In most cases it will be targeted and used largely for web applications, not web sites.
If you build a web site you have commercial pressure to ensure that it will be viewable in as many browsers and on as many platforms as possible. You can't have system requirements on a brochure.
If you build an application, people don't by default expect it to function on all platforms and browsers. People develop applications largely for single platforms, so that sort of focus can carry over reasonably smoothly to web applications.
Having said that, if it's implemented by all the above mentioned companies/browsers, then your application will gain immediate cross platform support, with users even having a choice of browser platform within their chosen OS platform.
I'm not talking about the current generation of web applications here, the likes of web mail (Hotmail, GMail, etc). I'm talking about the next generation, where the application looks and feels much closer to what we traditionally consider to be an application. That's where these standards are going. They won't feel like the web we know now, and won't be treated in the same manner.
So Microsoft can go off and do their own thing, and that's fine. As long as the other platforms have their equivalent technology, web application developers won't be left out in the cold if they want to build cross platform applications.
I'm talking about client side rules. ie the rules you find under Preferences -> Rules. These have a specific limitation that they're incapable of moving messages between IMAP folders.
Yes you can do server side rules, and on occasion I do, as I run my own mail server (qmail + courier-imap, using Maildir). But for convenience sake, it's nice to be able to quickly throw together rules on the client side, which is impossible with Mail.app, due to this limitation.
Perhaps I need to create a junk folder on the server myself first...
You do. Select the new folder, then Mailbox (menubar) -> Use this folder for -> Junk. Same process for when you want to store your Sent or Trash on the remote server.
Although I can't actually confirm that this works for the Junk folder. I only keep my Sent folder on the server. But the option is there for the Junk folder, so I assume it must work.
doesn't ... have the ability to move my mail to a Junk folder on my IMAP server.
Yes it does:
Preferences -> Accounts -> Special Mailboxes -> Store junk messages on the server.
My personal IMAP complaint is that you can't create rules to move messages between folders on the server, only folders on the client.
what type of answer could satisfy such a short "code" better?
One that matched the letters?
From a self taught coder's perspective, I would have to agree.
:)
..." /scurries off to read up on new [thing]/
I am constantly aware of the limitations of my mathematical knowledge. When I add new functionality to my programs, I work it out in my head or on paper, write that solution into code, then sit back and look at it and realise that there's a better way. The problem is I don't have the training to know how to get to that better way.
There's a lot about programming that you can learn online. But there's also a whole lot more that you can't find online until you even know what it is you're looking for.
It's always in the back of my mind that someday I'd like to go back to school and fill in the gaps. In the meantime, all I can do is make the best of what I know, and try and slowly fill in the gaps via the resources the internet provides.
Of course this is where having knowledgeable friends comes in handy
Me: "So I worked out how to make that bit
Friend: "Wow. Why don't you just do [thing]?"
Me: "Uhh, right. Yes. Good thinking."
I'd go one further and ask for sftp read/write in Finder.
I've yet to see Poison return better results or download faster than the single network Acquisition. As far as I'm concerned, it's all hype and no substance.
Best in the business my arse. You get what you pay for when you pick out a host with some of the cheapest server prices in the industry. Their customer service record has always been fragile, and you don't have to throw the stone far to find disastisfied customer reports.
Since my time with them I've found several other much more reputable hosts in a similar to slightly more expensive price range. EV1 (formerly Rackshack) are gutter hosting, and I'd strongly advise all to avoid them.
Careful where you wave that moron tag. It's looking suspiciously like a rock in a glasshouse.
What you've described is the basic economics of broadband *everywhere*. There will always be a tiny percentage of hardcore users who consume the bulk of a flatrate offering.
Telecom's strangle hold on the local loop is undisputedly why we're suffering from lack of service here. The affect of severely limited competition means that Telecom is under no pressure to improve their offerings. Physical location and international connectivity also play a part.
Until we see real competition here, we're going to continue seeing sub par offerings. A small percentage of people taking full advantage of flatrate offerings has no bearing on the matter.
"If you adhere to the standards it will work just fine in Mozilla. It might work in IE, but quite probably won't if you're doing any CSS2 or some CSS1. IE plains sucks when it comes to standards support."
That's just plain not true (well, unless you're targetting an IE lower than 5.5). Set your DTD to one of the stricts, use the standards, and you're fine.
There are minimal issues that might arise, and for all of them there are work arounds that won't excessively muddy your markup or force you to drop the use a supported feature.
For a lot of those things to happen, there must have been other indicators on top of the chest pain. But wouldn't you rather the doctors went the extra length to ensure you're not going to topple over once you walk out the door?
In a situation like that, I would be more inclined to point the finger at the lack of government subsidisation than at doctors overstepping the mark. Had I gone through a similar process in my city I might have ended up with something around a $100 bill plus medication costs.
Don't be naive. Cutting spending on space programs won't magically funnel more money into social programs.
Social spending is heavily weighted by the left or right leaning of the ruling party, and has little connection to the size of space exploration budgets.
Anyway, if you're American, then you'd be more likely to see the space program funding being shifted into the military budget.
We need man in space because it's cool.
We've been writing books about it, making movies about it, saying we're going to grow up to do it, dreaming about it for so long now that turning around and saying we're not going to do it is impossible.
Logic doesn't come into it. It's an over powering human desire to explore, discover and just generally do cool shit.
That's my take anyway.
I've been testing a solution like this for the past few months.
1. There's a few useful pages out there, but really all you need to do is get slapd installed and running, then point Outlook's severely broken LDAP functionality at it. Outlook uses standard schemas, so there's no need for any changes or additions there.
2. It will work from both Outlook and Outlook Express. Possibly better from OE, although I haven't spent much time with it.
3. You can't edit address book entries from either Outlook or Outlook Express to my knowledge, without using a third party LDAP plugin. We've ended up developing our own web based LDAP editor, and left only lookups to Outlook itself.
But as I said, Outlook's LDAP functionality is pretty brain dead. If you're going to be having the LDAP database as the users' primary address book, I'd look into third party LDAP plugins for Outlook.