AXIOM Company

ليه "جوجل" ممكن يتجاهل موقعك؟ 🤔 (السر في الـ Semantic HTML)
لو فاكر إن الـ HTML مجرد رص عناصر وخلاص، يبقى لازم تعيد تفكيرك!
كتير مننا بيستخدم الـ في كل حاجة.. حرفياً في كل حاجة! وده بيخلي "عناكب" محركات البحث تتووه جوه كود موقعك.
يعني إيه Semantic HTML؟
يعني تستخدم Tags ليها معنى، بتوصف المحتوى اللي جواها. بدل ما تستخدم فاضي، استخدم:
: للجزء اللي فوق (اللوجو والمينيو).
: خصيصاً لروابط التنقل.
: للمحتوى الأساسي والفريد في الصفحة.
: لو بتكتب مقال أو بوست مستقل.
: عشان تقسم الصفحة لأجزاء واضحة.
: لمعلومات التواصل وحقوق النشر تحت.
طيب وده هيفيدني في إيه؟
1️⃣ SEO أفضل: جوجل بيفهم موقعك أسرع وبيرشحه للناس بشكل أحسن.
2️⃣ Accessibility: بتساعد الأشخاص اللي بيستخدموا Screen Readers إنهم يتصفحوا موقعك بسهولة.
3️⃣ Clean Code: الكود بتاعك بيبقى منظم، سهل القراءة، واحترافي لو حد غيرك هيعدل عليه.
نصيحة الأسبوع:
المرة الجاية وأنت بتبني Layout لموقعك، اسأل نفسك: "هل العنصر ده ليه Tag مخصص يوصفه؟" لو الإجابة أيوة، ابعد عن الـ فوراً! 🚫
💬 قولي في الكومنتات: إيه أكتر Tag عرفت أهميته مؤخراً وبدأت تستخدمه؟
#برمجة

📌اجعل Navbar يتابع القسم الذي تتصفحه تلقائيًا!

هل تريد أن تبدو صفحات موقعك أكثر احترافية؟
باستخدام JavaScript وIntersection Observer، يمكن للـ Navbar تغيير الرابط النشط أثناء التصفح بسهولة.

✅ النتيجة:

تجربة مستخدم سلسة

Navbar يوضح دائمًا مكان المستخدم في الصفحة

تصميم أكثر احترافية وسهولة للتنقل

Validation في الـ Front-End: حماية أم وهم!
كثير من المشاريع ما زالت تعتمد على
Client-Side Validation كخط دفاع أساسي…
رسائل خطأ جميلة
حقول مقفولة
Regex ذكي
لكن الحقيقة التقنية مختلفة تمامًا.
🔍 ماذا يفعل الـ Front-End Validation فعليًا؟
تحسين تجربة المستخدم
تقليل الأخطاء غير المقصودة
تسريع التفاعل مع النموذج
❌ وماذا لا يفعل؟
لا يمنع التلاعب بالطلبات
لا يحمي من تعديل الـ Payload
لا يوقف الهجمات المتعمدة
أي Validation يتم تنفيذه في المتصفح
يمكن تجاوزه بسهولة.
⚠️ تاريخيًا… كثير من الثغرات بدأت هنا منها:
تعديل قيم مخفية (Hidden Fields)
تجاوز قيود الواجهة
إرسال Requests مباشرة إلى الـ API
كلها تمت رغم وجود
“Validation كامل” في الواجهة.
❗ !أين الخطأ الحقيقي؟ الخطأ ليس في الـ Front-End
بل في اعتباره طبقة أمان.
Front-End Validation ≠ Security
🎯 فلسفتنا في Axiom في Axiom نؤمن أن:
الـ Front-End لتحسين التجربة
الـ Back-End هو خط الدفاع الحقيقي
لكن الأهم:
أي منطق يُنفذ على العميل…
يجب افتراض أنه مكشوف.
الأمان يبدأ عندما نفهم حدود كل طبقة.

إزاي تصمم زرار (Button) احترافي بلمسة عصرية؟ ✨🚀
الـ Buttons مش مجرد كود، دي أكتر حاجة المستخدم بيتفاعل معاها في موقعك! وعشان كده النهاردة هنتعلم إزاي نحول زرار بسيط لشكل Pro باستخدام HTML & CSS. 💻
تصفح الصور عشان تعرف السر وتشوف الخطوات: 👇
🔹 الصورة الأولى: العنوان والنتيجة النهائية اللي هنوصلها.
🔹 الصورة الثانية: كود الـ HTML (الهيكل الأساسي للزرار).
🔹 الصورة الثالثة: كود الـ CSS (تنسيق الألوان، الحواف، والظلال) و إضافة الـ Hover Effect عشان الزرار يكون تفاعلي وحيوي.
🔹 الصورة الرابعة: النتيجه النهائيه .
💡 نصيحة للمبرمجين: الـ transition في الـ CSS هو السر اللي بيخلي حركة الزرار ناعمة (Smooth) ومريحة للعين، متنساش تضيفه دايماً!
طبقوا الكود عندكم وقولولنا في الكومنتات إيه أكتر حاجة محتاجين نشرحها المرة الجاية؟ 👇

CSS: لغة شكل؟ أم لغة سلوك؟
كثيرون ما زالوا ينظرون إلى CSS على أنها لغة شكل فقط…
ألوان، خطوط، هوامش.
لكن الحقيقة التقنية أخطر وأعمق من ذلك بكثير.
🔍 ماذا يمكن لـ CSS فعليًا؟
CSS ليست مجرد “دهان واجهات”، بل يمكنها:
قراءة HTML Attributes عبر Attribute Selectors
التفاعل مع حالات المستخدم (hover – focus – visited – checked)
التأثير على تحميل الموارد (Fonts, Images, URLs)
استغلال سلوك المتصفح في سيناريوهات تسريب معلومات
⚠️ تاريخيًا… CSS استُخدمت في هجمات حقيقية
تم رصد عدة فئات من الهجمات، منها:
CSS-based Data Exfiltration
تسريب بيانات عبر تحميل موارد مشروطة بقيم داخل الصفحة
Abuse of Attribute Selectors
استنتاج محتوى الحقول أو القيم بدون JavaScript
Side-Channel Leaks
استغلال الفروقات الزمنية أو السلوكية داخل المتصفح
هذه ليست نظريات…
بل ثغرات موثقة ظهرت لأن CSS صُنّفت خطأً كلغة “غير مؤذية”.
❗ أين المشكلة الحقيقية؟
المشكلة ليست في CSS نفسها
بل في الاعتقاد الشائع أن:
“أي كود يعمل داخل المتصفح = آمن”
وهذا اعتقاد خطير.
🎯 فلسفتنا في Axiom
في Axiom، نؤمن أن:
كل سطر Front-End هو جزء من الـ Attack Surface
سواء كان:
CSS
HTML
JavaScript
أو حتى Font Loader بسيط
الأمن لا يبدأ من السيرفر فقط…
بل من أول Pixel يُرسم على الشاشة.
🔐 Front-End Security ليس رفاهية — بل ضرورة.

🚀 ليه لازم تفرق بين الـ (*) والـ (body) في كود الـ CSS؟
​في عالم الـ CSS، فيه خطوة بنعملها "تلقائياً" أول ما نبدأ أي مشروع، وهي إننا نحط Styles معينة.. بس هل سألت نفسك قبل كدة: ليه بنحط حاجات في الـ Universal Selector (*) وحاجات تانية في الـ body؟ 🤔
​الفرق بينهم جوهري جداً وممكن يبوظلك الـ Layout لو مش فاهمه صح! تعالوا نعرف الفرق في Axiom:
​✨ 1️⃣ الـ Universal Selector (*):
ده "المايسترو" اللي بيكلم كل عنصر في الصفحة (بدون استثناء).
​استخدامه الصح: بنستخدمه عشان نعمل Reset شامل للمشروع، زي تصفير الـ (Margin & Padding) وتوحيد الـ (Box-sizing).
​خلي بالك: استخدامه بزيادة أو في "تنسيقات شكلية" ممكن يعملك مشاكل غير متوقعة في عناصر تانية!
​✨ 2️⃣ الـ Body Selector:
ده "الأساس" اللي بتتبني عليه الروح البصرية للموقع.
​استخدامه الصح: هنا بنحط الحاجات اللي بتعتمد على الـ Inheritance (الوراثة)، زي نوع الخط (Fonts)، الألوان العامة، وخلفية الصفحة.
​الميزة: هو أأمن وأنظف في التحكم، لأن العناصر بتورث منه التنسيقات بشكل طبيعي وسلس.
​💡 الخلاصة من Axiom:
استخدم الـ (*) عشان تنظف وتصفر إعدادات المتصفح، واستخدم الـ body عشان ترسم الهوية البصرية لموقعك بذكاء.
​الفرق الحقيقي: الـ (*) تأثيره مباشر وقوي على كل حتة، أما الـ body بيمشي بمبدأ الوراثة الهادي والمنظم. 💻🔥
​"قولنا في كومنت، كنت بتستخدم الـ Universal Selector في إيه تاني غير الـ Reset؟"
​

في عالم يتغير بوتيرة غير مسبوقة، حيث تتحول التقنيات وتتجدد الأدوات يومًا بعد يوم، تسعى Axiom إلى أن تكون نقطة الثبات التي يعود إليها كل متعلم. رؤيتنا هي بناء منظومة تعليمية تُعيد تعريف طريقة تعلم البرمجة؛ منظومة ترى أن المعرفة الحقيقية تبدأ من أساسٍ قوي، لكنها لا تتوقف عنده.

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