Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

[Adam Barth]

On Wed, Jun 6, 2012 at 6:59 PM, Glenn Maynard  wrote:
> On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius 
> wrote:
>> On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote:
>> > Please don't encourage yet more sites to open new tabs when I didn't ask
>> > for it.
>> It's merely a new browsing context IIUC, not necessarily a new window
>> (frame, tab, tile or whatever it's called this year). Someone that
>> understands the codebase of a modern browser could even make the back
>> button work, although he would have to restrict write access to the history
>> stack or tree as well, for security reasons.
>
> He's saying he wants it to force target=_blank, though.

That doesn't seem necessary.  Why not navigate the current window to a
new document in an unrelated browsing context?

Adam

Re: [whatwg] video element not ready for prime time

[Chris Double]

On Fri, Jan 13, 2012 at 6:46 AM, Francis Boumphrey
 wrote:
> Firstly if I use a video with the src attribute
>
> e.g. 
>
> and my user agent does not support the format, all I get (in my versions of
> Opera and Firefox) is a blank screen.

Recent versions of Firefox display a message for the user if the mime
type of the video is not supported instead of a blank screen.

-- 
http://www.bluishcoder.co.nz

Re: [whatwg] video element not ready for prime time

[Kit Grose]

On 06/06/2012, at 7:44 AM, Ian Hickson wrote:
> On Fri, 13 Jan 2012, Kit Grose wrote:
>> 
>> I'd argue that while we did receive in WebM "a common codec" it does not 
>> enjoy the sort of universal adoption required to be able to mandate its 
>> support in the spec, so on that logic, I think establishing a 
>> declarative fallback mechanism is probably required to prevent a 
>> situation where you cannot write a robust HTML5 page with video and 
>> without resorting to JS.
> 
> I don't think it's time to give up yet, but maybe I'm overly optimistic...


Is there any reason why it wouldn't be prudent to render the content of the 
 element as HTML if the video cannot be played, given that fallback 
content in the video element is already supported for legacy browsers in the 
spec:

> Content may be provided inside the video element. User agents should not show 
> this content to the user; it is intended for older Web browsers which do not 
> support video, so that legacy video plugins can be tried, or to show text to 
> the users of these older browsers informing them of how to access the video 
> contents.

How are legacy UAs without  support appreciably different from a UA with 
restrictive or limited  support? Surely the author's intent in either 
case is delivering the content in a different way or delivering appropriate 
alternate content.

Even if we eventually get a common codec (which I—perhaps overly 
pessimistically—feel is unlikely), authors are already using the  
element without supplying whatever that eventual codec will be, and users are 
suffering without reasonable fallbacks.

As it stands, it's almost better (and certainly easier) for authors to default 
to Flash video and use the existing, declarative fallback behaviour of the 
 element to use a  element instead. That can't be in the best 
interest of the open web.

—Kit Grose

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

[Glenn Maynard]

On Wed, Jun 6, 2012 at 8:26 PM, Bjartur Thorlacius wrote:

> On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote:
> > Please don't encourage yet more sites to open new tabs when I didn't ask
> > for it.
> It's merely a new browsing context IIUC, not necessarily a new window
> (frame, tab, tile or whatever it's called this year). Someone that
> understands the codebase of a modern browser could even make the back
> button work, although he would have to restrict write access to the history
> stack or tree as well, for security reasons.
>

He's saying he wants it to force target=_blank, though.

-- 
Glenn Maynard

Re: [whatwg] Media queries, viewport dimensions, srcset and picture

[Mark Callow]

On 06/06/2012 21:36, Henri Sivonen wrote:
> More to the point, the important characteristic is being able to stop
> downloading *quarter* way through the file and get results that are as
> good as if the full-size file had been down sampled with both
> dimensions halved and that size had been sent as the full file. (I am
> not aware of a bitmap format suitable for photographs that has this
> characteristic. I am aware that JPEG 2000 does not have this
> characteristic. I believe interlaced PNGs have that characteristic,
> but they aren't suitable for photographs, due to the lossless
> compression.) 
IIRC Kodak's PhotoCD image format had this characteristic. The first
part is a low res. image, the second is the differences between the low
res. image zoomed to the high res. size and the actual high res. image.

Regards

-Mark

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

[Bjartur Thorlacius]

On Wed, Jun 06, 2012 at 07:32:34PM -0500, Glenn Maynard wrote:
> Please don't encourage yet more sites to open new tabs when I didn't ask
> for it.
It's merely a new browsing context IIUC, not necessarily a new window (frame, 
tab, tile or whatever it's called this year). Someone that understands the 
codebase of a modern browser could even make the back button work, although he 
would have to restrict write access to the history stack or tree as well, for 
security reasons.

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

[Glenn Maynard]

On Wed, Jun 6, 2012 at 6:56 PM, Charlie Reis  wrote:

> I'm hoping to bypass all of those by overriding any specification of target
> in the link.  That is, if "rel=unrelated" is specified, that forces target
> to be "_blank".
>

Please don't encourage yet more sites to open new tabs when I didn't ask
for it.

-- 
Glenn Maynard

Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior

[Boris Zbarsky]

On 6/6/12 7:47 PM, Ian Hickson wrote:

On Fri, 27 Jan 2012, Boris Zbarsky wrote:

On 1/27/12 1:30 AM, Ian Hickson wrote:

On Wed, 5 Oct 2011, Henri Sivonen wrote:

On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky   wrote:

What Firefox does do is block execution of

Re: [whatwg] tabindexscope

[Ian Hickson]

On Mon, 30 Jan 2012, Tab Atkins Jr. wrote:
> On Mon, Jan 30, 2012 at 1:54 PM, Ian Hickson  wrote:
> > On Tue, 8 Nov 2011, Ojan Vafai wrote:
> >> We keep running into the use case where the physical position matters
> >> for the tab order. The problem with just setting tabIndex (or CSS3
> >> tab-index) is that it takes the thing out of the natural order.
> >>
> >> This problem comes up in a lot of places (e.g. absolute positioning).
> >> It's recently come up for CSS flexboxes, e.g. if you set flex-order or a
> >> reverse flow, then the tabindex still being in document order is often
> >> not what the author wants
> >> (https://bugs.webkit.org/show_bug.cgi?id=62664).
> >>
> >> A
> >> 
> >> C
> >> B
> >> 
> >> D
> >>
> >> The order for the tabbing would be A-D-B-C.
> >
> > The spec says that the order when you omit tabindex (or set it to 0)
> > should follow platform conventions. If the platform convention is to make
> > the tab order follow the visual position, then that's what the browser
> > should do.
> >
> > Surely that would be better than having authors manage local regions for
> > tabindex, especially since the positioning depends on the CSS level, not
> > the HTML level, and thus trying to manage the tabindex in the HTML would
> > be a layering violation anyway.
> 
> If you are attempting to match the tab order to the position of an
> element, you are correct.  In this situation, the tab order of the
> group itself should be controlled by the 'nav-index' property
> alongside the positioning code.
> 
> However, *within* a group of controls, the relative order can want to
> be scoped without reference to CSS.  This can happen because the group
> is being positioned with CSS (and thus the appropriate tab-index is
> unpredictable), because the group may be generated into multiple pages
> with different tab-index'd items elsewhere in the page, or just
> because the dev would like to write their tab-indexes without having
> to renumber everything every time they move the HTML around in the
> page.
> 
> Scoping a tab-index is thus a property that can appropriately belong
> to the HTML level, just as much as tab-index itself does.

Can you give some examples of real-world pages where the tabindex 
attribute has been used (with difficulty due to the lack of scoping), 
where nav-index is not the right solution, and where the UA following 
platform conventions for tab order doesn't or wouldn't end up in a good 
UI, that show that this feature would be useful? I'm having trouble 
picturing it, and the frequent references above to positioning and other 
CSS layout features is confusing me.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

[Charlie Reis]

I'm hoping to bypass all of those by overriding any specification of target
in the link.  That is, if "rel=unrelated" is specified, that forces target
to be "_blank".

Charlie

On Wed, Jun 6, 2012 at 4:53 PM, Michal Zalewski  wrote:

> Several questions:
>
> 1) How would this mechanism work with named windows (which may be targeted
> by means other than accessing opener.*)? In certain implementations (e.g.,
> Chrome), the separation in this namespace comes free, but that's not given
> for other browsers. There are ways in which the attacker could, for
> example, load GMail in a window that already has window.name set.
>
> 2) What would be the behavior of a rel=unrelated link with target=
> pointing to an existing iframe on the page? Could it work in any useful way?
>
> 3) What about the same with target= pointing to an existing window? Would
> that window become isolated? What would happen to the 'back' button /
> history.back()?
>
>

Re: [whatwg] Proposal for Links to Unrelated Browsing Contexts

[Michal Zalewski]

Several questions:

1) How would this mechanism work with named windows (which may be targeted
by means other than accessing opener.*)? In certain implementations (e.g.,
Chrome), the separation in this namespace comes free, but that's not given
for other browsers. There are ways in which the attacker could, for
example, load GMail in a window that already has window.name set.

2) What would be the behavior of a rel=unrelated link with target= pointing
to an existing iframe on the page? Could it work in any useful way?

3) What about the same with target= pointing to an existing window? Would
that window become isolated? What would happen to the 'back' button /
history.back()?

Re: [whatwg] Proposal: "Offline-Capable" Meta Tag and API Indicates Application's Ability to Function Without Network Connection

[Ian Hickson]

On Fri, 27 Jan 2012, Brian Blakely wrote:
> On Fri, Jan 27, 2012 at 4:50 PM, Ian Hickson  wrote:
> > On Fri, 27 Jan 2012, Brian Blakely wrote:
> > >
> > > "What kind of app are you considering that needs 700MB at once?"
> > >
> > > I'm considering videogames that the user would like to play offline
> > > (plane flight, subway, etc), as well as massive software packages like
> > > Adobe CS. A good application designer would allow the user to choose
> > > portions of the app that they would like to cache long-term, but suppose
> > > the user needs the entire thing?  In that case, 700MB could likely
> > > lowballing by quite a bit.
> >
> > I think appcache handles this particular case reasonably well (modulo it's
> > other known limitations, anyway). The caching progress can be easily
> > reported to the user (either by the UA or the page), so the user can know
> > that they should leave the tab open while it does the update, and yet the
> > page is usable in the meantime.
>
> I completely agree Ian, app cache would be the means by which a 
> developer sends their assets to the user's local storage device.
> 
> This proposal deals chiefly with standardizing the messaging around 
> that. The developer sets up the application to be ready for offline use 
> (via App Cache, localStorage, IndexedDB, cookies, etc), and informs the 
> UA when the user can go off the wire.  The UA then informs the user in a 
> predictable way that will become familiar to them as they continue to 
> use that particular client.
> 
> Background downloading and other mechanics introduced in this thread 
> enable a native-like app download process that is, again, always the 
> same on the same UA, instead of varying from application to application.

I think we should wait for sites to start showing their own UI for this 
kind of thing -- "ok, I'm now fully cached" -- before we add a mechanism 
for the script to ask the UA to show UI for this. Without the experience 
gained from authors doing it themselves, we don't really have enough 
information about how to design the feature.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] HTMLLinkElement.disabled and HTMLLinkElement.sheet behavior

[Ian Hickson]

On Fri, 27 Jan 2012, Boris Zbarsky wrote:
> On 1/27/12 1:30 AM, Ian Hickson wrote:
> > On Wed, 5 Oct 2011, Henri Sivonen wrote:
> > > On Tue, Oct 4, 2011 at 9:54 PM, Boris Zbarsky  wrote:
> > > > What Firefox does do is block execution of

Re: [whatwg] beforepopstate event?

[Ian Hickson]

On Fri, 27 Jan 2012, Thomas Broyer wrote:
> 
> A common use case for beforeunload is to prompt the user before leaving 
> when it has unsaved changes. For instance, you edited a mail draft, 
> updated the phone number of a contact, or filled any kind of form, but 
> you didn't save your changes; when you "navigate away", beforeunload can 
> be used to prompt you whether you really want to go (and lose your 
> changes).
> 
> Within a "single-page app", where you use location.hash=xxx and
> hashchange, or pushState() and popstate, to handle the navigation,
> there doesn't seem to be any way to prompt the user and possibly
> *cancel* the navigation. Something like:
> 1. you're looking at your mail inbox, and click on "new mail"
> 2. you type in some text
> 3. you click on the "previous page" button of your browser, or trigger
> an equivalent action using a keyboard shortcut (possibly mistakenly)
> As the app developer, I'd like to be able to prompt the user whether
> he really want to go (and lose his changes), and if he actually wants
> to continue editing his mail draft (and/or save it before navigating
> again), then *cancel* the "history traversal"; in a similar way as if
> I developed a "multi-page app" (or if he'd close the window/tab or
> navigate away from the app): I could then do that using the
> beforeunload event, either cancelling it or setting its returnValue to
> some non-empty string value.

Ah, yeah. This isn't supported. I would recommend just making the app not
discard the state, so it becomes a non-issue. They hit back, and the 
message is saved to drafts and can be obtained again by going forward. You 
can put up a message saying that the draft will be discarded in five 
minutes or some such, if the ideal model is for the data to be lost.

The reason onbeforeunload makes sense is that there's no way to do 
anything once the page is unloaded. But that doesn't apply here, where the 
same code is still running.


> Unless I missed something, all I can do is to handle the hashchange or
> popstate event and use Window.confirm() or similar, and only update
> the page from the location.hash or history.state if he confirms; but
> then navigation has already taken place, I cannot cancel the
> navigation but only "ignore" it.

Well, you can always just do history.forward() or whatever, to go back to 
the previous state. :-)

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] Cut and paste (and related) events' futures

[Ian Hickson]

On Thu, 26 Jan 2012, Chris O'Brien wrote:
>
> This is my first post to the mailing list, so please forgive me if the 
> following is inappropriate for the list and let me know where I should 
> direct this instead (h...@whatwg.org? ).
> 
> In all the last-released versions of the major browsers (except Opera), 
> there's support for cut-and-paste events like "onpaste" on  type="text"... and  elements.
> 
> Is there any plan to put these events into the standard? Isn't that a 
> basic tenent of WHATWG--if the real-world vendor implementations are in 
> consensus yet don't reflect the standard, change (or add to) the 
> standard to reflect the de facto market standard, so long as any 
> modifications are backwards compatible?

On Thu, 26 Jan 2012, Mike Taylor wrote:
> 
> You're probably looking for this: 
> http://dev.w3.org/2006/webapi/clipops/clipops.html. A search for 
> "clipboard data API" in the archives might bring up some interesting 
> discussion as well.

Yeah, I haven't added this to the HTML spec because of the existence of 
Hallvord's work cited above. I haven't reviewed it closely. I think it 
might make sense to embed it into the larger HTML spec, but that's 
basically up to Hallvord.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[whatwg] Proposal for Links to Unrelated Browsing Contexts

[Charlie Reis]

Hi all--
  I've posted a new proposal to the WhatWG wiki to give web sites a way to
open a link in an unrelated browsing context.  These links would open in a
new window with no script connections back to the original site, which is
useful for web apps like Gmail that open user-contributed links.  Also,
this could allow multi-process browsers like Google Chrome to open the new
page in a separate process.

  Any feedback on the proposal is appreciated!
http://wiki.whatwg.org/wiki/Links_to_Unrelated_Browsing_Contexts

Thanks,
Charlie Reis

Re: [whatwg] s in by quality as well as codec

[Charles Pritchard]

On Jun 5, 2012, at 2:54 PM, Ian Hickson  wrote:

> On Tue, 21 Feb 2012, Rodger Combs wrote:
>> 
>> I propose that  add a quality, bitrate, or filesize attribute to 
>> allow the UA to decide between multiple streams by choosing the maximum 
>> quality file that it can download within a reasonable amount of time 
>> (e.g. it will download faster than it will play) or based on a user 
>> preference (e.g. prefer SD quality, or always use HD when provided). It 
>> should also be possible to retrieve a list of the s the UA can 
>> play in JS, and switch between them by user action (either a JS call for 
>> a custom UI or a dropdown in the builtin UI), loading the new file and 
>> switching to it with minimal skipping. This way, a site like YouTube, 
>> which presents several files in various bitrates and codecs, can allow 
>> the user to choose to use a higher quality without having to force an 
>> src attribute on the video, and a mobile UA that roams from 3G to WiFi 
>> or moves close to a base station can increase the quality of its stream. 
>> I think it fits in well with the purpose of the source element. This is 
>> certainly open for modification, but I think it's a good concept in 
>> essence.
> 
> If this is for a site like YouTube, I think an adaptive network channel 
> would be a more effective solution (i.e. one where the download adapts in 
> real time to changing network conditions, with the endpoints negotiating 
> with each other regarding what to transmit).


I'd like to see strawman proposals for resource description markup.

Presently, magnet+BitTorrent is the only mature and implemented tech in this 
field that I've found with wide support. And it's not even meant for adaptive 
streaming.

I know that markup for subtitles happened in this group. I'd like to see an 
effort for markup for resources, with the same experimental atmosphere.

The hope being that we can copy and paste some kind of text markup which 
describes various endpoints and metadata sufficient for streaming strategies 
for media.

-Charles

Re: [whatwg] Media queries, viewport dimensions, srcset and picture

[Markus Ernst]

Am 06.06.2012 14:36 schrieb Henri Sivonen:

On Wed, May 23, 2012 at 6:21 PM, Florian Rivoal  wrote:

1) simplyfy srcset to only accept the *x qualifier


Is there a good reason to believe that * will be something other than
a power of two?

That is, could we just optimize the *x syntax away and specify that
the first option is 1x, the second is 2x, the third is 4x, etc.?


Explicitly specifying the * in *x allows more flexibility in the future 
for cases such as:
- If sometime most displays will have 2x or higher resolutions, authors 
might want to set 1x versions aside.
- If 3x or whatever displays should occur, the spec should be suitable 
for them, too.
- Some UAs might decide to progressively load sources in order to 
emulate what we know from interlaced GIFs. Authors could for this 
purpose add 0.5x and even 0.25x versions.

Re: [whatwg] Media queries, viewport dimensions, srcset and picture

[Henri Sivonen]

On Wed, May 23, 2012 at 6:21 PM, Florian Rivoal  wrote:
> On the other hand, I think that including 600w 400h in there is misguided.

I agree.

> 1) simplyfy srcset to only accept the *x qualifier

Is there a good reason to believe that * will be something other than
a power of two?

That is, could we just optimize the *x syntax away and specify that
the first option is 1x, the second is 2x, the third is 4x, etc.?

> I believe the only way out is through an image format that:
...
> - is designed so that the browser can stop downloading half way through
> the file, if it determines it got sufficiently high resolution given the
> environment

More to the point, the important characteristic is being able to stop
downloading *quarter* way through the file and get results that are as
good as if the full-size file had been down sampled with both
dimensions halved and that size had been sent as the full file. (I am
not aware of a bitmap format suitable for photographs that has this
characteristic. I am aware that  JPEG 2000 does not have this
characteristic. I believe interlaced PNGs have that characteristic,
but they aren't suitable for photographs, due to the lossless
compression.)

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] Various HTML element feedback

[Henri Sivonen]

On Wed, Jun 6, 2012 at 2:53 AM, Ian Hickson  wrote:
>> That might be realistic, especially there is no significant semantic
>> clarification in sight in general. This raises the question why we could
>> not just return to the original design with some physical markup like
>> , , and  together with  that was added later.
>
> I think you'll find the "original design" of HTML isn't what you think it
> is (or at least, it's certainly not as presentational as you imply above),
> but that's neither here nor there.

Is there a record of design between
http://www.w3.org/History/19921103-hypertext/hypertext/WWW/MarkUp/Tags.html
and
http://www.w3.org/MarkUp/draft-ietf-iiir-html-01.txt
?
>> So why not simply define  recommended and describe , ,
>> , and  as deprecated but supported alternatives?
>
> What benefit does empty deprecation have? It's not like we can ever remove
> these elements altogether. What harm do they cause?

The harm is the wasted time spent worrying about and debating which
"semantic" alternative for italics to use.

> If we have to keep them, we are better served by embracing them and giving
> them renewed purpose and vigour, rather than being ashamed of them.

I think we have to keep them, because trying to declare them invalid
would cause people to do a lot of pointless work, too, but I think we
could still be ashamed of them.

> Note that as it is specified,  can be used instead of  with
> basically no loss of semantics. (This is because the spec defines
> "paragraph" in a way that doesn't depend on .)

Is there any known example of a piece of software that needs to care
about the concept of "paragraph" and uses the rules given in the spec
for determining what constituted "paragraphs"?

-- 
Henri Sivonen
hsivo...@iki.fi
http://hsivonen.iki.fi/

Re: [whatwg] s in by quality as well as codec

[Silvia Pfeiffer]

I believe right now there are two proposals under discussion that are
trying to address the adaptive streaming issues:
https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html
and
http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html

I believe both are still somewhat at the experimental level and need
harmonization, but they are both being worked on at the W3C.

HTH.

Cheers,
Silvia.

On Wed, Jun 6, 2012 at 8:23 AM, Charles Pritchard  wrote:
> On Jun 5, 2012, at 2:54 PM, Ian Hickson  wrote:
>
>> On Tue, 21 Feb 2012, Rodger Combs wrote:
>>>
>>> I propose that  add a quality, bitrate, or filesize attribute to
>>> allow the UA to decide between multiple streams by choosing the maximum
>>> quality file that it can download within a reasonable amount of time
>>> (e.g. it will download faster than it will play) or based on a user
>>> preference (e.g. prefer SD quality, or always use HD when provided). It
>>> should also be possible to retrieve a list of the s the UA can
>>> play in JS, and switch between them by user action (either a JS call for
>>> a custom UI or a dropdown in the builtin UI), loading the new file and
>>> switching to it with minimal skipping. This way, a site like YouTube,
>>> which presents several files in various bitrates and codecs, can allow
>>> the user to choose to use a higher quality without having to force an
>>> src attribute on the video, and a mobile UA that roams from 3G to WiFi
>>> or moves close to a base station can increase the quality of its stream.
>>> I think it fits in well with the purpose of the source element. This is
>>> certainly open for modification, but I think it's a good concept in
>>> essence.
>>
>> If this is for a site like YouTube, I think an adaptive network channel
>> would be a more effective solution (i.e. one where the download adapts in
>> real time to changing network conditions, with the endpoints negotiating
>> with each other regarding what to transmit).
>
>
> I'd like to see strawman proposals for resource description markup.
>
> Presently, magnet+BitTorrent is the only mature and implemented tech in this 
> field that I've found with wide support. And it's not even meant for adaptive 
> streaming.
>
> I know that markup for subtitles happened in this group. I'd like to see an 
> effort for markup for resources, with the same experimental atmosphere.
>
> The hope being that we can copy and paste some kind of text markup which 
> describes various endpoints and metadata sufficient for streaming strategies 
> for media.
>
> -Charles