Должны ли веб-приложения соответствовать веб-стандартам?

Похоже, что другие люди, которые ответили до сих пор, понятия не имеют, о чем вы говорите.

Как и я, вам приходилось ломать голову над тем, чтобы ваши веб-приложения были максимально доступными. То есть они должны работать без скриптов и таблиц стилей. JavaScript и CSS следует использовать только для улучшения опыта. Они не должны требоваться.

SproutCore и Cappuccino - это фреймворки для интерфейсной разработки, которые требуют, чтобы у пользователя были включены как JavaScript, так и CSS. Ваш вопрос заключается в том, как нам согласовать это с догматами дня.

К сожалению, однозначного ответа у меня нет. Мне нравится, что SproutCore и Cappuccino (и, возможно, другие) проверяют пределы возможностей веб-браузера. Я также твердо уверен, что информация и услуги, предоставляемые в Интернете, должны быть доступны как можно большему количеству людей, учитывая ограничения технологии.

Ваш подход к решениям должен основываться на глубоком знании вашей пользовательской базы. Если вы работаете над приложением для iPhone, вам не нужно беспокоиться о традиционной веб-доступности, потому что это очень наглядно. Если вы создаете веб-приложение для широкой аудитории, эти новые фреймворки, вероятно, будут плохим выбором (если вы цените максимально широкий доступ к вашей информации и услугам).

Со временем программы чтения с экрана, вероятно, станут лучше интерпретировать интерфейсы с большим количеством JavaScript, поэтому, возможно, эта проблема исчезнет. Дело в том, что на его месте может «прорасти» что-то еще.

Javascript является веб-стандартом - определенно в большей степени, чем, скажем, Flash, который ранее (и до сих пор часто используется) для полнофункциональных веб-приложений. В этом отношении SproutCore и Cappuccino - гигантские улучшения в моей книге.

Вопрос здесь действительно в том, насколько важна доступность. Как сказал Эндрю, это во многом личное решение, основанное на знании своих пользователей. Для некоторых приложений доступность действительно не имеет особого смысла - 280 Slides - хороший тому пример. Это приложение для графического дизайна, которое в основном посвящено визуальному поведению. Нет смысла превращаться в открытый текст. (По крайней мере, текстовое приложение, предназначенное для выполнения того, что делает 280 Slides, было бы совершенно другим.)

да. Поначалу это будет сложно, но как только кодовая база станет зрелой, вы будете благодарны, что следовали этим строгим стандартам.

Изменить: дополнительным преимуществом будет переносимость на многие веб-платформы через профили CSS и многое другое.

Модель MVC может быть применена к настольным приложениям так же легко, как и к веб-приложениям. Я не вижу особых причин проводить различие между ними, тем более что граница более размыта в случае веб-приложений.

Я не знаю об этих конкретных фреймворках, но многие веб-фреймворки в наши дни построены вокруг модели MVC, например, ASP MVC, CakePHP, Ruby on Rails и т. Д.

Разделите столько, сколько сможете, и в конце концов окупится. Когда все становится сложным и волосатым :)

Я думаю, им стоит. Следуя этому типу дизайна MVC, можно упростить внесение изменений, обеспечивает хорошее разделение ответственности и, как правило, легче понять новичкам в проекте.