MozCampLATAM2012/ProposedTalks/Building an Interoperable Web

- give authors the power to create content or applications for their users
  - but not things where the abuse is going to be worse than the
    benefit.  (not easy to tell in advance)
  - Make it easier to build things that are better for users.  The
    default should be the better behavior.
    - mechanisms for user choice need to actually work.  For example,
      preferences for default font size didn't because too few users
      changed them, and authors wrote too much Web content that either
      (a) depends on the default values or (b) overwrites them
  - Make it a better choice than things that are for one OS (e.g.,
    Windows Apps, Android/iOS apps) or for one ecosystem (e.g.,
    Facebook).  (The Web has competition.)

Browsers and Standards

- the Web stack has multiple implementations
  - that's good in itself, since it means that one company doesn't control it
- making technology part of the Web means getting it in all browsers
  - getting it in some browsers can put pressure on the others if
    developers like it (though engines used in proprietary stacks have
    a developer mindshare advantage here)
- standards are a tool to do this
  - some people view standards processes as like a "democracy" -- if we'd
    wanted various parties to have certain rights they'd be designed very
    differently -- so most are not.
  - documenting things well is good because it helps new browsers --
    a browser-maker that has to spend less energy reverse-engineering how
    core Web technology works has more chance to bring new innovation to the
    Web
  - choice of how to standardize:  patent policy, how much room for
    discussion is needed (not needed when describing how things already
    work and we can't change them), tool support, whether the relevant
    parties (browser makers, developers, other parties) are in the room

How to be involved?

 - what technology do we need?
   - use cases first!
     - as a Web developer or as a user
     - describing solutions first doesn't work because if there's a
       problem with the solution, people don't know what the problem
       you wanted solved was.  And knowing what problem you want solved
       also helps prioritization.
   - prioritization
     - can't work on everything at once
     - hard to know how to measure tradeoffs
     - better to prioritize inaccurately than not at all
 - whether to start within Mozilla and bring something more complete to
   a standards body, or start within a standards body?
   - depends on whether it's likely to be well-received
 - how to build it?
   - writing specifications
     - trade off value and cost (don't include everything)
     - define things precisely
       - interop
       - no hidden costs
   - tests
     - good tests can make a standard ready for use much faster
- join the mailing lists
  - W3C lists
  - WHATWG lists
  - IETF
  - etc.
- how to get a sense of a community before diving in

Implementing standards in Mozilla

- I'm going to talk about the HTML rendering pipeline
  - HTML (, SVG, XUL) document
    - serialization of a tree structure
      http://dbaron.org/talks/2012-03-11-sxsw/slide-5.xhtml
  - DOM tree
    - tree structure corresponding to markup
    - code in content/
    - model that's exposed to script
    - type hierarchy based on element types
  - frame tree
    - second tree structure
      http://dbaron.org/talks/2012-03-11-sxsw/slide-8.xhtml
    - code in layout/
    - rectangles
    - type hierarchy based around CSS 'display' property
    - 3 main operations: construction, Reflow (position calculation), painting
  - graphics API

How to get involved?

- figure out what problems *you* want to solve
  - have a goal:  what do you want to change about the Web?
  - beware some "good first bugs", though they might be good
- how to start out
  - look for and read documentation (e.g., build docs are good, but beware out-of-date docs), read code
  - talk to people
    - avoid spending too much time going down the wrong track
      - duplicating work
      - taking the wrong approach
  - but also show you're serious; be willing to spend time figuring things out
- again, figure things out for yourself, but when you're stuck, ask questions

Español

Português

(Thanks to Ruben Morais for the translation.)

Quais são os objetivos da tecnologia Web?

- O escopo se expandiu ao longo da história da Web
  - Passou a ser mais que um local para compartilhar dissertações de Física
  - Aplicativos hoje
  - Outras coisas que não estão na Web hoje mas podem estar no futuro

- Liberdade para os usuários
  - Com segurança (Mesmo que eles não saibam o que não é seguro)

- Dar aos autores o poder de criar conteúdo ou aplicativos para seus usuários
  - Mas não coisas que abusam mais do que ajudam (difícil de imaginar exemplos)
  - Facilitar a criação de coisas que são melhores para os usuários.
    O comportamento padrão deve ser o melhor.
    - Mecanismos que oferecem uma escolha ao usuários devem funcionar de verdade.
      Por exemplo, preferências para o tamanho padrão da fonte não funcionaram,
      já que poucos usuários as mudavam, e os autores criaram muito conteúdo que
      (a) dependia dos valores iniciais ou (b) ignoravam a preferência
  - Torná-la uma escolha melhor para coisas que são feitas para um SO (por ex.
    aplicativos Windows, aplicativos para Android/iOS) ou para um ecossistema
    (por ex. Facebook). (A web oferece competição)

Navegadores e padrões

- A plataforma Web tem várias implementações
  - Isso é bom, já que uma compania sozinha não tem o controle
- Tornar uma tecnologia parte da Web requer que ela esteja presente em todos os
  navegadores
    - Levá-la para alguns navegadores pode criar pressão para os outros caso os
      desenvolvedores gostem da tecnologia. (Implementações que são
      usadas em plataformas proprietárias tem uma vantagem nisso)
- Padrões são ferramentas para fazer exatamente isto
  - Algumas pessoas enxergam processos de padronização como uma "democracia" –
    se os participantes tivessem direitos determinados, o processo seria bem
    diferente – mas a maioria não é.
  - Uma boa documentação é necessária pois ajuda novos navegadores – um desen-
    volvedor de um navegador precisa gastar menos tempo revertendo o funciona-
    mento de uma tecnologia da Web e tem mais chances de trazer inovações para
    a plataforma.
  - Escolha de como padronizar: patentes envolvidas, quanto espaço para discus-
    são é preciso (não é preciso quando estamos descrevendo coisas que já fun-
    cionam e não podemos mudá-las), suporte de ferramentas, se todos os grupos
    interessados (navegadores, desenvolvedores, outros) estão de acordo.

Como se envolver?

- Que tecnologia precisamos?
  - Casos de uso primeiro!
    - Como um desenvolvedor Web ou como um usuário
    - Descrever as soluções primeiro não funciona porque caso haja um problema
      com a solução, ninguém saberá qual é o problema que você tentou resolver.
      Saber qual problema você quer resolver também ajuda a priorizar.
  - Prioridades
    - Impossível fazer tudo ao mesmo tempo
    - Difícil medir prós e contras
    - Melhor priorizar sem precisão do que não priorizar
  - É melhor começar dentro da Mozilla e levar algo mais completo ao grupo de
    padronização, ou começar no grupo de padronização?
    - Depende de quão bem a tecnologia será recebida
  - Como construí-la?
    - Escrevendo especificações
      - Avaliar valores (não incluir tudo)
      - Definir com precisão
        - Interop
        - Sem custos escondidos
    - Testes
      - Padrões com bons testes ficam prontos para uso mais rapidamente
  - Entre nas listas de discussão
    - Listas do W3C
    - Listas do WHATWG
    - IETF
    - Etc.
  - Como entender a comunidade antes de se envolver

Implementando padrões na Mozilla

 - Irei falar da linha de renderização de HTML
   - Documento HTML (, SVG, XUL)
     - Serialização de uma estrutura em árvore
       http://dbaron.org/talks/2012-03-11-sxsw/slide-5.xhtml
   - DOM tree
     - Estrutura em árvore correspondente ao markup
     - Código em content/
     - Modelo exposto a scripts
     - Hierarquia de tipos baseada nos tipos de elementos
   - Frame tree
     - Segunda estrutura em árvore
       http://dbaron.org/talks/2012-03-11-sxsw/slide-8.xhtml
     - Código em layout/
     - Retângulos
     - Hierarquia de tipo baseada na propriedade CSS 'display'
     - 3 operações principais: construção, reflow, renderização
   - API gráfica

Como se envolver?

 - Descubra quais problemas *você* quer resolver
   - Tenha um objetivo: o que você quer mudar na Web?
   - Desconfie de "good first bugs", mas eles podem ser bons
 - Como começar
   - Procure e leia a documentação e o código
   - Converse com pessoas
     - Evite gastar muito tempo no caminho errado
       - Trabalho duplicado
       - Usando uma aproximação ruim
   - Mostre que você está disposto, gaste tempo descubrindo como as coisas fun-
     cionam
   - Seja persistente
 - Novamente, descubra as coisas por conta própria, mas quando estiver travado,
   faça perguntas

MozCampLATAM2012/ProposedTalks/Building an Interoperable Web

Contents

Summary

To Be Completed by the Audience

Planned outline of talk

English

Español

Português

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

How to Contribute

MozillaWiki

Around Mozilla

Tools