This site uses cookies.
Some of these cookies are essential to the operation of the site,
while others help to improve your experience by providing insights into how the site is being used.
For more information, please see the ProZ.com privacy policy.
English to Russian: A brief history of markup - Краткая история разметки веб-документов General field: Tech/Engineering Detailed field: IT (Information Technology)
Source text - English 1. A brief history of markup
HTML is the unifying language of the World Wide Web. Using simple tags this language contains, the human race has created an astoundingly diverse network of hyperlinked documents, from Amazon, eBay, and Wikipedia to personal blogs and websites dedicated to cats that look like Hitler.
HTML5 is the latest iteration of this lingua franca at the moment, and although this is the most ambitious change of our common tongue, it is not the first time HTML has been updated. The language has been evolving from the start.
As with the web itself, the HyperText Markup Language was the brainchild of Sir Tim Berners-Lee. In 1991 he wrote a document called “HTML Tags” in which he proposed fewer than two dozen elements that could be used for writing web pages.
Sir Tim didn’t come up with the idea of using tags consisting of words between angle brackets; those kinds of tags already existed in the SGML (Standard Generalized Markup Language) format. Rather than inventing a new standard, Sir Tim saw the benefit of building on top of what already existed — a trend that can still be seen in the development of HTML5.
From IETF to W3C: The Road to HTML 4
There was never any such thing as HTML 1. The first official specification was HTML 2.0, published by the IETF, the Internet Engineering Task Force. Many of the features in this specification were driven by existing implementations. For example, the market-leading Mosaic web browser of 1994 already provided a way for authors to embed images in their documents using an tag. The img element later appeared in the HTML 2.0 specification.
The role of the IETF was superceded by the W3C, the World Wide Web Consortium, where subsequent iterations of the HTML standard have been published at http://www.w3.org. The latter half of the nineties saw a flurry of revisions to the specification until HTML 4.01 was published in 1999.
At that time, HTML faced its first major turning point.
XHTML 1: HTML as XML
After HTML 4.01, the next revision to the language was called XHTML 1.0. The X stood for “eXtreme” and web developers were required to cross their arms in an X shape when speaking the letter.
No, not really. The X stood for “eXtensible” and arm crossing was entirely optional.
The content of the XHTML 1.0 specification was identical to that of HTML 4.01. No new elements or attributes were added. The only difference was in the syntax of the language. Whereas HTML allowed authors plenty of freedom in how they wrote their elements and attributes, XHTML required authors to follow the rules of XML, a stricter markup language upon which the W3C was basing most of their technologies.
Having stricter rules wasn’t such a bad thing. It encouraged authors to use a single writing style. Whereas previously tags and attributes could be written in uppercase, lowercase, or any combination thereof, a valid XHTML 1.0 document required all tags and attributes to be lowercase.
The publication of XHTML 1.0 coincided with the rise of browser support for CSS. As web designers embraced the emergence of web standards, led by The Web Standards Project, the stricter syntax of XHTML was viewed as a “best practice” way of writing markup.
Then the W3C published XHTML 1.1.
While XHTML 1.0 was simply HTML reformulated as XML, XHTML 1.1 was real, honest-to-goodness XML. That meant it couldn’t be served with a mime-type of text/html. But if authors published a document with an XML mime-type, then the most popular web browser in the world at the time — Internet Explorer — couldn’t render the document.
It seemed as if the W3C were losing touch with the day-to-day reality of publishing on the web.
XHTML 2: Oh, We're Not Gonna Take It!
If Dustin Hoffman’s character in The Graduate had been a web designer, the W3C would have said one word to him, just one word: XML.
As far as the W3C was concerned, HTML was finished as of version 4. They began working on XHTML 2, designed to lead the web to a bright new XML-based future.
Although the name XHTML 2 sounded very similar to XHTML 1, they couldn’t have been more different. Unlike XHTML 1, XHTML 2 wasn’t going to be backwards compatible with existing web content or even previous versions of HTML. Instead, it was going to be a pure language, unburdened by the sloppy history of previous specifications.
It was a disaster.
The Schism: WHATWG TF?
A rebellion formed within the W3C. A rebellion formed within the W3C. The consortium seemed to be formulating theoretically pure standards unrelated to the needs of web designers. Representatives from Opera, Apple, and Mozilla were unhappy with this direction. They wanted to see more emphasis placed on formats that allowed the creation of web applications.
Things came to a head in a workshop meeting in 2004. Ian Hickson, who was working for Opera Software at the time, proposed the idea of extending HTML to allow the creation of web applications. The proposal was rejected.
The disaffected rebels formed their own group: the Web Hypertext Application Technology Working Group, or WHATWG for short.
From Web Apps 1.0 to HTML5
From the start, the WHATWG operated quite differently than the W3C. The W3C uses a consensus-based approach: issues are raised, discussed, and voted on. At the WHATWG, issues are also raised and discussed, but the final decision on what goes into a specification rests with the editor. The editor is Ian Hickson.
On the face of it, the W3C process sounds more democratic and fair. In practice, politics and internal bickering can bog down progress. At the WHATWG, where anyone is free to contribute but the editor has the last word, things move at a faster pace. But the editor doesn’t quite have absolute power: an invitation-only steering committee can impeach him in the unlikely event of a Strangelove scenario.
Initially, the bulk of the work at the WHATWG was split into two specifications: Web Forms 2.0 and Web Apps 1.0. Both specifications were intended to extend HTML. Over time, they were merged into a single specification called simply HTML5.
Reunification
While HTML5 was being developed at the WHATWG, the W3C continued working on XHTML 2. It would be inaccurate to say that it was going nowhere fast. Was going nowhere very, very slowly.
In October 2006, Sir Tim Berners-Lee wrote a blog post in which he admitted that the attempt to move the web from HTML to XML just wasn’t working. A few months later, the W3C issued a new charter for an HTML Working Group. Rather than start from scratch, they wisely decided that the work of the WHATWG should be used as the basis for any future version of HTML.
All of this stopping and starting led to a somewhat confusing situation. The W3C was simultaneously working on two different, incompatible types of markup: XHTML 2 and HTML 5 (note the space before the number five). Meanwhile a separate organization, the WHATWG, was working on a specification called HTML5 (with no space) that would be used as a basis for one of the W3C specifications!
Any web designers trying to make sense of this situation would have had an easier time deciphering a movie marathon of Memento, Primer, and the complete works of David Lynch.
XHTML is Dead: Long Live the XHTML Syntax
The fog of confusion began to clear in 2009. The W3C announced that the charter for XHTML 2 would not be renewed. The format had been as good as dead for several years; this announcement was little more than a death certificate.
Strangely, rather than passing unnoticed, the death of XHTML 2 was greeted with some mean-spirited gloating. XML naysayers used the announcement as an opportunity to deride anyone who had ever used XHTML 1 — despite the fact that XHTML 1 and XHTML 2 have almost nothing in common.
Meanwhile, authors who had been writing XHTML 1 in order to enforce a stricter writing style became worried that HTML5 would herald a return to sloppy markup.
As you’ll soon see, that’s not necessarily the case. HTML5 is as sloppy or as strict as you want to make it.
The Timeline of HTML5
The current state of HTML5 isn’t as confusing as it once was, but it still isn’t straightforward.
There are two groups working on HTML5. The WHATWG is creating an HTML5 specification using its process of “commit then review.” The W3C HTML Working Group is taking that specification and putting it through its process of “review then commit.” As you can imagine, it’s an uneasy alliance.
Still, there seems to finally be some consensus about that pesky “space or no space?” question (it’s HTML5 with no space, just in case you were interested).
Perhaps the most confusing issue for web designers dipping their toes into the waters of HTML5 is getting an answer to the question, “when will it be ready?”
In an interview, Ian Hickson mentioned 2022 as the year he expected HTML5 to become a proposed recommendation [1]. What followed was a wave of public outrage from some web designers. They didn’t understand what “proposed recommendation” meant, but they knew they didn’t have enough fingers to count off the years until 2022.
The outrage was unwarranted. In this case, reaching a status of “proposed recommendation” requires two complete implementations of HTML5. Considering the scope of the specification, this date is incredibly ambitious. After all, browsers don’t have the best track record of implementing existing standards. It took Internet Explorer over a decade just to add support for the abbr element.
The date that really matters for HTML5 is 2012. That’s when the specification is due to become a “candidate recommendation.” That’s standards-speak for “done and dusted.”
But even that date isn’t particularly relevant to web designers. What really matters is when browsers start supporting features. We began using parts of CSS 2.1 as soon as browsers started shipping with support for those parts. If we had waited for every browser to completely support CSS 2.1 before we started using any of it, we would still be waiting.
It’s no different with HTML5. There won’t be a single point in time at which we can declare that the language is ready to use. Instead, we can start using parts of the specification as web browsers support those features.
Remember, HTML5 isn’t a completely new language created from scratch. It’s an evolutionary rather than revolutionary change in the ongoing story of markup. If you are currently creating websites with any version of HTML, you’re already using HTML5.
2. The Design of HTML5
The French Revolution was a an era of extreme political and social change. Revolutionary fervor was applied to time itself. For a brief period, the French Republic introduced a decimal time system, with each day divided into ten hours and each hour divided into one hundred minutes. It was thoroughly logical and clearly superior to the sexagesimal system.
Decimal time was a failure. Nobody used it. The same could be said for XHTML 2. The W3C rediscovered the lesson of post-revolutionary France: changing existing behavior is very, very difficult.
Design Principles
Keen to avoid the mistakes of the past, the WHATWG drafted a series of design principles to guide the development of HTML5. One of the key principles is to “Support existing content.” That means there’s no Year Zero for HTML5.
Where XHTML 2 attempted to sweep aside all that had come before, HTML5 builds upon existing specifications and implementations. Most of HTML 4.01 has survived in HTML5.
Some of the other design principles include “Do not reinvent the wheel,” and “Pave the cowpaths,” meaning, if there’s a widespread way for web designers to accomplish a task — even if it’s not necessarily the best way — it should be codified in HTML5. Put another way, “If it ain’t broke, don’t fix it.”
Many of these design principles will be familiar to you if you’ve ever dabbled in the microformats community (http://microformats.org). The HTML5 community shares the same pragmatic approach to getting a format out there, without worrying too much about theoretical problems.
This attitude is enshrined in the design principle of “Priority of constituencies,” which states, “In case of conflict, consider users over authors over implementers over specifiers over theoretical purity.”
Ian Hickson has stated on many occasions that browser makers are the real arbiters of what winds up in HTML5. If a browser vendor refuses to support a particular proposal, there’s no point in adding that proposal to the specification because then the specification would be fiction. According to the priority of constituencies, we web designers have an even stronger voice. If we refuse to use part of the specification, then the specification is equally fictitious.
Keeping it Real
The creation of HTML5 has been driven by an ongoing internal tension. On the one hand, the specification needs to be powerful enough to support the creation of web applications. On the other hand, HTML5 needs to support existing content, even if most existing content is a complete mess. If the specification strays too far in one direction, it will suffer the same fate as XHTML 2. But if it goes too far in the other direction, the specification will enshrine tags and tables for layout because, after all, that’s what a huge number of web pages are built with.
It’s a delicate balancing act that requires a pragmatic, levelheaded approach.
Error Handling
The HTML5 specification doesn’t just declare what browsers should do when they are processing well-formed markup. For the first time, a specification also defines what browsers should do when they are dealing with badly formed documents.
Until now, browser makers have had to individually figure out how to deal with errors. This usually involved reverse engineering whatever the most popular browser was doing — not a very productive use of their time. It would be better for browser makers to implement new features rather than waste their time duplicating the way their competitors handle malformed markup.
Defining error handling in HTML5 is incredibly ambitious. Even if HTML5 had exactly the same elements and attributes as HTML 4.01, with no new features added, defining error handling by 2012 would still be a Sisyphean task.
Error handling might not be of much interest to web designers, especially if we are writing valid, well-formed documents to begin with, but it’s very important for browser makers. Whereas previous markup specifications were written for authors, HTML5 is written for authors and implementers. Bear that in mind when perusing the specification. It explains why the HTML5 specification is so big and why it seems to have been written with a level of detail normally reserved for trainspotters who enjoy a nice game of chess while indexing their stamp collection.
Translation - Russian 1. Краткая история разметки веб-документов
HTML - это объединяющий язык Всемирной паутины. С помощью простых тегов, которые содержит этот язык, род человеческий создал поразительно разнообразную сеть документов, связанных между собой гиперссылками, от Amazon, eBay и Wikipedia до личных блогов и страничек, посвященных котикам, похожим на Гитлера.
HTML5 - это последняя итерация этого лингва-франка (языка международного общения) на данный момент, и хотя это самое амбициозное изменение нашего общего языка, HTML обновляется не в первый раз. Этот язык не перестает развиваться с самого начала.
Как и сам веб, язык гипертекстовой разметки, HyperText Markup Language, был детищем сэра Тима Бернерса-Ли. В 1991 году он написал документ под названием “теги HTML”, где предложил около двух десятков элементов, которые можно было бы использовать для написания веб-страниц.
Сэр Тим не придумал использовать теги, состоящие из слов в угловых скобках; такие теги уже существовали в формате SGML (Standard Generalized Markup Language). Вместо того чтобы изобретать новый стандарт, сэр Тим увидел выгоду в том, чтобы строить поверх того, что уже существовало, — тенденция, все еще заметная в развитии HTML5.
От IETF до W3C: дорога к HTML 4
Никогда не существовало такого предмета, как HTML 1. Первой официальной спецификацией был HTML 2.0, опубликованный IETF, Инженерным советом Интернета. Многие из пунктов в этой спецификации пришли из существующих реализаций. Например, ведущий на рынке веб-браузер Mosaic 1994 года уже предоставил авторам возможность вставлять изображения в документы с помощью тега . Позже элемент img появился в спецификации HTML 2.0.
На смену IETF пришел W3C, Консорциум Всемирной паутины (World Wide Web Consortium), который публиковал последовательные обновления стандарта HTML на сайте http://www.w3.org. Во второй половине девяностых годов произошел шквал изменений в спецификации, пока в 1999 году не был опубликован HTML 4.01.
В это время HTML встретился с первым из своих важнейших поворотных моментов.
XHTML 1: HTML как XML
После HTML 4.01 следующая редакция языка называлась XHTML 1.0. Буква X означала "экстремальный", и веб-разработчики должны были скрещивать руки в форме буквы X, когда произносили эту букву.
Нет, не совсем так. Буква Х означала eXtensible (расширяемый), а скрещивать руки было совершенно необязательно.
Содержание спецификации XHTML 1.0 было идентично содержанию спецификации HTML 4.01. Никаких новых элементов или атрибутов добавлено не было. Единственное различие заключалось в синтаксисе языка. В то время как HTML предоставлял авторам большую свободу в том, как они писали свои элементы и атрибуты, XHTML требовал от авторов следовать правилам XML, более строгого языка разметки, на котором W3C основывал большинство своих технологий.
Иметь более строгие правила было не так уж плохо. Это поощряло авторов использовать единый стиль письма. Если раньше теги и атрибуты можно было писать прописными, строчными буквами или любой их комбинацией, то для того чтобы документ XHTML 1.0 проходил валидацию, требовалось, чтобы все его теги и атрибуты были написаны в нижнем регистре.
Публикация стандарта XHTML 1.0 совпала с началом поддержки браузерами CSS. Поскольку веб-дизайнеры поддерживали появление веб-стандартов во главе с проектом Web Standards Project, более строгий синтаксис XHTML рассматривался как “лучший практический” способ написания разметки.
Затем W3C опубликовал XHTML 1.1.
Тогда как XHTML 1.0 был просто HTML, переписанный средствами XML, то XHTML 1.1 был настоящим, честным XML. Это означало, что сервер не мог отдавать его с MIME-типом text/html. Но если же авторы публиковали документ с MIME-типом XML, то самый распространенный браузер в мире на тот момент – Internet Explorer – вовсе не мог отобразить документ.
Казалось, что W3C теряет связь с повседневной реальностью публикации в интернете.
XHTML 2: О, мы его не возьмем!
Если бы персонаж Дастина Хоффмана в "Выпускнике" был веб-дизайнером, W3C сказал бы ему одно слово, только одно слово: XML.
Что касается W3C, то HTML закончился на версии 4. W3C начал работать над XHTML 2, предназначенным для того, чтобы вести веб в светлое новое будущее, основанное на XML.
Хотя название XHTML 2 звучало очень похоже на XHTML 1, они не могли быть более разными. В отличие от XHTML 1, XHTML 2 не было предусмотрено обратной совместимости с существующим веб-контентом или хотя бы с предыдущими версиями HTML. Вместо этого планировалось, что XHTML 2 будет чистым языком, не обремененным неряшливым прошлым предыдущих спецификаций.
Это была катастрофа.
Раскол: WHATWG TF?
Внутри W3C возникло восстание. Внутри W3C возникло восстание. Казалось, что Консорциум, разрабатывал теоретически чистые стандарты, не связанные с потребностями веб - дизайнеров. Представители Opera, Apple и Mozilla были недовольны этим направлением. Они хотели, чтобы больше внимания уделялось форматам, которые позволяют создавать веб-приложения.
Дело дошло до кульминации на семинаре-совещании в 2004 году. Ян Хиксон, который в то время работал в Opera Software, предложил идею расширения HTML для создания веб-приложений. Это предложение было отклонено.
Недовольные повстанцы сформировали свою собственную группу: рабочую группу по технологии веб-гипертекстовых приложений, Web Hypertext Application Technology Working Group, или сокращенно WHATWG.
От Web Apps 1.0 к HTML5
С самого начала WHATWG действовал совершенно иначе, чем W3C. W3C использует подход, основанный на консенсусе: вопросы поднимаются, обсуждаются и голосуются. На WHATWG также поднимаются и обсуждаются вопросы, но окончательное решение о том, что входит в спецификацию, остается за редактором. Редактор - Ян Хиксон.
На первый взгляд, процедура W3C более демократична и справедлива. На практике интриги и внутренние распри могут тормозить движение вперед. В WHATWG, где каждый может внести свой вклад, но последнее слово остается за редактором, все движется более быстрыми темпами. Но редактор не обладает абсолютной властью: собранный только по личным приглашениям руководящий комитет может объявить ему импичмент в маловероятном случае повторения сценария с доктором Стрейнджлав.
Первоначально основная часть работ в WHATWG была разделена на две спецификации: Web Forms 2.0 и Web Apps 1.0. Обе спецификации были предназначены для расширения HTML. Со временем они были объединены в единую спецификацию, называемую просто HTML5.
Воссоединение
В то время как HTML5 разрабатывался в WHATWG, W3C продолжал работать над XHTML 2. Было бы неверно сказать, что он быстро шел в никуда. Он двигался в никуда очень, очень медленно.
В октябре 2006 года сэр Тим Бернерс-Ли написал пост в блоге, в котором признался, что попытка заставить веб перейти с HTML на XML просто не сработала. Несколько месяцев спустя W3C выпустил новый устав для рабочей группы по HTML. Вместо того чтобы начинать с нуля, W3C мудро решил, что работа WHATWG должна быть использована в качестве основы для любой будущей версии HTML.
Все эти "стоп" и "старт" привели к несколько запутанной ситуации. W3C одновременно работал над двумя различными, несовместимыми типами разметки: XHTML 2 и HTML 5 (обратите внимание на пробел перед цифрой пять). Тем временем отдельная организация, WHATWG, работала над спецификацией под названием HTML5 (без пробела), которая будет использоваться в качестве основы для одной из спецификаций W3C!
Любому веб-дизайнеру, пытающемуся разобраться в этой ситуации, было бы легче расшифровать киномарафон из «Мементо», «Детонатора» и полной кинематографии Дэвида Линча.
XHTML мертв: да здравствует синтаксис XHTML
Туман путаницы начал рассеиваться в 2009 году. W3C объявил, что устав для XHTML 2 не будет продлен. Формат XHTML 2 уже несколько лет считался мертвым; это объявление было не более чем свидетельством о смерти.
Как ни странно, смерть XHTML 2 не осталась незамеченной, а была встречена с каким-то подлым злорадством. XML-скептики использовали это объявление как возможность высмеять любого, кто когда-либо использовал XHTML 1, несмотря на то, что XHTML 1 и XHTML 2 не имеют почти ничего общего.
Тем временем авторы, которые писали XHTML 1 для того, чтобы обеспечить более строгий стиль написания, забеспокоились, что HTML5 возвестит о возвращении к небрежной разметке.
Как вы скоро увидите, это не обязательно так. HTML5 настолько небрежен или строг, насколько вы хотите его таким сделать.
Развитие HTML5
Нынешнее состояние HTML5 уже не так запутанно, как когда-то раньше, но оно все еще не является простым.
Есть две группы, работающие над HTML5. WHATWG создает спецификацию HTML5, пользуясь своим методом "принять, затем пересмотреть". В W3C рабочая группа по HTML берет эту спецификацию и пропускает ее через свою процедуру "пересмотреть, затем принять". Как вы можете себе представить, это непростой союз. Тем не менее, кажется, наконец-то есть какой-то консенсус по поводу этого надоевшего вопроса “с пробелом или без пробела?” (это HTML5 без пробела - на всякий случай, если вам интересно).
Пожалуй, самая запутанная проблема для веб-дизайнеров, которые пробуют кончиком ноги воду HTML5, - это получение ответа на вопрос: “Когда он будет готов?”
В одном из интервью Ян Хиксон упомянул 2022 год как год, когда он надеется, что HTML5 станет предлагаемой рекомендацией [1]. За этим последовала волна общественного возмущения со стороны некоторых веб-дизайнеров. Они не понимали, что означает “предлагаемая рекомендация”, но знали, что у них не хватит пальцев на руках, чтобы отсчитать годы до 2022 года.
Возмущение было неоправданным. В этом случае достижение статуса “предложенной рекомендации” требует двух полных реализаций HTML5. Учитывая объем спецификации, эта дата невероятно амбициозна. В конце концов, у браузеров не самая лучшая репутация в плане реализации существующих стандартов. Браузеру Internet Explorer потребовалось более десяти лет, чтобы добавить поддержку элемента abbr.
Дата, которая действительно имеет значение для HTML5, - это 2012 год. Именно тогда спецификация должна стать "претендующей на рекомендацию". На жаргоне стандартов это означает "сделали и сдули пылинки".
Но даже эта дата не особенно актуальна для веб-дизайнеров. Что действительно важно, так это когда браузеры начнут поддерживать функции. Мы начали использовать части CSS 2.1, как только начали поставляться браузеры с поддержкой этих частей. Если бы мы ждали, когда каждый браузер полностью поддержит CSS 2.1, прежде чем начать использовать какую-то часть CSS 2.1, мы бы все еще ждали.
Не иначе с HTML5. Никогда не наступит один единственный момент времени, в который мы могли бы объявить, что язык готов к использованию. Вместо этого мы можем начинать использовать части спецификации по мере того, как веб-браузеры будут поддерживать эти функции.
Помните, что HTML5 - это не полностью новый язык, созданный с нуля. Это скорее эволюционное, чем революционное, изменение в продолжающейся истории разметки веб-документов. Если вы сейчас создаете веб-сайты с любой версией HTML, то вы уже используете HTML5.
2. Дизайн HTML5
Французская революция была эпохой крайних политических и социальных перемен. Революционный пыл был приложен к самому времени. На короткое время Французская республика ввела десятичную систему времени, в которой каждый день делился на десять часов, а каждый час - на сто минут. Она была полностью логична и явно превосходила шестидесятеричную систему.
Десятичное время оказалось неудачным. Никто им не пользовался. То же самое можно сказать и о XHTML 2. W3C заново открыл для себя урок послереволюционной Франции: изменить существующее поведение очень и очень трудно.
Принципы проектирования
Стремясь избежать ошибок прошлого, WHATWG составила ряд принципов проектирования, которыми она руководствуется при разработке HTML5. Один из ключевых принципов - "Поддерживать существующий контент". Это означает, что с HTML5 не начинается новая эра.
Там, где XHTML 2 пытался отбросить все, что было раньше, HTML5 строится на существующих спецификациях и реализациях. Большая часть HTML 4.01 сохранилась в HTML5.
Из других принципов проектирования есть "Не изобретайте колесо" и "Асфальтируйте тропинки", означающие, что если есть широко распространенный способ для веб-дизайнеров выполнить задачу — даже если это не обязательно лучший способ - он должен быть кодифицирован в HTML5. Иначе говоря, "Если не сломано, не чините".
Многие из этих принципов проектирования будут знакомы вам, если вы когда-либо пробовали себя в сообществе микроформатов (http://microformats.org) Сообщество HTML5 разделяет тот же прагматический подход к получению формата, не слишком беспокоясь о теоретических проблемах.
Это отношение закреплено в принципе проектирования “Приоритета пользователей”, который гласит: "В случае конфликта ставьте интересы пользователей выше интересов разработчиков, разработчиков – выше конкретных реализаций, реализации – выше спецификаций, спецификации – выше теоретической чистоты."
Ян Хиксон неоднократно заявлял, что создатели браузеров являются настоящими арбитрами того, что окажется в HTML5, а что нет. Если поставщик браузера отказывается поддержать конкретное предложение, нет смысла добавлять это предложение в спецификацию, потому что тогда спецификация будет фикцией. Согласно приоритету пользователей, мы, веб-дизайнеры, имеем даже более сильный голос. Если мы отказываемся использовать часть спецификации, то спецификация в равной степени фиктивна.
Ближе к реальности
Создание HTML5 было вызвано постоянным внутренним напряжением. С одной стороны, спецификация должна быть достаточно мощной, чтобы поддерживать создание веб-приложений. С другой стороны, HTML5 должен поддерживать существующий контент, даже если большинство существующего контента представляет собой полный беспорядок. Если спецификация отклонится слишком далеко в одном направлении, ее постигнет та же участь, что и XHTML 2. Но если она зайдет слишком далеко в другом направлении, то спецификация закрепит теги и таблицы для разметки, потому что, в конце концов, именно с ними строится огромное количество веб-страниц.
Это тонкое балансирование, которое требует прагматичного, уравновешенного подхода.
Обработка ошибок
Спецификация HTML5 не просто объявляет, что браузеры должны делать, когда они обрабатывают синтаксически правильную разметку. Впервые спецификация также определяет, что браузеры должны делать, когда они имеют дело с документами, содержащими синтаксические ошибки.
До сих пор создателям браузеров приходилось каждому самостоятельно решать, что делать с ошибками. Обычно это означало, что нужно было применять реверс-инжиниринг и реализовывать примерно то, что делал в случае ошибок самый популярный браузер — не очень продуктивное использование своего времени. Для производителей браузеров было бы лучше реализовать новые функции, а не тратить свое время на дублирование того, как их конкуренты обрабатывают синтаксически ошибочную разметку.
Определение обработки ошибок в HTML5 невероятно амбициозно. Даже если бы HTML5 имел точно такие же элементы и атрибуты, как HTML 4.01, без добавления новых функций, определение обработки ошибок к 2012 году все равно было бы сизифовой задачей.
Обработка ошибок может не представлять особого интереса для веб-дизайнеров, особенно если мы пишем валидные, синтаксически правильные документы, но это очень важно для разработчиков браузеров. В то время как предыдущие спецификации разметки были написаны для авторов, HTML5 написан для авторов и разработчиков. Имейте это в виду при ознакомлении со спецификацией. Это объясняет, почему спецификация HTML5 так велика и почему она, кажется, была написана с уровнем детализации, обычно зарезервированным для буквоедов, наслаждающихся шахматной игрой во время индексации своей коллекции марок.
German to English: Mechanical properties General field: Tech/Engineering Detailed field: Mechanics / Mech Engineering
Source text - German Eigenschaften der Werkstoffe
Um beurteilen zu können, ob sich ein Werkstoff für eine bestimmte Anwendung eignet, müssen seine physikalischen, mechanischen, technologischen und chemischen Eigenschaften bekannt sein. Beispiele für wichtige Werkstoffeigenschaften enthält Tabelle 1. Diese Eigenschaften hängen vom inneren Aufbau des Werkstoffs ab, der sich durch das Herstellungsverfahren und die Verarbeitung verändern und auch gezielt beeinflussen lässt.
Die mechanischen Eigenschaften bestimmen in wesentlicher Weise den Einsatz eines Werkstoffes in Konstruktionen, da sie Aussagen darüber liefern, welche Belastungen der Werkstoff ohne Schädigung ertragen kann.
Mechanische Werkstoffkennwerte
Eine der wichtigsten Kenngrößen ist die Festigkeit. Ganz allgemein ist darunter der Widerstand zu verstehen, den ein Werkstoff einer Formänderung durch äußere Kräfte entgegensetzt. Bekannt ist, dass bei einem festen, harten Werkstoff von außen eine große Kraft für die Formänderung, z. B. Verbiegen, aufgebracht werden muss. Bei einem weichen Material genügt dafür hingegen eine kleinere äußere Kraft.
Die Festigkeit eines Werkstoffes ist der Widerstand gegen eine äußere Verformung.
Je nachdem, wie der Werkstoff belastet wird, werden unterschiedliche Festigkeitswerte betrachtet:
Abschleppseile, Ketten oder auch Schrauben sind typische Beispiele für eine Zugbelastung eines Werkstoffes. In diesen Fällen ist die Bestimmung der Zugfestigkeit wichtig. Gemäß DIN EN 10 002 wird das zu prüfende Material in seiner Längsrichtung durch Zugkräfte bis zum Bruch beansprucht (Bild 1).
Lagerwerkstoffe, Fundamente oder Maschinengestelle werden hingegen auf Druck beansprucht. Hier gilt der Ermittlung der Druckfestigkeit (DIN 50 106) besonderes Interesse. Bestimmt wird die Widerstandsfähigkeit von Werkstoffen gegen Druckkräfte (Bild 2).
Bei der Festlegung der Scherfestigkeit (nach DIN 50 141) wird der Widerstand vermittelt, den der Werkstoff einer Verschiebung in einer Querschnittsfläche entgegensetzt. Dabei tritt eine Schubbeanspruchung ein. Diese Belastungsform findet sich beim Abscheren von Blechen oder der Beanspruchung von Nieten (Bild 3, Seite 10).
Träger in Konstruktionen werden vielfach auf Biegung beansprucht. Zur sicheren Auslegung muss daher die Biegefestigkeit (Bild 1) bekannt sein. Bestimmt wird der Widerstand, den Werkstücke bei einer Durchbiegung zeigen. Der Werkstoff wird dazu an einer Seite auf Zug und auf der anderen Seite auf Druck belastet.
Sich drehende Bauteile, wie z. B. Schnittswellen, Kurbelwellen oder Bohrer, müssen einer Torsionsbelastung standhalten. Bei der in diesem Fall notwendigen Prüfung der Torsionsfähigkeit (Bild 2) wird der Widerstand ermittelt, den ein Werkstück gegenüber verdrehenden Kräften zeigt.
An schlanken Bauteilen, z. B. Pleuelstangen und Fachwerkstreben oder auch an ganzen schlanken Konstruktionen, wie z. B. Leitungsmasten, ist der Widerstand gegen Knicken von Interesse. An den Bauteilen können hier Druckkräfte in Richtung der Längsachse angreifen, bis eine Ausknickung oder der Bruch erfolgt. Bei der Bestimmung der Knickfestigkeit (Bild 3) werden die Werkstücke dabei vorwiegend auf Zug und auf Druck beansprucht.
Die bisher gezeigten Kenngrößen bezogen sich alle auf die Festigkeit des Werkstoffes. Aber auch das Verformungsverhalten eines Werkstoffes kann wichtig sein, z. B. dann, wenn er noch weiter verformt werden soll.
Die Dehnbarkeit (Dehnung) eines Werkstoffes ist seine Fähigkeit, bei einer Krafteinwirkung seine Form zu verändern (Bild 4).
Gut vorstellen lässt sich dies am Beispiel der Dehnung eines Gummibandes. Die bei einem Gummiband beim Dehnen efolgte Verformung ist elastisch, d. h., nach Entlastung nimmt der Werkstoff seine ursprüngliche Form wieder an (Bild 5). Dementsprechend wird unter der Elastizität eines Werkstoffes die Eigenschaft verstanden, nach einer Belastung wieder die Ausgangsform anzunehmen. Gummi, Kautschuk und sogar Stahl sind innerhalb bestimmter Grenzen unterschiedlich elastisch.
Ist eine Verformung hingegen dauerhaft, d. h. bleibt sie auch nach Entlastung erhalten, spricht man von einer plastischen Verformung (Bild 6). Beispielsweise kann eine metallische Feder durch eine zu große Kraft überdehnt und damit bleibend verformt werden.
Die „zu große Kraft“, die zur bleibenden Formänderung führt, wird durch die Elastizitätsgrenze gekennzeichnet – eine Kenngröße, die z. B. im Zugversuch als Dehngrenze bestimmt wird. Die Kenntnis der Elastizitätsgrenze ist notwendig, um eine tragende Konstruktion nicht zu großen Kräften auszusetzen, die zu Formänderungen führen würden. Im Fall einer gewünschten Formänderung, beispielsweise beim Hämmern eines Metalls in eine bestimmte Form, muss hingegen eine Kraft über der Elastizitätsgrenze angewendet werden.
Eine Verformung kann plastisch (bleibend, irreversibel) oder elastisch (nicht bleibend, reversibel) erfolgen.
Werkstoffe können sich bei Umformungen sehr unterschiedlich verhalten. Zähe Werkstoffe wie reines Blei oder Kupfer können bei einer Krafteinwirkung vor der Zerstörung erhebliche Formänderungen hinnehmen. Dieses Verhalten wird als Zähigkeit bezeichnet.
Spröde Werkstoffe, wie Glas, Keramik oder Grauguss zeigen bei einer Krafteinwirkung bis zur Zerstörung keine bleibende Formänderung. Sie brechen bei einer bestimmten Kraft, ohne sich vorher zu dehnen, man spricht von Sprödigkeit.
Auch die Härte gestattet Aussagen über die Festigkeit eines Werkstoffes. Unter der Härte wird der Widerstand verstanden, den ein Material dem Eindringen eines anderen härteren Körpers entgegensetzt (Bild 1). Diamant ist z. B. sehr hart, Blei ist hingegen sehr weich.
Mechanische Kennwerte für die genannten Eigenschaften werden in der Regel mit genormten Prüfverfahren ermittelt. Nachfolgend sollen hier beispielhaft die für das Verständnis wichtigsten Verfahren beschrieben werden. Für weitere und spezielle Prüfverfahren sei auf die entsprechenden Normen und auf Literatur verwiesen.
Translation - English Properties of materials
In order to be able to assess whether a material is suitable for a particular application, its physical, mechanical, technological and chemical properties must be known. Table 1 contains examples of important material properties. These properties depend on the internal structure of the material, which can be changed and specifically influenced by the manufacturing methods and processing.
Mechanical properties essentially determine the applications of a material in constructions, since they provide information about the loads the material can withstand without damage.
Mechanical material parameters
One of the most important parameters is strength. Quite generally, it is to be understood as the resistance that a material opposes to a change in shape caused by external forces. It is known that with a solid, hard material a great force must be applied from the outside for a large force for change in shape, eg bending. With a soft material, however, a smaller external force is sufficient.
The strength of a material is the resistance to external deformation.
Depending on how the material is loaded, different strength values are considered:
Tow ropes, chains or screws are typical examples of a tensile load on a material. In these cases, determining the tensile strength is important. According to DIN EN 10 002, the material to be tested is subjected to tensile forces in its longitudinal direction until it breaks (Fig. 1).
Bearing materials, foundations or machine frames, on the other hand, are subjected to pressure. The determination of the compressive strength (DIN 50 106) is of particular interest here. The resistance of materials to compressive forces is determined (Fig. 2).
When determining shear strength (in accordance with DIN 50 141), the resistance that the material opposes to a displacement in a cross-sectional area is conveyed. A shear stress occurs. This type of load occurs when sheet metal is sheared off or rivets are loaded (Fig. 3, page 10).
Beams in structures are often subjected to bending. The flexural strength (Fig. 1) must therefore be known for a safe design. The resistance that workpieces show when they deflect is determined. The material is subjected to tension on one side and compression on the other side.
Rotating components, such as cut shafts, crankshafts or drills have to withstand a torsional load. During the test of the torsional ability (Fig. 2), which is necessary in this case, the resistance that a workpiece shows against twisting forces is determined.
On slender components, connecting rods and truss struts or even on whole slender structures, such as line poles, resistance to buckling is of interest. Here, compressive forces in the direction of the longitudinal axis can act on the components until they are bent or broken. When determining the buckling strength (Fig. 3), the workpieces are mainly subjected to tension and compression.
The parameters shown so far all related to the strength of the material. But the deformation behavior of a material can also be important, for example when it is to be further deformed.
The ductility (elongation) of a material is its ability to change its shape when a force is applied (Fig. 4).
This can be easily imagined using the example of the stretching of a rubber band. The deformation that occurs in a rubber band when it is stretched is elastic; in other words, after the unloading, the material returns to its original shape (Fig. 5). Accordingly, the elasticity of a material is understood as the property of returning to its original shape again when unloaded. Rubber, elastomer and even steel are differently elastic within certain limits.
If, however, a deformation is permanent, i.e. it is retained even after the load is removed, it is referred to as plastic deformation (Fig. 6). For example, a metallic spring can be overstretched by too great a force and thus permanently deformed.
The force that is "too great" and leads to permanent change in shape is characterized by the elastic limit - a parameter that is determined, for example as the yield strength in the tensile test. Knowledge of the elastic limit is necessary in order not to subject a load-bearing structure to excessive forces that would lead to changes in shape. In the case of a desired change in shape, for example when hammering a metal into a certain shape, a force above the elastic limit must be applied.
Deformation can be plastic (permanent, irreversible) or elastic (non-permanent, reversible).
Materials can behave very differently during forming. Tough materials such as pure lead or copper can undergo considerable changes in shape when a force is applied before they are destroyed. This behavior is referred to as toughness.
Brittle materials such as glass, ceramics or gray cast iron show no permanent change in shape when force is applied until they are destroyed. They break at a certain force without stretching beforehand; one speaks of brittleness.
The hardness also allows statements about the strength of a material. Hardness is understood as the resistance that a material offers to the penetration of another, harder body (Fig. 1). For example diamond is very hard, but lead is very soft.
Mechanical parameters for the properties mentioned are usually determined using standardized test methods. The most important procedures for understanding are described below as examples. For further and special test methods, reference is made to the relevant standards and literature.
More
Less
Experience
Years of experience: 18. Registered at ProZ.com: Nov 2020. Became a member: Nov 2020.
Adobe Photoshop, CafeTran Espresso, Microsoft Excel, Microsoft Word, Powerpoint, SDL TRADOS, Smartcat
CV/Resume
CV available upon request
Bio
Grown up in a bilingual (Russian - German) family, I studied metallurgy at Krasnoyarsk State University of Non-Ferrous Metals (Russia), and computer sciences at Berlin Technical University. I have a good understanding of technical and scientific texts, and translate them using correct terminologies.