Bug 27603 - updating Document.idl to match HTML5 spec: domain read-write and access to getSelection
Summary: updating Document.idl to match HTML5 spec: domain read-write and access to ge...
Status: UNCONFIRMED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC OS X 10.5
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-07-23 03:04 PDT by Luke Kenneth Casson Leighton
Modified: 2010-06-10 18:44 PDT (History)
1 user (show)

See Also:


Attachments
makes Document.domain read-write and adds Document.getSelection to all bindings, as per HTML5 spec (1.67 KB, patch)
2009-07-23 03:17 PDT, Luke Kenneth Casson Leighton
no flags Details | Formatted Diff | Diff
removes JS-specificism around Document.domain; keeps comment on getSelection to avoid it being confused with IE block of properties, above, but makes comment same as is shown further down in file (1.84 KB, patch)
2009-07-23 15:17 PDT, Luke Kenneth Casson Leighton
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Luke Kenneth Casson Leighton 2009-07-23 03:04:41 PDT
carrying on from discussion in https://bugs.webkit.org/show_bug.cgi?id=27434 comment https://bugs.webkit.org/show_bug.cgi?id=27434#c3 suggests that the domain property be made read-write and that access to getSelection be made universal to all bindings, to match the HTML5 specification.
Comment 1 Luke Kenneth Casson Leighton 2009-07-23 03:17:43 PDT
Created attachment 33323 [details]
makes Document.domain read-write and adds Document.getSelection to all bindings, as per HTML5 spec
Comment 2 Mark Rowe (bdash) 2009-07-23 09:50:53 PDT
Comment on attachment 33323 [details]
makes Document.domain read-write and adds Document.getSelection to all bindings, as per HTML5 spec

>  #if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT
>                   attribute [ConvertNullToNullString] DOMString domain;
>  #else
> -        readonly attribute DOMString domain;
> +        attribute DOMString domain;
>  #endif

It doesn't seem necessary to have this be #if'd any more.

> +        // now in HTML5 specification
> +        DOMSelection       getSelection();

The comment doesn't add anything.

> +2009-07-22  lkcl <lkcl@lkcl.net>
> +
> +        Reviewed by NOBODY (OOPS!)
> +
> +        https://bugs.webkit.org/show_bug.cgi?id=27603
> +
> +		https://bugs.webkit.org/show_bug.cgi?id=27434#c3 suggests that the
> +		domain property be made read-write and that access to getSelection be
> +		made universal to all bindings, to match the HTML5 specification.
> +
> +        * dom/Document.idl: updated to match HTML spec on domain and getSelection

Your ChangeLog entry again contains tabs that will make our pre-commit hook unhappy.
Comment 3 Luke Kenneth Casson Leighton 2009-07-23 15:06:36 PDT
(In reply to comment #2)
> (From update of attachment 33323 [details])
> >  #if defined(LANGUAGE_JAVASCRIPT) && LANGUAGE_JAVASCRIPT
> >                   attribute [ConvertNullToNullString] DOMString domain;
> >  #else
> > -        readonly attribute DOMString domain;
> > +        attribute DOMString domain;
> >  #endif
> 
> It doesn't seem necessary to have this be #if'd any more.

 ah... oh?  oh, what, because the [ConvertNullToNullString] gets ignored by bindings generators that don't need it?  oh, ok.  great.  less code!

> > +        // now in HTML5 specification
> > +        DOMSelection       getSelection();
> 
> The comment doesn't add anything.

 oh, ok.  just trying to be helpful.

> > +2009-07-22  lkcl <lkcl@lkcl.net>
> > +
> > +        Reviewed by NOBODY (OOPS!)
> > +
> > +        https://bugs.webkit.org/show_bug.cgi?id=27603
> > +
> > +		https://bugs.webkit.org/show_bug.cgi?id=27434#c3 suggests that the
> > +		domain property be made read-write and that access to getSelection be
> > +		made universal to all bindings, to match the HTML5 specification.
> > +
> > +        * dom/Document.idl: updated to match HTML spec on domain and getSelection
> 
> Your ChangeLog entry again contains tabs that will make our pre-commit hook
> unhappy.

 achhh, yes, that's vi messing up (ok - me messing up using vi) sorry.  now i know, i've done s/^I/    /g but there may be a couple of entries still with tabs, i'll try to find them.
Comment 4 Luke Kenneth Casson Leighton 2009-07-23 15:14:02 PDT
> > +        // now in HTML5 specification
> > +        DOMSelection       getSelection();
> 
> The comment doesn't add anything.

 ahh, yes it does.  look carefully at the original file, and you
 can see that getSelection() _used_ to be commented
 as a "Mozilla Extension".

 if you remove only the #ifdef, and don't provide a comment,
 it looks like getSelection() is an IE Extension (not an
 HTML5ism) because that's the commented-block above it.


        // IE extensions

                 attribute [ConvertNullStringTo=Undefined, ConvertNullToNullString] DOMString charset;
        readonly attribute [ConvertNullStringTo=Undefined] DOMString defaultCharset;
        readonly attribute [ConvertNullStringTo=Undefined] DOMString readyState;

        Element            elementFromPoint(in long x, in long y);

        // HTML 5
        DOMSelection       getSelection();

        // Mozilla extensions

        readonly attribute [ConvertNullStringTo=Null] DOMString characterSet;


 looking _further_ down the Document.idl file, you can see
 that there is in fact a comment "// HTML 5" already in there:

        // HTML 5
        NodeList getElementsByClassName(in DOMString tagname);


 so, anticipating that "HTML 5" is acceptable, because it's already
 _in_ the file, i'm resubmitting a patch which contains the exact
 same comment "HTML 5".

 the alternative is to move the function getSelection() to somewhere
 which would only confuse people.
Comment 5 Luke Kenneth Casson Leighton 2009-07-23 15:17:55 PDT
Created attachment 33384 [details]
removes JS-specificism around Document.domain; keeps comment on getSelection to avoid it being confused with IE block of properties, above, but makes comment same as is shown further down in file
Comment 6 Eric Seidel (no email) 2009-08-06 20:18:00 PDT
Comment on attachment 33384 [details]
removes JS-specificism around Document.domain; keeps comment on getSelection to avoid it being confused with IE block of properties, above, but makes comment same as is shown further down in file

I believe getSelection is intentionally avoided for Obj-C bindings, but I"m not sure.  Please have an Apple person, like Mark Rowe or Tim Hatcher comment as to if this change is correct or not.
Comment 7 Eric Seidel (no email) 2009-08-09 08:54:49 PDT
Comment on attachment 33384 [details]
removes JS-specificism around Document.domain; keeps comment on getSelection to avoid it being confused with IE block of properties, above, but makes comment same as is shown further down in file

Removing my review.