rash

Можно. На VirtualPC у меня не получилось (не помню, по какой причине, да и не особо разбирался), а на VMWare или Virtual BOX должен установиться нормально…

Первое, что нашлось: http://www.ampsoft.net/webdesign-l/WindowsMacFonts.html

Если все эти элементы — непосредственные потомки одного родителя, то можно, например, так: body * { display: none; } body #bar, body #foo { display: block; } Но, скорее всего, случай посложнее…

А на спичках вы не экономите? Так как это кодировка с переменной длиной символа, то разметка, содержащая только ASCII-символы, в весе не изменится ни на бит. А возможность использовать на странице UNICODE-символы бывает весьма полезна. Что-то мне подсказывает, что страниц, на которых ни при каких обстоятельствах не может появиться UNICODE-символ, становится все меньше. Тут надо просто решить, что важнее. Экономия не всегда должна быть экономной, иногда экономя — проигрываешь, хотя бы в универсальности.

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

Надо проверить на tinyint-индексе :-)

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

А в чем противоречие спецификации?

Так и выбирайте только ключ, не нужно выбирать все поля.

Ясно, любопытство поутихло :-) Интересно, на практике кто-то уже с этим сталкивался? :-)

Это понятно, но ключ-то может быть только уникальным. То есть добавлять записи в таблицу станет невозможным? Значит, всего два с лишним миллиарда операций с записями (или четыре, если брать беззнаковое число), и таблица «выходит из строя»? :-)

Кстати, а что будет, когда диапазон, предоставляемый типом данных ключа будет исчерпан? Вряд-ли это реально грозит на практике, но просто интересно, кто-нибудь знает?

Google - вряд-ли. Просто они понимают, что надо делать не круче («мы такие умные — изобретаем свой велосипед») а эффективнее. Причем не в плане производительности кода, а в плане скорости разработки. В частности если в гугле работают такие глупые программисты, а вы такие умные, почему вы еще не там? Вы могли бы легко доказать свое превосходство ;-) (Вопрос саркастический, ответа не требует). Что касается фирм, не занимающихся непосредственно веб-технологиями, то, возможно, вы в чем-то правы.

Не попадалось :-)

http://www.plazoo.com/ru/tools.asp М?

Очень трудно будет ввести ограничения в изначально открытый протокол. Просто разведется множество «форков».

Ася настойчиво дает понять, что с удобными клиентами она работать не хочет. Да и потенциальных возможностей у протокола xmpp (он же jabber) больше, чем у OSCAR (icq) он может легко расширяться и поддерживать новые возможности. И открытость протокола гарантирует отсутствие неожиданных изменений, при которых старые клиенты «вдруг» перестанут работать.

Ну это нормально, что чего-то человек может не уметь. Если пытаться все делать самостоятельно, то получится дилетант широкого профиля.

Класс вполне берет на себя функции пространства имен. А если имена классов согласовывать с именами файлов, то останется еще меньше возможностей не заметить конфликт.

Может быть (не уверен, не пробовал) body { postiton: fixed; overflow: hidden; }

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

Значит Notepad++ этого не понял :-) Подозреваю, что дело было именно в BOM.

Нужно сохранять в UTF без BOM.

Нельзя прописать по умолчанию. Если не указывать единицы измерения — могут быть проблемы.

2^32 невозможно вычислить, если результат - целочисленная переменная длиной 4 байта. Она может принимать значения от 0 до 2^32-1.