konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Napisalismy jakis prosty webowy widget, ktory pobiera dane z waszej strony, wyswietla jakies wasze newsy itd. Ale ten wlasnie widget ma mieszkac na obcych stronach. Przygotowaliscie JS, htmla, CSS. Wszystko tak by potencjalny uzytkownik zlapal, zrobil COPY / PASTE kodu HTML i bedzie smigac. Jakis tam link do zewnetrznego CSSa i JSa ktory mieszka na waszej www.
Widget jakos tam wygladam przyciski, tla, teksty, hovery, colorki itd....

Widget mieszka na obcej stronie, ktory ma tone CSSow i zdarzaja sie kwiatki gdzie jakis baran np zrobi by wszystkie <ul> mialy dodatkowy line-heigh, albo <div> byl zawsze text-align:center... <h1> mial 500px a <a> byl rozowy... ;) Oczywiscie wszystkie takie kwiatki wpasowuja sie w wasz kod czasami psujac jakies eleenty dizajnu. Czlowiek nie jest w stanie przewidziec wszystkiego... niestety.

Zastanawiam sie jakie mielibyscie podejscie by miec pewnosc ze ZAWSZE wasz widget wyswietli sie tak jak zostalo zaplanowane (pomijajac momenty kiedy wlasciciel strony pobierze waszego CSS, zmodyfikuje i bedzie do niego linkowac - jego sprawa). Macie jakies ciekawe pomysly na to?

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Chamski i brutalny reset wszystkich stylów w kontenerze widgeta.

Temat: Niezalezny CSS w widgetach, na obcych stronach

XHR dla ubogich iframe, jeżeli twój kod będzie w iframe to style na stronię zewnętrznej nie dadzą rady

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Narazie widze dwie opcje o ktorych myslalem, aczkolwiek nie jest to cos, co bym chcial zastosowac.
Widget addthis, facebook i pewnie kilka innych uzywaja iframe'ow.

Temat: Niezalezny CSS w widgetach, na obcych stronach

Może ci pomoże lektura
https://plus.google.com/u/0/115060278409766341143/posts...

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Michał Szaniewski:
Może ci pomoże lektura
https://plus.google.com/u/0/115060278409766341143/posts...

Ciekawe, ale absolutnie nie pomaga w tym temacie :)
ps.. nie wiedzialem ze IE ma limit selectorow na stylesheet ;)

Temat: Niezalezny CSS w widgetach, na obcych stronach

bo kto tyle wpisuje :P

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Chyba najlepsze rozwiązanie to iframe, ponieważ ciężko będzie resetować wszystkie style - mamy przecież specyficzność selektorów czy !important (sic!).

BTW - IE ma też limit (31) ładowanych stylesheetów w tagach <link> czy <style> :)

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Michał Szaniewski:
bo kto tyle wpisuje :P

Jeden plik, z 4000 styli, zrobione recznie to faktycznie masakra, ale kiedy plik ze stylami jest czescia procesu wrzucania plikow na serwery produkcyjne, to juz ma to znaczenie, kiedy w tym wlasnie procesie, sprawdzamy rozne moduly, te ktore sa integralna czescia strony i laczymy kilka roznych CSS w jeden plik ;) Dla mnie to 4096 akurat okazalo sie bardzo istotna informacja (nie problematyczna poki co) ;)
Konrad Karpieszuk

Konrad Karpieszuk WordPress Plugin
Compatibility
Assurance for WPML

Temat: Niezalezny CSS w widgetach, na obcych stronach

css3 ma atrybut scoped dla elementu style, co zawęża oddziaływanie stylów do tylko jednego elementu, np widzetu. w polaczeniu z css reset w takim stylu osiagniesz wlasnie to co chcesz

http://html5doctor.com/the-scoped-attribute/

nie wiem tylko jak jest ze wsparciem tego w browserach (wg artykulu zaden nie wspiera, ale arykul ma swoich kilka miesiecy)

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Konrad Karpieszuk:

slowo klucz "css3" - IE6 kiepsko wspiera takie cuda ;)

Do resetow, znalazlem cos takiego: https://github.com/premasagar/cleanslate
Niby ladnie wszystko zeruje i robi ustawia jako domyslne, oczywiscie mozna wymusic swoje wg. uznania, aczkolwiek wizja tony !important mnie przeraza ;)Andrzej Winnicki edytował(a) ten post dnia 12.07.12 o godzinie 11:32

Temat: Niezalezny CSS w widgetach, na obcych stronach

Trochę marudzisz :)
Zapewne zostały ci star nawyk jak nie używaj iframe czy !important. Bo jak zaczynasz naukę to jest to odradzane w fachowej literaturze ;P . Natomiast jak już poznałeś zasady to możesz je naginać/łamać. Jednak moim zdaniem powinieneś zostać przy iframe bo działa wszędzie i zapewni ci zgodności wstecz na wiele wyższym poziomie niż reste.Michał Szaniewski edytował(a) ten post dnia 12.07.12 o godzinie 15:30

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Michał Szaniewski:
!important jest problematyczny, niezgodny z moimi wierzaniami i bogami, i stwarza wiecej problemow niz jest wart. Uzywam go tylko i wylacznie, kiedy juz naprawde nie mam wyjscia. Wedlug mnie 99% ludzi uzywa tego tylko dlatego ze sa leniwi albo brakuje im podstawowej wiedzy ;)

iframe wydaje sie OK, aczkolwiek wiem ze zaczynaja sie problemy jesli twoj widget zmienia swoje rozmiary dynamicznie. Uzycie iframe to bylby wlasnie moj "stary nawyk", nowy podpowiada NIE :)

Sprobuje jeszcze napisac swoj CSS czyszczacy wiekszosc styli. Nie bedzie w 100% skuteczny, ale bede zadowolony jak bedzie dzialac w 90% ;) Staram sie ominac iframe'a bo to oznaczaloby duzo pracy... ale jak opcja numer 1 padnie... iframe bedzie moim psiapsielem...

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Andrzej Winnicki:

slowo klucz "css3" - IE6 kiepsko wspiera takie cuda ;)

Tutaj problemem nie jest IE6. Scoped bangla obecnie chyba tylko w webkitach (safari i mobile'a nie liczę) a i tam trzeba włączyć obsługę we flagach.

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

ja bym zrobił tak, żeby style były generowane przez javasciript "inline".
Wtedy miałyby większy priorytet niż te które są pisane w arkuszach.
Łukasz Stępa

Łukasz Stępa Front-End developer

Temat: Niezalezny CSS w widgetach, na obcych stronach

popraw mnie jeśli się myle, ale jak dasz jakiś unikalny id na root'a tego widgeta, i dasz w cssie na każdy element style tak jak mają dokładnie wyglądać, razem z width: auto czy jakąs szerokością stałą na divy w tym widgetcie, czy text-align, line-height itp na elementy <a> i inne które występują w widgecie, to nadpiszą one wszystkie style ogólne z danej strony jeśli takowe są. A w razie jak np szerokość widgeta miała by się zmieniać dynamicznie, to inline'owy js na jakiegoś diva i finito.

Trochę to naokoło i na pewno o tym też myslałeś, ale wydaje mi się to lepsze niż !important. Jedyna zagwozdka to taka na jakie elementy dać jakie style żeby nie musieć dawać ich na wszystkie :) bo nie przypuszczam żeby ktoś dał na stronie na wszystkie <a> position: absolute czy jakieś podobne kwiatki.

Albo jakieś ogólne ustawienie/zresetowanie styli na wszystkie elementy w widgecie #widget * { style }

Temat: Niezalezny CSS w widgetach, na obcych stronach

@Piotr, !importantn (http://jsfiddle.net/4SvPY/) ważniejsze po za tym ile by to ważyło jaki by się robił muł
@Łukasz jeżeli dobrze cię rozumiem to nie masz racji i to z dwóch powodów 1.) jak nazwać uniwersalnie widget tak aby przypadkiem już nie występował gdzieś na jakiejś stronie 2.) j.w. http://jsfiddle.net/4SvPY/1/

Trzeba pamiętać że ludzie maję różne problemy z css-em i najczęściej rozwiązują je przy pomocy !importantn

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Michał Szaniewski:
@Piotr, !importantn (http://jsfiddle.net/4SvPY/) ważniejsze po za tym ile by to ważyło jaki by się robił muł
@Łukasz jeżeli dobrze cię rozumiem to nie masz racji i to z dwóch powodów 1.) jak nazwać uniwersalnie widget tak aby przypadkiem już nie występował gdzieś na jakiejś stronie 2.) j.w. http://jsfiddle.net/4SvPY/1/

Trzeba pamiętać że ludzie maję różne problemy z css-em i najczęściej rozwiązują je przy pomocy !importantn

Masz rację że important ważniejsze, ale prawdą jest też, że jeśli ktoś chce na siłe zmienić style jakiegoś widgetu to i tak zmieni. Ja osobiście zastosowałbym "inline" ponieważ jest większe prawdopodobieństwo że style nie zostaną nadpisane, niżeli jakby to był arkusz zewnetrzny.

Co do wagi to zależy od wielkości widgetu. Jeśli jest nieduży to jest to mało istotne. Poza tym czas ładowania widgetu to nie tylko style i struktura html. Jeśli mi widget ładowałby się wolno to zerknąłbym na to co robi javascript oprócz wyświetlenia htmla i tam bym szukał rozwiązania.

Kolejną rzeczą, nie wiem co masz na myśli mówiąc że przy stosowaniu inline w tym przypadku, robiłby się muł. Jeśli chodziło Ci o czytelność to moim zdaniem to nie ma znaczenia. Osoby które faktycznie korzystają z widgetu nie mają takiej wrażliwości że zaglądają w kod html i patrzą jak to jest zrobione. A osoby które spojrzą w kod i stwierdzą że zrobiłyby to lepiej.. no coż, facebook też daje możliwość pobrania "like" w wersji iframe, która w środku generuje htmla ze stylami "inline".

Co do pomysłu Łukasza, to nazwa uniwersalna widgetu nie byłaby problemem, można by ją generować automatycznie przez php, czy nawet javascript.
A unikalny identyfikator nie zawsze jest najważniejszy. Pomijając "important!" ważna jest dokładność scieżki. Im bardziej dokładna tym bardziej styl jest ważniejszy.
np: body #wrapper #widgets #widget1.widget jest ważniejsze niż #widget1.widget

Pytanie tylko jest takie. Czy jest to faktycznie aż takie istotne? Czy możemy poświecić tyle czasu żeby myśleć nad uniwersalnym rozwiązaniem? I jeśli już wymyślimy, to ile procent osób będzie próbowało to obejść? Moim zdaniem mało.
Jeśli ktoś chce zmienić style to zmieni. Więc trzeba sobie zadać pytanie czy głowienie się nad tym aż w takim stopniu jest warte świeczki?Piotr Pażuchowski edytował(a) ten post dnia 22.07.12 o godzinie 19:27

konto usunięte

Temat: Niezalezny CSS w widgetach, na obcych stronach

Piotr Pażuchowski:
Masz rację że important ważniejsze, ale prawdą jest też, że jeśli ktoś chce na siłe zmienić style jakiegoś widgetu to i tak zmieni. Ja osobiście zastosowałbym "inline" ponieważ jest większe prawdopodobieństwo że style nie zostaną nadpisane, niżeli jakby to był arkusz zewnetrzny.

Jeden widget przychodzi w 3 designach (kazdy w dwoch skinach - light i dark), do tego mozesz zapomniec o :hover i innych takich tam, wiec inline nie rozwiaze tutaj problemu. niemozliwe sie stanie kontrolowanie tego i jakiekolwiek updaty beda bardzo upierdliwe. Zmusiloby mnie to takze do ogarniecia 3 roznych designow.
Jesli nie ta droga, to dynamicznie wsadzane inline z JSa ale to brzmi jak jeszcze gorszy pomysl.
Co do wagi to zależy od wielkości widgetu. Jeśli jest nieduży to jest to mało istotne. Poza tym czas ładowania widgetu to nie tylko style i struktura html. Jeśli mi widget ładowałby się wolno to zerknąłbym na to co robi javascript oprócz wyświetlenia htmla i tam bym szukał rozwiązania.

Laduje sie szybko, ladowanie to nie problem. W chwili obecnej jedyna rzecz ktora urosla do wiekszych rozmiarow to tlumaczenia (15 jezykow) ale rozwiazanie na to juz mam - wczesniej nie bylo po prostu potrzebne :)

----

Ostatnio chlopaki poprosili mnie o dopisanie event trackingu dla GA i Omniture + musze dodac pare rzeczy + rozdzielic tlumaczenia + przepisac pare duperelek by zrobic z tego bezbolesny modul.
Tak wiec mam 2 tygodnie zaplanowane jako inwestycja w upgrade. Dam wam znac jak rozwiazalem problem tego cholernego CSSa. Chwilowo nadal jestem za pobierznym resetem wiekszosci styli. Szczerze mowiac nie znalazlem za wiele problemow z obcymi stronkami, ale lubie jak wszystko jest idealnie ;)Andrzej Winnicki edytował(a) ten post dnia 22.07.12 o godzinie 19:26
Łukasz Stępa

Łukasz Stępa Front-End developer

Temat: Niezalezny CSS w widgetach, na obcych stronach

@Michał myśle że dająć jakąś 3 członową klasę z nazwą widgeta zmniejszamy szansę na to aby identyczna klasa znalazła się gdzieś na stronie. Lub też jeśli jest taka możliwość, napisać skrypt który sprawdzałby na wstępie czy dana klasa występuje na danej stronie, jeśli nie występuje to si, jeśli występuje to wygenerować inną i sprawdzić. Wtedy szansa na to że druga unikalna także będzie występować jest jeszcze niższa.

ad 2. No cóż, przyjąłem że nikt o zdrowych zmysłach nie narzuca !important na zwykłe elementy ;) no ale masz racje, nie jesteśmy w stanie przewidzieć czy coś takiego może mieć miejsce, a w zasadzie gdzieś na jakieś stronie pewnie coś takiego jest, więc wtedy chyba jedyna opcja to iframe, albo reset również z !important, ale to już wtedy będą wjeżdzać same !important więc w to już bym się nie bawił.

Następna dyskusja:

CSS Frameworks




Wyślij zaproszenie do