Comments 52
ура!
Большое спасибо за сообщение и список изменений.
Большое спасибо, обновляюсь.
>В библиотеке Pagination теперь используется вместо
>В библиотеке Pagination теперь используется strong вместо b
зачем???
зачем???
тег strong рекомендует использовать W3C. Считалось, что при индексации гуглом, есть определенные предпочтения. strong предпочтительнее b, em лучше чем i. Однако, в последних интервью Мэтт Катс говорил о том, что для гугла разница не имеет никакого значения, и оба тэги учитываются одинаково. Ознакомиться можно в его блоге www.mattcutts.com/blog/
Сколько уже можно-то?!
Во-первых, W3C не рекомендует использовать тег <strong> вместо <b>, во-вторых, W3C не рекомендует использовать тег <em> вместо <i>.
W3C рекомендует использовать их с учетом их семантической значимости! Например, если Вы желаете сделать акцент на слове или фразе, которая должна быть прочитана с паузой, большей значимостью, используйте для выделения тег <strong>. Если Вы желаете усилить это значение в еще большей степени, используйте тег <em>.
Но остаются такие моменты, как типографские правила, как, например, такое — принято названия кораблей выделять курсивом (не обязательно имеются в виду правила русской типографики, но W3C не в Москве расположен), но если мы не желаем делать на названии корабля акцентирующее внимание, то выделяйте его просто тегом <i> (например, корабль Титаник). А жирный текст выделяйте тегом <b>.
Во-первых, W3C не рекомендует использовать тег <strong> вместо <b>, во-вторых, W3C не рекомендует использовать тег <em> вместо <i>.
W3C рекомендует использовать их с учетом их семантической значимости! Например, если Вы желаете сделать акцент на слове или фразе, которая должна быть прочитана с паузой, большей значимостью, используйте для выделения тег <strong>. Если Вы желаете усилить это значение в еще большей степени, используйте тег <em>.
Но остаются такие моменты, как типографские правила, как, например, такое — принято названия кораблей выделять курсивом (не обязательно имеются в виду правила русской типографики, но W3C не в Москве расположен), но если мы не желаем делать на названии корабля акцентирующее внимание, то выделяйте его просто тегом <i> (например, корабль Титаник). А жирный текст выделяйте тегом <b>.
Спокойнее, Ипполит :) Зачем столько агрессии, приведите лучше источники где можно добыть дополнительной инфы. Мы тут не холиварим, я лично за здравый смысл в обсуждении вопроса. Цель не доказать, что кто-то прав или не прав, а найти практический смысл применения тегов.
Прально. А в чём смысл был выделять текущую страницу тегом <b>? Это же тег, отвечающий за визуальное оформление. А что если мне надо текущую страницу бордером отметить, а не жирным? Вот поэтому, я считаю, правильно поставили <strong> вместо <b>. Потому что в этом больше смысла, т.е. семантики. Можно было ещё как-то типа <span class="current">...</span >
с точки зрения css что <b> что <strong> теги одного типа и оформить их можно как угодно. и ни тот ни другой в паджинаторе нафиг не нужны (если уж смотреть с точки зрения семантики то <li class='active'> куда более подходит на роль выделения страницы)
>с точки зрения css что что теги одного типа и оформить их можно как угодно
Правильно. Но cr0t сказал «А жирный текст выделяйте тегом <b>». С этим я в корне не согласен, и вообще, и в контексте пейджера.
>если уж смотреть с точки зрения семантики то <li class='active'> куда более подходит на роль выделения страницы
Согласен.
Правильно. Но cr0t сказал «А жирный текст выделяйте тегом <b>». С этим я в корне не согласен, и вообще, и в контексте пейджера.
>если уж смотреть с точки зрения семантики то <li class='active'> куда более подходит на роль выделения страницы
Согласен.
э, что-то заметно пошла стагнация, багфиксы какие-то и ничего глобального, понимаю конечно, что и цифра соответствующая, но больно долго всё фиксется. Да и видно, что Рик Эллис как-то отошёл от детища, по логам в SVN видна больше рука Дэрика :)
Улучшена безопасность xss_clean() (Internet Explorer)
это оччень карашо, просто оччень карашо 8)
Отлично, как-раз думал чего-нить заламзать на этом фреймворке…
Пожалуйста, подкиньте кармы для публикации поста в блоге Web 3.0
Свершилось: habrahabr.ru/blogs/web30/51751/
Спасибо всем, кто поддержал кармой!
Спасибо всем, кто поддержал кармой!
Отлично, спасибо за новость!
UFO just landed and posted this here
Если вы из песочницы, то как мне думается, что там кармы подкидывают, если нет, то действуйте проще.
Мне один товарищ писал, что мол подкинь кармы, вот хочу статью запостить и ссылочку на статью, почитал, кармы прибавил.
А таким способом, только получите минусов, хотя могу ошибаться
Мне один товарищ писал, что мол подкинь кармы, вот хочу статью запостить и ссылочку на статью, почитал, кармы прибавил.
А таким способом, только получите минусов, хотя могу ошибаться
Что-то затухает разработка, ничего нового и интересного. Я понимаю, что ЭллисЛаб выгоднее заниматься своим expression engine'ом, но все же… обидно.
UFO just landed and posted this here
— При наличии в URL запрещённых символов теперь отдаётся «HTTP/1.1 400 Bad Request».
это какие, например?
это какие, например?
CodeIgniter сильно ограничивает диапазон символов, которые могут быть указаны в URL, чтобы таким образом не передать в ваше приложение ничего вредоносного. URI могут содержать только следующее:
* Буквенно-цифровой текст
* Тильда: ~
* Точка:.
* Двоеточие::
* Символ подчеркивания: _
* Дефис: —
* Буквенно-цифровой текст
* Тильда: ~
* Точка:.
* Двоеточие::
* Символ подчеркивания: _
* Дефис: —
А известно когда появятся новые версии Codex или Blase?
Багфиксы хорошо, но всё же надеемся. что появятся какие-то глобальности, вот чего бы хотелось уже иметь сразу в стандратном пакете:
1. Библиотека для работы с авторизацией, удобная, расширяемая
2. Следует из 1, некий класс для работы с правами доступа, ACL хотя бы тот же
3. Генератор форм, например на паттерне декоратор, для быстрой генерации форм как из кода, так например из yaml или еще чего там, что-то типа Rapyd.com
4. ORM, хотя бы за основу IgnitedRecord, доработать, сделать лучше :)
5. Кэширование, всё же надо переделать стандратный класс кэширования базы данных, вплоть до проверки устаревания, роутинга и т.п.
6. AJAX, уже всё же определиться, какой front-end фреймворк поддерживать, раз уж пошли по пути копирования RoR, то начать с Prototype, дальше уже посмотреть можно и на JQuery. Создать удобные классы для генерации js в back-end'е, так же использование как в РоР .rjs
В общем еще море горизонтов куда расти
1. Библиотека для работы с авторизацией, удобная, расширяемая
2. Следует из 1, некий класс для работы с правами доступа, ACL хотя бы тот же
3. Генератор форм, например на паттерне декоратор, для быстрой генерации форм как из кода, так например из yaml или еще чего там, что-то типа Rapyd.com
4. ORM, хотя бы за основу IgnitedRecord, доработать, сделать лучше :)
5. Кэширование, всё же надо переделать стандратный класс кэширования базы данных, вплоть до проверки устаревания, роутинга и т.п.
6. AJAX, уже всё же определиться, какой front-end фреймворк поддерживать, раз уж пошли по пути копирования RoR, то начать с Prototype, дальше уже посмотреть можно и на JQuery. Создать удобные классы для генерации js в back-end'е, так же использование как в РоР .rjs
В общем еще море горизонтов куда расти
1-5 — добро поджаловать в кохану.
нет :) спасибо, Кохана мне не понравилась, первоначально, как отколок от CI, какая-то история мутная, после уже документации нет, коммунити слабая, поддержка совершенно мизерная и что-то нет уверенности, что проект будет поддерживаться дальше.
На самом деле, все эти 1-5 я уже для себя определил, нашёл, написал и т.п. Но хочется всё же, чтобы все это было в стандартном пакете CI
На самом деле, все эти 1-5 я уже для себя определил, нашёл, написал и т.п. Но хочется всё же, чтобы все это было в стандартном пакете CI
Вот как раз из-за таких глобальностей, я уже начал поглядывать одним глазом на ZF (:
э, ну я бы не назвал это глобальностями :) всё это действительно уже есть, и в коммунити, и в вики лежит, просто в «ядро» не включили по умолчанию…
ZF можно использовать в CI :)))
ZF можно использовать в CI :)))
Если сайт полностью делать на ZF, то он будет очень требовательным к ресурсам.
Лучше тогда использовать отдельные компоненты ZF в CI.
Лучше тогда использовать отдельные компоненты ZF в CI.
Много чего в вики есть, но я думаю вы в курсе =)
Помните Эллис говорил, что мол новая версия EE будет написана полностью CI, так вот мне кажется, что кучу нового появится в CI как раз из EE в свое время. Короче ждем пока.
Помните Эллис говорил, что мол новая версия EE будет написана полностью CI, так вот мне кажется, что кучу нового появится в CI как раз из EE в свое время. Короче ждем пока.
Так и будет ;)
Они еще летом хотели выпустить EE2.0 но все затянулось и ее до сих пор нету :(
а так они с CI сейчас идут синхронно, ЕЕ тоже немного обновился до — «ExpressionEngine 1.6.7 Build 20090211»
Номера версий думаю они не случайно выровняли и думаю скоро мы увидим сначала CodeIgniter 2.0, а потом ExpressionEngine 2.0 полностю написаным на CI ;)
Надеюсь ждать осталось недолго ))
а так они с CI сейчас идут синхронно, ЕЕ тоже немного обновился до — «ExpressionEngine 1.6.7 Build 20090211»
Номера версий думаю они не случайно выровняли и думаю скоро мы увидим сначала CodeIgniter 2.0, а потом ExpressionEngine 2.0 полностю написаным на CI ;)
Надеюсь ждать осталось недолго ))
Большое спасибо!
Жаль плюсануть не могу (
Жаль плюсануть не могу (
Ребята, такая проблема:
Вчера закончил писать проект на CI предыдущей версии.
Сегодня начал следующий проект на обновленной версии и теперь проблема — невозможно поместить объект в сессию.
Никто не встречат таких проблем? Если переписать старый файл библиотеки сессии, то все ок.
Вчера закончил писать проект на CI предыдущей версии.
Сегодня начал следующий проект на обновленной версии и теперь проблема — невозможно поместить объект в сессию.
Никто не встречат таких проблем? Если переписать старый файл библиотеки сессии, то все ок.
Sign up to leave a comment.
CodeIgniter 1.7.1