จากผู้เขียน: ก่อนอื่นเลย พรีโปรเซสเซอร์คืออะไร? กล่าวโดยสรุป พรีโปรเซสเซอร์คือโปรแกรมที่แก้ไขข้อมูลเพื่อให้เหมาะกับความต้องการอินพุตของโปรแกรมอื่น ตัวประมวลผลล่วงหน้า CSS เป็นภาษาสคริปต์ที่ขยายขีดความสามารถของ CSS ทั่วไปด้วยตัวแปร กฎการซ้อน ฟังก์ชัน และบล็อกแบบลอจิคัล

ทำไมฉันจึงควรใช้มัน?

บ่อยครั้งคุณจะพบว่าตัวเองอยู่ในสถานการณ์ที่คุณต้องใช้งาน ค่าเดียวกันสำหรับคุณสมบัติเฉพาะใน สถานที่ที่แตกต่างกัน. ตัวอย่างเช่น ขั้นแรกคุณระบุสีแดงเป็นสีหลักของไซต์ จากนั้นคุณต้องเปลี่ยนเป็นสีเขียว

ด้วยตัวแปร คุณไม่จำเป็นต้องค้นหาและแทนที่การกล่าวถึงสีแดงทุกครั้งในสไตล์ คุณกำหนดค่าของตัวแปรเพียงครั้งเดียว เช่น "สีหลัก" จากนั้นใช้ตัวแปรนั้นเป็นค่า

ค่าสีหลักจะเปลี่ยนไปในที่เดียว คุณยังสามารถนำเข้าได้ ไฟล์ซีเอสเอสจากแหล่งอื่นโดยไม่ต้องคำนึงถึงจำนวนคำขอเครือข่าย เนื่องจากสามารถรวมทั้งหมดเป็นไฟล์เดียวก่อนการคอมไพล์

ด้วยลักษณะที่ซ้อนกันของตัวประมวลผลล่วงหน้า CSS คุณจะได้รับโค้ดขนาดกะทัดรัดพร้อมผลลัพธ์เดียวกัน LESS และ SCSS ยึดหลักการ DRY ซึ่งย่อมาจาก "อย่าพูดซ้ำตัวเอง" หรือ "อย่าพูดซ้ำตัวเอง"

พรีโปรเซสเซอร์ เริ่มต้นอย่างรวดเร็ว

เกิดอะไรขึ้นกับ LESS?

เครือข่ายเต็มไปด้วยการอภิปรายว่าอันไหนดีกว่า: LESS หรือ SCSS ดังนั้นฉันจะไม่ครอบคลุมทั้งสองหัวข้อโดยละเอียด ฉันจะพูดถึงปัญหาเล็กๆ น้อยๆ ที่ฉันมีกับ LESS แทน

SCSS ใช้สัญลักษณ์ $ เพื่อกำหนดตัวแปร ในขณะที่ LESS ใช้สัญลักษณ์ @ เนื่องจาก CSS ยังใช้สัญลักษณ์ @ สำหรับคำสั่งสื่อ การนำเข้า และภาพเคลื่อนไหวของคีย์เฟรม สิ่งนี้อาจทำให้นักพัฒนาสับสนได้

สัญลักษณ์ $ ไม่ได้ใช้ใน CSS สัญลักษณ์ @ มีอยู่ใน SCSS แต่ใช้สำหรับคำสั่ง @if , @else , @each , @for และ @ While

แม้ว่าสถานการณ์นี้อาจไม่เกิดขึ้นจริงสำหรับทุกคน แต่ควรใช้ ID ที่แตกต่างกันเพื่อแยกองค์ประกอบออกจากกัน

SCSS รองรับแบบดั้งเดิม การแสดงออกทางตรรกะเช่น if/else บล็อกและลูป มิกซ์อินที่ได้รับการปกป้องใน LESS นั้นมองเห็นได้ง่ายกว่า แต่เข้าใจได้ยากกว่า

สามารถทำได้โดยใช้ LESS...

...หรือเพียงแค่ใช้ SCSS

LESS กำหนดมิกซ์อินที่ได้รับการปกป้องเพียงรายการเดียวเท่านั้น ดังนั้น คุณไม่สามารถส่งผ่านอาร์กิวเมนต์ที่สองและประมวลผลในมิกซ์อินเดียวกัน โดยทำซ้ำโค้ดสำหรับทุกคนได้ สถานการณ์ที่เป็นไปได้. ในความเป็นจริง LESS (น้อยกว่า) มีมากกว่า (ตั้งใจเล่นสำนวน)

ฉันรู้ว่าเป็นไปได้ที่จะย่อโค้ดให้สั้นลงโดยใช้ค่าเสริมเป็นชื่อคุณสมบัติสำหรับในกรณีนี้ แต่ปัญหาคือฉันไม่สามารถแมปสองส่วนที่ต่างกันของมิกซ์อินเดียวกันตามเงื่อนไขให้เป็น LESS ได้

มีเรื่องปวดหัวมากขึ้นกับรหัสนี้...

พรีโปรเซสเซอร์ เริ่มต้นอย่างรวดเร็ว

เรียนรู้พื้นฐานการทำงานด้วย โปรเซสเซอร์ล่วงหน้าน้อยลงและสัสด้วย เป็นศูนย์สมบูรณ์ในเวลาน้อยกว่า 2 สัปดาห์

...กว่าด้วยสิ่งนี้

เพื่อให้ได้ผลลัพธ์เดียวกันโดยใช้ LESS ฉันต้องกำหนดทุกอย่างล่วงหน้า เขียนมิกซ์อิน รับตำแหน่งดัชนี วนซ้ำด้วยตรรกะของฉันจนกว่าค่าดัชนีจะเป็น เท่ากับศูนย์และเรียกมิกซ์อินด้วยตนเอง

แม้ว่านี่จะเป็นความเห็นส่วนตัวของฉัน แต่โดยทั่วไปแล้ว SCSS จะจัดการค่าการคำนวณและค่าทางคณิตศาสตร์ได้ดีกว่า

มีอะไรผิดปกติกับมัน?

ในทางกลับกัน LESS นั้นซับซ้อนกว่ามาก เช่น เมื่อฉันใช้มัน ฉันไม่ได้พยายามคำนวณ แต่ถึงแม้ว่าผมจะทำ 100% ลบ 50px เท่ากับ 50% เมื่อใด?

น้อย เหตุใดคุณจึงละเลยค่าด้วยการเปลี่ยนหน่วย

ทำไมคุณถึงทำให้ฉันเรียนรู้ไม้ค้ำยันของคุณ ในเมื่อฉันรู้จัก CSS แล้ว?

และสิ่งสุดท้ายอย่างหนึ่ง ต้องขอบคุณโปรเจ็กต์ LibSass ที่ทำให้ SCSS มี Wrapper มากมายสำหรับภาษาอื่นๆ เช่น C, Go, PHP, Python, Dart เป็นต้น

เหตุใดเราจึงตัดสินใจละทิ้ง LESS เพื่อสนับสนุน SCSS

ในขณะที่เรากำลังพัฒนาการ์ด JotForm เราจำเป็นต้องประมวลผลค่าตัวแปรล่วงหน้า - การคอมไพล์ล่วงหน้าและการแคชฝั่งเซิร์ฟเวอร์ในเวลาเดียวกัน และทั้งหมดนี้จะต้องทำให้สมบูรณ์แบบ

เราต้องการให้ผู้ใช้สามารถปรับแต่งได้ รูปร่างแบบฟอร์ม เพื่อให้การเปลี่ยนแปลงใด ๆ ปรากฏและแคชบนเซิร์ฟเวอร์ทันทีและพร้อมกัน เพื่อประโยชน์ของผู้ใช้ของเรา เราไม่ต้องการรันเชลล์ไคลเอ็นต์แบบ LESS เนื่องจากจำเป็น พลังการคำนวณลูกค้า - และหลายสิ่งหลายอย่างอาจผิดพลาดได้

เราไม่ได้เริ่มวงจรการพัฒนาโดยมีเป้าหมายในการย้ายจาก LESS ไปสู่ ​​SCSS แต่ครึ่งทางของการจัดการกับปัญหาเล็กๆ น้อยๆ เหล่านี้ การไม่มีกระดาษห่อหุ้มที่ดีสำหรับ LESS ถือเป็นฟางเส้นสุดท้าย

อย่างไรก็ตามความแตกต่างระหว่าง LESS และ SCSS นั้นมีความสำคัญน้อยกว่าสิ่งที่เหมือนกัน ท้ายที่สุดแล้ว มันไม่สำคัญว่าคุณจะใช้พรีโปรเซสเซอร์ตัวไหน ตราบใดที่คุณใช้งานมัน

กำลังพยายามจัดการโครงการขนาดใหญ่ด้วยไฟล์ CSS ไฟล์เดียวและแบบดั้งเดิม โครงสร้างซีเอสเอสยากกว่าการใช้พรีโปรเซสเซอร์มากโดยมีปัญหาสองสามข้อ

อะไรคืองานหลักของพรีโปรเซสเซอร์และงานไหนให้เลือก: SASS หรือ LESS เราจะหารือในบทความนี้ ก่อนอื่นคุณต้องกำหนดพรีโปรเซสเซอร์ - มันคืออะไร? เป็นเครื่องมือหรือเครื่องมือที่แก้ไขโค้ดบางอย่างโดยการแปลงผ่านความสามารถต่างๆ อินพุตตัวประมวลผลคือโค้ดที่อธิบายโดยโครงสร้างวากยสัมพันธ์ต่างๆ การออกแบบเหล่านี้เข้าใจได้เฉพาะกับเครื่องดนตรีนี้เท่านั้น มันสามารถแทนที่โครงสร้างภาษาที่ซับซ้อนต่าง ๆ หรือเพิ่มอันใหม่ในทางตรงกันข้าม ผลลัพธ์จากโปรแกรมจะมีโค้ดมากกว่า คุณภาพต่ำด้วยโครงสร้างที่ถูกถอดออก

เพื่อให้เข้าใจคำว่าพรีโปรเซสเซอร์ได้ดีขึ้น ลองดูตัวอย่างกัน ข้อมูลเข้าของโปรแกรมนี้คือโค้ดที่ประกอบด้วยคำ ปัญหา เครื่องหมายลูกน้ำ และจุดต่างๆ หากมีฟังก์ชันทดแทน คำสำคัญในรูปแบบย่อนั่นคือในตัวย่อถึงชื่อเต็มผลลัพธ์ที่ได้จะเป็นประโยคที่มีสัญลักษณ์ขยาย นี่เป็นความเข้าใจเบื้องต้นที่สุดว่าพรีโปรเซสเซอร์คืออะไร โดยพื้นฐานแล้ว มันมีคำสั่งและความสามารถที่ซับซ้อนมากขึ้น

ดังนั้นโปรแกรมนี้จึงนำเสนอการออกแบบที่หลากหลายเพื่อความเรียบง่ายและรวดเร็วในการพัฒนาและการสนับสนุนสไตล์

โดยปกติรหัสจะมุ่งเป้าไปที่ลักษณะของมนุษย์:

ความสามารถในการอ่าน

โครงสร้าง.

ผลงาน.

นอกจากนี้ เมื่อพิจารณาถึงตัวประมวลผลล่วงหน้า โปรแกรมเมอร์ต้องเผชิญกับแนวคิดเรื่องน้ำตาลเชิงวากยสัมพันธ์ นี่คือส่วนเพิ่มเติมบางอย่างของภาษาการเขียนโปรแกรมที่ไม่ส่งผลต่อกำไรใดๆ คุณลักษณะเพิ่มเติมแต่ปรับปรุงความสามารถในการอ่าน

ประเภทหลัก

ตัวเลือกที่พบบ่อยที่สุดคือ LESS, SASS และ Stylus ตามที่กำหนดไว้ข้างต้น ข้อดีของการใช้เครื่องมือดังกล่าวคือการปรับปรุงเนื้อหาข้อความ โครงสร้าง และประสิทธิภาพการทำงาน อย่างไรก็ตาม มีนักพัฒนาเพียงไม่กี่รายที่ใช้โปรแกรมดังกล่าวในการทำงาน เนื่องจากพวกเขาเชื่อว่าการทำงานกับโปรแกรมเหล่านี้มีความซับซ้อนและฟังก์ชันหลายอย่างยังไม่ชัดเจน

โปรแกรมที่ได้รับความนิยมมากที่สุดในปัญหานี้ โปรแกรมนี้ได้รับการพัฒนาในปี 2009 โดยทีมงานโปรแกรมเมอร์ มีฟังก์ชั่นการใช้งานครบครัน ระดับพื้นฐาน. ข้อเสียเปรียบหลักคือการขาด โครงสร้างที่มีเงื่อนไขและรอบ ข้อได้เปรียบหลัก ของเครื่องดนตรีชิ้นนี้– มีความชัดเจนและใช้งานง่ายค่ะ ฟังก์ชั่นสามารถขยายได้ด้วยปลั๊กอินต่างๆ

สไตล์ชีตที่ยอดเยี่ยมทางวากยสัมพันธ์

SASS เป็นพรีโปรเซสเซอร์ที่ทรงพลังที่สุด ได้รับการพัฒนาโดยทีมโปรแกรมเมอร์ทั้งหมด ก่อตั้งขึ้นในปี 2550 เพื่อเป็นโมดูลสำหรับ HAML และยังเขียนด้วยภาษา Ruby (มีพอร์ต C++) นอกจากนี้ยังมีฟีเจอร์ที่หลากหลายกว่าเมื่อเปรียบเทียบกับโปรแกรมอื่นๆ หากต้องการขยายขีดความสามารถของ Syntacically Awesome Style Sheets คุณสามารถใช้ไลบรารี Compass อันทรงพลังได้ โปรแกรม SASS มีสองตัวเลือกไวยากรณ์: Sass และ SCSS

นี่คือเครื่องดนตรีที่อายุน้อยที่สุดและมีแนวโน้มมากที่สุด ก่อตั้งขึ้นในปี พ.ศ. 2553 พรีโปรเซสเซอร์ของสไตลัสเป็นพรีโปรเซสเซอร์ที่สะดวกและขยายได้มากที่สุด

โดยปกติแล้วโปรแกรมเมอร์จะทำงานกับ LESS อยู่แล้ว ไฟล์ใดๆ ถือเป็นไฟล์ LESS ที่ถูกต้อง ในกรณีนี้ไม่จำเป็นต้องมีนามสกุลไฟล์ เมื่อใช้โค้ด CSS ปกติ ให้ใส่ไว้ในไฟล์ชื่อเดียวกัน แต่มีนามสกุล .less ในความเป็นจริง ได้รับไฟล์ที่เหมือนกันโดยไม่มีข้อผิดพลาดและมีเนื้อหาตรงกันทุกประการ ข้อแตกต่างระหว่างไฟล์เพียงอย่างเดียวคือความพร้อมใช้งาน เส้นว่างหลังจากตัวเลือก ดังนั้นเมื่อใช้เครื่องมือนี้ เวลาในการรวบรวมจึงน้อยกว่ามาก ดังนั้นการกระทำ เครื่องมือนี้มุ่งเป้าไปที่เป้าหมายเฉพาะสร้างโครงสร้างที่สะดวก ซึ่งสามารถทำได้ด้วย CSS ทั่วไป แต่จะสะดวกน้อยลง

ปัจจัยหลักในการเลือก

ตาม ลักษณะการทำงาน Sass ดีกว่าโปรแกรมอื่นอย่างแน่นอนในหลาย ๆ ด้าน แต่ถ้างานเสร็จแล้วโดยใช้ Less ก็ไม่มีประโยชน์ที่จะเปลี่ยน ตามที่กล่าวไว้ข้างต้น SASS อนุญาตให้คุณใช้ Compass ซึ่งทำให้การทำงานกับคำนำหน้าง่ายขึ้น โปรแกรมอื่นๆ ไม่มีโครงการ Compass เนื่องจากภาษาของเครื่องมือค่อนข้างซับซ้อน SASS มีบูลีนและ ตัวดำเนินการแบบวนรอบ. เว็บไซต์ LESS มีความสวยงามและใช้งานง่ายเมื่อเทียบกับเว็บไซต์อื่นๆ

เมื่อทำงานกับกฎ @media โปรแกรมเมอร์จะเพิ่มบล็อกที่ด้านล่างของหน้าสไตล์ สิ่งนี้นำไปสู่การตัดการเชื่อมต่อในรูปแบบ Less และ Sass ต่างก็เป็นเครื่องมือที่ช่วยแก้ปัญหานี้ และโดยทั่วไปแล้วคณิตศาสตร์ที่อยู่เบื้องหลังสิ่งเหล่านั้นก็คล้ายกัน ในแง่ของความเร็ว พรีโปรเซสเซอร์ทั้งสองตัวมีประสิทธิภาพที่ดี

ผู้พัฒนาทั้งสองตัวเลือกยังคงปรับปรุงต่อไป

ตามรีวิวและความคิดเห็นจากโปรแกรมเมอร์ เครื่องมือทั้งสองสามารถใช้งานได้อย่างเท่าเทียมกัน สไตล์ชีตที่ยอดเยี่ยมทางวากยสัมพันธ์ตามแหล่งข้อมูลบางแห่งมีมากกว่านั้น ความเร็วต่ำเมื่อเทียบกับคนอื่นๆ บางคนคิดว่า Stylus เหนือกว่าโปรเซสเซอร์ทั้งสองในปัจจุบัน

ดังนั้นจึงไม่มีวิธีแก้ปัญหาที่แน่นอนสำหรับคำถามในการใช้ Less และ Sass เนื่องจากทั้งสองอย่างนี้มีคุณสมบัติและฟังก์ชันการทำงานที่ดี ดังนั้นทางเลือกจึงถูกกำหนดโดยเป้าหมายและวัตถุประสงค์ของโปรแกรมเมอร์

“และมีคำถามเชิงตรรกะอย่างสมบูรณ์: “SASS และ SCSS แตกต่างกันอย่างไร” หัวข้อนี้น่าสนใจเรามาดูกันดีกว่า

เมื่อไร เรากำลังพูดถึงเมื่อเราพูดถึง Sass โดยทั่วไปเราหมายถึงผู้ประมวลผลล่วงหน้าและภาษาโดยทั่วไป

อย่างไรก็ตาม การใช้ Sass (ตัวประมวลผลล่วงหน้า) เราสามารถใช้ไวยากรณ์ที่แตกต่างกันสองแบบ:

• Sass(เยื้อง) ;
• SCSS (ไวยากรณ์เหมือน CSS)

ประวัติเล็กน้อย

เดิม Sass เป็นส่วนหนึ่งของตัวประมวลผลล่วงหน้าอีกตัวหนึ่งคือ Haml ซึ่งคิดค้นและเขียนโดยนักพัฒนา Ruby

ดังนั้นสไตล์ Sass จึงใช้ไวยากรณ์เหมือน Ruby ไม่มีวงเล็บ ไม่มีอัฒภาค และไม่มีการเยื้องที่เข้มงวด เช่นนี้

// ตัวแปร!primary -color= hotpink // Primary =border-radius(!radius) -webkit-border-radius= !radius -moz-border-radius= !radius border-radius= !radius .my-element color= !primary -color width= 100% overflow= ซ่อน .my-other-element +border-radius(5 px)

เมื่อเทียบกับ ไวยากรณ์ซีเอสเอสมีความแตกต่างที่เห็นได้ชัดเจน

ตัวแปรถูกระบุผ่าน ! ไม่ใช่ $ สัญลักษณ์การมอบหมายค่า = ไม่ใช่ :

แต่นี่คือลักษณะที่ Sass มองก่อนเวอร์ชัน 3.0 ซึ่งเปิดตัวในเดือนพฤษภาคม 2010 ซึ่งเปิดตัวโดยสมบูรณ์ ไวยากรณ์ใหม่เรียกว่า SCSS หรือ Sassy CSS

เป้าหมายของเขาคือการทำให้ไวยากรณ์ Sass ใกล้ชิดกับ CSS มากขึ้น ทำให้เข้ากันได้กับ CSS มากขึ้น:

// ตัวแปร $primary -color: hotpink; // Mixin @mixin border-radius($radius ) ( -webkit-border-radius: $radius ; -moz-border-radius: $radius ; border-radius: $radius ; ) .my-element ( สี: $primary -สี; ความกว้าง: 100%; ล้น: ซ่อนอยู่; ) .my-other-element ( @include border-radius(5 px); )

SCSS นั้นใกล้เคียงกับ CSS มากกว่า Sass อย่างแน่นอน นักพัฒนา Sass ทำงานอย่างหนักเพื่อทำให้ไวยากรณ์ทั้งสองอยู่ใกล้กันมากขึ้นโดยการแทนที่ ! (เครื่องหมายตัวแปร) และ = (เครื่องหมายกำหนด) บน $ และ: จาก CSS

ดังนั้นเมื่อเริ่มโปรเจ็กต์ใหม่ คุณอาจสงสัยว่าจะใช้ไวยากรณ์อะไร ให้ฉันช่วยคุณตัดสินใจ

ข้อดีของไวยากรณ์เยื้อง Sass

แม้ว่าไวยากรณ์นี้อาจดูแปลกเล็กน้อยสำหรับคุณ แต่ก็มีหลายรูปแบบ ช่วงเวลาที่น่าสนใจ. ประการแรกจะสั้นกว่าและพิมพ์ง่ายกว่า ไม่มีวงเล็บหรืออัฒภาค แต่ไม่จำเป็น

ไม่จำเป็นต้องใช้ @mixin หรือ @include เมื่อเพียงพอแล้ว สัญลักษณ์ง่ายๆ: = และ +

Sass ยังมีมาตรฐานการเข้ารหัสที่สะอาดเนื่องจากการใช้การเยื้อง เนื่องจากการเยื้องที่ไม่ถูกต้องอาจทำให้สไตล์ชีต .sass ทั้งหมดเสียหายได้ ขั้นตอนแรกที่นี่คือการตรวจสอบให้แน่ใจว่าโค้ดนั้นสะอาดและมีรูปแบบที่ถูกต้อง

มีวิธีเดียวเท่านั้นที่จะเขียนโค้ด Sass: เขียนให้ถูกต้อง

อย่าลืมว่าการเยื้องมีค่าบูลีนใน Sass เมื่อมีการใช้การเยื้องบล็อกตัวเลือก หมายความว่าเป็นตัวเลือกที่ซ้อนกัน

ตัวอย่างเช่น:

.element-a color: hotpink .element-b float: left ... ส่งออกโค้ด CSS ต่อไปนี้: .element-a ( color : hotpink ; ) .element-a .element-b ( float : left ; )

ข้อเท็จจริงง่ายๆ ของการเลื่อน .element-b ไปทางขวาหนึ่งระดับหมายความว่าเป็นเช่นนั้น องค์ประกอบลูกจาก .element-a ซึ่งเปลี่ยนโค้ด CSS ที่เป็นผลลัพธ์ ดังนั้นควรระวังการเยื้อง!

ฉันเชื่อว่าไวยากรณ์ที่ใช้การเยื้องจะดึงดูดทีมที่ทำงานกับ Ruby/Python เป็นหลักมากกว่าทีมโปรแกรมเมอร์ PHP/Java (แต่ก็ไม่แน่นอน)

ข้อดีของไวยากรณ์ SCSS

ประการแรกมันเข้ากันได้กับ CSS โดยสมบูรณ์ ซึ่งหมายความว่าคุณสามารถเปลี่ยนชื่อไฟล์ CSS เป็น .scss ได้ และมันจะทำงานเหมือนกับไม่มีอะไรเกิดขึ้น

การทำให้ SCSS เข้ากันได้กับ CSS อย่างสมบูรณ์ถือเป็นสิ่งสำคัญสำหรับการสนับสนุน Sass มาโดยตลอดนับตั้งแต่เปิดตัว SCSS และในความคิดของฉันนี่เป็นจุดแข็ง

พวกเขายังพยายามจับตาดูสิ่งที่อาจกลายเป็นไวยากรณ์ CSS ที่ถูกต้องในอนาคตและนำไปใช้ (ด้วยเหตุนี้ @directives )

เนื่องจาก SCSS เข้ากันได้กับ CSS จึงแทบไม่ต้องมีการฝึกอบรมเพิ่มเติม ไวยากรณ์ค่อนข้างจะเหมือนกัน ท้ายที่สุดแล้ว มันเป็นเพียง CSS ที่มีความพิเศษบางอย่าง

นี่เป็นสิ่งสำคัญสำหรับนักพัฒนาใหม่ เพื่อให้พวกเขาสามารถเริ่มเขียนโค้ดได้อย่างรวดเร็วโดยไม่ต้องมีความรู้เกี่ยวกับ Sass มากนัก

นอกจากนี้ยังสามารถอ่านได้มากขึ้นเนื่องจากโครงสร้างเฉพาะนั้นสมเหตุสมผลแล้ว เมื่อคุณเห็น @mixin คุณจะรู้ว่ามันเป็นการประกาศมิกซ์อิน เมื่อคุณเห็น @include คุณจะรู้ว่ามันเป็นการโทรแบบมิกซ์อิน

ไม่มีเงื่อนไขผูกมัดและทุกสิ่งก็สมเหตุสมผลโดยไม่ต้องตีความ

นอกจากนี้ เครื่องมือ ปลั๊กอิน และการสาธิตที่มีอยู่เกือบทั้งหมดสำหรับ Sass ยังได้รับการพัฒนาโดยใช้ไวยากรณ์ SCSS ไวยากรณ์นี้มุ่งเน้นไปที่มืออาชีพมากขึ้นเรื่อยๆ และจะถูกเลือกโดยพวกเขาตามค่าเริ่มต้น (หากไม่ใช่เพียงตัวเลือกเดียวที่เป็นไปได้)

สาเหตุหลักมาจากเหตุผลที่กล่าวข้างต้น ตัวอย่างเช่น การค้นหาการเน้นสำหรับไวยากรณ์ที่เยื้อง Sass ล้วนๆ กลายเป็นเรื่องยากมากขึ้น โดยทั่วไปแล้วจะมีตัวเลือกแบ็คไลท์ SCSS เท่านั้น

บทสรุป

อย่างไรก็ตาม ตัวเลือกนั้นเป็นของคุณ แต่ถ้าคุณไม่มีเหตุผลที่น่าสนใจจริงๆ ในการใช้ไวยากรณ์ที่มีการเยื้อง ฉันขอแนะนำอย่างยิ่งให้ใช้ SCSS บน Sass ไม่เพียงแต่ง่ายกว่า แต่ยังสะดวกกว่าอีกด้วย หากคุณเป็นมือใหม่ SCSS คือสิ่งที่คุณต้องการ ความคล้ายคลึงกับ CSS จะไม่ทำให้คุณกลัวจากการเรียนรู้เลย์เอาต์โดยใช้ตัวประมวลผลล่วงหน้า แต่คุณสามารถพิจารณาใช้ Sass ในโครงการของคุณได้ สิ่งสำคัญคืออย่ากลัวที่จะใช้เทคโนโลยีใหม่ในการทำงานของคุณ!

ป.ล. โปรดทราบว่า Sass ไม่เคยมีคำย่อจาก ตัวพิมพ์ใหญ่ไม่ว่าจะเป็นไวยากรณ์หรือภาษาโปรแกรมก็ตาม ในขณะที่ SCSS จะแสดงด้วยตัวพิมพ์ใหญ่เสมอ

ฉันชอบไวยากรณ์ SASS มากกว่า SCSS ในเรื่องความกะทัดรัด แต่การซ้อนสไตล์จำนวนมากใน SASS สามารถขจัดข้อดีของความสั้นได้อย่างรวดเร็ว ไม่ว่าในกรณีใด ความแตกต่างระหว่าง SASS และ SCSS ก็ไม่ใช่พื้นฐาน LESS กลายเป็นว่าใกล้ชิดกับ SCSS มากกว่า SASS และโดยทั่วไปมันก็เป็นสิ่งเดียวกัน มีความแตกต่างไม่มาก แต่มีสองสามข้อที่เปลี่ยนสมดุลแห่งอำนาจโดยพื้นฐาน

1. LESS - ฝั่งไคลเอ็นต์สามารถใช้ JS ได้

เจาะจงกว่านั้นไม่ใช่ว่าเขาทำได้ แต่เขาออกแบบมาเพื่อสิ่งนี้ แนวทางปฏิบัติทั่วไปสำหรับการใช้โค้ด LESS:

ตอนนั้นเองที่มีการเพิ่มความสามารถในการคอมไพล์บนเซิร์ฟเวอร์ (ทั้ง js และ ruby) เข้าไป

เมื่อมองแวบแรกดูเหมือนเป็นทรัพย์สินที่แปลก เหตุใดจึงต้องคอมไพล์บนฝั่งไคลเอ็นต์หากคุณสามารถคอมไพล์บนเซิร์ฟเวอร์ได้อย่างสมบูรณ์แบบและให้บริการ CSS บีบอัดสำเร็จรูปแบบที่เราคุ้นเคยกับ SASS

เหตุผลชัดเจนหลังจากศึกษาบรรทัดสุดท้ายของเอกสาร LESS ที่ไม่มีคำอธิบาย:

@ความสูง: `document.body.clientHeight`;

เส้นเล็กๆ โดดเดี่ยวเช่นนี้มอบโอกาสที่นักออกแบบเลย์เอาต์ใฝ่ฝันมาตั้งแต่เริ่มต้นการเรียนรู้สไตล์ต่างๆ การเรียกสคริปต์ Java ฝั่งไคลเอ็นต์จาก CSS และคำนึงถึงการตั้งค่าเบราว์เซอร์จริงเมื่อสร้างสไตล์

นั่นคือตอนนี้เรามีโอกาสที่จะโหลด DOM ก่อนแล้วจึงสร้างมันขึ้นมา CSS ที่กำหนดเองตรงฝั่งไคลเอ็นต์ จากนั้นลองคิดด้วยตัวเองว่าสิ่งนี้จะเปิดโอกาสให้อะไรได้บ้าง

ไม่ว่าโครงการของคุณต้องการสิ่งนี้หรือไม่นั้นเป็นคำถามที่แตกต่างออกไป เป็นที่ชัดเจนว่าทุกคนคุ้นเคยกับความไม่แน่นอน/ความเป็นอิสระของลูกค้า และการจัดวางในรูปแบบ "เราทำในระดับสากล เพื่อให้ทุกคนเห็นไม่มากก็น้อยในทุกความละเอียด" แต่นี่ไม่ใช่เหตุผลที่จะลืมว่าขณะนี้มีโอกาสเช่นนี้และด้วยเหตุนี้คุณจึงสามารถทำได้เช่นเค้าโครงที่ยืดหยุ่นมาก

2. LESS ไม่เหมือน SASS/SCSS ตรงที่ไม่มีตรรกะ

ไม่มี if/then, for ฯลฯ ใน LESS แม้ว่าเมื่อพิจารณาว่า JS นั้นถูกสร้างไว้อย่างง่ายดาย แต่ฉันคิดว่ามันค่อนข้างเป็นไปได้ที่จะผิดพลาดในตรรกะ ฉันไม่ได้ลองมัน

3. การผสมง่ายกว่าใน LESS + คุณสามารถผสมคลาสได้

ฉันชอบความจริงที่ว่าใน LESS คุณสามารถรวมคุณสมบัติของคลาสอื่น ๆ ไว้ในคำจำกัดความได้ ตัวคลาสเองนั้นเป็นมิกซ์อิน นี่เป็นอีกคุณสมบัติหนึ่งที่ SASS/SCSS ไม่มี คุณสามารถรวมไฟล์ CSS ปกติเป็น LESS และใช้คลาสของไฟล์นั้นเพื่อกำหนดคุณสมบัติของคุณได้ ตัวอย่างเช่น:

ห่อ (
การตัดข้อความ: ห่อ;
พื้นที่สีขาว: ก่อนห่อ;
พื้นที่สีขาว: -moz-pre-wrap;
การตัดคำ: แบ่งคำ;
}
ก่อน ( .wrap )

สรุป

ยกเว้นจุดที่ 1 ความแตกต่างนั้นไม่มากนักและตัวเลือกก็ยิ่งใหญ่กว่าสำหรับมือสมัครเล่น

สำหรับฉันโดยส่วนตัวแล้ว LESS ดูน่าดึงดูดยิ่งขึ้นเพราะความเรียบง่าย ฉันไม่เคยต้องการวงจรและเงื่อนไขในรูปแบบมาก่อน ยูทิลิตี้คลาสสิกเช่น "box-shadow, linear-gradient, darken" มีให้ใช้ในราคา LESS

ใช่ ห้องสมุดสำเร็จรูปหลายแห่งได้ถูกเขียนขึ้นสำหรับ SASS แล้ว (