Почему бы не использовать таблицы для разметки в HTML? [закрыто]
mysql_insert_id дает вам идентификатор вставки последнего оператора INSERT в соединении, которое вы ему даете.
Если вы вызываете это сразу после своей вставки, в том же соединении mysql, вы получаете вставленный идентификатор, соответствующий этому вставному оператору, независимо от любых других вставок, проходящих в среднем времени.
55 ответов
К сожалению, CSS Zen-Garden больше не может использоваться в качестве примера хорошего дизайна HTML/CSS. Фактически все их недавние проекты используют графику для заголовка раздела. Эти графические файлы определяются в CSS.
Следовательно, веб-сайт, цель которого состоит в том, чтобы показать преимущество хранения дизайна из содержания, теперь регулярно фиксирует ОТВРАТИТЕЛЬНЫЙ ГРЕХ помещения содержания в дизайн. (Если заголовок раздела в файле HTML должен был измениться, отображенный заголовок раздела не был бы).
, Который только идет, чтобы показать, что даже те защищают строгий DIV & религия CSS, не может следовать их собственным правилам. Можно использовать это в качестве инструкции в том, как тесно Вы следуете за ними.
Это не категорический аргумент, каким-либо образом, но с CSS можно взять ту же разметку и изменить расположение в зависимости от носителя, который является хорошим преимуществом. Для страницы печати можно бесшумно подавить навигацию, не имея необходимость создавать страницу для печати, например.
Одна таблица для расположения не была бы этим плохо. Но Вы не можете получить расположение, в котором Вы нуждаетесь со всего одной таблицей большую часть времени. Довольно скоро у Вас есть 2 или три вложенных таблицы. Это становится очень громоздким.
-
НАМНОГО более трудно читать. Это не до мнения. Там только больше вложил теги без опознавательных знаков на них.
-
Разделение содержания от представления является хорошей вещью, потому что это позволяет Вам фокусироваться на том, что Вы делаете. Смешивание этих двух приводит к чрезмерно увеличенным в размерах страницам, которые трудно прочитать.
-
CSS для стилей позволяет Вашему браузеру кэшировать файлы, и последующие запросы намного быстрее. Это ОГРОМНО.
-
Таблицы блокируют Вас в дизайн. Несомненно, не всем нужна гибкость CSS Zen-Garden, но я никогда не работал над сайтом, где я не должен был изменять дизайн немного тут и там. Это намного легче с CSS.
-
Таблицы трудно разработать. У Вас нет особой гибкости с ними (т.е. все еще необходимо добавить HTML-атрибуты, чтобы полностью управлять стилями таблицы)
, я не использовал таблицы для нетабличных данных за, вероятно, 4 года. Я не оглянулся назад.
я действительно хотел бы предложить читать CSS Мастерство Andy Budd. Это фантастически.
Вот раздел HTML из недавнего проекта:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>{DYNAMIC(TITLE)}</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
<div id="header">
<h1><!-- Page title --></h1>
<ol id="navigation">
<!-- Navigation items -->
</ol>
<div class="clearfix"></div>
</div>
<div id="sidebar">
<!-- Sidebar content -->
</div>
<!-- Page content -->
<p id="footer"><!-- Footer content --></p>
</body>
</html>
И вот тот же самый код как основанное на таблице расположение.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>{DYNAMIC(TITLE)}</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
<table cellspacing="0">
<tr>
<td><!-- Page Title --></td>
<td>
<table>
<tr>
<td>Navitem</td>
<td>Navitem</td>
</tr>
</table>
</td>
</tr>
</table>
<table>
<tr>
<td><!-- Page content --></td>
<td><!-- Sidebar content --></td>
</tr>
<tr>
<td colspan="2">Footer</td>
</tr>
</table>
</body>
</html>
единственная чистота я вижу, в котором основанное на таблице расположение является тем, что я фанатичен со своим добавлением отступа. Я уверен, что довольное раздел имело бы еще две встроенных таблицы.
Другая вещь думать о: размеры файла . Я нашел, что основанные на таблице разметки являются дважды размером своих дубликатов CSS обычно. На нашей широкополосной связи hig-скорости, которая не является огромной проблемой, но это находятся на тех с набором модемы.
Я хотел бы добавить, что основанные на отделении разметки являются easer, чтобы поддержать, развить, и осуществить рефакторинг. Просто некоторые изменения в CSS для переупорядочения элементов и это сделано. На основе моего опыта перепроектируйте расположение, что таблицы использования являются кошмаром (больше, если существуют вложенные таблицы).
Ваш код также имеет значение от семантический точка зрения.
Никакие аргументы в ОТДЕЛЕНИЯХ не способствуют от меня.
я сказал бы: Если обувь соответствует, носите ее.
стоит отметить, что это трудно, если не невозможный найти хороший метод DIV+CSS рендеринга содержания в двух или трех столбцах, который последователен на всех браузерах, и все еще смотрит просто способ, которым я предназначил.
Это склоняет чашу весов немного к таблицам в большинстве моих разметок, и хотя я чувствую себя виновным в использовании их (dunny, почему, люди просто говорят, что это плохо, таким образом, я пытаюсь слушать их), в конце, прагматическое представление, это просто легче и быстрее для меня для использования ТАБЛИЦ. Мне не платят по часам, таким образом, таблицы являются более дешевыми для меня.
Разметки CSS обычно намного лучше для доступности, если содержание прибывает в естественный порядок и имеет смысл без таблицы стилей. И это не просто программы экранного доступа, которые борются с основанными на таблице разметками: они также делают его намного тяжелее для мобильных браузеров для рендеринга страницы правильно.
кроме того, с основанным на отделении расположением можно очень легко сделать прохладные вещи с таблицей стилей печати такой как, исключая заголовки, нижние колонтитулы и навигацию от печатных страниц - я думаю, что это было бы невозможным, или по крайней мере намного более трудным, чтобы сделать это с основанным на таблице расположением.
, Если Вы сомневаетесь, что разделение содержания от расположения легче с отделениями, чем с таблицами, смотрите на основанный на отделении HTML в CSS Zen-Garden , посмотрите, как изменение таблиц стилей может решительно изменить расположение, и думать о том, могли ли Вы достигнуть того же множества разметок, если HTML был базирующейся таблицей... При выполнении основанного на таблице расположения Вы вряд ли будете использовать CSS для управления всем интервалом и дополнением в ячейках (если бы Вы были, Вы почти наверняка нашли бы легче использовать плавающие отделения и т.д. во-первых). Не используя CSS для управления всем этим, и из-за того, что таблицы определяют слева направо и порядок от начала до конца вещей в HTML таблицы имеют тенденцию означать, что расположение становится очень зафиксированным в HTML.
Реалистично я думаю, что очень трудно полностью изменить расположение дизайна div-and-CSS-based, не изменяя отделения немного. Однако с div-and-CSS-based расположением намного легче настроить вещи как интервал между различными блоками и их относительные размеры.
я предполагаю, что это верно, что использование элемента таблицы для расположения имеет мало общего с табличными данными.И что же? Мой босс заботится? Мои пользователи заботятся?
Google и другие автоматизированные системы делают уход, и они так же важны во многих ситуациях. Семантический код легче для неинтеллектуальной системы проанализировать и обработать.
Имение для работы с веб-сайтом, который включил 6 слоев вложенных таблиц, сгенерированных некоторым приложением, и имевший его, генерирует недопустимый HTML, это было на самом деле 3-часовое задание для исправления его повреждающийся для незначительного изменения.
Это - конечно, пограничный случай, но основанный на таблице дизайн неудобен в сопровождении. При использовании css Вы выделяете стиль поэтому при фиксации HTML, который у Вас есть меньше для волнения по поводу повреждения.
кроме того, попробуйте это JavaScript. Переместите отдельную ячейку от одного места до другого места в другой таблице. Скорее сложный для выполнения, где отделение/промежуток было бы просто work copy-paste-wise.
"Делает мой уход босса"
, Если я был Вашим боссом. Вы заботились бы.;), Если Вы оцениваете свою жизнь.
Огромная проблема для меня - то, что таблицы, особенно вложенные таблицы, берут намного дольше для рендеринга, чем правильно размеченная css реализация. (Вы можете заставлять css столь же замедлиться).
Все браузеры представляют css быстрее, потому что каждое отделение является отдельным элементом, таким образом, экран может загружаться, поскольку пользователь читает. (Для огромных наборов данных, и т.д.). Я использовал css вместо таблиц в том экземпляре, даже не имеющем дело с расположением.
вложенная таблица А (таблицы в ячейках, и т.д.) не представит к окну браузера, пока последнее "/таблица" не будет найдено. Еще хуже - плохо определенная таблица даже не будет иногда представлять! Или когда это делает, вещи неправильно себя ведут. (не colspanning правильно с "TD" и т.д.)
я использую таблицы для большинства вещей, но когда дело доходит до больших данных и требования иметь экранный рендеринг быстро для конечного пользователя - я стараюсь изо всех сил использовать то, что должен предложить CSS.
Таблицы не в общем легче или более удобны в сопровождении, чем CSS. Однако существуют некоторые конкретны проблемы расположения, где таблицы являются действительно самым простым и наиболее гибким решением.
CSS явно предпочтителен в случаях, где представляемая разметка и CSS поддерживают тот же вид дизайна, никто в их правильном уме не утверждал бы, что font - теги лучше, чем определение книгопечатания в CSS, так как CSS дает Вам то же питание, чем font - теги, но намного более чистым способом.
проблема с таблицами, однако, в основном, что модель макета таблицы в CSS не поддерживается в Microsoft Internet Explorer. Таблицы и CSS поэтому не эквивалентны в питании. Недостающая часть подобное сетке поведение из таблиц, где края ячеек выравниваются и вертикально и горизонтально, в то время как ячейки все еще расширяются для содержания их содержания. Это поведение не легко достигнуть в чистом CSS без жесткого кодирования некоторых размеров, который делает дизайн твердым и хрупким (как долго, поскольку мы должны поддерживать Internet Explorer - в других браузерах, это легко достигается при помощи display:table-cell).
, Таким образом, это не действительно вопрос или таблицы или CSS, предпочтительно, но это - вопрос распознавания конкретных случаев, где использование таблиц может сделать расположение более гибким.
самой важной причиной не таблицы использования является доступность. Инструкции по Доступности веб-контента http://www.w3.org/TR/WCAG10/ совет против использования таблиц для расположения. Если Вы обеспокоены доступностью (и в некоторых случаях можно по закону быть обязаны к), необходимо использовать CSS, даже если таблицы более просты. Обратите внимание, что Вы можете всегда , создают то же расположение с CSS как с таблицами, могло бы просто требоваться больше работы.
Стоит выяснить CSS и отделения так центральные загрузки столбца содержания и рендеринг перед боковой панелью в макете страницы. Но если Вы изо всех сил пытаетесь использовать плавающие отделения для вертикального выравнивания логотипа с некоторым текстом спонсорства, просто используйте таблицу и движение с жизнью. Религия сада Дзэн просто не дает много удара для маркера.
идея разделить содержание от представления состоит в том, чтобы разделить приложение, таким образом, различные виды работы влияют на различные блоки кода. Это на самом деле об управлении изменениями. Но кодирование стандартов может только исследовать текущее состояние кода поверхностным способом.
журнал изменений для приложения, которое зависит от кодирования стандартов для "разделения содержания от представления", покажет шаблон параллельных изменений через вертикальные бункеры. Если изменение в "содержании" всегда сопровождается изменением в "представлении", насколько успешный разделение?
, Если Вы действительно хотите разделить свой код продуктивно, используйте Подрывную деятельность и рассмотрите Ваши журналы изменений. Тогда используйте самые простые методы кодирования - отделения, таблицы, JavaScript, включают, функции, объекты, продолжения, безотносительно - для структурирования приложения так, чтобы изменения поместились в простой и удобный способ.
Инструменты, которые используют разметки таблицы, могут стать чрезвычайно тяжелыми должный на сумму кода, требуемого создать расположение. Портал SAP Netweaver ТАБЛИЦЕЙ использования по умолчанию к расположению их страницы.
производственный портал SAP на моем текущем концерте имеет домашнюю страницу, HTML которой весит по 60K и идет семь таблиц глубоко, три раза в странице. Добавьте в JavaScript, неправильном употреблении 16 iframes с подобными проблемами таблицы в них, чрезмерно тяжелый CSS и т.д., и страница взвешивает более чем 5 МБ.
Занимание время для понижения веса страницы, таким образом, можно использовать пропускную способность, чтобы сделать, привлекательные операции с пользователями стоят усилия.
Согласно 508 соответствиям (для программ экранного доступа для визуально impared), таблицы должны только использоваться для содержания данных а не для расположения, поскольку это заставляет программы экранного доступа волноваться. Или таким образом, мне сказали.
при присвоении имен к каждому из отделений можно очистить их всех вместе использование CSS также. Они - просто немного больше боли для получения для нахождения способа, к которому Вам нужны они.
Вся эта мысль вокруг семантической разметки является разделением разметки и представлением, которое включает расположение.
Отделение не заменяет таблицы, у них есть свое собственное использование в разделении содержания в блоки сходных материалов (). Когда Вы не имеете навыков и полагаетесь на таблицы, необходимо будет часто разделять содержание в к ячейкам для получения желаемого расположения, но Вас, привычка должна коснуться разметки для достижения представления при использовании семантической разметки. Это действительно важно, когда разметка сгенерирована, а не статические страницы.
Разработчики должны прекратить обеспечивать разметку, которая подразумевает расположение так, чтобы те из нас, у кого действительно есть навыки для представления содержания, могли продолжить наши задания, и разработчики не должны возвращаться к своему коду для внесения изменений, когда для представления нужно изменение.
- 508 Соответствий - способность к screenreader для понимания разметки.
- Ожидание рендеринга - таблицы не представляют в браузере, пока это не добирается до конца
</table>элемент.
Похоже, вы просто привыкли к столам и все. Размещение макета в таблице ограничивает вас только этим макетом. С помощью CSS вы можете перемещать биты, посмотрите на http://csszengarden.com/ И нет, компоновка обычно не требует большого количества вложенных элементов div.
Без таблиц для верстки и правильной семантики HTML становится намного чище, поэтому его легче читать. Почему кто-то, кто не понимает CSS, должен читать это? И если кто-то считает себя веб-разработчиком, то хорошее понимание CSS является обязательным.
Преимущества SEO заключаются в возможности размещать наиболее важный контент выше страницы и иметь лучшее соотношение контента и разметки.
Я думаю, что лодка приплыла. При рассмотрении направления, промышленность взяла Вас, заметит, что CSS и Открывает, Standards победители того обсуждения. Который в свою очередь означает для большей части работы HTML, за исключением форм, разработчики будут использовать отделения вместо таблиц. Мне приходится нелегко с тем, что, потому что я не гуру CSS, но это - способ, которым это.
хорошо разделить содержание от расположения
, Но это - ошибочный аргумент; Клише Думая
Это - ошибочный аргумент, потому что HTML-таблицы являются расположением! Содержание данные в таблице, представление является самой таблицей. Поэтому разделение CSS от HTML может время от времени быть очень трудным. Вы не разделяете содержание от представления, Вы разделяете представление от представления! Множество вложенных отделений не отличается, чем таблица - это - просто различный набор тегов.
другая проблема с разделением HTML из CSS состоит в том, что им нужны глубокие знания друг друга - Вы действительно не можете разделить их полностью. Расположение тега в HTML сильно связывается с файлом CSS, неважно, что Вы делаете.
я думаю, что таблицы по сравнению с отделениями сводятся к потребностям Вашего приложения.
В приложении мы разрабатываем на работе, нам был нужен макет страницы, где части динамично измерят себя к своему содержанию. Я провел дни, пытаясь заставить это работать перекрестный браузер с CSS и ОТДЕЛЕНИЯМИ, и это был полный кошмар. Мы переключились на таблицы и все это всего работавший .
Однако у нас есть очень закрытая аудитория для нашего продукта (мы продаем часть аппаратных средств с веб-интерфейсом), и проблемами доступности не является беспокойство о нас. Я не знаю, почему программы экранного доступа не могут иметь дело с таблицами хорошо, но я предполагаю, является ли это способом, которым это - тогда разработчики, должны обработать его.
Это не действительно о том, лучше ли 'отделения, чем таблицы для расположения'. Кто-то, кто понимает CSS, может копировать любой дизайн с помощью 'таблицы расположения' довольно прямо. Реальная победа использует элементы HTML для того, для чего они там. Причиной Вы не использовали бы таблицы для non-tablular данных, является та же причина, Вы не храните целые числа как символьные строки - технология работает намного более легко при использовании его для цели, для которой это разработано. Если было когда-либо необходимо использовать таблицы для расположения (из-за недостатков браузера в начале 1990-х), это, конечно, не теперь.
Кроме того, не забывайте, таблицы не вполне представляют хорошо на мобильных браузерах. Несомненно, iPhone имеет браузер задницы удара, но у всех нет iPhone. Рендеринг таблицы может быть арахисом для современных браузеров, но это - набор арбузов для мобильных браузеров.
я лично нашел, что многие люди используют слишком многих <div> теги, но умеренно, это может быть чрезвычайно чисто и легко читать. Вы упоминаете, что людям приходится тяжелее, читая CSS, чем таблицы; с точки зрения 'кода' это, возможно, верное; но с точки зрения чтения содержания (представление> источник) чертовски много легче понять структуру с таблицами стилей, чем с таблицами.
Гибкость макета
Представьте, что вы создаете страницу с большим количеством миниатюр.
DIVs :
Если вы поместите каждую миниатюру в DIV с плавающей точкой влево, возможно, 10 из них поместятся в ряд. Сделайте окно уже, а БАМ - это 6 на ряд, или 2, или сколько угодно.
ТАБЛИЦА:
Вы должны явно сказать, сколько ячеек подряд. Если окно слишком узкое, пользователь должен прокрутить горизонтально.
Ремонтопригодность
Та же ситуация, что и выше. Теперь вы хотите добавить три миниатюры в третий ряд.
DIVs:
Добавьте их. Макет будет автоматически изменен.
ТАБЛИЦА: Вставьте новые ячейки в третий ряд. Упс! Теперь там слишком много предметов. Вырежьте некоторые из этого ряда и поместите их в четвертый ряд. Сейчас там слишком много предметов. Вырежьте часть из этой строки ... (и т. Д.)
( Конечно, если вы генерируете строки и ячейки с помощью серверных сценариев, это, вероятно, не будет проблемой. )
1: Да, Ваши пользователи действительно заботятся. Если они будут использовать программу экранного доступа, она будет потеряна. Если я использую какой-либо другой инструмент, который пытается извлечь информацию из страницы, встречаясь с таблицами, которые не используются для представления табличных данных, вводит в заблуждение.
отделение А или промежуток приемлемы для разделения содержания, потому что , который является точно значением тех элементов . Когда я, поисковая система, программа экранного доступа или что-либо еще, встречусь с элементом таблицы, мы ожидаем, что это означает, что "следующее является табличными данными, представленными в таблице". Когда мы встретимся с отделением, мы ожидаем, что "это - элемент, привыкший к отделение язь мое содержание в отдельные части или области.
2: Удобочитаемость: Неправильно. Если весь код представления находится в css, я могу считать HTML, и я пойму содержание страницы. Или я могу считать css и понять представление. Если все смешано в HTML, я должен мысленно зачеркнуть все связанные с представлением биты, прежде чем я смогу даже видеть то, что довольно и что не. Кроме того, я боялся бы встречать веб-разработчика, который не понял css, таким образом, я действительно не думаю, что это - проблема.
3: Таблицы медленнее: Да, они. Причина проста: Таблицы должны быть проанализированы полностью, включая их содержание, прежде чем они смогут быть представлены. Отделение может быть представлено, когда с ним встречаются, даже прежде , его содержание было проанализировано. Это означает, что отделения обнаружатся, прежде чем страница закончила загружаться.
И затем существует премия, что таблицы намного более хрупки, и будут не всегда представляться тем же в различных браузерах с различными шрифтами и размерами шрифта и всеми другими факторами, которые могут заставить расположение варьироваться. Таблицы являются отличным способом гарантировать, что Ваш сайт будет выключен пикселем или два в определенных браузерах, не масштабируется хорошо, когда пользователь изменяет свой размер шрифта или изменяет его настройки любым другим способом.
, Конечно, № 1 является большим. Много инструментов и приложений зависит от семантического значения веб-страницы. Обычным примером являются программы экранного доступа для слабовидящих пользователей. Если Вы будете веб-разработчиком, Вы найдете, что многие крупные компании, которые могут иначе нанять Вас для работы над сайтом, , требуют , что сайт доступен даже в этом случае. Что означает, что необходимо думать о семантическом значении HTML. С семантической паутиной, или более соответствующим образом, микроформаты, RSS-ридеры и другие инструменты, Ваше содержание страницы больше не просматривается исключительно через браузер.
-
1Таким образом, Вы отключаете поддержку IPv6 Apache. Можно зафиксировать его иначе: добавьте
127.0.0.1 localhostк файлу hosts, таким образом, разрешение IPv4 является priorized по IPv6 для localhost;) – Áxel Costas Pena 4 December 2013 в 01:52
Я исследовал выпуск программ для чтения с экрана и таблиц несколько лет назад и придумал информацию, которая противоречит тому, чему верит большинство разработчиков:
http://www.webaim.org/techniques/tables/
"Вы, вероятно, услышите, что некоторые защитники доступности говорят, что таблицы расположения являются плохой идеей, и что методы расположения CSS должны использоваться вместо этого. Существует истина в том, что они говорят, но, честно говоря, использование таблиц для расположения не является худшей вещью, которую Вы могли сделать с точки зрения доступности. Люди со всеми видами нарушений могут легко получить доступ к таблицам, пока таблицы разработаны с доступностью в памяти".
Тот факт, что это горячо обсуждаемый вопрос, свидетельствует о неспособности W3C предвидеть разнообразие схем компоновки, которые можно было бы предпринять. Использование divs + css для семантически понятного макета - отличная идея, но детали реализации настолько ошибочны, что фактически ограничивают свободу творчества.
Я попытался переключить один из сайтов нашей компании с таблиц на блоки div, и это была такая головная боль, что я полностью выбросил часы работы, которые я потратил на это, и вернулся к таблицам. Попытки бороться с моими divs, чтобы получить контроль над вертикальным выравниванием, обрушили на меня серьезные психологические проблемы, от которых я никогда не избавлюсь, пока продолжаются эти дебаты.
Тот факт, что люди должны часто придумывать сложные и уродливые обходные пути для достижения простых целей проектирования (таких как вертикальное выравнивание), убедительно свидетельствует о том, что правила недостаточно гибкие. Если спецификаций ДЕЙСТВИТЕЛЬНО достаточно, то почему высокопоставленные сайты (например, SO) считают необходимым изменять правила, используя таблицы и другие обходные пути?