Jump to content

Расширение языка HTML


smevok239
 Share

Recommended Posts

Максимка, давай, не покачай, сделай их всех! :D

А то накинулись всем скопом... :devil:

Погодите немного, пойду схожу за попкорном :)

К сожалению, я боюсь, что ты опоздал где-то на сутки... походу уже всё закончилось :(

Link to comment
Share on other sites

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

Золотые слова. Я добавлю, что после всего, что новый человек добавил, должен быть минимальный шанс, что все поломается.

Link to comment
Share on other sites

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

Золотые слова. Я добавлю, что после всего, что новый человек добавил, должен быть минимальный шанс, что все поломается.

А я разве где-то сказал, что я не согласен? Я абсолютно согласен с Рашидом. Поддерживаю! Но вы меня не поняли. Я не советовал юзать переменные на всё и вся. Я говорил про те проекты, где это разрешено, и что использовать их надо тоже с умом. Я лично в своих визитках найду местечко переменным, а вы нет? Ну и не надо, никто ж не наставивает :)

Link to comment
Share on other sites

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

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

Link to comment
Share on other sites

А давайте поговорим, зачем вообще ЯП-ам переменные и как программисты, бедные, живут и каждый день в них путаются. Хотя да, я же забыл, верстальщики много раз тупее, чем программисты :yahoo:

Link to comment
Share on other sites

А давайте поговорим, зачем вообще ЯП-ам переменные и как программисты, бедные, живут и каждый день в них путаются. Хотя да, я же забыл, верстальщики много раз тупее, чем программисты :yahoo:

CSS не ЯП.

Link to comment
Share on other sites

Great Rash, s0rr0w, Братва, я всё обдумал и пришёл к выводу, что в ваших словах отчасти нет логики, поэтому продолжим нашу беседу...

Рашид:

Ты не понял. Вот представь ситуацию: есть проект А, он развивается уже 3 года.

3 года назад пришел ты, написал там все круто и красиво с ресетом сверху. Потом ты нашел работу получше и уволился.

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

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

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

Согласен, но погоди, есть вещи, которые априори ДОЛЖНЫ идти ПЕРЕД основным кодом или хотя бы перед Целью! Вот переменные относятся именно к таким вещам. Вот так они устроены, что ж тут поделать... мне очень жаль :facepalmxd: Если у вас тайный проект, то тогда вам их просто лучше НЕ юзать, вот и всё, в противном случае следующее утверждение В корне не верно именно у тебя:

Поэтому то что ты говоришь (объявления переменных только вначале и т.п.) в корне неправильно.

А где по твоему логичнее будет использовать переменные? Я вижу только три места в коде, где они могут идти:

1. В отдельной таблице стилей первой.

2. Наверху основной таблице стилей.

3. В секциях блоков в начале.

Я не прав?

Саш:

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

Да что ж так сразу пессимистично-то? Я юзаю ресет уже три года, ни разу проблем не было. А потом вы мыслите не теми категориями. Это CSS, Саш, и переменные в нём != переменным в ЯП.

Link to comment
Share on other sites

Вот это я считаю тупостью. Как может придти Вася через три года и взять в руки проект, о котором он ничего не знает? Это чушь какая-та, что ж это за организация такая??

Приходи ко мне, я тебе покажу проект, про который ты однозначно ничего знать не будешь.

А почему бы кому-то из команды не сообщить Васе, что на проекте используется ресет, который лежит в отдельной таблице и подключён первым? Или это какая-та тайная организация, где не разрешается выдавать тайны?)))

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

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

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

А где по твоему логичнее будет использовать переменные? Я вижу только три места в коде, где они могут идти:

1. В отдельной таблице стилей первой.

2. Наверху основной таблице стилей.

3. В секциях блоков в начале.

1. Ты забываешь, что таблиц стилей в одном документе может быть больше чем одна.

2. Нет понятия "основная таблица стилей"

3. Каких таких блоков?

Это CSS, Саш, и переменные в нём != переменным в ЯП.

Так я про это и говорю, что это не тождественные понятия

Link to comment
Share on other sites

И что? Т.е. если ЯП - не путаются, а если не ЯП - сразу путаться начинают?

Проблема в том, что из CSS пытаются сделать недоЯП. Я считаю, что это очень плохо и ненужно. У CSS очень много других проблем, которые намного важнее чем отсутствие анимации и переменных. Их и надо решать. Но вместо этого CSS пытаются превратить в фарш, а люди этому только радуются, интернеты пестрят примерами анимированных меню, мол "смотрите как круто" и все радостно кричат "ура!". Я считаю что в долгосрочной перспективе это приведет к проблемам, которые есть сейчас у HTML.

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

Верстальщики много раз тупее чем программисты. Объясню почему: не так давно умные люди пытались ввести XHTML, который был бы жестко формализован (шаг влево, шаг вправо, забыл кавычку и страница просто не отобразится), но верстальщики оказались не готовы к такому подходу, хотя я убежден, что он был бы несомненным благом для индустрии.

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

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

Тут нет тупости, просто так все устроено.

  • Like 1
Link to comment
Share on other sites

Макс, зачем переменные?

Это можно и классами решить, ведь классов то ставить можно много.

вот и сделать можно примерно так:

.height_1 { height: 10px; }

Вот тебе те же переменные.

И вполне это юзабельно.

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

Верстальщики много раз тупее чем программисты. Объясню почему: не так давно умные люди пытались ввести XHTML, который был бы жестко формализован (шаг влево, шаг вправо, забыл кавычку и страница просто не отобразится), но верстальщики оказались не готовы к такому подходу, хотя я убежден, что он был бы несомненным благом для индустрии.

Хм, точно верстальщики не готовы были? Или все-таки программисты? Ведь валидность обычно теряется после натягивания шаблона на CMS.

Link to comment
Share on other sites

Не знаю, у меня никто не ныл. Но знаете, очень много ПХП программистов ноют по поводу ООП - не готовы, а может просто тупы. Но наличие людей, которые "не осилили" предметную область до конца будет всегда и это не повод ориентироваться на них. Переменные в css - раздутая тема. По двум причинам. Во-первых, это очень полезно, особо для всяких БЭМ, где минимум каскадов, а значит максимум повторений. Во-вторых, потому что те, кому оно надо, давно это используют у себя в виде шаблонов с генерацией результата. Хотя "чистые" css переменные были бы чуточку удобнее... хотя бы для отладки. А говорит - не нужны переменные ибо верстальщики запутаются и напортачат - глупость. Да, запутаются и напортачат, да, даже без переменных, ибо это зависит от верстальщика, а не от css.

Link to comment
Share on other sites

Во-первых, это очень полезно, особо для всяких БЭМ, где минимум каскадов, а значит максимум повторений.

Хочется синтаксического сахара? Чем не угодила надстройка LESS? Чем удобнее нативная поддержка?

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

Link to comment
Share on other sites

Во-первых, это очень полезно, особо для всяких БЭМ, где минимум каскадов, а значит максимум повторений.

Хочется синтаксического сахара? Чем не угодила надстройка LESS? Чем удобнее нативная поддержка?

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

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

Волков бояться - в лес не ходить.

Link to comment
Share on other sites

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

Поддерживаю мнение, что XHTML (или я бы даже сказал, XML + HTML) является превосходным решением всех проблем. И не нужен бы был уродец HTML5

Link to comment
Share on other sites

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

Поддерживаю мнение, что XHTML (или я бы даже сказал, XML + HTML) является превосходным решением всех проблем. И не нужен бы был уродец HTML5

Есть такая штука как обратная совместимость и в большей степени она тянет весь ворох Г*вна проб и ошибок...правильно Мишка заметил, что жизнь XHTML была заведома провальна обилием различных некачественных CMS формирующих добрую наверное половину интернета..это означало бы отрубить людей от интернета и значительно увеличить стоимость разработки ..и там деньги не одним млрд исчеслялись бы. Кому это надо?..

Link to comment
Share on other sites

Есть такая штука как обратная совместимость и в большей степени она тянет весь ворох Г*вна проб и ошибок...правильно Мишка заметил, что жизнь XHTML была заведома провальна обилием различных некачественных CMS формирующих добрую наверное половину интернета..это означало бы отрубить людей от интернета и значительно увеличить стоимость разработки ..и там деньги не одним млрд исчеслялись бы. Кому это надо?..

Обратная совместимость тут не нужна. Браузеры ведь не могут за один день отказаться рисовать не XHTML контент. XHTML гораздо дешевле в разработке HTML, потому что требования фиксированы. Например, что лучше с точки зрения поддержки, писать примитивные значения атрибутов в кавычках (type="button") или без (type=button)? Все будут как один говорить, что без кавычек гораздо лучше. И это может быть справедливо для HTML-мышления. Перенесясь из мира браузеров в мир серверных приложений, когда тип может быть записан переменной, быть не у HTML-тега, а у XML-тега, то кавычки просто обязаны быть, дабы защитить будущий код от ошибки перечня типов


$tagType = "msg important"
<myTag type="{$tagType}">Fock</myTag>

Этот код гораздо устойчивее к изменениям, чем если бы не было кавычек. Я понимаю, что в мире XML документ не будет валиден, если бы не было кавычек, я тут просто гирперболизировал пример.

XHTML задумывалась как отдельная ветка. В общем хз почему она не взлетела. Наверное все звезды одновременно неправильно сошлись.

На самом деле XHTML2 в том виде, в котором он был, не исправлял ни одной проблемы, которую нужно было решать. XML - для оформления, HTML - для контента, микроформаты - для поисковиков. Вот формула успеха. HTML5 напоролся на то, что при всем многообразии новых тегов, они все равно нафиг никому не нужны и не выполняют свою роль на 100%

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share


×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. See more about our Guidelines and Privacy Policy