حاليًا في Discourse، إذا قمت بلصق نص عادي في المُنشئ، فإن سلوك المتصفح المعتاد عبر Ctrl+Z سيتراجع عن هذا اللصق ويزيل النص الملصق. ومع ذلك، إذا قمت بلصق نص منسق مثل هذا النص الغامق، فلن يعمل التراجع. وبالمثل، لا يمكن التراجع عن لصق الروابط فوق النص لإنشاء روابط لها، ولا يمكن التراجع عن تنسيق markdown الذي تم إدخاله عبر اختصارات مثل Ctrl+B أو عند إضافة تنسيق من خيارات شريط أدوات المُنشئ. من الناحية المثالية، سيتم إضافة أكبر قدر ممكن من هذا إلى مكدس التراجع حتى يعمل Ctrl+Z.
دعني أقدم وصفًا لما يحدث لي كثيرًا.
أقوم بنسخ بعض النصوص من موقع ويب آخر والتي تكون رابطًا، أو نصًا غامقًا، أو عنوانًا، وما إلى ذلك. (في بعض الأحيان يتم تسجيل هذه الحقيقة وفي أحيان أخرى لا يتم ذلك.)
أذهب إلى Discourse للصق هذا النص في منشوري الذي أكتبه جزئيًا بالفعل.
أضغط على Ctrl+V الذي يُدخل النص المنسق.
أدرك خطئي وأضغط على Ctrl+Z، والذي لا يفعل شيئًا.
أقوم بإزالة النص المنسق الذي أدخلته عن طريق الخطأ يدويًا. (في معظم الأحيان يكون الإصدار المرتبط الذي لصقته عن طريق الخطأ، لذلك لا يتعين عليّ إزالة علامة # أو شيء من هذا القبيل.)
أضغط على Ctrl+Shift+V، وهو ما كان ينبغي عليّ فعله في المرة الأولى للصق النص غير المنسق.
من الواضح أن هذا يرجع جزئيًا إلى خطأ المستخدم، وعندما لا أخطئ يكون الأمر مجرد خطوتين (نسخ من موقع ويب آخر، لصق كنص عادي في Discourse). ولكن عندما أخطئ (وهو ما يحدث كثيرًا نظرًا لأنني معتاد على الضغط على Ctrl+V نظرًا لأن معظم مواقع الويب لا تقوم باللصق المنسق) سيكون من الجيد لو تمكنت من توفير بعض الوقت عن طريق جعل Ctrl+Z يعمل كالمعتاد.
حسنًا، لا تعمل التراجع افتراضيًا كلما استخدمت جافاسكريبت لتعديل إدخال. لكنني بحثت ووجدت أن document.execCommand يمكنه إدراج نص مع إلحاقه بمكدس التراجع.
على سبيل المثال، إذا قمت بتنفيذ document.getElementById('myInput').value = 'asd' ثم Ctrl + Z، فلن يتم التراجع.
ولكن إذا قمت بتنفيذ document.execCommand('insertText', false, 'asd') بينما يكون المؤشر في المكان الذي تريده (والذي يجب أن يكون كذلك بناءً على سير عمل Discourse الحالي)، فسيتم إدراج النص بشكل صحيح وسيقوم Ctrl + Z بإزالة النص المضاف كما هو متوقع.
بشكل أساسي، أتساءل عما إذا كان يمكن استخدام document.execCommand (أو أي عملية أخرى إذا تم اعتبار نهج آخر أفضل) لإلحاق مكدس التراجع حتى يعمل Ctrl + Z في هذه الحالات.
لا - لقد قمنا بإزالة هذا الدعم عمدًا من Discourse قبل سنوات لصالح السماح لصندوق النص الأصلي للمتصفح بالتعامل مع التراجع كما ينبغي عبر جميع مواقع الويب القياسية.
أعتقد أنني أفوت شيئًا ما. ماذا يعني “السماح لمعالجة التراجع في مربع النص الأصلي للمتصفح بالعمل” بالضبط؟ بقدر ما أعرف، لا يعمل التراجع للنص المنسق على الإطلاق في Discourse، لذا هل تقول إن عدم عمل التراجع هو سلوك موقع ويب قياسي؟
السبب في ارتبكي هو أنني لا أستطيع التفكير في موقع ويب واحد (بخلاف أشياء مثل Microsoft Word حيث يعمل التراجع) يدعم اللصق المنسق بخلاف Discourse. لذلك ليس لدي ما أقارن به Discourse لرؤية ما هو “قياسي”. إذا كان بإمكانك توجيهي إلى عدد قليل من مواقع الويب للمقارنة، فسيكون ذلك مفيدًا للغاية.
اضغط على جربها بنفسك، ثم أدخل نصًا في مربع النص، توقف مؤقتًا، ثم اضغط على Ctrl+Z للتراجع عن إجراءاتك. إليك عرض توضيحي. أولاً، نضغط على الزر جربها بنفسك، مما يؤدي إلى عرض عنصر HTML <textarea> في المتصفح.
فهمي هو أن @seanblue يسأل عما إذا كان بإمكاننا تعديل واجهات برمجة تطبيقات المتصفح التي نستخدمها عند معالجة مربع النص للإشارة إلى المتصفح بشكل أفضل حتى يتمكن من التعامل مع التراجع بشكل أفضل. لذا سينطبق هذا فقط على اختصارات لوحة المفاتيح، وشريط الأدوات، والتحميل وما شابه ذلك.
أنا لست ضد ضبط الأمور هنا، لكنني أخشى أن تتطلب بعض واجهات برمجة التطبيقات هذه الكثير من العناية، وهناك بالتأكيد خطر حدوث تراجعات.
لست ضد التجارب هنا، ربما إذا أراد المجتمع إرسال بعض طلبات السحب (PRs) لإظهار لنا كيفية القيام بذلك.
يمكننا بالتأكيد أن نفعل أفضل من ذلك هنا. الكثير من أزرار شريط الأدوات وسلوك اللصق المتقدم لدينا يضبطان قيمة مربع النص مباشرة في جافاسكريبت. هذا يكسر تمامًا سجل التراجع/الإعادة الأصلي للمتصفح.
بدلاً من ذلك، كلما قمنا بإجراء تعديلات برمجية على مربع النص، يجب أن نستخدم document.execCommand (كما ذكر @seanblue). بهذه الطريقة، يفسر المتصفح ذلك بنفس طريقة إجراء المستخدم، ويقوم بإدراجه بشكل نظيف في سجل التراجع/الإعادة.
الأمر insertText، والذي يمكنك استخدامه لاستبدال النص برمجيًا في المؤشر مع الحفاظ على مخزن التراجع المؤقت (سجل التعديلات) في عناصر textarea و input العادية.
ولكن مربع النص هذا لا يتعامل مع النص المنسق، وهذا ليس ما أتحدث عنه. أعلم أن المتصفحات تتعامل مع التراجع عن النص المكتوب أو الملصق بشكل طبيعي. نقطتي هي أن Discourse لا يتعامل مع التراجع عن النص المنسق الملصق. اتبع هذه الخطوات لترى ما أتحدث عنه.
هذا صحيح. أنا لا أقترح التعامل مع التراجع بنفسك في JavaScript. أقترح أنه عند معالجة مربع النص، أخبر المتصفح بذلك حتى يتمكن من التراجع عن التغيير بنفسه عندما يضغط المستخدم على Ctrl+Z.
على سبيل المثال، سيتم حل 99٪ من إحباطي إذا عمل Ctrl+Z بعد لصق نص منسق. هل سيكون من المثالي أن يتم التراجع عن كل عملية باستخدام Ctrl+Z؟ بالتأكيد. ولكن يمكن التراجع عن معظم العمليات الأخرى عن طريق تكرار العملية الأصلية (على سبيل المثال، يمكن لـ Ctrl+B إضافة وإزالة تنسيق markdown الغامق). ولكن مع اللصق، لديه القدرة على تضمين كمية كبيرة من تنسيق markdown غير المتوقع، بما في ذلك العناوين والروابط وحتى الجداول، وهذا هو السبب في أنه من المهم جدًا أن يعمل التراجع في هذه الحالة.
إذا قمنا بتضييق النطاق ليشمل فقط التعامل مع التراجع في حالة اللصق المنسق وتجاهلنا اختصارات أخرى وأزرار شريط الأدوات وما إلى ذلك، فهل سيقلل ذلك المخاطر بما يكفي لتجربته؟
حسنًا؛ بين شرحك وشرح @david، أفهم الفرق. أنا فقط لا أستخدم تلك الأزرار في المحرر في معظم الأحيان. أكتب الأشياء في مربع النص باستخدام لوحة مفاتيح الكمبيوتر (سواء كانت فعلية أو على الشاشة)، ويتعامل المتصفح مع ذلك بسلاسة.
هذا مفهوم. أنا أيضًا أميل إلى كتابة الماركداون بدلاً من استخدام أزرار شريط الأدوات لذلك، لذا فإن هذا الجانب ليس مشكلة بالنسبة لي حقًا. لقد ذكرت شريط الأدوات فقط في المنشور الأصلي للإشارة إلى أنه لا يحدث فقط عند لصق نص منسق. القدرة على التراجع عن إجراءات شريط الأدوات ليست مهمة للغاية لأن المستخدم يقوم بتلك الإجراءات عن قصد. ولكن عند اللصق، غالبًا ما يكون التنسيق عرضيًا وغير متوقع، لذا فإن القدرة على التراجع عن ذلك ستكون مريحة للغاية.
أحد الأشياء الجيدة هو أنه (في رأيي) يمكن القيام به بشكل تدريجي بدلاً من الاضطرار إلى إصداره دفعة واحدة. من الواضح أنني لا أعرف ما إذا كان هذا هو الحال من منظور تقني، ولكن من منظور المستخدم أعتقد أنه سيكون على ما يرام. قد تكون بعض الفواصل المنطقية هي:
لصق نص يصبح منسقًا، بما في ذلك أشياء مثل الخط العريض والصور والروابط
سأقوم بتخصيص هذا العمل لإصداره القادم، مما يعني أننا سنقوم بتنظيفه خلال الأشهر الستة القادمة تقريبًا، ولن يحدث ذلك بين عشية وضحاها، لكننا سنحقق تقدمًا هنا.
لقد تطور الأمر ليصبح إعادة هيكلة كاملة مطلوبة للمؤلف. خطتنا طويلة الأجل هي دعم طبقة تجريد مختلفة للمؤلف، والتي أصبحت الآن ملتصقة بشدة بكونها دائمًا عنصر TEXTAREA.
الخطوة الأولى لفك الحظر هي دعم مؤلف قابل للتحرير بالمحتوى يبدو ويتصرف مثل منطقة النص الحالية لدينا.
لا أتوقع أن نبدأ هذا المشروع قبل 3 أشهر أخرى، لأن لدينا 3 مشاريع كبيرة جدًا أخرى أمامه، لكنني بالتأكيد أتوقع أن نبدأ في هذا المشروع هذا العام.
واو، لم أسمع قط عن contenteditable حتى الآن. هل تمانع في مشاركة شرح تقني موجز لسبب الحاجة إلى هذا التغيير/رغبتك فيه؟ إذا لم يكن الأمر كذلك، فلا بأس، أنا فقط فضولي.
إنه معقد إلى حد ما، لكننا نريد الدخول في عالم التجريب بمحررات غنية. هذا من شأنه أن يفتح ذلك.
السبب في أن هذا العمل على المسار الحرج هو أن جميع أجزائنا الداخلية مرتبطة بشدة بتنفيذ معين (TEXTAREA). ليس لدينا وظيفة واحدة للتفاعل مع المؤلف، بل هو أشبه بنسخ ولصق 20 تطبيقًا مختلفًا.
ما نود القيام به هو إنشاء مكون “هيكل عظمي” صغير يقول
هذه هي طريقة تحديد النص
هذه هي طريقة إدراج النص
وهكذا… ثم يمكننا إعادة تنفيذ الهيكل العظمي كمحتوى قابل للتحرير أو تنفيذ صديق للتراجع لـ TEXTAREA.
الكثير من التعليمات البرمجية تحتاج إلى الانتقال للسماح بذلك.
هذا لا يقترب من شمولية العمل طويل الأمد الذي وصفه @sam. لكنني أعتقد أنه سيساعد على المدى القصير. يجب أن يحافظ هذا على سجل التراجع عند لصق نص منسق، والاقتباس، وعند استخدام (معظم) أزرار/اختصارات لوحة المفاتيح في المحرر.
إنه متاح الآن على Meta - أبلغنا إذا لاحظت أي مشاكل.
