Re: CfC: publish a new Working Draft of Web IDL; deadline October 18

2010-10-12 Thread Shiki Okasaka
Thanks, Cameron.

[DoNotCheckDomainSecurity] is one of the WebKit IDL's attributes,
briefly described here:

  http://www.adambarth.com/papers/2009/barth-weinberger-song.pdf

I think security related attributes like this would be very helpful, too.

 - Shiki

2010/10/12 Cameron McCormack c...@mcc.id.au:
 -minus various people

 Shiki Okasaka:
 You've been missed, Cameron!

 Just a reminder, my wish list is here (this doesn't have to be
 reflected in the very next WD, though):
   
 http://lists.w3.org/Archives/Public/public-script-coord/2010JanMar/0003.html
 A signed 8 bit integer type has been required in WebGL.

 Thanks for pointing these out.  I’ve made sure they all have issue boxes
 in the spec.  The one I can find the least information about is
 [DoNotCheckDomainSecurity].  What are its requirements – just allow
 property accesses that would normally be blocked because they are cross
 origin?  Is it something HTML5 would use?

 Thanks,

 Cameron

 --
 Cameron McCormack ≝ http://mcc.id.au/





Re: CfC: publish a new Working Draft of Web IDL; deadline October 18

2010-10-12 Thread Shiki Okasaka
You've been missed, Cameron!

Just a reminder, my wish list is here (this doesn't have to be
reflected in the very next WD, though):
  http://lists.w3.org/Archives/Public/public-script-coord/2010JanMar/0003.html
A signed 8 bit integer type has been required in WebGL.

Best,

 - Shiki

2010/10/12 Jonas Sicking jo...@sicking.cc:
 Same here.

 On Monday, October 11, 2010, Anne van Kesteren ann...@opera.com wrote:
 On Mon, 11 Oct 2010 12:56:22 +0200, Arthur Barstow art.bars...@nokia.com 
 wrote:

 In case you didn't know, Cameron is back! And he wants to publish a new 
 Working Draft of Web IDL since he says I’ve finished porting across Web IDL 
 to target ECMAScript 5th edition (modulo bugs of course!):

 http://dev.w3.org/2006/webapi/WebIDL/

 As such, this is a Call for Consensus to publish a new WD of Web IDL. If you 
 have any comments or concerns about this proposal, please send them to 
 public-webapps by October 18 at the latest.

 As with all of our CfCs, positive response is preferred and encouraged and 
 silence will be assumed to be assent.


 Awesome, definitely support this!


 --
 Anne van Kesteren
 http://annevankesteren.nl/








[WebIDL] outstanding bugs?

2010-10-12 Thread Anne van Kesteren

Hey Cameron,

If all outstanding issues have markers, there are some you missed reported  
as bug reports against Web IDL. I don't really mind whether they are  
marked, but I do hope the bug reports are being tracked.


Cheers,


--
Anne van Kesteren
http://annevankesteren.nl/



[Bug 10985] The sentence The subprotocol names must all be non-empty ASCII strings with no control characters and not spaces in them (i.e. only characters in the range U+0021 to U+007E). should ac

2010-10-12 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10985

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||i...@hixie.ch
 Resolution||FIXED

--- Comment #1 from Ian 'Hixie' Hickson i...@hixie.ch 2010-10-12 08:52:27 UTC 
---
Assuming the difference is s/not/no/, agreed.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



Re: Comment on Widget Interface...

2010-10-12 Thread Arthur Barstow
 Hi Addison - our Widget Interface spec is blocked, pending feedback 
from the I18N community regarding Marcos' proposal below.


Would you please provide feedback by October 20 (the day before our next 
voice conf)?


-Art Barstow

On Oct/5/2010 12:10 PM, ext Marcos Caceres wrote:

hi Addison,

On Thu, Sep 30, 2010 at 8:57 PM, Phillips, Addisonaddi...@lab126.com  wrote:

Are you talking about a script using navigator.language?

Not really, unless you expect navigator.language to be how widget containers 
expose the runtime locale.

Widget PC describes how a widget is packaged (which can include localization) and how it 
is configured (what the widget container should do when it unpackages and runs 
the widget). The container determines what the locale is going to be for the widget (which, 
as you pointed out in your earlier reply, is implementation specific). This, in turn, affects 
what language the 'name' or other fields returned by the Widget Interface are in. I'm 
suggesting that you need to provide programmatic access to this value, which may be distinct 
from navigator.language. Text direction for those fields might also need to be exposed.


Ok, so there are essentially three problems we need to tackle here:

1. Exposing the actual language which was used (during Step 7 in PC)
to choose the localize the content for name and description (we don't
expose). We have this bit - this is solved:

[[
9.1.5. Rule for Getting a Single Attribute Value
...
   E. Let lang be the language tag derived from having processed the
xml:lang attribute on either element, or in element's ancestor chain
as per [XML]. If xml:lang was not used anywhere in the ancestor chain,
then let lang be an empty string.

   F. Associate lang with result.
]]

And similarly in section 9.1.8. Rule for Getting Text Content. [2]

Essentially, for each element or attribute that is displayable, we
have an abstract object (a so called 'localizable string)' that is
represented as:

{string: ' unicode |  ltr marker | rtl marker | lro marker | rlo marker |',
lang: language tag | empty string}

2. Given the liberal way that PC selects languages, we could end up
with each attribute in the widget object containing different
languages:

widget.name; /*in English*/
widget.shortName; /*unlocalized*/
widget.description; /*in French*/

So, we basically need to extend DOMString:

interface LocalizedString : DOMString {
 readonly attribute DOMString lang;
}

Then:

widget.name.lang === en;

3. At runtime, upon getting an attribute from the Widget object (e.g.,
widget.name), you need to display that properly. The case is:

$(#somePElement).innerHTML = widget.name; //in Arabic

To display it properly, we need something like the algorithm described in:
http://www.iamcal.com/understanding-bidirectional-text/


WDYT?

[1] 
http://dev.w3.org/2006/waf/widgets/#rule-for-getting-a-single-attribute-valu0
[2] http://www.w3.org/TR/widgets/#rule-for-getting-text-content






RE: Comment on Widget Interface...

2010-10-12 Thread Phillips, Addison
Hi Art,

I have scheduled this topic for our telecon tomorrow.

Addison

Addison Phillips
Globalization Architect (Lab126)
Chair (W3C I18N, IETF IRI WGs)

Internationalization is not a feature.
It is an architecture.


 -Original Message-
 From: Arthur Barstow [mailto:art.bars...@nokia.com]
 Sent: Tuesday, October 12, 2010 5:16 AM
 To: marc...@opera.com; Phillips, Addison; public-i18n-c...@w3.org
 Cc: public-webapps
 Subject: Re: Comment on Widget Interface...
 
   Hi Addison - our Widget Interface spec is blocked, pending
 feedback
 from the I18N community regarding Marcos' proposal below.
 
 Would you please provide feedback by October 20 (the day before our
 next
 voice conf)?
 
 -Art Barstow
 
 On Oct/5/2010 12:10 PM, ext Marcos Caceres wrote:
  hi Addison,
 
  On Thu, Sep 30, 2010 at 8:57 PM, Phillips,
 Addisonaddi...@lab126.com  wrote:
  Are you talking about a script using navigator.language?
  Not really, unless you expect navigator.language to be how
 widget containers expose the runtime locale.
 
  Widget PC describes how a widget is packaged (which can include
 localization) and how it is configured (what the widget container
 should do when it unpackages and runs the widget). The container
 determines what the locale is going to be for the widget (which, as
 you pointed out in your earlier reply, is implementation specific).
 This, in turn, affects what language the 'name' or other fields
 returned by the Widget Interface are in. I'm suggesting that you
 need to provide programmatic access to this value, which may be
 distinct from navigator.language. Text direction for those fields
 might also need to be exposed.
 
  Ok, so there are essentially three problems we need to tackle
 here:
 
  1. Exposing the actual language which was used (during Step 7 in
 PC)
  to choose the localize the content for name and description (we
 don't
  expose). We have this bit - this is solved:
 
  [[
  9.1.5. Rule for Getting a Single Attribute Value
  ...
 E. Let lang be the language tag derived from having processed
 the
  xml:lang attribute on either element, or in element's ancestor
 chain
  as per [XML]. If xml:lang was not used anywhere in the ancestor
 chain,
  then let lang be an empty string.
 
 F. Associate lang with result.
  ]]
 
  And similarly in section 9.1.8. Rule for Getting Text Content.
 [2]
 
  Essentially, for each element or attribute that is displayable,
 we
  have an abstract object (a so called 'localizable string)' that
 is
  represented as:
 
  {string: ' unicode |  ltr marker | rtl marker | lro marker | rlo
 marker |',
  lang: language tag | empty string}
 
  2. Given the liberal way that PC selects languages, we could end
 up
  with each attribute in the widget object containing different
  languages:
 
  widget.name; /*in English*/
  widget.shortName; /*unlocalized*/
  widget.description; /*in French*/
 
  So, we basically need to extend DOMString:
 
  interface LocalizedString : DOMString {
   readonly attribute DOMString lang;
  }
 
  Then:
 
  widget.name.lang === en;
 
  3. At runtime, upon getting an attribute from the Widget object
 (e.g.,
  widget.name), you need to display that properly. The case is:
 
  $(#somePElement).innerHTML = widget.name; //in Arabic
 
  To display it properly, we need something like the algorithm
 described in:
  http://www.iamcal.com/understanding-bidirectional-text/
 
 
  WDYT?
 
  [1] http://dev.w3.org/2006/waf/widgets/#rule-for-getting-a-
 single-attribute-valu0
  [2] http://www.w3.org/TR/widgets/#rule-for-getting-text-content
 
 


Updates to FileAPI

2010-10-12 Thread Arun Ranganathan

 WebApps WG,

There have been some updates to the File API.

http://dev.w3.org/2006/webapi/FileAPI/

Notable changes are:

1. Exception codes are no longer harnessed to DOMException's exception 
codes, per discussion on this listserv.


2. Metadata attributes creationDate and lastModifiedDate have been added 
to the File object, per discussion on the WHATWG listserv.


3. Blob no longer has a .url attribute.  Instead, Window and 
WorkerGlobalScope have been extended with methods createBlobURL and 
revokeBlobURL, per discussion on this listserv.


4. The Blob URI section has undergone changes, per discussion on this 
listserv.  Notably, Blob supports the addition of an HTTP Content-Type, 
which implementations must return as a response header when Blob URIs 
are dereferenced.


5. There are (ongoing) fixes to bugs, including incorrect uses of long 
long (in lieu of unsigned long long), per (ongoing) discussion on the 
listserv.


In off-list discussion, a few points have come up, which I'll summarize 
below:


1. The emerging HTML5 Device specification [1] includes a section on 
streams and an affiliated Stream API, which relies normatively on Blob 
URIs [2] defined in the File API.  Since we've eliminated the .url 
property on Blob, we should also eliminate the .url property on the 
Stream object.  There has been some discussion on renaming the methods 
createBlobURL and revokeBlobURL to be more generic, so that use cases 
such as Stream can be accommodated.  This is an ongoing discussion.  In 
general, there's consensus around eliminating the .url attribute from 
Stream.


2. There is ongoing discussion about the addition of Content-Disposition 
as well (as an attribute on Blob, as a parameter to Blob.slice, and as a 
response header when dereferencing blob: URIs), to facilitate and 
optimize downloads.  The use of a Content-Disposition header allows URLs 
(both http:// and blob:) to dereference content straight for download, 
with the benefit of header-determined processing (e.g. the download 
doesn't occur first).  Another suggestion to address this use case is 
that instead of supporting Content-Disposition, to allow for an 
additional URL property on the FileSaver constructor, modulo domain 
restrictions.  This discussion is ongoing.


3. In general, there's ongoing discussion on allowing *even more* HTTP 
response behavior when dereferencing blob: URIs.  I strongly favor a 
strict subset of HTTP, and only a use-case driven addition of further 
response headers and response codes.  Arguments cited in favor of 
including all of http:// are that blob: URIs should be completely 
indistinguishable from HTTP URIs, thus allowing maximum reuse with XHR 
and other aspects of the platform.  Currently, I believe we allow for a 
great deal of intermingling without reproducing HTTP in its entirety 
within Blob URIs.


-- A*

[1] http://dev.w3.org/html5/html-device/
[2] http://dev.w3.org/html5/html-device/#stream-api



Re: Updates to FileAPI

2010-10-12 Thread Eric Uhrhane
Arun:

On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathan a...@mozilla.com wrote:
  WebApps WG,

 There have been some updates to the File API.

 http://dev.w3.org/2006/webapi/FileAPI/

 Notable changes are:

 1. Exception codes are no longer harnessed to DOMException's exception
 codes, per discussion on this listserv.

 2. Metadata attributes creationDate and lastModifiedDate have been added to
 the File object, per discussion on the WHATWG listserv.

My apologies for not bringing this up earlier; I just realized that
the discussions I've been involved with weren't on the public lists,
and I didn't share their conclusions on the relevant threads.

The creationDate is going to be problematic.  It works fine on
Windows, but not on Unix-style systems.

On Unix, ctime is *not* creation time.  It's the last time the inode
was modified, so e.g. changing permission bits will alter it.
http://en.wikipedia.org/wiki/MAC_times has a good writeup on ctime.

I see that your spec allows for an empty string on systems where
creationDate isn't available, but my gut response is not to add a
Windows-specific feature.

 3. Blob no longer has a .url attribute.  Instead, Window and
 WorkerGlobalScope have been extended with methods createBlobURL and
 revokeBlobURL, per discussion on this listserv.

 4. The Blob URI section has undergone changes, per discussion on this
 listserv.  Notably, Blob supports the addition of an HTTP Content-Type,
 which implementations must return as a response header when Blob URIs are
 dereferenced.

 5. There are (ongoing) fixes to bugs, including incorrect uses of long long
 (in lieu of unsigned long long), per (ongoing) discussion on the listserv.

I'll update my specs to use unsigned long long where appropriate as well.
I'll also be updating my extensions to FileError/FileException.  Shall
I leave a gap, or just start numbering where you left off?

 In off-list discussion, a few points have come up, which I'll summarize
 below:

 1. The emerging HTML5 Device specification [1] includes a section on
 streams and an affiliated Stream API, which relies normatively on Blob URIs
 [2] defined in the File API.  Since we've eliminated the .url property on
 Blob, we should also eliminate the .url property on the Stream object.
  There has been some discussion on renaming the methods createBlobURL and
 revokeBlobURL to be more generic, so that use cases such as Stream can be
 accommodated.  This is an ongoing discussion.  In general, there's consensus
 around eliminating the .url attribute from Stream.

 2. There is ongoing discussion about the addition of Content-Disposition as
 well (as an attribute on Blob, as a parameter to Blob.slice, and as a
 response header when dereferencing blob: URIs), to facilitate and optimize
 downloads.  The use of a Content-Disposition header allows URLs (both
 http:// and blob:) to dereference content straight for download, with the
 benefit of header-determined processing (e.g. the download doesn't occur
 first).  Another suggestion to address this use case is that instead of
 supporting Content-Disposition, to allow for an additional URL property on
 the FileSaver constructor, modulo domain restrictions.  This discussion is
 ongoing.

 3. In general, there's ongoing discussion on allowing *even more* HTTP
 response behavior when dereferencing blob: URIs.  I strongly favor a strict
 subset of HTTP, and only a use-case driven addition of further response
 headers and response codes.  Arguments cited in favor of including all of
 http:// are that blob: URIs should be completely indistinguishable from HTTP
 URIs, thus allowing maximum reuse with XHR and other aspects of the
 platform.  Currently, I believe we allow for a great deal of intermingling
 without reproducing HTTP in its entirety within Blob URIs.

 -- A*

 [1] http://dev.w3.org/html5/html-device/
 [2] http://dev.w3.org/html5/html-device/#stream-api





Re: Updates to FileAPI

2010-10-12 Thread Arun Ranganathan

 On 10/12/10 2:12 PM, Eric Uhrhane wrote:

Arun:

On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathana...@mozilla.com  wrote:

  WebApps WG,

There have been some updates to the File API.

http://dev.w3.org/2006/webapi/FileAPI/

Notable changes are:

1. Exception codes are no longer harnessed to DOMException's exception
codes, per discussion on this listserv.

2. Metadata attributes creationDate and lastModifiedDate have been added to
the File object, per discussion on the WHATWG listserv.

My apologies for not bringing this up earlier; I just realized that
the discussions I've been involved with weren't on the public lists,
and I didn't share their conclusions on the relevant threads.

The creationDate is going to be problematic.  It works fine on
Windows, but not on Unix-style systems.

On Unix, ctime is *not* creation time.  It's the last time the inode
was modified, so e.g. changing permission bits will alter it.
http://en.wikipedia.org/wiki/MAC_times has a good writeup on ctime.

I see that your spec allows for an empty string on systems where
creationDate isn't available, but my gut response is not to add a
Windows-specific feature.


(Yes, this discussion also occurred on WHATWG).

Is your suggestion to *only* allow lastModifiedDate, and not to support 
creationDate at all, even though implementations can return the empty 
string on [Unix-style] systems where creationDate is unreliable?



3. Blob no longer has a .url attribute.  Instead, Window and
WorkerGlobalScope have been extended with methods createBlobURL and
revokeBlobURL, per discussion on this listserv.

4. The Blob URI section has undergone changes, per discussion on this
listserv.  Notably, Blob supports the addition of an HTTP Content-Type,
which implementations must return as a response header when Blob URIs are
dereferenced.

5. There are (ongoing) fixes to bugs, including incorrect uses of long long
(in lieu of unsigned long long), per (ongoing) discussion on the listserv.

I'll update my specs to use unsigned long long where appropriate as well.
I'll also be updating my extensions to FileError/FileException.  Shall
I leave a gap, or just start numbering where you left off?


I think you can probably start where what's in File API leaves off.  We 
should keep tightly in sync :-)


-- A*



Re: Updates to FileAPI

2010-10-12 Thread Eric Uhrhane
On Tue, Oct 12, 2010 at 11:18 AM, Arun Ranganathan a...@mozilla.com wrote:
  On 10/12/10 2:12 PM, Eric Uhrhane wrote:

 Arun:

 On Tue, Oct 12, 2010 at 10:46 AM, Arun Ranganathana...@mozilla.com
  wrote:

  WebApps WG,

 There have been some updates to the File API.

 http://dev.w3.org/2006/webapi/FileAPI/

 Notable changes are:

 1. Exception codes are no longer harnessed to DOMException's exception
 codes, per discussion on this listserv.

 2. Metadata attributes creationDate and lastModifiedDate have been added
 to
 the File object, per discussion on the WHATWG listserv.

 My apologies for not bringing this up earlier; I just realized that
 the discussions I've been involved with weren't on the public lists,
 and I didn't share their conclusions on the relevant threads.

 The creationDate is going to be problematic.  It works fine on
 Windows, but not on Unix-style systems.

 On Unix, ctime is *not* creation time.  It's the last time the inode
 was modified, so e.g. changing permission bits will alter it.
 http://en.wikipedia.org/wiki/MAC_times has a good writeup on ctime.

 I see that your spec allows for an empty string on systems where
 creationDate isn't available, but my gut response is not to add a
 Windows-specific feature.

 (Yes, this discussion also occurred on WHATWG).

Well, there was discussion in May about how modificationDate might be
earlier than creationDate on Windows, due to odd copy behavior, but no
mention IIRC that this couldn't work at all on Unix systems, which I
think is significant.

 Is your suggestion to *only* allow lastModifiedDate, and not to support
 creationDate at all, even though implementations can return the empty string
 on [Unix-style] systems where creationDate is unreliable?

Yes.  If we publish APIs that only work on Windows, Windows-based
developers will write code that works on their test machines, but
fails elsewhere.  Web code is supposed to be more portable than that.

 3. Blob no longer has a .url attribute.  Instead, Window and
 WorkerGlobalScope have been extended with methods createBlobURL and
 revokeBlobURL, per discussion on this listserv.

 4. The Blob URI section has undergone changes, per discussion on this
 listserv.  Notably, Blob supports the addition of an HTTP Content-Type,
 which implementations must return as a response header when Blob URIs are
 dereferenced.

 5. There are (ongoing) fixes to bugs, including incorrect uses of long
 long
 (in lieu of unsigned long long), per (ongoing) discussion on the
 listserv.

 I'll update my specs to use unsigned long long where appropriate as well.
 I'll also be updating my extensions to FileError/FileException.  Shall
 I leave a gap, or just start numbering where you left off?

 I think you can probably start where what's in File API leaves off.  We
 should keep tightly in sync :-)

Sounds good; thanks.



[Bug 10624] [Selection] Selection anchorNode/anchorOffset/focusNode/focusOffset do not match existing browser behaviour

2010-10-12 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10624

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||public-webapps@w3.org
  Component|pre-LC1 HTML5 spec (editor: |DOM Range
   |Ian Hickson)|
 AssignedTo|i...@hixie.ch|dave.n...@w3.org
Product|HTML WG |WebAppsWG
  QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



[Bug 10691] [Selection] Specify extend method for Selection objects

2010-10-12 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10691

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||public-webapps@w3.org
  Component|pre-LC1 HTML5 spec (editor: |DOM Range
   |Ian Hickson)|
 AssignedTo|i...@hixie.ch|dave.n...@w3.org
Product|HTML WG |WebAppsWG
  QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



[Bug 9514] [Selection] Specify Selection.modify()

2010-10-12 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=9514

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||public-webapps@w3.org
  Component|pre-LC1 HTML5 spec (editor: |DOM Range
   |Ian Hickson)|
 AssignedTo|i...@hixie.ch|dave.n...@w3.org
Product|HTML WG |WebAppsWG
   Target Milestone|LC  |---
  QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



[Bug 10798] [Selection] Find a new home for Selection

2010-10-12 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10798

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 CC||public-html-wg-issue-tracki
   ||n...@w3.org,
   ||public-h...@w3.org
  Component|DOM Range   |HTML5 spec (editor: Ian
   ||Hickson)
 Resolution||FIXED
Product|WebAppsWG   |HTML WG
  QAContact|member-webapi-...@w3.org|public-html-bugzi...@w3.org

--- Comment #11 from Ian 'Hixie' Hickson i...@hixie.ch 2010-10-12 21:44:32 
UTC ---
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are
satisfied with this response, please change the state of this bug to CLOSED. If
you have additional information and would like the editor to reconsider, please
reopen this bug. If you would like to escalate the issue to the full HTML
Working Group, please add the TrackerRequest keyword to this bug, and suggest
title and text for the tracker issue; or you may create a tracker issue
yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Accepted
Change Description: see diff given below
Rationale: I've removed Selection from HTML.

Thanks Ms2er. I'll reassign the relevant bugs to the Range component.

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.



[Bug 10583] [Selection] toString should return only the text within the selection that is visible to the user

2010-10-12 Thread bugzilla
http://www.w3.org/Bugs/Public/show_bug.cgi?id=10583

Ian 'Hixie' Hickson i...@hixie.ch changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||public-webapps@w3.org
  Component|pre-LC1 HTML5 spec (editor: |DOM Range
   |Ian Hickson)|
 AssignedTo|i...@hixie.ch|dave.n...@w3.org
Product|HTML WG |WebAppsWG
  QAContact|public-html-bugzi...@w3.org |member-webapi-...@w3.org

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.