Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 164
А в чем проблема, если он такой плохой, то даже после принятия будут использовать ODF?
вы не знаете политику Майкрософт лоббирования своих разработок? даже мой коллега программист сказал
и правда затрахали уже псевдостандартами
в визуал студии вообще ппц что творится
по ходу стандарта ANSI C для микрософт не существует в принципе
как программист подписываюсь под словами твоего приятеля. уже заи... надоело плодить "костыли" в коде из-за неправильной интерпретации визлов.
как верстальщик мог бы многое вам рассказать о шаманстве с IE =)
Все мы как ITшики можем много что сказать против продуктов от МС... Как впрочем и от продуктов "опенсоурса" и Эпла. Но вот почему-то у меня большая нелюбовь к МСу. На работе у меня стоит линух, но сейчас приходится прогать под винду. Хорошо, что есть такой продукт, как VMWare (VirtualBox не прижился).
Ты не прав.
Ты глубоко не прав.
А подробнее? Я вот, как человек активно использующий CSS, тоже считаю что box-model шизофреническая.
Вы считаете килотонны таблиц лучше? Они не для этого придуманы. И HTML придуман для того, чтобы отделить разметку от содержания. И потом, хоть CSS и не совершенен, но он развивается. А у IE я не вижу развития.
Разве из моего комментария это следует? Я запрещаю использовать таблицы для разметки на своих проектах.
И как раз как активное использование CSS в реальной жизни и вызывает иногда желание задушить w3c. Просто за непрактичность — причём именно в попытках отделить содержание от представления.
И, говоря уже конкретно об IE, да, у него уйма недостатков. Но на всё кроме селекторов почти всегда находится обход в виду какого-нибудь древнего хака.
А вот когда я пробовал сделать в FF inline-block, это было весело. В самом соответсвующем стандартам браузере у меня есть выбор между -moz-inline-block, -moz-inline-box и -moz-inline-stack (ни один из которых не работает полностью по стандарту). Так что я бы не торопился так уж ругать IE. То есть развитие это конечно хорошо и в FF3 они это поправят, но некоторые вещи хочется делать сейчас.
И как раз как активное использование CSS в реальной жизни и вызывает иногда желание задушить w3c. Просто за непрактичность — причём именно в попытках отделить содержание от представления.
И, говоря уже конкретно об IE, да, у него уйма недостатков. Но на всё кроме селекторов почти всегда находится обход в виду какого-нибудь древнего хака.
А вот когда я пробовал сделать в FF inline-block, это было весело. В самом соответсвующем стандартам браузере у меня есть выбор между -moz-inline-block, -moz-inline-box и -moz-inline-stack (ни один из которых не работает полностью по стандарту). Так что я бы не торопился так уж ругать IE. То есть развитие это конечно хорошо и в FF3 они это поправят, но некоторые вещи хочется делать сейчас.
-moz-* это разве стандарт? о.О И «самый соответствующий», если мне не изменяет память, Safari.
-moz очевидно не стандарт, но я же его использую не ради его самого, а чтобы получить поведение хотя бы отдалённо похожее на стандартное.
Safari последний я не пробовал, может быть. Про старый Сафари знакомый рассказывал истории: "открываем первый раз под Сафари, а там — пусто! Oo". Вот Опера точно много чего поддерживает.
Safari последний я не пробовал, может быть. Про старый Сафари знакомый рассказывал истории: "открываем первый раз под Сафари, а там — пусто! Oo". Вот Опера точно много чего поддерживает.
читайте ниже про -moz. а я вам скажу, что сейчас, сверстанный семантически верно валидный (x)html-документ с валидным CSS на 90% будет одинаково отображаться и в FF2.x, и в Opera9.x, и в Safari 3.x, и в Konquerror 3.x. Версии на одну ниже могут чуть больше несовпадений содержать. А вот IE будет проклят до тех пор, пока его разработчики не придут в себя. Хотя они уже пообещали всем качественную поддержку CSS2.1 в IE8. Время покажет...
сижу в лисе уже 2 года, не сталкивался с таким.
вбил и получил обычный текст в тэге параграфа. и всегда так было, я юзал fck еще полтора года назад. сегодня же советую смотреть в сторону tinymce из фришных. и у меня не возникало никода проблем с работой wysiwyg редакторов ни в одном из браузеров.
а почему вы выдаете за преимущество использование библиотек MS в FCK?
у меня винда стоит только 4й день (провожу эксперимент "сколько выдержу под вистой").
А если работать с текстом не из документов МСО, то проблем не взоникает.. у меня не возникало
у меня винда стоит только 4й день (провожу эксперимент "сколько выдержу под вистой").
А если работать с текстом не из документов МСО, то проблем не взоникает.. у меня не возникало
я не говорил, что Tiny лучше FCK.
Я лишь сказал, что поддержка "стандартов спецфикаций" от МС может быть плюсом, но ни как не основным достоинством.
напр. у меня нет лишних 20 т.р., чтоб купить винду и офис, (я лучше upgrade компу или машине сделаю, или девушке подарок), а использование их "С. и С." вынуждает меня покупать их софт.
Зачем?
Я могу совершенно бесплатно и с тем же комфортом работать в OSS.
Поймал себя на мысли, что это уже холивар...
все это ИМХО. не хочу развязывать новых войн.
Я лишь сказал, что поддержка "стандартов спецфикаций" от МС может быть плюсом, но ни как не основным достоинством.
напр. у меня нет лишних 20 т.р., чтоб купить винду и офис, (я лучше upgrade компу или машине сделаю, или девушке подарок), а использование их "С. и С." вынуждает меня покупать их софт.
Зачем?
Я могу совершенно бесплатно и с тем же комфортом работать в OSS.
Поймал себя на мысли, что это уже холивар...
все это ИМХО. не хочу развязывать новых войн.
Вбил бла-бла, потыкал в размеры и т.п. всё пашет.
Браузер FF-2.0.0.8-сборка для Mandriva Linux.
Браузер FF-2.0.0.8-сборка для Mandriva Linux.
Да-да-да, Mozilla не реализует фичу, которая описана в непринятом стандарте. Какой качмар. CSS 21 - это всё еще не стандарт (зайдите сюда и убедитесь что it will remain Candidate Recommendation at least until 20 December 2007). В Firefox 3 поддержка inline-block есть, а в в CSS2 (который-таки стандарт) его нет...
Да. Я сравнивал FF3 и Opera 9.50 в опере поддержка анимированной SVG куда круче.
уважаемый, конструкции типа -moz, -webkit, -khtml являются отладочными заглушками в браузерах, на которых тестируются селекторы CSS, для которых в будущем в данном браузере должна быть введена поддержка. потому никто вам не гарантирует их корректную работу. попробуйте нарисовать круг чере -moz-border-radius и -webkit-border-radius и увидите, что в сафари у же согли грамотно реализовать border-radius из css3, а в файрфоксе пока еще, но на то это и отладка.
Да я понимаю. но проблема в том что задачи для решения которых требуются эти значения есть уже сейчас. И в IE я уже сейчас могу их решить.
Конечно, есть другие вещи, которые в IE не сделать. Селекторы :before и :after, в первую очередь. Вообще это не к тому что IE идеал браузеров, а к тому что ругать его можно с учётом того что другие немногим лучше.
Конечно, есть другие вещи, которые в IE не сделать. Селекторы :before и :after, в первую очередь. Вообще это не к тому что IE идеал браузеров, а к тому что ругать его можно с учётом того что другие немногим лучше.
вы можете указать, что именно такое архиэксклюзивное позволяет сделать ie?
И где этот datasrc+datafield используется, интересно ? Сайтов работающих только в IE - полно, но вот использования datasrc+datafield я в реальном мире не видел. Может быть что-то всё-таки с ним не так ?
незачОт! то, что не прижилось, то было обречено. вот и все.
идиотом выставлете здесь до сих пор себя только вы
Дайте пожалуйста ссылку на спецификацию формата Doc.
Легко - http://support.microsoft.com/default.aspx/kb/840817
Раздел Royalty-Free File Format Programs
Раздел Royalty-Free File Format Programs
А это что за херня?
> The documentation that covers the binary file format specifications is cumulative and covers the most current form of the binary file formats as well as earlier versions. If you want to receive the documentation, contact Microsoft at the following e-mail address to initiate the agreement sign-up process.
Перед тем как получить спеки по HTML и CSS мне не нужно ничьего соглашения. И ничего подписывать не нужно.
Кроме того, я сомневаюсь что там качественна я спека по которой можно со 100% точностью восстановить документ.
> The documentation that covers the binary file format specifications is cumulative and covers the most current form of the binary file formats as well as earlier versions. If you want to receive the documentation, contact Microsoft at the following e-mail address to initiate the agreement sign-up process.
Перед тем как получить спеки по HTML и CSS мне не нужно ничьего соглашения. И ничего подписывать не нужно.
Кроме того, я сомневаюсь что там качественна я спека по которой можно со 100% точностью восстановить документ.
Стандарты должны быть нейтральными. Помоему уже достаточно "стандартов" от MS.
ЭЭ, см. выше, inline-block. Далее, text-overflow: ellipsis. contentEditable. Если копать глубже, то expression и behavior, которые при условии поддержки JS позволяют закрыть пару дырок.
Если говорить о JS, то клиентское хранилище через user data (задолго до того как похожая вещь появилась в WhatWG HTML5). XMLHTTPRequest (уже все растащили, но всё же). VML (canvas хуже, правда, а SVG только недавно начали все поддерживать).
Если говорить о JS, то клиентское хранилище через user data (задолго до того как похожая вещь появилась в WhatWG HTML5). XMLHTTPRequest (уже все растащили, но всё же). VML (canvas хуже, правда, а SVG только недавно начали все поддерживать).
inline-block и text-overflow: ellipsis это попытки протолкнуть свои свойства. лучшие проходят в стандарт. overflow-x/y будет в css3, если не ошибаюсь.
по поводу остального. таже ситуация.
вы изначально подходите к проблеме неправильно.
нельзя гнуть свою линию и плевать на других, это приведет к печальным последствиям, современниками которых мы сейчас и являемся. должен быть унифицированный стандарт, к которому может обратиться любой желающий и получить желаемый результат.
по поводу остального. таже ситуация.
вы изначально подходите к проблеме неправильно.
нельзя гнуть свою линию и плевать на других, это приведет к печальным последствиям, современниками которых мы сейчас и являемся. должен быть унифицированный стандарт, к которому может обратиться любой желающий и получить желаемый результат.
Я подхожу к проблеме практически. И, что самое интересное, все к ней так подходят. Я уверен что нестандартные css значения в IE взяты не с потолка — скорее всего просто множество разработчиков интранет (IE-only) сайтов из компаний-партнёров Майкрософт активно требовало вещей, которые в стандарте того времени даже не намечалось. Use-cases для ellipsis в каждом втором веб-приложении тонна.
Но, отойдя от IE, чем же вот это: http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 лучше? Точно такая же попытка гнуть свою линию. В стандарте (ECMAScript 3) про всё это ни слова.
Да в общем и WhatWG это точно такая же попытка плевать на W3C и пробить новый стандарт в обход. Причём в этот "стандарт" включается нечеловеческий мусор вроде поддержки SQL в JavaScript. Только потому что в Google не собирались ждать стандарта клиентского хранилища и сделали Gears.
Но, отойдя от IE, чем же вот это: http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 лучше? Точно такая же попытка гнуть свою линию. В стандарте (ECMAScript 3) про всё это ни слова.
Да в общем и WhatWG это точно такая же попытка плевать на W3C и пробить новый стандарт в обход. Причём в этот "стандарт" включается нечеловеческий мусор вроде поддержки SQL в JavaScript. Только потому что в Google не собирались ждать стандарта клиентского хранилища и сделали Gears.
и лучшее снова окажется в общепринятом стандарте. однако, мы забываем, что ие всеже принято ругать не за свои фишки, а за свои баги.
Это верно. Но на практике для меня основная проблема с любым браузером это не баги, а невозможность сделать как надо. Баги мешают, но если есть хоть какой-нибудь обход, то это не очень важная проблема. По моим ощущениям, хотя именно ошибок в альтернативных браузерах меньше, возможностей сделать шаг влево и всё равно достичь своей цели в них тоже часто меньше.
Пример: в FF есть замечательная особенность DOM-модели в HTML — все названия аттрибутов приводятся к lower-case. То есть получить исходный case имени аттрибута невозможно (если не переключать миме-тип на xhtml). Это не баг, а разрешённая особенность имплементации. Но при решении определённой задачи мне от этого было ни капли не легче.
Я не собираюсь хвалить IE, но ругать компанию которая изобрела XMLHTTPRequest за баги это очень односторонняя позиция.
Пример: в FF есть замечательная особенность DOM-модели в HTML — все названия аттрибутов приводятся к lower-case. То есть получить исходный case имени аттрибута невозможно (если не переключать миме-тип на xhtml). Это не баг, а разрешённая особенность имплементации. Но при решении определённой задачи мне от этого было ни капли не легче.
Я не собираюсь хвалить IE, но ругать компанию которая изобрела XMLHTTPRequest за баги это очень односторонняя позиция.
в CSS3 будет переключение боксовых моделей. что касается текущей. вы знаете, сначала я тоже от нее плевался, потом просто привык, единственное, чего не хватает, так это вычисляемых значение, например, таких http://www.css3.info/calculated-values-a…
год назад, я перешел из статуса вечного фрилансера в статус штатного сотрудника серьезной крупной вебдев компании. так вот там я набрался очень много опыта у моего коллеги и он привел очень грамотный пример, почему именно w3c box model правильная. сейчас его я уже не вспомню, но если очень нужно, попытаюсь у него снова выяснить.
год назад, я перешел из статуса вечного фрилансера в статус штатного сотрудника серьезной крупной вебдев компании. так вот там я набрался очень много опыта у моего коллеги и он привел очень грамотный пример, почему именно w3c box model правильная. сейчас его я уже не вспомню, но если очень нужно, попытаюсь у него снова выяснить.
Фреймы придумали в Нетскейп вообще-то...
кстати, по поводу собственных стандартов IE, вам нравится, как реализованы такие вещи, как filter: ? а hasLayout это по вашему нормально?
Если бы не эти заигрывания со стандартами, то не было бы никакого "HTML/CSS ver. MS". Было бы разделение интернета на два лагеря. И ещё неизвестно какой бы выиграл в конце-концов. Скорее всего такого бы бардака как сейчас не было.
PDF. А вообще многие дальновидные организации переходят именно на ODF. То что вы называете стандартом является на самом деле нелепым стечением обстоятельств.
Когда гос учреждения мигрируют на OpenOffice.org, заказчики на Mac OS X а продвинутые разработчики на Linux - придется принять этот формат. И ставить плагин к MSOffice.
На Mac OS X - iWorks от Эпла поддерживает OpenXML вообще-то - т.е. зачем переходить куда-то. Ну и OpenOffice.org можно поставить от Новела, а не от Сана, и спокойно пользоваться OpenXML - т.е. зачем куда-то переходить неясно, да и потом ODF замечательно читается у меня в Office 2007 - после того как я поставил конвертер, т.е. в чем проблема то?
Вопрос стоит не в выборе приложения а в выборе формата. Посмотрим еще как OO от новела будет читать XML от MSOffice с встроенными бинарными данными, кои ни как не задокументированы в "стандарте".
Расскажите мне последовательность действий, которая породит бинарные данные в OpenXML файле?
Шаг 1:
Юзер открывает MS Word
Шаг 2: Юзер вставляет какой-нибудь объект.
Шаг 3: Юзер сохраняет docx.
В архиве имеет XML + бинарные данные, спеки на которые отсутствуют в принципе.
Как ни странно в "стандарте" есть отсылки к таким бинарным данным.
Юзер открывает MS Word
Шаг 2: Юзер вставляет какой-нибудь объект.
Шаг 3: Юзер сохраняет docx.
В архиве имеет XML + бинарные данные, спеки на которые отсутствуют в принципе.
Как ни странно в "стандарте" есть отсылки к таким бинарным данным.
какой-нибудь, не катит, т.е. если какой-нибудь, это картинка, то будет вполне специфицированный jpeg файл например, т.е. Вам не нравится возможность расширять содержимое файла бинарным контентом или что? На мой взгляд это крайне удобная возможность, т.к. позволяет использовать OpenXML в сценариях, когда необходимо обернуть бинарные данные человеко-читаемым контентом. Т.е. это скорее плюс стандарта, чем минус. Это расширяет область его применения. Понимаете?
Я не против бинарных данных. Но признайте сами, что отсылка к таким данным без спецификаций затрудняет реализацию стандарта.
Отсылка к данным без спецификаций, безусловно затрудняет реализацию. Вы этим словом только что называете? Т.е. где там отсылки к бинарным данным без спецификаций?
Читаем там же:
In several places, Ecma 376 specifies ways in which a document can incorporate external graphics, audio, and video files, without specifying even a minimal set of file formats that should be supported. This immediately creates a barrier to interoperability, because there is no reason to expect that different implementations of Ecma 376 will support the same multimedia file types.
И одному ктулху известно что будет сувать в эти тэги MSOffice 2013.
In several places, Ecma 376 specifies ways in which a document can incorporate external graphics, audio, and video files, without specifying even a minimal set of file formats that should be supported. This immediately creates a barrier to interoperability, because there is no reason to expect that different implementations of Ecma 376 will support the same multimedia file types.
И одному ктулху известно что будет сувать в эти тэги MSOffice 2013.
Во избежании дополнительных вопросов привожу ссылку
Ссылаться стоит, всетаки, на авторитетные источники, а не на агитпроп конкурентов. :), хотя по OpenXML уровень дискуссии таков, к сожалению, что авторитетных источников крайне мало, все низведено на уровень холивара, в худших его проявлениях. Можно в общем учебник писать по методике создания протестующих организаций.
Ответы на эти "замечания" я уже писал в своем блоге, поэтому не буду повторять еще и здесь, но идея проста - приведенный пример говорит о способности формата обеспечить совместимость с существующими приложениями - хорошо ли это? Да хорошо. Пострадает ли совместимость если не использовать эту возможность? - нет не пострадает. Пострадает ли переносимость документов если этим пользоваться - теоретически - да, практически - крайне маловероятно. Т.е. если у Вас есть возможность описать функциональность приложения, в котором создан документ, то это скорее хорошо, чем плохо, т.к. сохраняет инвестиции в приложения и не отражается на содержимом документа.
Если говорить о степени документированности ссылки на тот-же quicktime - то стоит признать, что ее можно было сделать и лучше, однако текущий ее вид врядли приведет к каким либо несовместимостям в текущем времени, а создавать долгосрочные архивы с включенным квиктаймом - тоже врядли кто-то станет - т.е. эта не точность с крайне низкой вероятностью может привести к каким либо проблемам, хотя, разумно было бы ее дополнить. Т.е., на мой взгляд, это не повод для столь бурных реакций.
Ответы на эти "замечания" я уже писал в своем блоге, поэтому не буду повторять еще и здесь, но идея проста - приведенный пример говорит о способности формата обеспечить совместимость с существующими приложениями - хорошо ли это? Да хорошо. Пострадает ли совместимость если не использовать эту возможность? - нет не пострадает. Пострадает ли переносимость документов если этим пользоваться - теоретически - да, практически - крайне маловероятно. Т.е. если у Вас есть возможность описать функциональность приложения, в котором создан документ, то это скорее хорошо, чем плохо, т.к. сохраняет инвестиции в приложения и не отражается на содержимом документа.
Если говорить о степени документированности ссылки на тот-же quicktime - то стоит признать, что ее можно было сделать и лучше, однако текущий ее вид врядли приведет к каким либо несовместимостям в текущем времени, а создавать долгосрочные архивы с включенным квиктаймом - тоже врядли кто-то станет - т.е. эта не точность с крайне низкой вероятностью может привести к каким либо проблемам, хотя, разумно было бы ее дополнить. Т.е., на мой взгляд, это не повод для столь бурных реакций.
> Ссылаться стоит, всетаки, на авторитетные источники, а не на агитпроп конкурентов. :)
Изините, помоему это не агитпроп а объективная критика. Давайте сойдемся на этом или будем называть OOXML агитпропом Microsoft?
Вот ваш блог персональный никак иначе назвать не могу :) Если откинуть шелуху "Линух гауно, Microsoft рулит".
Вы давно уже работаете в Microsoft?
Изините, помоему это не агитпроп а объективная критика. Давайте сойдемся на этом или будем называть OOXML агитпропом Microsoft?
Вот ваш блог персональный никак иначе назвать не могу :) Если откинуть шелуху "Линух гауно, Microsoft рулит".
Вы давно уже работаете в Microsoft?
Не очень, хотя в некотором смысле я всегда занимался проектами на майкрософте - поэтому можно считать, что давно :)
Понимаете, объективная критика, это когда примерно так: мы писали то-то... попробовали сделать то-то... но нифига не выходит. Тогда это объективная критика. А когда Word95 неспецифицированным продуктом вдруг становится... то :(
Кстати эти флажки в т.ч. вполне могут использоваться и для OpenXML, который создается oo.o
Понимаете, объективная критика, это когда примерно так: мы писали то-то... попробовали сделать то-то... но нифига не выходит. Тогда это объективная критика. А когда Word95 неспецифицированным продуктом вдруг становится... то :(
Кстати эти флажки в т.ч. вполне могут использоваться и для OpenXML, который создается oo.o
Добавил свою петицию. Спасибо за информацию.
не за что. на самом деле ведь никто не против хороших разработок и стандартов того же майкрософта. но то, что сейчас редмодский гигант пытается продвинуть, добавит всем головной боли в будущем.
Как выяснилось добавит даже себе. Неизбезно MSIE ковыляет за адекватными стандартами и соответствие стандартам чуток улучшилось в IE7. И тут у всех послетали сложные корпоративные приложения, заточенные строго под IE6. Всем весело, все смеются.
То что происходит сейчас, вообще-то позволит, как минимум, облегчить работу тысячам разработчиков. Т.е. на все офисы начиная с 2000 можно поставить openxml compatibility pack и они будут работать с ним, и тысячи программистов, которые выгружали отчетики в ворд и эксел через OLE automation или офисные макросы - смогут теперь сделать свои программы проще и изящней и эффективней - просто генерируя OpenXML файлы для этих целей.
А также, миллиарды документов из архивов могут быть легко конвертированы в открытый и хорошо документированный формат, и соответственно стать доступными для широкого класса приложений.
Только этого, согласитесь, уже совсем не мало.
А также, миллиарды документов из архивов могут быть легко конвертированы в открытый и хорошо документированный формат, и соответственно стать доступными для широкого класса приложений.
Только этого, согласитесь, уже совсем не мало.
+1 я тож добавил... А я вообще в принципе Майкрософт не люблю... (*подозрительно*) не нравятся они мне ))
скажите, почему все так против, или просто "Против" это такая национальная черта? а где можно ЗА проголосовать? я лично ЗА.
почему против в данном случае четко указано в петиции, вам этого мало?
да, потому что я ЗА этот формат. Этого мало?
было бы интересно услышать ваши за в противовес представленным против
хорошо, сейчас напишу, хотя это вгонит меня в минус сильный :)
вот мой ответ: http://aleks-raiden.habrahabr.ru/blog/30…
Интересно посмотреть как к этому относятся посетители сайта http://bvs.habrahabr.ru/blog/30985.html ?
успел споймать зловещее число проголосовавших =)
*** ***, Russia, 6 minutes ago
Comments: simply no
Comments: simply no
А почему никто не захотел покопаться в стандарте ODF? Да потому, что "по умолчанию" практически все настроены против Microsoft и всего, что с ними связано. В то же время идеализируют ODF потому, что он относится к open source. Я не верю в то, что в стандарте ODF нет ни одной подобной ошибки или упущения. Кстати, вот нашел тому подтверждение. Open source не идеален, равно как и Microsoft и ему подобные.
По сути нужно мнение незаинтересованных экспертов со стороны, которые должны всесторонне и тщательно проанализоровать и сравнить оба стандарта. Если, конечно, еще этого не сделали. И только после этого уже можно делать какие-то выводы в пользу какого-либо стандарта.
По сути нужно мнение незаинтересованных экспертов со стороны, которые должны всесторонне и тщательно проанализоровать и сравнить оба стандарта. Если, конечно, еще этого не сделали. И только после этого уже можно делать какие-то выводы в пользу какого-либо стандарта.
Насчет "фанатиками" - это ваши слова. Я такого не говорил и уж тем более не думал. Насчет "ты" - по-видимому, вас не обучали в детстве культуре общения.
В интернетах не принято говорить вы. %)
Я думаю это пошло от двух причин: в английском языке нет обращения вы (есть you и хоть ты тресни), общение на форумах, блогах и подобном больше похоже на дружеское обсуждение, чем на деловой разговор.
Я думаю что именно поэтому говорят ты.
А по-поводу вашего утверждения... Я с вами категорически не согласен. И тот и другой стандарт в своё время старательно изучался, более того проводилось наглядное сравнение ODF с OOXML.
Вот, хотя бы, это:
http://ooxmlisdefectivebydesign.blogspot…
Я думаю это пошло от двух причин: в английском языке нет обращения вы (есть you и хоть ты тресни), общение на форумах, блогах и подобном больше похоже на дружеское обсуждение, чем на деловой разговор.
Я думаю что именно поэтому говорят ты.
А по-поводу вашего утверждения... Я с вами категорически не согласен. И тот и другой стандарт в своё время старательно изучался, более того проводилось наглядное сравнение ODF с OOXML.
Вот, хотя бы, это:
http://ooxmlisdefectivebydesign.blogspot…
Lain_13, я не вижу здесь ни одного опубликованного комментария на английском языке. На какой версии русского языка вы говорите? Но специально для вас, если это вам ближе: Hey you, Lain_13, did a reply from Troorl was written in English? Простите за резкость :)
Дальше, если такое тестирование проводилось, то автору топика или сайта уж тем более нужно было бы потрудиться предоставить ссылку на страницу со сравнением на видном месте. Читать всю эту страницу целиком, конечно, не обязательно, можно ограничиться выводами. На зато есть сам факт наличия такого материала!
Дальше, если такое тестирование проводилось, то автору топика или сайта уж тем более нужно было бы потрудиться предоставить ссылку на страницу со сравнением на видном месте. Читать всю эту страницу целиком, конечно, не обязательно, можно ограничиться выводами. На зато есть сам факт наличия такого материала!
Ви таки будете удивлены, но в некоторых версия русского языка принято конструктивный диалог начинать со слов "ты хуй!" и ничего, как-то общаются. Вот такие вот бывают версии русского языка. Даже в реале встречался. ;)
Ну а автор топика действительно не прав, не приведя доказательств ущербности формата OOXML и, даже, не дав ссылки на это. Впрочем, я ссылку дал.
Ну а автор топика действительно не прав, не приведя доказательств ущербности формата OOXML и, даже, не дав ссылки на это. Впрочем, я ссылку дал.
Когда предлагается заменить один формат на другой, то "другой такой же" не нужен - нужен лучший. Уж извините...
Мне ближе ODF из за своей открытой природы. Это как рынок, тут у руля многие силы и никто не сможет возвести в ранг стандарта баги старой линейки продуктов. Этого просто не допустят остальные!
Разговор ведь больше не о технических недочётах — они наверняка есть и в ODF. Вопрос больше в том, что OOXML имеет проблемы как стандарт — не использованы другие стандарты, часть технологий защищены патентами и так далее. И это проблема — корпоративная политика Microsoft. Именно по этому сразу и все настроены против _стандарта_, так как знают корпоративную политику. А ODF не имеет _подобных_ проблем из-за открытости. А на мелкие технические недочёты можно закрывать глаза как к ODF так и к OOXML
В ODF есть подобные ошибки и упущения. И над ними работают. Что касается критики, то давайте посмотрим подробнее:
1. Формулы - используется MathML, а не TeX. При всём моем уважению к TeX'у вынужден сказать что для встраивания в другие форматы он не годится. Ибо нет и не может быть никакого описания этого языка. Потому что существует одна и только одна каноническая реализация и никакая модификация стандарта невозможна. Так что ни о какой открытости не может быть и речи. Почему используется MathML, а не ISO 12083:1994 ? Ну наверное потому что MathML поддерживается гораздо большим числом программ и организаций, чем ISO 12083:1994... Мертворождённые стандарты (пусть даже освящённые ISO) - они и есть мёртворождённые...
2. Описание языка формул было сознательно исключено из первой версии стандарта ибо там всё очень непросто. Чтобы привести все формулы в соответствие со стандартами ISO (а не с одной-единственной существующей реализацией) требуется время. А использовать ODF без совместимости на уровне формул тоже можно и бессмысленным он от этого не становится. Лучше никакого стандарта, чем плохой.
3. Отсутствие каких-либо возможностей (как в ODF) - вещь менее страшное чем отсуствие описания каких-либо возможностей (как в OOXML), так что этот пункт критики вообще "мимо кассы": нельзя объять необъятного. К тому же таблицы действительно можно вставить с помощью вставки объекта типа spreadsheet в объект типа presentation.
4. Отсутствие стандарта на макросы - это проблема (и пока нерешённая). Однако это, всё-таки, гораздо лучше чем ситуация с OOXML где макросы не то что непонятно как интерпретировать - их даже нельзя увидеть (в OOXML никакого описания нет вообще, а MS Office использует свой собственный недокументированный бинарный формат для хранения макросов)!
Дальнейшая критика уже вообще не выдерживает никакой критики. Да, OpenDocument Foundation, Inc действительно самораспутилась - и что ? Какое это имеет отношение к формату ? Это всё равно как если бы кто-нибудь сказал что у Спартака огромные проблемы: спартаковский фэн-клуб в поселке Гадюкино самораспустился! Ну и что с этим может сделать Спартак ?
В общем если ODF заслуживает оценки "удовлетворительно" (то есть "3 балла" для тех кто забыл), то OOXML - это где-то между "плохо" и "неудовлетворительно". К сожалению никакого формата, который бы заслуживал оценки "отлично" у нас нет - так что приходится выбирать среди двух зол...
1. Формулы - используется MathML, а не TeX. При всём моем уважению к TeX'у вынужден сказать что для встраивания в другие форматы он не годится. Ибо нет и не может быть никакого описания этого языка. Потому что существует одна и только одна каноническая реализация и никакая модификация стандарта невозможна. Так что ни о какой открытости не может быть и речи. Почему используется MathML, а не ISO 12083:1994 ? Ну наверное потому что MathML поддерживается гораздо большим числом программ и организаций, чем ISO 12083:1994... Мертворождённые стандарты (пусть даже освящённые ISO) - они и есть мёртворождённые...
2. Описание языка формул было сознательно исключено из первой версии стандарта ибо там всё очень непросто. Чтобы привести все формулы в соответствие со стандартами ISO (а не с одной-единственной существующей реализацией) требуется время. А использовать ODF без совместимости на уровне формул тоже можно и бессмысленным он от этого не становится. Лучше никакого стандарта, чем плохой.
3. Отсутствие каких-либо возможностей (как в ODF) - вещь менее страшное чем отсуствие описания каких-либо возможностей (как в OOXML), так что этот пункт критики вообще "мимо кассы": нельзя объять необъятного. К тому же таблицы действительно можно вставить с помощью вставки объекта типа spreadsheet в объект типа presentation.
4. Отсутствие стандарта на макросы - это проблема (и пока нерешённая). Однако это, всё-таки, гораздо лучше чем ситуация с OOXML где макросы не то что непонятно как интерпретировать - их даже нельзя увидеть (в OOXML никакого описания нет вообще, а MS Office использует свой собственный недокументированный бинарный формат для хранения макросов)!
Дальнейшая критика уже вообще не выдерживает никакой критики. Да, OpenDocument Foundation, Inc действительно самораспутилась - и что ? Какое это имеет отношение к формату ? Это всё равно как если бы кто-нибудь сказал что у Спартака огромные проблемы: спартаковский фэн-клуб в поселке Гадюкино самораспустился! Ну и что с этим может сделать Спартак ?
В общем если ODF заслуживает оценки "удовлетворительно" (то есть "3 балла" для тех кто забыл), то OOXML - это где-то между "плохо" и "неудовлетворительно". К сожалению никакого формата, который бы заслуживал оценки "отлично" у нас нет - так что приходится выбирать среди двух зол...
Стандарт так или иначе утверждён в ISO и серьёзных ошибок следовательно в нём нет.
Что же касается ошибок в реализации стандарта - вот тут и зарыта собака. Зачем вобще нужен стандарт OOXML если его нельзя толком реализовать ни в каких приложениях, кроме приложений MicrosoftOffice?
Что же касается ошибок в реализации стандарта - вот тут и зарыта собака. Зачем вобще нужен стандарт OOXML если его нельзя толком реализовать ни в каких приложениях, кроме приложений MicrosoftOffice?
1. а чем плохо наличие альтернативы?
6. что значит конфликтует? можно поподробнее объяснить?
6. что значит конфликтует? можно поподробнее объяснить?
1. даже не просто альтернативы, а открытого стандарта поддерживаемого флагманом индустрии супротив стандарта понимаемого и используемого лишь небольшим процентом пользователей. Боюсь, что повторится ситуация с браузерами. Большая часть рынка принадлежит Майкрософту, продукты которого являются фактическим стандартом, а некое сообщество придумывает и навязывает стандарт, который востребован лишь 15%-20% пользователей, и, как как следствие, разработчикам приходится ради охвата этих 20% рынка делать двойную работу.
Я не говорю, что эти стандарты плохи, напротив, они хорошо и понятно описаны, поддерживаются неплохим коммьюнити программистов, но мне, как разработчику, они только добавляют проблем.
Я не говорю, что эти стандарты плохи, напротив, они хорошо и понятно описаны, поддерживаются неплохим коммьюнити программистов, но мне, как разработчику, они только добавляют проблем.
В случае с офисными форматами и браузерами вам проблем добавляют скорее не стандарты, а то, что MS не следует им.
MS следует стандарту дефакто - своему собственному, которым пользуется три четверти рынка. С чего бы монополисту имеющему свои собственные удобные привычные стандарты вдруг переходить на стандарты конкурентов? Ну это как если бы вы попытались ввести в США в использование евро (им пользуется больше стран и, соответственно, нет монополии одного правительства) или рубли, или заставить перейти пользователей qwerty-клавиатур на раскладку Дворака (говорят, она удобней и эргономичней, позволяет развить большую скорость печати). Или, совсем реальный пример, перевести рунет с устарелых, поддерживаемых только в русских локализациях систем/софта ANSI и KOI8-R кодировок на универсальный формат Unicode - я с этим уже лет пять мучаюсь - в Windows, если русский не установлен языком по умолчанию, очень редко можно встретить софт нормально отображаюший кириллицу (как раз MS-продукты (а так же некоторые opensource-разработки типа X-Chat) поддерживают кириллицу превосходно, дело как раз в недалёких либо ленивых программерах третьих фирм. на вскидку это: mIRC, R&Q, qip, the bat, punto, Total Commander и много другого софта, от которого мне пришлось отказаться или свести использование к минимуму, так как я не хотел отказываться от русского языка).
DOC и RTF — это уже где-то де-факто, но не стандарты. А OOXML ещё вовсе не де-факто, т.к. пока мало народу перешло на новый Офис, и ещё меньше используют новый формат в документообороте.
Ага, придёться тройную работу делать: поддержка ISO ODF, ISO OOXML (если примут), и имплементация OOXML самой Microsoft. :P
ну уж нет. основной заказчик моей конторы пользуется IE6 и MS Office 2003, в которм есть VBA.
Ну дык и зачем вам стандарт ISO OOXML ? Он сделает жизнь проще ? Шансов на то что MS OOXML и ISO OOXML будут совпадать - примерно нуль. Вряд ли несоответствие ISO OOXML будет рассматриваться Microsoft'ом в качестве ошибки, которую нужно срочно исправлять.
мне их война стандартов документов пока безразлична - у меня как у пользователя лицензия на полную версию MS Office 2007 и последняя версия OpenOffice.org, а как программист я работал пока только с Excel c его comma separated или tabseparated форматами.
а вот у других пользователей иногда позникают проблемы - например, они не знают, чем открыть полученный по почте "стандартный" документ ODF, созданный в OpenOffice, а иногда и просто не могут - нет прав на установку OpenOffice, или нет интернета, чтобы его скачать и т.п., так как всегда пользовались только MS Office и его хватало на все нужды.
а вот у других пользователей иногда позникают проблемы - например, они не знают, чем открыть полученный по почте "стандартный" документ ODF, созданный в OpenOffice, а иногда и просто не могут - нет прав на установку OpenOffice, или нет интернета, чтобы его скачать и т.п., так как всегда пользовались только MS Office и его хватало на все нужды.
1. Наличие альтернативы дискредетирует саму идею стандартизации. Принцип ISO: "one standard, one test - accepted everywhere" (один стандарт, один тест - используется везде). Конечно это не реальное состояние дел, а идеал к которому ISO стремится, но это значит что всё, что этому идеалу не соответствует требует серъезного отдельного обоснования.
6. Это значит что OOXML не использует существующие стандарты, а содержит "в себе" их несовместимый аналог. Дальше - см. 1.
6. Это значит что OOXML не использует существующие стандарты, а содержит "в себе" их несовместимый аналог. Дальше - см. 1.
не совсем понимаю, что значит "несовместимый аналог" для даты и времени или обозначения языка - если формат известен, значит, всегда можно конвертировать из одного формата в другой. где тут несовместимость и конфликты?
"Несовместимый аналог" для даты - это дата измеряемая с 1го января 1990 года притом так, что она совпадает к григорианским календарём после 1 марта, а до 1го марта - идёт 29е февраля (считать это юлианским календарём тоже нельзя ибо дни недели с ним не совпадают). "Несовместимый стандарт" для обозначения языка - это перечень чисел в OOXML. Не секрет, что список языков - не есть величина постоянная (например филипинский язык получил своё ISO-название ("fil") только в 2004 году). Таким образом если не использовать ISO 639 (а OOXML его не использует), то потребуется всё время поддерживать в актуальном состоянии три таблицы: в ISO 639, в OOXML и таблицу соответствия. Ну и кому это надо ? Ясно кому: Microsoft'у. У него уже есть код, который как-то работает, переделывать его желания никакого нет. Нормальный такой подход для внутрифирменного стандарта, не претендующего на признание в ISO. Пусть он таким и дальше будет - никто ни в чём Microsoft обвинять не станет, только спасибо скажут...
Ну так по любому нет рабочего стандарта, ODF в виде ISO 26300 сейчас не поддерживается нике, текущая версия ODF 1.1 не является стандартом ISO. Пусть теперь попробует Microsoft ;-)
А почему вы так уверены, что "ODF в виде ISO 26300 сейчас не поддерживается никем" ? ODF 1.0, ODF 1.1 и ODF 1.2 - это на переходы a-la MS Word 95 => MS Word 97, когда от формата осталось одно название. Это достаточно прозрачное расширение. ODF 1.1 отличается от ODF 1.0 примерно настолько же, насколько формат, реально используемый в MS Office 2007, отличается от OOXML, описанный в пресловутых 6000 с лишним станицах документации. Так что попытку уже можно считать неудавшейся.
P.S. Объясните мне, идиоту, чем Microsoft лучше Sun'а попытку стандартизации Java которого "завернули", в частности, под речи про недопустимость ситуации, при которой одна компания разрабатывает стандарт ?
P.S. Объясните мне, идиоту, чем Microsoft лучше Sun'а попытку стандартизации Java которого "завернули", в частности, под речи про недопустимость ситуации, при которой одна компания разрабатывает стандарт ?
ODF 1.1 оазис не собирался стандартизовать, а собирался 1.2 - который правда еще не разработан. А ODF 1.0 не поддерживается никем просто в силу того, что все поддерживают что-то другое, похожее на него, но дополненное "от себя" в силу неполноты формата и не до конца реализовывают то, что описано в стандарте. Более того, нет двух независимых реализаций ODF которые бы были полностью совместимы. Т.е. этот формат в реальности принесет мало пользы в силу того, что он еще сырой, но очень уж хотелось авторам побиться в войнушку стандартизационную - поэтому и протащили его в ИСО.
А 6000 страниц это скорее благо всетаки, кстати, если Вы решите реализовать ODF то Вам придется реализовывать и то, на что он ссылается, а это, примерно, те же 6000 страниц - ну может немного больше.
Майкрософт лучше тем, что он не один разрабатывал этот стандарт - в его разработки принимал участие гораздо более широкий коллектив компаний, это не стандарт Майкрософта, это открытый стандарт ECMA, вообще-то. Кстати создателями ECMA был ИБМ :) т.е. прежде чем протестовать строем - полезно думать головой
А 6000 страниц это скорее благо всетаки, кстати, если Вы решите реализовать ODF то Вам придется реализовывать и то, на что он ссылается, а это, примерно, те же 6000 страниц - ну может немного больше.
Майкрософт лучше тем, что он не один разрабатывал этот стандарт - в его разработки принимал участие гораздо более широкий коллектив компаний, это не стандарт Майкрософта, это открытый стандарт ECMA, вообще-то. Кстати создателями ECMA был ИБМ :) т.е. прежде чем протестовать строем - полезно думать головой
А где можно подписать петицию ЗА OOXML?
Попытался было подписаться, а оказалось что уже подписывал, и было это уже ой как давно. Не опоздали? :)
Все-равно мелкомягкие будут все клепать по своим стандартам...
Я хотел бы напомнить народу о таком чудесном сайте, как:
http://ooxmlisdefectivebydesign.blogspot…
http://ooxmlisdefectivebydesign.blogspot…
Неактуальный баян полугодичной давности. http://habrahabr.ru/blog/open_source/179…
Ставлю минус. Даже некоторые комментарии слово в слово :)
Ставлю минус. Даже некоторые комментарии слово в слово :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
НЕТ формату Microsoft Office в качестве стандарта ISO