OpenWack Community Software Blog

Everyone of you saw those fancy labels on sites and software products indicating that the page markup passed W3C validation.

Hereby I claim that W3C validation will not be the priority of OpenWack pages markup nor will it ever be a requirement for OpenWack themes and plugins.

W3C standards were introduced with a good idea of validating HTML and CSS to be supported by all generally available browsers. But the reality is that they bring unnecessary restrictions and do not guarantee anything.

For example, putting block elements in <a> will not validate. Tag <object> (for a flash video player e.g.) will not validate. Although both those examples are handled fine by all relevant web-browsers of today. Why restrict then? These are examples of XHTML Transitional, I’m not even speaking of XHTML Strict.

On the other hand you can write W3C compliant code but there’s no guarantee that it will work in IE7 or (oh god) in IE6. It’s absolutely necessary to test your code in these browsers and even write some CSS hacks to handle their misbehavior. Microsoft did a great job of creating this mess.

I understand why software like Adobe Dreamweaver will generate W3C-compliant markup at all costs. This is marketing and is aimed at people who know what W3C validation is but are not aware of its failure. So realistically for now these are just labels. And they significantly contributed to the wide adoption of the standards that fail to bring the order.

We will try to maintain those standards wherever reasonable but not for the sole purpose of staying compliant with them. Given the mentioned shortcomings we do not see big reasons to comply.

There’s a much more effective practice of just testing all your markup in all major browsers people use. That’s the only relevant validation you can get to write software aimed at providing adequate user experience.

During the first months of planning and development we’ve elaborated the detailed picture of our goals with the OpenWack product and what it will try to achieve in the Web. I tried to formulate a short description of the main points that you can now read, evaluate and ask questions about.

We welcome any feedback on how our mission speaks to you and what we can do to serve your needs better.

OpenWack Mission Statement

We currently work on the engine of HTTP forms for OpenWack core that will be used everywhere: on the user pages, admin area, and plugins. Needless to say, it’s an important task to make forms as easy to operate as possible meanwhile retaining flexibility.

For example, 80% of admin area will consist of forms in their basic incarnation, such as listing sectioned fields of settings with “Submit” button. On the other hand plugins may require all kinds of forms, response types, before-submit validations and all.

A basic form is going to have default decorator. This can be overridden right in the markup if your form requires that. Also you will be given program tools to control submit methods, Ajax, validation, and so on.

Forms, as a critical part of the OpenWack core is most likely to have several iterations through the product versions to mature but at this point we have a very good understanding of their requirements. We have seen them all with other Skalfa products. OpenWack will contain all technical experience of the company and introduce our understanding of the current and future community software market.