أفكار في Markdown

Markdown هو طبيعة ثانية للكثير منا. إذا نظرنا إلى الوراء ، أتذكر بدء الكتابة في Markdown بعد وقت قصير من إصدار John Gruber أول محلل لغوي يستند إلى Perl في عام 2004 بعد التعاون في اللغة مع Aaron Swartz.

إن صيغة Markdown مخصصة لغرض واحد: أن تستخدم كتنسيق للكتابة على الويب.

- جون جروبر

كان هذا منذ ما يقرب من 20 عامًا - yikes! ما بدأ كصيغة أكثر ملاءمة للكاتب والقارئ لـ HTML أصبح محبوبًا لكيفية كتابة وتخزين النثر التقني للمبرمجين والأشخاص البارعين في التكنولوجيا.

Markdown هو دلالة على ثقافة المطور والتلاعب بالنصوص. ولكن منذ تقديمه ، تغير أيضًا عالم المحتوى الرقمي. بينما لا يزال Markdown جيدًا بالنسبة لبعض الأشياء ، لا أعتقد أنه يجب أن يكون المحتوى المطلوب بعد الآن.

هناك سببان رئيسيان لهذا:

1. لم يكن Markdown مصممًا لتلبية احتياجات المحتوى الحالية.
2. Markdown يعيد الخبرة التحريرية.

بالطبع ، يتأثر هذا الموقف بالعمل على منصة للمحتوى المنظم. في Sanity.io ، نقضي معظم أيامنا في التفكير في الكيفية التي يفتح بها المحتوى كبيانات الكثير من القيمة ، ونقضي الكثير من الوقت في التفكير بعمق في تجارب المحرر ، وكيفية توفير وقت الأشخاص ، وجعل العمل مع المحتوى الرقمي ممتعًا . لذلك ، هناك مظهر في اللعبة ، لكني آمل أن أكون قادرًا على تصوير أنه على الرغم من أنني سأجادل ضد Markdown باعتباره تنسيق الانتقال للمحتوى ، ما زلت أقدر عميقًا لأهميته وتطبيقه وإرثه.

قبل عملي الحالي ، عملت كمستشار تقني في وكالة حيث كان علينا أن نحارب أنظمة إدارة المحتوى التي أغلقت محتوى عملائنا من خلال تضمينه في نماذج البيانات التقديمية والمعقدة (نعم ، حتى النماذج مفتوحة المصدر). لقد لاحظت أن الناس يعانون من بناء جملة Markdown ، ويتم تثبيط حافزهم في وظائفهم كمحررين ومنشئي محتوى. لقد أمضينا ساعات (وأموال العميل) في بناء برامج عرض علامات مخصصة لم يتم استخدامها مطلقًا لأن الناس ليس لديهم الوقت أو الدافع لاستخدام بناء الجملة. حتى أنني عندما كنت متحمسًا للغاية ، فقد تخليت عن المساهمة في التوثيق مفتوح المصدر لأن تطبيق Markdown القائم على المكونات أدى إلى الكثير من الاحتكاك.

لكني أرى أيضًا الوجه الآخر للعملة. يأتي Markdown مع نظام إيكولوجي مثير للإعجاب ومن وجهة نظر المطور ، هناك بساطة أنيقة لملفات النص العادي وبناء جملة سهل التحليل للأشخاص الذين اعتادوا على قراءة التعليمات البرمجية. لقد قضيت يومًا يومًا في إنشاء MultiMarkdown مثير للإعجاب -> LaTeX -> real-time-PDF-preview-pipeline في نص Sublime لكتابتي الأكاديمية. ومن المنطقي أنه يمكن فتح ملف README.md وتحريره في محرر التعليمات البرمجية وتقديمه بشكل جيد على GitHub. ليس هناك شك في أن Markdown يجلب الراحة للمطورين في بعض حالات الاستخدام.

لهذا السبب أيضًا أرغب في بناء نصيحتي ضد Markdown من خلال النظر إلى الوراء في سبب تقديمها في المقام الأول ، ومن خلال الاطلاع على بعض التطورات الرئيسية للمحتوى على الويب. بالنسبة للكثيرين منا ، أعتقد أن Markdown هو شيء نعتبره مجرد "شيء موجود" كأمر مسلم به. لكن كل التقنيات لها تاريخ وهي نتاج تفاعل بشري. من المهم أن تتذكر عندما تقوم أنت ، القارئ ، بتطوير تقنية ليستخدمها الآخرون.

النكهات والمواصفات

تم تصميم Markdown ليسهل على كتّاب الويب العمل مع المقالات في عصر يتطلب فيه النشر على الويب كتابة HTML. لذلك ، كان الهدف هو تسهيل التفاعل مع تنسيق النص في HTML. لم تكن أول بناء جملة مبسط على هذا الكوكب ، لكنها كانت هي التي اكتسبت أكبر قدر من الجاذبية على مر السنين. اليوم ، نما استخدام Markdown إلى ما هو أبعد من نية التصميم الخاصة به ليكون طريقة أبسط لقراءة وكتابة HTML ، ليصبح أسلوبًا لترميز النص العادي في الكثير من السياقات المختلفة. بالتأكيد ، يمكن أن تتطور التقنيات والأفكار بما يتجاوز نواياها ، ولكن يمكن إرجاع التوتر في استخدام Markdown اليوم إلى هذا الأصل والقيود الموضوعة في تصميمه.

بالنسبة لأولئك الذين ليسوا على دراية بالصياغة ، خذ محتوى HTML التالي:

 <p>The <a href=”https://daringfireball.net/projects/markdown/syntax#philosophy”>Markdown syntax</a> is designed to be <em>easy-to-read</em> and <em>easy-to.write</em>.</p>

باستخدام Markdown ، يمكنك التعبير عن نفس التنسيق مثل:

 The [Markdown syntax](https://daringfireball.net/projects/markdown/syntax#philosophy) is designed to be _easy-to-read_ and _easy-to-write_.

إنه مثل قانون الطبيعة أن تبني التكنولوجيا يأتي مصحوبًا بضغط للتطور وإضافة ميزات إليه. تعني الشعبية المتزايدة لـ Markdown أن الناس يريدون تكييفه مع حالات الاستخدام الخاصة بهم. لقد أرادوا المزيد من الميزات مثل دعم الحواشي السفلية والجداول. جاء التنفيذ الأصلي بموقف عنيد ، والذي كان في ذلك الوقت معقولًا لما كان قصد التصميم:

بالنسبة إلى أي ترميز لم يتم تغطيته من خلال بناء جملة Markdown ، يمكنك ببساطة استخدام HTML نفسه. ليست هناك حاجة لتمهيده أو تحديده للإشارة إلى أنك تقوم بالتبديل من Markdown إلى HTML ؛ أنت فقط تستخدم العلامات.

- جون جروبر

بمعنى آخر ، إذا كنت تريد جدولاً ، فاستخدم <table></table> . ستجد أن هذا لا يزال هو الحال بالنسبة للتنفيذ الأصلي. اتخذ أحد الخلفاء الروحيين لـ Markdown ، وهو MDX ، نفس المبدأ ولكنه امتد إلى JSX ، وهي لغة قوالب تستند إلى JS.

من Markdown إلى Markdown؟

يمكن أن يبدو أن جاذبية Markdown بالنسبة للكثيرين لم تكن مرتبطة كثيرًا بـ HTML ، ولكن بيئة العمل الخاصة بالنص العادي والبنية البسيطة للتنسيق. أراد بعض منشئي المحتوى استخدام Markdown لحالات استخدام أخرى غير المقالات البسيطة على الويب. قدمت تطبيقات مثل MultiMarkdown مزايا للكتاب الأكاديميين الذين أرادوا استخدام ملفات نصية عادية لكنهم كانوا بحاجة إلى المزيد من الميزات. قريباً سيكون لديك مجموعة من تطبيقات الكتابة التي قبلت بناء جملة Markdown ، دون بالضرورة تحويلها إلى HTML أو حتى استخدام صيغة markdown كتنسيق تخزين.

في الكثير من التطبيقات ، ستجد برامج تحرير تمنحك مجموعة محدودة من خيارات التنسيق ، وبعضها "مستوحى" من البنية الأصلية. في الواقع ، كان أحد التعليقات التي تلقيتها على مسودة هذه المقالة هو أنه في الوقت الحالي ، يجب أن تكون كلمة "Markdown" ذات غلاف أقل ، نظرًا لأنها أصبحت شائعة جدًا ، وتمييزها عن التنفيذ الأصلي. لأن ما نعترف به على أنه تخفيض السعر أصبح أيضًا شديد التنوع.

CommonMark: محاولة لترويض تخفيض السعر

مثل الآيس كريم ، يأتي Markdown بالعديد من النكهات ، بعضها أكثر شهرة من البعض الآخر. عندما بدأ الأشخاص في تفكيك التنفيذ الأصلي وإضافة ميزات إليه ، حدث شيئان:

1. أصبح الأمر أكثر صعوبة للتنبؤ بما يمكن أن تفعله ككاتب وما لا تستطيع فعله مع Markdown.
2. كان على مطوري البرمجيات اتخاذ قرارات بشأن التنفيذ الذي يجب اعتماده لبرامجهم. احتوى التطبيق الأصلي أيضًا على بعض التناقضات التي أضافت الاحتكاك للأشخاص الذين أرادوا استخدامه برمجيًا.

بدأ هذا المحادثات حول إضفاء الطابع الرسمي على Markdown في المواصفات المناسبة. الشيء المثير للاهتمام الذي قاومه جروبر ، ولا يزال يفعله ، لأنه أدرك أن الناس يريدون استخدام Markdown لأغراض مختلفة و "لن يكون هناك بناء جملة واحد يجعل الجميع سعداء." إنه موقف مثير للاهتمام بالنظر إلى أن Markdown يترجم إلى HTML ، وهي مواصفات تتطور لتلائم الاحتياجات المختلفة.

على الرغم من أن التطبيق الأصلي لـ Markdown مغطى بترخيص "يشبه BSD" ، فإنه يقرأ أيضًا "لا يجوز استخدام اسم Markdown أو أسماء المساهمين فيه لتأييد أو ترويج المنتجات المشتقة من هذا البرنامج دون إذن كتابي مسبق محدد. " يمكننا أن نفترض بأمان أن معظم المنتجات التي تستخدم "Markdown" كجزء من موادها التسويقية لم تحصل على هذا الإذن الكتابي.

أنجح محاولة لإدخال Markdown في مواصفات مشتركة هي ما يُعرف اليوم باسم CommonMark. ترأسها جيف أتوود (المعروف بالمشاركة في تأسيس Stack Overflow and Discourse) وجون ماكفارلين (أستاذ الفلسفة في Berkely الذي يقف وراء Babelmark and pandoc). أطلقوها في البداية باسم "Standard Markdown" ، لكنهم غيروها إلى "CommonMark" بعد تلقي انتقادات من Gruber. الذي كان موقفه ثابتًا ، فإن القصد من Markdown هو أن يكون بناء جملة تأليف بسيط يترجم إلى HTML:

davewiner وهذا هو عيب CommonMark. يريدون تسهيل الأمور على المبرمجين كهدف أساسي. لقد فاتتهم النقطة.

- جون جروبر (gruber) 8 سبتمبر 2014

أعتقد أن هذا حدد أيضًا النقطة التي دخلت Markdown في المجال العام. على الرغم من أن CommonMark لم يتم تصنيفها على أنها "Markdown" (وفقًا للترخيص) ، يتم التعرف على هذه المواصفات ويشار إليها باسم "markdown". اليوم ، ستجد CommonMark بمثابة التطبيق الأساسي لبرامج مثل Discourse و GitHub و GitLab و Reddit و Qt و Stack Overflow و Swift. تعتمد المشاريع مثل unified.js bridges syntaxes من خلال ترجمتها إلى Abstract Syntax Trees ، أيضًا على CommonMark لدعمها الشكلي.

لقد جلبت CommonMark الكثير من التوحيد حول كيفية تنفيذ تخفيض السعر ، وبطرق كثيرة جعلت الأمر أسهل على المبرمجين لدمج دعم تخفيض السعر في البرنامج. لكنها لم تجلب نفس التوحيد لكيفية كتابة واستخدام التخفيضات. خذ GitHub Flavored Markdown (GFM). يعتمد على CommonMark ولكنه يمتد بمزيد من الميزات (مثل الجداول وقوائم المهام ويتوسطه خط). يصف Reddit "Reddit Flavored Markdown" بأنه "تباين لـ GFM" ويقدم ميزات مثل بناء الجملة لتمييز المفسدين. أعتقد أنه يمكننا أن نستنتج بأمان أن كل من المجموعة التي تقف وراء CommonMark و Gruber كانت على حق: فهي تساعد بالتأكيد في المواصفات المشتركة ، ولكن نعم ، يريد الأشخاص استخدام Markdown لأشياء محددة مختلفة.

Markdown كاختصار تنسيق

قاوم Gruber إضفاء الطابع الرسمي على Markdown في مواصفات مشتركة لأنه افترض أنها ستجعلها أقل أداة للكتاب وأكثر أداة للمبرمجين. لقد رأينا بالفعل أنه حتى مع التبني الواسع للمواصفات ، فإننا لا نحصل تلقائيًا على صيغة تعمل بنفس الطريقة على نحو متوقع عبر سياقات مختلفة. والمواصفات مثل CommonMark ، كما هي ، حققت نجاحًا محدودًا أيضًا. من الأمثلة الواضحة على تطبيق Slack's markdown (يسمى mrkdown ) الذي يترجم *this* إلى قوي / غامق ، وليس تركيزًا / مائلًا ، ولا يدعم بنية [link](https://slack.com) ، ولكنه يستخدم <link|https://slack.com> بدلاً من ذلك.

ستجد أيضًا أنه يمكنك استخدام بناء جملة يشبه Markdown لتهيئة التنسيق في برامج تحرير النص المنسق في برامج مثل Notion و Dropbox Paper و Craft ، وإلى حد ما ، ستتحول مستندات Google (على سبيل المثال ، asterisk + space على سطر جديد ستتحول إلى قائمة نقطية). ما هو مدعوم وما يترجم إلى ما يختلف. لذلك ، لا يمكنك بالضرورة أن تأخذ ذاكرتك العضلية معك عبر هذه التطبيقات. بالنسبة لبعض الناس ، هذا جيد ، ويمكنهم التكيف. بالنسبة للآخرين ، يعد هذا ورقة ورقية ويمنعهم من استخدام هذه الميزات. الذي يطرح السؤال ، لمن تم تصميم Markdown ، ومن هم مستخدموه اليوم؟

من هم مستخدمي Markdown المفترض أن يكونوا؟

لقد رأينا وجود الشطب في توتر بين حالات الاستخدام المختلفة ، والجماهير ، ومفاهيم مستخدميها. ما بدأ كلغة ترميز لكتاب الويب المتمرسين في HTML على وجه التحديد ، أصبح محبوبًا لأنواع المطورين.

في عام 2014 ، بدأ كتّاب الويب في الابتعاد عن نقل الملفات من خلال الموزعين في Perl و FTP. نمت أنظمة إدارة المحتوى (CMSs) مثل WordPress و Drupal و Moveable Type (التي أعتقد أن Gruber لا تزال تستخدمها) بشكل مطرد لتصبح أدوات الانتقال للنشر على الويب. لقد عرضوا وسائل مثل محررات النصوص الغنية التي يمكن لكتاب الويب استخدامها في متصفحاتهم.

لا تزال برامج تحرير النص المنسق تفترض أن HTML و Markdown هما بناء جملة النص المنسق الأساسي ، لكنهما أزالا بعض العبء المعرفي عن طريق إضافة أزرار لإدراج بناء الجملة هذا في المحرر. وبشكل متزايد ، لم يكن الكتاب ولا يجب أن يكونوا على دراية بلغة HTML. أراهن أنك إذا قمت بتطوير الويب باستخدام CMSs في 2010 ، فمن المحتمل أن يكون عليك التعامل مع "HTML غير المرغوب فيه" الذي جاء من خلال هؤلاء المحررين عندما قام الأشخاص بلصقهم مباشرةً من Word.

اليوم ، سأجادل في أن مستخدمي Markdown الأساسيين هم مطورون وأشخاص مهتمون بالكود. ليس من قبيل المصادفة أن Slack جعل WYSIWYG وضع الإدخال الافتراضي بمجرد استخدام برامجهم من قبل المزيد من الأشخاص خارج الأقسام الفنية. وحقيقة أن هذا كان قرارًا مثيرًا للجدل ، لدرجة أنهم اضطروا إلى إعادته كخيار ، يوضح مدى عمق حب التخفيض في مجتمع المطورين. لم يكن هناك احتفال كبير بـ Slack الذي كان يحاول جعله أكثر سهولة ويسر للجميع. وهذا هو لب الموضوع.

إيديولوجية تخفيض السعر

حقيقة أن التخفيضات أصبحت أسلوب كتابة لغة مشتركة ، وما تلبي معظم أطر مواقع الويب ، هو أيضًا السبب الرئيسي الذي جعلني متقلبًا بعض الشيء بشأن نشر هذا. غالبًا ما يتم الحديث عنها على أنها سلعة متأصلة لا يمكن إنكارها. أصبح Markdown سمة مميزة لكونه صديقًا للمطورين. لقد قضى الأشخاص الأذكياء والمهرة الكثير من الساعات الجماعية في تمكين عمليات التخفيض في جميع أنواع السياقات. لذا ، فإن تحدي هيمنتها سوف يزعج البعض بالتأكيد. ولكن من المأمول أن تفرز بعض المناقشات المثمرة حول شيء غالبًا ما يتم اعتباره أمرًا مفروغًا منه.

انطباعي هو أن صداقة المطور التي يرتبط بها الأشخاص بـ Markdown ترتبط في الغالب بثلاثة عوامل:

1. التجريد المريح لملف نصي عادي.
2. هناك نظام بيئي للأدوات.
3. يمكنك الاحتفاظ بالمحتوى الخاص بك بالقرب من سير عمل التطوير الخاص بك.

أنا لا أقول إن هذه المواقف خاطئة ، لكنني سأقترح أنها تأتي مع مقايضات وبعض الافتراضات غير المعقولة.

النموذج العقلي البسيط لملف نصي عادي

قواعد البيانات أشياء مدهشة. لكن لديهم أيضًا سمعة مكتسبة من كونهم صعبًا ولا يمكن الوصول إليها من قبل مطوري الواجهة. لقد عرفت الكثير من المطورين الرائعين الذين يخجلون من التعليمات البرمجية وقواعد البيانات الخلفية ، لأنهم يمثلون التعقيد الذي لا يريدون قضاء الوقت فيه. حتى مع WordPress ، الذي يقوم بالكثير من الأشياء خارج الصندوق لمنعك من الاضطرار إلى التعامل مع قاعدة البيانات الخاصة به بعد الإعداد ، فقد كان الأمر عبئًا في النهوض والتشغيل.

ومع ذلك ، فإن الملفات النصية العادية تكون ملموسة بشكل أكبر ويسهل التفكير فيها إلى حد ما (طالما أنك معتاد على إدارة الملفات). مقارنة بشكل خاص بنظام يقوم بتقسيم المحتوى الخاص بك إلى جداول متعددة في قاعدة بيانات علائقية مع بعض الهياكل الاحتكارية. بالنسبة لحالات الاستخدام المحدود ، مثل منشورات المدونة ذات النص المنسق البسيط مع الصور والروابط ، فإن تخفيض السعر سوف ينجز المهمة. يمكنك نسخ الملف وإلصاقه في مجلد أو إيداعه في git. المحتوى يشعر بأنه ملكك بسبب الملفات الملموسة. حتى إذا كانت مستضافة على GitHub ، وهو برنامج ربحي كخدمة مملوكة لشركة Microsoft ، وبالتالي فهي مشمولة بشروط الخدمة الخاصة بها.

في العصر الذي اضطررت فيه فعليًا إلى إنشاء قاعدة بيانات محلية لبدء التطوير المحلي والتعامل مع مزامنتها مع جهاز التحكم عن بُعد ، فإن جاذبية الملفات النصية العادية أمر مفهوم. لكن تلك الحقبة ولت إلى حد كبير مع ظهور الخلفيات كخدمة. تستثمر الخدمات والأدوات مثل Fauna و Firestore و Hasura و Prisma و PlanetScale و Sanity's Content Lake بكثافة في تجربة المطور. حتى تشغيل قواعد البيانات التقليدية المتعلقة بالتنمية المحلية أصبح أقل صعوبة مقارنة بما كان عليه الحال قبل 10 سنوات فقط.

إذا فكرت في الأمر ، فهل تمتلك المحتوى الخاص بك أقل إذا تم استضافته في قاعدة بيانات؟ ألم تصبح تجربة المطور في التعامل مع قواعد البيانات أكثر بساطة مع ظهور أدوات SaaS؟ وهل من العدل أن نقول إن تقنية قواعد البيانات الاحتكارية تؤثر على قابلية نقل المحتوى الخاص بك؟ اليوم يمكنك تشغيل ما هو أساسًا قاعدة بيانات Postgres بدون مهارات مسؤول النظام ، وإنشاء الجداول والأعمدة ، ووضع المحتوى الخاص بك بداخله ، وتصديره في أي وقت كملف تفريغ .sql .

ترتبط قابلية نقل المحتوى بشكل أكبر بكيفية هيكلة هذا المحتوى في المقام الأول. خذ WordPress ، إنه مفتوح المصدر بالكامل ، يمكنك استضافة قاعدة البيانات الخاصة بك. حتى أنه يحتوي على تنسيق تصدير موحد في XML. لكن أي شخص حاول الخروج من تثبيت WordPress الناضج يعرف مدى ضآلة ذلك إذا كنت تحاول الابتعاد عن WordPress.

نظام بيئي واسع ... للمطورين

لقد تطرقنا بالفعل إلى النظام البيئي الهائل لعملية تخفيض السعر. إذا نظرت إلى أطر مواقع الويب المعاصرة ، فإن معظمها يفترض أن الشطب هو تنسيق أساسي للمحتوى ، وبعضها هو التنسيق الوحيد . على سبيل المثال ، لا يزال Hugo ، منشئ الموقع الثابت الذي تستخدمه مجلة Smashing ، يتطلب ملفات تخفيض السعر للنشر المرقم. بمعنى أنه إذا أرادت Smashing Magazine استخدام CMS لتخزين المقالات ، فعليها التفاعل مع ملفات markdown ، أو تحويل كل المحتوى إلى ملفات markdown. إذا بحثت في وثائق Next.js و Nuxt.js و VuePress و Gatsby.js وما إلى ذلك ، فستظهر عملية تخفيض السعر بشكل بارز. إنها أيضًا البنية الافتراضية لملفات README على GitHub ، والتي تستخدمها أيضًا للتنسيق في ملاحظات وتعليقات طلب السحب.

هناك بعض الإشارات الشريفة للمبادرات الهادفة إلى جلب بيئة العمل من تخفيض السعر إلى الجماهير. سوف يمنحك Netlify CMS و TinaCMS (السليل الروحي لـ Forestry) واجهات مستخدم حيث يتم في الغالب استخلاص صيغة تخفيض السعر للمحررين. ستجد عادةً أن المحررات القائمة على markdown في CMSes تمنحك وظائف معاينة للتنسيق. سيسمح لك بعض المحررين ، مثل Notion ، بلصق بناء الجملة ، وسيقومون بترجمته إلى تنسيقهم الأصلي. لكني أعتقد أنه من الآمن أن نقول ، إن الطاقة التي بذلت للابتكار من أجل تخفيض السعر لم تحابي الأشخاص الذين لا يكتبون تركيبها. لم تتسرب إلى المكدس ، كما كانت.

مهام سير عمل المحتوى أو مهام سير عمل المطور؟

بالنسبة للمطور الذي يصنع مدونته ، فإن استخدام ملفات markdown يقلل من بعض النفقات العامة للحصول عليها وتشغيلها ، نظرًا لأن الأطر غالبًا ما تأتي مع تحليل مدمج أو تقدمه بشكل عام كجزء من التعليمات البرمجية المبدئية. ولا يوجد شيء إضافي للتسجيل فيه. يمكنك استخدام git لربط هذه الملفات بجانب التعليمات البرمجية الخاصة بك. إذا كنت مرتاحًا لـ git diffs ، فسيكون لديك تحكم في المراجعة كما اعتدت على البرمجة. بمعنى آخر ، نظرًا لأن ملفات markdown موجودة في نص عادي ، يمكن دمجها مع سير عمل المطور لديك.

ولكن بعد ذلك ، سرعان ما تصبح تجربة المطور أكثر تعقيدًا. وينتهي بك الأمر إلى المساومة على تجربة مستخدم فريقك كمنشئي محتوى ، وتبقى تجربة المطورين الخاصة بنا عالقة مع تخفيض السعر لحل المشكلات التي تتعدى هدفها في التصميم.

نعم ، قد يكون أمرًا رائعًا أن تجعل فريق المحتوى الخاص بك يستخدم git ويتحقق من تغييراتهم ، ولكن في نفس الوقت ، هل هذا هو أفضل استخدام لوقتهم؟ هل تريد حقًا أن يصطدم المحررون بتعارضات الدمج أو كيفية إعادة تحديد الفروع؟ Git صعب بما يكفي للمطورين الذين يستخدمونه كل يوم. وهل يمثل هذا الإعداد حقًا أفضل سير عمل للأشخاص الذين يعملون بشكل أساسي مع المحتوى؟ أليست هذه هي الحالة التي تفوقت فيها تجربة المطور على تجربة المحرر ، وليست التكلفة والوقت والجهد اللذين يمكن أن يبذلا في صنع شيء أفضل للمستخدمين؟

نظرًا لأن التوقعات والاحتياجات من المحتوى وبيئات التحرير قد تطورت ، لا أعتقد أن عمليات الشطب الواسعة ستفعل ذلك لنا. لا أرى كيف ينتهي المطاف ببعض بيئة العمل للمطورين في نهاية المطاف لصالح غير المطورين ، وأعتقد أنه حتى بالنسبة للمطورين ، فإن عملية تخفيض السعر تعيق إنشاء المحتوى الخاص بنا وتحتاج إلى العودة. لأن المحتوى على الويب قد تغير بشكل كبير منذ أوائل العقد الأول من القرن الحادي والعشرين.

من فقرات إلى كتل

لطالما كان لدى Markdown خيار إلغاء الاشتراك في HTML إذا كنت تريد أشياء أكثر تعقيدًا. نجح هذا بشكل جيد عندما كان المؤلف أيضًا مشرف الموقع ، أو على الأقل كان يعرف HTML. لقد نجح أيضًا لأن مواقع الويب عادةً ما تكون في الغالب HTML و CSS. كانت الطريقة التي صممت بها مواقع الويب هي في الغالب إنشاء تخطيطات كاملة للصفحة. يمكنك تحويل Markdown إلى ترميز HTML ووضعه بجانب ملف style.css الخاص بك. بالطبع ، كان لدينا CMSes ومولدات مواقع ثابتة في العقد الأول من القرن الحادي والعشرين أيضًا ، لكنهم عملوا في الغالب بنفس الطريقة ، عن طريق إدخال محتوى HTML داخل القوالب دون أي تمرير لـ "الدعائم" بين المكونات.

لكن معظمنا لم يعد يؤلف HTML كما كان في الأيام الخوالي بعد الآن. تطور المحتوى على الويب من كونه في الغالب مقالات ذات تنسيق نص منسق بسيط إلى وسائط متعددة مكونة ومكونات متخصصة غالبًا مع تفاعل المستخدم (وهي طريقة رائعة لقول "دعوة الاشتراك في الرسائل الإخبارية إلى اتخاذ إجراءات").

من المقالات إلى التطبيقات

في أوائل عام 2010 ، كان الويب 2.0 في ذروته ، وبدأت شركات البرمجيات كخدمة في استخدام الويب للتطبيقات كثيفة البيانات. تم استخدام HTML و CSS و JavaScript بشكل متزايد لدفع واجهات المستخدم التفاعلية. Bootstrap مفتوح المصدر على Twitter ، إطار عملهم لبناء واجهات مستخدم أكثر اتساقًا ومرونة. أدى هذا إلى ما يمكن أن نطلق عليه "إضفاء الطابع المكون" على تصميم الويب. لقد غيرت الطريقة التي نبني بها للويب بطريقة أساسية.

تميل أطر عمل CSS المختلفة التي ظهرت في هذا العصر (مثل Bootstrap و Foundation) إلى استخدام أسماء فئات معيارية وافترضت هياكل HTML معينة لتقليل صعوبة إنشاء واجهات مستخدم مرنة وسريعة الاستجابة. مع فلسفة تصميم الويب الخاصة بالتصميم الذري واصطلاحات اسم الفئة مثل Block-Element-Modifier (BEM) ، تم تحويل الإعداد الافتراضي من التفكير في تخطيط الصفحة أولاً ، إلى رؤية الصفحات كمجموعة من عناصر التصميم القابلة للتكرار والمتوافقة.

أيًا كان المحتوى الموجود لديك داخل تخفيض السعر غير متوافق مع هذا. ما لم تكن أسفل حفرة الأرانب لإقحام موزعي تخفيض السعر ، وقمت بتعديلها لإخراج الصيغة التي تريدها (المزيد حول هذا لاحقًا). لا عجب ، فقد تم تصميم Markdown ليكون عبارة عن مقالات نصية منسقة بسيطة لعناصر HTML الأصلية التي قد تستهدفها باستخدام ورقة أنماط.

لا تزال هذه مشكلة للأشخاص الذين يستخدمون Markdown لتوجيه المحتوى إلى مواقعهم.

الويب القابل للدمج

ولكن حدث شيء ما لمحتوياتنا أيضًا. لم نتمكن فقط من البدء في العثور عليه خارج علامات HTML الدلالية <article> ، ولكنه بدأ يحتوي على المزيد من ... الأشياء. انتقل الكثير من المحتوى الخاص بنا من الدوريات الحية والمدونات الخاصة بنا إلى وسائل التواصل الاجتماعي: Facebook و Twitter و tumblr و YouTube. لاستعادة مقتطفات المحتوى إلى مقالاتنا ، كنا بحاجة إلى أن نكون قادرين على تضمينها. بدأت اتفاقية HTML في استخدام علامة <iframe> لتوجيه مشغل الفيديو من YouTube أو حتى إدراج مربع تغريدة بين فقرات النص. بدأت بعض الأنظمة في تلخيص ذلك إلى "رموز مختصرة" ، وغالبًا ما تحتوي الأقواس على بعض الكلمات الرئيسية لتحديد كتلة المحتوى التي يجب أن تمثلها ، وبعض سمات القيمة الرئيسية. على سبيل المثال ، قام dev.to بتمكين بناء الجملة من سائل اللغة النموذجية ليتم إدراجه في محرر Markdown الخاص بهم:

 {% youtube dQw4w9WgXcQ %}

بالطبع ، هذا يتطلب منك استخدام محلل Markdown مخصص ، ولديك منطق خاص للتأكد من إدخال HTML الصحيح عندما تم تحويل بناء الجملة إلى HTML. وسيتعين على منشئ المحتوى لديك أن يتذكر هذه الرموز (ما لم يكن هناك نوع من شريط الأدوات لإدراجها تلقائيًا). وإذا تم حذف شريحة أو تلفها ، فقد يؤدي ذلك إلى تعطيل الموقع.

لكن ماذا عن MDX؟

محاولة حل الحاجة إلى محتوى الكتلة هو MDX ، مع تقديم شعار "Markdown لعصر المكونات". يتيح لك MDX استخدام لغة نماذج JSX ، بالإضافة إلى JavaScript ، المتداخلة في بناء الجملة markdown. هناك الكثير من الهندسة الرائعة في المجتمع حول MDX ، بما في ذلك Unified.js ، التي تتخصص في تحليل تراكيب مختلفة في أشجار التركيب المجردة (ASTs) ، بحيث يسهل الوصول إليها لاستخدامها برمجيًا. لاحظ أن توحيد أسلوب الشطب من شأنه أن يجعل العمل بالنسبة للأشخاص الذين يعملون خلف Unified.js ومستخدميها أكثر بساطة ، نظرًا لوجود عدد أقل من الحالات الجانبية التي يجب تلبيتها.

تقدم MDX بالتأكيد تجربة مطور أفضل في دمج المكونات في Markdown. لكنه لا يجلب تجربة محرر أفضل ، لأنه يضيف الكثير من النفقات المعرفية لإنتاج المحتوى وتحريره:

 import {Chart} from './snowfall.js' export const year = 2018 # Last year's snowfall In {year}, the snowfall was above average. It was followed by a warm spring which caused flood conditions in many of the nearby rivers. <Chart year={year} color="#fcb32c" />

كمية المعرفة المفترضة فقط لهذا المثال البسيط كبيرة. تحتاج إلى معرفة وحدات ES6 ومتغيرات JavaScript وبناء جملة قوالب JSX وكيفية استخدام الدعائم والأكواد السداسية وأنواع البيانات ، ويجب أن تكون على دراية بالمكونات التي يمكنك استخدامها وكيفية استخدامها. وتحتاج إلى كتابته بشكل صحيح وفي بيئة تمنحك نوعًا من الملاحظات. ليس لدي شك في أنه سيكون هناك المزيد من أدوات التأليف التي يمكن الوصول إليها أعلى MDX ، يبدو الأمر وكأنه حل لشيء لا يحتاج إلى أن يكون مشكلة في المقام الأول.

ما لم تكن مجتهدًا للغاية في كيفية تكوين مكونات MDX الخاصة بك وتسميتها ، فإنه يربط أيضًا المحتوى الخاص بك بعرض تقديمي محدد. خذ فقط المثال أعلاه الذي تم إحضاره من الصفحة الأولى لـ MDX. ستجد سداسي اللون ذي الترميز الثابت للمخطط. عند إعادة تصميم موقعك ، قد لا يكون هذا اللون متوافقًا مع نظام التصميم الجديد الخاص بك. بالطبع ، لا يوجد شيء يمنعك من تجريد هذا واستخدام color=”primary” ، ولكن لا يوجد أيضًا أي شيء في الأداة يدفعك لاتخاذ قرارات حكيمة مثل هذه.

أصبح تضمين مخاوف عرض محددة في المحتوى الخاص بك مسؤولية متزايدة وشيء من شأنه أن يعيق التكيف والتكرار والتحرك بسرعة مع المحتوى الخاص بك. إنه يقفله بطرق أكثر دقة بكثير من وجود محتوى في قاعدة بيانات. أنت تخاطر بأن ينتهي بك الأمر في نفس المكان مثل الخروج من تثبيت WordPress الناضج باستخدام المكونات الإضافية. من المرهق فك دمج الهيكل والعرض التقديمي.

الطلب على المحتوى المنظم

مع المواقع الأكثر تعقيدًا ورحلات المستخدم ، نرى أيضًا الحاجة إلى تقديم نفس أجزاء المحتوى عبر موقع الويب. إذا كنت تدير موقعًا للتجارة الإلكترونية ، فأنت تريد تضمين معلومات المنتج في العديد من الأماكن خارج صفحة منتج واحدة. إذا كنت تدير موقعًا تسويقيًا حديثًا ، فأنت تريد أن تكون قادرًا على مشاركة نفس النسخة عبر طرق عرض مخصصة متعددة.

للقيام بذلك بكفاءة وموثوقية ، ستحتاج إلى تكييف المحتوى المنظم. هذا يعني أن المحتوى الخاص بك يجب أن يتم تضمينه مع البيانات الوصفية وتقطيعه بطرق تجعل من الممكن التحليل بحثًا عن النية. إذا شاهد المطور "صفحة" بها "محتوى" فقط ، فإن هذا يجعل من الصعب جدًا تضمين الأشياء المناسبة في الأماكن الصحيحة. إذا تمكنوا من الوصول إلى جميع "أوصاف المنتج" باستخدام واجهة برمجة التطبيقات أو استعلام ، فهذا يجعل كل شيء أسهل.

مع تخفيض السعر ، فأنت مقيد بالتعبير عن التصنيفات والمحتوى المنظم إما بنوع من تنظيم المجلد (مما يجعل من الصعب وضع نفس المحتوى في تصنيفات متعددة) أو تحتاج إلى زيادة بناء الجملة بشيء آخر.

قدم Jekyll ، وهو مولد موقع ثابت مبكر (SSG) تم تصميمه لملفات التخفيضات ، "Front Matter" كطريقة لإضافة البيانات الوصفية إلى المنشورات باستخدام YAML (تنسيق بسيط لقيمة المفتاح يستخدم مسافات لإنشاء النطاق) بين ثلاث شرطات في الأعلى من الملف. لذا ، سيكون لديك الآن صيغتان للتعامل معهما. تتمتع YAML أيضًا بسمعة طيبة في كونها مؤذية (خاصة إذا كنت من النرويج). ومع ذلك ، فقد تبنت مجموعات SSG الأخرى هذه الاتفاقية ، بالإضافة إلى أنظمة إدارة المحتوى المستندة إلى بوابة والتي تستخدم تخفيض السعر كتنسيق للمحتوى الخاص بهم.

عندما يتعين عليك إضافة بناء جملة إضافي إلى ملفاتك العادية للحصول على بعض إمكانيات المحتوى المنظم ، فقد تبدأ في التساؤل عما إذا كان الأمر يستحق ذلك حقًا. ومن هو التنسيق ومن يستبعد.

إذا فكرت في الأمر ، فإن الكثير مما نقوم به على الويب لا يقتصر على استهلاك المحتوى ، بل نقوم بإنشائه! أكتب حاليًا هذا المقال المطول في معالج نصوص متقدم في متصفحي.

هناك توقع متزايد بأنه يجب أن تكون قادرًا أيضًا على تأليف محتوى حظر في تطبيقات المحتوى الحديثة. بدأ الناس في التعود على تجارب مستخدم مبهجة تعمل وتبدو لطيفة ، وحيث لا يُتوقع منك تعلم بناء جملة متخصص. أشاع متوسط ​​فكرة أنه يمكنك إنشاء محتوى مبهج وبديهي على الويب. وبالحديث عن "الفكرة" ، فإن تطبيق الملاحظات الشهير قد دخل بالكامل في محتوى الحظر ، ويسمح للمستخدمين بمزج الحد الأقصى من مجموعة واسعة من الأنواع المختلفة. تذهب معظم هذه الكتل إلى ما هو أبعد من التخفيضات والعناصر الأصلية لـ HTML.

من الجدير بالملاحظة أن Notion ، التي تصف عمليتهم لجعل المحتوى الخاص بهم يمكن الوصول إليه من خلال واجهة برمجة التطبيقات (API) المرتقبة للغاية ، تشير إلى اختيار تنسيق المحتوى الخاص بهم ، وهو:

غالبًا ما يتم تحليل المستندات من محرر Markdown وتقديمها بشكل مختلف في تطبيق آخر. يميل التناقض إلى أن يكون قابلاً للإدارة بالنسبة للمستندات البسيطة ، ولكنه يمثل مشكلة كبيرة لمكتبة Notion الغنية بالكتل وخيارات التنسيق المضمنة ، والتي لا يتم دعم الكثير منها في أي تطبيق Markdown واسع الاستخدام.

تم استخدام Notion بتنسيق يستند إلى JSON يسمح لهم بالتعبير عنها كبيانات منظمة. حجتهم هي أنه يجعل من الأسهل والأكثر توقعًا للتفاعل مع المطورين الذين يرغبون في إنشاء عرضهم التقديمي الخاص لمحتوى الكتلة الذي يأتي من واجهات برمجة تطبيقات Notion.

إذا لم يكن الأمر Markdown ، فماذا بعد؟

أظن أن شهرة Markdown قد أعاقت الابتكار والتقدم للمحتوى الرقمي. لذلك ، عندما أزعم أنه يجب علينا التوقف عن اختياره كطريقة أساسية لتخزين المحتوى ، فمن الصعب إعطاء إجابة مباشرة لما يجب أن يحل محله. ما نعرفه ، مع ذلك ، هو ما يجب أن نتوقعه من تنسيقات المحتوى الحديثة وأدوات التأليف.

دعنا نستثمر في تجارب التأليف التي يمكن الوصول إليها

يتطلب استخدام تخفيض السعر أن تتعلم بناء الجملة ، وغالبًا ما تكون صيغًا متعددة وعلامات مخصصة لتكون عمليًا مع التوقعات الحديثة. اليوم ، يبدو هذا وكأنه توقع غير ضروري على الإطلاق لوضعه على معظم الناس. أتمنى أن نتمكن من توجيه المزيد من الطاقة إلى توفير تجارب تحريرية مبهجة وسهلة المنال تنتج تنسيقات محتوى محمولة حديثة.

على الرغم من صعوبة إنشاء برامج تحرير محتوى كتلة رائعة ، إلا أن هناك خيارين قابلين للتطبيق يمكن توسيعهما وتخصيصهما لحالة الاستخدام الخاصة بك (على سبيل المثال Slate.js أو Quill.js أو Prosemirror). ثم مرة أخرى ، قد يساعد الاستثمار في المجتمعات حول هذه الأدوات أيضًا في تطويرها بشكل أكبر.

على نحو متزايد ، يتوقع الناس أن تكون أدوات التأليف قابلة للوصول ، وفي الوقت الفعلي ، وتعاونية. لماذا يتعين على المرء الضغط على زر الحفظ على الويب في عام 2021؟ لماذا لا يكون من الممكن إجراء تغيير في مستند دون المخاطرة بحالة العرق ، لأن زميلك قد فتح المستند في علامة تبويب بالصدفة؟ هل يجب أن نتوقع من المؤلفين أن يتعاملوا مع تعارضات الدمج؟ ألا يجب أن نجعل من السهل على منشئي المحتوى العمل مع محتوى منظم بإمكانيات مرئية منطقية؟

لكي تكون جدليًا بعض الشيء: ابتكارات العقد الماضي في أطر عمل JavaScript التفاعلية ومكونات واجهة المستخدم مثالية لإنشاء أدوات تأليف رائعة. بدلاً من استخدامها لتحويل Markdown إلى HTML وفي شجرة بناء جملة مجردة لدمجها بعد ذلك في لغة قالب JavaScript تخرج HTML.

يجب أن يتبع محتوى الحظر أحد المواصفات

لم أذكر محررات WYSIWYG لـ HTML. لأنهم الشيء الخطأ. يفضل أن تتعامل محررات محتوى الكتل الحديثة مع تنسيق محدد. لدى المحررين المذكورين أعلاه على الأقل نموذج مستند داخلي معقول يمكن تحويله إلى شيء أكثر قابلية للنقل. If you look at the content management system landscape, you start to see various JSON-based block content formats emerge. Some of them are still tied to HTML assumptions or overly concerned with character positions. And none of them aren't really offered as a generic specification.

At Sanity.io, we decided early that the block content format should never assume HTML as neither input nor output, and that we could use algorithms to synchronize text strings. More importantly, was it that block content and rich text should be deeply typed and queryable. The result was the open specification Portable Text. Its structure not only makes it flexible enough to accommodate custom data structures as blocks and inline spans; it's also fully queryable with open-source query languages like GROQ.

Portable Text isn't design to be written or be easily readable in its raw form; it's designed to be produced by an user interface, manipulated by code, and to be serialized and rendered where ever it needs to go. For example, you can use it to express content for voice assistants.

 { "style": "normal", "_type": "block", "children": [ { "_type": "span", "marks": ["a-key", "emphasis"], "text": "some text" } ], "markDefs": [ { "_key": "a-key", "_type": "markType", "extraData": "some data" } ] }

An interesting side-effect of turning block content into structured data is exactly that: It becomes data! And data can be queried and processed. That can be highly useful and practical, and it lets you ask your content repository questions that would be otherwise harder and more errorprone in formats like Markdown.

For example, if I for some reason wanted to know what programming languages we've covered in examples on Sanity's blog, that's within reach with a short query. You can imagine how trivial it is to build specialized tools and views on top of this that can be helpful for content editors:

 distinct( *["code" in body[]._type] .body[_type == "code"] .language ) // output [ "text", "javascript", "json", "html", "markdown", "sh", "groq", "jsx", "bash", "css", "typescript", "tsx", "scss" ]

Example: Get a distinct list of all programming languages that you have code blocks of.

Portable Text is also serializable, meaning that you can recursively loop through it, and make an API that exposes its nodes in callback functions mapped to block types, marked-up spans, and so on. We have spent the last years learning a lot about how it works and how it can be improved, and plan to take it to 1.0 in the near future. The next step is to offer an editor experience outside of Sanity Studio. As we have learned from Markdown, the design intent is important.

Of course, whatever the alternative to markdown is, it doesn't need to be Portable Text, but it needs to be portable text. And it needs to share a lot of its characteristics. There have been a couple of other JSON-based block content format popping up the last few years, but a lot of them seem to bring with them a lot of “HTMLism.” The convenience is understandable, since a lot of content still ends up on the web serialized into HTML, but the convenience limits the portability and the potential for reuse.

You can disregard my short pitch for something we made at Sanity, as long as you embrace the idea of structured content and formats that let you move between systems in a fundamental manner. For example, a goal for Portable Text will be improved compatibility with Unified.js, so it's easier to travel between formats.

Embracing The Legacy Of Markdown

Markdown بكل مذاقه وتفسيراته وشوكه لن يختفي. I suspect that plain text files will always have a place in developers' note apps, blogs, docs, and digital gardens. As a writer who has used markdown for almost two decades, I've become accustomed to “markdown shortcuts” that are available in many rich text editors and am frequently stumped from Google Docs' lack of markdownisms. But I'm not sure if the next generation of content creators and even developers will be as bought in on markdown, and nor should they have to be.

I also think that markdown captured a culture of savvy tinkerers who love text, markup, and automation. I'd love to see that creative energy expand and move into collectively figuring out how we can make better and more accessible block content editors, and building out an ecosystem around specifications that can express block content that's agnostic to HTML. Structured data formats for block content might not have the same plain text ergonomics, but they are highly “tinkerable” and open for a lot of creativity of expression and authoring.

If you are a developer, product owner, or a decision-maker, I really want you to be circumspect of how you want to store and format your content going forward. If you're going for markdown, at least consider the following trade-offs:

Markdown is not great for the developer experience in modern stacks :

• It can be a hassle to parse and validate, even with great tooling.
• Even if you adopt CommonMark, you aren't guaranteed compatibility with tooling or people's expectations.
• It's not great for structured content, YAML frontmatter only takes you so far.

Markdown is not great for editorial experience :

• Most content creators don't want to learn syntax, their time is better spent on other things.
• Most markdown systems are brittle, especially when people get syntax wrong (which they will).
• It's hard to accommodate great collaborative user experiences for block content on top of markdown.

Markdown is not great in block content age , and shouldn't be forced into it. Block content needs to:

• Be untangled from HTMLisms and presentation agnostic.
• Accommodate structured content, so it can be easily used wherever it needs to be used.
• Have stable specification(s), so it's possible to build on.
• Support real-time collaborative systems.

What's common for people like me who challenge the prevalence of markdown, and those who are really into the simple way of expressing text formating is an appreciation of how we transcribe intent into code. That's where I think we can all meet. But I do think it's time to look at the landscape and the emerging content formats that try to encompass modern needs, and ask how we can make sure that we build something that truly caters to editorial experience, and that can speak to developer experience as well.

I want to express my gratitude to Titus Wormer (@wooorm) for his insightful feedback on my first draft of this post, and for the great work he and the Unified.js team have done for the web community.