Упростить style?

Есть следующее:

Идея этого куска кода - на время обновления страницы (бывает довольно долго) подвесить по центру картинку-вэйтер.

Есть что-нибудь по-проще для того же самого?

Или прямо как есть в css запихать?

Если я правильно понял, то что ты хочешь называется что то вроде "content placeholder animation" - хорошо гуглится еще "facebook placeholder".

На чистом css не получится, вернее, анимировать картинки можно, а вот ловить когда их уже можно заменить загрузившимся контентом, уже js.

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

<div class="placeholder">
  <!-- some boxes in light grey to look like content --> 
</div>
 

Соответственно, этот класс стилизуешь, если хочешь, анимируешь.
Далее отлавливаешь, когда все что тебе нужно загрузилось, просто удаляешь этот класс:

$(".placeholder").remove();

Пыхх... оказывается - померло...

Там осталось:

            < asp:UpdateProgress ID="UpdateProgressItem" runat="server" DisplayAfter="100"  > 
                < ProgressTemplate > 
                    < div id="UpdateProgressDiv" runat="server" >  
                        < asp:Image ID="Image1" runat="server" ImageUrl="~/InProgressImage/icon_inprogress.gif" / >  
                    < /div > 
                < /ProgressTemplate > 
            < /asp:UpdateProgress >

и

#UpdateProgressDiv  { 
    position: absolute;
    left: 35%;
    top: 25%;
    visibility: visible;
    text-align:center;
    vertical-align: middle;
    border-style: solid;
    border-color: black;
    background-color: #c8d1d4;
    margin: 2px 2px 2px 2px;
}

Вроде освободился, но не уверен что все правильно...

Хотелось бы еще убить DIV...

$(".placeholder").remove();

Ой неее, это сложно...

Лезть в жабьи скрипты на сложных страницах - неее, не хочу... не мое просто...

Ой неее, это сложно...Лезть в жабьи скрипты на сложных страницах - неее, не хочу... не мое просто...

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

Так ведь отслеживать, когда загрузится то что требуется, надо ведь все равно на стороне фронтеда?

-----

Не-не-не, не надо фронт-енда.

Для отслеживания чего и когда там надо запускать/отпускась/выпускать/убивать/загибать/распрямлять/сворачивать есть

< asp:UpdateProgress ID="UpdateProgressItem" runat="server" DisplayAfter="100"

что надо - оно уже умеет делать, надо просто дать ему то что ему надо.

на мой взгляд, на js быстрей проще и точнее можно сделать.

-----

Может быть.

А как потом его мирить со всеми остальными скриптами на страницах? Там ведь не все, если по этому пути идти, по спекам будет...

И Я как-то не уверен, что копи-паста приведенного выше аспх-кода будет дольше и менее точно... а больше мне (прогеру) там писать ничего не надо.

Единственное... может в цсс прописать что-то вида:

#updprgMain02    {      
background: url(Images/PleaseWait.gif) 
no-repeat 50px 50px;      
padding: 3em;      
text-align: center;      
vertical-align: middle;      
position:fixed;      
z-index: 16000;      
top: 10em;      
left: 36em;
/* IE */-moz-opacity: 1.0;
/* Mozilla */      opacity: 1.0;      
background-color: gold;      
color: black;      
font-weight: bold;      
font-size: large;
}

передай фронтендеру пусть делает

-----

Да Я бы отдал, но... Я тут не просто самый понимающий в данном вопросе, а вообще сам в единственном числе...

И, кстати, фронт-ендщиков умеющих работать с АСПХ как надо программистам в природе почти нет...

ну хорошо. Тогда твой вопрос, или твою задачу нужно будет сформулировать другим образом:

есть функциональность, за которую всегда априори отвечает фронтенд. Как сделать, чтобы за это отвечал бакенд?

Ведь то что ты хочешь, происходит в браузере. Браузер на стороне клиента, ты передал ему все что надо, но как ты оттуда можешь предугадать его поведение? Ну скажем, дома у тебя скорость 100 мб/с, но вдруг в какой то момент оказался где то на мобильном 2G, где еще и лимит кончился и скорость оттого еще грустнее. Какие ты видишь варианты для корректного решения своей задачи? Если ты тупо выставляешь таймаут, как определить, сколько? Поставишь 10 с, на быстром канале нужно будет лишних 9.6 с смотреть на серые прямоугольники, когда контент будет уже через 0.4 с загружен полностью. А на медленном может быть все наоборот. Значит таймаут тебе надо определять переменной, предварительно получив и юзер агент и браузер и его скорость, и все равно эти данные чтобы получить полностью, необходимо будет обратиться к фронту.
Ну или усреднять все и все будет приблизительно...

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

пс.

И, кстати, фронт-ендщиков умеющих работать с АСПХ как надо программистам в природе почти нет...

ну если сначала идет логика а потом под нее фронт, то конечно нужен не фронтендер а как минимум фуллстек, да с подходящим для тебя стеком. Но все же в большинстве случаев все таки наоборот, сначала дизайн, потом фронт, потом логика...

Впрочем, случаи конечно разные бывают, спорить что главнее первее яйцо или курица не буду )))

Если ты тупо выставляешь таймаут, как определить, сколько?

-----

Я вообще ничего не выставляю, не определяю и не знаю где и как оно будет работать.

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

И это... Я ничего дополнительно не пишу в коде... ну, разумеется, если мне не требуется что-то делать по событиям...

если сначала идет логика а потом

-----

Не в этом дело.

Дело в том, что фронтендщики не понимают что за них будет сделано в аспх и как в это сделанное встроится

со своими преференциями.

Эээ... можно смеятся - в моем вебе практически нет ХТМЛа. А там где есть - сделано не правильно

и надо переделывать. Вот такой он - фронтенд на аспхах...

И, кстати, Я тоже не все из этого понимаю, а потому делаю все раздельно и, в основном, в бакенде

или отдельных компонентах.

ну так...в asp достаточно серьезный порог вхождения, это вам не пхп и даже не питон... мазохистов как то не очень много, сейчас все хотят быстрее и проще.
я сам в свое время сдуру вначале в дотнет полез, вот вообще с нуля, не то чтобы был какой то там advanced user, а полный чайник, и сразу же в c#. Чуть не утонул...потом вот во фронтенд подался, да и вообще все это произошло само собой, по течению... сейчас вижу, что стек на самом деле важный и категорически незабитый, как другие. есть кстати и очень похожие и близкие направления, и причем тут довольно востребованные - довелось как то раз лет 5 назад посмотреть как строится логика в dymanics nav, axapta, crm.

Но не пошел, опять же, течение...
Я кстати говоря, знаю людей которые работают как в бакенде, так и во фронте с дотнетовским стеком. Так вот, один друг на бакенде все говорит примерно как ты, т.е. js, css для него простейшие вещи оттуда звучат как инопланетные бредни. Но там у него фронт практически не имеет значения, в том понимании к которому привыкли нынешние веб-девелоперы. И аппликейшены, что они обслуживают, в 99.9% случаев предназначены только для корпоративного использования, либо вообще чисто веб-сервисы, зачем там пилить фронт, верно? все формы что в vs по дефолту, а больше им и не надо никому ничего.
А вот когда вдруг появляется необходимость интегрировать всю эту стройную и рабочую систему - ничего лишнего, все четко и красиво - с каким-нибудь веб-сайтом, при этом сделать все более менее с современным дизайном, то тут то и начинается самый треш. Как правило, у них этим занимаются индусы на аутсорсе, и на выходе получается не то что на костылях все - избушка на курьих ножках и с мушиными крылышками...

Когда речь идет о просто веб сайте, с любой логикой, но именно о сайте, в его классическом для большинства веб-девов понимании, то разница, на чем будет логика, для фронтендера нет. Такие сайты есть, найти их и поизучать без проблем, хотя справедливости ради, надо признать, что чисто сайтов ради собственно сайтов на дотнете немного, ну все же это как из пушки по воробьям...
xml... может быть, надо подумать, я не очень силен в xml, хотя сейчас в силу основной работы приходится влезать более плотно... просто увидел вот это - runat="server" DisplayAfter="100"

и подумал, что это и есть таймаут, не?

у него фронт практически не имеет значения

-----

Именно.

Мне простят неуклюжий интерфейс, но только при условии что через него можно сделать что требуется,

Потому - js, css - "инопланетные бредни". Для меня. А вот фронтендщика умеющего работать с аспх - хочу.

НО - нету - порог вхожения высок - минимум 4 разноплановых языка разом... это - без нюансов самой среды.

DisplayAfter="100" и подумал, что это и есть таймаут, не?

-----

Это - задержка между посылкой формы с клиента на сервер и началом показа вэйтора.

Можно опустить - по дефолту задержка будет чуть больше.

Эээ... там, а аспехах, сотни подобных параметров у компонентов и каждый чего-то меняет...

Многовато инфы для дизайнеров - потому и почти нету умеющих с ними работать...

собственно сайтов на дотнете немного

-----

Честно говоря - без разницы на чем делать - любой генератор хтмла годится...

если, конечно, умеешь с ним работат'.

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

Для любого верстальщика такие генераторы - зло и адская боль: куча мусора, ненужного кода, который нужен только для функционирования этого самого генератора.

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

Но проблема еще в том, что и бакендщикам иногда проще взять полностью самим запилить логику отдельных компонентов с клиентской частью, чем делать раздельно - внешне выглядит же нормуль!

При этом html-a на сотни а иногда и тысячи строк больше, при этом такого, что сам черт ногу сломит...

пс. Прикольно, вот вчера буквально, тоже видимо кто-то озадачивается как ты ))

https://toster.ru/q/656208

зло и адская боль

-----

Ну так напиши свой, который не будет давать лишнего кода.

Боль там не в лишних килобайтах хтмля, в во вполне ощутимых трудозатратах на изучение и адаптацию к версионным изменениям.

При этом html-a на сотни а иногда и тысячи строк больше

-----

Если отрисовалось правильно - пофиг на то сколько и чего там было больше.

Просто потому, что требуемые данные уже на экране.

То, что этих данных надо ждать на каждой закрузке на 1-2 секунды дольше, чем если бы кто-то из дизайнеров сделал идеально-минимальный вариант, но через два-три месяца, есть ничто.

В крайнем случае - обновят железо.

У меня есть задачка, которая считается почти 40 минут.

Заполнили поля, кликнули - выставился вэйтор и ждем... 40 минут. Иногда - больше.

На этом фоне 1-2 секунды на загрузку лишних килобайт хтмля выглядит никак.

Ну а мне надо думать как сократить эти 40 минут счета, а не урезать кило хтмля...

Прикольно, вот вчера буквально

-----

Немного мелковато... обычно там еще добавляется тюнинг производительности баз, включая запросы, процедуры и триггеры, в купе с высокохудожественной обработкой графики.