Всё ок, вот описание соответствующего псевдокласса на MDN:
The :empty pseudo-class represents any element that has no children at all. Only element nodes and text (including whitespace) are considered. Comments or processing instructions do not affect whether an element is considered empty or not.
Вам бы UX-дизайнера, т.к. именно он должен в первую очередь заниматься решением таких проблем. Может быть можно сделать какое-то пошаговое заполнение формы? Почему пользователи допускают столько ошибок?
И отдельно про поля ввода: есть ведь очень много способов ввода текста. Ввод вручную, вставка (Ctr+V, Shift+Ins, из контекстного меню), перетащить текст из другого места, автокомплит и т.д. Вставить текст можно в конец, в середину, в начало строки, заменив N символов…
В общем, чтобы вмешаться непосредственно в сам процесс ввода и как-то обрабатывать вводимые символы, надо предусмотреть дикое количество нюансов. Как мне кажется, более-менее адекватная реализация любой подобной фичи стоит довольно дорого. Настолько, чтобы перед реализацией задать себе много-много вопросов и решить а стоит ли вообще пытаться вмешиваться в процесс ввода данных.
Да мне и оригинальный заголовок не очень :) Building — довольно общее слово, я до середины статьи надеялся, что речь пойдёт об архитектуре приложений и о «правильном» использовании компонентов фреймворка.
Имхо, что-то подобное ближе к смыслу статьи:
1) «Способы сборки Angular.js приложений» — отражает обзорный характер статьи
2) «Сборка Angular.js приложений: RequireJS, Browserify, Gulp» — возможно поможет кому-нибудь потом найти эту статью в поисковике
3) «Простой и удобный конфиг Gulp для сборки Angular.js приложений» — громоздко, но вроде бы наиболее полно отражает то, что автор статьи в итоге сделал
Читал эту статью в оригинале и, честно говоря, меня очень удивило несоответствие заголовка и содержания.
1) Непосредственно про Angular здесь не так много
2) Автор рассуждает о том, как «космические корабли бороздят просторы Большого Театра», а потом приходит к выводу, что DI в ангуляре для разруливания зависимостей вполне ок, а с загрузкой отдельных модулей по сети лучше не париться, объединяя все скрипты в один файл app.js и минифицируя его. Ну и предлагает для этого Gulp.js
Но ведь не конкретно этого лабиринта? Не получается ли, что все лабиринты, которые потенциально может сгенерировать программа — авторские?
Собственно из блога автора:
While this maze may look generic to you, it looks quite recognizable to me, because I spent quite a bit of time writing software that produces mazes in this style. If you look closely, you may notice the vertices form a fibonacci spiral. It’s a pretty unique design, but, just to be sure, I bought a box, took it home, and started looking through the collection of mazes on my website. These mazes are free for you to download, but definitely not free for you to reuse, unless I grant you permission.
Нарушение в том, что был взят конкретный сгенерированный вариант (и возможно лишь благодаря этому автор узнал «своё» произведение). Если бы программа была выложена на его сайте и неизвестный дизайнер сгенерировал бы другой лабринт в том же стиле — возможно никакой речи об авторских правах бы и не возникло.
Разумеется, это строго моё мнение, но на мой взгляд, объектом авторского права могут быть произведения, созданные с явным участием человека, с применением его труда. Эта программа-генератор, лабиринт, творчески разукрашенный в фотошопе, да тот же самый лабиринт, но придуманный самостоятельно и нарисованный в пэйнте…
Возможно автор имеет права на код программы? Алгоритм?
Ок, на произведения, созданные при помощи программы, но с долей участия человека.
Kraft Foods, конечно, поступили плохо, но и признавать объектом авторского права сгенерированные изображения — довольно скользкая тема. А если программист Василий напишет абсолютно другой код, который выдаст тот же результат? Он нарушит права Джима? :)
Представляется такая картина восстания машин: искусственный интеллект объединит все вычислительные мощности и начнёт генерировать музыку, кино, книги, статьи, лабиринты и т.д… чтобы потом подать в суд на всякого человека, который создаст похожее произведение о_О Таким образом, прогресс остановится и человечество перестанет развиваться.
— Angular Light easier than Angular.js
— No excess details like dependency Injection, services…
— If you use jQuery, then aLight can be more convenient than Angular.js
— Easy making directives
— Inheritance of directives
— An able to control a declarative data binding in the HTML, text-directives
ИМХО, наиболее адекватное решение тут: github.com/filamentgroup/politespace
Конечно, немного не то, что у вас, но:
— вполне решает задачу (нам ведь нужно показать пользователю отформатированный ввод, верно?)
— не шокирует пользователя, не воюет с системой, не мешает работе с буфером обмена
Извиняюсь за сокращалку, но хабрапарсер не дружит с ссылками на посты на medium.com
Два книга: designculture.exmachina.ru/
Советую прочесть сначала обе эти книги и лишь потом просматривать сайты типа dribbble.
P.S: ещё есть такой внушительный курс: hackdesign.org/lessons
+ демо: codepen.io/anon/pen/LcJtC
И отдельно про поля ввода: есть ведь очень много способов ввода текста. Ввод вручную, вставка (Ctr+V, Shift+Ins, из контекстного меню), перетащить текст из другого места, автокомплит и т.д. Вставить текст можно в конец, в середину, в начало строки, заменив N символов…
В общем, чтобы вмешаться непосредственно в сам процесс ввода и как-то обрабатывать вводимые символы, надо предусмотреть дикое количество нюансов. Как мне кажется, более-менее адекватная реализация любой подобной фичи стоит довольно дорого. Настолько, чтобы перед реализацией задать себе много-много вопросов и решить а стоит ли вообще пытаться вмешиваться в процесс ввода данных.
Кому вообще это могло прийти в голову?
В какой системе поля ввода ведут себя столь нестандартно?
Не удивительно, что вы не получали жалоб — с точки зрения пользователя система ведёт себя «странно», «не работает». На что тут жаловаться?
Имхо, что-то подобное ближе к смыслу статьи:
1) «Способы сборки Angular.js приложений» — отражает обзорный характер статьи
2) «Сборка Angular.js приложений: RequireJS, Browserify, Gulp» — возможно поможет кому-нибудь потом найти эту статью в поисковике
3) «Простой и удобный конфиг Gulp для сборки Angular.js приложений» — громоздко, но вроде бы наиболее полно отражает то, что автор статьи в итоге сделал
1) Непосредственно про Angular здесь не так много
2) Автор рассуждает о том, как «космические корабли бороздят просторы Большого Театра», а потом приходит к выводу, что DI в ангуляре для разруливания зависимостей вполне ок, а с загрузкой отдельных модулей по сети лучше не париться, объединяя все скрипты в один файл app.js и минифицируя его. Ну и предлагает для этого Gulp.js
Взять конкретную картинку без спроса — нарушение.
Считать все картинки, генерируемые программой автора, принадлежащими автору — не верно.
Собственно из блога автора:
Нарушение в том, что был взят конкретный сгенерированный вариант (и возможно лишь благодаря этому автор узнал «своё» произведение). Если бы программа была выложена на его сайте и неизвестный дизайнер сгенерировал бы другой лабринт в том же стиле — возможно никакой речи об авторских правах бы и не возникло.
Разумеется, это строго моё мнение, но на мой взгляд, объектом авторского права могут быть произведения, созданные с явным участием человека, с применением его труда. Эта программа-генератор, лабиринт, творчески разукрашенный в фотошопе, да тот же самый лабиринт, но придуманный самостоятельно и нарисованный в пэйнте…
А какой номер у серии?
Ок, на произведения, созданные при помощи программы, но с долей участия человека.
Kraft Foods, конечно, поступили плохо, но и признавать объектом авторского права сгенерированные изображения — довольно скользкая тема. А если программист Василий напишет абсолютно другой код, который выдаст тот же результат? Он нарушит права Джима? :)
Большая просьба — если возможно, не убирайте в черновики.
ЗЫ: отдельно повеселили кандидаты, говорящие «не своим» голосом =)
OpenFL?
Конечно, немного не то, что у вас, но:
— вполне решает задачу (нам ведь нужно показать пользователю отформатированный ввод, верно?)
— не шокирует пользователя, не воюет с системой, не мешает работе с буфером обмена