Re: [WSG] HTML 5 and XHTML 2 combined

And that's my point:

The best specs are those that take everyone's needs into account: users,
> developers, designers and browser vendors.


Why are the vendors the ones who are considered most important? It is not
JUST up to them, is it?

--
Brett P.


On Tue, Jan 20, 2009 at 2:25 PM, David Storey <dstorey@opera.com> wrote:

>
> On 20 Jan 2009, at 19:18, Brett Patterson wrote:
>
> 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.
>
>
> Not wanting to get into an argument, but if that is the case, who is going
> to implement the new specs if the vendors point, concerns and goals mean
> nothing?  If vendors don't get behind a spec and implement it then
> developers can't use it.  The best specs are those that take everyones needs
> into account; users, developers, designers and browser vendors.
>
>
>
> 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 <molte93@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.pattersonb@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, <olafBuddenhagen@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: memberhelp@webstandardsgroup.org
> *******************************************************************
>
>
> David Storey
>
> Chief Web Opener,
> Product Manager Opera Dragonfly,
> Consumer Product Manager Opera Core,
> W3C Mobile Web Best Practices Working Group member
>
> Consumer Product Management & Developer Relations
> Opera Software ASA
> Oslo, Norway
>
> Mobile: +47 94 22 02 32
> E-Mail: dstorey@opera.com
> Blog: http://my.opera.com/dstorey
>
>
>
>
>
>
>
> *******************************************************************
> List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
> Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
> Help: memberhelp@webstandardsgroup.org
> *******************************************************************
>