Você tem celular? De acordo com a Teleco, em novembro de 2005, havia mais ou menos 82.351.644 de celulares. Ainda me lembro de quando eles eram artigos de luxo, mesmo sendo grandes e pesados.
Hoje, por um preço razoável, você consegue celulares que tiram fotos e fazem outras coisas que nem James Bond ousava imaginar. E quer saber da melhor? Esse é só o começo.
Aparelhos com essas e outras possibilidades aparecerão. Os HandHelds com funcionalidades iguais as de um Desktop estarão em alta. Pessoas acessarão a internet de qualquer canto… não serão dependentes dos poucos HotSpots. Conexões como Wi-Max não serão novidade. Ninguém arregalará os olhos quando você tirar um Palm ou PPC do bolso para anotar algo e enviar por email, pelo contrário. A internet estará espalhada em cada bolso, em cada palma de mão.
O Google acabou de lançar uma versão do seu webmail para mobiles. Sem contar com sua versão de busca para Mobiles. O Flickr também tem sua versão para dispositivos móveis. Isso mostra que os grandes, de uma maneira ou de outra, estão preparados para essa nova etapa.
Como introdução a criação de sites para esses dispositivos, criamos dois artigos que poderão ajudar o desenvolvedor. É importante que comecemos a fazer da maneira certa. Ter em mente suas possibilidades, seus limites. Um dos artigos fala sobre SSR - Small-Screen Reader. O outro fala um pouco sobre MediaType para HandHelds.
13 ComentáriosQuem já teve que resolver alguns problemas de compatibilidade de layout para IE/Mac, sabe que não é fácil.
Mas agora, todos os problemas acabaram! O Microsoft anunciou que vai parar de dar suporte ao IE/Mac no dia 31 de Dezembro de 2005. E, em 31 de Janeiro de 2006, ele já não estará disponível para download.
Ótima notícia para todas as partes. Menos um browser que não segue os padrões para os desenvolvedores se preocuparem. O belo Safari, ganhará seu espaço, e fortalecerá sua competição com o Firefox. Ou seja, os desenvolvedores não precisam ter nem um favorito - qualquer que for o resultado, sairemos ganhando.
A próxima sombra de desespero que nos segue é o IE para Windows. Mais especificamente o IE 5. Pelas minhas contas (não sou bom em matemática), ele vai sair de linha no ano que vem. Pessoas atualizarão seus Windows, conseqüentemente o IE sobe para versão 6. Que é bem menos assustador.
Mais informações: A Final End to IE/Mac
obs.: Quer saber o mais legal?!
- It is recommended that Macintosh users migrate to more recent web browsing technologies such as Apple’s Safari.
Último parágrafo deste textinho lindo: Important information for microsoft Internet Explorer for mac users
Finalmente podemos falar em SVG na Web. Ou quase… Falta o Internet Explorer. Veja uma breve introdução ao assunto, com alguns exemplos do que é possível.
Atenção! Você precisa do Firefox 1.5 para ver esses exemplos. O Opera para Windows trava se você tentar acessar. O Opera 8.5 para Linux se comporta bastante bem.
A Web foi criada para ser um ambiente onde fosse possível trocar informações livremente, e que essas informações pudessem ser acessadas ao redor do planeta por qualquer pessoa. Em 1994, foi criado o W3C (World Wide Web Consortium): um consórcio internacional, onde são desenvolvidas os padrões para a web (Web Standards) tais como: HTML, CSS, XML, XSLT, entre outros.
Naquela época, no mercado de browsers, as opções ainda eram poucas: consistiam apenas em Lynx, Mozaic e Netscape Navigator, da Netscape Communications, então liderada por James Clark. A Microsoft, de Bill Gates, resolveu entrar nesse mercado lançando o Internet Explorer. A partir daí, o Netscape e o Internet Explorer começaram a travar uma guerra atrás de adpetos. A concorrência entre os dois browsers é chamada até hoje de Guerra dos Browsers. Durante essa “guerra”, os padrões do W3C ainda eram meros rascunhos. Por conta disso, as duas empresas que não podiam esperar que esses rascunhos ficassem prontos começaram a lançar seus browsers com padrões proprietários.
Agora o impasse: Os browsers tinham seus próprios padrões… Já os desenvolvedores não conseguiam criar um único código que funcionasse nos dois navegadores. Por este motivo, eles eram obrigados a desenvolver, na maioria das vezes, para apenas um browser.
Isso trouxe mais um problema, agora para os usuários. O usuário que usava Netscape, não conseguia acessar sites que eram feitos para Internet Explorer, e vice-versa.
Como a web não tinha sido projetada para desenvolver os criativos ambientes gráficos que temos atualmente, naturalmente, os recursos de desenvolvimento eram limitados e os criadores faziam das tripas coração para criar seus sites. Entre as muitas idéias que surgiram para ultrapassar ao ambiente de “apenas texto” da internet, estava aquela de utilizar tabelas de HTML para posicionar os elementos no layout, utilizando slices de imagem, gifs transparentes e a técnica de aninhamento de tabelas para contornar os problemas que os padrões proprietários traziam. A esse tipo de técnica, que foi usadapela maior parte dos websites, chamamos de layout com tabelas.
Os sites que seguem os Padrões Web utilizam uma metodologia de desenvolvimento baseado em 3 camadas, são elas:
Em poucas palavras: um site tableless é um site que não utiliza tables para a estruturação do Layout. É um site que segue os Padrões Web.
O termo “tableless” é usado mais largamente aqui no Brasil. Em outros países outros foram mais difundidos, por exemplo: CSS Layouts.
Um site tabeless segue obrigatoriamente regras de semântica. Cada tag tem sua função própria. Por exemplo, para criar um parágrafo de texto, usamos a tag <p></p>. A tag Table e suas filhas são utilizados para exibir dados tabulados, por exemplo, uma listagem de produtos, onde são mostrados algumas informações sobre o produto como tamanho, preço, cor, material, disponibilidade, etc…
| Tênis | Cor | Tamanho | Preço | Disponibilidade |
|---|---|---|---|---|
| Nike | Preto | 38-39 | R$ 100,00 | Em Estoque |
| Adidas | Branco | 40-41 | R$ 120,00 | Esgotado |
Formatar informações dos sites não é algo novo. Por volta de 1970, no começo da tragetória do SGML, vários browsers já personalizavam as aparências dos documentos, cada um com seu estilo próprio.
Håkon Wium Lie, estudava e percebia as dificuldades que se tinham ao desenvolver um site, e resolveu criar uma maneira fácil para formatar a informação do HTML. Foi aí que ele propôs a criação do CSS ou Cascading Style Sheets. Esse era o ano de 1994.
Em 1995 eles apresentaram sua proposta e finalmente, o W3C - World Wide Web Consortium - que estava acabando de nascer, se interessou pelo projeto e resolveu criar uma equipe, obviamente liderada por Håkon e Bert Bos. O resultado apareceu logo, em 1996, eles lançaram a recomendação oficial pelo W3C do CSS Level 1 (CSS 1).
Dois anos depois, no dia 12 de Maio de 1998, eles lançaram a recomendação do CSS de nível 2. A segunda versão das Folhas de Estilo para web.
Hoje em dia, o nível de compatibilidade entre os browsers é muito parecido, de forma que se você implementar algo específico em um browser, é muito provável que em outro browser esteja igual.
Portanto, o desenvolvedor pode ficar tranqüilo quanto a maioria dos problemas causados por diferenças entre browsers.
13 ComentáriosImagine se cada eletrodoméstico usasse um tipo de tomada. E ao comprar um novo eletrodoméstico, você tivesse que adaptar uma tomada nova em sua casa. Imaginou o caos que seria? Felizmente existe um PADRÃO de tomadas para todos os aparelhos domésticos. Se comprarmos um aparelho de som, e então levarmos para outra cidade, estado ou país, a tomada será a mesma e seu aparelho funcionará. Percebemos então o verdadeiro valor dos padrões. Na Web não é diferente, também é necessário haver padrões. Por isso que projetos como WaSP (Web Standards Project) surgiram no auge da desordem no desenvolvimento do sites. Eles foram um dos que impulsionaram a popularização dos Web Standards, fazendo a W3C (World Wide Web Consortium) ser conhecida por todos como uma autoridade e então ajudando-a a cumprir com seu papel.
O W3C criou linguagens básicas de publicação de conteúdo para Web. Essas linguagens são chamadas de Web Standards (Padrões Web). HTML, XHTML, CSS, SVG, XML, XSLT, entre vários outros.
Esses padrões hoje são estudados e felizmente os desenvolvedores estão aplicando em seus sites. Os desenvolvedores devem perceberem as incríveis vantagens que o desenvolvimento com os Padrões oferece, não só para a execução do trabalho, mas para a estruturação da web em si. Para a estruturação da Web do futuro, onde ninguém terá que garimpar em buscadores para conseguir a informação que se precisa, mas a informação estará aonde você estiver, andará com você aonde quer que for, e você terá acesso a ela sem barreiras, na hora que quiser, onde quiser, e usando o dispositivo que for.
Primeiramente é necessário que entendamos um pouco do conceito dos Web Standards.
A idéia original da Web, era que existisse um ambiente onde pessoas conseguissem trocar informações livremente, e que essas informações poderiam ser acessadas de diversos dispositivos. O W3C (World Wide Web Consortium) criou as linguagens básicas de publicação de conteúdo para Web, como por exemplo: HTML, CSS, SVG, XML, entre vários outros. Essas linguagens são chamadas de Web Standards (Padrões Web).
Por este tempo, deu- se início a Guerra dos Browsers. Onde o Internet Explorer e o Netscape travavam uma briga para conseguir mais adeptos. Durante essa guerra, as linguagens do W3C eram ainda rascunhos. Então, os browsers não tinham um guia completo para se basearem e lançarem seus browsers com suporte a esses Padrões. Resultou que os fabricantes de browsers criaram seus próprios padrões. E foi aí que problema começou a crescer para o lado dos desenvolvedores e usuários. De um lado estava o desenvolvedor estudando as diferenças de cada browser, para assim poder escolher qual ele iria priorizar e qual ele iria ignorar. Do outro usuário, com o mesmo dilema. Se ele escolhesse “tal” browser, os sites que ele visitara poderiam não funcionar.
Os usuários que tinham algum tipo de deficiência, como por exemplo auditiva ou visual, ficaram praticamente isolados do mundo digital, já que os desenvolvedores web tiveram que se adaptar a um certo tipo de browser, obedecendo suas peculiaridades.
Durante essa época, desenvolver um site era um trabalho árduo levando os desenvolvedores escolherem apenas um browser e desenvolver apenas para esse browser. Era quase que insuportável tenta desenvolver um site que se adequasse às duas plataformas de browsers. Os trabalho de atualizar ou fazer manutenções eram enormes e despendiam de muito tempo e paciência.
Foi por esse período que surgiram projetos como o WaSP (Web Standards Project), que é um movimento para difundir os Web Standards. Esse grupo teve um papel muito importante na divulgação dos Padrões. Eles conversaram com os fabricantes dos principais browsers, convencendo- os de fazerem browsers mais compatíveis com os Padrões. E isso deu certo… Tanto que temos o Opera, Mozilla, e vários outros por aí. Hoje, o desenvolvedor tem mais liberdade de desenvolvimento do que a 5 anos atrás. Hoje, a visão dos fabricantes de browser mudou completamente, e se continuar assim, teremos uma web melhor em muito pouco tempo.
Sabendo disso, podemos agora entender o que é Tableless.
Comecemos pelo nome. O nome Tableless é um nome mais “publicitário” para se referir a sites que seguem os Padrões. Os sites Tableless não são construídos usando as famigeradas tables. Elas usam XHTML para apresentar a informação e as Folhas de Estilo (CSS) para formatar essa informação. Pelo motivo de as tables não serem usadas para a estruturação, essa metodologia se chama Tableless.
Antes que você pense que as tables foram totalmente apagadas do mapa, eu explico: No movimento Web Standards, cada tag tem a sua função. Se você quer fazer um parágrafo, usa- se a tag <p>< /p>. Se quer fazer um título de primeiro nível, usa- se a tag <h1>< /h1>. Se você quer exibir dados tabulados, como por exemplo um calendário, ou ainda uma lista de produtos seguidos de nome, preço e tamanho, você usará as tables para exibir esses dados.
Essa pergunta é muito difícil de ser respondida porque as diferenças entre um método e outro são gritantes. Essas diferenças afetam todas as pessoas envolvidas no projeto: começando na equipe de desenvolvimento. Aquela briga tradicional entre designer e programador acaba. Eles começam a trabalhar juntos no mesmo projeto, sem um atrapalhar o trabalho do outro. O designer trabalhará sem tocar no código de programação, ficará apenas no código CSS, onde o programador não terá como estragar o layout do Designer. E dessa forma, com os dois trabalhando ao mesmo tempo, no mesmo projeto, o tempo de produção será diminuída.
Inclui os donos do negócio, já que há diversas economias no desenvolvimento do projeto e também em manutenções posteriores, bem como consumo de banda que é tão preciosa hoje em dia. E finalizando no usuário, que agora pode acessar o site usando a plataforma e o browser que preferir. Poderá acessar de seu Mac ou do seu Linux, usando Opera ou Konqueror. Ele terá controle.
Assunto interessantíssimo. Suponhamos a seguinte situação:
Final daquele grande projeto. Cliente grande, site gigantesco. Várias aprovações de layout durante o caminho. Tudo acertado e pronto para ir pro ar. Faltando apenas alguns detalhes, o chefe chama o designer em um canto e diz: - O cliente acabou de ligar; ele estava analisando o site e pediu que todos os títulos mudassem de cor. Ele não gostou do azul, gostaria de verde mesmo.
O designer, com um olhar de desgosto, volta para sua cadeira e fica pensando em apenas uma coisa: - Por onde vou começar?
Ele fez o site em um editor visual, os títulos do site estão sendo formatados nos próprios documentos, direto no código. A única saída seria abrir documento por documento e substituir título por título.
Creio que se isso não aconteceu com você, algo parecido deve ter acontecido. Se o site acima tivesse sido feito seguindo os padrões, usando CSS para sua formatação, e o código fosse um XHTML bem Semântico, o trabalho disso seria quase nulo. O designer (ou o responsável pelo código CSS) mudaria apenas uma linha.
E se, o caso não fosse para mudar apenas um título, mas mudar o layout do site, como faria? Se o site foi feito do jeito convencional, provavelmente seria da seguinte forma: O designer faria um novo layout em algum programa de imagem, implementaria este layout passando para HTML, e o programador teria que programar novamente em cima deste novo layout. Mas, se o site foi feito seguindo os Web Standards, bastava o designer escrever outro arquivo CSS, e depois de pronto, substituir os arquivos.
Despenderia de tempo apenas de uma pessoa. A programação não seria afetada, e o todo o site funcionaria perfeitamente, já que foi apenas o arquivo de formatação que foi substituído. Passe um pouco de tempo visitando o site: CSS Zen Garden.
Esse layout mostra como isso funciona. O criador deste site disponibilizou o arquivo HTML para download. Os interessados baixam esse arquivo, e fazem um CSS em cima dele e depois mandam enviam de volta. Os interessados tem apenas o direito de criar um CSS e se quiser usar imagens para compor o layout, eles não podem mudar o código HTML que o criador do site disponibilizou.
Há uma infinidade de layouts, bonitos, funcionais e compatíveis… Mudando apenas UM arquivo. Facilidade de manutenção ou renovação de layout, economia de tempo, trabalho e paciência.
Os usuários com necessidades especiais ganham mais facilidade de navegar no site.
Imagine um deficiente visual. Ele usa um browser que ao visitar um site, le todo o conteúdo mostrado na tela.
Os sites convencionais são feitos, em sua maioria com editores visuais. E em todos são usados os famosos spacer.gif. Para quem não sabe o que é isso, eu explico: São gifs transparentes de 1px que servem para dar espaçamento entre celular ou outro objeto da página. Esses spacer.gif normalmente são colocados apenas a tag relacionada a imagem, sem nenhum texto alternativo. Isso faz com que alguns sintetizadores leiam o nome da imagem. Então, suponha que você tem uma célula separada 20px e que essa distância foi feita com os spacer.gif.
O visitante terá que ouvir ou apertar uma tecla 20 vezes para passar essas imagens que são extremamente inúteis para ele. Isso transforma a navegação deles muito, muito cansativa. São coisas bem pequenas que fazem a navegação dessas pessoas valerem a pena.
Existem hoje muitos sistemas que analisam sites para checar se estão de acordo com as guias de acessibilidade. Esses são alguns:
Lembrando que o site não precisa ser Tableless para se aplicar as Guias de Acessibilidade. Mas se o site seguir os padrões, com certeza a experiência de se navegar vai ser muito melhor.
Existia muito, hoje a resistência é menor.
Os desenvolvedores ainda tem medo do novo. Muitos pensam:
- Preciso aprender tudo outra vez?! Tenho que largar o editor visual? Tenho que fazer o código na unha em vez de usar o editor visual que é tão mais fácil, rápido e prático?
Ou, muitas vezes o desenvolvedor já se convenceu, quer mudar, mas esta decisão não depende dele somente, e sim do Chefe. Parece brincadeira, mas já vi muitos casos do chefe falar:
- Você quer dizer que os sites que você vai fazer com essa nova metodologia não vai funcionar no Netscape 4?
Outros dizem que não vale a pena dedicar mais tempo aprendendo tudo de novo só para fazer sites funcionarem em outros browsers que não sejam Internet Explorer:
- Internet Explorer domina 90% do mercado, vou querer fazer para os outros 10%, porque?!
Hoje, felizmente esses comentários estão desaparecendo, e finalmente estão percebendo todas as vantagens que um site que segue os padrões pode trazer. No começo, uma desculpa bastante usada era que: Fazer sites usando os Padrões não servem para criar Portais, como Terra, UOL, AOL, e etc… Isso já é passado, mesmo porque naquele tempo nenhum era Tableless. A equipe do Terra foi treinada pela empresa em que trabalho (visie.com.br), e o site deles é Tableless. O ganho que tiveram com economia de banda foi espetacular e a facilidade de manutenção também foi enorme.
Outro caso interessante é o site da ESPN.
Aquele site é enorme. Depois que migraram o site para os padrões estima- se que a economia de banda seria de 730 terabytes no ano. A Wired conseguiu uma redução de tamanho das páginas de 54%. Diante de números tão expressivos, é difícil contestar de que não vale a pena. E se não valesse, porque sites como: Lee Jeans, Fast Company, Macromedia, Blogger, Chevrolet, Terra, Quark, e outros migraram para os Web Standards?
Como a folha de estilo (CSS) favorece o webdesigner no processo criativo de um site desde a criação até a montagem? Controle.
CSS favorece um grande controle para o designer. Tanto para a criação quanto para a modificação do layout. Usando CSS, o designer não precisa criar inúmeros gifs transparentes para controlar medidas e distâncias. Com CSS ele tem total controle na manipulação de margens, bordas, distâncias, posição, tamanho, e etc. Formatação de texto também uma das vantagens que é muito flexível. O designer pode aumentar o tamanho das linhas dos parágrafos, capitalizar, fazer caixa alta/baixa, e etc… CSS é como se fosse uma ferramenta para o designer. Assim como Photoshop, Illustrator, ou outro programa visual.
Atualmente poucos browsers causam problemas ao desenvolvedor. A maioria dos browsers atuais tem um bom suporte aos padrões, o que permite que os desenvolvedores façam sites sem muitos problemas.
Acho que o que dará mais problemas futuramente, serão os browsers de dispositivos móveis. Mas temos o consolo de que essa fatia do mercado, está começando a caminhar mais rapidamente… isso promete.
São visualizados com a melhor qualidade possível para esse dispositivo.
Claro, se você espera ver um site em um dispositivo móvel do mesmo jeito que vê num PC, é melhor rever seus conceitos. E se você pensa que só porque fez um site seguindo os Web Standards, ele vai ser visto com a melhor qualidade em “mobiles” (dispositivos móveis), também tire o cavalinho da chuva. Lembre- se que existem sites Tableless mal feitos, isso é claro.
Temos que ter em mente que usuários desses dispositivos tem algumas dificuldades, como por exemplo barra de rolagem. Dá um desanimo quando você abre um site num handheld, e então aquela imponente barra de rolagem horizontal aparece. Quando você é obrigado a rolar a barra toda vez que precisa navegar no menu.
No CSS existe uma facilidade enorme, chama-se Media Types. As Medias Types te permitem fazer um CSS exclusivamente para um tipo e Media. Como por exemplo Impressão ou até HandHelds (Essas são as mais comuns, existem outras medias, como por exemplo para leitores de telas para deficientes visuais ou outra que é exclusivamente para impressoras que imprimem em braile. Essas medias ainda não estão totalmente implementadas, por isso não são muito comuns.) As Medias Types funcionam da seguinte forma: se você quer que seu site tenha letras grandes na hora da impressão… Vocês simplesmente fará um arquivo CSS para impressão, que será usado automaticamente quando o visitante tentar imprimir uma página no seu site.
Com a Media Type para HandHelds não é diferente. Você cria um CSS exclusivamente para os dispositivos móveis. Seu site usará a mesma estrutura XHTML para qualquer media, o que muda é apenas o arquivo CSS. Essa é a facilidade que o CSS dá em relação a isso. Mas o desenvolvedor deve ter bom senso, e estudar um bocado esse mundo que é tão interessante e está se aproximando da popularidade tão rápido.
Vantagens enormes, para desenvolvedores e para usuário.
As vantagens ligadas à parte dos desenvolvedores estão na facilidade de manutenção e na briga entre designers e programadores. Na facilidade de manutenção, o desenvolvedor terá uma flexibilidade tremenda na hora de corrigir algum erro ou se simplesmente quiser mudar todo o layout do site. Se o designer quiser mudar o layout do site, ele simplesmente terá o trabalho de escrever outro código CSS formatando o site com o novo visual, e depois apenas substituir os arquivos. Sem trabalho de ter que refazer o código XHTML e sem precisar mexer no código do programador.
A briga entre o designer e o programador termina por que eles não atrapalham mais o trabalho um do outro. Nem o designer estraga o código do programador e nem o programador estraga o layout do designer.
Há muitas maneiras de os designers e programadores trabalharem harmoniosamente. Como por exemplo: no início do desenvolvimento, o designer e o programador podem sentar juntos e então criar a estrutura do documento, ou seja, o código XHTML do site. Aqui eles farão um código semântico, legível. Feita essa parte, os dois trabalharão em cima deste XHTML separadamente, cada um com sua responsabilidade. O programador com seus códigos client - side, banco de dados e etc… Já o designer ou o responsável por isso, formatará o visual do site, usando CSS. Com o XHTML estruturado semanticamente, o designer não terá grandes problemas ao aplicar estilos às tags.
Outra vantagem que interessa a sites grandes (como portais) é a diminuição do consumo de banda. Há uma queda enorme no número de linhas de código, já que tags desnecessárias foram totalmente excluídas e a separação de informação (XHTML) e formatação (CSS) é praticada. O fator “tamanho” é bastante importante, pois se o tamanho do site diminui, o consumo de banda diminui; logo, os gastos excessivos por causa do estouro de banda são imediatamente reduzidos.
Já o lado do usuário ganha uma grande vantagem: flexibilidade e controle. O usuário ganha a liberdade de escolher qual dispositivo, qual plataforma e por fim, qual browser ele irá utilizar para visualizar seus sites. Um usuário por exemplo pode utilizar Mac e navegar com Safari, Firefox ou até mesmo Internet Explorer. Ou utilizar Linux e navegar com Konqueror, Galeon ou Opera. Se preferir, o visitante pode estar usando algum dispositivo móvel como um PocketPC com Windows Mobile e visitar o site utilizando o Internet Explorer.
Como você já percebeu, há uma variação interminável de plataformas e dispositivos. Isso só tende a aumentar. Esse é o caminho que a web deve percorrer. Liberdade para troca de informações, independente do dispositivo utilizado para isso. É isso que o usuário espera.
16 Comentários
A Visie é pioneira em ministrar cursos presencias de Padrões Web, Tableless, AJAX e companhia…
Você pode fazer cursos individuais ou empresariais treinando grandes equipes. Já treinamos equipes de empresas como Editora Abril, Petrobrás, Terra, Unisys e muitos outros!
Nós ensinamos pessoas que tenham interesse pela profissão e pela internet. Que gostem de informação e saibam que a internet é algo que muda o relacionamento das pessoas.
Ensinamos no curso de tableless a escrever código com significado semântico, organizado e fácil de ser indexado por buscadores. Ensinamos que é muito mais que fazer um site sem tabelas.
Ensinamos o aluno a utilizar Ajax em lugares realmente úteis. Em aplicações por exemplo, Ajax é uma boa pedida. Mas em sites comuns, para fazer aparecer conteúdo textual por exemplo, fazer Ajax já não vale a pena.
Para mais informações sobre nossos cursos, por favor, visite: http://visie.com.br/treinamento/.
Lá você também pode conferir outros cursos como o de Python e PHP.
Dispositivos Móveis. Este é um terreno muito estranho para os desenolvedores de sites.
Talvez você tenha ouvido falar em fazer sites para Dispositivos Móveis (Mobiles) depois que começou a estudar Web Standards. Confesso que comecei a dar mais atenção a essa área depois que estudei a fundo os Padrões.
Mas, para aquele usuário um pouco mais avançado, que quer fazer seus sites aparecerem melhores nestes dispositivos, nada melhor que conhecer os Browsers que estão disponíveis e que são usados pelos usuários de Mobiles.
Tentei montar abaixo uma tabelinha de compatibilidade entre os browsers. Como eu, muitos não devem ter como comprar um aparelho desses para testar, por isso eu recomendo muito pesquisar pela internet. Tentarei na medida do possível dar algumas dicas por aqui sobre os dispositivos, browsers, compatibilidades e etc. Existem muitos sites que são ótimas fontes de estudos, com links e material farto sobre o assunto.
| Browser | HTML | XHTML 1.0 | CSS 1.0 | CSS 2.0 | DOM | JavaScript |
|---|---|---|---|---|---|---|
| Palm Web Pro 3.0 | sim | sim | sim | sim | ? | v1.5 |
| Palm Web Pro 3.5 | sim | sim | sim | sim | ? | v1.5 |
| PalmSource Web Browser 2.0 | sim | sim | sim | Parcial | ? | v1.5 |
| PalmSource Web Browser 3.0 | sim | XHTML 1.0 + XHTML Mobile Profile | sim | sim | Nível 1 / Parc. Nível 2 | sim |
| EudoraWeb Browser | sim | |||||
| Handspring(TM) Blazer(TM) 2.0 | sim | sim | ||||
| Pocket Internet Explorer | sim | ? | ? | ? | ? | ? |
Claro.
Como nos Desktops, os Mobiles tem seus Sistemas Operacionais. O Pocket Internet Explorer é para PocketPc (PPC), todos os outros são para Palm. Sim, há vários tipos de sistemas operacionais para Palm; e não, os browser não são compatívels com todos os tipos de Palms. Por exemplo, o browser Web Browser 3.0 só é compatível com Palm OS Cobalt que ainda nem saiu.
Se alguém souber mais alguma informação sobre especificamente o Internet Explorer. Por favor, nos diga para que possamos melhorar a tabela acima. ![]()