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 <[email protected]> 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 <[email protected]>
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, <[email protected]> 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: [email protected]
*******************************************************************
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: [email protected]
Blog: http://my.opera.com/dstorey
*******************************************************************
List Guidelines: http://webstandardsgroup.org/mail/guidelines.cfm
Unsubscribe: http://webstandardsgroup.org/join/unsubscribe.cfm
Help: [email protected]
*******************************************************************
