11 декабря 2013 в 17:20

Разработка → Мы потеряли тот Веб перевод

JavaScript*, CSS*, Разработка веб-сайтов*

Кратко: после браузерных войн организация W3C и группы разработчиков, такие как Web Standards Project, долго и упорно работали, чтобы восстановить единый нефрагментированный Веб. Но в последние несколько лет мы, разработчики, взяли, и заново всё зафрагментировали… Наверное, нам надо понять, что мы теряем, прежде чем потеряем этот Веб навсегда.

Ровно год назад патриарх веб-индустрии Anil Dash написал: "Мы потеряли Веб", скорбя по ранней, «досоциальной» блогосфере, до всех этих наших постингов фото, видео и мыслей, находящих последний приют в катакомбах Фейсбука, Твиттера, Инстаграма и Ютуба. Это вызвало отклик у многих, кто застал те дни; многих, кто по иронии судьбы затем ушёл работать в эти катакомбы.

Особенно, если тот самый период, примерно до середины 2000-х, был ранее вашего полноценного присутствия в Сети, вы должны найти время, чтобы не спеша, основательно прочитать его статью. Веб, действительно, изменился за последнее десятилетие, и не всегда к лучшему. Анил пишет:

«Мы потеряли основные идеи, лежавшие в основе, и хуже того, отказались от основополагающих ценностей, которые были в истоках мира Сети.»

… и отмечает, что одна из целей, для которых он написал заметку — чтобы люди, создающие новые социальные приложения, прикоснулись к истории, узнали её истоки.

Наверное, какие-то из этих идей, действительно, витают в воздухе, поскольку в последние пару недель Faruk Ateş и Jeremy Keith тоже размышляли на эту тему.

И я в том числе, большую часть прошедшего года думал о подобном, чувствуя, что мы потеряли кое-что из раннего веба, хотя думал о гораздо более ограниченной составляющей Интернета. О том, что обычно не попадает в поле зрения большинства пользователей Сети — о его коде. Думаю, что к нему тоже относится "… отказались от основополагающих ценностей, которые были в истоках мира Сети".

Браузерные войны

Анил говорит о Веб примерно с 2000 года, но я хочу сказать о сроке примерно с середины 1990-х годов. Сейчас почти все из нас слышали о браузерных войнах. Если спросить, что же тогда произошло, то большинство скажет, что это было время, когда Netscape и Microsoft боролись за контроль над Интернетом, стремясь сделать свой браузер доминирующим.

Но каким способом они пытались добиться доминирования? В некотором смысле, войны браузеров (первоначально воевали между собой Netscape и его предшественник Mosaic) могут называться «HTML-войнами», потому что полем сражения, образно говоря, для многочисленных браузеров, в том числе появившихся до IE, был язык HTML.

Не было никакой «стандартной версии HTML». Вместо этого, новые языковые возможности появлялись с новыми версиями браузеров — такие, как img, списки, таблицы, фреймы, теги font, embed и так далее. Появлялись целые языки (Javascript) и сложные архитектуры, такие как DOM. В основном, это было хорошо. Веб увеличивался в сложности и быстро получал жизненно важные функции.

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

Из этого периода мы узнали, что выигрывает тот, кто «ходит первым» (к примеру, теги «img», предложенные Марком Андрессеном, несмотря на противодействие Тима Бернерса-Ли, выступавшего за более гибкий механизм, победили и продолжают являться нам по сей день). Решения, принимаемые на уровне архитектуры, могут иметь очень длительный период полураспада, поэтому должны делаться особенно тщательно.

Это — обычный пунктик сегодняшних сетований веб-разработчиков; проще говоря, несоответствие браузеров — причина головной боли в веб-разработке. Представьте, каково разрабатывать сайты на самых последних, едва сделанных и плохо документированных функциях, меняющихся с каждым релизом браузеров?

Именно этот хаос видела группа W3C, роль которой, по-прежнему часто не понимают. Цель этого комитета была и остаётся — наладить диалог заинтересованных сторон, чтобы стандартизировать новшества. Чуть позже веб-разработчики почувствовали необходимость отстаивать принятие новых стандартов, и так родился проект Web Standards (который, как ни смешно, в начале этого года заявил, что «Наша работа здесь закончена». Почему это смешно, рассмотрим чуть ниже).

Но похоже, что мы упустили из виду то, что следствием браузерных войн и последующей основой W3C и проекта Web Standards было избегание «балканизации» в Интернете. Мы знали, что для Интернета важна универсальность и совместимость. И мы знали, что ~~Галактика~~ он был в опасности из-за браузерной фрагментированности.

И совершенно восхтительно, особенно, если вы знакомы с событиями Интернета конца 1990-х, с противостоянием JSSS (JavaScript StyleSheets) компании Netscape и CSS, несовместимыми недокументированными DOM, JavaScript и JScript, жестокой битвой между Netscape Communications и Microsoft — на этом фоне мы создали Веб, который не был раздробленным, стандартизируя HTML, CSS, JavaScript и DOM, давая изнурённым разработчикам преимущества такого Веба. Это было замечательное достижение; усилиями многих людей из Microsoft, Apple, Mozilla и Google была сделана большая неблагодарная работа по стандартизации технологий, теми, кто выступал за обучение разработчиков технологиям, основанных на стандартах. Некоторые стали хорошо известны, большинство упорно трудились за скромные награды, но каждый чувствовал, что именно таким должен быть Веб.

А потом, шаг за шагом, подобно той лягушке, которая не замечает своей смерти в медленно закипающей воде, мы выбросили этот Веб.

Мы позволили, поощряли и приняли фрагментацию DOM библиотеками и фреймворками, в каждом из которых — свой способ доступа к атрибутам, изменению элементов и управлению DOM.
Мы фрагментировали JavaScript языками, компилируемыми в него.
Мы фрагментировали HTML тоннами шаблонизаторов.
Мы фрагментировали CSS препроцессорами наподобие Sass и Less.

Что же мы наделали?

Это не означает, что всё кругом совершенно плохо. Это далеко не так. Каждая из этих технологий и инноваций доставляет разработчикам новые заботы. Многие — намечают пути для будущих стандартов. Но в совокупности, мы взяли относительно простой набор самостоятельных технологий — HTML, CSS, JavaScript, DOM; каждую — со своими четко определенными ролями, каждую — относительно законченную, чтобы освоить и начать работать с ней, и создали хаотичный зоопарк конкурирующих технологий, многие из которых делают ровно то же самое, но несколько иначе и несовместимо.

И на этом пути добавились зависимости от других языков и сред, потому что появилась стадия сборки в рабочем процессе, чего в Вебе ранее не было.

Что же мы получили?

Возможно, разработчики сейчас — более продуктивны. Возможно, мы сделали жизнь проще во время начальной фазы развития проектов. Но есть основания сомневаться, что есть больше, чем отдельные успехи во имя поддержания веры. Поверьте — это общий аргумент любой новой технологии — что она сделает разработку более продуктивной. Вы ведь читали что-то из вашей литературы? (вспомните, как чуть выше убеждали помнить наше наследие.) И разработчики ПО давно поняли, что лишь малый процент стоимости системы относится к начальной стадии её развития. Техническое обслуживание за годы и десятилетия — очень значительная доля затрат на систему (да, есть много литературы и на эту тему).

Но что же мы потеряли?

Когда-то веб-разработки стали отличаться от большинства других технологий тем, что мы говорили на одном языке, некотором Койне, lingua franca, наподобие разработок для Windows, крупнейшей платформы в течение многих лет, где несметное число языков, основ и сред разработки основывалось на Windows API. Эта общность языка принесла с собой ряд преимуществ, в том числе, облегчённое обучение веб-технологиям и упрощение поддержки проектов. Это увеличило жизнеспособность ваших знаний и опыта веб-разработчика.

Обучаемость

Наличие общего набора технологий для фронтенда упростило обучение. Поиск учебников, экспертов и рабочих встреч по этим технологиям было относительно простым делом. Освоение навыков и знаний было относительно просто. Вы можете написать некоторый HTML- и CSS-код и построить что-то полезное. Со временем вы сможете увеличить свои знания о них и добавить понимание JavaScript и DOM, чтобы расширить свои возможности. Был эффект сети из-за существования большой группы разработчиков, имеющих общие языки и концепции.

Действительно ли мы хотим уменьшить этот сетевой эффект путём фрагментации технологий в Интернете, рытьём катакомб институтов экспертизы, с незначительной долей общего языка? Мы должны хотя бы быть в курсе потенциальных последствий нашего выбора. Осознавая не только индивидуальные плюсы от выбора, но и то, что все вместе мы можем потерять.

Ремонтопригодность

Наличие общего набора технологий упрощает поддержание существующей базы кода. Лежащие в основе технологии HTML, CSS, JavaScript и DOM длительное время стабильны в отличие от большинства фреймворков, библиотек, языков и препроцессоров (не говоря уже об инструментах и языках, на которые они частично опираются). Будет ли база вашего сервиса поддерживаться 5 лет? И, основываясь на менее распространенных технологиях, количество разработчиков, способных поддерживать базу кодов, значительно уменьшается.

Традиционно, более половины стоимости сложной системы пришла во время фазы эксплуатации, так что при большой перестройке проще всё выбросить и начать строить заново, чем вести эволюционное развитие программных проектов; то, что мы строим для Интернета, становится все сложнее, и для критически важных проектов фаза обслуживания будет становиться все более длительной и дорогостоящей. И опять же, хорошо понятно, что ремонтопригодность сильно зависит от возможностей разрозненных разработчиков, чтобы понять и иметь причины (мотивацию) поддерживать кодовую базу длительное время, чем просто использовать для правок copy-paste [в языках разметки страниц — прим.перев.].

Взаимодействие

Одним из основных принципов Web является «совместимость». Хотя это непосредственно касается обеспокоенности тем, что «компьютерные языки и протоколы… призваны избежать рыночной фрагментации в прошлом», я бы утверждал, что фрагментация должна не только беспокоить, когда речь заходит о системах с нашим работающим кодом. Мы также должны быть обеспокоены фрагментацией сообщества веб-разработчиков. Чем меньше разработчиков с рабочим знанием технологии, тем меньше возможностей им взаимодействовать по вопросам технологии.

Из этого же круга — вопрос о том, как будут взаимодействовать технологии друг с другом. Скажем, у вас нравится, как Sass реализует переменные, но хочется использовать и @ debug в LESS. Вам нужны и LESS, и Sass, и, вероятно, вокруг разразится чертов беспорядок. Монолитный подход многих «инноваций» значительно влияет на то, как будут взаимодействовать они друг с другом.

Долговечность

Если вы провели годы, развивая знания и опыт в Flash или Silverlight/WPF, это знание становится всё более бесполезным. То же самое произойдет с jQuery, как это было с другими, казалось бы, доминировавшими библиотеками JavaScript и фреймворками, такими как Prototype. Это произойдет со всеми библиотеками и фреймворками, которые мы изучаем сегодня так усердно: AngularJS, Bootstrap, <… подставьте ваше название...>. Очень немногие технологии прожили последние годы, не говоря уже про десятилетия. Как человек, тратящий разумное количество времени в изучение технологий, я был бы озабочен тем, чтобы усилия были оправданы.

Что же делать?

jQuery, Backbone, AngularJS, CoffeeScript, Bootstrap, Sass, LESS (просто назовём некоторые из самых популярных фреймворков, библиотек, языков и препроцессоров, которые мы разработали за последние несколько лет для решения проблем, чтобы делать все более сложные вещи, не выделяя ничего конкретно) являются сложными, мощными технологиями, хорошо проверенные в очень многих рабочих процессах, используемых тысячами, десятками тысяч разрабочиков или более. Они не уходят. И вслед за ними придут другие. Возможно, понадобится медленное погружение из высоких технологий в HTML, CSS, DOM, JavaScript. В конце концов, программисты мало, если вообще, пишут на ассемблере, не говоря уже о машинном коде. Но, как Anil Dash писал о другом Вебе, "мы отказались от основополагающих ценностей, которые были в истоках мира Сети", и я думаю, что это верно и по отношению к создаваемому коду.

Что может быть этими основными ценностями? Нетрудно видеть, что они ясно описаны консорциумом W3C (еще раз, слова Анил: "узнать немного истории, чтобы знать свои истоки").

«W3C стремится к техническому совершенству, но прекрасно понимает, что известное сегодня может быть недостаточно, чтобы решить проблемы завтра. Поэтому мы стремимся построить Web, который может легко превратиться в еще лучший Web, не нарушая того, что уже работает. Принципы простоты, модульности, совместимости и расширяемости лежат в основе всех наших конструкций.»

Цели W3C, принципы работы и их направленность

Руководствуются ли разработчики этими принципами простоты, модульности, совместимости и расширяемости, когда они разрабатывают новые языки? Фреймворки? Препроцессоры? Конечно, во многих случаях — да. Это особенно верно в отношении polyfills и "prollyfills". У них нет цели «вскипятить океан» организацией огромного массива функциональности, а скорее, следуют модели „свободного присоединения небольших кусочков“, которые делают одно действие, но делают это хорошо.

Но во многих случаях наши решения не модульные, не простые или не совместимые (особенно, в произвольных комбинациях). На самом деле я бы сказал, что в этом — суть вопроса. Вместо решения конкретной задачи через простоту, модульность и совместимость, наши решения часто становятся все более сложными нагромождениями решений всех видов проблем. Вот к примеру то, что архитекторы CSS пре-процессора сообщают о принципах конструирования Sass:

»Не существует формального процесса, по которому мы добавляем новые функции в Sass. Подходящие идеи могут исходить от кого угодно и отовсюду, и мы рады рассмотреть их из списка рассылки, IRC, Twitter, сообщения в блоге, из других компиляторов CSS, или любого другого источника".

… которые, скорее, напоминают Гомера:

Свободное присоединение небольших кусочков

В 2002 году один из пионеров веба Дэвид Вайнбергер (между прочим, соавтор из Cluetrain Manifesto) описал " небольшие слабо связанные кусочки " — способ мышления, который делает интернет особым. Я давно думал, что это относится также к технологиям Интернета, и эти принципы должны определять, как мы создаём проекты для Интернета, будь то наши собственные сайты, для наших клиентов, работодателей, или самих технологий, которые развиваются в Интернете.

Если бы каждый раз, когда мы брались решение задачи, мы думали, «как я могу решить эту маленькую проблему?», или даже "в самом ли деле здесь проблема?", и затем решить её на принципах модульности, совместимости, и расширяемости, насколько возможно, то мы выберем долгий путь к укрощению взрыва сложности, который мы видели в течение последнего пятилетия или около того, и возвратимся, по меньшей мере, частично на тот Web, который мы потеряли.

Возможно, этому вебу тоже пришлось бы повзрослеть, чтобы отвечать на вызовы все более усложняющихся моделей, которые мы строим. Когда веб состоял из документов и сайтов, возможно, мы сохранили бы простоту, но в эпоху приложений простота — это роскошь, которую не можем себе позволить. Возможно, с течением времени будут необходимы фундаментальные доработки всех необходимых фрагментов платформ.

Но, прежде чем мы потеряем навсегда этот веб, думаю, что мы должны по-настоящему понять тот веб и то, что обеспечивает его чёткую работу. И когда мы делаем технические, архитектурные решения о том, каким будет веб, мы не должны думать только о собственных выгодах, но также о том, что утратит с ними нынешний интернет.

UPD 12.12.2013 16.00: Интересно сравнить то, что в блоге автора написали за неделю и здесь — за сутки; приведу начала переводов английских комментаторов, всех подряд:

начала комментариев к английской версии

* Блестящая статья! Я думаю, что эти явления цикличны, и что нынешняя фрагментация будет стандартизирована, и фрагментируется снова, т.к. люди придумают различные решения, чтобы эффективно работать.…
* Я боролся с этим совсем немного сам, отошёл от Джиквери к «старомодной» ванили, и была тяга к Sass, и всё больше ищут людей с опытом работы в них…
* Происходят некоторые значительные события в истории веба. Мы видим наступление технологий, как и в других областях…
* это действительно хороший пост, вы делаете много превосходных наблюдений.
* Это всё раздуто. Я делал сайты года с 97-го, DOM, CSS и языки шаблонов — не проблемы того порядка как были в войне Нетскейпа и Майкрософт. Они все сводятся к стандартной технологии…
* Мощная статья — чувствую, что большинство технологий требуют предупреждений об умеренном использовании…

и ещё 5-6 комментариев.

В общем, там немного больше, но за неделю, всё же, но и мы в полноте анализа ситуации не отстаём, все особые моменты в комментариях отметили.

Самое читаемое Разработка

Комментарии (74)

anreyyyy 11 декабря 2013 в 17:48

+58

Хватит ныть!

AlexTest 12 декабря 2013 в 02:57 (комментарий был изменён)

+15

Порог вхождения в современный зоопарк веб-технологий от самих методик разработки до конкретных инструментов все выше.
Зарплаты сеньоров все заоблачнее — и это не может не радовать (сарказм)!
Никаких KISS — только фреймворки генерирующие фреймворки на все случаи жизни!
А в итоге все как на картинке:
AVGUR 12 декабря 2013 в 09:38

0

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

Zippovich 11 декабря 2013 в 17:57

+25

Раньше люди думали что земля плоская и держится на 3-х китах. Потом — БАЦ — и земля круглая — и даже не в центре вселенной, появилось много разнообразных телескопов, и трудно даже выбрать из всего разнообразия какой тебе подходит — делают они одно и то же, только немного по разному.
Мы фрагментировали и усложнили свое представление о мире. Мы потеряли тот мир! RIP!

dikkini 11 декабря 2013 в 18:00

0

И сколько ты не изучай космос и технологии для его изучения, всегда придут новые технологии, которые дадут новые знания о новых объектах и тебе опять придется лезть глубже и глубже в этот стек технологиях. А раньше как все просто было…
- Zippovich 11 декабря 2013 в 18:05
  
  +2
  
  просто не было — была куча несовместимых друг с другом технологий, которые не стандартизировались.
  сейчас есть стандарты и надстройки над ними — их можно пользовать, можно не пользовать — ну да, работают они по разному, но и решают в основном свои цели (jquery — для простоты, angular — для сложных js приложений, которые работают вживую). Но что в этом богатстве выбора плохого, я так и не понял из статьи. Ведь это всего надстройки, стандарт един.
  - dikkini 11 декабря 2013 в 20:37
    
    0
    
    *Не надо забывать скрытный тег *
  - VolCh 12 декабря 2013 в 01:59
    
    +3
    
    Но что в этом богатстве выбора плохого, я так и не понял из статьи. Ведь это всего надстройки, стандарт един.
    
    Всё больше народу, который не знает стандарт, а знает лишь свои любимые фреймворки и библиотеки. Скажем, jQuery-программист раньше было шуткой, а теперь реальность. Для поддержки проекта на angular, человеку, писавшему только на jquery, мало поможет его опыт — придется изучать практически всё с нуля.
    - Zippovich 12 декабря 2013 в 17:20
      
      0
      
      у таких людей плохая карма

shambho 11 декабря 2013 в 18:57 (комментарий был изменён)

Web-технологии стали заложниками собственной «стабильности» — они уже давно не удовлетворяют современным потребностям, как по функциональности, так и по программированию оных. Ностальнические технологии «того веба» являются узким местом, которое не решаются реформировать как раз апологеты «совместимости». Но, по-видимому, количество несуразностей ещё не перешло в качественное решение все это разгрести. Опыт HTML5 показывает, что если найдется хороший «локомотив», то остальные дружно согласятся присоединиться к современному поезду.

Aingis 14 декабря 2013 в 14:33

0

Потребности или спрос всегда опережает предложение, это норма. Обратная совместимость — реальность, никто не будет пользоваться браузером, в котором ломается половина сайтов. Поэтому Опера, кстати, и сменила движок, хотя в ней ломалось гораздо меньше сайтов.

Сайтов, написанных с соблюдением всех стандартов — малая часть, большинство написано абы как плохо разбирающимися людьми, даже здесь отметились неспециалисты, которые всё туда же, ринулись критиковать стандарты, даже не будучи знакомы с ними. Опять же эти сайты никем не поддерживаются, иначе бы они были уже попросту переписаны, и они сломаются, стоит отбросить обратную совместимость.

zag2art 11 декабря 2013 в 19:44

+13

Alexey2005 11 декабря 2013 в 19:45

+22

К сожалению, в W3C сидят не инопланетяне с Сириуса, а те же самые умники, которые занимались браузерными войнами. Можно смело считать, что войны не закончились, а просто перешли в затяжную позиционную фазу. Там по-прежнему каждый тянет одеяло в свою сторону. По-прежнему считают необязательным выполнять предписания совместно принятого стандарта. По-прежнему добавляют вендорные префиксы, особенности реализации. По-прежнему сперва реализовывают в браузерах, а потом ставят всех перед фактом и протаскивают в качестве стандарта.
Причём похоже на то, что во всём W3C нет ни одного верстальщика. Я даже не уверен, что там есть программисты — скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки. Ничем иным просто не объяснить тот факт, что W3C принимает самые дикие, идиотские, неудобные решения, тогда как наиболее типичные случаи вёрстки и программирования до сих пор не покрыты (уже сколько лет самый популярный вопрос юных верстальщиков — «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны». W3C, ау, вы там совсем что ли лыка не вяжете?). Отсюда и получается:

Мы фрагментировали JavaScript языками, компилируемыми в него.
Мы фрагментировали HTML тоннами шаблонизаторов.
Мы фрагментировали CSS препроцессорами наподобие Sass и Less

Продукция W3C неюзабельна до такой степени, что приходится придумывать нечто более удобное.

zag2art 11 декабря 2013 в 19:47

0

> скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки

Улыбнуло :)
SerafimArts 12 декабря 2013 в 15:06

+1

как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны

Всё же элементарно! Оборачиваете div в элемент с disply: table-cell;, этот элемент в другой с dsiplay: table;, к внутреннему применяете vertical-align: middle;, а к нужному диву disply: inline-block; и вуаля! Всего пара часов потраченного в пустую времени и уже почти рабочий вариант выравнивания по середине =)
- SerafimArts 12 декабря 2013 в 23:37
  
  0
  
  Кстати, грамматика прямо пропорциональна качеству такого решения ;)
- Aingis 14 декабря 2013 в 11:37
  
  0
  
  Вообще во флексбоксе ещё проще:
  .container {
  display: flex;
  align-content: center;
  }
  www.w3.org/TR/css3-flexbox/#align-content
kiselev_dv 12 декабря 2013 в 16:46

+2

Пользуясь случаем, хотел спросить у верстальщиков, почему табличная верстка это чуть ли не табу в современном вэбе?

То есть я понимаю все прелести идеи «HTML отражает структуру, css отвечает за отображение» и то что таблицы смешивают отображение и структуру данных что эту идею ломает.

Но почему обернуть текст в 3 дива не имеющих отношения к логике данных — это неизбежная жертва, а обернуть тот же текст в td, tr ,table — это как пукнуть в лифте?
- irium 12 декабря 2013 в 17:25
  
  0
  
  Но почему обернуть текст в 3 дива не имеющих отношения к логике данных — это неизбежная жертва, а обернуть тот же текст в td, tr ,table — это как пукнуть в лифте?
  
  Плюсую. Тоже до сих пор этого не понимаю.
- spmbt 12 декабря 2013 в 17:29
  
  0
  
  У вёрстки на таблицах много особенностей в крайних случаях представления контента (пустые ячейки, диспропорции в заполнении ячеек). При использовании таблиц как каркаса придётся свести их использование к строго ограниченным формам (насколько помню, только одна ячейка в ширину, иначе вылезают краевые особенности). Я это проходил в 2010-м, в новых браузерах могло что-то измениться, но старые всё равно их имеют. Кроме того, дивы гибче в переставлении блоков средствами CSS, хотя тоже не на 100% гибкие.
  - НЛО прилетело и опубликовало эту надпись здесь
- GearHead 12 декабря 2013 в 17:58
  
  0
  
  всё просто. попробуйте перенести сайдбар (скажем, с левой стороны в правую) с помощью одного только CSS в табличной вёрстке и в блочной.
  - kiselev_dv 12 декабря 2013 в 18:20
    
    0
    
    Ясно-понятно что одним css для таблички не обойдешься. Но на блочной, как правило дело так же не ограничивается изменением float или заменой left:5px на right:5px. Тут же выясняется что надо обернуть сайдбар и контент в еще один див, т.к. справа ему хватало относительно позиционированного родителя, а слева уже нет и т.п. И на практике это выливается в то что вам все-равно надо меня шаблон и переносить вывод дочерних элементов в другое место.
    
    Сатанинский смех, а потом вы узнаете что ваш клиент — гос контора которая использует какой-нибудь ужас и ничем другим кроме шестого эксплорера пользоваться не может.
    - GearHead 12 декабря 2013 в 18:34
      
      0
      
      на практике выливается, что чем опытнее верстальщик, тем лаконичнее вёрстка (без лишних оборачивающих дивов). а чем лаконичнее вёрстка, тем меньше изменений нужно для модификации. а табличную вёрстку лаконичной никогда не назовёшь.
      
      и это я уже не буду говорить про адаптивность, которая является банальным проявлением уважения к пользователям, и которую табличной вёрсткой вы не получите.
      
      и это я уже и не говорю о том, что идейно разметка должна разбивать сайт на смысловые части, а их вид должен абстрагироваться от самих данных, чего табличная вёрстка не даёт.
      - Perez 18 декабря 2013 в 00:09
        
        0
        
        По моему адаптивность слегка переоценивается в последнее время. Мне думается что один большой и сложный шаблон под всё сразу куда менее технологичен чем пара тройка простых с заточкой под конкретные задачи.
  - Aingis 14 декабря 2013 в 11:44
    
    0
    
    Если у вас стандартная трёхколоночная раскладка (или двухколоночная), то довольно просто:
    table { direction: rtl }
    th, td { direction: ltr }
    в предположении, что у вас сайт на языке, пишущемся слева направо. (Впрочем, иначе вы бы знали о свойстве direction.)
    - НЛО прилетело и опубликовало эту надпись здесь
      - Aingis 17 декабря 2013 в 23:32
        
        0
        
        Это да, я так в статье «Основные способы вёрстки» и писал.
- fatal 13 декабря 2013 в 01:30
  
  0
  
  Чем отличается DIV от TABLE? Семантика — наше всё! :) Ну и современные браузеры уже позволяют DIV-ы собрать как таблицу (выше пример привели).
  - НЛО прилетело и опубликовало эту надпись здесь
kiselev_dv 12 декабря 2013 в 18:06

0

В поддержку треда о стандартах W3C и практике.

Попробуйте на досуге указать в xsd что вам нужен набор дочерних элементов встречающихся в любом порядке но с ограничениями на количество. Казалось-бы самый простой вариант.

К примеру нижеприведенные элементы могут следовать в любом порядке но лишь указанное количество раз:
<optinal/> — может встречаться 0 или 1 раз
<optinal-multy/> — может встречаться 0 раз и более
<required/> — строго 1 раз
<required-multy/> — 1 раз и более

С математической точки зрения стандарт полон. Т.е. задать такие ограничения можно. Но на практике это выливается в решение задачек по комбинаторике и записи чуть ли не всех возможных комбинаций sequence и choice.
NekR 13 декабря 2013 в 11:25

+2

> (уже сколько лет самый популярный вопрос юных верстальщиков — «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны». W3C, ау, вы там совсем что ли лыка не вяжете?). Отсюда и получается:

display: flex;
align-items: center;

В современных браузерах работает очень хорошо.
Aingis 14 декабря 2013 в 12:04

+2

> Можно смело считать, что войны не закончились, а просто перешли в затяжную позиционную фазу. Там по-прежнему каждый тянет одеяло в свою сторону.

Верно, каждый отстаивает свои интересы, однако, сторонам вполне удаётся договориться, учтя все стороны вопроса. Быстро хорошо не бывает.

> По-прежнему добавляют вендорные префиксы, особенности реализации.

Файрфокс и Хром уже отказались от добавления новых префиксов и перешли к модели включения экспериментальных свойств за флагами.

> По-прежнему сперва реализовывают в браузерах, а потом ставят всех перед фактом и протаскивают в качестве стандарта.

Действительно такое бывает, когда вводится что-то совершенно новое, но по какой-то причине нужное вендору. Однако, для в таких случаях, во-первых, как раз есть ограждающие префиксы. Во-вторых, все понимают, что нестандартную фичу никто не будет поддерживать, и поэтому выдвигают предложение на стандартизацию. А иногда даже помогают с реализацией. Просто так протянуть стандарт не получится, одно из требований на звание стандарта: наличие двух независимых реализации, и в любом случае пройдёт длительный процесс обсуждения со всеми заинтересованными сторонами.

> Причём похоже на то, что во всём W3C нет ни одного верстальщика.

Есть и не один. Правда, участники довольно продвинуты, они не просто верстальщики, а знают яваскрипт и многое другое.

> Я даже не уверен, что там есть программисты — скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки.

И программисты есть, например, активно принимает участие Дэвид Барон — главный программист из Мозиллы. Кстати именно они не дают протащить в стандарт сложнореализуемые потенциально тормозные штуки вроде селектора вложенного элемента.

> «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны»

Вопрос уже решён во флексбоксе и уже есть в том или ином виде в 77% браузеров, написал выше:
habrahabr.ru/post/205692/#comment_7097346

> Отсюда и получается:…

Как справедливо отметили ниже, это вообще серверная сторона. Что творится на сервере — ваше дело. Клиенту отдаётся всё тот же HTML, CSS и JS.

> Продукция W3C неюзабельна до такой степени, что приходится придумывать нечто более удобное.

Всё прекрасно используемо, просто вы хотите странного. Я, так, вообще не вижу смысла в препроцессорах. Переменные? Уже есть спецификация, и она даже начал внедряться в Файрфоксе. Префиксы? Старая песня, от них уже отказываются. Миксины? Перечесление селекторов через запятую никто не отменял, впрочем и они будут в следующей версии спецификации.

Да это не быстрый процесс, потому что стандартизация затрагивает множество участников и каждому даётся возможность принять участие, вдобавок, браузерам тоже нужно время на внедрение и обратную связь, но процесс идёт медленно, но верно.
- НЛО прилетело и опубликовало эту надпись здесь
  - Aingis 17 декабря 2013 в 23:27
    
    0
    
    Всё верно, @viewport, предложенный Оперой призван заменить мету. Есть даже реализации в IE10, в Опере на Presto, вроде, в Хромиуме тоже есть. Но, конечно, до полного внедрения далеко. Однако, про спецификацию помнят.
    - НЛО прилетело и опубликовало эту надпись здесь

Gorthauer87 11 декабря 2013 в 20:05

Обычный процесс эволюции. Что в нём страшного? Лучше уж жить в живом хаосе, чем в мёртвой золотой клетке.

orcy 11 декабря 2013 в 20:38 (комментарий был изменён)

На этом пути не надо ограничеватся только клиентским вебом! И сервера мы тоже теряем, смотрите какой беспредел: питон, руби, node.js, asp.net mvc, еще и по нескольку фреймворков у каждого. Нужно вернутся к теплому ламповому PHP (или CGI + bash?) и перестать фрагментировать сервера. Десктопы тоже надо прекращать фрагметировать, не нужно это. Есть же C и Win32 API, зачем этим MFC, WTL, Qt, .NET WinForms, WPF, Java. Переусложения какие-то.

Может автор просто постебал жалобы вроде «веб уже не торт», а я просто не понял.

bigfatbrowncat 12 декабря 2013 в 10:31

+1

Возможно, автор имел в виду немного другое: на протяжении 5-6 лет усиленной стандартизации разработка под Web становилась всё проще и проще. Но в какой-то момент она снова начала становиться сложнее. И это его удручает.
- Alexeyco 12 декабря 2013 в 10:35
  
  0
  
  Все равно, больше похоже на то, что автору кто-то испортил настроение и он решил выместить свои переживания в форме статьи «как же стало хреново». На мой взгляд, ну да, вроде (теоретически) все по делу. Но с другой стороны, читаешь и думаешь «ну и что». Ну пишут авторы фреймворки, которые немодульные и несовместимые. Ну никто ж не запрещает взять то, что у них, и сделать это модульным. К примеру, мне бы хотелось иметь шлем, подключенный к компьютеру, чтобы я думал — а оно само код генерировало. Но такого шлема нет. А мне страсть, как хотелось бы. Должен ли я написать статью о том, что все плохо?
  - Lendon 13 декабря 2013 в 01:42
    
    0
    
    Шлем это мечта… Можно было бы писать код прямо в транспорте, засунув руки в карманы.
- zw0rk 16 декабря 2013 в 15:38
  
  0
  
  Может просто потому что бизнес заметил, что предыдущие задачи делаются просто и можно усложнять задачу? Реактивный манифест, к примеру, это ведь усложнение задачи, которое пока требует более сложных решений.

ImLiar 12 декабря 2013 в 00:50

–7

Вся суть поста:
— Вот вам нормальные инструменты вместо этих обрезков технологий для разметки текста
— Нет, хотим дальше жрать говно ложками.

Aux 12 декабря 2013 в 15:40

+1

Инструментов как раз никто не даёт, дают только ложки с разным оформлением и размерами. Кто-то выбирает большую золотую ложку, кто-то маленькую люминевую, но говно жрут все.

Правильный посыл был бы перестать жрать говно, а не обсуждать ложки.

Lure_of_Chaos 12 декабря 2013 в 02:46

+13

А я верю, что разнообразие — суть эволюции. Да, многие технологии недолговечны, но если они умирают, то они непригодны, и не стоит их содержать на искусственном дыхании. Например, почему мне нужно писать document.getElementsByClassName вместо $(".class"), а затем еще и итерируя, вызывать метод .item(i)? Ведь не составило бы большого труда примерно ту же фунцкциональность таких фреймворков, как jQuery, реализовать нативно. Просто необходимо вдумчиво рассмотреть существующие решения и осторожно их слить во что-то лучшее, при этом минимально, но верно отходя от пережитков — не боясь обратной совместимости. Ведь сейчас никто не напишет document.all['item'].
Почему даже теперь (если я не отстаю от жизни) в CSS нет наследования и примесей, это до сих пор вынуждены делать те же LESS и SASS. Зато появились излишние навороты вроде анимаций, которые, на мой взгляд, больше инкапсулируют (и тщательно от нас скрывают) довольно сложную логику под «разметкой» — и в целом это все очень сильно напоминают стремления инноваций предложить нам две-три кнопки «сделать збс», вместо действительно логично нужных вещей.
И таки да, теперь мы видим кучу вещей, вроде логотипов и мультиков на «чистом html5 и css3», исходник которых еще менее очевиден, чем будучи напсан на js. Но нужно ли это, если теперь без js не будут работать сколь серьезные сайты, а _некоторые_ браузеры вообще выпиливают настройки «запретить js»? Это как гламур — впечатляет, но не насущно.
И если раньше мы имели браузерную войну Netscape\IE\Opera с надписями «best viewed in IE6 800x600», то теперь HTML5 сам раздробился на подмножество себя, и мы, как никогда раньше, имеем фичи, имеющиеся в одних и отсутствующие напрочь в других браузерах.
Хуже того — Win8 IE не включает Flash, а Opera Mini все еще не умеет Ajax, что только затрудняет разработку сайтов, так что приходится использовать все больше библиотек — особенно, учитывая тенденцию веб-приложений все больше подражать дестопным. И это тогда, когда и в помине в вебе не существует что-либо похожее на компоненты, на менеджеры раскладки (layout). Почему так бывает, что текст вполне может «вылезти» за пределы своего контейнера? Почему до сих пор нужно «сбрасывать» стили всякими reset.css? Почему надо использовать хаки и не везде в качестве единиц измерения можно использовать проценты?
Вот где настоящая война, а не одних фреймворков с другими. Скорей, сами библиотеки только помогают хоть как не быть заложниками этой войны, делая простые вещи действительно достижимыми, худо-бедно выполняя первый принцип Веба — кроссплатформенность (и кроссбраузерность).

Aingis 14 декабря 2013 в 12:48

+1

> Например, почему мне нужно писать document.getElementsByClassName вместо $(".class"), а затем еще и итерируя, вызывать метод .item(i)?

Во-первых, document надо писать потому что поиск по всему документу. Если вы ищете внутри формы, например, то вам надо указать ноду формы. Во-вторых, есть более простой метод (IE8+!): .querySelectorAll('.class') — тоже самое, что и джейквери только не надо грузить десятки килобайт библиотеки. Всё уже реализовано «нативно».

И кто вам сказал, что обязательно вызывать .item? По-моему, это как раз та штука, которой никто не пользуется. Никто не мешает пользоваться результатом метода как массивом (или вообще превратить его в массив с помощью Array.slice).

> И таки да, теперь мы видим кучу вещей, вроде логотипов и мультиков на «чистом html5 и css3»…

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

> Хуже того — Win8 IE не включает Flash…

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

> …а Opera Mini все еще не умеет Ajax…

Опера мини обладает избирательной поддержкой из-за особенности технологии «тонкого клиента» для самых маломощных устройств. Она и веб-шрифты не поддерживает, и WebGL по очевидным причинам никогда не будет. Тут надо понимать, либо вы делаете сайт для всех, либо с самими навороченными технологиями.

Впрочем, ходят разговоры о таком подходе как «постепенное улучшение», когда самые продвинутые технологии работают там, где поддерживаются.

> И это тогда, когда и в помине в вебе не существует что-либо похожее на компоненты, на менеджеры раскладки (layout).

Вообще уже давно существует: Flexbox — 77% браузеров в том или ином виде, и CSS Grid Layout — тут только IE 10+ и Webkit в начальной стадии, но и технология куда более мощная и требующая тщательной проработки.

> Почему так бывает, что текст вполне может «вылезти» за пределы своего контейнера?

Потому что куда его девать? Вы вообще это всерьёз и вправду не знаете про свойство overflow, управляющее этим поведением? В управлении и сила CSS.

> Почему надо использовать хаки и не везде в качестве единиц измерения можно использовать проценты?

Потому что ничто не совершенно, а проценты считаются относительно чего-то, и не всегда понятно относительно чего считать, как округлять значения до пикселей, и тому подобные вопросы, а острой необходимости в них нет, особенно имея calc() и box-sizing.

> Скорей, сами библиотеки только помогают хоть как не быть заложниками этой войны, делая простые вещи действительно достижимыми, худо-бедно выполняя первый принцип Веба — кроссплатформенность (и кроссбраузерность).

Последние версии браузеров довольно хорошо совместимы, кроме разве что самых последних, ещё не стандартизированных новшеств, и в этом заслуга как раз процесса стандартизации. Проблемы возникают со старыми браузерами, но что вы хотите от моделей, которые вышли до того, как устоялись соответствующие стандарты?

Стимулируйте пользователей переходить на новые версии с помощью «постепенного улучшения» и «изящной деградации» (хотя тут будет правильнее перевести как «рабочей»).
vanfukov 16 декабря 2013 в 17:57

0

Opera Mini не умеет Ajax не все еще, а by design, она же рассчитана на супер-медленный gprs.
- VolCh 24 декабря 2013 в 01:31
  
  0
  
  А разве один из плюсов Аякса не как раз уменьшение трафика? Вместо перезагрузки полностью отрендереренной (на сервере в html) страницы, загружать только изменяющиеся данные?
  - vanfukov 24 декабря 2013 в 10:24
    
    +1
    
    В общем случае конечно уменьшает, но Мини работает с obml-форматом, который она получает от серверов Оперы. Так что результат аякс-запроса всё равно приходит сначала на большой сервер, потом сжимается и только потом попадает в телефон, на котором обновляется вся страница. Но в итоге по трафику получается всё равно выгода. Вот тут, например, можно почитать более детально: dev.opera.com/articles/view/opera-binary-markup-language/
    И плюсом идёт тот факт, что современный жаваскрипт на тех старых телефонах, на которых идёт мини, тормозил бы беспощадно.
НЛО прилетело и опубликовало эту надпись здесь

stansult 12 декабря 2013 в 05:19

+10

Вот к примеру то, что архитекторы CSS пре-процессора сообщают о принципах конструирования Sass:
Не существует формального процесса, по которому мы добавляем новые функции в Sass. Подходящие идеи могут исходить от кого угодно и отовсюду, и мы рады рассмотреть их из списка рассылки, IRC, Twitter, сообщения в блоге, из других компиляторов CSS, или любого другого источника.
…которые, скорее, напоминают Гомера

Автор (John Allsopp) почему-то остановился и не доцитировал :)

Ниже полная цитата — точнее, последние два предложения, одно из которых (в корне меняющее смысл) опущено Джоном:

Good ideas can come from anyone from anywhere and we’re happy to consider them from the mailing list, IRC, twitter, blog posts, other css compilers, or any other source. However, most of the time we end up saying no.

Что переводится:

Подходящие идеи могут исходить от кого угодно и отовсюду, и мы рады рассмотреть их из списка рассылки, IRC, твиттера, блогов, других компиляторов CSS, или любого другого источника. Однако в большинстве случаев мы в конце концов скажем «нет».

dim_s 12 декабря 2013 в 09:37 (комментарий был изменён)

Давайте уясним одну вещь, стандарты нужны были для браузеров, для того чтобы они поддерживали один стандарт рендеринга. С этим то сейчас полно работы. Если препроцессор или язык-транслятор в js могут развиваться без бюрократических процедур принятия стандартов, то JS, CSS, HTML не могут. Поэтому у таких технологий огромное преимущество в развитии. И статья правда похожа на нытье.

Alexeyco 12 декабря 2013 в 10:31

0

Простите, немного не очевидна фраза про то, что JS, CSS, HTML не могут развиваться без бюрократических процедур. Почему у них преимущество?
- dim_s 12 декабря 2013 в 10:47
  
  0
  
  Преимущество не у них (JS, CSS, HTML). Я имел ввиду, что пока примут стандарт, пока браузеры все внедрят, проходит год-два, а трансляторы и компиляторы могут двигаться быстрее в этом смысле.

potan 12 декабря 2013 в 11:00

А чем плоха фрагментация?
Конечно, надо было сразу сделать все по правильному. Но мне нравится, что сосуществуют разные подходы, такие как CoffeeScript и Fay, а не какой-то один фиксированный язык или технология.

Moskus 12 декабря 2013 в 11:09

Занятно, что автор в самом конце упомянул переход от документов и сайтов к приложениям, но ничего не сказал о том, что именно этот переход, по сути, и есть главный источник того, что он называет «потерей Web».
HTML, CSS и JS изначально были и в очень большой степени остаются средствами создания документов (пусть и очень интерактивных теперь), а то, что путем наращивания вокруг них всего перечисленного автором великолепия их удалось заставить быть средствами обеспечивающими визуальное представление и логику приложений — это просто так вышло.

Про зоопарк в UX/UI автор тоже умолчал как-то (это изначально тоже входило в интересы W3C). Хотя технологический зоопарк в Web происходит от специфических требований к UX/UI где-то на половину, а то и на две трети.
Диалектично, что в desktop-приложениях сейчас интерфейсы выглядят на несколько порядков более единообразно, чем в web-приложениях, хотя технически, свободы у desktop-разработчиков «чуть больше». И это всего лишь результат требований заказчиков, а вовсе не технологических обстоятельств.

uvelichitel 12 декабря 2013 в 15:32

VanillaJS framework не содержит консервантов и генномодифицированных продуктов.

Sun_ua 12 декабря 2013 в 16:41

Вспомнилось )

storoj 12 декабря 2013 в 18:43

0

Мне кажется или скриншот какой-то пожухлый? На SO вроде белый фон, а тут как-то серо.
Джипеги выцветают со временем как старые газеты?
- Doktor_Gradus 13 декабря 2013 в 01:14
  
  +2
  
  Скорее, у вас монитор тускнеет.

z6Dabrata 12 декабря 2013 в 16:56

О чем он?

Я каждый день благодарю бразузерных богов:
За то, что мне не нужно помнить что в ie-дивы, а в nn — слои.
Что я могу использовать разные фреймворки для разных задач.
Что я могу написать приложение для своего телефона (или телевизора), плагин для браузера, скрипт для arduino, или серверный код используя одни и те же технологии.
Что каждый раз когда я сохраняю файл в течении 5 секунд я получаю ошибку, если тесты перестают работать хотя бы в одном браузере.
Что все различия в браузерах зорошо задокументированы и даже если я сомневаюсь, что именно сломалось, я могу найти фикс / полифил за 5 минут.
Что я могу писать код используя любой CSS пре-процессор, вкладывать селекторы в селекторы, использовать переменные и миксины.
Что исходные коды большинства браузеров открыты.
Что разработчики осознают, что не время останавливаться и в результате появляются штуки типо этого: extensiblewebmanifesto.org/

Расскажи мне кто-то в конце 90х, о том как все будет сегодня, я бы уже шел искать криогенную камеру.

ViGilant 12 декабря 2013 в 17:40

Меня больше беспокоит, что веб скатывается в бездну картиночек, тупых видео и статусов в социальных сетях

GearHead 12 декабря 2013 в 18:00

+3

а должен быть только код, код, и ещё раз код!
- ViGilant 12 декабря 2013 в 21:14
  
  0
  
  не в том смысле, что код-код-код и ничего кроме кода, а в том смысле, что какая-то деградация наблюдается и это печально
  - up01 14 декабря 2013 в 07:19
    
    0
    
    Дело не в вебе, а в куче «обывателей», которые в нем появились в последние годы.
spmbt 12 декабря 2013 в 18:00

0

Об этом — как раз статья, на которую ссылается автор и часто цитирует: dashes.com/anil/2012/12/the-web-we-lost.html «The Web We Lost», Anil Dash (December 13, 2012)

fogone 12 декабря 2013 в 22:33

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

prijutme4ty 13 декабря 2013 в 04:30

Автор путает серверную сторону и браузерную (а препроцессоры живут, как правило, на сервере). А то во времена старого веба все до единого писали на PHP? Не было ни разных языков, ни разных баз данных?
Кроме того, стоит понимать, что путем нагромождения зоопарка из тысяч библиотек, сообщество отсеет действительно хорошие и универсальные идеи и рано или поздно стандартизует их. Эволюция так и происходит — миллионами мутаций, из которых действительно удачных немного. И вполне возможно, что когда-нибудь jquery-селекторы будут реализованы в ядре javascript. Но на всё нужно время.

VolCh 13 декабря 2013 в 12:34

0

а препроцессоры живут, как правило, на сервере

Разве препроцессоры живут обычно не на дев-машине, а на сервер билд-системой деплоится нормальный html/css/js?

jquery-селекторы будут реализованы в ядре javascript

И что они там будут выбирать? DOM в ядре нет.
- prijutme4ty 13 декабря 2013 в 14:18
  
  0
  
  Это в любом случае не на браузере, пользователь вообще никак не зависит от того, был ли использован less или sass или coffeescript.
  А getElementById тогда где реализован? Вот на этом уровне и можно реализовывать подобную функциональность.
  - VolCh 24 декабря 2013 в 01:39
    
    +1
    
    А getElementById тогда где реализован?
    
    В DOM (переменная document, грубо говоря, в браузере), есть ещё BOM (переменная window) — это вещи к ядру JavaScript не относящиеся. Например, в Node.js их нет.
Vertex 13 декабря 2013 в 15:37

0

Все знают, что плохие программисты будут в аду работать на Perl'e.
- SerafimArts 13 декабря 2013 в 21:28 (комментарий был изменён)
  
  0
  
  на 1с, говорят, можно сатану вызвать: сатана()

zw0rk 22 декабря 2013 в 02:05

А вот (почти) противоположная точка зрения, что всё хорошо.

anreyyyy 11 декабря 2013 в 17:48

+58

Хватит ныть!
- AlexTest 12 декабря 2013 в 02:57 (комментарий был изменён)
  
  +15
  
  Порог вхождения в современный зоопарк веб-технологий от самих методик разработки до конкретных инструментов все выше.
  Зарплаты сеньоров все заоблачнее — и это не может не радовать (сарказм)!
  Никаких KISS — только фреймворки генерирующие фреймворки на все случаи жизни!
  А в итоге все как на картинке:
- AVGUR 12 декабря 2013 в 09:38
  
  0
  
  Поддержу.
  Потеряли, Потеряли… как по мне мы приобрели нечто новое, причем в таком количестве, что это только радует.
Zippovich 11 декабря 2013 в 17:57

+25

Раньше люди думали что земля плоская и держится на 3-х китах. Потом — БАЦ — и земля круглая — и даже не в центре вселенной, появилось много разнообразных телескопов, и трудно даже выбрать из всего разнообразия какой тебе подходит — делают они одно и то же, только немного по разному.
Мы фрагментировали и усложнили свое представление о мире. Мы потеряли тот мир! RIP!
- dikkini 11 декабря 2013 в 18:00
  
  0
  
  И сколько ты не изучай космос и технологии для его изучения, всегда придут новые технологии, которые дадут новые знания о новых объектах и тебе опять придется лезть глубже и глубже в этот стек технологиях. А раньше как все просто было…
  - Zippovich 11 декабря 2013 в 18:05
    
    +2
    
    просто не было — была куча несовместимых друг с другом технологий, которые не стандартизировались.
    сейчас есть стандарты и надстройки над ними — их можно пользовать, можно не пользовать — ну да, работают они по разному, но и решают в основном свои цели (jquery — для простоты, angular — для сложных js приложений, которые работают вживую). Но что в этом богатстве выбора плохого, я так и не понял из статьи. Ведь это всего надстройки, стандарт един.
    - dikkini 11 декабря 2013 в 20:37
      
      0
      
      *Не надо забывать скрытный тег *
    - VolCh 12 декабря 2013 в 01:59
      
      +3
      
      Но что в этом богатстве выбора плохого, я так и не понял из статьи. Ведь это всего надстройки, стандарт един.
      
      Всё больше народу, который не знает стандарт, а знает лишь свои любимые фреймворки и библиотеки. Скажем, jQuery-программист раньше было шуткой, а теперь реальность. Для поддержки проекта на angular, человеку, писавшему только на jquery, мало поможет его опыт — придется изучать практически всё с нуля.
      - Zippovich 12 декабря 2013 в 17:20
        
        0
        
        у таких людей плохая карма
shambho 11 декабря 2013 в 18:57 (комментарий был изменён)

+5

Web-технологии стали заложниками собственной «стабильности» — они уже давно не удовлетворяют современным потребностям, как по функциональности, так и по программированию оных. Ностальнические технологии «того веба» являются узким местом, которое не решаются реформировать как раз апологеты «совместимости». Но, по-видимому, количество несуразностей ещё не перешло в качественное решение все это разгрести. Опыт HTML5 показывает, что если найдется хороший «локомотив», то остальные дружно согласятся присоединиться к современному поезду.
- Aingis 14 декабря 2013 в 14:33
  
  0
  
  Потребности или спрос всегда опережает предложение, это норма. Обратная совместимость — реальность, никто не будет пользоваться браузером, в котором ломается половина сайтов. Поэтому Опера, кстати, и сменила движок, хотя в ней ломалось гораздо меньше сайтов.
  
  Сайтов, написанных с соблюдением всех стандартов — малая часть, большинство написано абы как плохо разбирающимися людьми, даже здесь отметились неспециалисты, которые всё туда же, ринулись критиковать стандарты, даже не будучи знакомы с ними. Опять же эти сайты никем не поддерживаются, иначе бы они были уже попросту переписаны, и они сломаются, стоит отбросить обратную совместимость.
zag2art 11 декабря 2013 в 19:44

+13
Alexey2005 11 декабря 2013 в 19:45

+22

К сожалению, в W3C сидят не инопланетяне с Сириуса, а те же самые умники, которые занимались браузерными войнами. Можно смело считать, что войны не закончились, а просто перешли в затяжную позиционную фазу. Там по-прежнему каждый тянет одеяло в свою сторону. По-прежнему считают необязательным выполнять предписания совместно принятого стандарта. По-прежнему добавляют вендорные префиксы, особенности реализации. По-прежнему сперва реализовывают в браузерах, а потом ставят всех перед фактом и протаскивают в качестве стандарта.
Причём похоже на то, что во всём W3C нет ни одного верстальщика. Я даже не уверен, что там есть программисты — скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки. Ничем иным просто не объяснить тот факт, что W3C принимает самые дикие, идиотские, неудобные решения, тогда как наиболее типичные случаи вёрстки и программирования до сих пор не покрыты (уже сколько лет самый популярный вопрос юных верстальщиков — «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны». W3C, ау, вы там совсем что ли лыка не вяжете?). Отсюда и получается:

Мы фрагментировали JavaScript языками, компилируемыми в него.
Мы фрагментировали HTML тоннами шаблонизаторов.
Мы фрагментировали CSS препроцессорами наподобие Sass и Less
Продукция W3C неюзабельна до такой степени, что приходится придумывать нечто более удобное.
- zag2art 11 декабря 2013 в 19:47
  
  0
  
  > скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки
  
  Улыбнуло :)
- SerafimArts 12 декабря 2013 в 15:06
  
  +1
  
  как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны
  
  Всё же элементарно! Оборачиваете div в элемент с disply: table-cell;, этот элемент в другой с dsiplay: table;, к внутреннему применяете vertical-align: middle;, а к нужному диву disply: inline-block; и вуаля! Всего пара часов потраченного в пустую времени и уже почти рабочий вариант выравнивания по середине =)
  - SerafimArts 12 декабря 2013 в 23:37
    
    0
    
    Кстати, грамматика прямо пропорциональна качеству такого решения ;)
  - Aingis 14 декабря 2013 в 11:37
    
    0
    
    Вообще во флексбоксе ещё проще:
    .container {
    display: flex;
    align-content: center;
    }
    www.w3.org/TR/css3-flexbox/#align-content
- kiselev_dv 12 декабря 2013 в 16:46
  
  +2
  
  Пользуясь случаем, хотел спросить у верстальщиков, почему табличная верстка это чуть ли не табу в современном вэбе?
  
  То есть я понимаю все прелести идеи «HTML отражает структуру, css отвечает за отображение» и то что таблицы смешивают отображение и структуру данных что эту идею ломает.
  
  Но почему обернуть текст в 3 дива не имеющих отношения к логике данных — это неизбежная жертва, а обернуть тот же текст в td, tr ,table — это как пукнуть в лифте?
  - irium 12 декабря 2013 в 17:25
    
    0
    
    Но почему обернуть текст в 3 дива не имеющих отношения к логике данных — это неизбежная жертва, а обернуть тот же текст в td, tr ,table — это как пукнуть в лифте?
    
    Плюсую. Тоже до сих пор этого не понимаю.
  - spmbt 12 декабря 2013 в 17:29
    
    0
    
    У вёрстки на таблицах много особенностей в крайних случаях представления контента (пустые ячейки, диспропорции в заполнении ячеек). При использовании таблиц как каркаса придётся свести их использование к строго ограниченным формам (насколько помню, только одна ячейка в ширину, иначе вылезают краевые особенности). Я это проходил в 2010-м, в новых браузерах могло что-то измениться, но старые всё равно их имеют. Кроме того, дивы гибче в переставлении блоков средствами CSS, хотя тоже не на 100% гибкие.
    - НЛО прилетело и опубликовало эту надпись здесь
  - GearHead 12 декабря 2013 в 17:58
    
    0
    
    всё просто. попробуйте перенести сайдбар (скажем, с левой стороны в правую) с помощью одного только CSS в табличной вёрстке и в блочной.
    - kiselev_dv 12 декабря 2013 в 18:20
      
      0
      
      Ясно-понятно что одним css для таблички не обойдешься. Но на блочной, как правило дело так же не ограничивается изменением float или заменой left:5px на right:5px. Тут же выясняется что надо обернуть сайдбар и контент в еще один див, т.к. справа ему хватало относительно позиционированного родителя, а слева уже нет и т.п. И на практике это выливается в то что вам все-равно надо меня шаблон и переносить вывод дочерних элементов в другое место.
      
      Сатанинский смех, а потом вы узнаете что ваш клиент — гос контора которая использует какой-нибудь ужас и ничем другим кроме шестого эксплорера пользоваться не может.
      - GearHead 12 декабря 2013 в 18:34
        
        0
        
        на практике выливается, что чем опытнее верстальщик, тем лаконичнее вёрстка (без лишних оборачивающих дивов). а чем лаконичнее вёрстка, тем меньше изменений нужно для модификации. а табличную вёрстку лаконичной никогда не назовёшь.
        
        и это я уже не буду говорить про адаптивность, которая является банальным проявлением уважения к пользователям, и которую табличной вёрсткой вы не получите.
        
        и это я уже и не говорю о том, что идейно разметка должна разбивать сайт на смысловые части, а их вид должен абстрагироваться от самих данных, чего табличная вёрстка не даёт.
        
        Perez 18 декабря 2013 в 00:09
        
        0
        
        По моему адаптивность слегка переоценивается в последнее время. Мне думается что один большой и сложный шаблон под всё сразу куда менее технологичен чем пара тройка простых с заточкой под конкретные задачи.
    - Aingis 14 декабря 2013 в 11:44
      
      0
      
      Если у вас стандартная трёхколоночная раскладка (или двухколоночная), то довольно просто:
      table { direction: rtl }
      th, td { direction: ltr }
      в предположении, что у вас сайт на языке, пишущемся слева направо. (Впрочем, иначе вы бы знали о свойстве direction.)
      - НЛО прилетело и опубликовало эту надпись здесь
        
        Aingis 17 декабря 2013 в 23:32
        
        0
        
        Это да, я так в статье «Основные способы вёрстки» и писал.
  - fatal 13 декабря 2013 в 01:30
    
    0
    
    Чем отличается DIV от TABLE? Семантика — наше всё! :) Ну и современные браузеры уже позволяют DIV-ы собрать как таблицу (выше пример привели).
    - НЛО прилетело и опубликовало эту надпись здесь
- kiselev_dv 12 декабря 2013 в 18:06
  
  0
  
  В поддержку треда о стандартах W3C и практике.
  
  Попробуйте на досуге указать в xsd что вам нужен набор дочерних элементов встречающихся в любом порядке но с ограничениями на количество. Казалось-бы самый простой вариант.
  
  К примеру нижеприведенные элементы могут следовать в любом порядке но лишь указанное количество раз:
  <optinal/> — может встречаться 0 или 1 раз
  <optinal-multy/> — может встречаться 0 раз и более
  <required/> — строго 1 раз
  <required-multy/> — 1 раз и более
  
  С математической точки зрения стандарт полон. Т.е. задать такие ограничения можно. Но на практике это выливается в решение задачек по комбинаторике и записи чуть ли не всех возможных комбинаций sequence и choice.
- NekR 13 декабря 2013 в 11:25
  
  +2
  
  > (уже сколько лет самый популярный вопрос юных верстальщиков — «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны». W3C, ау, вы там совсем что ли лыка не вяжете?). Отсюда и получается:
  
  display: flex;
  align-items: center;
  
  В современных браузерах работает очень хорошо.
- Aingis 14 декабря 2013 в 12:04
  
  +2
  
  > Можно смело считать, что войны не закончились, а просто перешли в затяжную позиционную фазу. Там по-прежнему каждый тянет одеяло в свою сторону.
  
  Верно, каждый отстаивает свои интересы, однако, сторонам вполне удаётся договориться, учтя все стороны вопроса. Быстро хорошо не бывает.
  
  > По-прежнему добавляют вендорные префиксы, особенности реализации.
  
  Файрфокс и Хром уже отказались от добавления новых префиксов и перешли к модели включения экспериментальных свойств за флагами.
  
  > По-прежнему сперва реализовывают в браузерах, а потом ставят всех перед фактом и протаскивают в качестве стандарта.
  
  Действительно такое бывает, когда вводится что-то совершенно новое, но по какой-то причине нужное вендору. Однако, для в таких случаях, во-первых, как раз есть ограждающие префиксы. Во-вторых, все понимают, что нестандартную фичу никто не будет поддерживать, и поэтому выдвигают предложение на стандартизацию. А иногда даже помогают с реализацией. Просто так протянуть стандарт не получится, одно из требований на звание стандарта: наличие двух независимых реализации, и в любом случае пройдёт длительный процесс обсуждения со всеми заинтересованными сторонами.
  
  > Причём похоже на то, что во всём W3C нет ни одного верстальщика.
  
  Есть и не один. Правда, участники довольно продвинуты, они не просто верстальщики, а знают яваскрипт и многое другое.
  
  > Я даже не уверен, что там есть программисты — скорее всего стандартами заведуют очень странные личности, бесконечно далёкие от Web-разработки.
  
  И программисты есть, например, активно принимает участие Дэвид Барон — главный программист из Мозиллы. Кстати именно они не дают протащить в стандарт сложнореализуемые потенциально тормозные штуки вроде селектора вложенного элемента.
  
  > «как центрировать DIV по высоте контейнера, если размеры ни DIV'а, ни этого контейнера неизвестны»
  
  Вопрос уже решён во флексбоксе и уже есть в том или ином виде в 77% браузеров, написал выше:
  habrahabr.ru/post/205692/#comment_7097346
  
  > Отсюда и получается:…
  
  Как справедливо отметили ниже, это вообще серверная сторона. Что творится на сервере — ваше дело. Клиенту отдаётся всё тот же HTML, CSS и JS.
  
  > Продукция W3C неюзабельна до такой степени, что приходится придумывать нечто более удобное.
  
  Всё прекрасно используемо, просто вы хотите странного. Я, так, вообще не вижу смысла в препроцессорах. Переменные? Уже есть спецификация, и она даже начал внедряться в Файрфоксе. Префиксы? Старая песня, от них уже отказываются. Миксины? Перечесление селекторов через запятую никто не отменял, впрочем и они будут в следующей версии спецификации.
  
  Да это не быстрый процесс, потому что стандартизация затрагивает множество участников и каждому даётся возможность принять участие, вдобавок, браузерам тоже нужно время на внедрение и обратную связь, но процесс идёт медленно, но верно.
  - НЛО прилетело и опубликовало эту надпись здесь
    - Aingis 17 декабря 2013 в 23:27
      
      0
      
      Всё верно, @viewport, предложенный Оперой призван заменить мету. Есть даже реализации в IE10, в Опере на Presto, вроде, в Хромиуме тоже есть. Но, конечно, до полного внедрения далеко. Однако, про спецификацию помнят.
      - НЛО прилетело и опубликовало эту надпись здесь
Gorthauer87 11 декабря 2013 в 20:05

+1

Обычный процесс эволюции. Что в нём страшного? Лучше уж жить в живом хаосе, чем в мёртвой золотой клетке.
orcy 11 декабря 2013 в 20:38 (комментарий был изменён)

+3

На этом пути не надо ограничеватся только клиентским вебом! И сервера мы тоже теряем, смотрите какой беспредел: питон, руби, node.js, asp.net mvc, еще и по нескольку фреймворков у каждого. Нужно вернутся к теплому ламповому PHP (или CGI + bash?) и перестать фрагментировать сервера. Десктопы тоже надо прекращать фрагметировать, не нужно это. Есть же C и Win32 API, зачем этим MFC, WTL, Qt, .NET WinForms, WPF, Java. Переусложения какие-то.

Может автор просто постебал жалобы вроде «веб уже не торт», а я просто не понял.
- bigfatbrowncat 12 декабря 2013 в 10:31
  
  +1
  
  Возможно, автор имел в виду немного другое: на протяжении 5-6 лет усиленной стандартизации разработка под Web становилась всё проще и проще. Но в какой-то момент она снова начала становиться сложнее. И это его удручает.
  - Alexeyco 12 декабря 2013 в 10:35
    
    0
    
    Все равно, больше похоже на то, что автору кто-то испортил настроение и он решил выместить свои переживания в форме статьи «как же стало хреново». На мой взгляд, ну да, вроде (теоретически) все по делу. Но с другой стороны, читаешь и думаешь «ну и что». Ну пишут авторы фреймворки, которые немодульные и несовместимые. Ну никто ж не запрещает взять то, что у них, и сделать это модульным. К примеру, мне бы хотелось иметь шлем, подключенный к компьютеру, чтобы я думал — а оно само код генерировало. Но такого шлема нет. А мне страсть, как хотелось бы. Должен ли я написать статью о том, что все плохо?
    - Lendon 13 декабря 2013 в 01:42
      
      0
      
      Шлем это мечта… Можно было бы писать код прямо в транспорте, засунув руки в карманы.
  - zw0rk 16 декабря 2013 в 15:38
    
    0
    
    Может просто потому что бизнес заметил, что предыдущие задачи делаются просто и можно усложнять задачу? Реактивный манифест, к примеру, это ведь усложнение задачи, которое пока требует более сложных решений.
ImLiar 12 декабря 2013 в 00:50

–7

Вся суть поста:
— Вот вам нормальные инструменты вместо этих обрезков технологий для разметки текста
— Нет, хотим дальше жрать говно ложками.
- Aux 12 декабря 2013 в 15:40
  
  +1
  
  Инструментов как раз никто не даёт, дают только ложки с разным оформлением и размерами. Кто-то выбирает большую золотую ложку, кто-то маленькую люминевую, но говно жрут все.
  
  Правильный посыл был бы перестать жрать говно, а не обсуждать ложки.
Lure_of_Chaos 12 декабря 2013 в 02:46

+13

А я верю, что разнообразие — суть эволюции. Да, многие технологии недолговечны, но если они умирают, то они непригодны, и не стоит их содержать на искусственном дыхании. Например, почему мне нужно писать document.getElementsByClassName вместо $(".class"), а затем еще и итерируя, вызывать метод .item(i)? Ведь не составило бы большого труда примерно ту же фунцкциональность таких фреймворков, как jQuery, реализовать нативно. Просто необходимо вдумчиво рассмотреть существующие решения и осторожно их слить во что-то лучшее, при этом минимально, но верно отходя от пережитков — не боясь обратной совместимости. Ведь сейчас никто не напишет document.all['item'].
Почему даже теперь (если я не отстаю от жизни) в CSS нет наследования и примесей, это до сих пор вынуждены делать те же LESS и SASS. Зато появились излишние навороты вроде анимаций, которые, на мой взгляд, больше инкапсулируют (и тщательно от нас скрывают) довольно сложную логику под «разметкой» — и в целом это все очень сильно напоминают стремления инноваций предложить нам две-три кнопки «сделать збс», вместо действительно логично нужных вещей.
И таки да, теперь мы видим кучу вещей, вроде логотипов и мультиков на «чистом html5 и css3», исходник которых еще менее очевиден, чем будучи напсан на js. Но нужно ли это, если теперь без js не будут работать сколь серьезные сайты, а _некоторые_ браузеры вообще выпиливают настройки «запретить js»? Это как гламур — впечатляет, но не насущно.
И если раньше мы имели браузерную войну Netscape\IE\Opera с надписями «best viewed in IE6 800x600», то теперь HTML5 сам раздробился на подмножество себя, и мы, как никогда раньше, имеем фичи, имеющиеся в одних и отсутствующие напрочь в других браузерах.
Хуже того — Win8 IE не включает Flash, а Opera Mini все еще не умеет Ajax, что только затрудняет разработку сайтов, так что приходится использовать все больше библиотек — особенно, учитывая тенденцию веб-приложений все больше подражать дестопным. И это тогда, когда и в помине в вебе не существует что-либо похожее на компоненты, на менеджеры раскладки (layout). Почему так бывает, что текст вполне может «вылезти» за пределы своего контейнера? Почему до сих пор нужно «сбрасывать» стили всякими reset.css? Почему надо использовать хаки и не везде в качестве единиц измерения можно использовать проценты?
Вот где настоящая война, а не одних фреймворков с другими. Скорей, сами библиотеки только помогают хоть как не быть заложниками этой войны, делая простые вещи действительно достижимыми, худо-бедно выполняя первый принцип Веба — кроссплатформенность (и кроссбраузерность).
- Aingis 14 декабря 2013 в 12:48
  
  +1
  
  > Например, почему мне нужно писать document.getElementsByClassName вместо $(".class"), а затем еще и итерируя, вызывать метод .item(i)?
  
  Во-первых, document надо писать потому что поиск по всему документу. Если вы ищете внутри формы, например, то вам надо указать ноду формы. Во-вторых, есть более простой метод (IE8+!): .querySelectorAll('.class') — тоже самое, что и джейквери только не надо грузить десятки килобайт библиотеки. Всё уже реализовано «нативно».
  
  И кто вам сказал, что обязательно вызывать .item? По-моему, это как раз та штука, которой никто не пользуется. Никто не мешает пользоваться результатом метода как массивом (или вообще превратить его в массив с помощью Array.slice).
  
  > И таки да, теперь мы видим кучу вещей, вроде логотипов и мультиков на «чистом html5 и css3»…
  
  Такие эксперименты обычно не являются хорошими практиками, а наоборот большим извратом. Тем не менее они представляют возможность изучить какую-то технологию лучше, особенно если вы не понимаете, как они работают.
  
  > Хуже того — Win8 IE не включает Flash…
  
  Флеш ни имеет ни малейшего отношения к стандартам кроме того, что он побудил написать новые для функций, недоступных ранее в браузерах. Сейчас практически всё что можно было сделать на флеше можно сделать и в браузерах (правда, не во всех, только в новых).
  
  > …а Opera Mini все еще не умеет Ajax…
  
  Опера мини обладает избирательной поддержкой из-за особенности технологии «тонкого клиента» для самых маломощных устройств. Она и веб-шрифты не поддерживает, и WebGL по очевидным причинам никогда не будет. Тут надо понимать, либо вы делаете сайт для всех, либо с самими навороченными технологиями.
  
  Впрочем, ходят разговоры о таком подходе как «постепенное улучшение», когда самые продвинутые технологии работают там, где поддерживаются.
  
  > И это тогда, когда и в помине в вебе не существует что-либо похожее на компоненты, на менеджеры раскладки (layout).
  
  Вообще уже давно существует: Flexbox — 77% браузеров в том или ином виде, и CSS Grid Layout — тут только IE 10+ и Webkit в начальной стадии, но и технология куда более мощная и требующая тщательной проработки.
  
  > Почему так бывает, что текст вполне может «вылезти» за пределы своего контейнера?
  
  Потому что куда его девать? Вы вообще это всерьёз и вправду не знаете про свойство overflow, управляющее этим поведением? В управлении и сила CSS.
  
  > Почему надо использовать хаки и не везде в качестве единиц измерения можно использовать проценты?
  
  Потому что ничто не совершенно, а проценты считаются относительно чего-то, и не всегда понятно относительно чего считать, как округлять значения до пикселей, и тому подобные вопросы, а острой необходимости в них нет, особенно имея calc() и box-sizing.
  
  > Скорей, сами библиотеки только помогают хоть как не быть заложниками этой войны, делая простые вещи действительно достижимыми, худо-бедно выполняя первый принцип Веба — кроссплатформенность (и кроссбраузерность).
  
  Последние версии браузеров довольно хорошо совместимы, кроме разве что самых последних, ещё не стандартизированных новшеств, и в этом заслуга как раз процесса стандартизации. Проблемы возникают со старыми браузерами, но что вы хотите от моделей, которые вышли до того, как устоялись соответствующие стандарты?
  
  Стимулируйте пользователей переходить на новые версии с помощью «постепенного улучшения» и «изящной деградации» (хотя тут будет правильнее перевести как «рабочей»).
- vanfukov 16 декабря 2013 в 17:57
  
  0
  
  Opera Mini не умеет Ajax не все еще, а by design, она же рассчитана на супер-медленный gprs.
  - VolCh 24 декабря 2013 в 01:31
    
    0
    
    А разве один из плюсов Аякса не как раз уменьшение трафика? Вместо перезагрузки полностью отрендереренной (на сервере в html) страницы, загружать только изменяющиеся данные?
    - vanfukov 24 декабря 2013 в 10:24
      
      +1
      
      В общем случае конечно уменьшает, но Мини работает с obml-форматом, который она получает от серверов Оперы. Так что результат аякс-запроса всё равно приходит сначала на большой сервер, потом сжимается и только потом попадает в телефон, на котором обновляется вся страница. Но в итоге по трафику получается всё равно выгода. Вот тут, например, можно почитать более детально: dev.opera.com/articles/view/opera-binary-markup-language/
      И плюсом идёт тот факт, что современный жаваскрипт на тех старых телефонах, на которых идёт мини, тормозил бы беспощадно.
- НЛО прилетело и опубликовало эту надпись здесь
stansult 12 декабря 2013 в 05:19

+10

Вот к примеру то, что архитекторы CSS пре-процессора сообщают о принципах конструирования Sass:
Не существует формального процесса, по которому мы добавляем новые функции в Sass. Подходящие идеи могут исходить от кого угодно и отовсюду, и мы рады рассмотреть их из списка рассылки, IRC, Twitter, сообщения в блоге, из других компиляторов CSS, или любого другого источника.
…которые, скорее, напоминают Гомера
Автор (John Allsopp) почему-то остановился и не доцитировал :)

Ниже полная цитата — точнее, последние два предложения, одно из которых (в корне меняющее смысл) опущено Джоном:
Good ideas can come from anyone from anywhere and we’re happy to consider them from the mailing list, IRC, twitter, blog posts, other css compilers, or any other source. However, most of the time we end up saying no.
Что переводится:
Подходящие идеи могут исходить от кого угодно и отовсюду, и мы рады рассмотреть их из списка рассылки, IRC, твиттера, блогов, других компиляторов CSS, или любого другого источника. Однако в большинстве случаев мы в конце концов скажем «нет».
dim_s 12 декабря 2013 в 09:37 (комментарий был изменён)

0

Давайте уясним одну вещь, стандарты нужны были для браузеров, для того чтобы они поддерживали один стандарт рендеринга. С этим то сейчас полно работы. Если препроцессор или язык-транслятор в js могут развиваться без бюрократических процедур принятия стандартов, то JS, CSS, HTML не могут. Поэтому у таких технологий огромное преимущество в развитии. И статья правда похожа на нытье.
- Alexeyco 12 декабря 2013 в 10:31
  
  0
  
  Простите, немного не очевидна фраза про то, что JS, CSS, HTML не могут развиваться без бюрократических процедур. Почему у них преимущество?
  - dim_s 12 декабря 2013 в 10:47
    
    0
    
    Преимущество не у них (JS, CSS, HTML). Я имел ввиду, что пока примут стандарт, пока браузеры все внедрят, проходит год-два, а трансляторы и компиляторы могут двигаться быстрее в этом смысле.
potan 12 декабря 2013 в 11:00

0

А чем плоха фрагментация?
Конечно, надо было сразу сделать все по правильному. Но мне нравится, что сосуществуют разные подходы, такие как CoffeeScript и Fay, а не какой-то один фиксированный язык или технология.
Moskus 12 декабря 2013 в 11:09

0

Занятно, что автор в самом конце упомянул переход от документов и сайтов к приложениям, но ничего не сказал о том, что именно этот переход, по сути, и есть главный источник того, что он называет «потерей Web».
HTML, CSS и JS изначально были и в очень большой степени остаются средствами создания документов (пусть и очень интерактивных теперь), а то, что путем наращивания вокруг них всего перечисленного автором великолепия их удалось заставить быть средствами обеспечивающими визуальное представление и логику приложений — это просто так вышло.

Про зоопарк в UX/UI автор тоже умолчал как-то (это изначально тоже входило в интересы W3C). Хотя технологический зоопарк в Web происходит от специфических требований к UX/UI где-то на половину, а то и на две трети.
Диалектично, что в desktop-приложениях сейчас интерфейсы выглядят на несколько порядков более единообразно, чем в web-приложениях, хотя технически, свободы у desktop-разработчиков «чуть больше». И это всего лишь результат требований заказчиков, а вовсе не технологических обстоятельств.
uvelichitel 12 декабря 2013 в 15:32

0

VanillaJS framework не содержит консервантов и генномодифицированных продуктов.
Sun_ua 12 декабря 2013 в 16:41

+8

Вспомнилось )
- storoj 12 декабря 2013 в 18:43
  
  0
  
  Мне кажется или скриншот какой-то пожухлый? На SO вроде белый фон, а тут как-то серо.
  Джипеги выцветают со временем как старые газеты?
  - Doktor_Gradus 13 декабря 2013 в 01:14
    
    +2
    
    Скорее, у вас монитор тускнеет.
z6Dabrata 12 декабря 2013 в 16:56

0

О чем он?

Я каждый день благодарю бразузерных богов:
За то, что мне не нужно помнить что в ie-дивы, а в nn — слои.
Что я могу использовать разные фреймворки для разных задач.
Что я могу написать приложение для своего телефона (или телевизора), плагин для браузера, скрипт для arduino, или серверный код используя одни и те же технологии.
Что каждый раз когда я сохраняю файл в течении 5 секунд я получаю ошибку, если тесты перестают работать хотя бы в одном браузере.
Что все различия в браузерах зорошо задокументированы и даже если я сомневаюсь, что именно сломалось, я могу найти фикс / полифил за 5 минут.
Что я могу писать код используя любой CSS пре-процессор, вкладывать селекторы в селекторы, использовать переменные и миксины.
Что исходные коды большинства браузеров открыты.
Что разработчики осознают, что не время останавливаться и в результате появляются штуки типо этого: extensiblewebmanifesto.org/

Расскажи мне кто-то в конце 90х, о том как все будет сегодня, я бы уже шел искать криогенную камеру.
ViGilant 12 декабря 2013 в 17:40

0

Меня больше беспокоит, что веб скатывается в бездну картиночек, тупых видео и статусов в социальных сетях
- GearHead 12 декабря 2013 в 18:00
  
  +3
  
  а должен быть только код, код, и ещё раз код!
  - ViGilant 12 декабря 2013 в 21:14
    
    0
    
    не в том смысле, что код-код-код и ничего кроме кода, а в том смысле, что какая-то деградация наблюдается и это печально
    - up01 14 декабря 2013 в 07:19
      
      0
      
      Дело не в вебе, а в куче «обывателей», которые в нем появились в последние годы.
- spmbt 12 декабря 2013 в 18:00
  
  0
  
  Об этом — как раз статья, на которую ссылается автор и часто цитирует: dashes.com/anil/2012/12/the-web-we-lost.html «The Web We Lost», Anil Dash (December 13, 2012)
fogone 12 декабря 2013 в 22:33

+1

Если бы стандарт, который я придумал всё время пытались допились, я бы серьезно призадумался над его качеством, удобством и соответствием нуждам.
prijutme4ty 13 декабря 2013 в 04:30

0

Автор путает серверную сторону и браузерную (а препроцессоры живут, как правило, на сервере). А то во времена старого веба все до единого писали на PHP? Не было ни разных языков, ни разных баз данных?
Кроме того, стоит понимать, что путем нагромождения зоопарка из тысяч библиотек, сообщество отсеет действительно хорошие и универсальные идеи и рано или поздно стандартизует их. Эволюция так и происходит — миллионами мутаций, из которых действительно удачных немного. И вполне возможно, что когда-нибудь jquery-селекторы будут реализованы в ядре javascript. Но на всё нужно время.
- VolCh 13 декабря 2013 в 12:34
  
  0
  
  а препроцессоры живут, как правило, на сервере
  
  Разве препроцессоры живут обычно не на дев-машине, а на сервер билд-системой деплоится нормальный html/css/js?
  
  jquery-селекторы будут реализованы в ядре javascript
  
  И что они там будут выбирать? DOM в ядре нет.
  - prijutme4ty 13 декабря 2013 в 14:18
    
    0
    
    Это в любом случае не на браузере, пользователь вообще никак не зависит от того, был ли использован less или sass или coffeescript.
    А getElementById тогда где реализован? Вот на этом уровне и можно реализовывать подобную функциональность.
    - VolCh 24 декабря 2013 в 01:39
      
      +1
      
      А getElementById тогда где реализован?
      
      В DOM (переменная document, грубо говоря, в браузере), есть ещё BOM (переменная window) — это вещи к ядру JavaScript не относящиеся. Например, в Node.js их нет.
- Vertex 13 декабря 2013 в 15:37
  
  0
  
  Все знают, что плохие программисты будут в аду работать на Perl'e.
  - SerafimArts 13 декабря 2013 в 21:28 (комментарий был изменён)
    
    0
    
    на 1с, говорят, можно сатану вызвать: сатана()
zw0rk 22 декабря 2013 в 02:05

0

А вот (почти) противоположная точка зрения, что всё хорошо.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.