Павел Волынцев

Если под стилем подразумевается рамка вокруг картинки, то легко

.icon {
    border: 1px solid red;
}

А если нужен доступ к отдельным линиям, то не используй embed, a вставляй сразу в HTML.
Вот пример: меняется видимость и цвет элементов codepen.io/copist/pen/WvVRRL

Очень смутный вопрос. А что за игра?
Игры можно сделать на стороне клиента (веб-браузер), технологий очень много.
Можно на JS сделать с использованием <canvas> и более простые варианты возможны.

.hea {
   position: absolute;
   width: 100%;
   left: 0px;
}

codepen.io/copist/pen/wKzGeq

У меня на этих курсорах двусторонние стрелки.


Первый раз вижу курсоры односторонние. Всегда же были туда-сюда. А что такими делать?

Тег <i /> - это самый короткий тег среди всех, что есть.
Кроме прямого назначения "italic" он также ассоциируется с "icon".
А классы на него можно навешать какие угодно, так же как и на <span> <strong> <div>

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

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

Можно ли отказаться от веб-фреймворка?
Да, можно, если проект достаточно прост.

С фреймворком или без фреймворка

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

Сначала присваиваем класс с картинкой какому-нибудь второстепенному объекту, а затем по таймауту - целевому объекту.

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

Более перспективным вариантом считаю изучить вёрстку. Это, в принципе, просто ремесло. Там нет магии. Все "тайные знания" уже давно являются достоянием общественности, есть обучающие материалы.

---

Может вам посмотреть на системы прототипирования? Чтобы можно было делать грубо оформленные страницы для составления общей картины.
Пальцем в небо, то есть гугль "fast prototyping":

• Пример https://proto.io/en/tour/ + https://proto.io/en/demos/
  
• Обзор www.sitepoint.com/tools-prototyping-wireframing
  

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

Готовые проекты на всех языках программирования доступны на github в исходниках.

блог на Python + Django : lightbird.net/dbe/blog.html
блог на PHP + Laravel 4 : www.codeheaps.com/php-programming/creating-blog-us...
блог на PHP + Phalcon : https://github.com/phalcon/blog-tutorial
блог на PHP + Yii2 : www.tutorial-zoo.com/yii-2/how-to-create-a-blog
блог на nodejs code.tutsplus.com/tutorials/nodejs-step-by-step-bl...
блог на Ruby-on-rails : https://www.reinteractive.net/posts/32-ruby-on-rai...
wiki на Go : https://golang.org/doc/articles/wiki/

Знаете ли вы порталы, где показываются интерфейсы ...

У них используется много полупрозрачных изображений для отдельных ингредиентов.
Вот, например, изображение для начинки "шампиньоны" 500600.ru/images/ingridients/shampiniony1.png
Изображения накладываются друг на друга с помощью JS в объекте типа canvas.
Вот так это реализовано в HTML: copi.st/LE8L

Пример реализации: codepen.io/copist/pen/EVayRq

Картинки нет.
У вас ошибка в Javascript.
Проверьте, что к странице подключились все файлы javascript

Собирай опыт сам в том, к чему душа тянется.

Не заметил я там никого уменьшения. У них сайт не респонсив.

Подсветка по события onmouseover и onmouseout, повешана на теги <path> через javascript в файле www.a-centauri.ru/assets/js/js_pack.js строки 324

take.ms/1G7mh
take.ms/sbRPt

Движущаяся область <div class="floor_popup"> с обозначением текущего выделения привязана к курсору через событие onmousemove на <body class="korpus1-1">
take.ms/dED5U

Всё это можно определить через отладчик

У вас среди вопросов уже был подобный и в нём уже указан приоритет технологий для изучения (ответ).

А Petja указал правильный подход изучения каждой отдельной технологии (ответ)

Я хотел бы раскрыть пункт "4. Практика и еще раз практика, решение множества конкретных задач"

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

Для примера были взяты свежие задачи с бирж фрилансеров weblancer.net и fl.ru типа "создать тему к CMS", "сделать посадочную страницу" (landing page) или "разработать сайт-визитку".

Были рассмотрены следующие способы изучения:

1. Повторить работы опытных фрилансеров. Исходные макеты либо не дали, либо они уже отличаются от того, что есть на сайте.
2. Включиться в открытый проект. Проблема в том, что сверстать страницы HTML можно несколькими способами, вплоть до image map или таблиц. А сравнить-то результат вёрстки не с чем.
3. Взять где-нибудь бесплатно или купить шаблон, к которому прилагается макет PSD, изучить свёрстанный вариант и повторить. Это оказался самый эффективный способ. Платные шаблоны делают профессионалы, "вылизывают" их, доводят до совершенства. И бесплатные шаблоны есть очень крутые, но их мало.

Мы использовали шаблоны с templatemonster. Там есть шаблоны под популярные CMS и просто HTML шаблоны. Также позже брали примеры из обзоров (35 примеров прекрасных посадочных страниц...) и повторяли несколько из них. Несложный макет в итоге верстается за сутки.

Это покрывает темы (из указанного же списка):

• XHTML, HTML4, HTML5
• CSS2.1, CSS3
• JavaScript, Ajax
• jQuery
• Twitter Bootstrap
• CSS Grids
• CSS Frameworks
• Progressive Enhancement, Graceful Degradation
• Responsive Web Design
• CSS Pre-Processors (LESS / Sass)
• CMS (WordPress, Joomla)
• Data Formats (JSON, XML)
• Internationalization / Localization
• Image Editing Tools (Photoshop, Fireworks, etc.)
• работа со шрифтами

Задачи типовые, а охват тем сразу вот какой обширный. Изучение в интенсивном темпе заняло 2...4 месяца. Профессионалом так быстро не станешь, но на позицию junior уже можно претендовать.

Так что мои советы:
1. Чтобы получить бесценную практику, занимайся реальными вещами, а не учебными примерами
2. Используй опыт профессионалов, чтобы повторять и копировать лучшие решения

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

Верстальщик преобразует графический макет (Photoshop или иной) в набор HTML + CSS + картинки. Иногда к свёрстанному макету может подключить типовые библиотеки Javascript, например, slider для картинок, или всплывающие подсказки (tooltip), или диалоговые окна (dialog/popup).
Знания и навыки:

• работа с графическими программами, чтобы понять, как собран макет
  
• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты и другие технологии
  
• пригодятся знания по HTML-фреймворкам, например, Twitter Bootstrap или Semantic UI
• навыки кроссбраузерной вёрстки, чтобы в разных браузерах выглядело и работало одинаково
  
• навыки отзывчивой вёрстки, чтобы можно было использовать на устройствах с разными возможностями и разрешениями
  
• знание типовых решений javascript, чтобы реализовать простейшие вещи, заложенные в макете
  

Фронтенд-разработчик делает так, чтобы макеты, полученные от верстальщика, были наполнены реальными данными. Если приложение построено как client-side (то есть вся основная логика загружается в виде огромного javascript в браузер, а данные запрашиваются с сервера по AJAX; это называется "толстый клиент"), то фронтенд-разработчику потребуется следующее:

• знание HTML, HTML5, CSS, CSS3, понятие про веб-шрифты, спрайты, Comet и другие технологии
• глубокое знание Javascript, включая использование готовых фреймворков, библиотек и написание расширений для них, что подразумевает объектно-ориентированное и событийное программирование
  
• знание AJAX, CORS и навык создания тестовых затычек на стороне сервера, чтобы можно было разрабатывать приложение пока бакенд не готов
  

Если фронтенд строится на стороне сервера, то дополнительно потребуется знать используемый серверный язык программирования (например, Python, Ruby или PHP) и используемый фреймворк (Django, Ruby-on-Rails, Yii). На практике бывало такое, что фронтендер просил в нужной части проекта сделать var_dump от структуры данных, которую надо показать и перечислить серверные методы, которые надо вызвать по нажатию предполагаемых кнопок.

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

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

-----------

Написал дополнение: copist.ru/blog/2015/08/29/layout-designer-vs-front...