пропозиції роботи
Wypowiedzi
-
Jakub Szlenk:
Zakładam, że szanowny kolega wie, że zamknięto projekt XHTML2 głównie ze względu na brak wsparcia ze strony firmy MS w IE dla XHTMLa. Bo implementacja innych języków zgodnych z XML w pozostałych przeglądarkach wolno lecz konsekwentnie wciąż się rozwija.
moze to byc jedna z przyczyn, ale z tego co kojarze, W3C zamknelo grupe XHTML2 zeby przeniesc zasoby do HTML5 i tym samym jednoznacznie okreslic stanowisko W3C co do przyszlosci HTML.
a implementacja innych jezykow XML sie rozwija, owszem. ale wydaje mi sie, ze duzo mniej to zmieni, niz HTML5 - i duzo mniej osob jest zainteresowanych tym rozwojem. dlatego dzieje sie to w takim tempie, w jakim sie dzieje.
XML jest dziś podstawą przetwarzania danych po stronie servera oraz technologii Ajax po stronie klienta. To jasne. Po przez przetwarzanie XML często uzyskujemy XHTML na wyjściu ze względu na łatwość użycia transformat między nimi oraz użyciu interfejsu DOM. Uważam, że to jest główna siła tego języka w praktyce.
mi sie jednak wydaje, ze obecne tendencje to zwrot w kierunku JSON(+JSONP). imho to dobrze - taki format jest jasniejszy, lzejszy, przyjemniejszy. chociaz zapewne w niektorych miejscach nieadekwatny.
swoją drogą - można połączyć elegancką logikę z eleganckim kodem HTML. jest >> to pracochłonne i zazwyczaj oznacza rezygnację z gotowych rozwiązań
(albo ich modyfikację), ale jest jak najbardziej wykonalne.True
Oczywiście, że tak. Choć wydaje mi się to dość powszechnie oczywiste.
odnosilem sie do Twojej wypowiedzi z innego posta: "Zdecydowana większość szablonów CMS-ów nie przejdzie przez validator. Może dlatego właśnie czuje do nich niechęć, gdyż zawsze była dla Mnie ważniejsza logika niż estetyka aplikacji www."
reszte naszej dyskusji wycinam, bo wlasciwie wynikala ze wzajemnego niezrozumienia. ;)
Pzdr.Szymon Piłkowski edytował(a) ten post dnia 05.08.10 o godzinie 15:10 -
Jakub Szlenk:
Sensu stricte była już o tym dyskusja. Wielcy webowi guru są zgodni że XHTML wciąż będzie stosowany w sieci bo znajduje praktyczne zastosowanie. Na dowód w IE9 wprowadzono (wreszcie!!!) parser dla XHTML.
czy rzeczywiście?
główną siłą XHTML miała być łatwość integracji z innymi językami o składni XML-owej - MathML itp. - dużo znasz stron/aplikacji, które faktycznie korzystają z tych możliwości?
obecna popularność XHTML to tylko efekt "hype" - 99% stron mogłoby równie dobrze korzystać z HTML 4.01 i być przy tym równie dostępna/elegancka pod względem kodu/zgodna ze standardami.
Po prostu tagi forsujące na stronach Audio i Video to nie wszystko.
nie jestem pewien, czy dobrze zrozumiałem Twoją wypowiedź, ale jeśli sprowadzasz html5 do audio/video albo twierdzisz, że te tagi to główne nowości w html5 - mylisz się. :)
swoją drogą - można połączyć elegancką logikę z eleganckim kodem HTML. jest to pracochłonne i zazwyczaj oznacza rezygnację z gotowych rozwiązań (albo ich modyfikację), ale jest jak najbardziej wykonalne. -
Piotr Lewandowski:
Dokładnie... Jak dla mnie to wygląda tak, że konferencja jest organizowana głównie po to, żeby na niej zarobić, a dopiero potem żeby coś tam promować...
śmiała teoria. chciałbyś ją może poprzeć jakimiś konkretami? ;)
z raczej pewnego źródła wiem, że organizatorzy za bardzo na tej konferencji nie zarobią - na pewno nie tyle, żeby zwróciła się włożona praca ;)
drogo? no, w przeliczeniu na PLN i polskie zarobki to trochę piw jest. ale po porównaniu ceny+line-upu do innych konferencji front-endowych w europie (fronteers €375, jsconf €530) wyszło mi, że nie ma bardziej opłacalnej. zwłaszcza po odliczeniu transportu. ;)
tak mi się wydaje, że konferencje zazwyczaj z natury są przewidziane dla osób, którym wstęp zasponsoruje firma albo tych, którym zależy na tyle, żeby zapłacić. -
Szymon Piłkowski edytował(a) ten post dnia 02.08.10 o godzinie 16:49
$("#add_photo").click(function() {
$("#up_photos").append('<input type="text" />');
});
-
a co Ty probujesz zrobic? jesli dobrze rozumiem, to:
- po pierwsze, to "input" a nie "<input>" - chyba ze to jakis feature sizzle'a ktorego nie znam.
- po drugie, jesli probujesz wybrac element o atrybucie "type" rownym "text", to nie powinienes uzywac metody attr, tylko okreslic to w selektorze (ew. uzyc metody filter). (attr sluzy do pobierania/ustawiania atrybutow)
- po trzecie, cache'owanie elementow DOM nie ma sensu jesli nie odwolujesz sie do nich wiecej niz raz.
czyli w skrocie powinno byc jakos tak:
$("#add_photo").click(function() {
$("#up_photos").append( $("input[type=text]") );
});
-
Andrzej Winnicki:
ps. glupie ze replace() nie moze uzyc stringa i po prostu go zastapic wielokrotnie, musi miec regexa.
"foobarbar".replace("bar", "bas", "gi");
odwołuję tym samym swojego własnego posta powyżej ;-)
chociaż właściwie ECMA-262 o tym nie wspomina, więc może to być jakiś non-standard feature w Gecko (nie mam w tej chwili jak sprawdzić w innych przeglądarkach).
wyrywek z ECMA:
Szymon Piłkowski edytował(a) ten post dnia 29.07.10 o godzinie 02:05
If searchValue is a regular expression (an object whose [[Class]] internal property is "RegExp"), do the following: If searchValue.global is false, then search string for the first match of the regular expression searchValue. If searchValue.global is true, then search string for all matches of the regular expression searchValue. Do the search in the same manner as in String.prototype.match, including the update of searchValue.lastIndex. Let m be the number of left capturing parentheses in searchValue (using NcapturingParens as specified in 15.10.2.1).
If searchValue is not a regular expression, let searchString be ToString(searchValue) and search string for the first occurrence of searchString. Let m be 0.
-
alert(('ala ma asa').replace('asa','psa'));
tyle, że przy użyciu stringa nie możemy ustawić parametru global. czyli tylko pierwsze wystąpienie będzie zamienione.
EDIT: a jednak może. sprostowanie w moim następnym poście ;)Szymon Piłkowski edytował(a) ten post dnia 29.07.10 o godzinie 01:59 -
gratuluje checi do pracy ;) nie wiem czy sie przyjmie, jest tego duzo na rynku.
anyway, sugestia: prosze, blagam; plugin moze byc polski, ale poslugiwanie polskimi nazwami zmiennych/fkcji/obiektow itp w kodzie w to naprawde fatalna sprawa. zwlaszcza uzywanie stringow "tak"/"nie" zamiast booleanow true/false :D -
wedle specyfikacji, mógłbyś próbować dołączać specjalny CSS z parametrem media="tv", ale czy i w jakich przeglądarkach to działa - szczerze mówiąc nie wiem.
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Opinie i oceny stron www/grafik
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy Opinie i oceny stron www/grafik
-
Iwona Lalik:
Jeśli miałabym próbować w JS pisać coś takiego spróbowałabym użyć tej bibloteczki http://raphaeljs.com/
nie ma mowy. raphael bazuje na svg, svg nie jest odpowiednią technologią do gier z dynamiczną animacją m.in. ze względu na niską wydajność. poza tym raphael o ile się orientuję jest stworzony do prezentacji danych.
polecałbym canvas, ewentualnie DOM + CSS transforms API w zależności od wymagań. istnieją gotowe biblioteki, ale to wszystko jest dość nowym tematem w JS (i dlatego tak interesującym)
jeśli chodzi Ci po prostu o wyprodukowanie tej gry i nie preferujesz żadnej technologii, to wydaje mi się niestety że flash będzie tu rozwiązaniem tańszym i bezpieczniejszym.
jeśli zależy Ci na tym, żeby było to zrobione w JS (co samo w sobie byłoby niezłą reklamą gry) to zachęcam do odezwania się do mnie na priv i opisania czego dokładnie oczekujesz - temat gier w JavaScripcie to coś, co leży ostatnio w centrum moich zainteresowań :) nie gwarantuję, że będę w stanie Ci pomóc, ale chętnie przynajmniej zapoznam się z tematem.Szymon Piłkowski edytował(a) ten post dnia 21.07.10 o godzinie 23:49 -
-
What's the Frequency, Kenneth?
- 17.07.2010, 07:20
-
Piotr Lewandowski:
A o graceful degradation kolega słyszał ? nigdzie nie napisałem, że IE6 ma wyświetlać wszystko DOKŁADNIE tak samo jak najnowsze browsery... Ważne, żeby braki IE nie powodowały wyje***ia w kosmos całej aplikacji... Bo tak właśnie tworzy większość developerów...
czyli twierdzisz, że niedociągnięcia IE6 nie przeszkadzają Ci, pod warunkiem że możesz je częściowo olać (== obsłużyć w mniej fajny sposób)? ;)
ja piszę o w pełni działającej, stabilnej i wydajnej aplikacji.
Wszystko da się albo naprawić albo skutecznie ominąć... a może nie ?
prawda. przy czym naprawianie i omijanie oraz wykrywanie wymaga dodatkowego czasu, a czasem poświęcania pewnych funkcjnalności/eleganckich rozwiązań. oraz psucia kodu hackami/ifami/conditionalami/dodatkowymi includami dla IE, albo robienia rzeczy na około. w obu przypadkach tracimy i czas, i jakość.
Wszystkie - na pewno nie - najpopularniejsze ? Owszem... Zwłaszcza że jest ich raptem kilka...
prawda. ale tak dziwnie się składa że to te mniej popularne są bardziej upierdliwe ;)
edit: Taka zagadka: Co to jest ? Wisi na biurku i piszczy "nie da się, nie da się" ?? Dupa, nie front-endowiec...
prawda. ale też nigdzie nie piszę że się nie da - piszę, że wymaga to dodatkowej pracy. -
Piotr Lewandowski:
"nie ma hajsu na ie6" ?? no tak... pamiętanie o pisaniu poprawnego kodu kosztuje w pip kasy... powtarzałem to już wielokrotnie na GL: pisanie poprawnego kodu działającego w IE6 nie wymaga ani dodatkowego czasu ani kasy - wystarczy pamiętać CO i JAK pisać żeby działało.. Tylko że większość front-endowców to lazy bastardy :D
ee.. bzdura. samo radzenie sobie z błędami w renderowaniu stron kiedy tworzymy jakiś pojedyńczy portal - to rzeczywiście nie jest problem, można się tego nauczyć. natomiast brak dostępu wszystkich fajnych nowych selektorów oraz JScript sprawiają, że developowanie pod IE6 jest naprawdę, naprawdę kosztowne. po prostu to, co robię, mógłbym zrobić 10 razy szybciej+lepiej, gdybym mógł użyć czegoś, czego użyć nie mogę ze względu na IE. dodaj do tego kwestie związane z cache'owaniem, nagłowkami i kodowaniami, niemożność użycia poprawnego content-type, problemy z pnga, formularzami, itp.
popatrz sobie w kod takiego jQuery albo tinyMCE i zobacz ile pracy wymaga obsługa IE6.
i nie, nie wierzę, żeby ktoś znał na pamięć wszystkie bugi IE i umiał przewidzieć każde dziwne zachowanie lub memory leak. -
Paweł Jędrasiewicz:
Próbowałem rozwiązać to następująco: program czyta zmienną uzależnioną od języka, która ma się pojawić na przycisku. Liczy długość stringa i mnoży x10px, które to później są dopisane do parametru width: <dlugosc_zmiennej x 10>px;
zrób ukryty element o takich samych ustawieniach fonta co Twój niby-browse-button, daj mu display: inline i width: auto, wsadź do środka ten sam tekst, który chcesz mieć w swoich buttonie. następnie pobierz wymiary ukrytego elementu, usuń go, a wymiary nadaj swojemu buttonowi. ;) -
nie podpinaj zdarzenia pod niewidoczną kontrolkę, zamiast tego spróbuj podpiąć je pod element, który ją zasłania i "udaje" (znajdz go firebugiem).
-
a dlaczego nie? link który wkleiłeś nie ma żadnego demo page, więc nie bardzo mogłem się firebugiem pobawić. nie działa po prostu podpięte zdarzenie?
osobiście używałem http://www.appelsiini.net/projects/filestyle/demo.html - pluginu jquery. spokojnie do 'przesłaniającego' elementu można bindować zdarzenia.
może zapominasz, że - skoro przykrywasz przycisk czymś innym - to zdarzenia powinieneś podpinać nie do przycisku, tylko do tego, co go przykrywa? :) -
Z tego co kojarzę, 2022 to nie tyle data ukończenia specyfikacji html5, tylko przewidywany moment w którym przynajmniej 2 przeglądarki będą obsługiwały 100% rekomendacji W3C. To coś całkiem innego.
Odnośnie ostatniej polityki Adobe: a) adobe czynnie bierze udział w rozwoju html5 i canvasa, b) adobe rozbudowuje dreamweavera o toole do html5, c) adobe uczestniczy w rozwoju WebM.
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
Zaloguj się za pomocą
