Thread

As for a mobile-specific theme, the initial release will not likely have one, but I’m fairly confident that one will be available in a short time, presuming there’s a demand.

And what about the front-end? Are you planning specific support (or is it available through CI)? Browser detection and negotiation?

And what about the front-end? Are you planning specific support (or is it available through CI)? Browser detection and negotiation?

There’s nothing to prevent you from doing this in 1.x, but CI does have a User Agent class that can assist you if you do not already have a preferred method established.

There’s nothing to prevent you from doing this in 1.x, but CI does have a User Agent class that can assist you if you do not already have a preferred method established.

Nothing prevents it in 1.x but there is no support for it either, or is there?

Nothing prevents it in 1.x but there is no support for it either, or is there?

I don’t understand the question.  Mobile browser support is based entirely on your markup and styling.

I don’t understand the question.  Mobile browser support is based entirely on your markup and styling.

I guess it depends on how you choose to implement it. I like to implement it over content negociation such that the same URL serves mobile content to mobile users and regular content to other users.

Again there are different solutions to implement content negociation but the one I find most efficient is to supply several templates for a ressource and have a controler choose the most appropriate template for a browser.

So the question becomes where you place that control. You can repeat all the tests in every template and do many embeds, you can also use Apache content negociation and URL rewriting. Or you can have a framework that takes care of the repeatitive coding. Each solution has different benefits/challenges so, to answer your question, at one point the markup and styling is important but the framework can assist by taking hold of the very repeative code needed for content negociation. And I guess the question is whether CI has this ability.

EE has this ability now, but you still have to implement it how you see fit, as there are literally an infinite number of ways to approach it, even after deciding that content negotiation is the method you wish to use.  EE “supports” it in the same sense that it supports any HTML, CSS, and server-side extensibility for any other task.  This is really a derailment of this thread, though, so if you wish to discuss possible ways to handle content negotiation in an unintrusive way, i.e. without tons of code in each template, then please start a thread in the General forums, or if you’re interested in how it can be done in CI, in the development forums at CodeIgniter.com.

EE has this ability now, but you still have to implement it how you see fit, as there are literally an infinite number of ways to approach it

I did not realize there was support for content negotiation in EE today.

Sorry, I did not intend to derail the thread, the question just flowed in the discussion. I don’t need it now but it’s something we are considering for the future, so if a decision is made, I’ll do as you suggest and post a request in the appropriate forum.

Cutting out IE 6 is exactly the forward-thinking I love to see in web design.

I just wish ElisLabs had the same view of PHP 5 only support for EE and (especialy) CodeIgniter.

Cutting out IE 6 is exactly the forward-thinking I love to see in web design.

I just wish ElisLabs had the same view of PHP 5 only support for EE and (especialy) CodeIgniter.

Points to page 2 :-D

As Derek just pointed out, CI and by extension, EE 2.0 support PHP 5 just fine. It’s up to the developer to choose.

I would gather that the EllisLab team does MORE work to ensure full support for 4 and 5, and all the “fiveinistas” just need to accept that EL is not going to abandon 80% of the PHP market.

If you want 5 in CI, it’s there.

Can we please move on now?

I’ll just throw in one good word for IE6 here: If I hadn’t gotten tired of waiting years and years and years and years and years and years for a new version of IE, I don’t think I would have ever switched to Firefox.

As Derek just pointed out, CI and by extension, EE 2.0 support PHP 5 just fine. It’s up to the developer to choose.

I would gather that the EllisLab team does MORE work to ensure full support for 4 and 5, and all the “fiveinistas” just need to accept that EL is not going to abandon 80% of the PHP market.

If you want 5 in CI, it’s there.

Can we please move on now?

I don’t care if CI supports php 4, but I do care that CI doesn’t use some php 5 features. It does matter that CI uses a loader class when it could use php 5 autoloading. It does matter that the loader class returns singleton classes whether we like it or not.

I also don’t accept that 80% number. You can’t include zombie legacy php 4 applications running on obsolete code bases in that number. Poll EE and CI users and I think that number would not be far lower.

Also, I don’t understand people congratulating Ellislab on their decision to drop IE 6 support. It’s the right call for Ellislab, but not for EE customers and 10% of our clients.

Rick, I appreciate your thoughts, really I do, and would love to code PHP5 only.  But please trust that we have experience with who our users are and the technology that’s available to them.  We’ve polled EE users before, and we also have daily experience in providing them with support.  We still regularly support users running PHP 4.1 and MySQL 3.23.  You can choose to believe that PHP 5 support is more ubiquitous than reported, and perhaps it is, but it’s still significantly weak.  GoPHP5’s initiative chose 5.2 as the bar for a reason, and RHEL5, easily the most common server distro in the hosting market, does not support PHP 5.2 and never will.  That’s a lot of people we’d be abandoning.

Even dropping support for severely out of date versions has to be made judiciously.  And that’s exactly what we did here.  Our customers, this community, and your clients are not severely impacted by this decision so it was a no brainer for us.  Again, 1.x’s control panel works perfectly with IE6, and will be sold and supported for a long time.  2.x’s control panel markup is not locked away intermixed with programming logic, so if you need IE6 control panel support on a 2.x powered site, you are free to do so.

I just had a thought concerning IE6 support, funny to me anyways…
The word Kludge was practically invented or made famous at least by being placed in CSS comment code to explain why IE6 hacks were necessary.
So removing the kludg-i-ness could only be a good and progressive thing.
IE8 was out of beta on March 19th.
Progressive aggressive enhancement is the way to go.
http://browsehappy.com I noticed savethedeveloper.org currently unavailable.