I would feel everyone in cooperation would be the way to go. Browser vendors (going to call them vendors, for short) need to understand that just because they want what they want does not matter as much as what is needed. If a major change is needed and vendors do not want to follow along, then so be it. If every vendor's ideas differed in some respect, then every browser would become an "Internet Explorer -type" browser. One that does not follow suit with the way things ought to be, in IE's case, is. It should be said to them that whole "fact," to save everyone the headache of trying to design for every different browser and what that browser supports/does not support. Sorry, but it is a bit of a touchy subject, especially considering the amount of work that one has to put in with others to get *EVERY* browser to play with one good block of code.
How do you imagine this could be reconciled? If you hijack HTML5 to > effectively become XHTML2, browser vendors will just again come up with > something different conforming to *their* goals. (HTML4.5 or whatever.) > Their goals are not as important as what the whole idea of the Web is, and Tim Berners-Lee's/CERN's goals for the Web. Which is, as one major part (responsibility of advocates/vendors/anyone with any part of the Web), universal accessibility. When vendors design for their own goal(s), they are not living up to that responsibility; therefore, their points and concerns mean *NOTHING*, and can be dismissed without a split-second thought, when it comes to the working groups and what is deemed necessary to reach that goal of universal accessibility. And to Benjamin Hawkes-Lewis, to answer your earlier questions When you speak of browser vendors mixing "old languages with the new", I'm > not sure what you mean, or why it is a problem. > The below also explains the above quote of your question. The problem is, that we need to drop what really is heavy and unnecessary luggage, (this luggage being what is not supported in XHTML 1.0 Transitional, at least by my view points). "Rift-raft," as Philip said is, "the baggage of earlier, arguably poorly thought out, standards." You mentioned creating Transitional and Strict document types, but it's > unclear what user problems this would solve or how exactly it would help > merge HTML5 and XHTML2. I meant this in the sense of the current X/HTML transitional and strict approaches, as in the reason they were developed rather than just a Strict or Transitional approach (not implementing both, in HTML and XHTML). It could help merge them and solve problems by identifying any conflicting parts of the Standards, any conflicts that you can see that might take place. Focus on the Code that goes into a web page first, you have a small portion of differences that can be resolved by dropping the "luggage of earlier, poorly thought out standards." Why would combining HTML5 and XHTML2 would prevent browser developers > inventing their own language features? This is best answered by reading the 3 previous posts from this one. What "headache" are you talking about? The headache stems from the different code necessary to force IE to play nicely and the different codes each browser has made especially for itself (understand the question above about inventing their own language features, where we completely ignore them). But, anyway, like I said, I read your links and can now agree with you. I was just trying to answer your previous questions, not stir up another argument. -- Brett P. On Tue, Jan 20, 2009 at 11:45 AM, Molte <molt...@gmail.com> wrote: > Indeed they should. > > The problem just might be, that if the browser vendors do not like the > language they can simply just avoid supporting it (just like going on a > strike). And then what idea is there of a standard that is not supported or > used? > > It's just a question about who has the power to decide the future of the > Web. The browser vendors? the coders/developers? "us"? or just everyone in > cooperation? > > 2009/1/20 Brett Patterson <inspiron.patters...@gmail.com> > > Okay, long time posted in this subject. I see where Benjamin is heading >> with his discussions, and I agree with him. Took me awhile to read and >> understand his links. But, Olaf, why are browser vendors allowed to choose >> what is right and wrong with HTML and XHTML, and coders are to play along, >> and the working groups that build upon HTML and XHTML (work with it, fix it, >> whatever) suppose to conform to browser vendor's goals? They should not be >> allowed to tell working groups what should and should not be allowed! It is >> not up to them. If it is, what is the purpose of the working groups? Are the >> working groups composed only of browser vendors, or both designers/coders >> and browser vendors? Vendors should be made to follow the standards and >> codes, and ideas and goals of the working group, should they not? >> >> -- >> Brett P. >> >> >> >> On Tue, Jan 13, 2009 at 3:10 AM, <olafbuddenha...@gmx.net> wrote: >> >>> >>> Hi, >>> >>> On Fri, Jan 09, 2009 at 06:50:18PM +0000, Philip TAYLOR (Ret'd) wrote: >>> >>> > I am arguing that HTML 5 should stop carrying with it the baggage of >>> > earlier, arguably poorly thought out, standards and should rather have >>> > the courage to propose how things will be expressed /in the future/. >>> > By definition, this will require browsers to parse (and process) HTML >>> > 5 documents differently to how they parse and process documents >>> > conforming to earlier standards (and, of course, how they parse and >>> > process documents that lack a DOCTYPE directive and which therefore >>> > cannot be safely assumed to conform to any standards whatsoever). By >>> > so doing, HTML 5 could define the <IMG> element to be a container (in >>> > HTML 5), even though it was not a container in previous >>> > specifications. >>> >>> I think this is precisely what XHTML2 set out to do. >>> >>> HTML5 came up because browser vendors didn't agree this is the right >>> way... >>> >>> How do you imagine this could be reconciled? If you hijack HTML5 to >>> effectively become XHTML2, browser vendors will just again come up with >>> something different conforming to *their* goals. (HTML4.5 or whatever.) >>> >>> -antrik- >>> >>> >>> >> > > > -- > Molte > > CosSinCalc > http://cossincalc.com > ******************************************************************* List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm Help: memberh...@webstandardsgroup.org *******************************************************************
