Думаю, что это из-за того, что в современном мире есть разделение труда. Контент-менеджер отвечает за интересное чтиво, разработчик за функционал, а дизайнер за дизайн, и у каждого из них свои инструменты.
Если использовать вашу логику, то нужно отказаться от css в вебе и перенести управление оформлением в js.
Я так понял, что речь про это: https://www.webcomponents.org/element/PolymerElements/paper-input Если перейти по ссылке и начать вводить email, то плейсхолдер "улетает".
Как по мне, такое решение лучше, чем плейсхолдеры без label. А такое, к сожалению, встречается.
С моей точки зрения, самый продуманный почтовый интерфейс у mail.ru и что хорошо, можно через этот интерфейс работать с любой почтой. Правда вместо фич гугла получите фичи mail.ru.
Тоже самое с Disk-o. Очень хорошо реализовано хранения второстепенной информации за пределами компьютера, так ещё и не привязана к облаку mail.ru.
Это в самом большом файле. А файлов может мульён, кто их знает.
Другое дело, что стоимость разных строчек разная. Есть те которые приносят огромную пользу клиенту. А есть вспомогательный код с малой ценностью для конечного пользователя. А бывают строки которые обходятся самим разработчикам в суммы со многими нулями.
В старых версиях windows было так, что ветка реестра в которой хранились все данные о пользователях (хэши паролей) была как надёжная крепость. Чего нельзя было сказать о резервной копии файла этой ветки.
Статью читал по диагонали, поэтому вопрос в рамках ветки комментариев. А на сколько километров вглубь действует магия? Возможно трёх тысяч (или даже трёхсот) километров от центра земли хватит для набора второй космической, учитывая, что в центре земли невесомость, а в разгонной шахте можно использовать технологии типа HyperLoop.
Правда, если не пользоваться магией, то на охлаждение шахты на такую глубину потребуется очень много времени.
Тогда могу сказать, что наиболее интересной частью статьи стало:
Поэтому мы начали параллельно с разработкой проекта вести документацию по основным проблемам и их решению. Такой источник знаний поможет новобранцам найти ответы на типичные проблемы и быстрее адаптироваться в проекте.
Давайте подумаем, зачем это может понадобится Techmedia. Будем исходить из того, что TM в состоянии нанять переводчика, который будет переводить 3-10 статей лучших статей в день интересных англоязычной аудитории. И если западная аудитория придёт на российский рынок, то появляется возможность ей что-то продать. А что продаёт TM, известно всем. Во-первых, это корпоративные блоги, а во вторых программистов через "Мой круг". Учитывая, что покупатель будет западным, платящий по западным ценам, то вполне возможно, что англоязычный хабр и англоязычный Круг смогут себя окупить.
Нужно признать, что красивые истории связанные логотипом помогают обратить внимание на логотип. Человек может не обращать внимания на логотип, но стоит ему рассказать почему надкушенное яблоко стало символом компании или что перевёрнутое название напитка — это арабское проклятье, и он уже проявит интерес. И возможно, даже будет вспоминать эти истории столкнувшись с логотипами, но при этом может не вспомнить название компании.
К сведению, relative-time — это вебкомпонент из Polymer, по сути посторонний тэг, в котором скрыты свои html+css+js, условно не доступные другим частям страницы.
В этом смысле netlify не отличается от CloudFlare. Просто потому, что netlify — это в первую очередь cdn. Но остальное в нём тоже сделано очень хорошо.
Из вашего комментария кажется, что Netlify это тоже генератор статических сайтов.
Netlify — хостинг для статических сайтов. Работает по следующему принципу, сначала запускает виртуальную машину, на которой запускается какой-нибудь генератор сайтов, например Jekyll, или какой-нибудь скрипт, который должен сгенерировать и поместить в папку статический сайт, а потом уже этот сайт публикуется через cdn. Один инструмент вместо двух, это просто удобнее, тем более что ограничений на использование своих скриптов и плагинов нет.
Для меня кажется странным подход отказываться от Jekyll в пользу чего-то другого, только потому что хостинг чего-то не позволяет.
Мне не совсем понятно, зачем для статических сайтов нужен URLRewrite.
Я тоже не думал, что такая экзотическая вещь мне может понадобится, но когда понадобилось оказалось, что хостинг такую функцию предоставляет.
В моём случае, javascript отображает одну и ту же страницу по разному в зависимости от url. Страница одна, а адресов несколько.
GitHub Pages + CloudFlare лучше использовать netlify. Во-первых снимаются многие ограничения, вроде упомянутых файловых операций. А во-вторых добавляется множество плюшек, вроде URLRewrite и https по-умолчанию.
Тут вопрос эффективности. На что стоит тратить время сообщества, на доведение до идеала нескольких хороших статей, которые будут прочитаны сотнями тысяч, или на приведение в порядок сотен статей, которые "не выстрелят".
Коррекция не редко нужна статьям типа "Tutorial", которые используются как учебные материалы и плохо когда в них встречаются ошибки. К тому же они со временем устаревают. А правки могут позволить оставаться статьям актуальными максимально долго.
Коррекция нужна переводам, потому что очень часто переводивший не так понимает смысл фраз.
Коррекция иногда нужна для статей "Из песочницы", потому что автор, как правило, не профессиональный писатель и может совершать смысловые и стилистические ошибки. И если сейчас показать "как надо", то в следующий раз можно ожидать более качественный материал.
Есть хорошая альтернатива, которая используется на многих новостных сайтах — Ctrl+Enter, которая не требует усилий со стороны читателя.
Но возможно эту же ошибку кто-то уже обнаружил. Значит читатель зря потратит своё время и время автора. Кроме того автору приходится самому находить место правки. Т.к. предложение о правке приходят хаотично, то будет принято первое попавшееся предложение. Просто нельзя увидеть все варианты исправления одной ошибки в одном вместе.
Конечно это всё ИМХО, а в реальности может оказаться, что режим корректора ни кому не нужен.
Пару раз я пытался сообщить авторам об ошибках через личные сообщения, но не разу не довёл это дело до конца. Поэтому мне кажется, что если бы у меня была бы возможность указывать на ошибки не отвлекаясь от чтения, а у автора принимать исправление одним кликом, то это сильно бы всё упростило. Да, мне кажется. Надеюсь, что не только мне.
В своё время редактирование было привилегией. На первом этапе звание корректора тоже будет доступно не всем. Кому и как давать эту привилегию пусть решают админы хабра.
Возможно вы и правы. Хотелось бы услышать мнение людей, которые исправляют свои статьи на основе замечаний из личных сообщений.
Возможно они легко понимают, в какой статье и что нужно исправлять, и делают это легко и не принуждённо, тратя не больше полминуты на каждое исправление. Возможно, мне только кажется, что сообщения об одних о тех же ошибках приходят по нескольку раз, дублируя друг друга.
Возможно, режим корректора — это слишком.
Думаю, что это из-за того, что в современном мире есть разделение труда. Контент-менеджер отвечает за интересное чтиво, разработчик за функционал, а дизайнер за дизайн, и у каждого из них свои инструменты.
Если использовать вашу логику, то нужно отказаться от css в вебе и перенести управление оформлением в js.
Я так понял, что речь про это: https://www.webcomponents.org/element/PolymerElements/paper-input
Если перейти по ссылке и начать вводить email, то плейсхолдер "улетает".
Как по мне, такое решение лучше, чем плейсхолдеры без label. А такое, к сожалению, встречается.
С моей точки зрения, самый продуманный почтовый интерфейс у mail.ru и что хорошо, можно через этот интерфейс работать с любой почтой. Правда вместо фич гугла получите фичи mail.ru.
Тоже самое с Disk-o. Очень хорошо реализовано хранения второстепенной информации за пределами компьютера, так ещё и не привязана к облаку mail.ru.
Это в самом большом файле. А файлов может мульён, кто их знает.
Другое дело, что стоимость разных строчек разная. Есть те которые приносят огромную пользу клиенту. А есть вспомогательный код с малой ценностью для конечного пользователя. А бывают строки которые обходятся самим разработчикам в суммы со многими нулями.
В старых версиях windows было так, что ветка реестра в которой хранились все данные о пользователях (хэши паролей) была как надёжная крепость. Чего нельзя было сказать о резервной копии файла этой ветки.
Статью читал по диагонали, поэтому вопрос в рамках ветки комментариев. А на сколько километров вглубь действует магия? Возможно трёх тысяч (или даже трёхсот) километров от центра земли хватит для набора второй космической, учитывая, что в центре земли невесомость, а в разгонной шахте можно использовать технологии типа HyperLoop.
Правда, если не пользоваться магией, то на охлаждение шахты на такую глубину потребуется очень много времени.
Тогда могу сказать, что наиболее интересной частью статьи стало:
Хотелось бы подробностей.
Давайте подумаем, зачем это может понадобится Techmedia. Будем исходить из того, что TM в состоянии нанять переводчика, который будет переводить 3-10 статей лучших статей в день интересных англоязычной аудитории. И если западная аудитория придёт на российский рынок, то появляется возможность ей что-то продать. А что продаёт TM, известно всем. Во-первых, это корпоративные блоги, а во вторых программистов через "Мой круг". Учитывая, что покупатель будет западным, платящий по западным ценам, то вполне возможно, что англоязычный хабр и англоязычный Круг смогут себя окупить.
Нужно признать, что красивые истории связанные логотипом помогают обратить внимание на логотип. Человек может не обращать внимания на логотип, но стоит ему рассказать почему надкушенное яблоко стало символом компании или что перевёрнутое название напитка — это арабское проклятье, и он уже проявит интерес. И возможно, даже будет вспоминать эти истории столкнувшись с логотипами, но при этом может не вспомнить название компании.
Правильно ли я понимаю, что преобразование декартовых координат в "золотые" такая же тривиальная задача, как обратная операция?
Всё время речь о целых числах и вдруг любая точность. Т.е. возможна точность 1e-6. Но как это стыкуется с целыми числами?
К сведению, relative-time — это вебкомпонент из Polymer, по сути посторонний тэг, в котором скрыты свои html+css+js, условно не доступные другим частям страницы.
В этом смысле netlify не отличается от CloudFlare. Просто потому, что netlify — это в первую очередь cdn. Но остальное в нём тоже сделано очень хорошо.
Из вашего комментария кажется, что Netlify это тоже генератор статических сайтов.
Netlify — хостинг для статических сайтов. Работает по следующему принципу, сначала запускает виртуальную машину, на которой запускается какой-нибудь генератор сайтов, например Jekyll, или какой-нибудь скрипт, который должен сгенерировать и поместить в папку статический сайт, а потом уже этот сайт публикуется через cdn. Один инструмент вместо двух, это просто удобнее, тем более что ограничений на использование своих скриптов и плагинов нет.
Для меня кажется странным подход отказываться от Jekyll в пользу чего-то другого, только потому что хостинг чего-то не позволяет.
Я тоже не думал, что такая экзотическая вещь мне может понадобится, но когда понадобилось оказалось, что хостинг такую функцию предоставляет.
В моём случае, javascript отображает одну и ту же страницу по разному в зависимости от url. Страница одна, а адресов несколько.
GitHub Pages + CloudFlare лучше использовать netlify. Во-первых снимаются многие ограничения, вроде упомянутых файловых операций. А во-вторых добавляется множество плюшек, вроде URLRewrite и https по-умолчанию.
В windows тоже есть обрезание.
https://s.mail.ru/6cmr/46CMeCXb1
браузер: Chrome 60.0.3112.101
разрешение: 1280×1024×24
Тут вопрос эффективности. На что стоит тратить время сообщества, на доведение до идеала нескольких хороших статей, которые будут прочитаны сотнями тысяч, или на приведение в порядок сотен статей, которые "не выстрелят".
Коррекция не редко нужна статьям типа "Tutorial", которые используются как учебные материалы и плохо когда в них встречаются ошибки. К тому же они со временем устаревают. А правки могут позволить оставаться статьям актуальными максимально долго.
Коррекция нужна переводам, потому что очень часто переводивший не так понимает смысл фраз.
Коррекция иногда нужна для статей "Из песочницы", потому что автор, как правило, не профессиональный писатель и может совершать смысловые и стилистические ошибки. И если сейчас показать "как надо", то в следующий раз можно ожидать более качественный материал.
Есть хорошая альтернатива, которая используется на многих новостных сайтах — Ctrl+Enter, которая не требует усилий со стороны читателя.
Но возможно эту же ошибку кто-то уже обнаружил. Значит читатель зря потратит своё время и время автора. Кроме того автору приходится самому находить место правки. Т.к. предложение о правке приходят хаотично, то будет принято первое попавшееся предложение. Просто нельзя увидеть все варианты исправления одной ошибки в одном вместе.
Конечно это всё ИМХО, а в реальности может оказаться, что режим корректора ни кому не нужен.
Пару раз я пытался сообщить авторам об ошибках через личные сообщения, но не разу не довёл это дело до конца. Поэтому мне кажется, что если бы у меня была бы возможность указывать на ошибки не отвлекаясь от чтения, а у автора принимать исправление одним кликом, то это сильно бы всё упростило. Да, мне кажется. Надеюсь, что не только мне.
Как смог изобразил все три режима на одной картинке

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