* Simon Pieters wrote:
>I propose that some members of the HTMLDocument and HTMLElement interfaces
>that are also useful for non-HTML documents and non-HTML elements are
>moved either to Document and Element or to DocumentWithUsefulStuff and
>ElementWithUsefulStuff interfaces (possibly with
Simon Pieters wrote:
HTML5 says that all Document objects must implement HTMLDocument and
other supported interfaces. I presume it says so in order to dodge the
question of when to implement which interface
And also because when using mixed-namespace documents it really does make sense
to ha
On Tue, 21 Aug 2007 19:43:05 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
wrote:
* Simon Pieters wrote:
would be any kind of improvement. You would have to explain why they
need to be on Document rather than on a DocumentWithUsefulStuff inter-
face. Clearly adding them to Document would make
* Simon Pieters wrote:
>> would be any kind of improvement. You would have to explain why they
>> need to be on Document rather than on a DocumentWithUsefulStuff inter-
>> face. Clearly adding them to Document would make implementers who do
>> not and do not plan to implement HTMLDocument anywhere
On Tue, 21 Aug 2007 18:36:16 +0200, Bjoern Hoehrmann <[EMAIL PROTECTED]>
wrote:
As for the specific issue:
We're not happy with implementing the HTMLDocument interface on all
Document objects. It will affect all other types of documents and the
naming of their members in the future, and an
I agree with Stewart that it would be a mistake to put innerHTML and other
such things on the Element interface. The Core XML DOM also supports XML
data files and should not include features that are specific to user
interface languages such as HTML.
I am not sure what the motivation is for gener
* Charles McCathieNevile wrote:
>This is from the HTML group, but my first impression is that Simon is
>right. Unfortunately my other first impression is that nobody is currently
>really working on the relevant specs - is that true?
As far as the Web API Working Group is concerned, Simon woul
"Simon Pieters" <[EMAIL PROTECTED]> wrote:
>
> On Tue, 21 Aug 2007 17:23:47 +0200, João Eiras <[EMAIL PROTECTED]>
> wrote:
>
> >> Does this make sense on Element? I mean, the class attribute and it's
> >> semantics are HTML/XHTML specific.
> >
> >
> > The same goes for innerHTML. I agree ther
On Tue, 21 Aug 2007 17:23:47 +0200, João Eiras <[EMAIL PROTECTED]>
wrote:
Does this make sense on Element? I mean, the class attribute and it's
semantics are HTML/XHTML specific.
The same goes for innerHTML.
I agree there could be a generic property to access the markup directly,
but
i
On Tue, 21 Aug 2007 17:13:55 +0200, liorean <[EMAIL PROTECTED]> wrote:
On 21/08/07, Simon Pieters <[EMAIL PROTECTED]> wrote:
We'd rather have the members of HTMLDocument that are useful for all
types
of documents to be moved to the Document interface. This would probably
be:
* locatio
2007/8/21, liorean <[EMAIL PROTECTED]>:
>
>
> On 21/08/07, Simon Pieters <[EMAIL PROTECTED]> wrote:
> > We'd rather have the members of HTMLDocument that are useful for all
> types
> > of documents to be moved to the Document interface. This would probably
> be:
> >
> >* location
> >* URL (
On 21/08/07, Simon Pieters <[EMAIL PROTECTED]> wrote:
> We'd rather have the members of HTMLDocument that are useful for all types
> of documents to be moved to the Document interface. This would probably be:
>
>* location
>* URL (also present in SVGDocument)
>* domain (also present in
This is from the HTML group, but my first impression is that Simon is
right. Unfortunately my other first impression is that nobody is currently
really working on the relevant specs - is that true?
cheers
Chaals
--- Forwarded message ---
From: "Simon Pieters" <[EMAIL PROTECTED]>
T
Hi Charles & everyone,
Charles McCathieNevile wrote:
On Thu, 16 Aug 2007 19:56:59 +0200, Travis Leithead
<[EMAIL PROTECTED]> wrote:
Recently, a member-only vote was held
to attempt (yet-again) to resolve general complaining, grumbling, etc.,
about the latest API names chosen for the Select
14 matches
Mail list logo
