Угу, у меня вот ноут есть с сенсорным экраном, могу и так и сяк использовать.
По мне должны работать и стили hover и стили для сенсорных устройств одновременно или же переключаться на лету через JS.
Ну как нет, если на юнити точно так же выбираешь платформу Android и вместо красивых размытых динамических теней мы получаем «лесенки». Unity точно так же выдает картинку, которая будет на девайсе, вплоть до того, что можно эмулировать Open GL ES 3.0/2.0 + бегать между Shader Hardware Tier 1/2/3.
должен предупредить, не стоит по части шейдеров слишком сильно на этот режим эмуляции надеяться, сталкивался с ситуацией когда в нём всё норм, а на итоговой сборке шейдер глючит.
Как у анрила хз.
Вся эта xml-ная гадость в html-коде (впрочем, и не только в нём) раздражает.
О чём речь?
Да и какое вам до него дело, пользовались бы дальше костыльным HTML5.
Эти два стандарта развивались не мешая друг другу.
Одно в XHTML точно плохо это то что при нём обозреватель не рисует на лету разметку и пока документ не догрузится до конца страница не отобразится, отчего на больших страницах при плохой связности это большая проблема.
XHTML2 вероятно бы эту модель унаследовал, но в целом XHTML2 заметно чище и продуманнее, он мог бы дать толчок к очистке от груза всех остальных устаревших технологий и архитектурных ошибок. Тем более учитывая куда идёт веб (одностраничные веб-приложения), эта особенность XHTML уже не столь ощутима.
Отважились. Microsoft планировал всех пересадить на XAML и C#. Но… «не шмогла я, не шмогла».
Как-то не заметил. Где можно почитать про их попытку? Я от них помню только Silverlight, но это была так себе попытка, у них тогда уже был подпорченный имидж.
Microsoft нетвёрдо стоит на ногах? Я вас умоляю.
Ну тут этим не ограничивается, ещё авторитет, а у Microsoft он спорный, только недавно начали отмываться. Ещё я помню было время когда они убивали свои технологии, кому охота переползать на то что возможно потом закопают? Как например было с XNA.
Этого недостаточно. Единственный вариант, когда вы можете полностью «сменить курс» — это если у вас монополия.
Монополия это самый простой вариант, но всегда есть вариант идти по обходному пути и заодно проталкивать свою технологию в другие продукты разными способами. В итоге можно создать такую ситуацию что не поддержка технологии = уход пользователей на платформу где технология поддерживается. Естественно технология должна быть желанной и решать многие современные трудности заметно лучше всех прочих альтернатив.
Ну если бы не закопали XHTML2 то это бы уже было, но его закопали в угоду HTML5.
В веб-технологиях много легаси, мусора и прочих несуразностей, но пока никто не отважился пилить совершенно новую технологию (а реально такое сможет только твёрдо стоящая на ногах корпорация, т. к. мало технологию сделать её ещё надо продвинуть в массы). Есть потуги на WebGL но пока они выглядят мягко говоря не очень.
func e(error error) bool {
if error != nil {
return true
}
return false
}
//...
pool, error = pgx.NewConnPool(connPoolConfig)
if e(error) {
log.Crit("Unable to create connection pool", "error", error)
for e(error) {
log.Debug("Try to create connection pool", "warning", error)
pool, error = pgx.NewConnPool(connPoolConfig)
}
}
И в моём мирке всё спокойно (очень уж вымораживает писать «error != nil»). Есть ещё парочка похожих обёрток, более специализированных (для логирования и вывода спец json-ответа об ошибке). Мне норм.
И добавил новые, посидите на нём с плохой связью (которая может быть и внезапно на стороне хостинг-провайдера). У вас его «конвейер» встанет и вся сессия повесится на несколько минут. Для обычного пользователя поможет только выход из обозревателя. Короче HTTP2 плох если пакеты вдруг теряются. Пока сам не нарвался, относился к этому скептически.
По мне должны работать и стили hover и стили для сенсорных устройств одновременно или же переключаться на лету через JS.
https://engineering.instagram.com/sharding-ids-at-instagram-1cf5a71e5a5c у инстаграма было как минимум так.
А вот на тему статьи ютубных идов, есть давно библиотека hashids о которой почему-то не упомянули.
должен предупредить, не стоит по части шейдеров слишком сильно на этот режим эмуляции надеяться, сталкивался с ситуацией когда в нём всё норм, а на итоговой сборке шейдер глючит.
Как у анрила хз.
Понятно.
С примерами сложно ибо не видел пока прямо удачных компаний.
А так вспоминается: WebExtension, flexbox, CSS Grid, SPDY.
+ о чём уже сказал lexxpavlov
Да и какое вам до него дело, пользовались бы дальше костыльным HTML5.
Эти два стандарта развивались не мешая друг другу.
Одно в XHTML точно плохо это то что при нём обозреватель не рисует на лету разметку и пока документ не догрузится до конца страница не отобразится, отчего на больших страницах при плохой связности это большая проблема.
XHTML2 вероятно бы эту модель унаследовал, но в целом XHTML2 заметно чище и продуманнее, он мог бы дать толчок к очистке от груза всех остальных устаревших технологий и архитектурных ошибок. Тем более учитывая куда идёт веб (одностраничные веб-приложения), эта особенность XHTML уже не столь ощутима.
Ну тут этим не ограничивается, ещё авторитет, а у Microsoft он спорный, только недавно начали отмываться. Ещё я помню было время когда они убивали свои технологии, кому охота переползать на то что возможно потом закопают? Как например было с XNA.
Монополия это самый простой вариант, но всегда есть вариант идти по обходному пути и заодно проталкивать свою технологию в другие продукты разными способами. В итоге можно создать такую ситуацию что не поддержка технологии = уход пользователей на платформу где технология поддерживается. Естественно технология должна быть желанной и решать многие современные трудности заметно лучше всех прочих альтернатив.
В веб-технологиях много легаси, мусора и прочих несуразностей, но пока никто не отважился пилить совершенно новую технологию (а реально такое сможет только твёрдо стоящая на ногах корпорация, т. к. мало технологию сделать её ещё надо продвинуть в массы). Есть потуги на WebGL но пока они выглядят мягко говоря не очень.
Просто в теме слабо затронули оптические проблемы.
Ещё.
И в моём мирке всё спокойно (очень уж вымораживает писать «error != nil»). Есть ещё парочка похожих обёрток, более специализированных (для логирования и вывода спец json-ответа об ошибке). Мне норм.