W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > November 2009

[Bug 8365] Remove the Web Browsers Section 6

From: <bugzilla@wiggum.w3.org>
Date: Wed, 25 Nov 2009 02:30:54 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1ND7eg-0001DT-UH@wiggum.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8365





--- Comment #14 from Shelley Powers <shelleyp@burningbird.net>  2009-11-25 02:30:54 ---
(In reply to comment #13)
> (In reply to comment #12)
> > > 
> > > Since ePub is defined as a subset of XHTML, it doesn't make sense to me to
> > > remove anything from the HTML5 spec on the basis that ePub doesn't need it.
> > > It's already a subset specification. 
> > >
> > 
> > I wouldn't remove any element of HTML because only one user agent uses only a
> > subset. But I don't think user agents should impose their own unique
> > requirements, either. 
> 
> I don't see anything specific to only one kind of client, but maybe you have
> some specific examples. 
>

There is significant sections of the specification that have little to do with
HTML, and mostly to do with browsers, or browser like objects. 

> > 
> > > > 
> > > > All applications that make use of HTML or XHTML have their own requirements and
> > > > needs. The appropriate procedure is to define specifications for the
> > > > application functionality, and leave the HTML markup for the HTML WG.
> > > > 
> > > 
> > > It's true that there are different kinds of HTML clients. HTML5 provides for
> > > this with a variety of conformance classes:
> > > http://dev.w3.org/html5/spec/Overview.html#conformance-requirements
> > >
> > 
> > There should be a simplified set of conformation requirements for all clients
> > related to HTML, XHTML, and the DOM.
> 
> Do you think there are any such clients not covered by one of the included
> conformance classes?
>

I think we're talking two different things here.

You seem to think that if there are enough clients who use the technology, it's
OK to include the technology in the HTML5 specification.

What I'm saying is that regardless of how useful the technology is to various
applications, if it's not specific to HTML, XHTML, or the DOM, then it is best
handled in a separate specification. 

By separating the material, instead of one large, complex specification, with a
confused sense of audience, we have two simple, lucid specifications, with a
clear idea of audience.



> > 
> > > It clearly says that non-scripting UAs are exempt from implementing any of the
> > > scripting features, for instance. The scripting features in section 6 don't
> > > look any different to me in this regard than other scripting- and event-related
> > > requirements throughout the spec.
> > >
> > 
> > Again, though, I don't think that we should be including application specific
> > requirements into what should be a general markup language, and associated DOM. 
> 
> None of the requirements are specific to only one kind of application, if
> that's what you mean. I believe I showed that all the subsections of section 6
> apply to a wide variety of clients (though some may not apply to specific kinds
> of clients such as non-scripting UAs).
> 


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Wednesday, 25 November 2009 02:30:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:01:05 UTC