Houdini: Belki de CSS'de Hiç Duymadığınız En Heyecan Verici Gelişme

Hiç belirli bir CSS özelliğini kullanmak istediniz, ancak tüm tarayıcılarda tam olarak desteklenmediği için kullanamadınız mı? Veya daha da kötüsü, tüm tarayıcılarda destekleniyordu, ancak destek hatalı, tutarsız ve hatta tamamen uyumsuz muydu? Bu senin başına geldiyse - ki bahse girerim olmuştur - o zaman Houdini'yi önemsemelisin.

Houdini, nihai hedefi bu sorunu sonsuza dek ortadan kaldırmak olan yeni bir W3C görev gücüdür. Bunu, geliştiricilere ilk kez CSS'nin kendisini genişletme gücü ve bir tarayıcının oluşturma motorunun stil ve düzen sürecine bağlanmak için araçlar sağlayacak yeni bir API kümesi sunarak yapmayı planlıyor.

SmashingMag'de Daha Fazla Okuma :

• WebDev Ortamınızı Yerel Olarak Kurmayı Neden Durdurmalısınız?
• CSS'nin Geleceği: Deneysel CSS Özellikleri
• 53 CSS-Tekniği Olmadan Yaşayamazsınız

Ama bu özellikle ne anlama geliyor? Bu iyi bir fikir mi? Ve geliştiricilerin şimdi ve gelecekte web siteleri oluşturmasına nasıl yardımcı olacak?

Bu yazıda bu soruları cevaplamaya çalışacağım. Ama bunu yapmadan önce, bugün sorunların ne olduğunu ve neden böyle bir değişime ihtiyaç duyulduğunu netleştirmek önemli. Ardından, Houdini'nin bu sorunları nasıl çözeceği hakkında daha ayrıntılı konuşacağım ve şu anda geliştirilmekte olan daha heyecan verici özelliklerden bazılarını listeleyeceğim. Son olarak, Houdini'yi gerçeğe dönüştürmek için web geliştiricileri olarak bugün yapabileceğimiz bazı somut şeyler sunacağım.

Houdini Hangi Sorunları Çözmeye Çalışıyor?

Ne zaman bir makale yazsam veya yepyeni bir CSS özelliğini gösteren bir demo oluştursam, kaçınılmaz olarak yorumlarda veya Twitter'da birileri "Bu harika! Bir 10 yıl daha kullanamayacak olmamız ne yazık ki.”

Böyle yorumlar ne kadar sinir bozucu ve yapıcı olmasa da, bu duyguyu anlıyorum. Tarihsel olarak, özellik önerilerinin yaygın bir şekilde benimsenmesi yıllar almıştır. Bunun nedeni, web tarihi boyunca, CSS'ye yeni bir özellik eklemenin tek yolunun standartlar sürecinden geçmek olmasıdır.

Standartlar sürecine kesinlikle karşı değilim, ancak uzun zaman alabileceğini inkar edemem!

Örneğin, flexbox ilk olarak 2009'da önerildi ve geliştiriciler, tarayıcı desteği eksikliği nedeniyle bugün onu kullanamadıklarından hala şikayet ediyorlar. Verilmiş, bu sorun yavaş yavaş ortadan kalkıyor çünkü neredeyse tüm modern tarayıcılar artık otomatik olarak güncelleniyor; ancak modern tarayıcılarda bile, teklif ile bir özelliğin genel kullanılabilirliği arasında her zaman bir gecikme olacaktır.

İlginçtir ki, web'in tüm alanlarında durum böyle değildir. JavaScript'te son zamanlarda işlerin nasıl çalıştığını düşünün:

Bu senaryoda, bir fikre sahip olmakla onu üretimde kullanmak arasındaki süre bazen birkaç gün olabilir. Demek istediğim, üretimde zaten zaman async / await işlevlerini kullanıyorum ve bu özellik tek bir tarayıcıda bile uygulanmadı!

Ayrıca, bu iki topluluğun genel duyguları arasında büyük bir fark görebilirsiniz. JavaScript topluluğunda, insanların işlerin çok hızlı ilerlediğinden şikayet ettiği makaleler okursunuz. Öte yandan CSS'de, insanların onu gerçekten kullanabilmeleri için ne kadar uzun süreceğinden dolayı yeni bir şey öğrenmenin yararsızlığından yakındıklarını duyarsınız.

Öyleyse Neden Daha Fazla CSS Çoklu Dolgu Yazmıyoruz?

İlk başta, daha fazla CSS çoklu dolgusu yazmak cevap gibi görünebilir. İyi çoklu dolgularla CSS, JavaScript kadar hızlı hareket edebilir, değil mi?

Ne yazık ki, o kadar basit değil. Çoklu doldurma CSS'si inanılmaz derecede zordur ve çoğu durumda performansı tamamen yok etmeyecek şekilde yapmak imkansızdır.

JavaScript dinamik bir dildir, yani JavaScript'i çoklu doldurmak için JavaScript'i kullanabilirsiniz. Ve çok dinamik olduğu için son derece genişletilebilir. Öte yandan CSS, CSS'yi çoklu doldurmak için nadiren kullanılabilir. Bazı durumlarda, bir derleme adımında CSS'yi CSS'ye aktarabilirsiniz (PostCSS bunu yapar); ancak, DOM'nin yapısına veya bir öğenin düzenine veya konumuna bağlı olan herhangi bir şeyi çoklu dolgu yapmak istiyorsanız, çoklu dolgunun istemci tarafı mantığını çalıştırmanız gerekir.

Ne yazık ki, tarayıcı bunu kolaylaştırmıyor.

Aşağıdaki çizelge, tarayıcınızın bir HTML belgesini almaktan ekranda pikselleri görüntülemeye nasıl geçtiğinin temel bir özetini vermektedir. Mavi renkle renklendirilmiş adımlar, JavaScript'in sonuçları kontrol etme gücüne sahip olduğunu gösterir:

Resim oldukça kasvetli. Bir geliştirici olarak, tarayıcının HTML ve CSS'yi nasıl ayrıştırıp DOM ve CSS nesne modeline (CSSOM) dönüştürdüğü üzerinde hiçbir kontrolünüz yoktur. Kaskad üzerinde hiçbir kontrolünüz yok. Tarayıcının DOM'daki öğeleri nasıl yerleştirmeyi seçtiği veya bu öğeleri ekranda görsel olarak nasıl boyadığı üzerinde hiçbir kontrolünüz yoktur. Ve bestecinin ne yaptığı üzerinde hiçbir kontrolünüz yok.

İşlemin tam erişiminiz olan tek kısmı DOM'dur. CSSOM biraz açık; ancak Houdini web sitesinden alıntı yapmak gerekirse, "yetersiz belirtilmiş, tarayıcılar arasında tutarsız ve kritik özellikleri eksik."

Örneğin, günümüzde tarayıcılardaki CSSOM, size çapraz-orijinli stil sayfaları için kurallar göstermeyecek ve anlamadığı CSS kurallarını veya bildirimlerini atacaktır; bu, bir tarayıcıdaki bir özelliği çoklu doldurmak istiyorsanız, şu anlama gelir: bu desteklemiyorsa, CSSOM'u kullanamazsınız. Bunun yerine, DOM'yi gözden geçirmeniz, <style> ve/veya <link rel=“stylesheet”> etiketlerini bulmanız, CSS'yi kendiniz almanız, ayrıştırmanız, yeniden yazmanız ve ardından DOM'a geri eklemeniz gerekir.

Tabii ki, DOM'yi güncellemek genellikle tarayıcının daha sonra tüm basamak, düzen, boyama ve bileşik adımlardan tekrar geçmesi gerektiği anlamına gelir.

Bir sayfayı tamamen yeniden işlemek zorunda olmak o kadar büyük bir performans artışı gibi görünmese de (özellikle bazı web siteleri için), bunun potansiyel olarak ne sıklıkta gerçekleşmesi gerektiğini düşünün. Çoklu doldurma mantığının kaydırma olayları, pencere yeniden boyutlandırma, fare hareketleri, klavye olayları gibi şeylere yanıt olarak çalışması gerekiyorsa - gerçekten herhangi bir zamanda herhangi bir değişiklik - o zaman işler fark edilir, hatta bazen sakatlayıcı bir şekilde yavaş olacaktır.

Günümüzde çoğu CSS çoklu dolgusunun kendi CSS ayrıştırıcısını ve kendi kademeli mantığını içerdiğini fark ettiğinizde bu daha da kötüleşir. Ayrıştırma ve basamaklama aslında çok karmaşık şeyler olduğundan, bu çoklu dolgular genellikle ya çok büyük ya da çok hatalıdır.

Az önce söylediğim her şeyi daha kısa bir şekilde özetlemek gerekirse: Tarayıcının yapması gerektiğini düşündüğünden farklı bir şey yapmasını istiyorsanız (verdiğiniz CSS'ye göre), o zaman güncelleyerek ve değiştirerek onu taklit etmenin bir yolunu bulmalısınız. DOM'u kendiniz yapın. İşleme ardışık düzenindeki diğer adımlara erişiminiz yok.

Ama Neden Tarayıcının Dahili İşleme Motorunu Değiştirmek İstiyorum?

Bu, benim için kesinlikle bu makalenin tamamında cevaplanması gereken en önemli soru. Bu yüzden, şimdiye kadar bir şeyleri gözden kaçırdıysanız, bu kısmı yavaş ve dikkatli bir şekilde okuyun!

Son bölüme baktıktan sonra eminim bazılarınız “Buna ihtiyacım yok! Sadece normal web sayfaları yapıyorum. Tarayıcının içine girmeye veya süper süslü, deneysel veya son teknoloji bir şey oluşturmaya çalışmıyorum.”

Bunu düşünüyorsanız, bir saniyeliğine geri adım atmanızı ve yıllar boyunca web siteleri oluşturmak için kullandığınız teknolojileri gerçekten incelemenizi şiddetle tavsiye ediyorum. Erişim istemek ve tarayıcının stil sürecine bağlanmak, yalnızca gösterişli demolar oluşturmakla ilgili değildir; bu, geliştiricilere ve çerçeve yazarlarına iki temel şeyi yapma gücü vermekle ilgilidir:

• tarayıcılar arası farklılıkları normalleştirmek için,
• insanların bugün kullanabilmeleri için yeni özellikler icat etmek veya çoklu doldurmak.

Daha önce jQuery gibi bir JavaScript kitaplığı kullandıysanız, bu yetenekten zaten yararlanmışsınızdır! Aslında bu, bugün neredeyse tüm ön uç kitaplıkların ve çerçevelerin ana satış noktalarından biridir. GitHub'daki en popüler beş JavaScript ve DOM deposu - AngularJS, D3, jQuery, React ve Ember - hepsi, sizin düşünmenize gerek kalmaması için tarayıcılar arası farklılıkları normalleştirmek için çok iş yapar. Her biri tek bir API sunar ve çalışır.

Şimdi, CSS'yi ve onun tüm tarayıcılar arası sorunlarını düşünün. Bootstrap ve Foundation gibi tarayıcılar arası uyumluluğu iddia eden popüler CSS çerçeveleri bile aslında tarayıcılar arası hataları normalleştirmez - sadece onlardan kaçınırlar. Ve CSS'deki tarayıcılar arası hatalar sadece geçmişte kalmadı. Bugün bile flexbox gibi yeni düzen modülleri ile birçok tarayıcılar arası uyumsuzlukla karşı karşıya kalıyoruz.

Sonuç olarak, herhangi bir CSS özelliğini kullanabilseydiniz ve her tarayıcıda tamamen aynı şekilde çalışacağından emin olsaydınız geliştirme hayatınızın ne kadar güzel olacağını hayal edin. Ve blog yazılarında okuduğunuz veya konferanslarda ve buluşmalarda duyduğunuz tüm yeni özellikleri düşünün - CSS ızgaraları, CSS yakalama noktaları ve sabit konumlandırma gibi şeyler. Bunların hepsini bugün ve yerel CSS özellikleri kadar performanslı bir şekilde kullanabileceğinizi hayal edin. Ve tek yapmanız gereken GitHub'dan kodu almak.

Bu Houdini'nin rüyası. Görev gücünün mümkün kılmaya çalıştığı gelecek budur.

Bu nedenle, bir CSS çoklu dolgu yazmayı veya deneysel bir özellik geliştirmeyi hiç planlamamış olsanız bile, muhtemelen başkalarının bunu yapabilmesini istersiniz - çünkü bu çoklu dolgular bir kez var olduğunda, herkes onlardan yararlanır.

Şu anda Geliştirme Aşamasında Olan Houdini Özellikleri Nelerdir?

Yukarıda, geliştiricilerin tarayıcının işleme hattına çok az erişim noktasına sahip olduğundan bahsetmiştim. Gerçekten, tek yerler DOM ve bir dereceye kadar CSSOM'dir.

Bu sorunu çözmek için Houdini görev gücü, ilk kez geliştiricilere işleme hattının diğer bölümlerine erişim sağlayacak birkaç yeni özellik sundu. Aşağıdaki çizelge, boru hattını ve hangi adımları değiştirmek için hangi yeni özelliklerin kullanılabileceğini gösterir. (Gri olan özelliklerin planlandığını ancak henüz yazılmadığını unutmayın.)

Sonraki birkaç bölüm, her yeni spesifikasyona ve ne tür yetenekler sunduğuna ilişkin kısa bir genel bakış sunar. Ayrıca bu yazıda diğer özelliklerden bahsedilmediğini de belirtelim; tam liste için Houdini'nin taslaklarının GitHub deposuna bakın.

CSS Ayrıştırıcı API'sı

CSS Ayrıştırıcı API'si şu anda yazılmamıştır; yani, söylediklerimin çoğu kolayca değişebilir, ancak temel fikir, geliştiricilerin CSS ayrıştırıcısını genişletmesine ve yeni yapılar hakkında bilgi vermesine olanak sağlamasıdır - örneğin, yeni medya kuralları, yeni sözde sınıflar, yuvalama, @extends , @apply vb.

Ayrıştırıcı bu yeni yapıları öğrendiğinde, onları atmak yerine CSSOM'da doğru yere koyabilir.

CSS Özellikleri ve Değerleri API'sı

CSS'nin zaten özel özellikleri var ve daha önce de ifade ettiğim gibi, bunların ortaya çıkardığı olanaklar beni çok heyecanlandırıyor. CSS Özellikleri ve Değerleri API'si, özel özellikleri bir adım öteye taşır ve türler ekleyerek onları daha da kullanışlı hale getirir.

Özel mülklere tür ekleme konusunda pek çok harika şey var, ancak belki de en büyük satış noktası, türlerin geliştiricilerin özel mülklere geçiş yapmasına ve özel mülkleri canlandırmasına izin vermesidir, bugün yapamadığımız bir şey.

Bu örneği düşünün:

 body { --primary-theme-color: tomato; transition: --primary-theme-color 1s ease-in-out; } body.night-theme { --primary-theme-color: darkred; }

Yukarıdaki kodda, <body> öğesine night-theme sınıfı eklenirse, sayfadaki –primary-theme-color özellik değerine başvuran her bir öğe tomato darkred yavaş yavaş geçiş yapacaktır. Bunu bugün yapmak isteseydiniz, özelliğin kendisini değiştiremeyeceğiniz için bu öğelerin her biri için geçişi manuel olarak yazmanız gerekirdi.

Bu API'nin gelecek vaat eden bir başka özelliği de, geliştiricilere kademeli adım tamamlandıktan sonra öğeler üzerindeki özel bir özelliğin nihai değerini değiştirmenin bir yolunu veren bir "uygulama kancası" kaydetme yeteneğidir; bu, çoklu dolgular için çok yararlı bir özellik olabilir.

CSS Yazılı OM

CSS Typed OM, mevcut CSSOM'un 2. versiyonu olarak düşünülebilir. Amacı, mevcut modeldeki birçok sorunu çözmek ve yeni CSS Ayrıştırma API'si ve CSS Özellikleri ve Değerleri API'si tarafından eklenen özellikleri dahil etmektir.

Typed OM'nin bir diğer önemli amacı da performansı artırmaktır. Geçerli CSSOM'nin dize değerlerini anlamlı bir şekilde yazılmış JavaScript temsillerine dönüştürmek, önemli performans kazanımları sağlayacaktır.

CSS Düzeni API'sı

CSS Layout API, geliştiricilerin kendi düzen modüllerini yazmasına olanak tanır. Ve "düzen modülü" derken, CSS display özelliğine geçirilebilecek her şeyi kastediyorum. Bu, geliştiricilere ilk kez, display: flex ve display: table gibi yerel düzen modülleri kadar performanslı bir yerleşim planı sunacak.

Örnek bir kullanım örneği olarak, Masonry layout library, geliştiricilerin yalnızca CSS ile mümkün olmayan karmaşık düzenler elde etmek için bugün ne kadar istekli olduklarını gösterir. Bu düzenler etkileyici olsa da, ne yazık ki, özellikle daha az güçlü cihazlarda performans sorunlarından muzdariptirler.

CSS Düzen API'si, geliştiricilere bir düzen adını (daha sonra CSS'de kullanılır) kabul eden bir registerLayout yöntemi ve tüm düzen mantığını içeren bir JavaScript sınıfı vererek çalışır. İşte registerLayout aracılığıyla masonry nasıl tanımlayabileceğinize dair temel bir örnek:

 registerLayout('masonry', class { static get inputProperties() { return ['width', 'height'] } static get childrenInputProperties() { return ['x', 'y', 'position'] } layout(children, constraintSpace, styleMap, breakToken) { // Layout logic goes here. } }

Yukarıdaki örnekteki hiçbir şey size mantıklı gelmiyorsa endişelenmeyin. Dikkat edilmesi gereken en önemli şey, bir sonraki örnekteki koddur. masonry.js dosyasını indirip web sitenize ekledikten sonra, CSS'yi şöyle yazabilirsiniz ve her şey işe yarayacaktır:

 body { display: layout('masonry'); }

CSS Boya API'sı

CSS Paint API, yukarıdaki Layout API'ye çok benzer. Tıpkı registerLayout yöntemi gibi çalışan bir registerPaint yöntemi sağlar. Geliştiriciler daha sonra bir CSS görüntüsünün beklendiği herhangi bir yerde CSS'de paint() işlevini kullanabilir ve kayıtlı adı iletebilir.

Renkli bir daire çizen basit bir örnek:

 registerPaint('circle', class { static get inputProperties() { return ['--circle-color']; } paint(ctx, geom, properties) { // Change the fill color. const color = properties.get('--circle-color'); ctx.fillStyle = color; // Determine the center point and radius. const x = geom.width / 2; const y = geom.height / 2; const radius = Math.min(x, y); // Draw the circle \o/ ctx.beginPath(); ctx.arc(x, y, radius, 0, 2 * Math.PI, false); ctx.fill(); } });

Ve CSS'de şu şekilde kullanılabilir:

 .bubble { --circle-color: blue; background-image: paint('circle'); }

Şimdi, .bubble öğesi arka planda mavi bir daire ile görüntülenecektir. Ne olursa olsun, daire ortalanacak ve öğenin kendisiyle aynı boyutta olacaktır.

İşletler

Yukarıda listelenen özelliklerin çoğu kod örneklerini gösterir (örneğin, registerLayout ve registerPaint ). Bu kodu nereye koyacağınızı merak ediyorsanız, cevap worklet scriptlerinde.

İş uygulamaları web çalışanlarına benzer ve komut dosyalarını içe aktarmanıza ve (1) işleme hattındaki çeşitli noktalarda çağrılabilen ve (2) ana iş parçacığından bağımsız olan JavaScript kodunu çalıştırmanıza izin verir.

Worklet komut dosyaları, yapabileceğiniz işlem türlerini büyük ölçüde kısıtlayacaktır, bu da yüksek performansı sağlamanın anahtarıdır.

Birleşik Kaydırma ve Animasyon

Birleştirilmiş kaydırma ve animasyon için henüz resmi bir spesifikasyon olmamasına rağmen, aslında daha iyi bilinen ve merakla beklenen Houdini özelliklerinden biridir. Nihai API'ler, geliştiricilerin, bir DOM öğesinin özelliklerinin sınırlı bir alt kümesinin değiştirilmesi için destekle, ana iş parçacığının dışında, bir birleştirici iş uygulamasında mantığı çalıştırmalarına izin verecektir. Bu alt küme yalnızca, oluşturma motorunu düzeni veya stili yeniden hesaplamaya zorlamadan okunabilen veya ayarlanabilen özellikleri içerecektir (örneğin, dönüştürme, opaklık, kaydırma ofseti).

Bu, geliştiricilerin, yapışkan kaydırma başlıkları ve paralaks efektleri gibi yüksek performanslı kaydırma ve girdi tabanlı animasyonlar oluşturmasını sağlayacaktır. Bu API'lerin çözmeye çalıştığı kullanım örnekleri hakkında GitHub'da daha fazla bilgi edinebilirsiniz.

Henüz resmi bir spesifikasyon bulunmamakla birlikte, Chrome'da deneysel geliştirme çoktan başladı. Aslında, Chrome ekibi şu anda bu API'lerin sonunda ortaya çıkaracağı ilkel öğeleri kullanarak CSS yakalama noktaları ve yapışkan konumlandırma uyguluyor. Bu harika çünkü Houdini API'lerinin, yeni Chrome özelliklerinin üzerlerinde oluşturulacak kadar performanslı olduğu anlamına geliyor. Hala Houdini'nin yerli kadar hızlı olmayacağına dair herhangi bir korkunuz varsa, bu gerçek tek başına sizi aksine ikna etmelidir.

Gerçek bir örnek görmek için Surma, dahili bir Chrome yapısı üzerinde çalışan bir video demosu kaydetti. Demo, Twitter'ın yerel mobil uygulamalarında görülen kaydırma başlığının davranışını taklit eder. Nasıl çalıştığını görmek için kaynak koduna bakın.

Şimdi Ne Yapabilirsin?

Bahsettiğim gibi, web sitesi kuran herkesin Houdini'yi önemsemesi gerektiğini düşünüyorum; gelecekte tüm hayatımızı çok daha kolaylaştıracak. Bir Houdini spesifikasyonunu asla doğrudan kullanmasanız bile, neredeyse kesinlikle birinin üzerine inşa edilmiş bir şey kullanacaksınız.

Ve bu gelecek yakın olmasa da, muhtemelen çoğumuzun düşündüğünden daha yakın. Tüm büyük tarayıcı satıcılarının temsilcileri, bu yılın başlarında Sidney'deki son Houdini yüz yüze toplantısındaydı ve neyin inşa edileceği veya nasıl devam edileceği konusunda çok az anlaşmazlık vardı.

Anlayabildiğim kadarıyla, mesele Houdini'nin bir şey olup olmayacağı değil, ne zaman olacağı meselesi ve işte burada hepiniz devreye giriyorsunuz.

Tarayıcı satıcıları, yazılım oluşturan herkes gibi, yeni özelliklere öncelik vermek zorundadır. Ve bu öncelik, genellikle kullanıcıların bu özellikleri ne kadar çok istediğinin bir işlevidir.

Bu nedenle, web'de stil ve mizanpajın genişletilebilirliğine önem veriyorsanız ve standart sürecinden geçmelerini beklemek zorunda kalmadan yeni CSS özelliklerini kullanabileceğiniz bir dünyada yaşamak istiyorsanız, üyelerle konuşun. kullandığınız tarayıcı(lar) için geliştirici ilişkileri ekiplerine gidin ve onlara bunu istediğinizi söyleyin.

Yardımcı olabileceğiniz diğer bir yol da, gerçek dünyadan kullanım örnekleri – bugün yapılması zor veya imkansız olan stil ve mizanpaj ile yapmak istediğiniz şeyler – sağlamaktır. GitHub'daki taslakların birçoğunda kullanım örneği belgeleri bulunur ve fikirlerinizle katkıda bulunmak için bir çekme isteği gönderebilirsiniz. Bir doküman yoksa, bir tane başlatabilirsiniz.

Houdini görev gücünün (ve genel olarak W3C'nin) üyeleri, web geliştiricilerinden gerçekten düşünceli girdiler istiyor. Spesifikasyon yazma sürecine katılan çoğu kişi, tarayıcılarda çalışan mühendislerdir. Genellikle kendileri profesyonel web geliştiricileri değildirler, bu da her zaman sorunlu noktaların nerede olduğunu bilmedikleri anlamına gelir.

Onlara söylememiz için bize güveniyorlar.

Kaynaklar ve Bağlantılar

• CSS-TAG Houdini Editör Taslakları, W3C Tüm Houdini taslaklarının en son genel sürümü
• CSS-TAG Houdini Görev Gücü Spesifikasyonları, GitHub Spesifikasyon güncellemelerinin ve geliştirmesinin gerçekleştiği resmi Github deposu
• Houdini Örnekleri, olası API'leri sergileyen ve deneyen GitHub Kodu örnekleri
• Houdini posta listesi, W3C Genel sorular sormak için bir yer

Bu makaleyi gözden geçirdikleri için Houdini üyeleri Ian Kilpatrick ve Shane Stephens'a özel teşekkürler.