ປະມານ 15 ປີກ່ອນ, ຂ້ອຍເຮັດວຽກຢູ່ບໍລິສັດທີ່ພວກເຮົາສ້າງແອັບຯສໍາລັບຕົວແທນການທ່ອງທ່ຽວ, ພະນັກງານໃນສະຫນາມບິນ, ແລະບໍລິສັດສາຍການບິນ. ພວກເຮົາຍັງສ້າງກອບໃນຕົວຂອງພວກເຮົາສໍາລັບອົງປະກອບ UI ແລະຄວາມສາມາດຂອງແອັບຯຫນ້າດຽວ. ພວກເຮົາມີອົງປະກອບສໍາລັບທຸກສິ່ງທຸກຢ່າງ: ຊ່ອງຂໍ້ມູນ, ປຸ່ມ, ແຖບ, ລະດັບ, ຕາຕະລາງຂໍ້ມູນ, ເມນູ, datepickers, ເລືອກ, ແລະຫຼາຍເລືອກ. ພວກເຮົາຍັງມີສ່ວນປະກອບ div. ອົງປະກອບ div ຂອງພວກເຮົາແມ່ນດີຫຼາຍ, ມັນໄດ້ອະນຸຍາດໃຫ້ພວກເຮົາເຮັດມຸມມົນໃນທຸກຕົວທ່ອງເວັບ, ເຊິ່ງ, ເຊື່ອຫຼືບໍ່, ບໍ່ແມ່ນເລື່ອງງ່າຍທີ່ຈະເຮັດໃນເວລານັ້ນ.
ວຽກງານຂອງພວກເຮົາໄດ້ເກີດຂື້ນໃນຈຸດໃດຫນຶ່ງໃນປະຫວັດສາດຂອງພວກເຮົາເມື່ອ JS, Ajax, ແລະ HTML ແບບເຄື່ອນໄຫວໄດ້ຖືກເຫັນວ່າເປັນການປະຕິວັດທີ່ນໍາພວກເຮົາໄປສູ່ອະນາຄົດ. ທັນທີທັນໃດ, ພວກເຮົາສາມາດປັບປຸງຫນ້າແບບເຄື່ອນໄຫວ, ເອົາຂໍ້ມູນຈາກເຄື່ອງແມ່ຂ່າຍ, ແລະຫຼີກເວັ້ນການໄປຫາຫນ້າອື່ນໆ, ເຊິ່ງເຫັນວ່າຊ້າແລະກະພິບຮູບສີ່ຫລ່ຽມສີຂາວໃຫຍ່ໃນຫນ້າຈໍລະຫວ່າງສອງຫນ້າ. ມີປະໂຫຍກຫນຶ່ງ, ໄດ້ຮັບຄວາມນິຍົມໂດຍ Jeff Atwood (ຜູ້ກໍ່ຕັ້ງ StackOverflow), ເຊິ່ງອ່ານວ່າ: "ແອັບພລິເຄຊັນໃດນຶ່ງທີ່ສາມາດຂຽນໄດ້ໃນ JavaScript ໃນທີ່ສຸດກໍຈະຂຽນເປັນ JavaScript."— Jeff Atwood
ສຳລັບພວກເຮົາໃນເວລານັ້ນ, ມັນຮູ້ສຶກຄືກັບວ່າກ້າທີ່ຈະໄປສ້າງແອັບເຫຼົ່ານັ້ນແທ້ໆ. ມັນຮູ້ສຶກຄືກັບການອະນຸມັດຜ້າຫົ່ມທີ່ຈະເຮັດທຸກຢ່າງກັບ JS. ດັ່ງນັ້ນພວກເຮົາໄດ້ເຮັດທຸກຢ່າງກັບ JS, ແລະພວກເຮົາບໍ່ໄດ້ໃຊ້ເວລາແທ້ໆເພື່ອຄົ້ນຄ້ວາວິທີການເຮັດສິ່ງອື່ນໆ. ພວກເຮົາບໍ່ຮູ້ສຶກວ່າມີແຮງຈູງໃຈທີ່ຈະຮຽນຮູ້ສິ່ງທີ່ HTML ແລະ CSS ສາມາດເຮັດໄດ້ຢ່າງຖືກຕ້ອງ. ພວກເຮົາບໍ່ໄດ້ຮັບຮູ້ວ່າເວັບເປັນເວທີການພັດທະນາ app ທັງຫມົດຂອງຕົນ. ພວກເຮົາສ່ວນຫຼາຍເຫັນວ່າມັນເປັນສິ່ງທີ່ພວກເຮົາຕ້ອງການເພື່ອເຮັດວຽກ, ໂດຍສະເພາະໃນເວລາທີ່ມັນມາກັບການສະຫນັບສະຫນູນຂອງຕົວທ່ອງເວັບ. ພວກເຮົາພຽງແຕ່ສາມາດຖິ້ມ JS ຫຼາຍກວ່ານັ້ນເພື່ອເຮັດສິ່ງຕ່າງໆໃຫ້ສໍາເລັດ. ຈະໃຊ້ເວລາເພື່ອຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບວິທີທີ່ເວັບເຮັດວຽກແລະສິ່ງທີ່ມີຢູ່ໃນເວທີໄດ້ຊ່ວຍຂ້ອຍບໍ? ແນ່ນອນ, ຂ້ອຍອາດຈະໄດ້ໂກນລະຫັດທີ່ບໍ່ຈໍາເປັນແທ້ໆ. ແຕ່, ໃນເວລານັ້ນ, ອາດຈະບໍ່ຫຼາຍ. ທ່ານເຫັນ, ຄວາມແຕກຕ່າງຂອງຕົວທ່ອງເວັບແມ່ນມີຄວາມສໍາຄັນຫຼາຍໃນເມື່ອກ່ອນ. ນີ້ແມ່ນເວລາທີ່ Internet Explorer ຍັງເປັນຕົວທ່ອງເວັບທີ່ໂດດເດັ່ນ, ໂດຍ Firefox ເປັນອັນດັບສອງທີ່ໃກ້ຊິດ, ແຕ່ເລີ່ມສູນເສຍສ່ວນແບ່ງຕະຫຼາດຍ້ອນ Chrome ໄດ້ຮັບຄວາມນິຍົມຢ່າງໄວວາ. ເຖິງແມ່ນວ່າ Chrome ແລະ Firefox ແມ່ນຂ້ອນຂ້າງດີທີ່ຈະຕົກລົງກັບມາດຕະຖານເວັບ, ສະພາບແວດລ້ອມທີ່ແອັບຯຂອງພວກເຮົາກໍາລັງເຮັດວຽກຫມາຍຄວາມວ່າພວກເຮົາຕ້ອງສະຫນັບສະຫນູນ IE6 ເປັນເວລາດົນນານ. ເຖິງແມ່ນວ່າໃນເວລາທີ່ພວກເຮົາໄດ້ຮັບການອະນຸຍາດໃຫ້ສະຫນັບສະຫນູນ IE8, ພວກເຮົາຍັງຕ້ອງຈັດການກັບຄວາມແຕກຕ່າງຫຼາຍລະຫວ່າງຕົວທ່ອງເວັບ. ບໍ່ພຽງແຕ່ເທົ່ານັ້ນ, ແຕ່ເວັບໄຊຕ໌ຂອງເວລາພຽງແຕ່ບໍ່ມີຄວາມສາມາດຫຼາຍທີ່ສ້າງຂຶ້ນໃນເວທີ.
ໄວຕໍ່ໄປໃນມື້ນີ້. ສິ່ງຕ່າງໆໄດ້ປ່ຽນແປງຢ່າງຫຼວງຫຼາຍ. ບໍ່ພຽງແຕ່ພວກເຮົາມີຄວາມສາມາດເຫຼົ່ານີ້ຫຼາຍກວ່າທີ່ເຄີຍມີມາກ່ອນ, ແຕ່ອັດຕາທີ່ພວກເຂົາສາມາດໃຊ້ໄດ້ກໍ່ເພີ່ມຂຶ້ນເຊັ່ນກັນ. ໃຫ້ຂ້ອຍຖາມຄໍາຖາມອີກເທື່ອຫນຶ່ງ, ຫຼັງຈາກນັ້ນ: ຈະໃຊ້ເວລາເພື່ອຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບວິທີການເຮັດວຽກຂອງເວັບແລະສິ່ງທີ່ມີຢູ່ໃນເວທີຊ່ວຍເຈົ້າໃນມື້ນີ້ບໍ? ແມ່ນແທ້ໆ. ການຮຽນຮູ້ທີ່ຈະເຂົ້າໃຈແລະນໍາໃຊ້ແພລະຕະຟອມເວັບໃນມື້ນີ້ເຮັດໃຫ້ທ່ານມີປະໂຫຍດອັນໃຫຍ່ຫຼວງກວ່າຜູ້ພັດທະນາອື່ນໆ. ບໍ່ວ່າທ່ານຈະເຮັດວຽກກ່ຽວກັບການປະຕິບັດ, ການເຂົ້າຫາ, ການຕອບສະຫນອງ, ທັງຫມົດຮ່ວມກັນ, ຫຼືພຽງແຕ່ການຈັດສົ່ງຄຸນສົມບັດ UI, ຖ້າທ່ານຕ້ອງການເຮັດມັນເປັນວິສະວະກອນທີ່ມີຄວາມຮັບຜິດຊອບ, ການຮູ້ເຄື່ອງມືທີ່ມີໃຫ້ທ່ານຈະຊ່ວຍໃຫ້ທ່ານບັນລຸເປົ້າຫມາຍຂອງທ່ານໄດ້ໄວຂຶ້ນແລະດີກວ່າ. ບາງສິ່ງທີ່ເຈົ້າອາດຈະບໍ່ຕ້ອງການຫ້ອງສະໝຸດອີກຕໍ່ໄປ ຮູ້ສິ່ງທີ່ຕົວທ່ອງເວັບສະຫນັບສະຫນູນໃນມື້ນີ້, ຄໍາຖາມ, ຫຼັງຈາກນັ້ນ, ແມ່ນ: ສິ່ງທີ່ພວກເຮົາສາມາດ ditch? ພວກເຮົາຕ້ອງການອົງປະກອບ div ເພື່ອເຮັດມຸມມົນໃນປີ 2025 ບໍ? ແນ່ນອນ, ພວກເຮົາບໍ່. ຄຸນສົມບັດຊາຍແດນ-ລັດສະໝີໄດ້ຮັບການສະໜັບສະໜຸນໂດຍທຸກຕົວທ່ອງເວັບທີ່ໃຊ້ໃນປັດຈຸບັນເປັນເວລາຫຼາຍກວ່າ 15 ປີໃນຈຸດນີ້. ແລະຮູບຮ່າງຂອງມຸມແມ່ນຍັງຈະມາໃນໄວໆນີ້, ສໍາລັບມຸມ fancier ເຖິງແມ່ນວ່າ. ໃຫ້ພິຈາລະນາລັກສະນະທີ່ຜ່ານມາຂ້ອນຂ້າງທີ່ປະຈຸບັນມີຢູ່ໃນທຸກຕົວທ່ອງເວັບທີ່ສໍາຄັນ, ແລະທີ່ທ່ານສາມາດນໍາໃຊ້ເພື່ອທົດແທນການຂຶ້ນກັບທີ່ມີຢູ່ໃນ codebase ຂອງທ່ານ. ຈຸດທີ່ບໍ່ແມ່ນເພື່ອປະຖິ້ມຫ້ອງສະຫມຸດທີ່ຮັກຂອງທ່ານທັງຫມົດໃນທັນທີແລະ rewrite codebase ຂອງທ່ານ. ສຳ ລັບສິ່ງອື່ນ, ທ່ານ ຈຳ ເປັນຕ້ອງພິຈາລະນາການສະ ໜັບ ສະ ໜູນ ຂອງ browser ກ່ອນແລະຕັດສິນໃຈໂດຍອີງໃສ່ປັດໃຈອື່ນໆສະເພາະກັບໂຄງການຂອງທ່ານ. ລັກສະນະຕໍ່ໄປນີ້ຖືກປະຕິບັດຢູ່ໃນສາມເຄື່ອງຈັກຂອງຕົວທ່ອງເວັບຕົ້ນຕໍ (Chromium, WebKit, ແລະ Gecko), ແຕ່ທ່ານອາດຈະມີຄວາມຕ້ອງການສະຫນັບສະຫນູນຕົວທ່ອງເວັບທີ່ແຕກຕ່າງກັນທີ່ປ້ອງກັນບໍ່ໃຫ້ທ່ານໃຊ້ພວກມັນທັນທີ. ໃນປັດຈຸບັນຍັງເປັນເວລາທີ່ດີທີ່ຈະຮຽນຮູ້ກ່ຽວກັບລັກສະນະເຫຼົ່ານີ້, ເຖິງແມ່ນວ່າ, ແລະບາງທີອາດວາງແຜນທີ່ຈະໃຊ້ພວກມັນໃນບາງຈຸດ. Popovers ແລະ Dialogs Popover API, ອົງປະກອບ
ແນ່ນອນ, ຄວາມໄວການເຊື່ອມຕໍ່ອິນເຕີເນັດຂອງເຈົ້າອາດຈະເພີ່ມຂຶ້ນເຊັ່ນດຽວກັນ, ແຕ່ນັ້ນບໍ່ແມ່ນກໍລະນີສໍາລັບທຸກຄົນ. ແລະບໍ່ແມ່ນທຸກຄົນມີຄວາມສາມາດອຸປະກອນດຽວກັນ. ການດຶງລະຫັດຂອງພາກສ່ວນທີສາມສໍາລັບສິ່ງທີ່ທ່ານສາມາດເຮັດໄດ້ກັບເວທີ, ແທນທີ່ຈະ, ສ່ວນຫຼາຍອາດຈະຫມາຍຄວາມວ່າທ່ານສົ່ງລະຫັດຫຼາຍ, ແລະດັ່ງນັ້ນຈຶ່ງເຂົ້າເຖິງລູກຄ້າຫນ້ອຍກວ່າປົກກະຕິ. ໃນເວັບ, ການປະຕິບັດການໂຫຼດທີ່ບໍ່ດີເຮັດໃຫ້ອັດຕາການປະຖິ້ມຂະຫນາດໃຫຍ່ແລະເຮັດໃຫ້ຊື່ສຽງຂອງຍີ່ຫໍ້ເຈັບປວດ. ແລ່ນລະຫັດໜ້ອຍລົງໃນອຸປະກອນ ຍິ່ງໄປກວ່ານັ້ນ, ລະຫັດທີ່ທ່ານສົ່ງໃນອຸປະກອນຂອງລູກຄ້າຂອງທ່ານອາດຈະແລ່ນໄວຂຶ້ນຖ້າມັນໃຊ້ JavaScript abstractions ຫນ້ອຍລົງຢູ່ເທິງເວທີ. ມັນຍັງອາດຈະຕອບສະໜອງໄດ້ຫຼາຍກວ່າ ແລະສາມາດເຂົ້າເຖິງໄດ້ຫຼາຍຂຶ້ນໂດຍຄ່າເລີ່ມຕົ້ນ. ທັງຫມົດນີ້ເຮັດໃຫ້ລູກຄ້າຫຼາຍແລະມີຄວາມສຸກ. ກວດເບິ່ງ blog ຊ່ອງຫວ່າງທີ່ບໍ່ສະເຫມີພາບການປະຕິບັດປະຈໍາປີຂອງເພື່ອນຮ່ວມງານຂອງຂ້ອຍ Alex Russell, ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າອຸປະກອນທີ່ນິຍົມສ່ວນໃຫຍ່ແມ່ນບໍ່ມີຢູ່ໃນຕະຫຼາດທີ່ມີຜູ້ໃຊ້ຫຼາຍຕື້ຄົນເນື່ອງຈາກຄວາມບໍ່ສະເຫມີພາບດ້ານຄວາມຮັ່ງມີ. ແລະຊ່ອງຫວ່າງນີ້ພຽງແຕ່ຂະຫຍາຍຕົວໃນໄລຍະເວລາ.
ໂຄງຮ່າງການກໍ່ສ້າງໃນ Masonry ຄຸນນະສົມບັດເວທີເວັບໄຊຕ໌ຫນຶ່ງທີ່ຈະມາເຖິງໃນໄວໆນີ້ແລະທີ່ຂ້ອຍຕື່ນເຕັ້ນຫຼາຍແມ່ນ CSS Masonry.
ໃຫ້ຂ້ອຍເລີ່ມຕົ້ນໂດຍການອະທິບາຍວ່າ Masonry ແມ່ນຫຍັງ. Masonry ແມ່ນຫຍັງ Masonry ແມ່ນປະເພດຂອງການຈັດວາງທີ່ເປັນທີ່ນິຍົມໂດຍ Pinterest ເມື່ອປີກ່ອນ. ມັນສ້າງການຕິດຕາມເນື້ອຫາທີ່ເປັນເອກະລາດພາຍໃນລາຍການທີ່ບັນຈຸຕົວເອງຢູ່ໃກ້ກັບການເລີ່ມຕົ້ນຂອງການຕິດຕາມເທົ່າທີ່ເຂົາເຈົ້າສາມາດເຮັດໄດ້.
ຫຼາຍຄົນເຫັນວ່າ Masonry ເປັນທາງເລືອກທີ່ດີສໍາລັບຫຼັກຊັບແລະຄັງຮູບພາບ, ເຊິ່ງແນ່ນອນວ່າມັນສາມາດເຮັດໄດ້. ແຕ່ Masonry ແມ່ນມີຄວາມຍືດຫຍຸ່ນຫຼາຍກ່ວາສິ່ງທີ່ທ່ານເຫັນໃນ Pinterest, ແລະມັນບໍ່ຈໍາກັດພຽງແຕ່ຮູບແບບນ້ໍາຕົກ. ໃນຮູບແບບ Masonry:
ເພງສາມາດເປັນຖັນ ຫຼືແຖວ:
ການຕິດຕາມເນື້ອຫາບໍ່ແມ່ນທັງຫມົດຕ້ອງມີຂະຫນາດດຽວກັນ:
ລາຍການສາມາດຂະຫຍາຍໄດ້ຫຼາຍເພງ:
ລາຍການສາມາດຖືກຈັດໃສ່ໃນການຕິດຕາມສະເພາະ; ພວກເຂົາບໍ່ ຈຳ ເປັນຕ້ອງປະຕິບັດຕາມຂັ້ນຕອນການຈັດວາງອັດຕະໂນມັດສະ ເໝີ:
ສາທິດ ນີ້ແມ່ນການສາທິດງ່າຍໆຈຳນວນໜຶ່ງທີ່ຂ້ອຍໄດ້ເຮັດໂດຍການໃຊ້ການຈັດຕັ້ງປະຕິບັດ CSS Masonry ໃນ Chromium ທີ່ຈະມາເຖິງ. ການສາທິດຄັງຮູບພາບ, ສະແດງໃຫ້ເຫັນວ່າລາຍການ (ຫົວຂໍ້ໃນກໍລະນີນີ້) ສາມາດຂະຫຍາຍຫຼາຍແທຣັກແນວໃດ:
ຄັງຮູບພາບອີກປະການຫນຶ່ງສະແດງໃຫ້ເຫັນເສັ້ນທາງຂອງຂະຫນາດທີ່ແຕກຕ່າງກັນ:
ແຜນຜັງເວັບໄຊທ໌ຂ່າວທີ່ມີບາງແຖບກວ້າງກວ່າບ່ອນອື່ນ, ແລະບາງລາຍການທີ່ກວມເອົາຄວາມກວ້າງທັງຫມົດຂອງໂຄງຮ່າງ:
ກະດານ kanban ສະແດງໃຫ້ເຫັນວ່າລາຍການສາມາດຖືກຈັດໃສ່ໃນເສັ້ນທາງສະເພາະ:
ຫມາຍເຫດ: ໄດ້ການສາທິດທີ່ຜ່ານມາໄດ້ຖືກສ້າງຂື້ນດ້ວຍ Chromium ຮຸ່ນທີ່ຍັງບໍ່ທັນມີໃຫ້ກັບຜູ້ໃຊ້ເວັບສ່ວນໃຫຍ່, ເພາະວ່າ CSS Masonry ແມ່ນພຽງແຕ່ເລີ່ມປະຕິບັດຢູ່ໃນຕົວທ່ອງເວັບເທົ່ານັ້ນ. ຢ່າງໃດກໍຕາມ, ຜູ້ພັດທະນາເວັບໄດ້ໃຊ້ຫ້ອງສະຫມຸດຢ່າງມີຄວາມສຸກເພື່ອສ້າງຮູບແບບ Masonry ສໍາລັບປີແລ້ວ. ສະຖານທີ່ໃຊ້ Masonry ໃນມື້ນີ້ ແທ້ຈິງແລ້ວ, Masonry ແມ່ນຂ້ອນຂ້າງທົ່ວໄປຢູ່ໃນເວັບໃນມື້ນີ້. ນີ້ແມ່ນບາງຕົວຢ່າງທີ່ຂ້ອຍພົບນອກຈາກ Pinterest:
ແລະອີກສອງສາມຢ່າງ, ບໍ່ຄ່ອຍຈະແຈ້ງ, ຕົວຢ່າງ:
ດັ່ງນັ້ນ, ການຈັດວາງເຫຼົ່ານີ້ຖືກສ້າງຂື້ນແນວໃດ? ວິທີແກ້ໄຂບັນຫາ ເຄັດລັບອັນໜຶ່ງທີ່ຂ້ອຍເຫັນໃຊ້ແມ່ນໃຊ້ຮູບແບບ Flexbox ແທນ, ປ່ຽນທິດທາງຂອງມັນໄປຫາຖັນ, ແລະຕັ້ງມັນເປັນຫໍ່. ດ້ວຍວິທີນີ້, ທ່ານສາມາດວາງລາຍການທີ່ມີຄວາມສູງທີ່ແຕກຕ່າງກັນໃນຫຼາຍຖັນເອກະລາດ, ໃຫ້ຄວາມປະທັບໃຈຂອງຮູບແບບ Masonry:
ຢ່າງໃດກໍຕາມ, ມີສອງຂໍ້ຈໍາກັດກັບການແກ້ໄຂນີ້:
ຄໍາສັ່ງຂອງລາຍການແມ່ນແຕກຕ່າງຈາກສິ່ງທີ່ມັນຈະເປັນຮູບແບບ Masonry ທີ່ແທ້ຈິງ. ດ້ວຍ Flexbox, ລາຍການຕ່າງໆຕື່ມໃສ່ຖັນທຳອິດກ່ອນ ແລະ ເມື່ອມັນເຕັມແລ້ວ, ຈາກນັ້ນໄປທີ່ຖັນຖັດໄປ. ດ້ວຍ Masonry, ລາຍການຕ່າງໆຈະ stack ໃນເສັ້ນໃດກໍ່ຕາມ (ຫຼືຖັນໃນກໍລະນີນີ້) ມີພື້ນທີ່ຫວ່າງຫຼາຍ. ແຕ່ຍັງ, ແລະບາງທີສໍາຄັນກວ່ານັ້ນ, ການແກ້ໄຂນີ້ຮຽກຮ້ອງໃຫ້ທ່ານກໍານົດຄວາມສູງຄົງທີ່ກັບຖັງ Flexbox; ຖ້າບໍ່ດັ່ງນັ້ນ, ບໍ່ມີການຫໍ່ຈະເກີດຂຶ້ນ.
ຫໍສະໝຸດ Masonry ພາກສ່ວນທີສາມ ສໍາລັບກໍລະນີທີ່ກ້າວຫນ້າທາງດ້ານຫຼາຍ, ນັກພັດທະນາໄດ້ໃຊ້ຫ້ອງສະຫມຸດ. ຫ້ອງສະຫມຸດທີ່ມີຊື່ສຽງທີ່ສຸດແລະເປັນທີ່ນິຍົມທີ່ສຸດສໍາລັບການນີ້ແມ່ນເອີ້ນວ່າ Masonry, ແລະມັນໄດ້ຮັບການດາວໂຫຼດປະມານ 200,000 ເທື່ອຕໍ່ອາທິດອີງຕາມ NPM. Squarespace ຍັງສະຫນອງອົງປະກອບການຈັດວາງທີ່ສະແດງຮູບແບບ Masonry, ສໍາລັບທາງເລືອກທີ່ບໍ່ມີລະຫັດ, ແລະຫຼາຍໆສະຖານທີ່ໃຊ້ມັນ. ທັງສອງທາງເລືອກເຫຼົ່ານີ້ໃຊ້ລະຫັດ JavaScript ເພື່ອຈັດວາງລາຍການໃນການຈັດວາງ. ການກໍ່ສ້າງໃນ Masonry ຂ້ອຍຮູ້ສຶກຕື່ນເຕັ້ນແທ້ໆທີ່ Masonry ປະຈຸບັນເລີ່ມປາກົດຢູ່ໃນຕົວທ່ອງເວັບທີ່ເປັນຄຸນສົມບັດ CSS ທີ່ມີໃນຕົວ. ເມື່ອເວລາຜ່ານໄປ, ທ່ານຈະສາມາດໃຊ້ Masonry ຄືກັນກັບທ່ານເຮັດ Grid ຫຼື Flexbox, ນັ້ນແມ່ນ, ບໍ່ຈໍາເປັນຕ້ອງມີການແກ້ໄຂຫຼືລະຫັດຂອງພາກສ່ວນທີສາມ. ທີມງານຂອງຂ້ອຍຢູ່ Microsoft ໄດ້ດໍາເນີນການສະຫນັບສະຫນູນ Masonry ທີ່ມີການກໍ່ສ້າງໃນໂຄງການ Chromium open source, ເຊິ່ງ Edge, Chrome, ແລະຕົວທ່ອງເວັບອື່ນໆຈໍານວນຫຼາຍແມ່ນອີງໃສ່. ຕົວຈິງແລ້ວ Mozilla ແມ່ນຜູ້ຈໍາຫນ່າຍຕົວທ່ອງເວັບທໍາອິດທີ່ສະເຫນີການດໍາເນີນການທົດລອງຂອງ Masonry ກັບຄືນໄປບ່ອນໃນປີ 2020. ແລະ Apple ຍັງມີຄວາມສົນໃຈຫຼາຍທີ່ຈະເຮັດໃຫ້ຮູບແບບເວັບໄຊຕ໌ໃຫມ່ນີ້ເກີດຂຶ້ນ. ການເຮັດວຽກເພື່ອມາດຕະຖານລັກສະນະແມ່ນຍັງກ້າວໄປຂ້າງຫນ້າ, ໂດຍມີຂໍ້ຕົກລົງພາຍໃນກຸ່ມເຮັດວຽກ CSS ກ່ຽວກັບທິດທາງທົ່ວໄປແລະແມ້ກະທັ້ງການສະແດງປະເພດການສະແດງໃຫມ່: grid-lanes. ຖ້າທ່ານຕ້ອງການຮຽນຮູ້ເພີ່ມເຕີມກ່ຽວກັບ Masonry ແລະຕິດຕາມຄວາມຄືບຫນ້າ, ກວດເບິ່ງຫນ້າຊັບພະຍາກອນ CSS Masonry ຂອງຂ້ອຍ. ໃນເວລານັ້ນ, ເມື່ອ Masonry ກາຍເປັນຄຸນສົມບັດພື້ນຖານ, ຄືກັນກັບ Grid ຫຼື Flexbox, ພວກເຮົາຈະສາມາດໃຊ້ມັນຢ່າງງ່າຍດາຍແລະໄດ້ຮັບຜົນປະໂຫຍດຈາກ:
ການປະຕິບັດທີ່ດີກວ່າ, ການຕອບສະຫນອງທີ່ດີກວ່າ, ງ່າຍໃນການນໍາໃຊ້ແລະລະຫັດງ່າຍຂຶ້ນ.
ຂໍໃຫ້ພິຈາລະນາເບິ່ງສິ່ງເຫຼົ່ານີ້ຕື່ມອີກ. ປະສິດທິພາບທີ່ດີກວ່າ ການສ້າງລະບົບການຈັດວາງທີ່ຄ້າຍຄືກັບ Masonry ຂອງທ່ານເອງ, ຫຼືໃຊ້ຫ້ອງສະຫມຸດພາກສ່ວນທີສາມແທນ, ຫມາຍຄວາມວ່າທ່ານຈະຕ້ອງແລ່ນລະຫັດ JavaScript ເພື່ອວາງລາຍການໃນຫນ້າຈໍ. ນີ້ຍັງຫມາຍຄວາມວ່າລະຫັດນີ້ຈະສະແດງການສະກັດ. ແທ້ຈິງແລ້ວ, ບໍ່ມີຫຍັງຈະປາກົດ, ຫຼືສິ່ງຕ່າງໆຈະບໍ່ຢູ່ໃນສະຖານທີ່ທີ່ເຫມາະສົມຫຼືຂະຫນາດທີ່ເຫມາະສົມ, ຈົນກ່ວາລະຫັດ JavaScript ຈະດໍາເນີນການ. ແຜນຜັງ Masonry ມັກຈະຖືກນໍາໃຊ້ສໍາລັບສ່ວນຕົ້ນຕໍຂອງຫນ້າເວັບ, ຊຶ່ງຫມາຍຄວາມວ່າລະຫັດຈະເຮັດໃຫ້ເນື້ອຫາຕົ້ນຕໍຂອງທ່ານປາກົດຂຶ້ນພາຍຫຼັງທີ່ມັນອາດຈະມີ, ທໍາລາຍ LCP ຂອງທ່ານ, ຫຼືຕົວວັດແທກການແຕ້ມເນື້ອໃນທີ່ໃຫຍ່ທີ່ສຸດ, ເຊິ່ງມີບົດບາດອັນໃຫຍ່ຫຼວງໃນການປະຕິບັດການຮັບຮູ້ແລະການເພີ່ມປະສິດທິພາບຂອງເຄື່ອງຈັກຊອກຫາ. ຂ້າພະເຈົ້າໄດ້ທົດສອບຫ້ອງສະຫມຸດ Masonry JS ດ້ວຍຮູບແບບທີ່ງ່າຍດາຍແລະໂດຍການຈໍາລອງການເຊື່ອມຕໍ່ 4G ຊ້າໃນ DevTools. ຫ້ອງສະຫມຸດບໍ່ໃຫຍ່ຫຼາຍ (24KB, 7.8KB gzipped), ແຕ່ມັນໃຊ້ເວລາ 600ms ເພື່ອໂຫລດພາຍໃຕ້ເງື່ອນໄຂການທົດສອບຂອງຂ້ອຍ. ນີ້ແມ່ນການບັນທຶກການປະຕິບັດທີ່ສະແດງໃຫ້ເຫັນວ່າເວລາໂຫຼດຍາວ 600ms ສໍາລັບຫ້ອງສະຫມຸດ Masonry, ແລະບໍ່ມີກິດຈະກໍາການສະແດງຜົນອື່ນໃດເກີດຂຶ້ນໃນຂະນະທີ່ມັນເກີດຂຶ້ນ:
ນອກຈາກນັ້ນ, ຫຼັງຈາກເວລາໂຫຼດເບື້ອງຕົ້ນ, script ທີ່ດາວໂຫລດແລ້ວຈໍາເປັນຕ້ອງຖືກວິເຄາະ, ລວບລວມ, ແລະຫຼັງຈາກນັ້ນດໍາເນີນການ. ທັງຫມົດ, ດັ່ງທີ່ໄດ້ກ່າວມາກ່ອນ, ແມ່ນການຂັດຂວາງການສະແດງຫນ້າ. ດ້ວຍການປະຕິບັດການ Masonry ທີ່ມີໃນ browser, ພວກເຮົາຈະບໍ່ມີສະຄິບເພື່ອໂຫລດແລະແລ່ນ. ເຄື່ອງຈັກຂອງຕົວທ່ອງເວັບພຽງແຕ່ຈະເຮັດມັນໃນລະຫວ່າງຂັ້ນຕອນການສະແດງຫນ້າເບື້ອງຕົ້ນ. ການຕອບສະຫນອງທີ່ດີກວ່າ ຄ້າຍຄືກັນກັບເວລາໂຫຼດໜ້າທຳອິດ, ປັບຂະໜາດໜ້າຕ່າງຂອງບຣາວເຊີຈະນຳໄປສູ່ການສະແດງຮູບແບບໃນໜ້ານັ້ນອີກຄັ້ງ. ໃນຈຸດນີ້, ເຖິງແມ່ນວ່າ, ຖ້າຫນ້າເວັບກໍາລັງໃຊ້ຫ້ອງສະຫມຸດ Masonry JS, ບໍ່ຈໍາເປັນຕ້ອງໂຫລດ script ອີກເທື່ອຫນຶ່ງ, ເພາະວ່າມັນຢູ່ແລ້ວ.ທີ່ນີ້. ຢ່າງໃດກໍຕາມ, ລະຫັດທີ່ຍ້າຍລາຍການໃນສະຖານທີ່ທີ່ເຫມາະສົມຈໍາເປັນຕ້ອງດໍາເນີນການ. ໃນປັດຈຸບັນຫ້ອງສະຫມຸດໂດຍສະເພາະນີ້ເບິ່ງຄືວ່າຈະໄວ pretty ໃນການດໍາເນີນການນີ້ໃນເວລາທີ່ຫນ້າໂຫຼດ. ແນວໃດກໍ່ຕາມ, ມັນເຮັດໃຫ້ລາຍການເຄື່ອນໄຫວເມື່ອພວກເຂົາຕ້ອງການຍ້າຍໄປບ່ອນອື່ນໃນການປັບຂະໜາດໜ້າຕ່າງ, ແລະນີ້ເຮັດໃຫ້ມີຄວາມແຕກຕ່າງກັນຫຼາຍ. ແນ່ນອນ, ຜູ້ໃຊ້ບໍ່ໄດ້ໃຊ້ເວລາປັບຂະຫນາດປ່ອງຢ້ຽມຂອງຕົວທ່ອງເວັບຫຼາຍເທົ່າທີ່ພວກເຮົາຜູ້ພັດທະນາເຮັດ. ແຕ່ປະສົບການການປັບຂະຫນາດພາບເຄື່ອນໄຫວນີ້ສາມາດເປັນກະວົນກະວາຍທີ່ສວຍງາມແລະເພີ່ມເວລາທີ່ຮັບຮູ້ວ່າມັນໃຊ້ເວລາສໍາລັບຫນ້າເພື່ອປັບຕົວກັບຂະຫນາດໃຫມ່ຂອງມັນ. ຄວາມງ່າຍຂອງການນໍາໃຊ້ແລະລະຫັດງ່າຍດາຍ ມັນງ່າຍປານໃດທີ່ຈະໃຊ້ຄຸນສົມບັດເວັບ ແລະວິທີການເບິ່ງລະຫັດທີ່ງ່າຍດາຍແມ່ນປັດໃຈສໍາຄັນທີ່ສາມາດເຮັດໃຫ້ມີຄວາມແຕກຕ່າງອັນໃຫຍ່ຫຼວງໃຫ້ກັບທີມຂອງເຈົ້າ. ພວກມັນບໍ່ສາມາດມີຄວາມສໍາຄັນເທົ່າກັບປະສົບການຂອງຜູ້ໃຊ້ສຸດທ້າຍ, ແນ່ນອນ, ແຕ່ປະສົບການຂອງຜູ້ພັດທະນາມີຜົນກະທົບຕໍ່ການຮັກສາ. ການໃຊ້ຄຸນສົມບັດເວັບທີ່ສ້າງຂຶ້ນມາມາພ້ອມກັບຜົນປະໂຫຍດທີ່ສໍາຄັນຢູ່ດ້ານຫນ້ານັ້ນ:
ນັກພັດທະນາຜູ້ທີ່ຮູ້ HTML, CSS, ແລະ JS ແລ້ວຈະສາມາດໃຊ້ຄຸນສົມບັດນັ້ນໄດ້ງ່າຍເພາະວ່າມັນໄດ້ຖືກອອກແບບເພື່ອປະສົມປະສານໄດ້ດີແລະສອດຄ່ອງກັບສ່ວນທີ່ເຫຼືອຂອງແພລະຕະຟອມເວັບ. ບໍ່ມີຄວາມສ່ຽງທີ່ຈະທໍາລາຍການປ່ຽນແປງທີ່ຖືກນໍາສະເຫນີໃນວິທີການນໍາໃຊ້ຄຸນສົມບັດ. ມີຄວາມສ່ຽງເກືອບສູນທີ່ຄຸນສົມບັດນັ້ນຖືກຍົກເລີກ ຫຼືບໍ່ໄດ້ຮັບການຮັກສາໄວ້.
ໃນກໍລະນີຂອງການກໍ່ສ້າງໃນ Masonry, ເນື່ອງຈາກວ່າມັນເປັນຮູບແບບເບື້ອງຕົ້ນ, ທ່ານໃຊ້ມັນຈາກ CSS, ຄືກັນກັບ Grid ຫຼື Flexbox, ບໍ່ມີ JS ທີ່ກ່ຽວຂ້ອງ. ນອກຈາກນີ້, ຄຸນສົມບັດ CSS ທີ່ກ່ຽວຂ້ອງກັບການຈັດວາງອື່ນໆ, ເຊັ່ນຊ່ອງຫວ່າງ, ເຮັດວຽກຕາມທີ່ເຈົ້າຄາດຫວັງໃຫ້ພວກມັນ. ບໍ່ມີເຄັດລັບ ຫຼືວິທີແກ້ໄຂບັນຫາໃດໆທີ່ຕ້ອງຮູ້ກ່ຽວກັບ, ແລະສິ່ງທີ່ເຈົ້າຮຽນມານັ້ນແມ່ນບັນທຶກໄວ້ໃນ MDN. ສໍາລັບ Masonry JS lib, ການເລີ່ມຕົ້ນແມ່ນສັບສົນເລັກນ້ອຍ: ມັນຮຽກຮ້ອງໃຫ້ມີຄຸນລັກສະນະຂໍ້ມູນທີ່ມີ syntax ສະເພາະ, ພ້ອມກັບອົງປະກອບ HTML ທີ່ເຊື່ອງໄວ້ເພື່ອກໍານົດຂະຫນາດຖັນແລະຊ່ອງຫວ່າງ. ນອກຈາກນັ້ນ, ຖ້າທ່ານຕ້ອງການຂະຫຍາຍຖັນ, ທ່ານຈໍາເປັນຕ້ອງໃສ່ຂະຫນາດຊ່ອງຫວ່າງຕົວທ່ານເອງເພື່ອຫຼີກເວັ້ນບັນຫາ:
ໃຫ້ສົມທຽບນີ້ກັບສິ່ງທີ່ການກໍ່ສ້າງໃນ Masonry ປະຕິບັດຈະຄ້າຍຄື:
ລະຫັດທີ່ງ່າຍກວ່າ, ໜາແໜ້ນກວ່າທີ່ສາມາດໃຊ້ສິ່ງຕ່າງໆເຊັ່ນຊ່ອງຫວ່າງ ແລະບ່ອນທີ່ການຂະຫຍາຍເສັ້ນທາງແມ່ນເຮັດດ້ວຍ span 2, ຄືກັນກັບໃນຕາໜ່າງ, ແລະບໍ່ຕ້ອງການໃຫ້ທ່ານຄິດໄລ່ຄວາມກວ້າງທີ່ຖືກຕ້ອງເຊິ່ງລວມມີຂະໜາດຊ່ອງຫວ່າງ. ເຮັດແນວໃດເພື່ອຮູ້ວ່າສິ່ງທີ່ມີຢູ່ແລະໃນເວລາທີ່ມັນມີຢູ່? ໂດຍລວມແລ້ວ, ຄໍາຖາມບໍ່ແມ່ນແທ້ໆວ່າທ່ານຄວນໃຊ້ Masonry ກໍ່ສ້າງໃນຫ້ອງສະຫມຸດ JS, ແຕ່ວ່າເວລາໃດ. ຫ້ອງສະຫມຸດ Masonry JS ແມ່ນຫນ້າປະຫລາດໃຈແລະໄດ້ຮັບການຕື່ມຊ່ອງຫວ່າງໃນເວທີເວັບໄຊຕ໌ສໍາລັບເວລາຫຼາຍປີ, ແລະສໍາລັບນັກພັດທະນາແລະຜູ້ໃຊ້ທີ່ມີຄວາມສຸກຫລາຍ. ມັນມີຂໍ້ບົກຜ່ອງບໍ່ຫຼາຍປານໃດຖ້າທ່ານປຽບທຽບມັນກັບການຈັດຕັ້ງປະຕິບັດ Masonry ທີ່ມີການກໍ່ສ້າງ, ແນ່ນອນ, ແຕ່ສິ່ງເຫຼົ່ານັ້ນບໍ່ສໍາຄັນຖ້າການປະຕິບັດນັ້ນບໍ່ພ້ອມ. ມັນງ່າຍສໍາລັບຂ້ອຍທີ່ຈະລາຍຊື່ຄຸນສົມບັດຂອງແພລະຕະຟອມເວັບໃຫມ່ໆເຫຼົ່ານີ້ເພາະວ່າຂ້ອຍເຮັດວຽກຢູ່ຜູ້ຂາຍຕົວທ່ອງເວັບ, ແລະດັ່ງນັ້ນຂ້ອຍມັກຈະຮູ້ວ່າສິ່ງທີ່ຈະມາເຖິງ. ແຕ່ນັກພັດທະນາມັກຈະແບ່ງປັນ, ການສໍາຫຼວດຫຼັງຈາກການສໍາຫຼວດ, ວ່າການຕິດຕາມສິ່ງໃຫມ່ແມ່ນຍາກ. ການຮັບຂໍ້ມູນເປັນເລື່ອງຍາກ, ແລະບໍລິສັດຕ່າງໆກໍ່ບໍ່ໄດ້ໃຫ້ຄວາມສຳຄັນກັບການຮຽນຮູ້ສະເໝີ. ເພື່ອຊ່ວຍໃນເລື່ອງນີ້, ນີ້ແມ່ນຊັບພະຍາກອນຈໍານວນຫນ້ອຍທີ່ສະຫນອງການປັບປຸງໃນວິທີທີ່ງ່າຍດາຍແລະຫນາແຫນ້ນເພື່ອໃຫ້ທ່ານສາມາດໄດ້ຮັບຂໍ້ມູນທີ່ທ່ານຕ້ອງການຢ່າງໄວວາ:
ເວທີເວັບໄຊທ໌ explorer: ທ່ານອາດຈະສົນໃຈໃນຫນ້າບັນທຶກການປ່ອຍຂອງມັນ. ແລະ, ຖ້າທ່ານມັກ RSS, ກວດເບິ່ງຟີດບັນທຶກການປ່ອຍ, ເຊັ່ນດຽວກັນກັບຂໍ້ມູນພື້ນຖານທີ່ມີໃຫມ່ແລະມີຢູ່ຢ່າງກວ້າງຂວາງ.
ເວັບໄຊຕ໌ກະດານສະຖານະຂອງເວທີ: ທ່ານອາດຈະມັກຫນ້າປີພື້ນຖານຕ່າງໆຂອງມັນ.
ໜ້າແຜນທີ່ສະຖານະຂອງ Chrome Platform.
ຖ້າທ່ານມີເວລາຫຼາຍ, ທ່ານອາດຈະສົນໃຈໃນບັນທຶກການປ່ອຍຕົວຂອງຜູ້ຂາຍຂອງຕົວທ່ອງເວັບ:
Chrome ຂອບ Firefox Safari
ສໍາລັບຊັບພະຍາກອນເພີ່ມເຕີມ, ກວດເບິ່ງການນໍາທາງຂອງ Web Platform Cheatsheet ຂອງຂ້ອຍ. ສິ່ງຂອງຂ້ອຍຍັງບໍ່ຖືກປະຕິບັດ ນັ້ນແມ່ນອີກດ້ານຫນຶ່ງຂອງບັນຫາ. ເຖິງແມ່ນວ່າທ່ານຈະຊອກຫາເວລາ, ພະລັງງານ, ແລະວິທີທີ່ຈະຕິດຕາມ, ມັນຍັງມີຄວາມອຸກອັ່ງທີ່ຈະໄດ້ຍິນສຽງຂອງເຈົ້າແລະລັກສະນະທີ່ທ່ານມັກ. ບາງທີເຈົ້າໄດ້ລໍຖ້າມາເປັນເວລາຫຼາຍປີເພື່ອໃຫ້ຂໍ້ບົກພ່ອງສະເພາະໃດໜຶ່ງໄດ້ຮັບການແກ້ໄຂ, ຫຼືຄຸນສົມບັດສະເພາະທີ່ຈະຈັດສົ່ງໃນໂປຣແກຣມທ່ອງເວັບທີ່ມັນຍັງຂາດຫາຍໄປ. ສິ່ງທີ່ຂ້ອຍຈະເວົ້າແມ່ນຜູ້ຂາຍຕົວທ່ອງເວັບຟັງ. ຂ້ອຍເປັນສ່ວນໜຶ່ງຂອງທີມງານຂ້າມອົງການຫຼາຍໆຄົນທີ່ພວກເຮົາສົນທະນາກ່ຽວກັບສັນຍານຂອງຜູ້ພັດທະນາ ແລະຄໍາຕິຊົມຕະຫຼອດເວລາ. ພວກເຮົາເບິ່ງຫຼາຍແຫຼ່ງຄໍາຕິຊົມທີ່ແຕກຕ່າງກັນ, ທັງພາຍໃນຂອງແຕ່ລະຜູ້ຂາຍຕົວທ່ອງເວັບແລະພາຍນອກ / ສາທາລະນະໃນເວທີສົນທະນາ, ໂຄງການແຫຼ່ງເປີດ, ບລັອກ, ແລະການສໍາຫຼວດ. ແລະ, ພວກເຮົາສະເຫມີພະຍາຍາມສ້າງວິທີທີ່ດີກວ່າສໍາລັບນັກພັດທະນາເພື່ອແບ່ງປັນຄວາມຕ້ອງການສະເພາະຂອງເຂົາເຈົ້າແລະກໍລະນີການນໍາໃຊ້. ດັ່ງນັ້ນ, ຖ້າທ່ານສາມາດເຮັດໄດ້, ກະລຸນາຮຽກຮ້ອງເພີ່ມເຕີມຈາກຜູ້ຂາຍຕົວທ່ອງເວັບແລະກົດດັນໃຫ້ພວກເຮົາປະຕິບັດຄຸນສົມບັດທີ່ທ່ານຕ້ອງການ. ຂ້າພະເຈົ້າໄດ້ຮັບວ່າມັນໃຊ້ເວລາ, ແລະຍັງສາມາດຂົ່ມຂູ່ (ບໍ່ໃຫ້ເວົ້າເຖິງອຸປະສັກສູງທີ່ຈະເຂົ້າ), ແຕ່ວ່າມັນຍັງເຮັດວຽກ. ນີ້ແມ່ນບາງວິທີທີ່ທ່ານສາມາດໄດ້ຍິນສຽງຂອງທ່ານ (ຫຼືບໍລິສັດຂອງທ່ານ) ໄດ້: ເອົາລັດປະຈໍາປີຂອງ JS, State of CSS, ແລະ State of HTML ການສໍາຫຼວດ. ພວກເຂົາມີບົດບາດອັນໃຫຍ່ຫຼວງໃນວິທີທີ່ຜູ້ຂາຍຕົວທ່ອງເວັບຈັດລໍາດັບຄວາມສໍາຄັນຂອງວຽກງານຂອງພວກເຂົາ. ຖ້າທ່ານຕ້ອງການ API ທີ່ອີງໃສ່ມາດຕະຖານສະເພາະເພື່ອປະຕິບັດຢ່າງສະຫມໍ່າສະເຫມີໃນທົ່ວຕົວທ່ອງເວັບ, ພິຈາລະນາການຍື່ນສະເຫນີໃນໂຄງການ Interop ຕໍ່ໄປ. ມັນຮຽກຮ້ອງໃຫ້ມີເວລາຫຼາຍ, ແຕ່ພິຈາລະນາວິທີການທີ່ Shopify ແລະ RUMvision ແບ່ງປັນລາຍການທີ່ຕ້ອງການຂອງພວກເຂົາສໍາລັບ Interop 2026. ຂໍ້ມູນລາຍລະອຽດເຊັ່ນນີ້ສາມາດເປັນປະໂຫຍດຫຼາຍສໍາລັບຜູ້ຂາຍຕົວທ່ອງເວັບທີ່ຈະຈັດລໍາດັບຄວາມສໍາຄັນ. ສໍາລັບການເຊື່ອມຕໍ່ທີ່ເປັນປະໂຫຍດຫຼາຍທີ່ຈະມີອິດທິພົນຕໍ່ຜູ້ຂາຍຂອງຕົວທ່ອງເວັບ, ກວດເບິ່ງການນໍາທາງຂອງ Web Platform Cheatsheet ຂອງຂ້ອຍ. ສະຫຼຸບ ເພື່ອປິດ, ຂ້າພະເຈົ້າຫວັງວ່າບົດຄວາມນີ້ເຮັດໃຫ້ເຈົ້າມີບາງສິ່ງທີ່ຄວນຄິດກ່ຽວກັບ:
ຄວາມຕື່ນເຕັ້ນສໍາລັບການ Masonry ແລະລັກສະນະເວັບທີ່ຈະມາເຖິງອື່ນໆ. ບາງຄຸນສົມບັດເວັບທີ່ເຈົ້າອາດຈະຕ້ອງການເລີ່ມໃຊ້. ບາງສ່ວນຂອງລະຫັດ custom ຫຼືພາກສ່ວນທີສາມທີ່ທ່ານອາດຈະສາມາດເອົາອອກໃນເງື່ອນໄຂຂອງຄຸນນະສົມບັດໃນຕົວ. ສອງສາມວິທີທີ່ຈະຕິດຕາມສິ່ງທີ່ ກຳ ລັງຈະມາເຖິງແລະມີອິດທິພົນຕໍ່ຜູ້ຂາຍ browser.
ສິ່ງທີ່ ສຳ ຄັນກວ່ານັ້ນ, ຂ້ອຍຫວັງວ່າຂ້ອຍໄດ້ຊັກຊວນເຈົ້າກ່ຽວກັບຜົນປະໂຫຍດຂອງການໃຊ້ແພລະຕະຟອມເວັບຢ່າງເຕັມທີ່.
