Здравствуйте, bzig, Вы писали:
B>Ну т.е. опять всё свелось к модальным диалогам, но пусть.
Что значит "свелось к модальным диалогам"? Тупо не работает свойство "max-height", независимо от того как используется.
S>>А ведь это обычный layouting, над которым на любом нормальном фреймворке даже задумываться не надо. И такие проблемы возникают постоянно — HTML/CSS просто не предназначен для разработки приложений.
B>А как это будет выглядеть в нормальном фрэймворке (можно, кстати, список?)? Те же самые вычисления и простановка какого-нибудь проперти. В чём принципиальная разница? Кроме той, что (я подозреваю) в нормальном фрэймворке-то и "em/ex" поддерживаться не будет, а будут пиксели и плевать, что там у юзера выставлено в настройках броузера 120%.
В нормальном фреймворке (абсолютно любой WPF, AWT, что-угодно с поддержкой layouts), не потребуются кодовые костыли для реализации базовой функциональности.
Здравствуйте, Somescout, Вы писали:
S>Что значит "свелось к модальным диалогам"? Тупо не работает свойство "max-height", независимо от того как используется.
Если мне память не изменяет, то оно работает только в том случае, если у родителя задан абсолютный размер. Хотя, и в этом случае ничего толком не гарантируется, в зависимости от браузера
Здравствуйте, Codealot, Вы писали:
S>>Что значит "свелось к модальным диалогам"? Тупо не работает свойство "max-height", независимо от того как используется.
C>Если мне память не изменяет, то оно работает только в том случае, если у родителя задан абсолютный размер. Хотя, и в этом случае ничего толком не гарантируется, в зависимости от браузера
Сейчас проверил — нет, даже если задавать абсолютный размер не работает. На счёт браузеров в точку: у меня max-height даже в разных версиях хрома по разному глючил.
Здравствуйте, Codealot, Вы писали:
C>Ну во первых, таблицы устарели и вообще это жуткий моветон, коллеги говном закидают.
Во-первых устарели не таблицы, а табличная верстка. Для отображения табличных данных ничего лучше таблиц нет. А во-вторых span с display: table-cell твоих коллег должен удовлетворить.
Здравствуйте, Codealot, Вы писали:
A>>При чём тут твой ник, если ты утверждал: C>При том, что ты утверждал, что это придумал я
Слушай, ты не способен даже признать, что ошибся, заявив, что аналогию придумал я. Какой смысл тогда тратить на тебя время и пытаться обсуждать с тобой что-либо по теме? Ты точно так же упрёшься по любому вопросу. Поэтому с тобой я закончил.
A>Так вот ситуация та же самая. Поверх примитивов создаются библиотеки компонентов и далее все пишут GUI, используя их.
почти та же самая. Ну то есть такая же, как земля и небо.
A>Для браузеров такие библиотеки уже есть, и никому не надо каждый раз делать компоненты, и не любить себя.
Ага-ага. Только вот незадача: любой чих, и эти компоненты ломаются. Любой компонент — с кучей ограничений нато, где, как и почему он может появляться, строгие требования к разметке и т.п. А крупные (типа той же sencha) просто банально берут на себя контроль за всем, практически не позволяют ничего стороннего, и все равно имеют кучу собственных ограничений на то, где как и почему какой-либо элемент может находиться.
И все равно. Любой залетный html * { padding: 2em } убьет любой «компонент».
Здравствуйте, vdimas, Вы писали:
V>В случае RVO "место" под возвращаемое значение создаётся до вызова getSomeStruct(..), адрес этого "места" де-факто подаётся как аргумент. V>Спеки в помоечку... ))
Персонально для НС добавлю:
ничего смешного, при возврате value types шириной более машинного слова в .Net после JIT или NetNative происходит ровно то же.
Здравствуйте, Codealot, Вы писали:
S>>Это целиком зависит от разработчика: сделать тормозной интерфейс можно на любом фреймворке.
C>Но на некоторых из них, невозможно не сделать тормозной.
На связке HTML/CSS/JS возможно. А что использовать над этим — это уже выбор разработчика. Некоторым и статический сайт-визитка без ангуляра с реактом не годится.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Somescout, Вы писали:
S>Эммммммммммммм... нет, это именно что костыли. Я буквально на днях напоролся на очередной выверт CSS
Костыли подпирают кучу легаси. Все боятся сломать совместимость, хотя при этом вводят новые фичи, которые в принципе не поддерживаются артефактами вроде IE.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
S>>Эммммммммммммм... нет, это именно что костыли. Я буквально на днях напоролся на очередной выверт CSS
Ops>Костыли подпирают кучу легаси. Все боятся сломать совместимость, хотя при этом вводят новые фичи, которые в принципе не поддерживаются артефактами вроде IE.
IE уже не актуален давно, на него никто и не смотрит. То же поведение max-(width|height) зафиксировано в стандарте, и пинать за это (так же как и за box-sizing) нужно W3C. И да, само собой сами они оправдываются тем, что "надо ничего не сломать", только вот по факту при этом вводят изначально кривые фичи.
S>IE уже не актуален давно, на него никто и не смотрит. То же поведение max-(width|height) зафиксировано в стандарте, и пинать за это (так же как и за box-sizing) нужно W3C. И да, само собой сами они оправдываются тем, что "надо ничего не сломать", только вот по факту при этом вводят изначально кривые фичи.
Здравствуйте, Somescout, Вы писали:
S>IE уже не актуален давно, на него никто и не смотрит. То же поведение max-(width|height) зафиксировано в стандарте, и пинать за это (так же как и за box-sizing) нужно W3C. И да, само собой сами они оправдываются тем, что "надо ничего не сломать", только вот по факту при этом вводят изначально кривые фичи.
ИЕ лишь пример. CSS-grid тоже в стандарте, однако поддерживаться начал совсем недавно, и до сих пор есть браузеры, в которых сайт с ним будет сломанным. Так почему, вместе с введением его (или чего-то подобного) поддержки, не поломать старые идиотские правила, назвав новым стандартом? А новые браузеры пусть обрабатывает оба случая, пока новый стандарт не вытеснит старый.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, vdimas, Вы писали:
DM>>Ну вот смотрю я в спеку и вижу совершенно иное: V>Я вижу всё то же
Вот, спасибо за ссылку на нужный документ. Ключевой момент:
Since WebAssembly's local variables are outside the address space, C/C++ compilers implement address-taken variables by creating a separate stack data structure within linear memory. This stack is sometimes called the "aliased" stack, since it is used for variables which may be pointed to by pointers.
Я говорил про первое — "WebAssembly's local variables are outside the address space", а ты — про второе, про то, как конкретный компилятор С++ обходит это ограничение. Теперь все на своих местах.
Здравствуйте, Mamut, Вы писали:
M>Языки без GC не спешат компилиться в wasm, вы все не поверите, потому что в wasm'е нет поддержки GC (это так же причина, почему в wasm'е нет доступа к DOM'у и нормальной интеграции с JS). Дотнетовский Blazor, компилирующийся в wasm, сначала грузит в браузер половину реализации дотнета, включая GC, а потом грузит приложения. Понятно, что никому это даром не надо.
Тут такая КВС идет, и по теме, в которой я даже не достиг уровня теоретика. Я когда-то Hello, World на JS немного допилил, и на этом все. И хотелось бы, может, немного побредить, но бреда тут и без меня хватает.
Здравствуйте, anonymous, Вы писали:
A>Слушай, ты не способен даже признать, что ошибся, заявив, что аналогию придумал я. Какой смысл тогда тратить на тебя время и пытаться обсуждать с тобой что-либо по теме? Ты точно так же упрёшься по любому вопросу. Поэтому с тобой я закончил.
А ты заявил, что ее придумал я, причем раньше того сообщения. И?
Здравствуйте, Ночной Смотрящий, Вы писали:
N>>Ад там уже не в языке, а в экосистеме. Все эти наслоения, включая TS, создают жутко хрупкую конструкцию из говна и палок.
НС>К счастью оно потихоньку фиксится.
Что, быстрее, чем это говно плодится? Меня в свое время удивил leftpad, и не тем, что он все сломал, а тем, что эта ерунда не часть осмысленной библиотеки, а отдельный модуль.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
C>>Например, в гов%о-мейле показ сообщений максимум по 50 за раз, да и тот тормозит, как указано в пункте 1.
Ops>Я вообще от него давно отказался, пользуюсь десктопным почтовиком, что намного удобнее, в т.ч. из-за тормознутости.
А каким, если не секрет?
Тоже вот хочу, но чтобы он на телефоне тоже был.
Вот представь себе, есть 5 аккаунтов IMAP, и идеально было бы, чтобы оно с ними синхронизировало почту и показывало бы некий объединенный inbox.
На телефоне, в браузере, и на десктопе. GMail такое не умеет (только pop), Outlook тоже (только раздельно)
Здравствуйте, D. Mon, Вы писали:
DM>Вот, спасибо за ссылку на нужный документ. Ключевой момент: DM>
Since WebAssembly's local variables are outside the address space, C/C++ compilers implement address-taken variables by creating a separate stack data structure within linear memory. This stack is sometimes called the "aliased" stack, since it is used for variables which may be pointed to by pointers.
DM>Я говорил про первое — "WebAssembly's local variables are outside the address space", а ты — про второе, про то, как конкретный компилятор С++ обходит это ограничение. Теперь все на своих местах.
Я же говорю — низкое кач-во спеки.
Аналогично ведь происходит с value-type в .Net, когда те передаются по ref/in/out.
Аналогично в Rust, аналогично в Хаскель, где структуры данных унутре передаются по ссылке.
В общем, С++ тут не при чём, этот список бесконечный.
