Путь к файлу / каталогу семантической уценки

#markdown

#Уценка

Вопрос:

Обычной практикой в Markdown для обработки путей к файлам / каталогам, которые не предназначены для ссылок, является использование обратных меток, которые помечают содержимое как «код». Эта практика происходит даже здесь, на SO. Мой вопрос в том, есть ли более семантически правильный вариант? Я не думаю, что пути к файлам технически считаются «кодом». Даже мои собственные слова здесь кажутся мне подозрительными, что приводит меня ко второму, очень связанному вопросу. Почему путь должен соответствовать этому критерию «не предназначен для ссылок»?

Для большего контекста я задал этот вопрос, пытаясь добавить инструкции по настройке в README.md файл для проекта кодирования. Здесь я пытаюсь сослаться на папку, src/io . Немного поразмыслив, я подумал: «Может быть, было бы лучше пометить пути, подобные этому, по-другому — возможно, как ссылку, даже если нажатие на нее не всегда работает?». Но это не распространяется на случаи, подобные SO questions / answers, где у вас есть только гипотетический путь (может быть, это критерий?).

Ответ №1:

Да, промежутки кода — это правильный способ разметки имен файлов и путей.

Диапазон кода Markdown отображается в элементе кода HTML. В спецификации HTML указано (курсив добавлен):

code Элемент представляет собой фрагмент компьютерного кода. Это может быть имя элемента XML, имя файла, компьютерная программа или любая другая строка, которую распознает компьютер.

Это явно вызывает имена файлов в качестве приемлемого содержимого code элемента. Хотя пути к каталогам конкретно не указаны, выражение «любая другая строка, которую распознает компьютер», безусловно, включает в себя оба.

Но это Markdown, а не HTML … тогда позвольте мне напомнить вам, что Markdown — это подмножество HTML, как объясняется в исходных правилах синтаксиса. И, как объяснено там…

Для любой разметки, на которую не распространяется синтаксис Markdown, вы просто используете сам HTML.

Таким образом, правильный способ разметки имен файлов и путей в HTML будет таким же в Markdown. Конечно, поскольку Markdown предполагает объем кода (с использованием рюкзаков), вам не нужно использовать необработанные code элементы HTML. Обратные ссылки облегчают чтение и запись ярлыков.

Но когда пути не будут ссылками?

Всякий раз, когда они не указывают на доступное местоположение. Здесь, на SO, мы регулярно видим вопросы с путями к локальным файлам и каталогам. Если я отправлю вопрос о том, как получить доступ к локальному файлу в моей локальной системе, вы не ожидаете, что перейдете по ссылке и получите доступ к файлу. Для этого мне нужно будет загрузить файл. Однако для правильного отчета по ситуации мне нужно использовать локальный путь, который недоступен в Интернете. Поэтому такие пути не должны быть ссылками. Не имеет значения, являются ли они псевдопутями или реальными путями.

Комментарии:

1. Именно то, что мне нужно было увидеть. Как веб-разработчик, я должен был знать, что нужно смотреть на спецификации HTML <code> , а не предполагать, что «пути к файлам не являются кодом». Множество других элементов имеют несколько значений, помимо того, что сразу бросается в глаза. Спасибо, что указали мне на это!