doctype « WordPress.com Tag Feed

Why is IE8 defaulting to Quirks mode?

integris1 — Tue, 10 Nov 2009 23:10:06 +0000

Had this problem with a site recently. A little reading suggests IE will be forced to document.compatMode= ‘BackCompat’ if there is a comment, PI, XML declaration (prior to IE8) or any non-whitespace textual content before the doctype. If a control character has snuck in that you can’t see in your text editor, that could do it.

Indice - Mis Utilidades

arcap2006 — Fri, 30 Oct 2009 10:18:17 +0000

Fuente: http://misutilidades.com.ar/

Labrīt

skri_me — Tue, 06 Oct 2009 15:39:06 +0000

deklarācija ir pati pirmā lieta, kas jānorāda web dokumentā, pat pirms

Case Sensitivity in CSS

asv3 — Sun, 20 Sep 2009 15:30:06 +0000

In CSS remember that font family names and URLs can be case sensitive, but so far I never tried differentiating two CSS class names by different case (upper and lower), hence never got to deal with case sensitivity of CSS, but on of my friends got this question in an interview, later figured out, but default CSS is not case sensitive, but XML or XHTML DOCTYPE declaration can make CSS class names case sensitive.

Always we should follow standards, but it’s good to know sub-standard implications as well. because you don’t know, some day you might end up using code return by other programmers.

So next time when some body ask you about case sensitivity of CSS, blame DOCTYPEs.

Declare Document Language In HTML5

unitechy — Fri, 11 Sep 2009 09:14:47 +0000

The HTML element in HTML5 now allows you to add the language of your document

So now if your webpage in HTML5 is in English, here is how your code should look like:

<!DOCTYPE html>

<head>

<title>Oh! My page is In English</title>

</head>

<body>

<h1>English</h1>

<p> Did you know, if you could read this, you know English Language!! </p>

<p>Congratu-fuckin-lations!! </p>

</body>

</html>

Doctype In Html5

unitechy — Thu, 10 Sep 2009 16:18:00 +0000

Doctype declaration is an instruction to the browser about what type of markup language you will be using in a webpage.

Example of Doctype in HTML 1.0

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>
<html>
<head>
<title>Ubersexy page</title>
</head>

<body>Nice webpage this is</body></html>

—————————————————————————————-

Declaring Doctype in HTML5 is damn easy! The above Doctype declaration just changes to something like this in HTML5:

<!DOCTYPE html >
<html>
<head>
<title>Ubersexy page</title>
</head>

<body>Nice webpage this is</body></html>

—————————————————————————————–

Easy isn’t it?

DOCTYPE для вашего сайта

szenprogs — Thu, 20 Aug 2009 05:46:01 +0000

Вы создали свой новый и уникальный сайт. Вы хотите продвигать его и получить посетителей. Но как отреагирует посетитель, если зайдя на сайт увидит поплывшие блоки, и вообще, неправильно отображенную страницу. Решение этой проблемы можно найти здесь.

Вы уверены, что сайт отверстан идеально, все теги правильные, структура соблюдена, но отображение сайта не такое, как хотелось бы. В этом виноват тег DOCTYPE. Цель этого тега – передать браузеру информацию о том, как сверстан сайт. И браузер, учитывая DOCTYPE, будет показывать страницу так, как предполагает стандарт, описанный в этом теге.

Неправильный DOCTYPE – это полбеды. Многие начинающие верстальщики вообще не знают о его назначении. Они даже не вставляют этот тег на страницу. В результате, браузер выбирает метод отображения на свое усмотрение. И это “свое усмотрение” может не совпадать с мнением верстальщика. Скажем, сайт сверстан в формате XHTML 1.0, а, если тег DOCTYPE не объявлен, то отображаться будет в формате HTML 4.01 (по умолчанию). В результате не то, что ожидал верстальщик.

Поэтому идите на портал SzenProgs и верстайте сайты правильно.

Problemas con los tags embed y noscript con el doctype strict

joeloverbeck — Tue, 18 Aug 2009 11:01:33 +0000

Digamos que intentamos embeber un vídeo en flash, en particular uno que usa un player y que carga el vídeo real mediante parámetros. Usamos la alternativa a javascript, por motivos de accesibilidad, y metemos un noscript. Para introducir el vídeo en la página web usamos la etiqueta embed, de manera similar a la siguiente:

<noscript>

</noscript>

Cuando intentamos validar la página según el Doctype XHTML 1.0 Strict, nos vamos a encontrar que no se permiten ni la etiqueta embed ni la noscript. ¿Cómo embebemos entonces un vídeo para los sujetos que o bien no tengan javascript o les apetezca empeorar notablemente su navegación desactivándolo?

1) Necesitamos la etiqueta object, que está permitida por este doctype y que además acepta la etiqueta param que contendrá los parámetros que necesitamos para mostrar el vídeo como queremos utilizando un reproductor específico.

2) Tal como está, la película aparecerá siempre, se asume que debajo del vídeo cargado directamente mediante javascript. Tendremos que ocultarlo para quienes tengan javascript activado.

Nótese el id de la etiqueta object. “Noscript” es el id que utilizaremos mediante javascript para referirnos a esta etiqueta y ocultar el objeto en caso de que el usuario tenga javascript activado. Escribo el siguiente script de javascript en un nuevo documento llamado noscript.js.

/* noscript.js */

En la página donde vayamos a introducir el vídeo cargamos el archivo mediante la etiqueta script usual. De esta manera, en caso de que el usuario no tenga javascript activado pasarán dos cosas: el primer objeto cargado por javascript no se cargará, y el objeto descrito anteriormente no se ocultará. El reproductor se cargará en ambos casos y pasaremos la validación del doctype strict.

Parámetros de la URL y doctype strict

joeloverbeck — Wed, 12 Aug 2009 07:15:07 +0000

Cuando nos lancemos a validar el doctype strict en una de nuestras páginas, seguramente nos indicará problemas con montones de enlaces. Esto se debe a que el doctype strict requiere que los & se encuentren codificados a su correspondiente &. Es algo que conviene tener en cuenta a la hora de programar si no se quiere tener que volver y buscar en cada página para hacer cada corrección a mano.

Insertar mapa de Google Maps sin iframes para cumplir el doctype strict

joeloverbeck — Mon, 10 Aug 2009 09:18:02 +0000

Insertar un mapa de Google Maps en una página usando un iframe es una forma sencilla, aunque obsoleta, de tener un mapa deprisa en la página web. Pero si uno ha de cumplir los estándares marcados por el doctype strict, hay que descartar la idea y usar javascript. Aquí tenemos un ejemplo que usa un único punto y que al hacerle click muestra la información pasada como un string.

<!– GOOGLEMAPS –>
<script src=”http://maps.google.com/maps?f=q&file=api&key=<%=GMAPS_KEY%>&source=s_q&hl=es&geocode=&q=Miramon+pasealekua+124+20014+Donostia-San+Sebasti%C3%A1n&sll=40.396764,-3.713379&sspn=11.774806,28.564453&ie=UTF8&z=14&iwloc=A&ll=43.301134,-1.967497&output=embed” type=”text/javascript”></script>

var gmarkers = [];

function load() {
if (GBrowserIsCompatible()) {
var map = new GMap2(document.getElementById(‘mapa’));
map.setCenter(new GLatLng(43.301134, -1.967497), 14);
var mm = new GMarkerManager(map);

// add the points
var point = new GLatLng(43.293134, -1.9720497);
var marker = new GMarker(point,{title: ‘Texto que saldrá al dejar el ratón sobre el marcador.’});
GEvent.addListener(marker, ‘click’, function() { marker.openInfoWindowHtml(“Texto que saldrá al hacer click en el marcador.”);} );
gmarkers[0] = marker;
mm.addMarkers(gmarkers, 0, 17);
mm.refresh();

}
}

//]]>
</script>
<div id=”mapa”>

</div>
<small><a id=”enlaceGoogleMaps” href=”http://maps.google.es/maps?f=q&source=embed&hl=es&geocode=&q=Miramon+pasealekua+124+20014+Donostia-San+Sebasti%C3%A1n&sll=40.396764,-3.713379&sspn=11.774806,28.564453&ie=UTF8&z=14&iwloc=A&ll=43.301134,-1.967497″ style=”color:#0000FF;text-align:left”>Ver mapa más grande</a></small>

El código se puede optimizar mucho, pero de momento quería documentar la solución deprisa.

HTML 5

jo — Fri, 07 Aug 2009 08:19:26 +0000

XHTML 2is dead, long live HTML 5! According to W3C News Archive, XHTML 2 working group is expected t

Adding a Doctype for displaying in all browsers

Ron Guilmet — Fri, 03 Jul 2009 13:33:46 +0000

Add before HTML tag.

DOCTYPE

Ron Guilmet — Sun, 28 Jun 2009 15:39:19 +0000

Start every web page with a DOCTYPE.

I put this here so I can have a quick reference to copy and paste.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" dir="ltr" lang="en-US">

Browser Compatibility Development Guide

Sudheer — Thu, 25 Jun 2009 19:53:32 +0000

Introduction

Creating cross browser web applications impacts the entire Software Development Life Cycle (SDLC). Impacted roles include project managers, web designers, architects, developers and quality assurance.

This guide for browser compatibility development has been designed to answer the following questions about developing cross browser web applications:

Is the browser compatibility problem a business problem?
What is the recommended browser compatibility solution?
What browser families do I need to support?
What environments and tools are required?
What are design and development best practices?
What are design and development pitfalls?
What additional resources are recommended?

The goal of this article is to provide the information needed to start or enhance a browser compatibility development practice in your organization.

Browser Compatibility Now and Then

At the turn of the century, web developers created applications which worked across Netscape and Internet Explorer (IE) browser families as each browser competed for market share. This was an arduous task due to evolving web standards and the lack of adoption across vendors. In the ensuing years, Internet Explorer won the market share battle, but not the war. The additional effort for building applications to work with Netscape was not warranted for many applications.

From the perspective of market share, the current situation looks much more like 2000 than 2003. There are now two very popular browser families, IE and Firefox. Other browsers such as Safari, Chrome and Opera have a significant presence as well.

From the perspective of web standards, it is a totally different game. Browser standards are stable and mature. Their adoption across vendors is very broad. While not a trivial task, it is much easier today to build web applications which work across browser families if standards are followed. Browser compatibility is more of a developer than a vendor problem today.

The Browser Compatibility Problem

Wikipedia defines “cross browser” as the ability for a website to support multiple web browsers. This is essentially what we mean by browser compatibility. In the past, new features were added to IE and Netscape without any coordination between vendors. This resulted in differences between how features worked ranging from slight cosmetic differences to profound conceptual differences.

Today, the maturity and adoption of web standards by vendors has standardized the feature set to a great extent. This is fortunate because the marketplace demands browser agnostic web applications. If your organization creates applications tied to a specific browser, it puts itself at the risk of turning away consumers and partners who prefer to interact with a particular browser. This is the browser compatibility business problem. If your website does not render or operate correctly on a user’s browser, it negatively affects your organizations image and brand. This means your applications should be browser agnostic to the highest degree practical.

The Browser Compatibility Solution

In the past, the requirement for cross browser applications was solved for by creating “forks” in the code to handle the peculiarities of supported browsers. This made it costly and difficult to create and maintain websites due to the redundant development and testing of the various code branches. When new browser versions were introduced, poorly designed forks often created additional work due to the change in browser behavior.

Web standards provide a much simpler solution for building cross browser applications. The web application is designed from the start to support web standards–not a particular browser. To a certain degree, this future proofs the web application from the introduction of new browsers and browser versions.

Structure, Presentation and Behavior Standards

There are three sets of World Wide Web Consortium (W3C) standards which describe the structure, presentation and behavior of a web page. There is also a key Ecma standard tied to manipulating the behavior.

The structure of the web page document is defined by markup language standards (HTML, XHTML, XML). The DOCTYPE descriptor tells the browser what document type definition to use in validating the structure and how strict to apply validation rules. The following DOCTYPE statements instruct the browser to strictly adhere to the HTML 4.01 and XHTML 1.0 specifications in validating the page.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<!DOCTYPE HTML PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN">

The presentation of the web page uses the CSS standard to control the colors, fonts and layout. CSS separates the content described in the document structure from how it is viewed in different contexts.

The behavior of the web page is controlled by the ability to manipulate a standard document object model (DOM) representation of the structure and presentation elements. ECMAScript, the standard version of JavaScript is the standard language used to manipulate the object model.

Adherence to structure, presentation and behavior standards (and not vendor specific adaptations of these standards) is the essence of the browser compatibility solution.

What Browser Families Should You Support?

You need to consider which browser families, operating systems and configurations are preferred by your customers, partners and employees. In order to understand your audience specifically, you will need to examine the web analytics particular to your web application.

There are many industry resources which provide browser usage analytics. These should be reviewed regularly to stay top of trends. An example is the following W3C website: http://www.w3schools.com/browsers/browsers_stats.asp.

In general, Firefox and IE are the most popular browsers. A good starting point in your browser compatibility practice is to minimally provide formal support for these two browser families, meaning you will fully verify them through the entire software development life cycle. By following web standards, you will be well positioned to support additional families such as Chrome, Safari, Opera or others if required by your audience with minimal additional effort.

In addition to the browsers supported, you should also pay attention to the types of devices and operating system versions being used as well so you can test your applications in environments similar to those being used by your customers, partners and employees.

What Environments and Tools are Required?

A browser compatibility solution requires the properly configured development and quality assurance environments to support web designers, architects, developers and quality assurance personnel throughout the software development life cycle (SDLC).

Development Environment

Web designer and developer desktops will need to be configured with the primary supported browsers. Firefox and Internet Explorer should be considered at minimum. If your audience demands it, other browsers such as Chrome, Safari and Opera should also be included.

Because Firefox more strictly adheres to structure, presentation and behavior standards, it should be the primary browser for development. Firefox should be configured as the default browser on the desktop and in your IDE (Integrated Development Environment), for example, Eclipse. Although Internet Explorer is not the primary browser, it should be utilized in unit testing.

Debugging tools are essential in developing cross browser applications. Firebug and Web Developer are two essential plug-ins which should be included in your Firefox configuration. A rich toolset and plug-in ecosystem is another advantage of the Firefox browser for designers and developers.

QA Environments

Quality assurance environments may be provisioned on site, or remote services may be used. A remote service may be useful for testing odd or uncommon browser and operating system combinations.

Whereas developers and designers should be using Firefox as their primary browser, quality assurance personnel should spend more time with Internet Explorer. This creates balance in the development and testing activities across the primary browser families.

Browser Compatibility Design and Development Best Practices

The following is a starter list of best practices for browser compatibility design and development.

1. Use Firefox as the primary browser for development
The Mozilla team designed Firefox to support W3C standards from the ground up. Because Firefox adheres more strictly to standards, it is much easier to develop a web application on Firefox and then get it to work in Internet Explorer than the reverse. Development IDE such as Eclipse should be configured so that Firefox is the default browser.

2. In development, periodically test the application in Internet Explorer and other supported browsers
Throughout the development phase, test the application in IE. Prior to Quality Assurance, thoroughly test the application in IE. Utilize your onsite or remote compatibility lab to test different versions within the supported browser families.

3. Use IE as the primary browser for Quality Assurance
A significant percentage of end users prefer Internet Explorer. Quality assurance testing the application developed primarily with Firefox on IE will ensure that any IE compatibility issues missed by developers in their unit testing will be identified. The application should also be regression tested versus all supported versions in the IE and Firefox browser families as well as other formally supported browsers.

4. Specify a DOCTYPE to explicitly declare the structure of the web page
A DOCTYPE specifying strict use of HTML or XHTML is recommended. Not being careful in the DOCTYPE declaration can throw a browser into what is known as “Quirks Mode” which allows invalid and vendor specific markup. A page developed unknowingly in quirks mode will not render consistently if at all with other browsers. The strict DOCTYPE keeps you honest in adhering to standard and valid markup document structure.

In Firefox, the “Page Info” dialog box (available from Tools, Page Info) specifies the rendering mode currently in effect. In addition, the document.compatMode property can be checked programmatically.

Although a “strict” DOCTYPE and standards compliance mode are recommended, each project must determine the level of warnings which are acceptable. It is quite possible to have an application that works fine with Firefox and IE, but still has items flagged by validators such as missing alt tags.

5. Utilize global CSS to separate document structure from presentation and to abstract browser presentation differences
Utilize CSS libraries to control the presentation across the site and encapsulate browser differences in the box model which controls white space around block level elements. Any presentation code such as font tags should be forbidden from the markup document and included in the CSS.

6. Use 3rd party libraries in lieu of custom JavaScript code for cross browser support
If you find yourself writing cross browser code, it should raise a red flag. It is a much better practice to use a 3rd party library which has been built and tested for cross browser support. For example, Ajax solutions such as Dojo provide JavaScript libraries which were built from the ground up for cross browser support and accessibility.

7. Utilize Firebug and Web Developer Plug-ins
The Firebug and Web Developer Plug-ins provide a wide variety of features designed to help validate, analyze, debug and correct browser compatibility issues. Try to avoid putting alerts in your JavaScript and markup for debugging which must later be removed. It is very easy to inspect and manipulate the structure, presentation and behavior elements of your web page at run time using these tools.

8. Develop a Browser Compatibility Knowledge Base
Create a Browser Compatibility Knowledge Base to catalog and share browser compatibility lessons learned, perhaps beginning with the previous seven items outlined here. This knowledge base can be as simple as a shared document or wiki.

Browser Compatibility Design and Development Pitfalls

The following is a starter list of pitfalls to avoid in the design and development of cross browser applications.

1. Avoid browser specific plug-ins – The whole purpose of creating cross browser applications is not being tied to a specific browser family. Browser specific plug-ins such as ActiveX controls are a detriment to compatibility.

2. Avoid code forks – If you find yourself coding JavaScript which says if(isIE6), you are introducing a fork, and a non standard feature into the web application. This will create duplicate development, QA, maintenance and production support activities. In addition, this code is likely to cause additional re-work as new IE or Firefox versions are introduced or other browsers such as Chrome or Safari are supported.

Your first course of action is to use standards to meet the stated requirement. If the requirements cannot be met without standard features, then it is better to create a fork which tests for a particular feature such as if (document.getElementById).

3. Not considering the implications of what CSS hacks are used – CSS hacks take advantage of browser deficiencies in supporting standards. These hacks may be used to encapsulate browser compatibility issues. However, care must be used to ensure they do not create maintainability issues, nor impede behavior in future browser versions.

Summary

Browser compatibility is more than a technical problem. It is a business problem. If your website does not render and operate properly on the browsers your customers and partners prefer to use, it may harm the reputation of your organization and turn customers away.

Ensuring browser compatibility of your web applications begins with understanding your end users needs. Compatibility development standards and practices to meet these needs must be defined for your organization and embedded into the entire software development lifecycle. Creating browser compatible applications affects the day to day job of project managers, web designers, architects, developers and quality assurance personnel.

Web standards which define the structure, presentation and behavior of a website are the cornerstone of a browser compatibility development practice. Adhering to these standards make what was once a very arduous job more manageable.

The proper environments and tools are needed for developers and quality assurance personnel to test for browser compatibility and to debug problems. These tools and environments should be designed and configured to simulate the user experience of your audience.

There are a number of best practices and pitfalls shared in this article. Creating a browser compatibility knowledge base will help capture the lessons learned and to share them with the broader development community.

Do you have the statistics which show what browsers your customers, partners and employees prefer to use? Do you have defined standards for creating web applications which will support these browsers? Do you have the appropriate environments and tools to test and debug for browser compatibility? Do you have a knowledge base to share lessons learned and best practices? If your answer is no to any of these questions, consider using the information presented here to start or enhance a browser compatibility development practice in your organization. The rest is up to you!

Browser Compatibility Resources

Anyone wanting to study browser compatibility in more detail would do well to start here.

Developing Web Applications Using Standards

Designing With Web Standards by Jeffrey Zeldman
Migrate Applications from IE to Mozilla by Doron Rosenberg
Using Web Standards by Mozilla
Web Standards Checklist by Max Design
The Business Benefits of Web Standards by Mozilla

Validation Services

W3C markup validation service
W3C CSS Validation Service
Mozilla DOCTYPE Sniffing

Starting a Web Page in HTML

alphaorganic — Sun, 21 Jun 2009 02:20:07 +0000

This tutorial will be going over the basic HTML structure including how to create new paragraphs, headers, page breaks, comments, and more. By learning to create a clear and consistent structure you will be able to apply elements easier in the future development of your web page.

[images coming soon]

[recommendation: When creating a web site we recommend a web development software such as "Dreamweaver" which is great for automatically generating tags. If you do not have access to a web development software this tutorial will still work with a simple word processor saved with the .html extension]

Lets Begin.

Before you can begin your HTML page you need to first declare a DOCTYPE at the top of your html page. For the purpose of this tutorial we will be using the following DOCTYPE: (you may copy and paste)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

<html>

I will not be going into further details on DOCTYPES buy you may visit http://www.w3.org for more information.

The <html> tag will begin the actual HTML portion of your document. Be sure to close the document with </html>

There are two main sections for a basic HTML page. The head and body section. The head section is generally where you would define the title of your page, meta tags or information about your page for search engines, the location of your page, where to add style sheets, and where you would write other scripts.

To create the head section type <head> directly after the opening html tag. To close the head section simply type </head>

The body section of your page will contain the content of your web page. This is the section that where you will display the text and graphics for your visitor to see.

To create the body section type <body> following the </head> tag. To close the body section simply type </body>

Now, its a good idea to declare the encoding of an html document. This will make it easier for different browsers with different default encoding to view the page properly. To declare the character encoding in the head section of your page type:

<meta http-equiv="content-type" content="text/html; charset=encoding" />

where encoding is the character encoding with which you saved the file. For the purpose of this tutorial we will use the encoding “UTF-8″

Next thing you will want to do is define your page a title. The title is short and descriptive and will be displayed on the title bar of your browser. To create a title type <title> anywhere following the opening <head> tag and type in the title you would like to appear and close it with </title> like so:

<title> Alpha Organic Blog </title>

The title will also appear in the history lists of your browser and will also affect the pages ranking in a search engine.

It is time to begin creating the content of your page. You will most likely want to highlight certain section or body’s of your page with headers. To do this you can type <hn> where n is a number from 1 to 6 depending on the level of header that you want to create followed by the contents of the header and finally close it with </hn>

Next you will want to create a new paragraph following your header. To begin a new paragraph type <p> followed by the contents of the paragraph and finally closing the paragraph with </p> If you would like to create a space within the paragraph you can always start a new paragraph with <p> tag or type &nbsp (a non-breaking space) within the same <p> element.

You can also give your HTML elements either a unique name with and “id” or a name that identifies it to a particular “class” . These naming techniques (or attributes) will come in handy when developing your web page further in the future when applying for example styles sheets that require certain elements to be identified. These topics will be touched on in other tutorials but it is important to learn now how and where to apply them. To apply an “id” or “class” type id=”name” or class=”name” within the opening tag of the element.

<h1 id="Alpha Organic News">News</h1>

To further organize page you will next want to break it up into divisions. Breaking your page up into divisions allows yo uto apply styles to entire chunks of your page at once. This again will be useful in the future when applying style sheets. To do so at the beginning of your division type <div and if desired give it an id or class and complete it with </div>

<div id="music">

*content*

</div>

In your page you will most likely want to stop your text from wrapping. The simple solution to this problem is to but a line break tag where you think a line break should occur. To insert a line break just type <br />

<br />News <br />Music <br />Audio/Video <br />Interactive, Web, and Design

A useful thing to do when making your web page is to include notes or comments as you go along. This is helpful when you want to refer to certain points in your page code to remind yourself or someone else why certain elements and code exist. To do this all you have to do is type <!– followed by the comments and close with –>

To help your viewers understand what they are viewing you may also choose to include a title to certain chunks or elements of your page. To do this type title=”label” within the tag you wish to label. It will look something like this:

<div id="music" title="music samples">

*content*

</div>

For next lesson click Basic HTML Formatting or click HERE for all HTML tutorials.

Página em branco no IE8

hlibco — Mon, 08 Jun 2009 02:45:50 +0000

Seu site simplesmente não renderiza mais no IE8?
Uma solução (trick) bem rápida é adicionar a seguinte meta tag:

Com isso, o navegador irá renderizar a página com “olhos” de um IE7. A idéia é que no futuro seja possível definir que o IE renderize como sendo um FF… Chega logo esse dia, chega logo!

30 HTML Best Practices for Beginners

Mobu — Tue, 02 Jun 2009 07:44:15 +0000

Source: http://net.tutsplus.com/tutorials/html-css-techniques/30-html-best-practices-for-beginners/

Just for your curiosity, I am naming the main 30 practices:

Always Close Your Tags
Declare the Correct DocType
Never Use Inline Styles
Place all External CSS Files Within the Head Tag
Consider Placing Javascript Files at the Bottom
Never Use Inline Javascript. It’s not 1996!
Validate Continuously
Download Firebug
Use Firebug! (duh!)
Keep Your Tag Names Lowercase
Use H1 – H6 Tags
If Building a Blog, Save the H1 for the Article Title
Download ySlow
Wrap Navigation with an Unordered List
Learn How to Target IE
Choose a Great Code Editor
Once the Website is Complete, Compress!
Cut, Cut, Cut
All Images Require “Alt” Attributes
Stay up Late
View Source
Style ALL Elements
Use Twitter
Learn Photoshop
Learn Each HTML Tag
Participate in the Community
Use a CSS Reset
Line ‘em Up!
Slice a PSD
Don’t Use a Framework…Yet

Hvordan får jeg hjemmesiden min synlig med doctype?

Helge — Tue, 26 May 2009 05:30:40 +0000

Dette er del 2 av en serie artikler om hvordan du kan øke synligheten på ditt nettsted hos søkemotor

Available XHTML doctypes

londonengland — Fri, 15 May 2009 07:00:42 +0000

There are three XHTML 1.0 doctypes available, plus one XHTML 1.1 doctype. The XHTML 1.0 doctypes are Strict, Transitional, and Frameset (to be used only when you are using frames to lay out your documents), and they differ only in the FPI and URL:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Frameset//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd”>

The XHTML 1.1 doctype also differs only in the FPI and URL, and it comes in only one variant rather than Strict and Transitional versions:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.1//EN”
“http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd”>

There is also a doctype for XHTML Basic, a stripped-down version of XHTML used (mostly theoretically at the time of this writing) for pages designed for mobile devices such as mobile phones:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML Basic 1.0//EN”
“http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd”>

Purposes of doctypes

Doctypes in (X)HTML serve two important purposes. First, they inform user agents and validators what DTD the document is written to. This action is passive—that is, your browser isn’t going and downloading the DTD every time a page loads to check that your markup is valid; it’s only when you manually validate a page that it kicks in. The second and, for practical purposes, most important purpose is that doctypes inform browsers to render documents in standards mode rather than quirks mode. This is known as doctype switching, and it was included in browsers as a way of determining how to render a document, the assumption being that if an author has included a doctype, then that author knows what he or she is doing, and the browser tries to interpret the strict markup in a strict way (i.e., standards mode). The absence of a doctype triggers quirks mode, which renders the markup in old and incorrect ways, the assumption here being that if the author hasn’t included a doctype, then he or she probably is not writing standard markup, and therefore the markup will be treated as if it has been written in the past for buggier browsers.

DocType header - HTML

ucanhireme — Tue, 21 Apr 2009 05:00:46 +0000

HTML 4.01 Strict: http://www.w3.org/TR/html4/strict.dtd“>
HTML 4.01 Transitional: http://www.w3.org/TR/html4/loose.dtd“>
HTML 4.01 Frameset: http://www.w3.org/TR/html4/frameset.dtd“>
XHTML 1.0 Strict: http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd“>
XHTML 1.0 Transitional: http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd“>
XHTML 1.0 Frameset: http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd“>
XHTML 1.1 DTD: http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd“>

For more information see http://www.w3.org/QA/2002/04/Web-Quality

Set Document Type Information in Microsoft Expression Web 2

minals — Tue, 31 Mar 2009 15:21:41 +0000

DocType describes a Document Type Definition (DTD).The DocType declaration in your web pages let the browsers determine which version of HTML, the pages use. It also determines the schema the Expression Web uses to drive the incompatibility notifications and IntelliSense for HTML and script. If the DocType declaration is missing in your page then Expression Web uses a secondary schema; also displays a warning shown below, that indicates there is an incompatibility in your code with the HTML schema you have selected.

An example of a DocType declaration is given below:

<!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd”>

You can set a default DocType in Microsoft Expression Web to automatically insert the declaration in new pages. Follow these steps:

1. Go to Tools > Choose Page Editor Options

2. In the Page Editor Options dialog box, switch to Authoring tab and select the Doctype and Secondary Schema you would like to use.

If you do not want Expression Web to insert a DocType declaration in new pages you create, choose ‘None’ in Document Type Declaration dropdown box.

AJAX Accordion Control "Flickering" Issue while implementing in DotNetNuke Site

Kaushal — Mon, 16 Mar 2009 06:28:45 +0000

While working on DNN 5.0 site, I was trying to have a left menu navigation using AJAX Accordion. Even, I got succeeded in implementing that but i come accross an issue of – flickering the Accordion control in IE while opening and closing and navigating thru panes.

After googling, I came to know about the solution and applied which worked successfully.

Frist is, Turn off FadeTransitions Property, i mean set it to “False”, yes, its the cute effect everybody want to have while using accordion with. But, while I set it to false and removed the TransitionDuration property – The problem of flickering issue got solved. So, everybody speak with me – “I dont want FadeTransition effect in DNN with Accordion!”.

Read More…

Problem with "doctype" column name into SharePoint List

Sanket Shah — Fri, 13 Mar 2009 21:14:31 +0000

I was faced problem with column name “doctype”, I was not able to create “doctype” column with any of the data type into SharePoint List, and I was getting “Unknown error” into my page when I tried to create column. I tried to find the solution on the internet for some time, but I didn’t get good information, I believe that “doctype” column name is reserved for internal purpose, so we can’t use same name like ID, title column name.

Luckily I was able to create “doctype” as single line of text data type, now the actual problem started, I was not able to delete “doctype” column from SharePoint list, definitely we can write custom code and delete same column from code. But I have found easy way to delete “doctype” column from going to tool called “SharePoint Manager 2007” and I have selected my site-> list -> “doctype” column and delete from that tool. You can find more information regarding SharePoint manager 2007 from my blog, here is link http://sanketinfo.wordpress.com/2008/10/15/sharepoint-manager-2007-%e2%80%93-administration-tool/

Now if we have requirements to create “doctype” into list, then we can create same column name by changing character case. “doctype” column name is case-sensitive, like we can create column with named “DocType”