W dniu 2011-02-01 07:58, Michał Gancarski pisze:
> On Mon, 31 Jan 2011 18:08:34 +0100, Paweł Piskorz wrote:
>
>>>> Zresztą HTML5 też nie działa,
>>>> wywalenie numerka tego nie naprawi :)
>>>
>>> Ale nie zepsuje.
>>
>> Dokumentacja wiecznie w produkcji = brak standardu.
>
> No to jak dziś :-) Nie ma realnego standardu, z uniwersalną implementacją.

No właśnie, standardy są - implementacja leży. Teraz wchodzimy w model
gdzie standardu nie będzie lub będzie w wielu wersjach - co się stanie z
implementacją?

>> Zaś spece z Googla robią wszystko na odp...l byle zaliczyć kolejne
>> "fjuczery" i wciskają kolejne. Znowu zaczyna się wyścig kto więcej
>> fajnych rzeczy wymyśli i doda do swojej przeglądarki, a za dokumentację
>> robią blogi tych, którzy dane fjuczery dodają do przeglądarek lub je
>> przypadkiem odkryją.
>
> Kurczę ale co w tym jest złego?

Powiedz, że żartujesz? Przecież już to przerabialiśmy - "obsługa"
standardów przez IE długo nie była udokumentowana, trzeba było szukać
"IE cośtam bug" ;)
Teraz GChrome dołączył do grupy "zróbmy to na odp..l" - to nie jest dobre.

> Przecież żeby istniał jakikolwiek postęp,
> musi istnieć rywalizacja i niezależne od siebie eksperymenty.

Rywalizację przeglądarek na polu "standardy zawsze w produkcji" już
przerabialiśmy - nie poszło im to za dobrze, wygrał silnIEjszy ;)
Eksperymenty są pożądane, jak najbardziej - ale nie żeby wszystko było
cały czas jednym wielkim eksperymentem, bo nigdy nie wejdzie do
powszechnego użycia.

> Mamy jednocześnie do
> dyspozycji coraz szerszą, faktycznie obsługiwaną bazę,

eksperymentalnych rzeczy, działających różnie w różnych przeglądarkach.

> a z drugiej szybki rozwój i eksperymenty.

Popatrz na sytuację, kiedyś wszyscy byli w tyle za standardami, teraz
zaczynają je wyprzedzać. Wtedy standardy nie mogły się doczekać
implementacji, teraz implementacje nie doczekają się dokumentacji. Z
jednej skrajności w drugą, a efekt jest ten sam - uboga ilość standardów
dostępnych i obsługiwanych tak samo przez wszystkich (no przynajmniej
przez tych liczących się).

Moim zdaniem W3C poszło lepszą drogą z CSS3 - podzielili dokumentację na
grupy tematyczne i każda ma swój status, dzięki czemu wiadomo co i kiedy
jest skończone, można implementować wybrane grupy a i eksperymentować
się da.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry

W dniu 2011-02-01 07:58, Michał Gancarski pisze:
> No tak, ale XHTML się nie przyjął. Jedno drugiemu nie przeczy, chodziło mi
> tylko i wyłącznie o budowanie frontendów webowych. Co do zastosowania
> XML+XSLT w tym konkteście to się nie wypowiadam - ktoś naprawdę w ten
> sposób generuje strony albo aplikacje webowe?

Oczywiscie, np. moi koledzy i ja :-) (na autorskim frameworku opartym o
JEE).

Dla pehapowcow tez jest zabawka: http://symphony-cms.com/


--
NotBear

do góry

On Tue, 01 Feb 2011 19:33:09 +0100, NotBear wrote:

> W dniu 2011-02-01 07:58, Michał Gancarski pisze:
>> No tak, ale XHTML się nie przyjął. Jedno drugiemu nie przeczy, chodziło mi
>> tylko i wyłącznie o budowanie frontendów webowych. Co do zastosowania
>> XML+XSLT w tym konkteście to się nie wypowiadam - ktoś naprawdę w ten
>> sposób generuje strony albo aplikacje webowe?
>
> Oczywiscie, np. moi koledzy i ja :-) (na autorskim frameworku opartym o
> JEE).

OK ale XSLT służy u Was do generowania front-endu czy do jakichś
przekształceń ważnych jedynie dla samej aplikacji, których wyniki są
niewidoczne dla użytkownika?


> Dla pehapowcow tez jest zabawka: http://symphony-cms.com/

O, zainteresowałeś mnie. Ściągam :-)


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

W dniu 2011-02-01 19:36, Michał Gancarski pisze:
> OK ale XSLT służy u Was do generowania front-endu czy do jakichś
> przekształceń ważnych jedynie dla samej aplikacji, których wyniki są
> niewidoczne dla użytkownika?

System szablonow do frontu HTML, alternatywne formaty, eksporty danych.


--
NotBear

do góry

Dnia Tue, 1 Feb 2011 07:58:58 +0100, Michał Gancarski napisał(a):

> Co do zastosowania
> XML+XSLT w tym konkteście to się nie wypowiadam - ktoś naprawdę w ten
> sposób generuje strony albo aplikacje webowe?

Przez długi czas fotka.pl

> piszemy pod przeglądarki, czy tego chcemy czy nie. Na szczęście konsensus
> co do tego co ma być, a czego nie ma być, jest wśród ich twórców coraz
> szerszy.

... a później przychodzi MS i mówi "a takiego, robimy po swojemu".

> elementów, selektorów, sztuczek, bibliotek itp. Mamy jednocześnie do
> dyspozycji coraz szerszą, faktycznie obsługiwaną bazę, a z drugiej szybki
> rozwój i eksperymenty.

I duży odsetek betonu, który hamuje rozwój przez brak aktualizacji
przeglądarek u siebie. No ale to już jest niezależne od nas.

--
Borys Pogoreło
borys(#)leszno,edu,pl

do góry

On Tue, 1 Feb 2011 20:57:21 +0100, Borys Pogoreło wrote:

> Dnia Tue, 1 Feb 2011 07:58:58 +0100, Michał Gancarski napisał(a):
>
>> Co do zastosowania
>> XML+XSLT w tym konkteście to się nie wypowiadam - ktoś naprawdę w ten
>> sposób generuje strony albo aplikacje webowe?
>
> Przez długi czas fotka.pl

OK.


>> piszemy pod przeglądarki, czy tego chcemy czy nie. Na szczęście konsensus
>> co do tego co ma być, a czego nie ma być, jest wśród ich twórców coraz
>> szerszy.
>
> ... a później przychodzi MS i mówi "a takiego, robimy po swojemu".

Mówił gdy mógł. Każdy będzie mówił gdy będzie mógł - do wypuszczenia
przeglądarki nie jest potrzebny certyfikat W3C. Teraz Microsoft w panice
nadrabia zaległości.


>> elementów, selektorów, sztuczek, bibliotek itp. Mamy jednocześnie do
>> dyspozycji coraz szerszą, faktycznie obsługiwaną bazę, a z drugiej szybki
>> rozwój i eksperymenty.
>
> I duży odsetek betonu, który hamuje rozwój przez brak aktualizacji
> przeglądarek u siebie. No ale to już jest niezależne od nas.

To inny problem :-)


--
Michał Gancarski

Sieeeaaaaaaaaaaa!

do góry

On Tue, 01 Feb 2011 14:01:55 +0100, Paweł Piskorz wrote:

> W dniu 2011-02-01 07:58, Michał Gancarski pisze:
>> On Mon, 31 Jan 2011 18:08:34 +0100, Paweł Piskorz wrote:
>>
>>>>> Zresztą HTML5 też nie działa,
>>>>> wywalenie numerka tego nie naprawi :)
>>>>
>>>> Ale nie zepsuje.
>>>
>>> Dokumentacja wiecznie w produkcji = brak standardu.
>>
>> No to jak dziś :-) Nie ma realnego standardu, z uniwersalną implementacją.
>
> No właśnie, standardy są - implementacja leży. Teraz wchodzimy w model
> gdzie standardu nie będzie lub będzie w wielu wersjach - co się stanie z
> implementacją?

Wcale nie "nie będzie standardu". Zawsze można się odwołać do snapshotu z
W3C, natomiast rzeczywistym standardem będzie konsensus pomiędzy twórcami
przeglądarek, snujący się wokół kierunku wytyczanego przez W3C/WHATWG, na
który to kierunek będą mieli wpływ także dostawcy przeglądarek. Czyli
dokładnie tak jak teraz :-)


>>> Zaś spece z Googla robią wszystko na odp...l byle zaliczyć kolejne
>>> "fjuczery" i wciskają kolejne. Znowu zaczyna się wyścig kto więcej
>>> fajnych rzeczy wymyśli i doda do swojej przeglądarki, a za dokumentację
>>> robią blogi tych, którzy dane fjuczery dodają do przeglądarek lub je
>>> przypadkiem odkryją.
>>
>> Kurczę ale co w tym jest złego?
>
> Powiedz, że żartujesz? Przecież już to przerabialiśmy - "obsługa"
> standardów przez IE długo nie była udokumentowana, trzeba było szukać
> "IE cośtam bug" ;)
> Teraz GChrome dołączył do grupy "zróbmy to na odp..l" - to nie jest dobre.

Mhm, jak dołączył? Póki co widzę co innego - coraz szersza baza możliwości
obsługiwanych w każdej przeglądarce, i to przy otwartej rebelii wobec W3C
(cokolwiek ktokolwiek chciałby powiedzieć na temat WHATG, była to forma
rebelii).


>> Przecież żeby istniał jakikolwiek postęp,
>> musi istnieć rywalizacja i niezależne od siebie eksperymenty.
>
> Rywalizację przeglądarek na polu "standardy zawsze w produkcji" już
> przerabialiśmy - nie poszło im to za dobrze, wygrał silnIEjszy ;)
> Eksperymenty są pożądane, jak najbardziej - ale nie żeby wszystko było
> cały czas jednym wielkim eksperymentem, bo nigdy nie wejdzie do
> powszechnego użycia.

Ej, cały czas to mamy. I IE nie wygrał, zauważ. IE jest co najwyżej
pośmiewiskiem i dopiero dziewiątka ten stan zmieni. Dziś nie ma
silniejszego, mamy cztery silniki konkurujące o wpływy plus n przeglądarek
na nich opartych.


>> Mamy jednocześnie do
>> dyspozycji coraz szerszą, faktycznie obsługiwaną bazę,
>
> eksperymentalnych rzeczy, działających różnie w różnych przeglądarkach.

Tych także. Niemniej mamy też coraz szerszą bazę rzeczy obsługiwanych po
prostu wszędzie. Bez żadnych eksperymentów. OK, nie wszędzie, IE nadgania.
Wraz z dziewiątką przyjdą min. elementy HTML5, media queries czy, hm, rgba
:-).


>> a z drugiej szybki rozwój i eksperymenty.
>
> Popatrz na sytuację, kiedyś wszyscy byli w tyle za standardami, teraz
> zaczynają je wyprzedzać. Wtedy standardy nie mogły się doczekać
> implementacji,
> teraz implementacje nie doczekają się dokumentacji. Z
> jednej skrajności w drugą, a efekt jest ten sam - uboga ilość standardów
> dostępnych i obsługiwanych tak samo przez wszystkich (no przynajmniej
> przez tych liczących się).
>
> Moim zdaniem W3C poszło lepszą drogą z CSS3 - podzielili dokumentację na
> grupy tematyczne i każda ma swój status, dzięki czemu wiadomo co i kiedy
> jest skończone, można implementować wybrane grupy a i eksperymentować
> się da.

Ale to jest właśnie pójście w kierunku "living standard" :-) Przecież
decyzja WHATWG wcale nie wyklucza dokładnie takiego samego działania. Nie
oznacza też braku koordynacji pomiędzy zainteresowanymi stronami ani
wyskakujących z nienacka kawałków implementacji. Różnica pomiędzy CSS3, a
tym co robi WHATWG jest jedynie taka, że w pewnym momencie W3C powie "heh,
skończyliśmy CSS3, wypalamy w węglu" (po to, by potem zrobić update do 3.1
:-)), a WHATWG czegoś takiego nie zrobi. Po drodze wszystko będzie się
odbywać tak samo - kolektywne ciało złożone z przedstawicieli
zainteresowanych stron będzie dopisywało, usuwało, modyfikowało. Tak z ręką
na sercu - pamiętasz w ogóle, które selektory są dostępne w CSS2, a które w
CSS3? Nie - pamiętasz tylko (jeśli w ogóle, bo przecież nie jesteśmy
encyklopediami) których możesz bezpiecznie używać.


--
Michał Gancarski

do góry

W dniu 2011-02-07 21:44, Michał Gancarski pisze:
> Tak z ręką
> na sercu - pamiętasz w ogóle, które selektory są dostępne w CSS2, a które w
> CSS3? Nie - pamiętasz tylko (jeśli w ogóle, bo przecież nie jesteśmy
> encyklopediami) których możesz bezpiecznie używać.

IMO sytuację można by opanować, gdyby wraz z publikacją kolejnej wersji
standardu obowiązkowo była gotowa zaktualizowana referencyjna
przeglądarka. To by powstrzymywało członków komitetu (czy jak to się tam
nazywa) od nadmiernej ekspresji twórczej, a jednocześnie dopingowało
pozostałych do implementacji tego samego zestawu. Chyba Amaya miała być
czymś takim.

artur

do góry

On 07.02.2011, Artur Muszyński <a...@u...wytnijto.com.pl> wroted:

> IMO sytuację można by opanować, gdyby wraz z publikacją kolejnej wersji
> standardu obowiązkowo była gotowa zaktualizowana referencyjna
> przeglądarka. To by powstrzymywało członków komitetu (czy jak to się tam
> nazywa) od nadmiernej ekspresji twórczej, a jednocześnie dopingowało
> pozostałych do implementacji tego samego zestawu. Chyba Amaya miała być
> czymś takim.

I była, do czasu pierwszej specyfikacji.

GS
--
Grzegorz Staniak <gstaniak _at_ gmail [dot] com>

do góry

W dniu 2011-02-07 21:44, Michał Gancarski pisze:
> On Tue, 01 Feb 2011 14:01:55 +0100, Paweł Piskorz wrote:
>
>> No właśnie, standardy są - implementacja leży. Teraz wchodzimy w model
>> gdzie standardu nie będzie lub będzie w wielu wersjach - co się stanie z
>> implementacją?
>
> Wcale nie "nie będzie standardu". Zawsze można się odwołać do snapshotu z
> W3C,

Ale WHATWG wkroczyło bo W3C było zbyt opieszałe, będziemy wieki czekać
aż te snapshoty dojdą do odpowiedniego statusu.

> natomiast rzeczywistym standardem będzie konsensus pomiędzy twórcami
> przeglądarek, snujący się wokół kierunku wytyczanego przez W3C/WHATWG, na
> który to kierunek będą mieli wpływ także dostawcy przeglądarek.

Weź nie strasz, po to im idą na rękę żeby się nie musieli
"konsensusować" poza dokumentacją ;)

> Czyli dokładnie tak jak teraz :-)

Jak teraz? Firefox wymusił na wszystkich stosowanie istniejących
standardów a nie jakiś konsensusów.

>> Powiedz, że żartujesz? Przecież już to przerabialiśmy - "obsługa"
>> standardów przez IE długo nie była udokumentowana, trzeba było szukać
>> "IE cośtam bug" ;)
>> Teraz GChrome dołączył do grupy "zróbmy to na odp..l" - to nie jest dobre.
>
> Mhm, jak dołączył?

Tak, że robią byle jak.

> Póki co widzę co innego - coraz szersza baza możliwości
> obsługiwanych w każdej przeglądarce,

W każdej co innego, taki "konsensus" :P

>> Rywalizację przeglądarek na polu "standardy zawsze w produkcji" już
>> przerabialiśmy - nie poszło im to za dobrze, wygrał silnIEjszy ;)
>> Eksperymenty są pożądane, jak najbardziej - ale nie żeby wszystko było
>> cały czas jednym wielkim eksperymentem, bo nigdy nie wejdzie do
>> powszechnego użycia.
>
> Ej, cały czas to mamy.

No mamy mamy, ale -webkit- czy -moz- w końcu znikają z niektórych
wartości, te eksperymenty mają swoje miejsce i swój koniec.

> I IE nie wygrał, zauważ.

Fakt, ponad 90% rynku to nie było zwycięstwo, to była totalna miazga.

> IE jest co najwyżej
> pośmiewiskiem i dopiero dziewiątka ten stan zmieni. Dziś

Ja się odnosiłem do przeszłości, gdzie wszyscy robili co chcieli.

>>> Mamy jednocześnie do
>>> dyspozycji coraz szerszą, faktycznie obsługiwaną bazę,
>>
>> eksperymentalnych rzeczy, działających różnie w różnych przeglądarkach.
>
> Tych także. Niemniej mamy też coraz szerszą bazę rzeczy obsługiwanych po
> prostu wszędzie.

Z nowych rzeczy to mamy border-radius i istny burdel + łatanie w JS ;)

> Bez żadnych eksperymentów.

Jak bez eskperymentów? A te wszystkie transitions, kolumny, border-image
itd.

>> Moim zdaniem W3C poszło lepszą drogą z CSS3 - podzielili dokumentację na
>> grupy tematyczne i każda ma swój status, dzięki czemu wiadomo co i kiedy
>> jest skończone, można implementować wybrane grupy a i eksperymentować
>> się da.
>
> Ale to jest właśnie pójście w kierunku "living standard" :-) Przecież
> decyzja WHATWG wcale nie wyklucza dokładnie takiego samego działania.

Mają tam jakiś podział też, ale mi chodzi o to żeby grupy uzyskały
kiedyś status ukończonych. O, już się zaczęło:
http://www.whatwg.org/specs/web-apps/current-work/mu
ltipage/sections.html#the-hgroup-element

> Nie
> oznacza też braku koordynacji pomiędzy zainteresowanymi stronami ani
> wyskakujących z nienacka kawałków implementacji. Różnica pomiędzy CSS3, a
> tym co robi WHATWG jest jedynie taka, że w pewnym momencie W3C powie "heh,
> skończyliśmy CSS3, wypalamy w węglu" (po to, by potem zrobić update do 3.1
> :-)), a WHATWG czegoś takiego nie zrobi.

No i właśnie na takim kamiennym węgielku chcę budować :)

> Po drodze wszystko będzie się
> odbywać tak samo - kolektywne ciało złożone z przedstawicieli
> zainteresowanych stron będzie dopisywało, usuwało, modyfikowało.

I mają nawet statusy, co będzie po last call for comments?

> Tak z ręką
> na sercu - pamiętasz w ogóle, które selektory są dostępne w CSS2, a które w
> CSS3? Nie - pamiętasz tylko (jeśli w ogóle, bo przecież nie jesteśmy
> encyklopediami) których możesz bezpiecznie używać.

Za dużo tego w CSS2 nie było: #id, .klasa, selektor potomka, >, +,
pseudoklasy do linków, :before, :after, [selektor=atrybutu]. Czyli
wszystko to co ma IE7, bo na :nth-child jeszcze za wcześnie.
(huh, zapomniałem tylko nieużywanych :first-* i niedziałającego :lang :)).
Poza tym selektory z CSS3 to już PR, więc można się uczyć tylko tej wersji.


--
message[autor="PablO"]::after {
content:"Pozdrawiam";
}

do góry