პოსტები ტეგით “IE Sucks”

Handling "onchange" event revisited

რამდენიმე თვის წინ დავწერე პოსტი, HTML ფორმის ელემენტის onchange ივენთისა და მისი დელეგირების შესახებ.

ნახსენებ პოსტში ნაჩვენებია onchange ივენთის დელეგირების მაგალითი სადაც ფორმის ყველა ელემენტის აღნიშნული ივენთის ცენტრალიზებული კონტროლი ხორციელდება მშობელი ელემენტის onchange ივენთის მეშვეობით.

მსგავსი შედეგის მიღწევა შესაძლებელი ე.წ. Event Bubbling – ის წყალობით რაც ივენთის, საწყისი ელემენტიდან მშობელი ელემენტისკენ გავრცელებას ეწოდება. მეტი თვალსაჩინოებისთვის იხ. სურათი(სურათისათვის განსაკუთრებული მადლობა ირაკლის):

picture-17

ივენთის გავცელების(შვილიდან მშობლის მიმართულებით) ასეთი მეთოდი ყველა ბრაუზერში ერთნაირად მუშაობს. და წესით ეს უნდა ეხებოდეს ყველა ტიპის ივენთს. თუმცა როგორც მოსალოდნელი იყო IE – ში მისი მერვე ვერსიის ჩათვლით სწორედ ამ ივენთზე აღმოჩნდა შეზღუდვა და იგი საწყისი ელემენტს(ელემენტი რომელზეც უშუალოდ წარმოიშვა ეს ივენთი) იქეთ არ ვრცელდება.

ერთი შეხედვით, ამ ჩიხიდან რამდენიმე გამოსავალი შეიძლება მოიძებნოს:

  1. ფორმის ყველა ელემენტის ჩამოვლა და მათთვის onchange ივენთ ჰენდლერის მინიჭება. თუმცა აქ მთელ რიგ პრობლემებს წავაწყდებით:

    • ელემენტებზე ასეთი გზით ივენთ ჰენდლერების მინიჭება IE – ში იწვევს მეხსიერებასთან დაკავშირებულ პრობლემებს, ე.წ. memory leaks. ეს გარემოება განსაკუთრებით მნიშვნელოვანია თუ ფორმაში ბევრი ელემენტები გვაქვს.
    • თუ ფორმის ელემენტები იტვირთება დინამიურად Ajax – ის მეშვეობით, ყოველი ასეთი ჩატვირთვის შემდეგ საჭიროა: ა) ყველა ფორმის ელემენტისა და მათი ივენთ ჰენდლერების განადგურება რათა თავიდან ავირიდოთ მეხსიერებასთან დაკავშირებული პრობლემები; ბ) ახლად ჩატვირთული ელემენტების იტერაცია და მათთვის შესაბამისი ივენთ ჰენდლერების განსაზღვრა.

    დამეთანხმებით რომ აღწერილი ორი მეთოდი დიდი მოქნილებით არ გამოირჩევა.

  2. ნაცვლად onchange ივენთისა გამოვიყენოთ onfocus და onblur ივენთები. თუმცა აღმოჩნდა რომ არც ამ ივენთების გავრცელება არ ხდება ტრადიციული(შვილიდან მშობლის მიმართულებით) მეთოდით.

გარკვეული კვლევა ძიების შემდეგ მივაგენი ისეთ ივენთებს(დიდი მადლობა PPK – ს) რომელთა ბაბლინგი IE – ში ისე მუშაობს როგორც საჭიროა. ეს ივენთებია onfocusin და onfocusout.

როგორ შეიძლება აღნიშნული ივენთების გამოყენება პრობლემის გადასაჭრელად? სანამ უშუალოდ კოდის წერას დავიწყებთ საჭიროა კარგად გავერკვეთ თუ როგორ მუშაობს onchange ივენთი HTML ფორმის ცალკეული ელემენტებისათვის და ასევე თუ რა გვერდის ავლის მექანიზმების გამოყენებაა შესაძლებელი IE – ში.

SELECT ელემენტი

ამ ელემენტის შემთხვევაში onchange ივენთი წარმოიშვება მხოლოდ იმ ჩამოსაშლელი სიიდან კონკრეტული ელემენტის ამორჩევის დროს. IE – ში იგივე ხდომილების ემულაციისათვის შესაძლებელია onclick ივენთის გამოყენება, თუმცა, ასეთ შემთხვევაში ივენთი ორჯერ წარმოიშვება ერთხელ ელემენტის გააქტიურებისას ხოლო მეორედ ჩამოსაშლელი სიიდან მნიშვნელობის არჩევისას. თუმცა ამ პრობლემის არიდება მარტივად არის შესაძლებელი სწორედ onfocusin და onfocusout ივენთების მეშვეობით რადგან ეს ორივე ივენთი წარმოიშვება onclick ივენთამდე, გამომდინარე აქედან შესაძლებელია წინა ივენთის ტიპის დამახსოვრება და შემდგომ უკვე დადგენა ეს იყო პირველი კლიკი თუ ჩამოსაშლელი მენიუდან ელემენტის არჩევა მოხდა?

INPUT text და TEXTAREA ელემენტები
ამ ელემენტების შემთხვევაში onchange ივენთი წარმოიშვება როდესაც ელემენტი კარგავს ფოკუსს. IE – ში იგივეს მიღწევა შესაძლებელია onfocusout ივენთის მეშვეობით.

INPUT checkbox და radio ელმენტები
ამ ელემენტების შემთხვევაში onchange ივენთი წარმოიშვება მათი მნიშვნელობის ცვლილების თანავე. IE – ში იგივე შედეგის მისაღებად მარტივად არის შესაძლებელი onclick ივენთის გამოყენება.

მაშ ასე წინა სამი პარაგრაფში გამოიკვეთა სამი ისეთი ივენთი რომელთა გამოყენებაც შესაძლებელია onchange ბაბლინგის ემულაციისათვის. ეს ივენთებია: onclick, onfocusin, onfocusout.

ამ ინფორმაციაზე დაყრდნობით მარტივად არის შესაძლებელი სულ რამდენიმე სტრიქონი კოდით გადავწყვიტოთ პრობლემა:

[javascript]
(function() {

var div = document.getElementById(‘testonchange’);

//ყველა ბრაუზერი IE – ს გარდა
if (document.addEventListener) {

div.onchange = function(e) {
//აქ შეგვიძლია გამოვიძახოთ ივენთის უშუალო ჰენდლერი
};

} else { //IE – ს სპეციფიური რეალიზაცია

var previousEvent = null;

div.onfocusin = div.onfocusout = div.onclick = function() {

var e = window.event,
target = e.srcElement,
isSelect = target.nodeName == ‘SELECT’,
notTextInput = target.nodeName == ‘INPUT’ && /^radio|checkbox$/i.test(target.type),
isTextInput = (target.nodeName == ‘INPUT’ && target.type == ‘text’) || target.nodeName == ‘TEXTAREA’,
validElement = notTextInput || isSelect;

if (isSelect && !target.size && /^focus(in|out)$/.test(previousEvent)) {
validElement = null;
}

previousEvent = e.type;

if ((e.type == ‘click’ && validElement) || (e.type == ‘focusout’ && isTextInput)) {
//აქ შეგვიძლია გამოვიძახოთ ივენთის უშუალო ჰენდლერი
}

};

}

div = null;

})();
[/javascript]

ეს არის და ეს :) კოდის დეტალური გარჩევით თავს აღარ შეგაწყენთ, ხოლო რეალური დემონსტრაცია შეგიძლიათ იხილოთ აქ.

ტეგები: , ,

HTML Form "elements" Property

ამ პოსტის დაწერამდე რამდენიმე წუთით ადრე წავაწყდი HTML form ელემენტის elements თვისებასთან დაკავშირებულ ერთ პრობლემას(შეცდომას) რომლის შესახებაც აქამდე არაფერი მსმენია და ცოტა არ იყოს უაზროდ დამახარჯინა დრო.

ცნობილია, რომ form ელემენტის აღნიშნული თვისება არის HTMLCollection ტიპის კოლექცია და იგი შეიცავს კონკრეტული HTML ფორმის შიგნით გამოყენებულ ყველა(input, select, button) ელემენტს. სწორედ ეს კოლექცია წარმოადგენს საჭირო ფორმის ელემენტებთან წვდომის ყველაზე უსაფრთხო(თურმე პირობითად) გზას.

როგორც აღმოჩნდა თუ ფორმის ელემენტებს მოვათავსებთ fieldset ტეგში(და წესით ეს ასეც უნდა გავაკეთოთ) elements კოლექცია მოულოდნელ რეზულტატს დაგვიბრუნებს. კერძოდ კი fieldset ელემენტიც(ან ელემენტები) ამ კოლექციაში აღმოჩნდება.

ჩემი ამოცანა მდგომარეობდა შემდეგში, რომ ფორმის ყველა ელემენტებისაგან მიმეღო მათი სახელებისა და მნიშნვნელობების ე.წ. key/value ობიექტი:
[javascript]
var map = {}, els = target.form.elements;
for (var i = 0, el; (el = els[i++]);) {
map[el.name] = el.value;
}
console.log(map);
[/javascript]

თუმცა ძალიან უცნაური შედეგი მივიღე რადგან fieldset ელემენტს არც name და არც value თვისებები არ გააჩნია.

პრობლემის იდენტიფიცირების შემდგომ ინტერნეტში მოვიძიე მცირეოდენი ინფორმაცია:

The HTML 4 standard adds new <fieldset> and <label> tags to the set of elements that can appear within a form. In IE 5 and later, placing a <fieldset> in a form causes a corresponding object to be added to the form’s elements[] array. Fieldset elements are not scriptable in interesting ways like other form elements are, and their objects do not have a type property like other form elements do. Therefore, the presence of Fieldset objects in the elements[] array seems like a mistaken design decision. This is particularly true since <label> tags do not cause corresponding objects to be added to the elements[] array. The Mozilla and Netscape 6 browsers have chosen to follow Microsoft’s lead on this in order to be compatible with IE.

What this means is that if you define a form that contains fieldsets, the contents of the elements[] array differ in recent, HTML 4-capable browsers and in older, pre-HTML 4 browsers. In this situation, using position-based numeric indexes in the elements[] array is not portable, and you should define name attributes for all your form elements and refer to them by name.

მოკლედ კვლავ IE :D ნუ რას ვიზამთ რეალობა ასეთია :P

ტეგები: , ,

IE8 – ფინალური ვერსია გამოვიდა

IE8 როგორც იქნა გვეღირსა და გამოვიდა IE8 – ს ფინალური ვერსია.

მიუხედავად იმისა რომ ბრაუზერების ვენდორებმა ძალიან გაგვანებივრეს ბოლო თვეების მანძილზე, ეს ინფორმაცია გაცილებით სასიხარულო და მნიშნველოვანი იყო ჩემთვის. რატომ? იმიტომ რომ დღესდღეობით IE6 და IE7 ორი გამორჩეულად ჩამორჩენილი ბრაუზერია რომლებსაც ბაზრის 67% უკავიათ ჯამში. იმედი მაქვს რომ IE8 რომელიც გაცილებით განვითარებულია მის ორ წინამორბედზე თუნდაც IE6 – ის სიკვდილს შეუწყობს ხელს. საბოლოო მომხმარებლისთვის შესაძლებელია ამას არსებითი მნიშნველობა არ აქვს, მაგრამ ჩემთვის(და არა მარტო) როგორც პროფესიონალისთვის ეს ძალიან ძალიან ძალიან მნიშვნელოვანია :)

მაშ ასე გადმოწერეთ და გაავრცელეთ რაც შეიძლება ჩქარა აიძულეთ ყველა IE – ს მომხმარებელს რომ ეს განახლება რაც შეიძლება სწრაფად გააკეთოს, ამითი ყველა დავაჩქარებთ IE6 – ის საბოლოო გარდაცვალების პროცესს :D

ტეგები:

საინტერესო JavaScript ტესტი meebo.com – ზე

ეხლახანს meebo.com – ზე შევიარე, და რატომღაც ვაკანსიების განყოფილებას გადავხედე, დამაინტერესა რა პოზიციებზე აქვს ვაკანსიები ამ კომპანიას… ერთერთი აღმოჩნდა javascript engineer (javascript ninja) და რატომღაც გადავხედე :P

პოსტში, ვაკანსიის აღწერის გარდა მითითებულია რამდენიმე JavaScript – თან დაკავშირებული შეკითხვა, და შევეცადე პასუხები გამეცა, ჩემის აზრით ეს დაგაინტერესებთ სრულად »

ტეგები: ,

IE6: მეხსიერების მენეჯმენტი და საინტერესო გამოსავალი

ამ ბოლო დროს საკმაოდ ბევრს ვმუშაობა IE6 – ის მეხსიერებასთან დაკავშირებულ პრობლემებზე ე.წ. “memory leaks”. გამოცდილი JavaScript(უფრო სწორად JScript IE – ს კონტექსტში) დეველოპერებისათვის ეს პრობლემა უცხო არ არის. იმაზე ლაპარაკი თუ რატომ არსებობს ეს პრობლემა შორს წაგვიყვანს, ამიტომ კონკრეტული პრობლემის აღწერითა და მოძებნილი გამოსავალით შემოვიფარგლები.

მიუხედავად იმისა, რომ მეხსიერებასთან დაკავშირებული გაუგებრობების თავიდან ასაცილებლად არსებობს გარკვეული წესები რომლებიც აუცილებლად უნდა დავიცვათ, მაინც ჩემის აზრით ძალიან უცნაურ პრობლემას და შესაბამისად გამოსავალს წავაწყდი.

ჩემი ამოცანა იყო გამეკეთებინა ისეთი ტეგი, რომელზეც მაუსით დაწკაპუნებისას იგი გარდაიქმნებოდა ტექსტურ ველად, რათა შესაძლებელი გამხდარიყო ამ ტეგის შიგთავსის რედაქტირება (იხ. მაგალითი). სრულად »

ტეგები: ,

JavaScript ფაილების ჩატვირთვა საჭიროების მიხედვით

თანამედროვე ე.წ. RIA ვებ აპლიკაციებში, კლიენტის მხარეს განსაკუთრებული და საპასუხისმგებლო როლი აკისრია. სწორედ კლიენტის მხარეს იყრის თავს უამრავი CSS/JavaScript და სხვადასხვა გრაფიკული ელემენტები. RIA ტიპისი სისტემებში JavaScript – ს განსაკუთრებული როლი უჭირავს, რადგან სწორედ მისი მეშვეობით მიიღწევა აპლიკაციის განსაკუთრებული და მიმზიდველი ინტერქატიულობა. რაც უფრო მეტად არის დატვირთული მსგავსი ტიპის ელემენტებით აპლიკაცია მით უფრო მეტ რესურსს საჭიროებს იგი.

ერთი შეხედვით ამ ტიპის რესურსები(იგულისხმება ფაილების რაოდენობა, ზომა და ა.შ.) არ უნდა იწვედნენ განსაკუთრებულ სირთულეს, არც ჩატვირთვისა და არც სისწრაფის მიხედვით… თუმცა ეს მხოლოდ ერთი შეხედვით ჩანს ასე.

Yahoo! – ს ინჟინრებმა საკმაოდ საფუძვლიანი კვლევა ჩაატარეს ამ თემასთან დაკავშირებით და აღმოჩნდა რომ სერვერის გადატვირთვას სწორედ, დოკუმენტში ჭარბად გამოყენებული მსგავსი ელემენტები იწვევენ. გარდა სერვერის დატვირთვისა ეს თავისთავად ცხადია უარყოფითად აისახება თავად აპლიკაციის მომხმარებლებზე(ჩატვირთვის სისწრაფე, კოდის შესრულების/ინტერპრეტაციის დრო). სრულად »

ტეგები: , ,

IE8 Beta: M$ – ის ნაბიჯი წინ!

images_ie8betalogo.gif

გუშინ ჩემთვის ცნობილი გახდა რომ M$ – მა გამოუშვა IE8 Beta ვერსია, რომლის გადმოწერა შესაძლებელია ამ მისამართიდან.

სიმართლე ითქვას ძალიან გამეხარდა, მიუხედავად იმისა რომ დღესდღეობით არსებულ ბრაუზერებს შორის დომინირებენ IE6(სრული საძაგლობა) და IE7(შედარებით ნაკლები საძაგლობა), და მათ აღმოფხვრას წლები დასჭირდება მაინც ძალიან სასიხარულოა M$ – ის ასეთი პროგრესული ნაბიჯი.

მითითებულ ბმულებზე შეგიძლიათ ნახოთ თუ რა განახლებებია ამ ბრაუზერში, თუმცა გირჩევთ John Resig – ის დეტაულური მიმოხილვის წაკითხვას. სრულად »

ტეგები: ,

IE vs W3C event handling

ივენთები საკმაოდ პრობლემატური საკითხია თანამედროვე JavaScript პროგრამირებაში, რაც ცალსახად გამოწვეულია ყველასათვის კარგად ცნობილი და “საყვარელი” InternetExplorer – ის გამო. პრინციპში ძალიან ცოტაა ისეთი შემთხვევები როდესაც ამ პრობლემაზე გვერდის ავლა არ შეიძლება მარტივად, თუმცა ასევე არსებობს შემთხვევები როდესაც ეს არათავსებოდა ძალიან არასასიამოვნოდ იჩენს ხოლმე თავს.

მიუხედავად იმისა, რომ, W3C – ს მიერ საკმაოდ მკაფიოდ არის ჩამოყალიბებული ივენთ მენეჯმენტის მოდელი, IE როგორც სხვა, ასევე ამ შემთხვევაშიც მოწოდების სიმაღლეზეა და თავის განსაკუთრებულ და “უფრო სწორ” მიდგომას გვთავაზობს, რაც საბოლოო ჯამში იწვევს ორმაგი(მინიმუმ) კოდის წერის აუცილებლობას. სრულად »

ტეგები: ,

IE incomplete DOM support…

ამჯერად ყურადღებას შევაჩერებ DOM ელემენტის hasAttribute მეთოდზე. ამ მეთოდის სახელი საკმაოდ თვითდოკუმენტირებულია და ადვილი მისახვედრია რისთვისაც გამოიყენება.

ზუსტი განმარტება:

The hasAttribute() method returns TRUE if the current element node has the attribute specified by name, and FALSE otherwise.

მაგრამ IE – ში DOM ელემენტს არ გააჩნია ეს შედარებით იშვიათად გამოყენებადი მაგრამ ძალიან სასარგებლო მეთოდი. თუმცა არსებობს სხვა საშუალება ამ ბრაუზერისათვის რომლის მეშვეობითაც ადვილად ავიცილებთ თავიდან ამ DOM – ის არასრული მხარდაჭერით გამოწვეულ პრობლემას. სრულად »

ტეგები: , ,

javascript+xpath+IE… სრული ფიასკო :(

აი მერე იტყვიან კარგი ბრაუზერია და რატომ აგინებო :( როგორ არ უნდა ვიგინო? რაღაცაში დამჭირდა xpath – ის სრული მხარდაჭერა HTML დოკუმენტების დასამუშავებლად… ვიწვალე დავწერე გავაკეთე ყველაფერი… მაგრამ რად გინდა? სულსწრაფობა მწარედ და ძვირად დამიჯდა…. ჩემი დაწერილი კოდი არ მუშაობს სრულ იდიოტთა მიერ შექმნილ IE – ში :( მათ შორის “უძალიან მაგრესია IE7, ტაბებიც კი აქვს” ბრაუზერშიც :(

აი რაზე უნდა ელაპარაკო ამ წყეული IE – ს ვენდორს? რით ვერ გამოფხიზლდნენ და რით ვერ გამოიღვიძეს?????

არ ვიცი… როდესმე რამე ეშველება თუ არა ამ სატანის გამოგონებას… ალბათ არა :(

მოკლედ ყველა ბრაუზერში მუშაობს ასეთი რამ:

[javascript]
var item, els = [], iterator = document.evaluate(‘//div/p[@class="some-class-name"]‘ document, null, 0, null);
while (item = iterator.iterateNext()) {
els.push(item);
}
[/javascript]

ალბათ კოდიდან მიხვდებით რაც ხდება… არ მაქვს დეტალების ახსნის თავი :(

უბედურება ის არის რომ სხვა დანარჩენ ბრაუზერებში სადაც კი ეს კოდი გავტესტე ნეიტივად არის document.evaluate მეთოდი… გადასცემ xpath გამოსახულებას და დაგიბრუნებს სასურველ ელემენტებს… აკეთე რაც გინდა და რაც გაგეხარდება… მაგრამ… მაგრამ IE – ს საერთოდ არ შეუძლია HTML – სთან ამ გზით მუშაობა…

ვეძებე.. თანაც ბევრი ვეძებე… და რას მივაგენი? :( აი ამას -> http://glazkov.com/blog/html-xpath-project

ვინმე გლაზკოვის მიერ დაწერილ იმპლემენტაციას… რომელიც იწონის ძალიან ბევრს და ძალიან ნელია :( არადა მიხაროდა მთელი ამოცანა 1 კილობაიტში ჩავტიეთქო :(

არავინ თქვას რომ ამ ბრაუზერს არსებობის უფლება აქვს!!!

ტეგები: ,