Doctype... The history behind Internet explorer issues

There’s a long history — and a black art — behind the doctype. While working on Internet Explorer 5 for Mac, the developers at Microsoft found themselves with a surprising problem. The upcoming version of their browser had improved its standards support so much, older pages no longer rendered properly. Or rather, they rendered properly (according to specifications), but people expected them to render improperly. The pages themselves had been authored based on the quirks of the dominant browsers of the day, primarily Netscape 4 and Internet Explorer 4. IE5/Mac was so advanced, it actually broke the web.

Microsoft came up with a novel solution. Before rendering a page, IE5/Mac looked at the “doctype,” which is typically the first line of the HTML source (even before the  element). Older pages (that relied on the rendering quirks of older browsers) generally didn’t have a doctype at all. IE5/Mac rendered these pages like older browsers did. In order to “activate” the new standards support, web page authors had to opt in, by supplying the right doctype before the  element.

This idea spread like wildfire, and soon all major browsers had two modes: “quirks mode” and “standards mode.” Of course, this being the web, things quickly got out of hand. When Mozilla tried to ship version 1.1 of their browser, they discovered that there were pages being rendered in “standards mode” that were actually relying on one specific quirk. Mozilla had just fixed its rendering engine to eliminate this quirk, and thousands of pages broke all at once. Thus was created — and I am not making this up — “almost standards mode.”

In his seminal work, Activating Browser Modes with Doctype, Henri Sivonen summarizes the different modes:

Quirks Mode
Standards Mode
Almost Standards Mode

In the Quirks mode, browsers violate contemporary Web format specifications in order to avoid “breaking” pages authored according to practices that were prevalent in the late 1990s.

In the Standards mode, browsers try to give conforming documents the specification-wise correct treatment to the extent implemented in a particular browser. HTML5 calls this mode the “no quirks mode.”

Firefox, Safari, Chrome, Opera (since 7.5) and IE8 also have a mode known as “Almost Standards mode,” that implements the vertical sizing of table cells traditionally and not rigorously according to the CSS2 specification. HTML5 calls this mode the “limited quirks mode.”

(You should read the rest of Henri’s article, because I’m simplifying immensely here. Even in IE5/Mac, there were a few older doctypes that didn’t count as far as opting into standards support. Over time, the list of quirks grew, and so did the list of doctypes that triggered “quirks mode.” The last time I tried to count, there were 5 doctypes that triggered “almost standards mode,” and 73 that triggered “quirks mode.” But I probably missed some, and I’m not even going to talk about the crazy things that Internet Explorer 8 does to switch between its four — four! — different rendering modes. Here’s a flowchart. Kill it. Kill it with fire.)

Now then. Where were we? Ah yes, the doctype:

That happens to be one of the 15 doctypes that trigger “standards mode” in all modern browsers. There is nothing wrong with it. If you like it, you can keep it. Or you can change it to the HTML5 doctype, which is shorter and sweeter and also triggers “standards mode” in all modern browsers.

This is the HTML5 doctype:

That’s it. Just 15 characters. It’s so easy, you can type it by hand and not screw it up.

Source: http://diveintohtml5.info/semantics.html#blank-space-gotcha

How Quirks mode works

A document is always set to one of three modes: 

1. no-quirks mode, the default; 
2. quirks mode, used typically for legacy documents; 
3. limited-quirks mode. 

Unless stated otherwise, a document must be in no-quirks mode.

The mode is only ever changed from the default if the document is created by the HTML parser, based on the presence, absence, or value of the DOCTYPE string. [HTML]

No-quirks mode was originally known as "standards mode" and limited-quirks mode was once known as "almost standards mode". They have been renamed because their details are now defined by standards. (And because Ian Hickson vetoed their original names on the basis that they are nonsensical.)

fonte: http://hsivonen.iki.fi/doctype/html5-mode.pdf

Quirks Mode

In the Quirks mode, browsers violate contemporary Web format specifications in order to avoid “breaking” pages authored according to practices that were prevalent in the late 1990s.

Standards Mode

In the Standards mode, browsers try to give conforming documents the specification-wise correct treatment to the extent implemented in a particular browser. HTML5 calls this mode the “no quirks mode.”

Almost Standards Mode

Firefox, Safari, Chrome, Opera (since 7.5) and IE8 also have a mode known as “Almost Standards mode,” that implements the vertical sizing of table cells traditionally and not rigorously according to the CSS2 specification. HTML5 calls this mode the “limited quirks mode.”

Possible Impacts:

There are several effects that most browsers use in Quirks Mode:

• In some browsers, the box model changes to the IE 5.5 version of the box model in quirks mode.
• Some browsers don't inherit styles into tables
• Quirks mode affects the parsing of CSS and CSS layout dramatically, if you are converting pages to standards mode from quirks mode, be sure to test your CSS layout and parsing extensively.
• Watch for changes to scripting when in quirks mode. Firefox changes the way the id-attribute works, for example. IE8 and IE9 have very dramatic changes to scripting in quirks mode.

These information are the result of a study I made while working in a legacy product, to understand the behavior why the browser was running under quirks/compatibility mode and find the best solution, considering possible impacts... I strongly recommend to use the latest doctype declaration (i.e. for HTML5) and replace deprecated CSS styles for the html5 equivalent ones).

References:

http://www.w3.org/html/wg/drafts/html/master/syntax.html#the-initial-insertion-mode

http://hsivonen.iki.fi/doctype/ie8-mode.png

http://hsivonen.iki.fi/doctype/

http://msdn.microsoft.com/en-us/library/cc196988(v=vs.85).aspx

http://msdn.microsoft.com/en-us/library/ie/hh869300(v=vs.85).aspx

http://www.quirksmode.org/css/quirksmode.html

http://webdesign.about.com/cs/doctype/a/aaquirksmode.htm

http://blogs.msdn.com/b/ie/archive/2011/12/14/interoperable-html5-quirks-mode-in-ie10.aspx

Moto G: incrivel!

Hoje resolvi postar em português para disseminar aos brasileiros que estão pensando em comprar um novo Smartphone um pouco da minha experiencia de uso com o Moto g, o novo Smartphone da Motorola.

Pesquisei muito antes de comprá-lo, pois sempre fui fã da Samsung e Nokia. A primeira barreira a ser vencida foi a da marca. Essa foi fácil superar, pois ao pesquisar descobri que o Moto g foi desenvolvido pela Motorola enquanto a empresa pertencia ao Google. Isto implica no fato de que o Moto g combinou muito bem seu sistema operacional com seu hardware (processador, memória...).

A segunda barreira foi que, após descobrir o Moto g, fui um pouco mais além e descobri o Moto x (que é considerado por muitos a obra prima do Google junto à Motorola). Não vou entrar em detalhes sobre este aparelho, mas o que pesquisei concluí que apesar de ele ter um processador de dois núcleos (contra um de 4 do Moto g), seu processador é sim melhor. Isto, além de outros recursos de reconhecimento de voz que o Moto x tem me seduziram a querer comprá-lo, até que seu preço de 1399 reais me fez optar por desistir (deixo claro que o valor dele ainda é baixo se comparado a outros modelos do mesmo nível de outras marcas.) Como não queria gastar mais de 1000 reais, voltei a cobiçar o Moto g novamente e analisar concorrentes da Samsung.

Do meu ponto de vista a Samsung pecou por ter lançado uma gama de aparelhos diferentes e com variadas opções (é aquela questão do paradoxo da escolha, onde você oferece opções demais e o cliente passa a ter muitas duvidas e não se decide.) Acabei aceitando o Galaxy s3 mini como concorrente do Moto g (ambos inclusive estavam custando o mesmo preço). O Moto g bateu o s3 pra mim por alguns detalhes, como proteção Corning Gorila glass 3 contra riscos na tela, velocidade de transferencia de dados ao usar internet (21mbps contra 14 do s3 mini), camera frontal de 1.3mp contra uma vga do s3, além do dispositivo da Motorola ser 2 anos mais moderno que o da Samsung e vir já preparado para receber o Android KitKat e , o melhor de tudo, o processador do Moto g que é um quad-core.

Esses foram os principais pontos que me ajudaram a optar pelo aparelho da Motorola, além também de ele vir com o Android puro (sem customizações e aplicativos que as empresas costumam adicionar, o que pode tornar o desempenho do aparelho um pouco lento as vezes).

Moto G VS Samsung Galaxy s3 mini (fonte: gsmarena.com)

Bom, hoje completam 2 semanas que estou com o aparelho e realmente só tenho elogios a respeito. Os serviços do Google funcionam muito bem, o reconhecimento de voz para localizar lugares e dirigir usando o GPS é outra coisa sensacional (mas que é independente do aparelho, e sim do sistema operacional (ou seja, deve funcionar bem em qualquer aparelho com Android).

Também usei o Bluetooth para transmitir músicas pelo som do carro e funcionou tranquilamente. 

Antes deste aparelho, eu tinha um Samsung Galaxy Ace, que comprei em 2011 quando estava na França ainda e o aparelho não estava mais suportando novos aplicativos, acusando falta de espaço interno. O Moto g tem duas versões, uma com 8Gb e outra com 16Gb de armazenamento interno (fornecendo ainda 50gb disponíveis no Google drive). Por alguma razão o meu Google drive ainda não reconheceu e me forneceu estes 50gb, mas acredito que conseguirei resolver este problema assim que tiver um tempinho, entrando em contato pelo suporte da Motorola que posso acessar diretamente pelo aparelho.

PS: Uma outra novidade interessante é que a Motorola divulgou na semana passada que em breve, o drive mode (diferencial forte do Moto x) será disponibilizado para o Moto g. Esta função identifica quando o usuário está dirigindo, lê as notificações recebidas e ainda permite respostas rápidas enquanto o usuário não pode olhar a tela.

Algumas fontes de pesquisa: 

Comparação Moto G vs Samsung Galaxy S3 mini

Informação sobre a linha de processadores dos aparelhos

UX Weekend in Florianopolis

So fellows, two weeks ago I had the pleasure of participating in a User Experience design course.
It was managed by Edu agni, and began on Friday with the Responsive Day, where we learned some concepts of "Mobile First" and Responsive web design.

Nowadays, when we design a website, we should consider that it can be seen in several types of devices (desktop, tablets, smartphones). This way, the mobile first concept says that we should start developing for the smaller device and then improve the system for the desktop version (when I say desktop version, I refer to a website displayed in a laptop/desktop browser).

But why to start by the mobile version? The answer is simple: If you start to think how to design for a small screen device, you will focus on the information that really matter. This will ensure that the user experience is 'usable'. Also, you can optimize user experience by adding some media queries and applying some styles to display and position information for other devices with different resolutions (designers applies the therm Progressive Enhancement in this context, where you start developing from the simplest, and keep improving the system for other resolutions).

Besides that, we also learned some techniques to understand user requirements (to define it!) such as User Cases, User Stories, Scenarios, Card Sorting. This last one we practiced a bit and it was a very interesting experience, which I'll probably try to apply in the product I work.

Usability Evaluation was one of the main topics we learned in the UX course, and of course, Jacob Nielsen was referenced, as expected, with his 10 heuristics (I'm planning to talk about it in a future post).


Well, It was really productive and I could 'update' my skills as front-end developer.
Here is a pub about the UX Weekend (by the way, I'm in the video! haha)

WikiComputação is... back!

So, after sometime, here I am publishing for WikiComputação again. Well, after these almost 2 years without posting anything here, I have some news. I enjoyed a great experience doing an internship for a French enterprise (Fruition Sciences SAS - a French startup that optimizes Wine production), where I developed some enhancements to their Decision-Making support system, using PHP (MVC framework), MySQL, jQuery, HTML and CSS.

I returned from France in october 2012 to complete my Computer Science Bachelor degree, and I had the opportunity to study one last course at UDESC. I picked up HCI (Human-Computer Interaction). I found this topic really interesting. I had the opportunity to study systems usability, ergonomics and other related concepts.

I may have forgotten to mention, but before I go to France, I was doing an internship at Render Multimídia LTDA (a Brazilian e-commerce that sells online courses), and during this period, I was trained to be the Front-end engineer in a team composed by 3 back-end developers and me (the front-end developer). At this point, some third-party enterprise was hired to design the new pages of the e-commerce, and I was creating the html+css+javascript effects from PSD files sent to me by the designers.

I enjoyed a lot this work, and since I was in charge with 'only' this job, I could improve my front-end knowledges really well.
When I went to France, I did an internship as a back-end developer, so I could improve my 'back-end' skills. I came back to Brazil and after one month I got hired by NeoGrid (a Brazilian Multi-National leader in Supply Chain Management), where I started my career as junior developer. There, we work in a SCRUM team, so we're all front-end/back-end developers at the same time.

I'm currently programming in Java (J2EE, JSP, Struts, Oracle, Liquibase). It's been an awesome experience. We also have QA analysts to help us testing the issues we solve (Funny story: If you have already worked with QAs you're probably aware of these phrases:"It works in my machine!" "This problem was not caused by my code changes!", "This is not related to the issue I'm currently working". haha It's a 'funny' war that I'm used to call "QA vs Dev".

PS: I don't know why the QA is a mouse in the cartoon... so don't blame me!!!
Another awesome thing is that we follow almost all the 12 topics to pass in the JOEL TEST.
Well... This was just an introduction to let you up to date about my current situation. As I mentioned, I enjoyed studying HCI concepts. Now, I'm trying to improve my knowledge in this major field and help my team to keep finding better solutions to the products we develop. This way, I came to Florianópolis this weekend to do the ResponsiveDay and User-Experience Design course (UX Weekend), conducted by Edu Agni, a Campus Party Brazil Design Consultant. I just came back from the #ResponsiveDay and it was very productive. Tomorrow we will start the UX Weekend.
I'll be talking about it soon, in my next post.