یک راهنمای سبک برای نوشتن SASS عاقل ، حفظ و مقیاس پذیر.
پروژه دستورالعمل SASS توسط همکاران سخاوتمندانه به چندین زبان ترجمه شده است. پانل گزینه ها را برای سوئیچ باز کنید.
درباره نویسنده
نام من کیتی جیرودل است ، من یک توسعه دهنده جلوی فرانسوی هستم که از سال 2015 در برلین (آلمان) مستقر هستم و هم اکنون در گوریل کار می کنم.
من چندین سال است که در حال نوشتن SASS هستم و نویسنده بسیاری از پروژه های مرتبط با SASS مانند SassDoc ، SitePoint Sass Reference و سازگاری SASS هستم. اگر علاقه مند به کمک های بیشتر من در جامعه SASS هستید ، به آن لیست نگاهی بیندازید.
من همچنین اتفاق می افتد که نویسنده کتابی درباره CSS (به زبان فرانسه) با عنوان CSS3 Pratique du Design Web (Eyrolles Editions) و همچنین کتابی در مورد SASS (به زبان انگلیسی) با عنوان Jump Start Sass (نسخه های یادگیری) هستم.
مشارکت کننده
دستورالعمل های SASS یک پروژه رایگان است که من در اوقات فراغت خود را حفظ می کنم. نیازی به گفتن نیست ، این کار بسیار زیادی است که همه چیز را به روز ، مستند و مرتبط نگه دارید. خوشبختانه ، من به بسیاری از مشارکت کنندگان بسیار کمک می کنم ، به خصوص وقتی صحبت از ده ها ترجمه مختلف می شود. حتما از آنها تشکر کنید!
حال اگر احساس مشارکت می کنید ، لطفاً بدانید که صدای جیر جیر در مورد آن ، پخش کلمه یا رفع یک تایپی کوچک با باز کردن یک مسئله یا یک درخواست کشش در مخزن GitHub بسیار عالی خواهد بود!
آخرین و مهمترین قبل از شروع ما: اگر از این سند لذت می برید ، یا برای شما یا تیم شما مفید است ، لطفاً از آن پشتیبانی کنید تا بتوانم روی آن کار کنم!
درباره SASS
اینگونه است که SASS خود را در مستندات خود توصیف می کند:
SASS پسوند CSS است که قدرت و ظرافت را به زبان اساسی اضافه می کند.
هدف نهایی SASS رفع نقص CSS است. CSS ، همانطور که همه ما می دانیم ، بهترین زبان در جهان نیست [استناد مورد نیاز]. در حالی که یادگیری بسیار ساده است ، به خصوص در پروژه های بزرگ می تواند به سرعت بسیار کثیف شود.
این جایی است که SASS به عنوان یک متا زبان برای بهبود نحو CSS به منظور ارائه ویژگی های اضافی و ابزارهای مفید وارد می شود. در همین حال ، ساس می خواهد در مورد زبان CSS محافظه کار باشد.
نکته این است که CSS را به یک زبان برنامه نویسی کاملاً برجسته تبدیل نکنید. SASS فقط می خواهد در جایی که CSS شکست بخورد ، کمک کند. به همین دلیل ، شروع با SASS سخت تر از یادگیری CSS نیست: این به سادگی چند ویژگی اضافی را در بالای آن اضافه می کند.
گفته می شود ، روش های زیادی برای استفاده از این ویژگی ها وجود دارد. برخی خوب ، برخی بد ، برخی غیرمعمول. این دستورالعمل ها به منظور ارائه یک رویکرد مداوم و مستند برای نوشتن کد SASS است.
Ruby Sass یا Libsass
اولین تعهد Sass تا اواخر سال 2006 ، بیش از 10 سال پیش برمی گردد. نیازی به گفتن نیست که از آن زمان تاکنون مسیری طولانی را طی کرده است. در ابتدا در روبی ، بنادر متنوع در اینجا و آنجا ظاهر شد. موفق ترین مورد ، Libsass (که در C/C ++ نوشته شده است) اکنون نزدیک است که کاملاً با نسخه اصلی Ruby سازگار باشد.
در سال 2014 ، تیم های Ruby Sass و Libsass تصمیم گرفتند قبل از حرکت به جلو ، همگام سازی هر دو نسخه منتظر بمانند. از آن زمان ، Libsass به طور فعال نسخه هایی را منتشر می کند تا با خواهر و برادر بزرگتر خود از ویژگی های خاص برخوردار باشد. آخرین ناسازگاری های باقی مانده توسط خودم تحت پروژه سازگاری SASS جمع آوری و ذکر شده است. اگر از ناسازگاری بین دو نسخه که ذکر نشده است آگاه هستید ، لطفاً به اندازه کافی مهربان باشید که بتوانید یک مسئله را باز کنید.
بازگشت به انتخاب کامپایلر. در واقع ، همه اینها به پروژه شما بستگی دارد. اگر این یک پروژه Ruby on Rails است ، شما بهتر از Ruby Sass استفاده می کنید ، که برای چنین موردی کاملاً مناسب است. همچنین ، توجه داشته باشید که Ruby Sass همیشه اجرای مرجع خواهد بود و همیشه Libsass را در ویژگی ها هدایت می کند. و اگر به دنبال تغییر از Ruby Sass به Libsass هستید ، این مقاله برای شما مناسب است.
در پروژه های غیر رقیق که نیاز به یکپارچه سازی گردش کار دارند ، Libsass احتمالاً ایده بهتری است زیرا بیشتر به بسته بندی اختصاص داده شده است. بنابراین اگر می خواهید استفاده کنید ، بگذارید Node. js را بگوییم ، Node-Sass همه انتخاب شده است.
SASS یا SCSS
در مورد معناشناسی نام SASS سردرگمی زیادی وجود دارد و به دلایل خوبی: SASS به معنای پیش پردازنده و نحو خاص خود است. خیلی راحت نیست؟
می بینید ، SASS در ابتدا نحو را توصیف کرد که ویژگی تعیین کننده آن حساسیت به آن بود. به زودی ، نگهبانان SASS تصمیم گرفتند با تهیه یک نحو سازگار با CSS به نام SCSS برای CSS SASSY ، شکاف بین SASS و CSS را ببندند. شعار این است: اگر CSS معتبر باشد ، SCSS معتبر است.
از آن زمان ، SASS (پیش پردازنده) دو نحو مختلف را ارائه می دهد: SASS (نه همه کپسول ، لطفاً) ، که به عنوان نحو متمایز و SCS نیز شناخته می شود. کدام یک از آنها استفاده می کند تقریباً به شما بستگی دارد زیرا هر دو از نظر ویژگی ها کاملاً معادل هستند. این فقط موضوع زیبایی شناسی در این مرحله است.
نحو حساس به فضای سفید SASS برای خلاص شدن از شر بریس ، نیمه ستون و سایر نمادهای نگارشی ، به تورفتگی متکی است و منجر به یک نحو لاغر و کوتاه تر می شود. در همین حال ، SCSS یادگیری آسان تر است زیرا بیشتر برخی از بیت های اضافی کوچک در بالای CSS است.
من ، خودم ، SCSS را بیش از SASS ترجیح می دهم زیرا به CSS نزدیکتر است و برای اکثر توسعه دهندگان دوستانه تر است. به همین دلیل ، SCSS نحو پیش فرض در طول این دستورالعمل ها است. می توانید در پنل جانبی به نحوی SASS SASS تغییر دهید.
سایر پردازنده ها
SASS پیش پردازنده در میان دیگران است. جدی ترین رقیب آن باید کمتر باشد ، یک پردازنده مبتنی بر Node. js که به لطف بوت استرپ معروف CSS Framework با استفاده از آن (تا نسخه 4) بسیار محبوب شده است. همچنین قلم ، یک پیش پردازنده بسیار مجاز و انعطاف پذیر وجود دارد ، اما استفاده از آن کمی سخت تر و با یک جامعه کوچکتر است.
چرا SASS را بیش از هر پردازنده دیگر انتخاب کنید؟امروز هنوز یک سوال معتبر است. چندی پیش ، ما قبلاً SASS را برای پروژه های مبتنی بر روبی توصیه می کردیم زیرا برای اولین بار در روبی ساخته شده بود و با روبی روی ریل خوب بازی می کرد. اکنون که Libsass با SASS اصلی (بیشتر) گرفتار شده است ، این دیگر توصیه های مرتبط نیست.
آنچه من با SASS دوست دارم رویکرد محافظه کارانه آن به CSS است. طراحی Sass مبتنی بر اصول قوی است: بسیاری از رویکرد طراحی به طور طبیعی از اعتقاد تیم های اصلی خارج می شود که الف) اضافه کردن ویژگی های اضافی دارای هزینه پیچیدگی است که باید با سودمندی توجیه شود و ب) باید به راحتی استدلال کرددر مورد آنچه که یک بلوک خاص از سبک ها با نگاه کردن به آن بلوک به تنهایی انجام می شود. همچنین ، SASS نسبت به سایر پردازنده ها توجه بسیار واضح تری به جزئیات دارد. تا آنجا که من می توانم بگویم ، طراحان اصلی عمیقاً از پشتیبانی از هر گوشه سازگاری CSS مراقبت می کنند و اطمینان حاصل می کنند که هر رفتار کلی سازگار است. به عبارت دیگر ، SASS یک نرم افزار با هدف حل مسائل واقعی است. کمک به ارائه قابلیت های مفید برای CSS که در آن CSS کوتاه است.
پیش پردازنده ها ، ما همچنین باید ابزارهایی مانند POSTCS و CSSNext را ذکر کنیم که در چند ماه گذشته در معرض دید قابل توجهی قرار گرفته اند.
POSTCS معمولاً (و نادرست) به عنوان "پردازنده" گفته می شود. فرض ، همراه با نام ناگوار ، این است که POSTCS را بر روی CSS تجزیه می کند که قبلاً توسط یک پیش پردازنده پردازش شده است. اگرچه می تواند به این روش کار کند ، این یک الزام نیست ، بنابراین POSTCS در واقع فقط یک "پردازنده" است.
این امکان را به شما می دهد تا به "نشانه های" برگه های سبک خود (مانند انتخاب کنندگان ، خصوصیات و مقادیر) دسترسی پیدا کنید ، این موارد را با JavaScript پردازش کنید تا برخی از عملکردها را انجام دهید و نتایج را به CSS انجام دهید. به عنوان مثال ، پیشوند محبوب کتابخانه Autoprefixer با POSTCS ساخته شده است. این قانون را برای دیدن اینکه آیا پیشوندهای فروشنده با مراجعه به ابزار پشتیبانی مرورگر Caniuse مورد نیاز هستند ، تجزیه می کند و سپس پیشوندهای فروشنده مورد نیاز را حذف و اضافه می کند.
این امر برای ساخت کتابخانه هایی که با هر پردازنده پیش پردازنده (و همچنین CSS وانیلی) کار می کنند ، فوق العاده قدرتمند و بسیار عالی است ، اما استفاده از POSTCS هنوز به خصوص آسان نیست. شما باید برای ساختن هر چیزی با آن ، کمی جاوا اسکریپت بدانید و API آن در بعضی مواقع می تواند گیج کننده باشد. در حالی که SASS فقط مجموعه ای از ویژگی ها را برای نوشتن CSS فراهم می کند ، POSTCS دسترسی مستقیم به CSS AST (درخت نحوی انتزاعی) و JavaScript را فراهم می کند.
به طور خلاصه ، SASS تا حدودی آسان است و بیشتر مشکلات شما را حل می کند. از طرف دیگر ، POSTCS می تواند دشوار باشد (اگر با JavaScript عالی نیستید) اما به نظر می رسد فوق العاده قدرتمند است. هیچ دلیلی وجود ندارد که نتوانید و نباید از هر دو استفاده کنید. در حقیقت ، POSTCSS فقط یک تجزیه و تحلیل رسمی SCSS را برای این کار ارائه می دهد.
با تشکر از کوری سیمونز به خاطر کمک و تخصص وی در این بخش.
معرفی
چرا یک راهنمای سبک
یک StyleGuide فقط یک سند دلپذیر برای خواندن نیست ، و یک حالت ایده آل برای کد شما تصویر می کند. این یک سند کلیدی در زندگی یک پروژه است و توصیف می کند که چگونه و چرا باید کد نوشته شود. ممکن است برای پروژه های کوچک مانند بیش از حد به نظر برسد ، اما در تمیز کردن پایگاه کد ، مقیاس پذیر و به راحتی قابل نگهداری است.
نیازی به گفتن نیست ، هرچه توسعه دهندگان بیشتر در یک پروژه درگیر شوند ، دستورالعمل های کد بیشتری لازم است. در همین راستا ، هرچه پروژه بزرگتر باشد ، یک سبک سبک نیز ضروری است.
- ساخت و نگهداری محصولات برای مدت زمان معقول ؛
- از توسعه دهندگان توانایی ها و تخصص های مختلف برخوردار هستند.
- تعدادی از توسعه دهندگان مختلف داشته باشید که در هر زمان معینی روی یک محصول کار می کنند.
- به طور مرتب کارکنان جدید روی صفحه ؛
- تعدادی از کد های کد دارند که توسعه دهندگان از داخل و خارج می شوند.
سلب مسئولیت
اولین چیزها اول: این یک راهنمای سبک CSS نیست. این سند در مورد نامگذاری کنوانسیون های کلاس های CSS ، الگوهای مدولار و سوال IDS در دنیای CSS بحث نخواهد کرد. این دستورالعمل ها فقط هدف برخورد با محتوای خاص SASS است.
همچنین ، این StyleGuide خود من است و بنابراین بسیار عقیده است. آن را به عنوان مجموعه ای از روش ها و توصیه هایی که در طول سالها صیقل داده ام و داده ام ، فکر کنید. همچنین این امکان را به من می دهد تا به تعداد انگشت شماری از منابع روشنگری پیوند برقرار کنم ، بنابراین حتماً قرائت های بعدی را بررسی کنید.
بدیهی است ، این مطمئناً تنها راه انجام کارها نیست و ممکن است متناسب با پروژه شما باشد. احساس راحتی کنید که از آن انتخاب کنید و آن را با نیازهای خود تطبیق دهید. همانطور که می گوییم ، مسافت پیموده شده شما ممکن است متفاوت باشد.
اصول اساسی
در پایان روز ، اگر یک چیز وجود داشته باشد ، من دوست دارم شما را از کل این سبک سبک دریافت کنید ، این است که SASS باید به همان اندازه ساده نگه داشته شود.
با تشکر از آزمایش های احمقانه من مانند اپراتورهای Bitwise ، تکرارها و ژنراتورها و یک تجزیه کننده JSON در SASS ، همه ما به خوبی از آنچه می توان با این پیش پردازنده انجام داد ، آگاه هستیم.
در همین حال ، CSS یک زبان ساده است. SASS ، که برای نوشتن CSS در نظر گرفته شده است ، نباید بسیار پیچیده تر از CSS معمولی باشد. اصل بوسه (آن را احمق نگه دارید) در اینجا مهم است و حتی ممکن است در برخی شرایط بر اصل خشک (خود را تکرار نکنید).
بعضی اوقات ، بهتر است به جای ساختن یک سیستم سنگین ، ناخوشایند و غیر ضروری پیچیده که کاملاً غیرقابل تحمل است ، کمی تکرار شود ، به دلیل اینکه کاملاً پیچیده است ، به جای ساختن یک سیستم سنگین ، ناخوشایند و غیر ضروری پیچیده است.
همچنین ، و بگذارید بار دیگر هری رابرتز را نقل کنم ، عمل گرایی کمال را برآورده می کند. در بعضی از مواقع ، احتمالاً خود را خلاف قوانینی که در اینجا شرح داده شده است ، خواهید دید. اگر منطقی باشد ، اگر احساس درستی داشته باشد ، این کار را انجام دهید. کد فقط یک وسیله است ، نه یک پایان.
گسترش دستورالعمل ها
بخش بزرگی از این سبک به شدت عقیده دارد. من چندین سال است که در حال خواندن و نوشتن SASS هستم ، تا جایی که اکنون هنگام نوشتن نامه های تمیز ، اصول زیادی را دارم. من می فهمم که ممکن است همه از همه راضی نباشد و مناسب همه نباشد ، و این کاملاً طبیعی است.
اگرچه ، من معتقدم که دستورالعمل ها برای تمدید ساخته شده اند. گسترش دستورالعمل های SASS می تواند به سادگی داشتن سندی باشد که بیان می کند کد پیروی از دستورالعمل های این سبک است به جز چند مورد. در این صورت ، قوانین خاص در زیر توضیح داده می شود.
نمونه ای از پسوند StyleGuide را می توان در مخزن SassDoc یافت:
این یک برنامه افزودنی به Node StyleGuide توسط Felix Geisendörfer است. هر چیزی از این سند آنچه را که می توان در Node StyleGuide گفت ، غلبه می کند.
نحو و قالب بندی
اگر از من بپرسید ، اولین کاری که یک StyleGuide باید انجام دهد توصیف روشی است که ما می خواهیم کد ما به نظر برسد.
هنگامی که چندین توسعه دهنده درگیر نوشتن CSS در همان پروژه (ها) هستند ، فقط زمان لازم است قبل از اینکه یکی از آنها شروع به انجام کارها به روش خود کند. دستورالعمل های کد که باعث تقویت سازگاری می شود نه تنها از این امر جلوگیری می کند ، بلکه در هنگام خواندن و به روزرسانی کد نیز به شما کمک می کند.
تقریباً ، ما می خواهیم (با الهام از دستورالعمل های CSS):
- دو (2) فضاها ، بدون برگه.
- در حالت ایده آل ، خطوط گسترده 80 شخصیت ؛
- قوانین CSS چند خطی به درستی نوشته شده است.
- استفاده معنی دار از فضای سفید.
رشته های
باور کنید یا نه ، رشته ها در هر دو اکوسیستم CSS و SASS نقش زیادی دارند. بیشتر مقادیر CSS یا طول یا شناسه هستند ، بنابراین در هنگام برخورد با رشته های SASS ، به برخی از دستورالعمل ها بسیار مهم است.
رمز
برای جلوگیری از هرگونه مشکل بالقوه در رمزگذاری شخصیت ، توصیه می شود که با استفاده از دستورالعمل CharSet ، رمزگذاری UTF-8 را در صفحه اصلی شیوه اصلی مجبور کنید. اطمینان حاصل کنید که این اولین عنصر صفحه شیوه است و قبل از آن شخصیتی از هر نوع وجود ندارد.
نقل قول
CSS نیازی به رشته ها ندارد ، حتی آنهایی که حاوی فضاهای هستند. به عنوان مثال نامهای خانوادگی فونت را در نظر بگیرید: فرقی نمی کند که آنها را در نقل قول های تجزیه کننده CSS بسته بندی کنید.
به همین دلیل ، SASS همچنین نیازی به رشته ها ندارد. حتی بهتر (و خوشبختانه ، شما اعتراف خواهید کرد) ، یک رشته نقل شده کاملاً معادل دوقلوهای بی نظیر آن است (به عنوان مثال "ABC" کاملاً برابر با ABC است).
گفته می شود ، زبانهایی که نیازی به رشته ندارند ، قطعاً اقلیت هستند و بنابراین ، رشته ها همیشه باید با نقل قول های منفرد (') در SASS پیچیده شوند (یک نوع ساده تر از دو برابر در صفحه کلید QWERTY). علاوه بر سازگاری با زبانهای دیگر ، از جمله پسر عموی CSS JavaScript ، دلایل مختلفی برای این انتخاب وجود دارد:
- نام های رنگی هنگام عدم وجود به عنوان رنگ ها رفتار می شوند که می تواند منجر به مشکلات جدی شود.
- بیشتر برجسته های نحوی در رشته های بدون سیم خفه می شوند.
- این به خوانایی عمومی کمک می کند.
- هیچ دلیل معتبری برای نقل قول رشته ها وجود ندارد.
طبق مشخصات CSS ، دستورالعمل CharSet باید در نقل قول های مضاعف اعلام شود تا معتبر تلقی شود. با این حال ، SASS هنگام تهیه CSS از این امر مراقبت می کند ، بنابراین نویسنده هیچ تاثیری در نتیجه نهایی ندارد. شما می توانید با خیال راحت به نقل قول های مجرد ، حتی برای charset بچسبید.
رشته ها به عنوان مقادیر CSS
مقادیر خاص CSS (شناسه ها) مانند اولیه یا SANS-SERIF نیازی به نقل نیست. در واقع ، خانواده فونت-خانواده: "Sans-Serif" به سکوت شکست می خورد زیرا CSS در انتظار شناسه است ، نه یک رشته نقل شده. به همین دلیل ، ما آن ارزش ها را نقل نمی کنیم.
از این رو ، ما می توانیم بین رشته های مورد نظر به عنوان مقادیر CSS (شناسه CSS) مانند مثال قبلی ، تمایز قائل شویم و هنگام چسبیدن به نوع داده SASS ، به عنوان مثال کلیدهای نقشه SASS.
ما سابق را نقل نمی کنیم ، اما دومی را در نقل قول های مجرد می بندیم.
رشته های حاوی نقل قول
اگر یک رشته شامل یک یا چند نقل قول واحد باشد ، ممکن است در عوض ، رشته را با نقل قول های مضاعف (") بسته بندی کند تا از فرار کاراکترها در رشته جلوگیری شود. نیازی به نقل نیست. در واقع ، خانواده فونت-خانواده: "Sans-Serif" ساکت خواهد بود زیرا CSS در انتظار شناسه است ، نه یک رشته نقل شده. به همین دلیل ، ما آن مقادیر را نقل نمی کنیم.
استراتژی برای تجارت گزینه های...
ما را در سایت استراتژی برای تجارت گزینه های دنبال می کنید
برچسب :
نویسنده : فریبا کامران
بازدید : 72
تاريخ : دوشنبه
22 خرداد
1402 ساعت: 21:35