Нет, Miraage всё верно говорит, никакая это не игра слов.
Верстальщик и фронт-энд-девлопер — это разные вещи, хотя и пресекающиеся.
Верстальщик режет макеты и пишет HTML/CSS-код. Плюс он встраивает этот код в шаблоны. Плюс знает JS на уровне «подключить jQuery-плагин и заанимировать панельку». Всё.
А всякий там сложный динамический интерфейс, общение с сервером через AJAX и тд и тп — это отдельная песня.
Я бы даже сказал, что серьезный фронт-энд девелопер это скорее не продвинутый верстальщик, а JS-программист с побочным знанием верстки.
Замечательно, но какое отношение миллиметры имеют к экрану? :) Там только пиксели есть. И эта конвертация отнюдь не однозначна.
Не существует никакой формулы, которая позволила бы совершенно однозначно предсказать, как будет выглядеть шрифт, заданный в pt, на всех системах/ос/браузерах/етц. Её в принципе не может быть.
Поясню.
Многочисленные статьи, предписывающие использовать только относительные единицы для размера шрифта, были актуальны и справедливы 3+ года назад. Когда браузеры не умели корректно масштабировать страницы целиком. И увеличение шрифта в настройках нередко приводило к поломке лейаута. Сегодня эти рекомендации потеряли актуальность.
На текущий момент пиксели, em-ы и проценты — абсолютно рабочие варианты при верстке. В некоторых ситуациях могут быть несколько более предпочтительны em-ы, в некоторых — px. Но в абстрактном-усредненном случае все три перечисленных варианта равноправны и нормальны.
Все это понятно. Только речь была не о том.
Был конкретный вопрос, можно ли получить значения без классов-оберток, из промежуточного объекта. Мне такая возможность кажется очень логичной, ибо зачем дублировать данные еще в какой-то обертке, если они УЖЕ есть в этом самом объекте (а не вовсе не в пикселях канваса)?
Я в общем-то уже знал, что нельзя — но оставалась малая надежда, что может я не знаю какого-то хака?
Все остальное уже лирика. Вопрос можно считать закрытым.
Цель именно такая, как я написал выше: корректировка существующего градиента, в широком смысле этого слова. Цветокоррекция, если угодно.
Не достать из того места — потому как хочется не привязываться ни к каким фреймворкам и сделать максимально независимую библиотечную функцию, которую потом можно будет подключить куда угодно.
Ну тут вопрос не в низко/высокоуровневости, а в полном отсутствии логичного функционала.
Доступ к отдельным пикселям на канвасе ведь есть? Да, не очень удобный, не очень быстрый — но есть. А обертками уже можно добавить удобства, гибкости, оптимизаций и т.д.
А цвета из градиента получить нельзя вообще никак, если только сам предварительно их где-то не сохранил — отдельно от канваса вообще.
Я нахожу это странным и нелогичным.
Мне кажется, это уход в сторону — равно как и упомянутый выше Джобс.
Это знаковые люди для компьютерной отрасти как бизнеса. Или, если угодно, как индустрии.
Автор же вопроса, как я понимаю, имел в виду основоположников информатики как науки.
А с маркетинговыми идолами дети познакомятся и так, никуда не денутся с подводной лодки…
С другими системами мне сравнивать сложно. С OpenGL я имел дело поверхностно, да и было это очень давно. Но подозреваю, что такой способ просто более прост/оптимален с т.з. программной реализации.
По логике, линия — все же объект линейный (который рисуется как бы последовательно), а не одномоментно заливаемая область. И при самопересечениях она должна накладываться сама на себя. Мне так кажется.
Способы обойти как бы есть. Самый очевидный — рисовать каждый сегмент ломаной отдельно. Но это костыль, причем грубый.
Во-первых, это может быть не ломаная, а какая-то сложная кривая.
Во-вторых, тогда будут возникать двойные наложения цвета в точках соприкосновения сегментов.
В-третьих, внутренняя область цельной замкнутой линии тоже может как-то использоваться.
Какой-то очень уж большой проблемой это не является, согласен. Но… «как-то доктор не аккуратненько» (с)
А у нас большая часть отчисленных пришлась именно на матанализ.
Хотя в осносном это «заслуга» преподавателя — была у нас по нему оч-ч-чень строгая тётка. Но, справедливости ради, и преподавала она очень хорошо. А уж заикаться о деньгах при ней было смерти подобно.
Да-да, я знаю про Чикуёнка и его метод, и тоже вспоминал о них.
Но в данном случае способ не подходит, поскольку он эксплуатирует багофичу IE округлять размеры блоков до целых пикселов. Тогда мы ширину экрана делим на 50 частей, округляем, обратно умножаем на 50 — и получаем то, что нужно. Но это только в IE.
FF и WebKit при расчетах используют дробные, неокругленные значения. Поэтому они посчитают все «правильно», и наш финт ушами не пройдёт.
В Опере будет своя проблема: она округляет (точнее даже не округляет, а тупо отбрасывает дробную часть) проценты. И там (в общем случае) тоже ничего работать не будет.
Да, это понятно.
Проблема только в том, что любое серьезное скриптовое изменение макета, повершенное на onResize, обычно адски тормозит, дергается и мерцает (особенно в IE).
Численно — да, нельзя.
Но в верстке есть разные трюки, когда нужные размеры получаются косвенными методами.
У меня в голове бродят кой-какие мысли, но пока в конкретное кроссбраузерное решение они не выстраиваются.
Насчет нельзя использовать JS — ну не то чтобы прямо совсем нельзя, но не хочется, неизящно. Я же написал, что задачу можно считать спортивной.
Нет, там всё несколько сложнее, чем диагональ квадрата и теорема Пифагора :)
Дело в том, что сетка географических координат не прямоугольна — меридианы сходятся у полюсов.
И 1 градус на экваторе и у полярного круга — совершенно разное расстояние в метрах.
Верстальщик и фронт-энд-девлопер — это разные вещи, хотя и пресекающиеся.
Верстальщик режет макеты и пишет HTML/CSS-код. Плюс он встраивает этот код в шаблоны. Плюс знает JS на уровне «подключить jQuery-плагин и заанимировать панельку». Всё.
А всякий там сложный динамический интерфейс, общение с сервером через AJAX и тд и тп — это отдельная песня.
Я бы даже сказал, что серьезный фронт-энд девелопер это скорее не продвинутый верстальщик, а JS-программист с побочным знанием верстки.