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

Днем я являюсь интерфейсным веб-разработчиком, но в свободное время балуюсь другими языками, такими как C, Objective-C, Python и т. Д. Когда я только начал заниматься веб-разработкой, идея веб-приложений только зарождалась.

С тех пор появилось два удивительных фреймворка: SproutIt SproutCore и 280 North Cappuccino (+ Objective-J). SproutCore используется Apple для своего приложения MobileMe, а компания 280 North выпустила 280 слайдов. Оба этих приложения великолепны и являются свидетельством того, что возможно в Интернете. Итак, импульс смещается. Веб-приложения начинают выглядеть и действовать как настольные приложения.

Итак, мой вопрос таков: должны ли веб-приложения соответствовать веб-стандартам, разделению разметки (контента), представления (дизайна) и поведения (функциональности) или нет?

Я не уверен насчет SproutCore, поскольку я не смотрел исходный код, но я знаю, что если вы перейдете на 280slides.com и отключите JavaScript, все в основном исчезнет. Остались бессмысленные слова.

Позвольте мне уточнить, я понимаю, что веб-приложения, такие как 280 Slides, предназначены для включения JavaScript и не предназначены для работы без него, но в моей повседневной работе мое основное внимание уделяется написанию чистой разметки, разделению контента, презентации и поведения, чтобы нашим сайтом и приложениями может пользоваться как можно больше людей.


frameworks standards web-standards
person Lark    schedule 06.03.2009    source источник

Ответы (6)


arrow_upward
5
arrow_downward

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

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

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

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

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

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

person Andrew Hedges    schedule 06.03.2009

arrow_upward
2
arrow_downward

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

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

person Chuck    schedule 06.03.2009

arrow_upward
1
arrow_downward

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

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

person cpatrick    schedule 06.03.2009

arrow_upward
1
arrow_downward

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

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

person Chris Thompson    schedule 06.03.2009
comment
Я не знаю, почему люди проголосовали за это. Это вообще не решает вопрос. Он спрашивает, следует ли выбросить из виду постепенную деградацию, прогрессивное улучшение и т. Д. С новыми фреймворками FRONT-END на основе JavaScript, которые входят в моду. - person Andrew Hedges; 07.03.2009
comment
Я явно неправильно понял вопрос. Я рад видеть, что кто-то другой смог дать лучший ответ. - person Chris Thompson; 13.03.2009

arrow_upward
0
arrow_downward

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

person cherouvim    schedule 06.03.2009

arrow_upward
-1
arrow_downward

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

person Ben S    schedule 06.03.2009