anonymous

• Person

anonymous replied on 2006-12-14 16:17:18

<div typeof='oa:TextualBody' resource='#note-20061214161718' property='rdf:value' datatype='rdf:HTML'> <p>A Proposed Recommendation is still a "work in progress" and may still be updated, obsolete, and replaced. But even if it does not imply any official endorsement by the W3C, most often a Proposed Recommendation is close to the final Recommendation both in content and in time.</p></div>

• Annotation
• Note

Ara Pehlivanian

• Person

Ara Pehlivanian replied on 2006-07-19 18:59:08

<div typeof='oa:TextualBody' resource='#note-20060719185908' property='rdf:value' datatype='rdf:HTML'> <p>Everything in moderation... going zealot doesn't help anyone. All you end up doing when you become a fanatic is lose focus and take the purpose of web development way out of context. Real web development isn't building blogs that validate. Real web development is meeting your clients requirements in the best way possible. That includes not only conforming to standards, but making sure you also fall within budget, deadline, and user base constraints. You can't just drop your head and run headlong toward "web standards, web standards, web standards" and trample everything else in your path. You need to think "business" as well as "conformance".</p> <p>Besides, who ever said the W3C recommendations were gold? If anything, technical specs should NEVER be left open to interpretation. What kind of silliness is that?</p></div>

• Annotation
• Note

Emil Stenström

• Person

Emil Stenström replied on 2006-07-31 15:41:20

<div typeof='oa:TextualBody' resource='#note-20060731154120' property='rdf:value' datatype='rdf:HTML'> <p>"Design for today" is a good point but it leaves a lot of space for interpretation. Some think that tables for layout is "today" and some think not. Determining this is not something we can get help from the standards bodies with, they are busy with CSS4. </p> <p>Instead I think a good way is to read and talk with a lot of real web developers and ask them what's the best way of making a website is. Today I wouldn't say that they would answer "tables for layout" any longer.</p> <p>I also have to disagree with suv4x4: The use of technology have very little to do with whether someone picks your product or not. Suv4x4's comment about breaking away from current best practices for the best of the customer have never been more false.</p></div>

• Annotation
• Note

How should we incorporate W3C's recommendations into our Web development?

The W3C specifications are sound; in most cases, but they are incomplete. Therefore, there exists a lot of room for interpretation when it comes to Web site development. Allow me to start with a common recurring issue; with respect to today's W3C specifications and whether or not they are in-line with how we want our Web documents to function, it is all part of natural progress. For instance, tables for layout were okay to use in the 90s because they did the job at the end of the day (relatively speaking), however, today, depending on needs, we most likely can't say the same for table based layouts. Today, floats for layout is considered to offer the most viable solution. However looking at where CSS3 is heading and even the Markup structures, float based designs most likely will not be 'the' layout solution for tomorrow's Web. If the Consortium's recommendations are always in an evolutionary process, how then are we to develop sites? Let me put it this way; today's competitive sites - in the interest of getting attention - are constantly in change. Whether they are presenting cutting or bleeding edge technologies in the field or simply even on the Web to have presence, to some extent, they require updates and maintenance. Realistically speaking, those sites that fall into these categories are in need of an update at most every 3 years (take this number with a grain of salt) by today's standards. So then based on this important bottom line, can we raise the following conjecture; design for today and the very near future if resources allow as such. Now you may be saying, what about... ya but.. so? The point is to accommodate for today's needs and not to worry about the tidbits of development as if it were to be a one time solution for the next 10 or 100 years to come. If you are in the Webdev business and interested in this field for many years to come, then allow me to suggest; do not worry. The Web is constantly evolving and at this far in the game, the Web as you know it will not be the same in 5, 10 or any x number of years. I am perhaps stating something very obvious here, yet it is apparent that it is widely overlooked. On the other hand, it is essential to keep this in mind: how costly will it be to bring today's documents up to speed in 5 years - facing extensibility? The answer is hidden within compromising among possible solutions from the marketability standpoint. If you love this art form, do know the specifications well as it suits your needs, yet at the same time do acknowledge its shortcomings and the very nature of Web's evolvement. I tell you, this is the compromising I speak of when you have to get things done. These technologies are merely tools, and they are here to help us with our work. One must not go the other way around by altering the requirements of their projects just to satisfy incomplete specifications. There is a good chunk of developers out there that takes pride in doing things the right way. The very nature of this mentality exist for two reasons. First being the separation of the level of their competency from the rest of the developers that do not or in-need to follow the best practices. This can essentially open up many opportunities as they may seem to better fit to take on projects then the other developers. Who is to question then for such accomplishment if they are certainly more equipped to do the job well? However, there remains one important point; being technically savvy is not always in positive correlation with having good business sense. Secondly, there seems to exists a rush to being the purist when it comes to the W3C recommendations. The Standards developers can then only show their competency among other developers whom already follow the good practices. By this, there exists a perception of being more competent then the average good developer, yet overlooking the core project goals. For instance, many Web standards designers can push their knowledge and proper way of applying the W3C documents, yet neglect to apply them in the right places. For small scale, personal, focused target audience sites, this idealistic approach will do wonders and allow them to achieve the most respect within the community, yet the same practices in which they preach of do not necessarily play well with all the complexities of sites where the user base, scope, and the goals of the site vary. May we remind ourselves that the W3C's specifications are only recommendations? Perhaps it should have been termed differently like; rules or laws, in which the resulting practices would possibly have been different. I personally tend to think of them as good guidelines. If they make sense to you for your real-world development then who is to stop you from using them? Not to mention most of the established specifications have been through a lot of revision by many people, groups, and organizations to push them forward to suit the needs of today's and future's Web. A lot of resources have already been allocated and used on establishing such practices and it would be foolish in my opinion to not take advantage of this but to integrate them in our work. In most cases, they are beneficial to us. What I'm trying to say is, use your best judgment when it comes to W3C and other Web technologies, and make the best out of what's suitable to your needs. Thank you for reading.

• Article
• CreativeWork
• Document
• Entity
• Post

Lennart Goosens

• Person

Lennart Goosens replied on 2011-10-26 01:57:06

<div typeof='oa:TextualBody' resource='#note-20111026015706' property='rdf:value' datatype='rdf:HTML'> <p>I agree with the point of departure of the article. Bad designers ignore standards, good designers adhere to them, and the best designers are intelligent enough to know when the rules stop being applicable. Common sense kicks in.</p> <p>In fact, a designer who wouldn't even break a rule when abiding by it yields bigger problems than it solves, is not unlike an Immanuel Kant adherent who wouldn't lie, even to save lives. What duty-based ethics and web standards have in common, is that they both provide a very sturdy framework, aiding us in deciding WHAT IS RIGHT. They're great, but all too often, people trade in common sense for blind reverence.</p> <p>"One must not go the other way around by altering the requirements of their projects just to satisfy incomplete specifications." Because that would be like Microsoft's approach to backwards compatibility - staying compatible with a precursor built like a card house is never worthwhile. XD</p> <p>Now, I do think you made a few (possibly) false assumptions, or at least omissions.</p> <p>1. You seem to assume that each and everyone of the people reading this is fully adept in web design, and can make a right judgment on the applicability of standards each and every time. However, some people, especially those who haven't yet fully grasped the abstract concepts behind separating structure and form, might even see this as an excuse to perpetuate bad design practices. Causing bad user experiences every day. (._.) 2. The attitude towards standards adherence shouldn't be dictated by economics and scale alone, but also by the very nature of the content that is being represented. While this pragmatist attitude will yield excellent results for an online store, it could turn out very badly when dealing with archival, historical and similar content, that will be stored for decades or even hundreds of years, and needs to remain legible whatever the case. It simply wouldn't be viable to make changes and fixes to those documents every few years or even decades. 3. I could be very wrong, but I don't think using tables for layout was ever a recommendation by any standards body. The number of standards being dropped, elements being deprecated; in other words the pace of evolution, has been catalysed a lot by bad design practices (and emerging new possibilities, of course), necessitating further development of standards. However, I feel that those efforts are directed for a large part towards decreasing the need for future game changers, and making the implementation of the remaining few easy for designers/authors. For instance, separating structure and form save us editing unbelievable amounts of spaghetti HTML code, even when most of HTML would be rendered a thing of the past.</p> <p>(Also, hasn't the standards movement mostly been about either restoring or pushing forward concepts that where conceived at the very beginning of the web? I guess it's too early to tell whether standards will keep evolving at this pace, and whether they will need to.)</p> <p>(I would like to hear more of your thoughts on this topic if at all possible)</p></div>

• Annotation
• Note