<5ADDD4F65DBE4310AE292FC787DAF33C@gmail.com> Message-ID: On Wed, Oct 31, 2012 at 7:33 PM, Ian Hickson wrote: > On Wed, 31 Oct 2012, Johan Sundstr?m wrote: > > On Wednesday, October 31, 2012 at 15:02 , Ian Hickson wrote: > > > On Tue, 30 Oct 2012, Johan Sundstr?m wrote: > > > > That said, I would still much enjoy a future where > > > > javascript:alert(document.doctype) would tell you something rich > about > > > > the page that we today need deep knowledge of document.compatMode > and/or > > > > combinations of XMLSerializer and parsers, or deep study of > DocumentType > > > > refdocs to tease out. > > > > > > Can you elaborate on that? > > > > Sure ? rich as in not "[object DocumentType]", but > > Well the toString() isn't what matters, it's what you can get from the > rest of the attributes on the object. Or are you just saying you wish > .toString() would expose the concatenated string? That would just be a > conveniece method. Is it worth the compat risk? > Yes, this is where our opinions differ. :-) To me, it is the (lack of) language integration that is the heart of the matter and the source of my itch ? not that what I attempted to do proved impossible to cobble together with a (perfectly functional!) solution using other documented DOM APIs scattered about in other disjunct parts of the browser object model, or pasting together object properties and programmer provided constant strings to almost reproduce the value sought. My own hack unintentionally got it wrong in several ways, for example, and I deem that unnecessary brittleness. >From my own experience, the only guaranteed safe, reliable and cross browser method for figuring out an object's class name is Object.prototype.toString.call(object_of_interest), so I would sacrifice consistency with DocumentType.prototype.toString behaviours of the past in an instance for a more useful and intuitive one. If a novice programmer's expectations on what happens when she uses the object in a string context is met, I'd call that improvement here. > ?on apple.com: > > > > ?on roxen.com: Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> > > I don't understand how that is different than document.compatMode, > really, other than the latter not exposing limited quirks mode. But in > theory at least, this information is already exposed. > It tells me what the doctype is, instead of the name of a bucket the browser sorts the doctype into for various semantic and standards compliance (and/or political) reasons. Both features are excellent, when they are the feature you seek, and they already bear decent names helping with their findability and learnability. I am essentially weary of the long knowledge gap and edit distance between alert(document.doctype) and alert((new XMLSerializer).serializeToString(document.doctype)) ? that we can straddle both in this group we already proved; I aspire to help the other 99%. > ?on the Firefox default homepage: > > PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" > > [...] > > This is for XML, right? In HTML the bit in the square brackets would just > be dropped. It's not clear that it's worth exposing just for XML... > > Anyway, this is the DOM Core spec, so I'll let Anne, Aryeh, and Ms2ger > give you a proper answer. :-) It probably is, and it's also where the change would be useful; were SVG and other DOMs exempt from returning a string serialization, it would be a substantially less useful change. -- / Johan Sundstr?m, http://ecmanaut.blogspot.com/ From froidure_nicolas at yahoo.fr Thu Nov 1 09:53:08 2012 From: froidure_nicolas at yahoo.fr (Nicolas Froidure) Date: Thu, 01 Nov 2012 17:53:08 +0100 Subject: [whatwg] Meta "bugreport" proposal In-Reply-To: References: <5090EDA7.9040309@yahoo.fr> <5090F5A6.2080901@gmx.de> <5090F81F.6010303@yahoo.fr> Message-ID: <5092A8F4.6020400@yahoo.fr> On 31/10/2012 20:33, Ian Hickson wrote: > On Wed, 31 Oct 2012, Nicolas Froidure wrote: > >> I think we need a specification to allow users to report websites bugs >> from their browser. That's why i think it could be usefull to add a meta >> markup like this : >> >> >> The uri could be : >> - mailto: to send a report by mail (ex: mailto:webmaster at example.org) >> - http: to send the bug report a a simple HTTP POST request (ex: >> http://example.org/bugreport). >> - bug: something more customizable to allow webmasters to fit bug reports with >> their systems (ex: bug:http?uri=/bug.dat&method=POST&captcha=/captcha.jpg ) >> - etc (ws:, irc: ...) >> >> In order to test this i just made a Chrome extension illustrating how browsers >> could handle this meta markup : >> https://chrome.google.com/webstore/detail/bugmeback/hgmagcomobmjhaomdoihiggpdekaehmg >> >> The code is there : https://github.com/nfroidure/BugMeBack >> >> Are you interested in that kind of approach for bug reporting ? >> > This seems interesting. My recommendation would be to continue developing > the extension, and to try to convince browser vendors and site owners that > this is a good feature to expose. If there is momentum behind a feature > such as this, it is much easier to push it into a spec. > > See also: > > http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F > I have made a Opera version of the extension today (it's on the repo for anyone who want to test). I've got a strong experience on Firefox add-ons so it wouldn't take a lot of time to do it for me. As some developper told me, it's on Internet Explorer that there's issues most of the time but no idea on how to do that for this browser, if anyone want to help, feel free. In order to promote this feature, you have to know that the bug reports can be copy/paste into a mail when the is not present. That's why i already use the extension to report bugs to webmasters. I suggest anyone who think the feature should become a spec to report bugs this way. On my side, i'll get most feedback i can and then write uses cases. Feel free to give me yours. > > On Wed, 31 Oct 2012, Julian Reschke wrote: > >> , not. >> > Indeed From froidure_nicolas at yahoo.fr Thu Nov 1 10:39:47 2012 From: froidure_nicolas at yahoo.fr (Nicolas Froidure) Date: Thu, 01 Nov 2012 18:39:47 +0100 Subject: [whatwg] Meta "bugreport" proposal In-Reply-To: <50921720.7090107@oupeng.com> References: <5090EDA7.9040309@yahoo.fr> <50921720.7090107@oupeng.com> Message-ID: <5092B3E3.5030800@yahoo.fr> On 01/11/2012 07:30, Kang-Hao (Kenny) Lu wrote: > I am not sure a new scheme is a good idea. For embedding data in a URL, > you might consider something like > > data:text/plain,http?uri=/bug.dat&method=POST&captcha=/captcha.jpg > > but I am not an expert on this to say whether this is a good idea. > It seems better. I added this to issues on GitHub. > I am not familiar Chrome extension API and what > chrome.extension.sendRequest does, but if it does send an email when > @href is a mailto: URL, you might want to either: > > 1. Discuss with whoever creates the entry for rel=webmaster in [1] to > see if either rel=webmaster can be dropped or rel=bugreport can be > merged into it. > 2. Extract mailto: URL from rel=webmaster too and treat it as if it is > rel=bugreport. > Unfortunately, the mailto protocol doesn't accept more than 1048 characters. It's not enought to cover console messages and the screenshot provided as a dataUri. It could be done by creating an internet resource and then providing a link via the mailto protocol, but i'm not able to host that content myself. In the other hand it could be a good way for browser vendors to have tracability on bug reports done with their browser in order to know the main issues encountered by their users. I know opera currently have quality programs to retrieve bugs and contact webmasters manually. From ojan at chromium.org Thu Nov 1 10:45:07 2012 From: ojan at chromium.org (Ojan Vafai) Date: Thu, 1 Nov 2012 10:45:07 -0700 Subject: [whatwg] Should scrollbars move focus? In-Reply-To: References:

Message-ID: On Wed, Oct 31, 2012 at 4:17 PM, Peter Kasting wrote: > On Wed, Oct 31, 2012 at 4:08 PM, Ojan Vafai wrote: > >> On Wed, Oct 31, 2012 at 3:46 PM, Robert O'Callahan > >wrote: >> > I think what's happening here in Gecko is that a click on a focusable >> > element moves focus, and a click on an element's scrollbars counts as a >> > click on the element. So clicking on the scrollbar of a

or
>> > contenteditable <div> (or even a <button> containing content with a
>> > scrollbar, if you're mad) moves focus to that element. I think this is
>> > quite reasonable actually.
>> >
>> > Example: http://people.mozilla.org/~roc/scrollbar-focus.html
>>
>> I see. Thanks for the clarification. I don't feel strongly about this.
>> Either direction seems fine. Although, it doesn't violate every native
>> platform's scrollbar convention.
>>
>
> The behavior Robert describes seems theoretically reasonable to me as well.
>

On the one hand, I think it'd be more consistent if clicking on scrollbars
just never moved focus. Here's a case that's kind of weird if you do move
focus:
<div tabIndex="-1" style="width: 100px; height: 100px; overflow: auto">
    <input>
    <div style="height:200px"></div>
</div>

If you focus the input, then click on the scrollbar, the input gets blurred.

I suppose the opposite case is worse though:
<div contentEditable style="width: 100px; height: 100px; overflow: auto">
    <div style="height:200px"></div>
</div>

Clicking on the scrollbar wouldn't focus the element, so you wouldn't get a
text input cursor unless you clicked inside the scrollable area.

I remain on the fence. :)

> Ojan, can you say how you tested the platform conventions?  On Windows I'm
> having a hard time finding an app with multiple scrollable elements that
> uses native scrollbars.  (For example, Visual Studio doesn't use native
> scrollbars.)
>

I didn't test nested scrollbars in Windows. I believe Elliott may have. I
did test them on Mac and Ubuntu. Clicking on nested scrollbars doesn't move
focus even if the scrollable element is focusable. On Ubuntu, clicking on
scrollbars doesn't even change window focus if the scrollbar is in a
different window.

From robert at ocallahan.org  Thu Nov  1 16:08:07 2012
From: robert at ocallahan.org (Robert O'Callahan)
Date: Fri, 2 Nov 2012 12:08:07 +1300
Subject: [whatwg] Should scrollbars move focus?
In-Reply-To: <CANMdWTs0nC4mM7vCG0+tMEfYrCqJfsECmWaPJL=RjRVezJDx1g@mail.gmail.com>
References: <CAPJYB1gkxsWuvMW0255WNa_0e+Zdpk-hSxAx2GQEYLVUxZz1Fw@mail.gmail.com>
	<Pine.LNX.4.64.1210192242460.2471@ps20323.dreamhostps.com>
	<CANMdWTv1ioRZerVK0zyot-Ge-26N+=L+x+9niXTCxmtzjdmoEw@mail.gmail.com>
	<CAPJYB1hcPjhDjax31aTx0EXR8E8ypLeaMcNf5wyF+7=PfV-7hQ@mail.gmail.com>
	<CANMdWTvuW8-AL5JkF71RH6DiDYhznASirGxZM-Hdsk4vrju8RQ@mail.gmail.com>
	<CAOp6jLZ+JOqMngNVcXTOJf0dZ_hmCU_2b2jQ_-wJ3+gWWT14Cg@mail.gmail.com>
	<CANMdWTuU7Fv0vpMUFHcZHhpY6=Ke2wnnFN7RzvSbbFYCjo7cfQ@mail.gmail.com>
	<CAAHOzFCqo=JzH1imbnwP=wdkQz17n5ptOVpnoJ_QkC2SscXS9A@mail.gmail.com>
	<CANMdWTs0nC4mM7vCG0+tMEfYrCqJfsECmWaPJL=RjRVezJDx1g@mail.gmail.com>
Message-ID: <CAOp6jLYnjbhPgN+jouKDG5PTndA-=kgwZ4sp1NDqbD+6_iy6EA@mail.gmail.com>

It would be trivial to change Gecko so that clicking on scrollbars never
moves focus. So I'm on the fence too, although obviously it would be
lower-risk for us to not change anything :-).

Rob
-- 
Jesus called them together and said, ?You know that the rulers of the
Gentiles lord it over them, and their high officials exercise authority
over them. Not so with you. Instead, whoever wants to become great among
you must be your servant, and whoever wants to be first must be your
slave ? just
as the Son of Man did not come to be served, but to serve, and to give his
life as a ransom for many.? [Matthew 20:25-28]

From etiennelg at gmail.com  Thu Nov  1 21:10:55 2012
From: etiennelg at gmail.com (Etienne Levesque Guitard)
Date: Fri, 2 Nov 2012 00:10:55 -0400
Subject: [whatwg] Should scrollbars move focus?
In-Reply-To: <CAOp6jLYnjbhPgN+jouKDG5PTndA-=kgwZ4sp1NDqbD+6_iy6EA@mail.gmail.com>
References: <CAPJYB1gkxsWuvMW0255WNa_0e+Zdpk-hSxAx2GQEYLVUxZz1Fw@mail.gmail.com>
	<Pine.LNX.4.64.1210192242460.2471@ps20323.dreamhostps.com>
	<CANMdWTv1ioRZerVK0zyot-Ge-26N+=L+x+9niXTCxmtzjdmoEw@mail.gmail.com>
	<CAPJYB1hcPjhDjax31aTx0EXR8E8ypLeaMcNf5wyF+7=PfV-7hQ@mail.gmail.com>
	<CANMdWTvuW8-AL5JkF71RH6DiDYhznASirGxZM-Hdsk4vrju8RQ@mail.gmail.com>
	<CAOp6jLZ+JOqMngNVcXTOJf0dZ_hmCU_2b2jQ_-wJ3+gWWT14Cg@mail.gmail.com>
	<CANMdWTuU7Fv0vpMUFHcZHhpY6=Ke2wnnFN7RzvSbbFYCjo7cfQ@mail.gmail.com>
	<CAAHOzFCqo=JzH1imbnwP=wdkQz17n5ptOVpnoJ_QkC2SscXS9A@mail.gmail.com>
	<CANMdWTs0nC4mM7vCG0+tMEfYrCqJfsECmWaPJL=RjRVezJDx1g@mail.gmail.com>
	<CAOp6jLYnjbhPgN+jouKDG5PTndA-=kgwZ4sp1NDqbD+6_iy6EA@mail.gmail.com>
Message-ID: <CADJPd87+G82tpEn_9coWVXDR7RnZQbrU6rzT+ZcCqDBCNGnKCw@mail.gmail.com>

I think Ubuntu has the right behavior, similar to how you can scroll
windows in OS X (with the scroll wheel) even if they're not in a focus; a
huge usability improvement over Windows when doing side-by-side document
editing.

If anything, I believe the user agent should never change platform
behavior. If platform A has behavior X and platform B has behavior Y, then
the user agent should behave as X on A and B on Y.

Which is to say: scroll bars should never change focus, regardless of the
case (as far as I know all platforms follow this convention)

?tienne
On 2012-11-01 7:08 PM, "Robert O'Callahan" <robert at ocallahan.org> wrote:

> It would be trivial to change Gecko so that clicking on scrollbars never
> moves focus. So I'm on the fence too, although obviously it would be
> lower-risk for us to not change anything :-).
>
> Rob
> --
> Jesus called them together and said, ?You know that the rulers of the
> Gentiles lord it over them, and their high officials exercise authority
> over them. Not so with you. Instead, whoever wants to become great among
> you must be your servant, and whoever wants to be first must be your
> slave ? just
> as the Son of Man did not come to be served, but to serve, and to give his
> life as a ransom for many.? [Matthew 20:25-28]
>

From silver at warwickcompsoc.co.uk  Fri Nov  2 05:02:12 2012
From: silver at warwickcompsoc.co.uk (James Ross)
Date: Fri, 2 Nov 2012 12:02:12 +0000
Subject: [whatwg] Should scrollbars move focus?
In-Reply-To: <CANMdWTs0nC4mM7vCG0+tMEfYrCqJfsECmWaPJL=RjRVezJDx1g@mail.gmail.com>
References: <CAPJYB1gkxsWuvMW0255WNa_0e+Zdpk-hSxAx2GQEYLVUxZz1Fw@mail.gmail.com>,
	<Pine.LNX.4.64.1210192242460.2471@ps20323.dreamhostps.com>,
	<CANMdWTv1ioRZerVK0zyot-Ge-26N+=L+x+9niXTCxmtzjdmoEw@mail.gmail.com>,
	<CAPJYB1hcPjhDjax31aTx0EXR8E8ypLeaMcNf5wyF+7=PfV-7hQ@mail.gmail.com>,
	<CANMdWTvuW8-AL5JkF71RH6DiDYhznASirGxZM-Hdsk4vrju8RQ@mail.gmail.com>,
	<CAOp6jLZ+JOqMngNVcXTOJf0dZ_hmCU_2b2jQ_-wJ3+gWWT14Cg@mail.gmail.com>,
	<CANMdWTuU7Fv0vpMUFHcZHhpY6=Ke2wnnFN7RzvSbbFYCjo7cfQ@mail.gmail.com>,
	<CAAHOzFCqo=JzH1imbnwP=wdkQz17n5ptOVpnoJ_QkC2SscXS9A@mail.gmail.com>,
	<CANMdWTs0nC4mM7vCG0+tMEfYrCqJfsECmWaPJL=RjRVezJDx1g@mail.gmail.com>
Message-ID: <DUB002-W63D54EAFEDFACE6C0C1C28E3670@phx.gbl>

> From: ojan at chromium.org
> Date: Thu, 1 Nov 2012 10:45:07 -0700
>
> I didn't test nested scrollbars in Windows. I believe Elliott may have. I
> did test them on Mac and Ubuntu. Clicking on nested scrollbars doesn't move
> focus even if the scrollable element is focusable. On Ubuntu, clicking on
> scrollbars doesn't even change window focus if the scrollbar is in a
> different window.

On Windows (tested on 7 using the Resource Monitor and Command Prompt properties windows), interacting with scrollbars will focus the window, but not the scrollable item itself (i.e. preserving the focus within the window).

However, Internet Explorer (9, on Windows 7), will move the focus to the scrollable element (for all types in Robert's test page).

James

From etiennelg at gmail.com  Fri Nov  2 06:21:49 2012
From: etiennelg at gmail.com (Etienne Levesque Guitard)
Date: Fri, 2 Nov 2012 09:21:49 -0400
Subject: [whatwg] Should scrollbars move focus?
In-Reply-To: <DUB002-W63D54EAFEDFACE6C0C1C28E3670@phx.gbl>
References: <CAPJYB1gkxsWuvMW0255WNa_0e+Zdpk-hSxAx2GQEYLVUxZz1Fw@mail.gmail.com>
	<Pine.LNX.4.64.1210192242460.2471@ps20323.dreamhostps.com>
	<CANMdWTv1ioRZerVK0zyot-Ge-26N+=L+x+9niXTCxmtzjdmoEw@mail.gmail.com>
	<CAPJYB1hcPjhDjax31aTx0EXR8E8ypLeaMcNf5wyF+7=PfV-7hQ@mail.gmail.com>
	<CANMdWTvuW8-AL5JkF71RH6DiDYhznASirGxZM-Hdsk4vrju8RQ@mail.gmail.com>
	<CAOp6jLZ+JOqMngNVcXTOJf0dZ_hmCU_2b2jQ_-wJ3+gWWT14Cg@mail.gmail.com>
	<CANMdWTuU7Fv0vpMUFHcZHhpY6=Ke2wnnFN7RzvSbbFYCjo7cfQ@mail.gmail.com>
	<CAAHOzFCqo=JzH1imbnwP=wdkQz17n5ptOVpnoJ_QkC2SscXS9A@mail.gmail.com>
	<CANMdWTs0nC4mM7vCG0+tMEfYrCqJfsECmWaPJL=RjRVezJDx1g@mail.gmail.com>
	<DUB002-W63D54EAFEDFACE6C0C1C28E3670@phx.gbl>
Message-ID: <CADJPd87fatC=od7wbev60cHcTbQE=VMV_6O5e+32TDB3BHEzkg@mail.gmail.com>

Wouldn't this be considered a browser-specific  implementation
bug/inconsistency then?

It seems that it's done because the scrollbars have to be in the DOM, and
therefore act as elements in the DOM tree (clicking in a random div for
instance does change focus, so the implementation is correct in the sense
of HTML). However, it doesn't look like this ever was looked at. It's just
the bi-product of the way the DOM is typically implemented.

Shouldn't it be fixed? Or rather, can it without breaking DOM functionality
in the browser?
On 2012-11-02 8:02 AM, "James Ross" <silver at warwickcompsoc.co.uk> wrote:

> > From: ojan at chromium.org
> > Date: Thu, 1 Nov 2012 10:45:07 -0700
> >
> > I didn't test nested scrollbars in Windows. I believe Elliott may have. I
> > did test them on Mac and Ubuntu. Clicking on nested scrollbars doesn't
> move
> > focus even if the scrollable element is focusable. On Ubuntu, clicking on
> > scrollbars doesn't even change window focus if the scrollbar is in a
> > different window.
>
> On Windows (tested on 7 using the Resource Monitor and Command Prompt
> properties windows), interacting with scrollbars will focus the window, but
> not the scrollable item itself (i.e. preserving the focus within the
> window).
>
> However, Internet Explorer (9, on Windows 7), will move the focus to the
> scrollable element (for all types in Robert's test page).
>
> James

From lists at ericportis.com  Fri Nov  2 10:03:41 2012
From: lists at ericportis.com (Eric Portis)
Date: Fri, 2 Nov 2012 11:03:41 -0600
Subject: [whatwg]  Features for responsive Web design
Message-ID: <CAKOuMHr_FXeEL=vptoGNToDUDv2813XME4C7NNm7v7Tm8RmbKA@mail.gmail.com>

Long time listener, first time caller. This echoes some of the points Fred
Andrews and others have made here over the past few months, but I don't
think I've seen the emphasis on separation of content/presentation before.
Apologies if anyone thinks this has already been adressed (say, with the
"performance matters more than convienence" paragraph here:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-September/037146.html
).

On Tue May 15 00:28:54 PDT 2012, Ian Hickson wrote:

> In practice, the only information regarding dimensions that can be
> usefully leveraged here is the viewport dimensions. This isn't the end of
> the world, though -- there's often going to be a direct correlation
> between the dimensions of the viewport and the dimensions of the images.

This relationship will be direct, however it will not often be simple and
requires authors to bake information about their layout into their srcset
declarations?a potentially complex and error-prone process which results in
fragile markup.

For example, let's say:

? I have a profile pic on my blog. I have a 200px-wide image (200.jpg), a
400px-wide image (400.jpg), and an 800px-wide image (800.jpg)

? My layout displays this image at max-width: 100% with 0.5em of padding on
all sides within a sidebar. By default this sidebar is folded under the
main content; I have a media query which pops it over to the right at
viewport widths >= 32em. Both the sidebar and the main content are in a
container element with a min-wdith of 20em, a max-width of 80em, and a
margin of 1em. The min-width: 32em media query stipulates that the sidebar
should have a width of 25% of this container after it pops over.  The
sidebar's font-size is 1rem (so, as long as the user hasn't zoomed, 16px).
I want to support up to 2x screens.

(like this: http://ericportis.com/etc/stretchy-images-example/)

? If we tie a responsive images markup pattern to viewport size ALL of that
info needs to go into how I write the markup for my image. Like this:

At viewport widths from our min of 20em (320css-px) to just under 32em
(512css-px):
image ddpx width = (viewport em width - 2ems container margin - 1em image
padding) * 16px/em * device-pixel-ratio

At viewport widths >= 512css-px:
image ddpx width = ((viewport em width - 2ems container margin) * .25 - 1em
image padding) * 16px/em * device-pixel-ratio

We can turn these equations around to figure out the srcset Xw (max-width
in css-px) declarations:

When the viewport < 512css-px:
viewport css-px width = (image ddpx width / device pixel ratio) + (2 ems
container margin + 1em image padding) * 16px/em

When the viewport >= 512css-px:
viewport css-px width = ((image ddpx width / device pixel ratio) + (1em
image padding * 16px/em)) / .25 + 2em container padding * 16px/em

Plug in some numbers and the srcset declaration that falls out of this is:

Crazy complicated! And it would require re-writing if:

- we tweak almost anything about the CSS
- some new device bursts on the scene and we desire to support resolutions
other than 1x & 2x

Too fragile!

I should note here that for what's been called the "art direction" use
case, which straddles (or perhaps blurs) the line between presentation and
content, being able to put breakpoints in markup and tailor specific images
for those breakpoints is great. But for the simpler?let's call it "stretchy
images"?use case, where we don't want to crop or otherwise alter an image
at all, but simply have it display as well as it can, efficiently, within a
fluid layout across a wide range of viewport-sizes & device-resolutions, we
don't *need* to put information about the layout in there at all. We might
currently want to bake it in for performance reasons, but I'll get to that
in a second.

For stretchy images the only two variables that really matter (excepting
bandwidth concerns) are 1) the device pixels the image is slotting into on
the layout and 2) the resolution of the image files themselves. Given
these, load the smallest image that is bigger than the device-pixel
dimensions of its box, or, failing that, the biggest file.

If the browser can handle figuring out the layout, authors only have to
make declarations about their content, resulting in simpler markup that is
far more resilient to layout changes:

I realize that requiring browsers to figure out what size the image will
end up rendering at on the layout before deciding which resource to load
will break image pre-fetchers as they currently operate. And that
pre-fetching is crucial to performance and therefore users. But it seems to
me pre-fetchers have a lot more headroom to get smarter than authors do,
and that we should strive to keep markup for content images as free from
presentational concerns as possible.

This pattern isn't mutually exclusive with the current srcset spec. What
I'm proposing is that if authors want simpler, more robust,
non-presentational markup, they should be able to opt into it and accept
the performance penalties that result (hopefully only for a while, while
browsers and pre-fetchers adapt).

?eric

PS
It would of course be *even better* for authors if the browser could do the
work of figuring out image resource dimensions, too:

I presume this would require additional HTTP requests and incur further
performance losses.

PPS
Also I want a pony: this is all just in the meantime while everyone works
towards fast, efficient, secure & universal JPIP/JPEG2000 support, right? (:

(Note that, regarding prefetching, browsers may have the similar problems
determining *how much* of a streaming, multi-resolution file to download
before all of the CSS is in. Though I suppose it will never be a wasted
effort to download the first renderable portion of a file, given that
higher resolution versions will all build off of that.)

From pkasting at google.com  Fri Nov  2 10:59:38 2012
From: pkasting at google.com (Peter Kasting)
Date: Fri, 2 Nov 2012 10:59:38 -0700
Subject: [whatwg] Should scrollbars move focus?
In-Reply-To: <CADJPd87fatC=od7wbev60cHcTbQE=VMV_6O5e+32TDB3BHEzkg@mail.gmail.com>
References: <CAPJYB1gkxsWuvMW0255WNa_0e+Zdpk-hSxAx2GQEYLVUxZz1Fw@mail.gmail.com>
	<Pine.LNX.4.64.1210192242460.2471@ps20323.dreamhostps.com>
	<CANMdWTv1ioRZerVK0zyot-Ge-26N+=L+x+9niXTCxmtzjdmoEw@mail.gmail.com>
	<CAPJYB1hcPjhDjax31aTx0EXR8E8ypLeaMcNf5wyF+7=PfV-7hQ@mail.gmail.com>
	<CANMdWTvuW8-AL5JkF71RH6DiDYhznASirGxZM-Hdsk4vrju8RQ@mail.gmail.com>
	<CAOp6jLZ+JOqMngNVcXTOJf0dZ_hmCU_2b2jQ_-wJ3+gWWT14Cg@mail.gmail.com>
	<CANMdWTuU7Fv0vpMUFHcZHhpY6=Ke2wnnFN7RzvSbbFYCjo7cfQ@mail.gmail.com>
	<CAAHOzFCqo=JzH1imbnwP=wdkQz17n5ptOVpnoJ_QkC2SscXS9A@mail.gmail.com>
	<CANMdWTs0nC4mM7vCG0+tMEfYrCqJfsECmWaPJL=RjRVezJDx1g@mail.gmail.com>
	<DUB002-W63D54EAFEDFACE6C0C1C28E3670@phx.gbl>
	<CADJPd87fatC=od7wbev60cHcTbQE=VMV_6O5e+32TDB3BHEzkg@mail.gmail.com>
Message-ID: <CAAHOzFA6==W5_LBaG3vVWFEzQEHXamZJzYfiRW+=c3OuTLeA4Q@mail.gmail.com>

On Fri, Nov 2, 2012 at 6:21 AM, Etienne Levesque Guitard <
etiennelg at gmail.com> wrote:

> Wouldn't this be considered a browser-specific  implementation
> bug/inconsistency then?
>

If you're referring to IE's reported behavior, I would say that yes, it's
not gospel regarding platform conventions, and it may not even
intentionally deviate.

I verified James' testing and am sufficiently convinced that the Windows
convention, like other platforms, seems to be to not change focus due to
scrollbar clicks.  That makes me lean towards the "change Gecko and WebKit
to never focus" camp.

From ian at hixie.ch  Fri Nov  2 15:32:08 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 2 Nov 2012 22:32:08 +0000 (UTC)
Subject: [whatwg] Define MessagePort.isConnected or
	MessagePort.ondisconnect
In-Reply-To: <9cef076f1003151807r7c2b448ata983f1ec125568e6@mail.gmail.com>
References: <9cef076f1003151713k5436e613m6bc4adec414915e2@mail.gmail.com>
	<v2rf965ae411003151744k476d31d9kd5bcf53b6844632d@mail.gmail.com>
	<d7b876161003151806w1bac931dh5014f949b0e2e9a0@mail.gmail.com>
	<9cef076f1003151807r7c2b448ata983f1ec125568e6@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211022216510.2478@ps20323.dreamhostps.com>

On Mon, 15 Mar 2010, ATSUSHI TAKAYAMA wrote:
> 
> I think, as Hixie suggested, an array like object to track references of 
> all connected ports would be nice *for SharedWorkers*. For ports created 
> dynamically by new MessageChannel, it doesn't seem to work well.

Why wouldn't it work well for MessageChannel ports?

I've specced something concrete so we have something to discuss here:

http://www.whatwg.org/specs/web-apps/current-work/#broadcasting-to-many-ports

Hopefully this will give authors a way to do the broadcasting without the 
memory leak you currently have to put up with.

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

From ian at hixie.ch  Fri Nov  2 15:40:57 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 2 Nov 2012 22:40:57 +0000 (UTC)
Subject: [whatwg] Declarative Inert DOM (e.g. the <template> element)
In-Reply-To: <CADh5Ky21VNrAEa5adTq+GKhKZwHW54uWCaOsk7hbZAVxP_-e6A@mail.gmail.com>
References: <CADh5Ky2tnXo2nhAqa5iCvK0mWmsLbo6ORDRSfyEyG+k1Cu41HQ@mail.gmail.com>
	<CAJQvAudpkh67QqZzag5po-Mk3ycxX9o6tZVTnSeb726JciN6ag@mail.gmail.com>
	<CADh5Ky21VNrAEa5adTq+GKhKZwHW54uWCaOsk7hbZAVxP_-e6A@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211022234510.2478@ps20323.dreamhostps.com>

Late last year and early this year, there were threads on the WHATWG list 
about changing the HTML parser to handle templates.

Work on this is ongoing, but has been mainly led by Rafael and Tony:

http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/templates/index.html

It's currently being discussed in the public-webapps list:

http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312
   http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg294

My plan is to not work on this myself in the near term, and to adopt for 
the HTML spec whatever parser changes end up getting implemented by 
multiple browsers (or that multiple browsers say they plan to implement, 
depending on when I next get to this particular topic) based on the work 
of Rafael and Tony above.

From fredandw at live.com  Fri Nov  2 18:29:10 2012
From: fredandw at live.com (Fred Andrews)
Date: Sat, 3 Nov 2012 01:29:10 +0000
Subject: [whatwg] Declarative web worker creation and communication?
Message-ID: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>

1. Declarative web worker creation.

Feedback and suggestions for appropriate markup to declare web workers
would be appreciated.

The use case is a document with JS disabled or restricted so that it can not
create web workers, yet still wants to create web workers to process page
input and to update the document.

For example, would a meta element be appropriate:
<meta name="webworker" content="worker1.js">

2. Declarative message handlers that update the DOM.

Feedback and suggestions for appropriate markup to declare points in a HTML
document that could be updated from received messages would be appreciated.

The use case is a document with JS disabled or restricted so that it can not
use JS to receive a message and update the DOM, yet still wants to support
AJAX style designs.   For example the document JS may be disabled but a
declarative mechanism may be defined to enable web workers to be create
and these need to be able to post changes to the document.

A mechanism specific to the need may be better for security.  For example,
being able to bind a HTML <div> element to a specific web worker.  A general
mechanism that allows a message to update any element by ID may be
less desirable for security.

Would it be best to use an iframe for all such use, perhaps using a new URL
that specifies a message target?

Would it be appropriate to add a new attribute to HTML elements that allows
their inner HTML to be replaced from a received message?

3. Declarative user input message posts.

Appropriate markup for declaring events to pass to web workers via messages
is also being considered, and feedback on this would also be appreciated.

For example, a form in a parent document with document JS disabled that still
wants to be able to post a submitted form to a web worker for processing, or
posting a message when a button is clicked.

For a form, perhaps a new form 'method' could be defined, say 'postmessage',
or perhaps a new URL scheme in the form 'action' would be adequate?

For a button a new URL scheme might be adequate for declaring a web worker
as the target.

Perhaps new HTML element attributes would be more appropriate?

Such usage may be rather different to typical HTTP URLs, as there may be no
response, but this may well suit the use and the web worker could use the
above mechanisms to post changes back to the document.  Would it be better
to define a response message?

4. Accessibility

There may be some potential to associate posted messages from UI elements
with key short cuts or other input to support accessibility.

Having declared points in the document that can receive updates may also
help accessibility, and perhaps a description could be added.   For example
a <div> element that receives email message updates could have a description
such as 'Email' and a reader support tool could then report the event to the
user.

A web page with active content that separates presentation from processing
using a non-JS document of presentation and web workers for processing with
a restricted set of messages may also help support accessibility.

Perhaps accessibility it is already well supported.   Feedback from people with
experience in this area would be welcomed.

Is anyone aware of any related work?

cheers
Fred

From minamide at cs.tsukuba.ac.jp  Fri Nov  2 21:50:00 2012
From: minamide at cs.tsukuba.ac.jp (Yasuhiko Minamide)
Date: Sat, 03 Nov 2012 13:50:00 +0900 (JST)
Subject: [whatwg] Question on Limits in Adaption Agency Algorithm
Message-ID: <20121103.135000.32414723.minamide@cs.tsukuba.ac.jp>

This is about Adaption Agency Algorithm in 12.2.5.4.7 The "in body" insertion 
mode.

Limits of loops in the adoption agency algorithm were introduced
in http://html5.org/tools/web-apps-tracker?from=5641&to=5642.
However, the limit for the inner loop introduces an unexpected behaviour for
the following fragment of an HTML document.

This document is parsed into the following DOM tree.

"xyz" is inserted as a child of <i> and the order between "abc" and "xyz" is 
reversed in the tree. We would like to know whether this is an intended 
behaviour of the specification.

We are aware that the similar reversal occurs in markup-in-tables.

Yasuhiko Minamide

From bruant.d at gmail.com  Sat Nov  3 03:38:11 2012
From: bruant.d at gmail.com (David Bruant)
Date: Sat, 03 Nov 2012 11:38:11 +0100
Subject: [whatwg] Declarative web worker creation and communication?
In-Reply-To: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>
Message-ID: <5094F413.1070006@gmail.com>

Le 03/11/2012 02:29, Fred Andrews a ?crit :
> 1. Declarative web worker creation.
>
> Feedback and suggestions for appropriate markup to declare web workers
> would be appreciated.
>
> The use case is a document with JS disabled or restricted so that it can not
> create web workers, yet still wants to create web workers to process page
> input and to update the document.
If JS is disabled, it's probably to prevent processing of page input
(among other things).

David

From fredandw at live.com  Sat Nov  3 06:11:43 2012
From: fredandw at live.com (Fred Andrews)
Date: Sat, 3 Nov 2012 13:11:43 +0000
Subject: [whatwg] Declarative web worker creation and communication?
In-Reply-To: <5094F413.1070006@gmail.com>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>,
	<5094F413.1070006@gmail.com>
Message-ID: <BLU002-W145C77BC793AA97777BA4BFAA660@phx.gbl>

Hi David,

The use case really is to be able to use web workers rather than the document JS.
An extension to disable or restrict the document JS will also be added.  The design
is intended to limit a large range of security issues.

cheers
Fred

> Date: Sat, 3 Nov 2012 11:38:11 +0100
> From: bruant.d at gmail.com
> To: fredandw at live.com
> CC: whatwg at whatwg.org
> Subject: Re: [whatwg] Declarative web worker creation and communication?
> 
> Le 03/11/2012 02:29, Fred Andrews a ?crit :
> > 1. Declarative web worker creation.
> >
> > Feedback and suggestions for appropriate markup to declare web workers
> > would be appreciated.
> >
> > The use case is a document with JS disabled or restricted so that it can not
> > create web workers, yet still wants to create web workers to process page
> > input and to update the document.
> If JS is disabled, it's probably to prevent processing of page input
> (among other things).
> 
> David

From w3c at adambarth.com  Sat Nov  3 09:34:34 2012
From: w3c at adambarth.com (Adam Barth)
Date: Sat, 3 Nov 2012 09:34:34 -0700
Subject: [whatwg] Question on Limits in Adaption Agency Algorithm
In-Reply-To: <20121103.135000.32414723.minamide@cs.tsukuba.ac.jp>
References: <20121103.135000.32414723.minamide@cs.tsukuba.ac.jp>
Message-ID: <CAJE5ia8mT0Kn50KM-OU7B1tF6iOEsVF20FfhEFnXi-MPfZT=-w@mail.gmail.com>

On Fri, Nov 2, 2012 at 9:50 PM, Yasuhiko Minamide
<minamide at cs.tsukuba.ac.jp> wrote:
> This is about Adaption Agency Algorithm in 12.2.5.4.7 The "in body" insertion
> mode.
>
> Limits of loops in the adoption agency algorithm were introduced
> in http://html5.org/tools/web-apps-tracker?from=5641&to=5642.
> However, the limit for the inner loop introduces an unexpected behaviour for
> the following fragment of an HTML document.
>
> <b><i><a><s><tt><div></b>abc</b></div></tt></s></a>xyz</i>
>
> This document is parsed into the following DOM tree.
>
> <b>
>   <i>
>     <a>
>       <s>
>         <tt></tt>
>       </s>
>     </a>
>     "xyz"
>   </i>
> </b>
> <a>
>   <s>
>     <tt>
>       <div>
>         <b></b>
>         "abc"
>       </div>
>     </tt>
>   </s>
> </a>
>
> "xyz" is inserted as a child of <i> and the order between "abc" and "xyz" is
> reversed in the tree. We would like to know whether this is an intended
> behaviour of the specification.
>
> We are aware that the similar reversal occurs in markup-in-tables.

The DOM you get when you hit the limits in the adoption agency
algorithm don't make a lot of intuitive sense.  Unfortunately, the
limits are necessary so that implementations don't end up having to do
quadratic work.  If this behavior is causing you trouble, you might
want to run your content through some sort of pre-processor that
re-writes these cases into valid HTML, which should get parsed in
intuitive ways by user agents.

Adam

From minamide at cs.tsukuba.ac.jp  Sun Nov  4 23:02:53 2012
From: minamide at cs.tsukuba.ac.jp (Yasuhiko Minamide)
Date: Mon, 05 Nov 2012 16:02:53 +0900 (JST)
Subject: [whatwg] Question on Limits in Adaption Agency Algorithm
In-Reply-To: <CAJE5ia8mT0Kn50KM-OU7B1tF6iOEsVF20FfhEFnXi-MPfZT=-w@mail.gmail.com>
References: <20121103.135000.32414723.minamide@cs.tsukuba.ac.jp>
	<CAJE5ia8mT0Kn50KM-OU7B1tF6iOEsVF20FfhEFnXi-MPfZT=-w@mail.gmail.com>
Message-ID: <20121105.160253.163012433.minamide@cs.tsukuba.ac.jp>

> The DOM you get when you hit the limits in the adoption agency
> algorithm don't make a lot of intuitive sense.  Unfortunately, the
> limits are necessary so that implementations don't end up having to do
> quadratic work.  If this behavior is causing you trouble, you might

I'm wondering whether the adoption agency algorithm without the limits
really has a quadratic complexity (with respect to the size of the stack).

Even if we do not impose a limit on the inner loop, each node in the
stack of open elements is processed at most once.

- The inner loop processes the nodes between the formatting element
  and the furthest block.
- Then, the formatting element is moved below the furthest block.

Then, the nodes above the furthest block will not be processed anymore.

If we do not impose the limit on the outer loop, the step 4 may cause
the quadratic behaviour. However, I think that it can be avoided by
slightly revising the algorithm.

I'm working on the automated test generation for the HTML5 parser 
specification and had the question when we try to understand the 
specification precisely.

Yasuhiko Minamide

From annevk at annevk.nl  Sun Nov  4 23:36:57 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 5 Nov 2012 08:36:57 +0100
Subject: [whatwg] URL: Parsing URLs without relative scheme
Message-ID: <CADnb78gxERB+xg3UfU=THG55swOB_H7j0oidtGyisZvGa0nU6g@mail.gmail.com>

Do we want to support parsing the query component of URLs without
relative scheme (such as mailto/javascript) into a separate entity or
just treat it as part of what the specification now calls "scheme
data". What this affects:

* We could more easily treat about:blank?test equal to about:blank
with a query component. Only WebKit does not support this.
* javascript: would consist of scheme data + query + fragment rather
than just scheme data + fragment
* data: would consist of scheme data + query rather than just scheme data
* The API (we should probably just allow manipulation for URLs with
relative scheme for now)

Spec: http://url.spec.whatwg.org/

-- 
http://annevankesteren.nl/

From simonp at opera.com  Sun Nov  4 23:14:23 2012
From: simonp at opera.com (Simon Pieters)
Date: Mon, 05 Nov 2012 09:14:23 +0200
Subject: [whatwg] Declarative web worker creation and communication?
In-Reply-To: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>
Message-ID: <op.wnajt9jlidj3kv@dhcp26-236.enst.fr>

On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews <fredandw at live.com> wrote:

>
> 1. Declarative web worker creation.
>
> Feedback and suggestions for appropriate markup to declare web workers
> would be appreciated.
>
> The use case is a document with JS disabled or restricted so that it can  
> not
> create web workers, yet still wants to create web workers to process page
> input and to update the document.

Can you give some concrete examples where JS is disabled or restricted?

-- 
Simon Pieters
Opera Software

From annevk at annevk.nl  Mon Nov  5 00:33:30 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 5 Nov 2012 09:33:30 +0100
Subject: [whatwg] URL: file: URLs
In-Reply-To: <op.wm0j7fvnidj3kv@dhcp26-236.enst.fr>
References: <CADnb78jJwxgLi4fn-DOKqbu4odSfv1_tCs9WzqEGg2Vpzz4nKw@mail.gmail.com>
	<508D70AA.4020802@mit.edu>
	<CADnb78jgYh_2VQ6x3xi_Y=EdOmBG-7T4DekvnMBJ1r+x1whANA@mail.gmail.com>
	<508E8F03.4090504@mit.edu>
	<CADnb78hS8eLzmwjURkwXAs3jh_qKgTu-7UsObmkfUiQ+A9Wj7Q@mail.gmail.com>
	<508E9F91.4090109@mit.edu>
	<CADnb78hDtjnKe+aK=9d3MjG=FzLV6Hy4hTAUti_nf9BUhbwm-g@mail.gmail.com>
	<50900296.20608@mit.edu> <op.wm0j7fvnidj3kv@dhcp26-236.enst.fr>
Message-ID: <CADnb78g57WKzbDJFKfCcVGymjQw_vJ2QF-C-ow-eJbFLOn476Q@mail.gmail.com>

On Tue, Oct 30, 2012 at 10:46 PM, Simon Pieters <simonp at opera.com> wrote:
> My knee-jerk reaction is the same as Anne's; why not do this for all
> platforms?

I now made it so that for URL's whose scheme is file, [a-Z] followed
by either : or | as first path segment becomes [a-Z] followed by :. I
also made it so that for URL's whose scheme is file, [a-Z] followed by
either : or | as host get an empty host and use that as first path
segment instead (applying the rules before, ending up with | converted
to :).

http://url.spec.whatwg.org/ (see "file host state" and "relative path
state", or search for "file" throughout)

Cheers,

-- 
http://annevankesteren.nl/

From fredandw at live.com  Mon Nov  5 01:24:33 2012
From: fredandw at live.com (Fred Andrews)
Date: Mon, 5 Nov 2012 09:24:33 +0000
Subject: [whatwg] Declarative web worker creation and communication?
In-Reply-To: <op.wnajt9jlidj3kv@dhcp26-236.enst.fr>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>,
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>
Message-ID: <BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>

Hi Simon,

The use I have in mind is a work-in-progress, see: http://www.w3.org/community/pua/wiki/Draft#Examples

However the HTML standard already permits a UA to disable JS, and there is the iframe sandbox, or CSP, or browser extensions, to disable JS.  I would like to make any extensions as widely applicable as possible in the hope of building support for them, and think there is a good case for a web application with document JS disabled that can still communicate with web workers to implement AJAX style designs.

The aim is not to work around JS being disabled, but to allow web pages to be designed with document JS disabled that still support a lot of features that are currently handled by the document JS.

After giving it some more thought it would seem best to add new attributes for communication with web workers so that the existing attributes could implement a backup using a HTTP request - this might help support backwards compatibility or allow content to degrade gracefully if web workers are not supported.  For example, if a form is declared to be submitted to a web work via a message post then it could also have a backup 'method' and 'action' to make a HTTP request to a server.

The best path for supporting DOM updates from received web worker messages is not so clear to me.  Perhaps an iframe, or a more general element extension that allows an innerHTML update to be received from web worker messages and perhaps from server sent events.

cheers
Fred

> To: whatwg at whatwg.org; fredandw at live.com
...
> On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews <fredandw at live.com> wrote:
...
> > 1. Declarative web worker creation.
> >
> > Feedback and suggestions for appropriate markup to declare web workers
> > would be appreciated.
> >
> > The use case is a document with JS disabled or restricted so that it can  not
> > create web workers, yet still wants to create web workers to process page
> > input and to update the document.
> 
> Can you give some concrete examples where JS is disabled or restricted?
> 
> -- 
> Simon Pieters
> Opera Software

From atwilson at google.com  Mon Nov  5 01:41:00 2012
From: atwilson at google.com (Andrew Wilson)
Date: Mon, 5 Nov 2012 10:41:00 +0100
Subject: [whatwg] Declarative web worker creation and communication?
In-Reply-To: <BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>
	<BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>
Message-ID: <CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>

On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews <fredandw at live.com> wrote:

> Hi Simon,
>
> The use I have in mind is a work-in-progress, see:
> http://www.w3.org/community/pua/wiki/Draft#Examples
>
> However the HTML standard already permits a UA to disable JS, and there is
> the iframe sandbox, or CSP, or browser extensions, to disable JS.  I would
> like to make any extensions as widely applicable as possible in the hope of
> building support for them, and think there is a good case for a web
> application with document JS disabled that can still communicate with web
> workers to implement AJAX style designs.
>

I guess I'm not convinced that a web worker (which has an architecture
designed for asynchronous background processing) is the right vehicle for
your "shared context" idea. My concern is that you're looking at the
limited APIs currently available to web workers, and concluding that this
makes them similar to shared contexts, when in reality the primary driver
behind the limited worker APIs is thread safety, not UA privacy.

>
> The aim is not to work around JS being disabled, but to allow web pages to
> be designed with document JS disabled that still support a lot of features
> that are currently handled by the document JS.
>
> After giving it some more thought it would seem best to add new attributes
> for communication with web workers so that the existing attributes could
> implement a backup using a HTTP request - this might help support backwards
> compatibility or allow content to degrade gracefully if web workers are not
> supported.  For example, if a form is declared to be submitted to a web
> work via a message post then it could also have a backup 'method' and
> 'action' to make a HTTP request to a server.
>
> The best path for supporting DOM updates from received web worker messages
> is not so clear to me.  Perhaps an iframe, or a more general element
> extension that allows an innerHTML update to be received from web worker
> messages and perhaps from server sent events.
>
> cheers
> Fred
>
> > To: whatwg at whatwg.org; fredandw at live.com
> ...
> > On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews <fredandw at live.com>
> wrote:
> ...
> > > 1. Declarative web worker creation.
> > >
> > > Feedback and suggestions for appropriate markup to declare web workers
> > > would be appreciated.
> > >
> > > The use case is a document with JS disabled or restricted so that it
> can  not
> > > create web workers, yet still wants to create web workers to process
> page
> > > input and to update the document.
> >
> > Can you give some concrete examples where JS is disabled or restricted?
> >
> > --
> > Simon Pieters
> > Opera Software
>
>

From gphemsley at gmail.com  Mon Nov  5 07:28:46 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Mon, 5 Nov 2012 10:28:46 -0500
Subject: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard
Message-ID: <CAH4e3M5+rqf3QPv1pXDA0vR7O9CWsNKzD_P=sWL6Kco=6QHkKw@mail.gmail.com>

Hey all,

As you might have heard, I have taken over editorship of the MIME Sniffing
Standard from Adam Barth.

As a first step in my editorship, I have taken the opportunity to rewrite
the document in a more procedural and modular way (IMO). The content and
meaning itself is not supposed to have changed, and I need your help to
verify that that is the case:

http://mimesniff.spec.whatwg.org/

In addition, this now means that I am open to hearing your suggestions
about how to improve the document beyond its current (i.e. former)
semantics.

You can file bugs here:

https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=MIME

As this document was originally an IETF document, there are also old issues
here:

http://trac.tools.ietf.org/wg/websec/trac/query?component=mime-sniff

It's not clear to me which of those remain outstanding on the current
version of the document, and it would be helpful to me if individuals with
a vested interest in them could migrate them to Bugzilla (with updated
descriptions that reflect the current state of the document). This will
ensure that I address them in a timely manner.

Also, it would be helpful if you could mark them as blocking the general
bug here:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19746

And if you want to follow the commits as they happen, you can follow
@mimesniff on Twitter:

https://twitter.com/mimesniff

Thanks!

Gordon

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From fredandw at live.com  Mon Nov  5 17:21:13 2012
From: fredandw at live.com (Fred Andrews)
Date: Tue, 6 Nov 2012 01:21:13 +0000
Subject: [whatwg] Declarative web worker creation and communication?
In-Reply-To: <CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>,
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>,
	<BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>,
	<CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>
Message-ID: <BLU002-W147F9FEEEA6218FC696F05FAA6B0@phx.gbl>

Hi Andrew,

Thank you for the feedback.  The PUA 'shared context' will likely need to be a
distinct web worker variant to cater for any required restrictions and also to
ensure it does not entangle its specific requirements with other innovations
to web workers.  However the message API may be reusable, and trying to
avoid gratuitous differences seems a worthy goal.

Some concerns (lack of understanding) I have with the Web Worker spec. at:
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html

"9.2.3 The worker's lifetime
... Otherwise, o is a Window object, and the relevant Document is just the Document that is the active document of the Window object o."

Does this mean that the Document object of the caller is made available to be web worker?  I can't see an interface to it?

"9.2.4 Processing model
...
5. A new script is now created, as follows.
...
Set the script's browsing context to owner browsing context.
...
Set the script's document to owner document."

There does not appear to be an API to actually effect the owner browsing context or document?
Is this just laying a foundation for future work?
Are web workers expected to someday be able to cause navigation of the creators browsing context etc?

"9.3 APIs available to workers
...
The DOM APIs (Node objects, Document objects, etc) are not available to workers in this version of this specification."

Are there plans to allow web workers access to the DOM of their creator?

Does this apply to documents created by the web worker, such as via XHR?

Looking at the source code for some implementations will help clarify the current state,
but it would also be of interest to know of planned web workers extensions?

cheers
Fred

> Date: Mon, 5 Nov 2012 10:41:00 +0100
> From: atwilson at google.com
> To: fredandw at live.com
> CC: whatwg at whatwg.org; simonp at opera.com
> Subject: Re: [whatwg] Declarative web worker creation and communication?
> 
> On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews <fredandw at live.com> wrote:
> 
> > Hi Simon,
> >
> > The use I have in mind is a work-in-progress, see:
> > http://www.w3.org/community/pua/wiki/Draft#Examples
> >
> > However the HTML standard already permits a UA to disable JS, and there is
> > the iframe sandbox, or CSP, or browser extensions, to disable JS.  I would
> > like to make any extensions as widely applicable as possible in the hope of
> > building support for them, and think there is a good case for a web
> > application with document JS disabled that can still communicate with web
> > workers to implement AJAX style designs.
> >
> 
> I guess I'm not convinced that a web worker (which has an architecture
> designed for asynchronous background processing) is the right vehicle for
> your "shared context" idea. My concern is that you're looking at the
> limited APIs currently available to web workers, and concluding that this
> makes them similar to shared contexts, when in reality the primary driver
> behind the limited worker APIs is thread safety, not UA privacy.
> 
> 
> >
> > The aim is not to work around JS being disabled, but to allow web pages to
> > be designed with document JS disabled that still support a lot of features
> > that are currently handled by the document JS.
> >
> > After giving it some more thought it would seem best to add new attributes
> > for communication with web workers so that the existing attributes could
> > implement a backup using a HTTP request - this might help support backwards
> > compatibility or allow content to degrade gracefully if web workers are not
> > supported.  For example, if a form is declared to be submitted to a web
> > work via a message post then it could also have a backup 'method' and
> > 'action' to make a HTTP request to a server.
> >
> > The best path for supporting DOM updates from received web worker messages
> > is not so clear to me.  Perhaps an iframe, or a more general element
> > extension that allows an innerHTML update to be received from web worker
> > messages and perhaps from server sent events.
> >
> > cheers
> > Fred
> >
> > > To: whatwg at whatwg.org; fredandw at live.com
> > ...
> > > On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews <fredandw at live.com>
> > wrote:
> > ...
> > > > 1. Declarative web worker creation.
> > > >
> > > > Feedback and suggestions for appropriate markup to declare web workers
> > > > would be appreciated.
> > > >
> > > > The use case is a document with JS disabled or restricted so that it
> > can  not
> > > > create web workers, yet still wants to create web workers to process
> > page
> > > > input and to update the document.
> > >
> > > Can you give some concrete examples where JS is disabled or restricted?
> > >
> > > --
> > > Simon Pieters
> > > Opera Software
> >
>

From atwilson at google.com  Mon Nov  5 23:05:57 2012
From: atwilson at google.com (Andrew Wilson)
Date: Tue, 6 Nov 2012 08:05:57 +0100
Subject: [whatwg] Declarative web worker creation and communication?
In-Reply-To: <BLU002-W147F9FEEEA6218FC696F05FAA6B0@phx.gbl>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>
	<BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>
	<CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>
	<BLU002-W147F9FEEEA6218FC696F05FAA6B0@phx.gbl>
Message-ID: <CAArhhitgJawaJVu9BNF4940Tst3Vuco64VhhLw5q=XgyqgbXZw@mail.gmail.com>

On Tue, Nov 6, 2012 at 2:21 AM, Fred Andrews <fredandw at live.com> wrote:

> Hi Andrew,
>
> Thank you for the feedback.  The PUA 'shared context' will likely need to
> be a
> distinct web worker variant to cater for any required restrictions and
> also to
> ensure it does not entangle its specific requirements with other
> innovations
> to web workers.  However the message API may be reusable, and trying to
> avoid gratuitous differences seems a worthy goal.
>

I'd encourage you to look at the MessagePort APIs, if you have not already.
Agreed that using messages to pass data between different contexts is a
powerful mechanism.

>
> Some concerns (lack of understanding) I have with the Web Worker spec. at:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html
>
> "9.2.3 The worker's lifetime
> ... Otherwise, o is a Window object, and the relevant Document is just the
> Document that is the active document of the Window object o."
>
> Does this mean that the Document object of the caller is made available to
> be web worker?  I can't see an interface to it?
>

The Document is not made available - really, this section is just
describing when it's safe to shutdown a worker (which can be quite complex
when you have workers that create other workers, and shared workers).

>
>
> "9.2.4 Processing model
> ...
> 5. A new script is now created, as follows.
> ...
> Set the script's browsing context to owner browsing context.
> ...
> Set the script's document to owner document."
>
> There does not appear to be an API to actually effect the owner browsing
> context or document?
> Is this just laying a foundation for future work?
> Are web workers expected to someday be able to cause navigation of the
> creators browsing context etc?
>
> I don't think the plan is to allow navigation of the browsing context -
I've always understood this section to mean that the worker shares a
browsing context with the creating document for the purposes of cross-site
XHR access, cookies, etc. I'm not at all sure what "set the script's
document" means, but I'm not particularly fluent in spec-speak - I'm sure
someone else on the list can explain the ramifications of that.

>
> "9.3 APIs available to workers
> ...
> The DOM APIs (Node objects, Document objects, etc) are not available to
> workers in this version of this specification."
>
> Are there plans to allow web workers access to the DOM of their creator?
>

There have been discussions about some aspects of this (you can check the
list archives - some people have wanted to be able to pass portions of the
DOM back and forth to workers) but fundamentally the DOM provides a
non-thread-safe API so I don't see how this would ever be possible.

>
> Does this apply to documents created by the web worker, such as via XHR?
>
> Looking at the source code for some implementations will help clarify the
> current state,
> but it would also be of interest to know of planned web workers extensions?
>

I know there has been discussion about more efficient ways to pass/share
data between documents and workers - this would enable things like
background rendering to canvas, etc. Some of the discussion has happened on
the W3C lists (such as
http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/0744.html) so
I'd suggest looking at those archives also.

>
> cheers
> Fred
>
>
> > Date: Mon, 5 Nov 2012 10:41:00 +0100
> > From: atwilson at google.com
> > To: fredandw at live.com
> > CC: whatwg at whatwg.org; simonp at opera.com
>
> > Subject: Re: [whatwg] Declarative web worker creation and communication?
> >
> > On Mon, Nov 5, 2012 at 10:24 AM, Fred Andrews <fredandw at live.com> wrote:
> >
> > > Hi Simon,
> > >
> > > The use I have in mind is a work-in-progress, see:
> > > http://www.w3.org/community/pua/wiki/Draft#Examples
> > >
> > > However the HTML standard already permits a UA to disable JS, and
> there is
> > > the iframe sandbox, or CSP, or browser extensions, to disable JS. I
> would
> > > like to make any extensions as widely applicable as possible in the
> hope of
> > > building support for them, and think there is a good case for a web
> > > application with document JS disabled that can still communicate with
> web
> > > workers to implement AJAX style designs.
> > >
> >
> > I guess I'm not convinced that a web worker (which has an architecture
> > designed for asynchronous background processing) is the right vehicle for
> > your "shared context" idea. My concern is that you're looking at the
> > limited APIs currently available to web workers, and concluding that this
> > makes them similar to shared contexts, when in reality the primary driver
> > behind the limited worker APIs is thread safety, not UA privacy.
> >
> >
> > >
> > > The aim is not to work around JS being disabled, but to allow web
> pages to
> > > be designed with document JS disabled that still support a lot of
> features
> > > that are currently handled by the document JS.
> > >
> > > After giving it some more thought it would seem best to add new
> attributes
> > > for communication with web workers so that the existing attributes
> could
> > > implement a backup using a HTTP request - this might help support
> backwards
> > > compatibility or allow content to degrade gracefully if web workers
> are not
> > > supported. For example, if a form is declared to be submitted to a web
> > > work via a message post then it could also have a backup 'method' and
> > > 'action' to make a HTTP request to a server.
> > >
> > > The best path for supporting DOM updates from received web worker
> messages
> > > is not so clear to me. Perhaps an iframe, or a more general element
> > > extension that allows an innerHTML update to be received from web
> worker
> > > messages and perhaps from server sent events.
> > >
> > > cheers
> > > Fred
> > >
> > > > To: whatwg at whatwg.org; fredandw at live.com
> > > ...
> > > > On Sat, 03 Nov 2012 03:29:10 +0200, Fred Andrews <fredandw at live.com>
> > > wrote:
> > > ...
> > > > > 1. Declarative web worker creation.
> > > > >
> > > > > Feedback and suggestions for appropriate markup to declare web
> workers
> > > > > would be appreciated.
> > > > >
> > > > > The use case is a document with JS disabled or restricted so that
> it
> > > can not
> > > > > create web workers, yet still wants to create web workers to
> process
> > > page
> > > > > input and to update the document.
> > > >
> > > > Can you give some concrete examples where JS is disabled or
> restricted?
> > > >
> > > > --
> > > > Simon Pieters
> > > > Opera Software
> > >
> >
>

From andrew at ado.is-a-geek.net  Tue Nov  6 08:07:05 2012
From: andrew at ado.is-a-geek.net (Andrew Oakley)
Date: Tue, 06 Nov 2012 16:07:05 +0000
Subject: [whatwg] SecurityError with parent, top, window,
 self and opener members of Window
Message-ID: <509935A9.6010704@ado.is-a-geek.net>

The specification seems to indicate that a SecurityError exception
should be thrown when the parent, top, window, self and opener
properties of a Window object are access by scripts with a different
effective script origin.  Some testing in Chrome, Firefox, IE and Opera
indicates that this is not what the browsers actually do.

I can't see any reason why we can't allow access to these properties,
should they be in the list of exceptions in section 6.2.1?  Are there
any more properties that should be in the list?

-- 
Andrew Oakley

From ian at hixie.ch  Tue Nov  6 11:21:53 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Nov 2012 19:21:53 +0000 (UTC)
Subject: [whatwg] Proposals for better support of Tables
In-Reply-To: <C282E02B-2BA6-455A-B275-DCC8B3D8621A@4d.com>
References: <C282E02B-2BA6-455A-B275-DCC8B3D8621A@4d.com>
Message-ID: <Pine.LNX.4.64.1211061914010.2478@ps20323.dreamhostps.com>

On Mon, 7 Feb 2011, Alexandre Morgaut wrote:
> 
> The HTML Table API provides powerful attributes like:
> - "scope"
> - "headers"
> - "colspan"
> - "rowspan"
> 
> All of them give informations about relationships between the table 
> cells, rows, and columns
> 
> It would be very helpful if:
>  - each "th" element could have a "cells" property which would be the 
> HTML Collection of each "td" they are heading
>  - each "td" element could have a "headerCells" property which would be 
> the HTML Collection of each of their related "th"
>  - each cell element could have "rows" and "columns" properties which 
> would be the HTML collection of each rows and columns covered by their 
> rowspan and colspan attributes

I was looking at this, and I think such an API is very attractive from a 
theoretical perspective, but I don't really understand what problem it 
would solve. Can you elaborate on what use cases you have for this? What 
would the page be doing with this API?

> Actually we can use getElementByClassName(), so we often see
> 
> <tr><th id="th1" colspan="2">MySection</th></tr>
> <tr><th id="th2" class="child-of-th1" scope="row">MyName</th><td>MyData</td></tr>
> <tr><th id="th3" class="child-of-th2" scope="row">+ MySubName</th><td>MySubData</td></tr>
>   
> instead of
> 
> <tr><th id="th1" colspan="2">MySection</th></tr>
> <tr><th id="th2" headers="th1" scope="row">MyName</th><td>MyData</td></tr>
> <tr><th id="th3" headers="th1 th2" scope="row">+ MySubName</th><td>MySubData</td></tr>

Do you have examples of pages that are like this that would benefit from 
the API you describe?

> About "headers" I wonder if this would be acceptable:
> 
> <tr><th id="th1" colspan="2">MySection</th></tr>
> <tr><th id="th2" headers="th1" scope="row">MyName</th><td>MyData</td></tr>
> <tr><th id="th3" headers="th2" scope="row">+ MySubName</th><td>MySubData</td></tr>
> 
> as for the third row, the th1 header is implicit from the th2 declared header

Yup, that is allowed and is defined to work as you'd expect.

From ian at hixie.ch  Tue Nov  6 11:25:21 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 6 Nov 2012 19:25:21 +0000 (UTC)
Subject: [whatwg] Sortable Tables
In-Reply-To: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
Message-ID: <Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>

On Thu, 1 Jul 2010, Christoph P?per wrote:
>
> It's a common task outside HTML to sort tables by one or more of its 
> columns.
> 
> There does seem interest among web content providers in making tables 
> client-side sortable since there are several Javascript solutions to do 
> just that, eg. <http://meta.wikimedia.org/wiki/Help:Sorting>, 
> <http://tablesorter.com/docs/>. From these we can learn what would be 
> needed from markup to help sorting algorithms. None of this must be 
> behaviorial, but descriptionary.
> 
> For starters, only rows inside ?tbody?s shall be reordered. For now 
> columns don?t have to be reordered, ie. only vertical, no horizontal 
> sorting. Nevertheless the design should make it possible to add the 
> other direction later.
> 
> Not every table has content that makes sense to be sorted in a different 
> order. So sortable tables should be marked as such. Note that ?col? and 
> ?colgroup? elements are hardly supported.
> 
> Not every column has content that makes sense to be sorted in a 
> different order. So non-sortable columns inside sortable tables should 
> be marked as such.
> 
> There are different ways to sort, eg. numeric, temporal or alphabetic 
> and ascending or descending. Therefore columns should bear information 
> how they should be sorted, ie. what kind of content their cells have.
> 
> Several columns may be used for sorting by some kind of priority.
> 
> The original order must be restorable.
> 
> Cell content may not consist of the string that should be used verbatim 
> for sorting purposes, eg. leading articles or similar numbers with 
> different units (?g?, ?kg?, ?t? ?). Cells should have an optional 
> attribute indicating their sort key. The ?time? element already provides 
> the necessary metadata features for temporal sorting ? maybe there 
> should be more of such elements instead.
>
> There may be columns that shall remain stable, eg. rank numbers.

This is a very interesting idea.

Is this something browser vendors would be interested in implementing? I'm 
hesitant to add a feature for this (which could be somewhat involved) 
before having the definite interest of some browser implementors.

From ojan at chromium.org  Tue Nov  6 11:39:35 2012
From: ojan at chromium.org (Ojan Vafai)
Date: Tue, 6 Nov 2012 11:39:35 -0800
Subject: [whatwg] Sortable Tables
In-Reply-To: <Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
Message-ID: <CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>

On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 1 Jul 2010, Christoph P?per wrote:
> >
> > It's a common task outside HTML to sort tables by one or more of its
> > columns.
> >
> > There does seem interest among web content providers in making tables
> > client-side sortable since there are several Javascript solutions to do
> > just that, eg. <http://meta.wikimedia.org/wiki/Help:Sorting>,
> > <http://tablesorter.com/docs/>. From these we can learn what would be
> > needed from markup to help sorting algorithms. None of this must be
> > behaviorial, but descriptionary.
> >
> > For starters, only rows inside ?tbody?s shall be reordered. For now
> > columns don?t have to be reordered, ie. only vertical, no horizontal
> > sorting. Nevertheless the design should make it possible to add the
> > other direction later.
> >
> > Not every table has content that makes sense to be sorted in a different
> > order. So sortable tables should be marked as such. Note that ?col? and
> > ?colgroup? elements are hardly supported.
> >
> > Not every column has content that makes sense to be sorted in a
> > different order. So non-sortable columns inside sortable tables should
> > be marked as such.
> >
> > There are different ways to sort, eg. numeric, temporal or alphabetic
> > and ascending or descending. Therefore columns should bear information
> > how they should be sorted, ie. what kind of content their cells have.
> >
> > Several columns may be used for sorting by some kind of priority.
> >
> > The original order must be restorable.
> >
> > Cell content may not consist of the string that should be used verbatim
> > for sorting purposes, eg. leading articles or similar numbers with
> > different units (?g?, ?kg?, ?t? ?). Cells should have an optional
> > attribute indicating their sort key. The ?time? element already provides
> > the necessary metadata features for temporal sorting ? maybe there
> > should be more of such elements instead.
> >
> > There may be columns that shall remain stable, eg. rank numbers.
>
> This is a very interesting idea.
>
> Is this something browser vendors would be interested in implementing? I'm
> hesitant to add a feature for this (which could be somewhat involved)
> before having the definite interest of some browser implementors.

This is a use-case that I absolutely think it makes sense to address. This
is extremely common whenever people use tables for actual tabular data and
it's non-trivial to do in a way that performs well. I'd have to see a more
concrete proposal in order to evaluate whether I'd be interested in
implementing it.

A couple thoughts off the top of my head:
1. Would sorting actually reorder the DOM nodes or just change their visual
order? It's not clear to me which one is better. I think the former is what
you'd want most of the time.
2. What values should the sort property allow. One idea is that it takes a
JS function similar to what JavaScript's sort function takes. If you leave
it out then it just does alphanumeric sort.
3. What elements does it go on? I don't see what it would do on a td. I
could see putting it on a th though. Also, it's not clear to me what would
get sorted. For example, in some tables, you would group trs inside tbodys
and want to sort those.

From bzbarsky at MIT.EDU  Tue Nov  6 11:55:06 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 06 Nov 2012 11:55:06 -0800
Subject: [whatwg] Sortable Tables
In-Reply-To: <CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
Message-ID: <50996B1A.7020601@mit.edu>

On 11/6/12 11:39 AM, Ojan Vafai wrote:
> This is a use-case that I absolutely think it makes sense to address.

Agreed.  Not that I can commit to implementing, necessarily, but I do 
think this is a common want.

> A couple thoughts off the top of my head:
> 1. Would sorting actually reorder the DOM nodes or just change their visual
> order? It's not clear to me which one is better. I think the former is what
> you'd want most of the time.

The former also makes defining the interaction of dynamic mutations with 
sorting much much simpler....

Another obvious question: how does (or should) sorting interact with 
rowspans?

-Boris

From silviapfeiffer1 at gmail.com  Tue Nov  6 14:18:42 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 7 Nov 2012 09:18:42 +1100
Subject: [whatwg] Sortable Tables
In-Reply-To: <50996B1A.7020601@mit.edu>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
	<50996B1A.7020601@mit.edu>
Message-ID: <CAHp8n2mue9oZn=U8c7Opvx3iewvJGafT3UOEZKLuqHeJXs3B3g@mail.gmail.com>

On Wed, Nov 7, 2012 at 6:55 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 11/6/12 11:39 AM, Ojan Vafai wrote:
>
>> This is a use-case that I absolutely think it makes sense to address.
>>
>
> Agreed.  Not that I can commit to implementing, necessarily, but I do
> think this is a common want.
>
>
Great to hear browser interest! It's something I've had to implement for
basically all Web apps I've been involved with developing, so am really
keen to get browsers to take this over.

Not quite new, but a good requirements analysis can be had from the list of
JS solutions here:
http://tympanus.net/codrops/2009/10/03/33-javascript-solutions-for-sorting-tables/

I our apps, we'd typically not associate sortable to the table, but to a
column header.
Typical classes/attributes we'd add to a table header cell:
* sortable class: boolean
* data-direction: ascending/descending
* data-type: date, number, text etc which determines the comparison
function used in sort
* data-sort-prio: numeric indicating sorting priority

Also, a sortable table's header needed some indication of the sortability,
so some default CSS like this:
    th.sortable {
      &:after { content: " ??"}
      &.current{
        &[data-direction="asc"]:after { content: " ?"}
        &[data-direction="desc"]:after { content: " ?"}
      }
    }

HTH...

Cheers,
Silvia.

From christoph.paeper at crissov.de  Tue Nov  6 16:17:09 2012
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Wed, 07 Nov 2012 01:17:09 +0100
Subject: [whatwg] Sortable Tables
In-Reply-To: <Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
Message-ID: <7AA0116A-33F0-478B-AAEB-1AE0319C2257@crissov.de>

Ian Hickson (2012-11-06):
> On Thu, 1 Jul 2010, Christoph P?per wrote:
>> 
>> For starters, only rows inside ?tbody?s shall be reordered.

That means every row groupp shall be sorted independently from others, while ?thead? and ?tfoot? remain unsorted, possibly bearing sort widgets.

>> Not every table has content that makes sense to be sorted in a different order.
>> So sortable tables should be marked as such.

We shall use opt-in, obviously. It?s not strictly necessary to mark ?table? as sortable, if at least one of its rows is marked as such, but it would be handy for ?autosort? where the author just wants to enable sorting without specifying the details.

(Table collapsing is a slightly different beast, but related. Let?s deal with that separately later, though.)

>> Note that ?col? and ?colgroup? elements are hardly supported.

But they?re essential for assigning sort properties.

A ?col? inherits the ?key? from a parent ?colgroup?, but may override it.

>> Not every column has content that makes sense to be sorted in a different order. So non-sortable columns inside sortable tables should be marked as such.

Here, I?m talking about columns that should be sorted, but not act as sort keys. See below for fixed columns.

>> There are different ways to sort, eg. numeric, temporal or alphabetic

This easily gets more complex than you wish.

<col key=auto>       = <col key>
  <col key=numeric>    1 = 100% = 1.0 = 1e0 = 2/2 ?
  <col key=text>       ? = ? = Ä ?
  <col key=date>       2012-11-06 = 2012-W45-2 ?
  <col key=value>      1000 g = 1 kg = 0.001 t > 1 lb

<col key=style>      can of worms
  <col key=class>      hardly better

The default ?key? is ?auto? for explicit columns and ?none? for implicit columns.

>> and ascending or descending.

It?s probably overkill to give authors the means to specify the preferred direction. It?s certainly not sane to let them exclude one or the other.

>> Therefore columns should bear (?) what kind of content their cells have.

Authors will mess this up of course, but then it?s their fault. Let?s not overload ?title? or ?abbr?.

>> Several columns may be used for sorting by some kind of priority.

This is a UI question, though.

>> The original order must be restorable.

Also mostly a UI issue, although if authors could describe how they initially sorted the data, that could also be used. They would err and lie more often than not, though.

>> Cell content may not consist of the string that should be used verbatim (?).
>> Cells should have an optional attribute indicating their sort key.

<th value="Rolling Stones, The">The Rolling Stones
  <td value="0.454">1 lb

>> There may be columns that shall remain stable, eg. rank numbers.

> This is a very interesting idea.

It was in 2010 and still is.

Pitfall: ?rowspan? and ?colspan?

Cells may span several rows or columns or both, and are always rectangular. Therefore, we should not sort cells! We should sort slots instead, as defined in <http://www.whatwg.org/specs/web-apps/current-work/multipage/tabular-data.html#table-model>.

A slot is uniquely identified by its row and column numbers and itself is not represented in markup, i.e. in CSS, it cannot be selected by element or other generic selectors, but a pseudo-element like ?::slot(row,column)? would be possible, and is as desirable as something like ?getSlotValue(x,y)?, possibly cf. <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19051>.

Assuming current attributes and elements, a ?td? or ?th? cell covers ?rowspan???colspan? slots and each of these has the same value. The slot value is that of its cell, and dynamically changes with it. The cell value is either its content normalized to a string or, if present, the value of its ?value? attribute. Sorting is done by first evaluating the slot values as suggested by the ?key? attribute value valid for their column, and by second sorting rows using the slot values in the user selected (or default first) column as primary key accordingly. If the same column has been used for the previous sort, the order is reversed (ascending ? descending). If a different column has been used before, it?s used as secondary key, and so on.

Cells spanning several columns (only) will usually remain intact for normal, vertical sorting, unless an affected sort key is set to ?fixed? in exceptional cases. Cells spanning multiple rows in the column to be sorted by, usually remain intact, too. Other cells spanning multiple rows (and possibly columns) need to be split into slots for sorting and (optionally) should be rejoined as far as possible afterwards.

To support this, cells must be splittable!

td     {color: green;}
  #split {color: red;}

<tr><td>3 <td id=split colspan=2> red
  <tr><td>1
  <tr><td>2 <td> green

after sorting by the first column should look like

<tr><td>1 <td id=split> red
  <tr><td>2 <td> green
  <tr><td>3 <td id=split> red

would if duplicate IDs were legal. The DOM tree, however, would not change! The value of the cell at position (1,1), i.e. second row and column since we count from zero, is always undefined, but the value of the slot at (1,1) changes from ?red? to ?green?.

Once we have splittable cells, one could imagine additions to the CSS table model and Selectors that allowed arbitrary partial repositioning of slots, think 15-puzzle. Let?s not go there yet, and not here.

User agents should not be required to sort tables that contain malformed slots, i.e. where multiple cells try to cover the same slot, e.g.:

There may be rows that should always go to the top or the bottom of their group. This should be handled by table headers and footers in most cases, otherwise it is not covered yet.

> Is this something browser vendors would be interested in implementing?

I, for one, hope so.

From duboisp2 at gmail.com  Tue Nov  6 19:42:27 2012
From: duboisp2 at gmail.com (Pierre Dubois)
Date: Tue, 6 Nov 2012 22:42:27 -0500
Subject: [whatwg] Proposals for better support of Tables
In-Reply-To: <Pine.LNX.4.64.1211061914010.2478@ps20323.dreamhostps.com>
References: <C282E02B-2BA6-455A-B275-DCC8B3D8621A@4d.com>
	<Pine.LNX.4.64.1211061914010.2478@ps20323.dreamhostps.com>
Message-ID: <CAPGwD7jWHt6cL4CseFiQJ2Jujb2oKWb_PjvXRHq_Gin4hPCvUg@mail.gmail.com>

On Tue, Nov 6, 2012 at 2:21 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> On Mon, 7 Feb 2011, Alexandre Morgaut wrote:
> >
> > The HTML Table API provides powerful attributes like:
> > - "scope"
> > - "headers"
> > - "colspan"
> > - "rowspan"
> >
> > All of them give informations about relationships between the table
> > cells, rows, and columns
> >
> > It would be very helpful if:
> >  - each "th" element could have a "cells" property which would be the
> > HTML Collection of each "td" they are heading

Use case: Draw a graphic based on a data table
* Like a pie chart, based on a sub-set of data contained in a data table.

An issue can be when the header cell cover and/or represent more than
one group (eg. multiple tbody from a column perspective and multiple
colgroup from a row perspective)

> >  - each "td" element could have a "headerCells" property which would be
> > the HTML Collection of each of their related "th"

Use case: Draw a graphic based on a data table
* As described in the previous use case, this would allow, from a data
cell perspective, to retrieve the associated heading cell content to
associate/create an label to each quarter on the generated pie chart.

An issue with this is about the scope used for the HTMLCollection of
the headerCells property. I means is that would return headerCells for
a row perspective, for a column perspective, for a row group
perspective, for a column group perspective or all of them.

> >  - each cell element could have "rows" and "columns" properties which
> > would be the HTML collection of each rows and columns covered by their
> > rowspan and colspan attributes

Use case: Draw a pie chart based on a sub-set of data contained in a
data table and retrieve heading cell content associated to the data
cells.

This would be preferable to be used instead of having the "cells"
property on "th" and the "headerCells" property on "td".

The "rows" and "columns" HTMLCollection can contains reference of all
"tr" and "col" of the cells covered by it's rowspan and colspan
attribute.
However, it is possible to retrieves the cells, with current API, from
a row perspective "tr"  but not from column perspective "col". A
suggestion would to add a "cells" property to the "col" API.

Regarding the grouping issue, the "tr" and "col" API can have both a
property named "groupIndex" where it would be possible to know the
exact scope of the each cells in a row or column perspective.

> > Actually we can use getElementByClassName(), so we often see
> >
> > <tr><th id="th1" colspan="2">MySection</th></tr>
> > <tr><th id="th2" class="child-of-th1" scope="row">MyName</th><td>MyData</td></tr>
> > <tr><th id="th3" class="child-of-th2" scope="row">+ MySubName</th><td>MySubData</td></tr>
> >
> > instead of
> >
> > <tr><th id="th1" colspan="2">MySection</th></tr>
> > <tr><th id="th2" headers="th1" scope="row">MyName</th><td>MyData</td></tr>
> > <tr><th id="th3" headers="th1 th2" scope="row">+ MySubName</th><td>MySubData</td></tr>

In both, is the second row is data summary of the data contained in
the third row ? A data table like the Nutrition Facts Table ?
(http://wet-boew.github.com/wet-boew/demos/tableparser/Table-CaseStudies-2.html)

> Do you have examples of pages that are like this that would benefit from
> the API you describe?

http://wet-boew.github.com/wet-boew/demos/tableparser/Table-CaseStudies-3.html
http://wet-boew.github.com/wet-boew/demos/tableparser/rowgrouping-techniques.html

Initial design done by content provider to represent complex tabular
data contains sometime row grouping. But when it became to put them in
HTML and because of the complexity of making those complex table
accessible WCAG compliant they are split in several simple table
combined with a set of heading (<hx>). The <hx> is use in replacement
of the row group header. That force to repeat the column cells header
on each simple table instead of having a feature that would allow to
froze the column cells header during the scrolling. I would leave that
for later but this is one use case where is valuable to add a "level"
property to "tr", "col", "tbody" and "colgroup" API

Cheers

:-)

Pierre Dubois

From silviapfeiffer1 at gmail.com  Wed Nov  7 01:47:49 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 7 Nov 2012 20:47:49 +1100
Subject: [whatwg] Sortable Tables
In-Reply-To: <509A2BDE.1010602@kosek.cz>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
	<50996B1A.7020601@mit.edu>
	<CAHp8n2mue9oZn=U8c7Opvx3iewvJGafT3UOEZKLuqHeJXs3B3g@mail.gmail.com>
	<509A2BDE.1010602@kosek.cz>
Message-ID: <CAHp8n2kdPrd_DHA40mDEGY2x4qKSG2aW5u-nrOFtW-bPZrDcdg@mail.gmail.com>

On Wed, Nov 7, 2012 at 8:37 PM, Jirka Kosek <jirka at kosek.cz> wrote:

> On 6.11.2012 23:18, Silvia Pfeiffer wrote:
>
> > * data-type: date, number, text etc which determines the comparison
> > function used in sort
>
> It would be very difficult to support sorting on dates and numbers as in
> HTML they are usually present formatted using specific locale. So there
> should be additional attribute added to td/th which can hold sort key
> which will override cell contents, something like
>
> <td sortas="2012-11-07">11. listopadu 2012</td>

Agreed. My example was very crude and simple and worked fine for our
purposes, but something more generic (and internationalized) needs more
functionality like this.

Silvia.

From jirka at kosek.cz  Wed Nov  7 01:54:19 2012
From: jirka at kosek.cz (Jirka Kosek)
Date: Wed, 07 Nov 2012 10:54:19 +0100
Subject: [whatwg] Sortable Tables
In-Reply-To: <CAHp8n2mue9oZn=U8c7Opvx3iewvJGafT3UOEZKLuqHeJXs3B3g@mail.gmail.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
	<50996B1A.7020601@mit.edu>
	<CAHp8n2mue9oZn=U8c7Opvx3iewvJGafT3UOEZKLuqHeJXs3B3g@mail.gmail.com>
Message-ID: <509A2FCB.8030600@kosek.cz>

On 6.11.2012 23:18, Silvia Pfeiffer wrote:

> * data-type: date, number, text etc which determines the comparison
> function used in sort

It would be very difficult to support sorting on dates and numbers as in
HTML they are usually present formatted using specific locale. So there
should be additional attribute added to td/th which can hold sort key
which will override cell contents, something like

<td sortas="2012-11-07">11. listopadu 2012</td>

Jirka

-- 
------------------------------------------------------------------
  Jirka Kosek      e-mail: jirka at kosek.cz      http://xmlguru.cz
------------------------------------------------------------------
       Professional XML consulting and training services
  DocBook customization, custom XSLT/XSL-FO document processing
------------------------------------------------------------------
 OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 member
------------------------------------------------------------------

From faulkner.steve at gmail.com  Wed Nov  7 01:55:50 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Wed, 7 Nov 2012 09:55:50 +0000
Subject: [whatwg] main element parsing behaviour
Message-ID: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>

Hi all,

After discussions with various implementers there appears to be some
questions about  the main element and the parsing algorithm

Can anyone with the requisite knowledge provide advice on what needs to be
added (if anything) to the main element spec [1] to define parsing for the
element?
also any other feedback welcome.

https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

-- 
with regards

Steve Faulkner
Technical Director - TPG

www.paciellogroup.com | www.HTML5accessibility.com |
www.twitter.com/stevefaulkner
HTML5: Techniques for providing useful text alternatives -
dev.w3.org/html5/alt-techniques/
Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html

From annevk at annevk.nl  Wed Nov  7 02:30:04 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 7 Nov 2012 11:30:04 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
Message-ID: <CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>

On Wed, Nov 7, 2012 at 10:55 AM, Steve Faulkner
<faulkner.steve at gmail.com> wrote:
> Can anyone with the requisite knowledge provide advice on what needs to be
> added (if anything) to the main element spec to define parsing for the
> element?

What did you do with the feedback you already got on this front?

http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0155.html

-- 
http://annevankesteren.nl/

From sil at kryogenix.org  Wed Nov  7 02:34:54 2012
From: sil at kryogenix.org (Stuart Langridge)
Date: Wed, 7 Nov 2012 10:34:54 +0000
Subject: [whatwg] Sortable Tables
In-Reply-To: <CAHp8n2kdPrd_DHA40mDEGY2x4qKSG2aW5u-nrOFtW-bPZrDcdg@mail.gmail.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
	<50996B1A.7020601@mit.edu>
	<CAHp8n2mue9oZn=U8c7Opvx3iewvJGafT3UOEZKLuqHeJXs3B3g@mail.gmail.com>
	<509A2BDE.1010602@kosek.cz>
	<CAHp8n2kdPrd_DHA40mDEGY2x4qKSG2aW5u-nrOFtW-bPZrDcdg@mail.gmail.com>
Message-ID: <CALWjOx+n-tSRG0Arz5+PSF4UzBbVcxwdvyQotfBxLrb9qqkHNA@mail.gmail.com>

I'm the author of http://www.kryogenix.org/code/browser/sorttable/, a
moderately popular JavaScript table sorting script. As such, I have about
nine years worth of anecdata about how authors want their HTML tables to be
sorted, the sorts of things they request, and issues that may be worth
taking into consideration. These are not particularly in order; they're
just things that I think are relevant.

Sorttable.js, my script, has the guiding principle of not needing
configuration in most cases. Therefore, it attempts to guess the type of a
table column: if a column looks like it contains numbers, sorttable will
use numeric sort (1 before 2 before 100) rather than alphanumeric sort (1
before 100 before 2); if a column looks like it contains date information,
then sorttable will sort by date (for formats DD/MM/YYYY and MM/DD/YYYY).
The algorithm used for this guessing is pretty naive (check the first cell
in a column; if it's blank, check the next one; etc). I think that this, by
itself, has accounted for sorttable's popularity, because in most cases, it
Just Works; you add a <script> element pointing to the script, and
class="sortable" to the <table>, and do *nothing else*, and your table is
sortable without any configuration.

Everything else below here is configuration-based: something you'd have to
do explicitly as an author. The above point is the critical one; guessing
column types to make table sorting be zero-config. Some alternative scripts
require you to explicitly tag date or numeric columns, and I think that
authors see that as annoying. Anecdata, of course.

Sorttable also allows authors to specify "alternate content" for a cell.
That is (ignore the invalid HTML attribute here; I didn't know any better,
and we didn't have data-* attributes when I wrote this stuff)

<td sorttable_customkey="11">eleven</td>

This is basically useful for when you have table data which has a definite
order but it can't be autoguessed, or (more usefully still) when it could
be autoguessed but that would be hard. The canonical example of this is
dates: it would be exceedingly annoying, given
<td>Wed 7th November, 10.00am GMT</td>
to have to parse that cell content in JavaScript to turn it back into a
Date() so it can be placed in sort order with other dates. The sorttable.js
solution is to specify a "custom key", which sorttable pretends was the
cell content for the purposes of sorting, so
<td sorttable_customkey="20121107-100000">Wed 7th November, 10.00am GMT</td>
and then the script can sort it. This feature is basically the get-out
clause, an author hook for saying "I know what I want, but your fancy
sorting thing can't handle it; how do I override that?" They can specify
custom keys for all their TDs and then sorting will work fine. (Obviously,
dates are less of a problem in theory today with <date> elements, but...
how does the script know to use the datetime attribute of the <date> in
<td><date>...</date></td>?)

In roughly descending order of popularity, here is what I've been asked
questions about, over the last decade or so:

1. Sorting tables inserted after page load. This is obviously not a problem
(sorting a table created with JS rather than in the base HTML), and
sorttable should handle it without explicit action from the author to
"mark" a table as sortable, but it doesn't because of laziness from me. I
include it for completeness because sorttable not handling it generates
probably a third of all the sorttable complaint email I receive; a properly
specced sortable tables implementation in browsers would obviously handle
this and wouldn't need to even have it specified.
2. Sorting a table on page load. That is: a table in HTML containing
unsorted data should be sorted by the browser when the page loads, without
user action. Sorttable doesn't do this because I think it's wrong (if you
want sorted data when the page loads, serve it as sorted in the HTML), but
lots of people ask for it.
3. Multiple header rows. Many authors have two or more <tr>s in the
<thead>, one of which contains rowspanned <th>s, to group columns together.
If this happens, which <th>s are clickable to sort the table? Which are
not? This is hard to autodiagnose (and indeed sorttable punts on it and
picks the first one, which is almost certainly wrong; even naively picking
the last <tr> inside <thead> would be better, but still imperfect).
4. Handling colspans and rowspans in the table. Sorttable.js basically
punts on this, because what's expected to happen when you sort a column
which contains only half a cell (because the other half's in another
column, with rowspan=2) is wildly author-specific. But a properly specced
solution doesn't get to punt and say "unsupported". This will need some
thought.
5. Numeric sort handling exponented numbers such as 1.5e6 (which do not
match a naive "is this a number" regexp such as /^[0-9]+$/ )
6. Specifying how to display that a column is sorted. This would likely be
done in this specification by leaving it to CSS and th::sorted-forward {
after: content("v"); } or some such thing (I have no policy suggestions
here), but authors want to be able to specify this, along with different
styles for a sorted column. This is mildly more awkward because there's no
real concept of a column in the DOM of an HTML table, but perhaps all the
TDs could grow a pseudo ::sorted-forward or something (handwaving here like
mad, obviously).
7. Case sensitivity in alphannumeric sorting. Some people like it, some
people don't; it's good to have some sort of author-controllable switch.
(Obviously solveable with <td
sorttable_customkey="INSENSITIVE">Insensitive</td> in the limit case, and
this, like many other things on this list, suggests that some sort of "here
is the JavaScript function I want you to use to produce sort keys for table
cells in this column" function is a useful idea. Sorttable allows this, and
people use it a lot.)
8. Mark a column as not sortable. Note: this does not mean that clicking on
that column doesn't sort it; it means that that column does not get sorted
*even when the rest of the table does*. This gets requested for a sort of
"left-hand header" concept, where the first column contains numbers, 1, 2,
3, 4 etc, one per row, to show which is row 1, row 2, row 3 etc of the
table. Obviously this column should not be sorted when the rest of the
table is. I'm not sure there's any good markup for this in HTML (<ol>s do
it, but there's no <ol> concept for <tr>s).
9. A commonly requested type of things to know how to automatically sort is
IP addresses. (I solve this by forwarding people the email explaining how
to add a new sort type function to sorttable, because I've never got around
to adding it to the script.)
10. Zebra-striped tables are a problem. Well, they're not a problem if
you're striping with CSS (#mytable tr:nth-child(2n) td { background: #eee;
}) but an awful lot of people bake the stripes into their HTML (<tr
class="even">), and this gets screwed up if you sort the table. The
solution here obviously might be to poke authors to do presentational stuff
with CSS instead and then their problems go away, but *lots* of people
complain about this.
11. Authors like the idea of having script callbacks before and after a
user action to sort, so they can do things to the table, show progress or
an hourglass, etc. This would presumably be neatly handled by firing a
"sort" event on the table or similar.
12. Stable sort: I recommend that the sort that's implemented be specified
as being a stable sort, because people who care really want it and write me
annoyed emails that it's not there, and no-one explicitly wants unstable
sort. :)
13. What happens if a table has multiple <tbody> elements? Do they sort as
independent units, or mingle together? Sorttable just sorts the first one
and ignores the rest, because multiple tbodies are uncommon, but that's not
really acceptable ;-)
14. Fixed-position rows. Many authors have a "totals" row at the bottom of
their table which should remain at the bottom of the table even after
sorting, which is easily handled (that's what <tfoot> is for), but some
authors also have rows midway through the table which are "headers": this
especially shows up in long tables, where the column headers from <thead>
are repeated midway down the table and should remain in position even when
the table is sorted. In general this means that they should remain the same
number of rows away from <thead>. This case is odd, and sorttable.js
doesn't handle it, but lots of people ask for it.

I hope that's useful. Happy to answer questions.

sil

-- 
New Year's Day --
everything is in blossom!
I feel about average.
   -- Kobayashi Issa

From faulkner.steve at gmail.com  Wed Nov  7 02:40:57 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Wed, 7 Nov 2012 10:40:57 +0000
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
Message-ID: <CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>

Hi Anne,

That feedback as stated was mainly for Hixie, who dismissed it.

I have sought further opinion, but do not have the expertise to know what I
need to do with it.

for example, I get the sense that implementers in general do not want to
mess with the parsing algorithm, so does that mean. I don't need to put
anything in the spec?

regards
SteveF

On 7 November 2012 10:30, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Wed, Nov 7, 2012 at 10:55 AM, Steve Faulkner
> <faulkner.steve at gmail.com> wrote:
> > Can anyone with the requisite knowledge provide advice on what needs to
> be
> > added (if anything) to the main element spec to define parsing for the
> > element?
>
> What did you do with the feedback you already got on this front?
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0155.html
>
>
>
> --
> http://annevankesteren.nl/
>

-- 
with regards

Steve Faulkner
Technical Director - TPG

From simonp at opera.com  Wed Nov  7 03:42:41 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 12:42:41 +0100
Subject: [whatwg] Sortable Tables
In-Reply-To: <509A2FCB.8030600@kosek.cz>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
	<50996B1A.7020601@mit.edu>
	<CAHp8n2mue9oZn=U8c7Opvx3iewvJGafT3UOEZKLuqHeJXs3B3g@mail.gmail.com>
	<509A2FCB.8030600@kosek.cz>
Message-ID: <op.wnehdwbridj3kv@device-23f190>

On Wed, 07 Nov 2012 10:54:19 +0100, Jirka Kosek <jirka at kosek.cz> wrote:

> On 6.11.2012 23:18, Silvia Pfeiffer wrote:
>
>> * data-type: date, number, text etc which determines the comparison
>> function used in sort
>
> It would be very difficult to support sorting on dates and numbers as in
> HTML they are usually present formatted using specific locale. So there
> should be additional attribute added to td/th which can hold sort key
> which will override cell contents, something like
>
> <td sortas="2012-11-07">11. listopadu 2012</td>

<time> exists, and <data> exists for non-time machine-readable data; maybe  
they can be utilized in some way?

-- 
Simon Pieters
Opera Software

From simonp at opera.com  Wed Nov  7 03:46:36 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 12:46:36 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
Message-ID: <op.wneizylpidj3kv@device-23f190>

On Wed, 07 Nov 2012 11:40:57 +0100, Steve Faulkner  
<faulkner.steve at gmail.com> wrote:

> Hi Anne,
>
> That feedback as stated was mainly for Hixie, who dismissed it.
>
> I have sought further opinion, but do not have the expertise to know  
> what I
> need to do with it.
>
> for example, I get the sense that implementers in general do not want to
> mess with the parsing algorithm, so does that mean. I don't need to put
> anything in the spec?

That's right.

I'm not convinced that we should freeze the parser now just because we  
have reached interop. I think not changing the parser here makes <main>   
(and other future elements; whatever we do here sets a precedent for  
future elements) inconsistent with the rest of HTML. In the long term,  
having <main> and <aside> parse differently just because we didn't want to  
change the behavior from 2012-era browsers will seem silly. Moreover, it  
will complicate the already complicated rules about when </p> may be  
omitted (in terms of how people think of the rule), which means that we  
might have to say that </p> is always required.

I'm also not convinced by Henri's assertion that <p> will not precede  
<main> in conforming content. <p> is used for all sorts of things, not  
just a paragraph of text.

-- 
Simon Pieters
Opera Software

From simonp at opera.com  Wed Nov  7 03:51:17 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 12:51:17 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <op.wneizylpidj3kv@device-23f190>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190>
Message-ID: <op.wnei7rnwidj3kv@device-23f190>

On Wed, 07 Nov 2012 12:46:36 +0100, Simon Pieters <simonp at opera.com> wrote:

> On Wed, 07 Nov 2012 11:40:57 +0100, Steve Faulkner  
> <faulkner.steve at gmail.com> wrote:
>
>> Hi Anne,
>>
>> That feedback as stated was mainly for Hixie, who dismissed it.
>>
>> I have sought further opinion, but do not have the expertise to know  
>> what I
>> need to do with it.
>>
>> for example, I get the sense that implementers in general do not want to
>> mess with the parsing algorithm, so does that mean. I don't need to put
>> anything in the spec?
>
> That's right.

OTOH, if we wanted <main> to parse like <aside>, we'd add "main" to:

[[
A start tag whose tag name is one of: "address", "article", "aside",  
"blockquote", "center", "details", "dialog", "dir", "div", "dl",  
"fieldset", "figcaption", "figure", "footer", "header", "hgroup", "menu",  
"nav", "ol", "p", "section", "summary", "ul"
]]

and:

[[
An end tag whose tag name is one of: "address", "article", "aside",  
"blockquote", "button", "center", "details", "dialog", "dir", "div", "dl",  
"fieldset", "figcaption", "figure", "footer", "header", "hgroup",  
"listing", "menu", "nav", "ol", "pre", "section", "summary", "ul"
]]

in  
http://www.whatwg.org/specs/web-apps/current-work/multipage/tree-construction.html#parsing-main-inbody

-- 
Simon Pieters
Opera Software

From jirka at kosek.cz  Wed Nov  7 03:55:46 2012
From: jirka at kosek.cz (Jirka Kosek)
Date: Wed, 07 Nov 2012 12:55:46 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <op.wneizylpidj3kv@device-23f190>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190>
Message-ID: <509A4C42.2000802@kosek.cz>

On 7.11.2012 12:46, Simon Pieters wrote:

> I'm not convinced that we should freeze the parser now just because we
> have reached interop. I think not changing the parser here makes <main> 
> (and other future elements; whatever we do here sets a precedent for
> future elements) inconsistent with the rest of HTML. In the long term,
> having <main> and <aside> parse differently just because we didn't want
> to change the behavior from 2012-era browsers will seem silly. Moreover,
> it will complicate the already complicated rules about when </p> may be
> omitted (in terms of how people think of the rule), which means that we
> might have to say that </p> is always required.

Changing parser each time new element is added is really evil idea and
sign of a bad design.

Parsing algorithm should be either not touched at all, or it should be
promptly changed to treat all unknown elements in other way if the
current treatment of unknown elements is not suitable for some reason.

Jirka

From annevk at annevk.nl  Wed Nov  7 03:58:40 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 7 Nov 2012 12:58:40 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <509A4C42.2000802@kosek.cz>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190> <509A4C42.2000802@kosek.cz>
Message-ID: <CADnb78ju8dSuqgt4s46jYHB9HAH4QKwxypwMjCBUU1VVR1h_ng@mail.gmail.com>

On Wed, Nov 7, 2012 at 12:55 PM, Jirka Kosek <jirka at kosek.cz> wrote:
> Changing parser each time new element is added is really evil idea and
> sign of a bad design.

HTML badly designed? Film at 11.

> Parsing algorithm should be either not touched at all, or it should be
> promptly changed to treat all unknown elements in other way if the
> current treatment of unknown elements is not suitable for some reason.

The problem is that the treatment of an element is largely a function
of its purpose.

-- 
http://annevankesteren.nl/

From simonp at opera.com  Wed Nov  7 04:13:30 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 13:13:30 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <509A4C42.2000802@kosek.cz>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190> <509A4C42.2000802@kosek.cz>
Message-ID: <op.wnej8sdridj3kv@device-23f190>

On Wed, 07 Nov 2012 12:55:46 +0100, Jirka Kosek <jirka at kosek.cz> wrote:

> Changing parser each time new element is added is really evil idea and
> sign of a bad design.
>
> Parsing algorithm should be either not touched at all, or it should be
> promptly changed to treat all unknown elements in other way if the
> current treatment of unknown elements is not suitable for some reason.

There are three ways to parse a new element that we probably want for new  
elements:

"inline" - like <span>, current behavior for unknown elements.
"block" - like <address>, currently a finite list of elements.
"void" - like <img>, currently a finite list of elements.
(Possibly also "block void", - like <hr>, although none such elements have  
been added since parsing was specified.)

If we were to design a system where we can make up new elements that go in  
one of those categories without changing the parser, I think we  
effectively have to put a magic string in the tag name, e.g. any element  
that starts with "block" is treated like <address>, but that has  
disadvantages:

* Looking at a substring of the tag name complicates the parser and  
probably ruins some optimizations.
* It means new non-inline elements will have long, ugly two-word names  
which is inconsistent with the rest of the language.

I can imagine other designs as well but they don't seem any better.

In conclusion, I think changing the parser when we introduce a new "block"  
or "void" element is a better approach.

-- 
Simon Pieters
Opera Software

From jirka at kosek.cz  Wed Nov  7 04:25:14 2012
From: jirka at kosek.cz (Jirka Kosek)
Date: Wed, 07 Nov 2012 13:25:14 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <op.wnej8sdridj3kv@device-23f190>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190> <509A4C42.2000802@kosek.cz>
	<op.wnej8sdridj3kv@device-23f190>
Message-ID: <509A532A.2090204@kosek.cz>

On 7.11.2012 13:13, Simon Pieters wrote:

> If we were to design a system where we can make up new elements that go
> in one of those categories without changing the parser, I think we
> effectively have to put a magic string in the tag name, e.g. any element
> that starts with "block" is treated like <address>, but that has
> disadvantages:
> 
> * Looking at a substring of the tag name complicates the parser and
> probably ruins some optimizations.
> * It means new non-inline elements will have long, ugly two-word names
> which is inconsistent with the rest of the language.

Indeed, this doesn't seem very appealing.

> I can imagine other designs as well but they don't seem any better.
> 
> In conclusion, I think changing the parser when we introduce a new
> "block" or "void" element is a better approach.

I think it's better to treat all new elements as inline (from parsing
point of view) then to change algorithm each time.

Changing parsing each time also means that such changes can't be undone.
Look for example at <hgroup>. It's supported by parsing algorithm as
implemented in browsers, so it will remain in spec forever even when
it's not actually implemented. With such approach parsing algorithm will
became boneyard of proposed but later thrown away elements over the time.

Jirka

From simonp at opera.com  Wed Nov  7 04:42:22 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 13:42:22 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <509A532A.2090204@kosek.cz>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190> <509A4C42.2000802@kosek.cz>
	<op.wnej8sdridj3kv@device-23f190> <509A532A.2090204@kosek.cz>
Message-ID: <op.wnelkwqzidj3kv@device-23f190>

On Wed, 07 Nov 2012 13:25:14 +0100, Jirka Kosek <jirka at kosek.cz> wrote:

> Changing parsing each time also means that such changes can't be undone.

They can be undone if doing so doesn't break the Web.

> Look for example at <hgroup>. It's supported by parsing algorithm as
> implemented in browsers, so it will remain in spec forever even when
> it's not actually implemented. With such approach parsing algorithm will
> became boneyard of proposed but later thrown away elements over the time.

I think we shouldn't put the parsing algorithm on a pedestal while not  
giving the same treatment to the default UA style sheet or other  
requirements related to an element that have to be implemented.

-- 
Simon Pieters
Opera Software

From hsivonen at iki.fi  Wed Nov  7 04:47:53 2012
From: hsivonen at iki.fi (Henri Sivonen)
Date: Wed, 7 Nov 2012 14:47:53 +0200
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <op.wnelkwqzidj3kv@device-23f190>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190> <509A4C42.2000802@kosek.cz>
	<op.wnej8sdridj3kv@device-23f190> <509A532A.2090204@kosek.cz>
	<op.wnelkwqzidj3kv@device-23f190>
Message-ID: <CAJQvAudnxL=xL2z7rOAcMuTpwVQ=riXY5g5HmGxq-5rhvG2PAA@mail.gmail.com>

On Wed, Nov 7, 2012 at 2:42 PM, Simon Pieters <simonp at opera.com> wrote:
> I think we shouldn't put the parsing algorithm on a pedestal while not
> giving the same treatment to the default UA style sheet or other
> requirements related to an element that have to be implemented.

The difference between the parsing algorithm on the UA stylesheet is
that authors can put display: block; in the author stylesheet during
the transition.

That said, the example jgraham showed to me on IRC convinced me that
if <main> is introduced to the platform, it makes sense to make it
parse like <article>. :-( (I?m not a fan of the consequences of the
?feature? of making </p> optional. Too bad that feature is ancient and
it?s too late on undo it.)

I guess I?ll focus on objecting to new void elements and especially to
new children of <head>.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From jirka at kosek.cz  Wed Nov  7 04:49:52 2012
From: jirka at kosek.cz (Jirka Kosek)
Date: Wed, 07 Nov 2012 13:49:52 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <op.wnelkwqzidj3kv@device-23f190>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190> <509A4C42.2000802@kosek.cz>
	<op.wnej8sdridj3kv@device-23f190> <509A532A.2090204@kosek.cz>
	<op.wnelkwqzidj3kv@device-23f190>
Message-ID: <509A58F0.5000204@kosek.cz>

On 7.11.2012 13:42, Simon Pieters wrote:

>> Look for example at <hgroup>. It's supported by parsing algorithm as
>> implemented in browsers, so it will remain in spec forever even when
>> it's not actually implemented. With such approach parsing algorithm will
>> became boneyard of proposed but later thrown away elements over the time.
> 
> I think we shouldn't put the parsing algorithm on a pedestal while not
> giving the same treatment to the default UA style sheet or other
> requirements related to an element that have to be implemented.

The difference is that deficiency of parsing algorithm can't be
compensated by JS or CSS. Until new element is widely supported you can
define it's styling in your CSS file or link to Javascript shim which
will provide functionality in older browsers. But I don't think that you
can alter parsing algorithm in the similar way.

Web browsers are now upgraded much more frequently and regularly so
change to PA might look like non problem. But various non-browser
applications are relying on HTML5 parsing libraries and those will not
be regularly updated.

Jirka

From simonp at opera.com  Wed Nov  7 05:04:34 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 14:04:34 +0100
Subject: [whatwg] main element parsing behaviour
In-Reply-To: <CAJQvAudnxL=xL2z7rOAcMuTpwVQ=riXY5g5HmGxq-5rhvG2PAA@mail.gmail.com>
References: <CA+ri+VnYnJUt8EcnshHZdGdU3XdWtfp-3c7RuYjtP+n1hX6_yQ@mail.gmail.com>
	<CADnb78jhRWj77+qQz7-m0rq9wKe6KMKUx3Xce=smYpM5-TJrag@mail.gmail.com>
	<CA+ri+VkrVqjW6e0zJtHebW2MQQRw0EOS9a8Ha5ynXxcDy=jRGg@mail.gmail.com>
	<op.wneizylpidj3kv@device-23f190> <509A4C42.2000802@kosek.cz>
	<op.wnej8sdridj3kv@device-23f190> <509A532A.2090204@kosek.cz>
	<op.wnelkwqzidj3kv@device-23f190>
	<CAJQvAudnxL=xL2z7rOAcMuTpwVQ=riXY5g5HmGxq-5rhvG2PAA@mail.gmail.com>
Message-ID: <op.wnemlwxjidj3kv@device-23f190>

On Wed, 07 Nov 2012 13:47:53 +0100, Henri Sivonen <hsivonen at iki.fi> wrote:

> On Wed, Nov 7, 2012 at 2:42 PM, Simon Pieters <simonp at opera.com> wrote:
>> I think we shouldn't put the parsing algorithm on a pedestal while not
>> giving the same treatment to the default UA style sheet or other
>> requirements related to an element that have to be implemented.
>
> The difference between the parsing algorithm on the UA stylesheet is
> that authors can put display: block; in the author stylesheet during
> the transition.

I guess that's fair.

> That said, the example jgraham showed to me on IRC convinced me that
> if <main> is introduced to the platform, it makes sense to make it
> parse like <article>. :-( (I?m not a fan of the consequences of the
> ?feature? of making </p> optional. Too bad that feature is ancient and
> it?s too late on undo it.)

For the record, the example is:

(The last <p> can be anything.)

> I guess I?ll focus on objecting to new void elements and especially to
> new children of <head>.

-- 
Simon Pieters
Opera Software

From simonp at opera.com  Wed Nov  7 05:59:08 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 14:59:08 +0100
Subject: [whatwg] <main> UA style sheet
Message-ID: <op.wneo4uhpidj3kv@device-23f190>

https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html  
says

[[
The User Agent style sheet should include the following style rule for the  
main element:
   main {
    display:block;
    }
]]

I think this is a bit inconsistent with the HTML spec.

First, it should be clear that this should hook in to the HTML spec's  
Rendering section, because this section has special rules when it comes to  
conformance classes and the use of words with requirements, as explained  
at the start of the section.

http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#rendering

This section also has this requirement:

[[
The CSS rules given in these subsections are, except where otherwise  
specified, expected to be used as part of the user-agent level style sheet  
defaults for all documents that contain HTML elements.
]]

I propose the following concrete text:

[[
=== Rendering ===

This section is to be treated as a subsection of HTML's Rendering section  
for the purpose of terminology, conformance classes and requirements.  
[HTML]

CSS:
... the style sheet ...
]]

Finally, I think the style sheet needs some tweaks. If we want <main> to  
have the same styles as <aside> (except for the effect <aside> has on  
<h1>, since <main> is not a sectioning element), I think the style sheet  
should be:

@namespace url(http://www.w3.org/1999/xhtml);
main { unicode-bidi: isolate; display: block; }

Replace this rule in the HTML spec:

:matches([dir=ltr i], [dir=rtl i], [dir=auto  
i]):not(address):not(blockquote
):not(center):not(div):not(figure):not(figcaption):not(footer):not(form
):not(header):not(hr):not(legend):not(listing):not(p):not(plaintext):not(pre
):not(summary):not(xmp):not(article):not(aside):not(h1):not(h2):not(h3):not(h4
):not(h5):not(h6):not(hgroup):not(nav):not(section):not(table):not(caption
):not(colgroup):not(col):not(thead):not(tbody):not(tfoot):not(tr):not(td
):not(th):not(dir):not(dd):not(dl):not(dt):not(menu):not(ol):not(ul):not(li)  
{
   unicode-bidi: embed;
}

with:

:matches([dir=ltr i], [dir=rtl i], [dir=auto  
i]):not(address):not(blockquote
):not(center):not(div):not(figure):not(figcaption):not(footer):not(form
):not(header):not(hr):not(legend):not(listing):not(p):not(plaintext):not(pre
):not(summary):not(xmp):not(article):not(aside):not(main):not(h1):not(h2):not(h3):not(h4
):not(h5):not(h6):not(hgroup):not(nav):not(section):not(table):not(caption
):not(colgroup):not(col):not(thead):not(tbody):not(tfoot):not(tr):not(td
):not(th):not(dir):not(dd):not(dl):not(dt):not(menu):not(ol):not(ul):not(li)  
{
   unicode-bidi: embed;
}

-- 
Simon Pieters
Opera Software

From simonp at opera.com  Wed Nov  7 06:23:27 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 15:23:27 +0100
Subject: [whatwg] A plea to Hixie to adopt <main>
Message-ID: <op.wnepv6u9idj3kv@device-23f190>

Hi,

My impression from TPAC is that implementors are on board with the idea of  
adding <main> to HTML, and we're left with Hixie objecting to it.

Hixie's argument is, I think, that the use case that <main> is intended to  
address is already possible by applying the Scooby-Doo algorithm, as James  
put it -- remove all elements that are not main content, <header>,  
<aside>, etc., and you're left with the main content.

I think the Scooby-Doo algorithm is a heuristic that is not reliable  
enough in practice, since authors are likely to put stuff outside the main  
content that do not get filtered out by the algorithm, and vice versa.

Implementations that want to support a "go to main content" or "highlight  
the main content", like Safari's Reader Mode, or whatever it's called,  
need to have various heuristics for detecting the main content, and is  
expected to work even for pages that don't use any of the new elements.  
However, I think using <main> as a way to opt out of the heuristic works  
better than using <aside> to opt out of the heuristic. For instance, it  
seems reasonable to use <aside> for a pull-quote as part of the main  
content, and you don't want that to be excluded, but the Scooby-Doo  
algorithm does that.

If there is anyone besides from Hixie who objects to adding <main>, it  
would be useful to hear it.

-- 
Simon Pieters
Opera Software

From ben.schwarz at gmail.com  Wed Nov  7 06:35:31 2012
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Thu, 8 Nov 2012 01:35:31 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <op.wnepv6u9idj3kv@device-23f190>
References: <op.wnepv6u9idj3kv@device-23f190>
Message-ID: <28A2FFB1-0CE5-4C6A-9941-EF7A5E3D66A2@gmail.com>

I generally markup pages using ARIA roles:

and variations thereafter?

If there were to be a <main> attribute (with an implicit ARIA role to match), where would it end? <contentinfo> <banner> ?
What is to be gained by adding an element, rather than using ARIA roles? Isn't that what ARIA is designed for?

On 08/11/2012, at 1:23 AM, "Simon Pieters" <simonp at opera.com> wrote:

> Hi,
> 
> My impression from TPAC is that implementors are on board with the idea of adding <main> to HTML, and we're left with Hixie objecting to it.
> 
> Hixie's argument is, I think, that the use case that <main> is intended to address is already possible by applying the Scooby-Doo algorithm, as James put it -- remove all elements that are not main content, <header>, <aside>, etc., and you're left with the main content.
> 
> I think the Scooby-Doo algorithm is a heuristic that is not reliable enough in practice, since authors are likely to put stuff outside the main content that do not get filtered out by the algorithm, and vice versa.
> 
> Implementations that want to support a "go to main content" or "highlight the main content", like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using <main> as a way to opt out of the heuristic works better than using <aside> to opt out of the heuristic. For instance, it seems reasonable to use <aside> for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that.
> 
> If there is anyone besides from Hixie who objects to adding <main>, it would be useful to hear it.
> 
> -- 
> Simon Pieters
> Opera Software

From jkorpela at cs.tut.fi  Wed Nov  7 06:48:34 2012
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Wed, 07 Nov 2012 16:48:34 +0200
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <op.wnepv6u9idj3kv@device-23f190>
References: <op.wnepv6u9idj3kv@device-23f190>
Message-ID: <509A74C2.3000503@cs.tut.fi>

2012-11-07 16:23, Simon Pieters wrote:

> Hixie's argument is, I think, that the use case that <main> is intended
> to address is already possible by applying the Scooby-Doo algorithm, as
> James put it -- remove all elements that are not main content, <header>,
> <aside>, etc., and you're left with the main content.

Hixie's idea is sufficient for determining the main content (in some 
sense) on a page that systematically uses the new structuring elements. 
This in turn is sufficient for some styling purposes, but not all purposes.

> I think the Scooby-Doo algorithm is a heuristic that is not reliable
> enough in practice, since authors are likely to put stuff outside the
> main content that do not get filtered out by the algorithm, and vice versa.

That's one point. Another point is that authors don't really need to use 
all the <header>, <nav>, etc. elements, and validation does not check 
for this. E.g., if you just want to have some styles that only apply to 
the main content, you might want to use just <main> and not all the 
other stuff.

But perhaps the strongest argument in favor of <main> is that the 
Scooby-Doo algorithm may determine the content, but it does not make it 
an element, on any DOM node. And elementhood is essential for many 
styling and scripting purposes.

> Implementations that want to support a "go to main content" or
> "highlight the main content", like Safari's Reader Mode, or whatever
> it's called, need to have various heuristics for detecting the main
> content, and is expected to work even for pages that don't use any of
> the new elements. However, I think using <main> as a way to opt out of
> the heuristic works better than using <aside> to opt out of the
> heuristic.

Sounds logical. And the Reader Mode functionality that you mention is 
one of the few signs of any meaningful support to the new structuring 
elements. There is much talk about the assumed "semantic" benefits of 
those elements, much less evidence of real benefits.

I suppose that the heuristics would include recognizing a <div> element 
to which class "main" has been assigned. Then one could argue that 
<main> is not needed, as authors can keep using <div class="main">, as 
millions of pages use. Then again, a similar argument would apply to 
<header> and friends.

> If there is anyone besides from Hixie who objects to adding <main>, it
> would be useful to hear it.

Well, I haven't seen much point in any of the new structuring elements 
in general, but the browser behavior you write about would make <main> 
much more relevant than the others.

Yucca

From faulkner.steve at gmail.com  Wed Nov  7 06:53:45 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Wed, 7 Nov 2012 14:53:45 +0000
Subject: [whatwg] A plea to Hixie to adopt <main>
Message-ID: <CA+ri+VnoOROJuaBpsBZ-KjAKV3ukiHs=wBJi18CiZb7h014Fpw@mail.gmail.com>

Hi Ben,

> I generally markup pages using ARIA roles:
>
> <header role=banner>
> <article role=main>
> <footer role=contentinfo>
>
> and variations thereafter?
>
> If there were to be a <main> attribute (with an implicit ARIA role to
> match), where would it end? <contentinfo> <banner> ?
> What is to be gained by adding an element, rather than using ARIA roles?
> Isn't that what ARIA is designed for?
>

various new HTML elements are already being mapped to ARIA or platform
accessibility APIs

<aside> is mapped to complementary ( IA2, AT-SPI and AX)
<article> is mapped to article ( IA2, AT-SPI and AX)
<nav> is mapped to navigation ( IA2, AT-SPI and AX)
<header>/<footer> are mapped to banner and conteninfo ( IA2, AT-SPI and AX)

etc.

this means when fuly implemented authors will not have to add aria roles
(built in vs bolt-on) the browsers do it already.

ARIA roles are used because the semantics are not fully implemented in
browsers yet.

If you take the time to read the spec [1] and supporting research you will
find the rationale and use cases detailed. Its based on commont authoring
practice.

[1]
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

regards
SteveF

On 08/11/2012, at 1:23 AM, "Simon Pieters" <simonp at opera.com> wrote:

> Hi,
>
> My impression from TPAC is that implementors are on board with the idea
of adding <main> to HTML, and we're left with Hixie objecting to it.
>
> Hixie's argument is, I think, that the use case that <main> is intended
to address is already possible by applying the Scooby-Doo algorithm, as
James put it -- remove all elements that are not main content, <header>,
<aside>, etc., and you're left with the main content.
>
> I think the Scooby-Doo algorithm is a heuristic that is not reliable
enough in practice, since authors are likely to put stuff outside the main
content that do not get filtered out by the algorithm, and vice versa.
>
> Implementations that want to support a "go to main content" or "highlight
the main content", like Safari's Reader Mode, or whatever it's called, need
to have various heuristics for detecting the main content, and is expected
to work even for pages that don't use any of the new elements. However, I
think using <main> as a way to opt out of the heuristic works better than
using <aside> to opt out of the heuristic. For instance, it seems
reasonable to use <aside> for a pull-quote as part of the main content, and
you don't want that to be excluded, but the Scooby-Doo algorithm does that.
>
> If there is anyone besides from Hixie who objects to adding <main>, it
would be useful to hear it.
>
> --
> Simon Pieters
> Opera Software

-- 
with regards

Steve Faulkner
Technical Director - TPG

From ben.schwarz at gmail.com  Wed Nov  7 06:59:00 2012
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Thu, 8 Nov 2012 01:59:00 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CA+ri+VnoOROJuaBpsBZ-KjAKV3ukiHs=wBJi18CiZb7h014Fpw@mail.gmail.com>
References: <CA+ri+VnoOROJuaBpsBZ-KjAKV3ukiHs=wBJi18CiZb7h014Fpw@mail.gmail.com>
Message-ID: <036FECC5-6C5D-41C1-A3E6-9C2C455C80AA@gmail.com>

Steve, you never fail to amaze me. (Thank you!)
So, with it laid out as clearly as that, the glaringly obvious missing element is <main>. (Thank you Simon)

Over to you, @Hixie.

On 08/11/2012, at 1:53 AM, Steve Faulkner <faulkner.steve at gmail.com> wrote:

> Hi Ben, 
>  
> I generally markup pages using ARIA roles:
> 
> <header role=banner>
> <article role=main> 
> <footer role=contentinfo>
> 
> and variations thereafter?
> 
> If there were to be a <main> attribute (with an implicit ARIA role to match), where would it end? <contentinfo> <banner> ?
> What is to be gained by adding an element, rather than using ARIA roles? Isn't that what ARIA is designed for? 
> 
> various new HTML elements are already being mapped to ARIA or platform accessibility APIs
> 
> <aside> is mapped to complementary ( IA2, AT-SPI and AX)
> <article> is mapped to article ( IA2, AT-SPI and AX)
> <nav> is mapped to navigation ( IA2, AT-SPI and AX)
> <header>/<footer> are mapped to banner and conteninfo ( IA2, AT-SPI and AX)
> 
> etc.
> 
> this means when fuly implemented authors will not have to add aria roles (built in vs bolt-on) the browsers do it already.
> 
> ARIA roles are used because the semantics are not fully implemented in browsers yet. 
> 
> If you take the time to read the spec [1] and supporting research you will find the rationale and use cases detailed. Its based on commont authoring practice.
> 
> 
> [1] https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
> 
> regards
> SteveF
> 
> On 08/11/2012, at 1:23 AM, "Simon Pieters" <simonp at opera.com> wrote:
> 
> > Hi,
> > 
> > My impression from TPAC is that implementors are on board with the idea of adding <main> to HTML, and we're left with Hixie objecting to it.
> > 
> > Hixie's argument is, I think, that the use case that <main> is intended to address is already possible by applying the Scooby-Doo algorithm, as James put it -- remove all elements that are not main content, <header>, <aside>, etc., and you're left with the main content.
> > 
> > I think the Scooby-Doo algorithm is a heuristic that is not reliable enough in practice, since authors are likely to put stuff outside the main content that do not get filtered out by the algorithm, and vice versa.
> > 
> > Implementations that want to support a "go to main content" or "highlight the main content", like Safari's Reader Mode, or whatever it's called, need to have various heuristics for detecting the main content, and is expected to work even for pages that don't use any of the new elements. However, I think using <main> as a way to opt out of the heuristic works better than using <aside> to opt out of the heuristic. For instance, it seems reasonable to use <aside> for a pull-quote as part of the main content, and you don't want that to be excluded, but the Scooby-Doo algorithm does that.
> > 
> > If there is anyone besides from Hixie who objects to adding <main>, it would be useful to hear it.
> > 
> > -- 
> > Simon Pieters
> > Opera Software
> 
> -- 
> with regards
> 
> Steve Faulkner
> Technical Director - TPG
> 
> www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner
> HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/
> Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html 
>

From simonp at opera.com  Wed Nov  7 07:08:35 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 07 Nov 2012 16:08:35 +0100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <28A2FFB1-0CE5-4C6A-9941-EF7A5E3D66A2@gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<28A2FFB1-0CE5-4C6A-9941-EF7A5E3D66A2@gmail.com>
Message-ID: <op.wnesclq2idj3kv@device-23f190>

On Wed, 07 Nov 2012 15:35:31 +0100, Ben Schwarz <ben.schwarz at gmail.com>  
wrote:

> I generally markup pages using ARIA roles:
>
> <header role=banner>
> <article role=main>
> <footer role=contentinfo>

There is an implicit mapping already.

> and variations thereafter?
>
> If there were to be a <main> attribute (with an implicit ARIA role to  
> match), where would it end?

It ends at <main> since that's the last landmark lacking an element.

> <contentinfo> <banner> ?

The are called <footer> and <header>.

> What is to be gained by adding an element, rather than using ARIA roles?

The gain is better ergonomics and more likelihood of getting accessible  
pages by people using the elements without doing extra work to cater for  
AT.

> Isn't that what ARIA is designed for?

The role and state part of ARIA was designed to be a stop-gap solution to  
make JS-based Web applications accessible in a way that would work in  
legacy IE with modern AT. The landmark part of ARIA was designed to do the  
same thing as the new elements in HTML. IIRC, landmarks were kept instead  
of embracing the new elements because the elements were specified in a  
document that was not expected to be finished in two decades whereas ARIA  
was expected to be finished in a much shorter time frame. That we would  
end up having both was not seen as a showstopper for either group.

-- 
Simon Pieters
Opera Software

From jkorpela at cs.tut.fi  Wed Nov  7 07:10:05 2012
From: jkorpela at cs.tut.fi (Jukka K. Korpela)
Date: Wed, 07 Nov 2012 17:10:05 +0200
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CA+ri+VnoOROJuaBpsBZ-KjAKV3ukiHs=wBJi18CiZb7h014Fpw@mail.gmail.com>
References: <CA+ri+VnoOROJuaBpsBZ-KjAKV3ukiHs=wBJi18CiZb7h014Fpw@mail.gmail.com>
Message-ID: <509A79CD.2040705@cs.tut.fi>

2012-11-07 16:53, Steve Faulkner wrote:

> ARIA roles are used because the semantics are not fully implemented in
> browsers yet.

It's a bit more complicated than that, isn't it? ARIA roles are also, 
and originally, meant for describing the meaning of elements that are 
used in "rich Internet applications" in a manner that cannot be deduced 
from the HTML markup. For example, if you set up a <span> element that 
acts as a checkbox, driven by JavaScript and formatted with CSS to look 
like a checkbox, then the ARIA role attribute is needed to inform 
browsers and assistive software about this.

Besides, many distinctions that can be made with ARIA roles cannot be 
described in HTML as currently defined. But that's not a big issue 
really, and it does not mean that corresponding elements should be added 
to HTML. ARIA has its role (no pun intended), and software that can 
currently handle role="foo" would really benefit nothing from the 
introduction of a <foo> element. It would be just some new stuff that 
should be supported in addition to existing support.

So the existence of something as an ARIA role value does not imply that 
a correspoding element should be added to HTML if not already present 
there. But neither does it constitute a counterargument to adding new 
elements.

Yucca

From derernst at gmx.ch  Wed Nov  7 08:00:34 2012
From: derernst at gmx.ch (Markus Ernst)
Date: Wed, 07 Nov 2012 17:00:34 +0100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <509A74C2.3000503@cs.tut.fi>
References: <op.wnepv6u9idj3kv@device-23f190> <509A74C2.3000503@cs.tut.fi>
Message-ID: <509A85A2.1010701@gmx.ch>

Am 07.11.2012 15:48 schrieb Jukka K. Korpela:
> I suppose that the heuristics would include recognizing a <div> element
> to which class "main" has been assigned. Then one could argue that
> <main> is not needed, as authors can keep using <div class="main">, as
> millions of pages use.

I doubt that this is useable for that kind of heuristics anyway - as 
there is no standard for this, "main" as a class name may indicate the 
main contents, but also a main container to center the whole page. Also, 
non-english speaking coders may use their own language words as id or 
class names.

From ojan at chromium.org  Wed Nov  7 08:52:13 2012
From: ojan at chromium.org (Ojan Vafai)
Date: Wed, 7 Nov 2012 08:52:13 -0800
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <op.wnepv6u9idj3kv@device-23f190>
References: <op.wnepv6u9idj3kv@device-23f190>
Message-ID: <CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>

On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters <simonp at opera.com> wrote:

> My impression from TPAC is that implementors are on board with the idea of
> adding <main> to HTML, and we're left with Hixie objecting to it.
>

For those of use who couldn't make it, which browser vendors voiced
support? I assume Opera since you're writing this thread.

Hixie's argument is, I think, that the use case that <main> is intended to
> address is already possible by applying the Scooby-Doo algorithm, as James
> put it -- remove all elements that are not main content, <header>, <aside>,
> etc., and you're left with the main content.
>
> I think the Scooby-Doo algorithm is a heuristic that is not reliable
> enough in practice, since authors are likely to put stuff outside the main
> content that do not get filtered out by the algorithm, and vice versa.
>
> Implementations that want to support a "go to main content" or "highlight
> the main content", like Safari's Reader Mode, or whatever it's called, need
> to have various heuristics for detecting the main content, and is expected
> to work even for pages that don't use any of the new elements. However, I
> think using <main> as a way to opt out of the heuristic works better than
> using <aside> to opt out of the heuristic. For instance, it seems
> reasonable to use <aside> for a pull-quote as part of the main content, and
> you don't want that to be excluded, but the Scooby-Doo algorithm does that.
>
> If there is anyone besides from Hixie who objects to adding <main>, it
> would be useful to hear it.

This idea doesn't seem to address any pressing use-cases. I don't expect
authors to use it as intended consistently enough for it to be useful in
practice for things like Safari's Reader mode. You're stuck needing to use
something like the Scooby-Doo algorithm most of the time anyways. I don't
outright object, but I think our time would be better spent on addressing
more pressing problems with the web platform.

From jgraham at opera.com  Wed Nov  7 09:48:49 2012
From: jgraham at opera.com (James Graham)
Date: Wed, 07 Nov 2012 18:48:49 +0100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
Message-ID: <509A9F01.1050905@opera.com>

On 11/07/2012 05:52 PM, Ojan Vafai wrote:
> On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters <simonp at opera.com> wrote:
>
>> My impression from TPAC is that implementors are on board with the idea of
>> adding <main> to HTML, and we're left with Hixie objecting to it.
>>
>
> For those of use who couldn't make it, which browser vendors voiced
> support? I assume Opera since you're writing this thread.

To be clear, "Opera" didn't voice support for anything. Some people from 
Opera suggested that it seemed like a reasonable idea (I think it seems 
like a reasonable idea).

> Hixie's argument is, I think, that the use case that <main> is intended to
>> address is already possible by applying the Scooby-Doo algorithm, as James
>> put it -- remove all elements that are not main content, <header>, <aside>,
>> etc., and you're left with the main content.
>>
>> I think the Scooby-Doo algorithm is a heuristic that is not reliable
>> enough in practice, since authors are likely to put stuff outside the main
>> content that do not get filtered out by the algorithm, and vice versa.
>>
>> Implementations that want to support a "go to main content" or "highlight
>> the main content", like Safari's Reader Mode, or whatever it's called, need
>> to have various heuristics for detecting the main content, and is expected
>> to work even for pages that don't use any of the new elements. However, I
>> think using <main> as a way to opt out of the heuristic works better than
>> using <aside> to opt out of the heuristic. For instance, it seems
>> reasonable to use <aside> for a pull-quote as part of the main content, and
>> you don't want that to be excluded, but the Scooby-Doo algorithm does that.
>>
>> If there is anyone besides from Hixie who objects to adding <main>, it
>> would be useful to hear it.
>
>
> This idea doesn't seem to address any pressing use-cases.

I think that finding the main content of a page has clear use cases. We 
can see examples of authors working around the lack of this feature in 
the platform every time they use a "skip to main" link, or (less 
commonly) aria role=main. I believe we also see browsers supporting 
role=main in their AT mapping, which suggests implementer interest in 
this approach since the solutions are functionally isomorphic (but with 
very different marketing and usability stories).

I think the argument that the Scooby Doo algorithm is deficient because 
it requires many elements of a page to be correctly marked up, compared 
to <main> which requires only a single element to get the same 
functional effect, has merit. The observation that having one element on 
a page marked ? via class or id ?  "main" is already a clear cowpath 
enhances the credibility of the suggested solution. On the other hand, I 
agree that now everyone heading down the cowpath was aiming for the same 
place; a <div class=main> wrapping the whole page, headers, footers, and 
all is clearly not the same as one that identifies the extent of the 
primary content. I don't know how these different uses stack up 
(apologies if it is in some research that I overlooked).

> I don't expect
> authors to use it as intended consistently enough for it to be useful in
> practice for things like Safari's Reader mode. You're stuck needing to use
> something like the Scooby-Doo algorithm most of the time anyways.

I think Maciej commented on this. IIRC, he said that it wouldn't be good 
enough for reader mode alone, but might usefully provide an extra piece 
of data for the heuristics.

> I don't
> outright object, but I think our time would be better spent on addressing
> more pressing problems with the web platform.

I think that's a very weak argument. In fact, given the current 
landscape I would expect this to swallow more of the web standards 
communities' time if it is not adopted than if it is. But I don't think 
that's a strong argument in favour of adopting it either.

From kanghaol at oupeng.com  Wed Nov  7 10:13:58 2012
From: kanghaol at oupeng.com (Kang-Hao (Kenny) Lu)
Date: Thu, 08 Nov 2012 02:13:58 +0800
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <509A9F01.1050905@opera.com>
References: <op.wnepv6u9idj3kv@device-23f190>	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com>
Message-ID: <509AA4E6.4060505@oupeng.com>

(12/11/08 1:48), James Graham wrote:
> I think that finding the main content of a page has clear use cases. We
> can see examples of authors working around the lack of this feature in
> the platform every time they use a "skip to main" link, or (less
> commonly) aria role=main. I believe we also see browsers supporting
> role=main in their AT mapping, which suggests implementer interest in
> this approach since the solutions are functionally isomorphic (but with
> very different marketing and usability stories).
> 
> I think the argument that the Scooby Doo algorithm is deficient because
> it requires many elements of a page to be correctly marked up, compared
> to <main> which requires only a single element to get the same
> functional effect, has merit.

Hixie's another argument, if I understand correctly, is to use <article>
in place of this role. I think the Web is probably full of mis-used
<article> already such that using the first <article> in document order
has no chance to work out, but it would nice if this can be verified,
even though I can already imagine that an author is unlikely to mark up
the main content with <article> when the main content isn't an article
in English sense.

> The observation that having one element on a page marked ? via class
> or id ?  "main" is already a clear cowpath enhances the credibility
> of the suggested solution. On the other hand, I agree that now
> everyone heading down the cowpath was aiming for the same place; a
> <div class=main> wrapping the whole page, headers, footers, and
> all is clearly not the same as one that identifies the extent of the
> primary content.

Right. So, assuming "skip to main" is the only use case for <main>,
which I am not sure if Steve agrees, I think the proposal should use
strong wording to prevent such misuse and the proposal should include
one example of such misuse and explains it.

Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/

From hugh.guiney at gmail.com  Wed Nov  7 10:25:29 2012
From: hugh.guiney at gmail.com (Hugh Guiney)
Date: Wed, 7 Nov 2012 13:25:29 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <509A9F01.1050905@opera.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com>
Message-ID: <CAEHyr+Y9NnXtWaMMVc1HwXzCswHB69kfiNp309jaRGAz7xcJgw@mail.gmail.com>

As a developer I'm in favor of this. Just take a look at the how
popular the question of "How do I enable Reader mode" is on SO[1], and
how complex and mysterious the actual algorithm appears to be[2], and
it's evident how authors and implementors alike could benefit from a
dedicated element.

Although, there's the question of how similar in definition it'd be to
<article>. Is it merely a more specific version of "a self-contained
composition [...] that is, in principle, independently distributable"?
Or is it a more specific <div>; a semantic "wrapper" element?

If it's the former, this could just as well be an empty attribute, as
<article main>. Not too different from ARIA, which maybe makes it a
little redundant, but it's less to type in CSS (article[main] vs
article[role="main"]), and also achieves landmark parity without
breaking "legacy" HTML parsers, frameworks, etc. which only expect
<article>.

If it's the latter, it probably makes more sense for it to be an
element, where it wouldn't say whether the content was self-contained
or not; just that its contents are considered the primary focus of the
page, except anything that would otherwise be excluded in the document
outline.

[1]: http://stackoverflow.com/questions/2997918/how-to-enable-ios-5-safari-reader-on-my-website
[2]: http://mathiasbynens.be/notes/safari-reader

From ian at hixie.ch  Wed Nov  7 11:38:02 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 7 Nov 2012 19:38:02 +0000 (UTC)
Subject: [whatwg] A plea to Hixie to adopt <main>,
 and main element parsing behaviour
In-Reply-To: <509AA4E6.4060505@oupeng.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
Message-ID: <Pine.LNX.4.64.1211071919250.5442@ps20323.dreamhostps.com>

On Wed, 7 Nov 2012, Simon Pieters wrote:
> 
> My impression from TPAC is that implementors are on board with the idea 
> of adding <main> to HTML, and we're left with Hixie objecting to it.

If implementors wish to implement something, my objecting is irrelevant. :-)

Just implement it.

> Hixie's argument is, I think, that the use case that <main> is intended 
> to address is already possible by applying the Scooby-Doo algorithm, as 
> James put it -- remove all elements that are not main content, <header>, 
> <aside>, etc., and you're left with the main content.

The reason there is no element <main> in the HTML spec currently is that 
there are no use cases for it that aren't already handled, right.

> I think the Scooby-Doo algorithm is a heuristic that is not reliable 
> enough in practice, since authors are likely to put stuff outside the 
> main content that do not get filtered out by the algorithm, and vice 
> versa.

That people will get markup wrong is a given. This will not obviously be 
any less the case with an element named <main> than an element named 
<article> or elements named <nav> or <aside> or <header>.

In fact, when we have looked at actual data for this (see e.g. the recent 
thread where I went through Steve's data, or the threads years ago when 
this first came up), it turns out authors are significantly more reliably 
using class names that relate to marking up navigation blocks and headers, 
than they are about marking up "main". Authors seem to put class="main" 
and equivalents around every possible combination of content in a page, 
purely based on their styling needs.

Thus if the use case is "determine where the boilerplate ends", i.e. 
skipping navigation blocks, headers, footers, and sidebars, the evidence 
I've examined suggests that it would be more reliable to have authors mark 
up those blocks than mark up "the main content".

> Implementations that want to support a "go to main content" or 
> "highlight the main content", like Safari's Reader Mode, or whatever 
> it's called, need to have various heuristics for detecting the main 
> content, and is expected to work even for pages that don't use any of 
> the new elements. However, I think using <main> as a way to opt out of 
> the heuristic works better than using <aside> to opt out of the 
> heuristic.

On what basis do you draw that conclusion?

> For instance, it seems reasonable to use <aside> for a pull-quote as 
> part of the main content, and you don't want that to be excluded, but 
> the Scooby-Doo algorithm does that.

If it's a pull quote, why would you _not_ want it excluded?

On Wed, 7 Nov 2012, Ojan Vafai wrote:
> 
> This idea doesn't seem to address any pressing use-cases. I don't expect 
> authors to use it as intended consistently enough for it to be useful in 
> practice for things like Safari's Reader mode. You're stuck needing to 
> use something like the Scooby-Doo algorithm most of the time anyways.

Exactly.

On Thu, 8 Nov 2012, Kang-Hao (Kenny) Lu wrote:
> 
> [...] another argument, if I understand correctly, is to use <article> 
> in place of this role. I think the Web is probably full of mis-used 
> <article> already such that using the first <article> in document order 
> has no chance to work out, but it would nice if this can be verified, 
> even though I can already imagine that an author is unlikely to mark up 
> the main content with <article> when the main content isn't an article 
> in English sense.

For the "jump to the start of the body" use case, <article> and <main> 
seem like they'd be misused exactly as much as each other.

> James Graham wrote:
> > The observation that having one element on a page marked ? via class 
> > or id ? "main" is already a clear cowpath enhances the credibility 
> > of the suggested solution. On the other hand, I agree that now 
> > everyone heading down the cowpath was aiming for the same place; a 
> > <div class=main> wrapping the whole page, headers, footers, and all is 
> > clearly not the same as one that identifies the extent of the primary 
> > content.
> 
> Right.

Studying the data, as I have done in previous threads, has always 
indicated that there is actually no cowpath here for "main". As James says 
above, these classes and IDs are used for all kinds of combinations of 
content and headers, content and navigation, just content, etc. If this is 
any indication, <main> wouldn't be useful for its stated purpose.

> So, assuming "skip to main" is the only use case for <main>, which I am 
> not sure if Steve agrees, I think the proposal should use strong wording 
> to prevent such misuse and the proposal should include one example of 
> such misuse and explains it.

The strength of the wording will have basically no effect, let's be 
realistic here. Few authors read the spec. It doesn't matter most of the 
time, because the failure mode if an author uses <em> instead of <var> or 
vice versa is just that the styling will be slightly off or maintenance 
will be slightly harder. The failure mode for <main> would be that its 
entire reason for existing (making a heuristic simpler) is lost.

On Wed, 7 Nov 2012, Simon Pieters wrote:
> 
> I'm not convinced that we should freeze the parser now just because we 
> have reached interop.

For the record, I personally do not consider the parser frozen.

If an implementor wants to implement <main>, they should IMHO do so by 
supporting it the same way as <article> is supported in the parser, with 
the DOM interface HTMLElement, with the same styling and (for conformance 
checkers and authoring tools) content model as <div>. However, I would 
recommend against implementing <main>, for the reasons given above.

> I think not changing the parser here makes <main> (and other future 
> elements; whatever we do here sets a precedent for future elements) 
> inconsistent with the rest of HTML. In the long term, having <main> and 
> <aside> parse differently just because we didn't want to change the 
> behavior from 2012-era browsers will seem silly.

Indeed. Given how relatively painless transitioning from no parser spec at 
all to having one at all actually ended up being, at least relative to 
what I was expecting, I think adding new elements isn't a big deal at all. 
(Even in the <head>.) We shouldn't add elements in general, but that's 
more about not expanding the language, not about the parser.

From silviapfeiffer1 at gmail.com  Wed Nov  7 13:07:10 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 8 Nov 2012 08:07:10 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <509A85A2.1010701@gmx.ch>
References: <op.wnepv6u9idj3kv@device-23f190> <509A74C2.3000503@cs.tut.fi>
	<509A85A2.1010701@gmx.ch>
Message-ID: <CAHp8n2mN-Sm9ULynUtgUBbpj6rBsBnHJS0BHy-LE5K7MbN2=sA@mail.gmail.com>

On Thu, Nov 8, 2012 at 3:00 AM, Markus Ernst <derernst at gmx.ch> wrote:

> Am 07.11.2012 15:48 schrieb Jukka K. Korpela:
>
>  I suppose that the heuristics would include recognizing a <div> element
>> to which class "main" has been assigned. Then one could argue that
>> <main> is not needed, as authors can keep using <div class="main">, as
>> millions of pages use.
>>
>
> I doubt that this is useable for that kind of heuristics anyway - as there
> is no standard for this, "main" as a class name may indicate the main
> contents, but also a main container to center the whole page. Also,
> non-english speaking coders may use their own language words as id or class
> names.
>

Agreed.

Looking at existing uses of <div class="main"> to analyse whether we need a
<main> element really doesn't make sense to me. I firmly believe that
class="main" is mostly used for CSS purposes and not for semantic (and thus
accessibility) purposes.

Instead, we should be looking at pages that use <xxx role=main> or more
traditionally in older Web pages use a "skip to main" link as the use cases
for a <main> element. Sometimes that may co-incide with <div class="main">,
but not in general.

Therefore, I don't actually think that the introduction in Steve's
document  is making a good case for the existence of the element with this
sentence:
"The main element formalises the common
practice<https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html#common>of
identification of the main content section of a document using the
id values such as 'content' and 'main'."

I'd suggest explaining that there is currently no explicit means of
identifying with 100% accuracy what part of a Web page is the single most
important part. Instead we have a solution only for accessibility purposes
with the @role="main" ARIA attribute, or more traditionally by providing a
"skip to main" link on the top of the page. If there was a <main> element
that semantically identified the important part of a Web page, that would
improve accessibility, but also enable for example search engines to give
that part of a Web page a higher importance.

On that latter part: I am always annoyed when a search engine gives me
links to a particular topic that I was searching for which is only
mentioned in a side bar as some related information. It would be possible
to exclude such content if there was a <main> element. The argument that
<article> and <aside> etc. will do away with such problems relies on
authors actually making use of these elements. I am yet to see that happen
- in fact I have seen people that started using these elements go away from
them again, since they don't seem to have any obvious advantage. <main> on
the other hand has a very real advantage - immediately for accessibility -
and its easier to put a single <main> element on a page than to introduce a
whole swag of new elements. It's the simplicity of that single element that
will make it immediately usable by everyone, will reduce the probability of
authoring error, and thus make it reliable for search engines and other
semantic uses.

Regards,
Silvia.

From ben.schwarz at gmail.com  Wed Nov  7 14:04:49 2012
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Thu, 8 Nov 2012 09:04:49 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <509AA4E6.4060505@oupeng.com>
References: <op.wnepv6u9idj3kv@device-23f190>	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
Message-ID: <16214F02-DC2D-4C99-A463-37AB6B7EE512@gmail.com>

"Skip to main" isn't the only use case :-)

FYI, as a web designer, (slap me here) I've almost never designed in a "skip to main" link. 
Call me ignorant (probably fitting), but in the "real world" a new way to markup 'skip to main' isn't on my mind.

What does concern me, as a web builder, *every day*, is how I markup the content in-between a <header> and a <footer>.

Consider the following:

In this (real, cutdown) example, I was marking up a series of events on a page. Headers and footers, then ? something in the middle.

<article>
<header>h1, h2, p</header>
<div class="content"></div>
<footer>time, a.permalink</footer>
</article>

In this (also, real) situation, I separated the main content of my page from the 'chrome' of the site, headers, footers, etc.

<div role="main" class="grid spine">
    <header>
      <h1>Lets talk</h1>
      <p>Product, sales or press enquiries?</p>
    </header>

The fact of the matter is that web authors are already inventing "main", daily.

Just some examples from the files open behind my mail right now. Happy to provide more!

Best,

Ben

On 08/11/2012, at 5:13 AM, "Kang-Hao (Kenny) Lu" <kanghaol at oupeng.com> wrote:

> (12/11/08 1:48), James Graham wrote:
>> I think that finding the main content of a page has clear use cases. We
>> can see examples of authors working around the lack of this feature in
>> the platform every time they use a "skip to main" link, or (less
>> commonly) aria role=main. I believe we also see browsers supporting
>> role=main in their AT mapping, which suggests implementer interest in
>> this approach since the solutions are functionally isomorphic (but with
>> very different marketing and usability stories).
>> 
>> I think the argument that the Scooby Doo algorithm is deficient because
>> it requires many elements of a page to be correctly marked up, compared
>> to <main> which requires only a single element to get the same
>> functional effect, has merit. 
> 
> Hixie's another argument, if I understand correctly, is to use <article>
> in place of this role. I think the Web is probably full of mis-used
> <article> already such that using the first <article> in document order
> has no chance to work out, but it would nice if this can be verified,
> even though I can already imagine that an author is unlikely to mark up
> the main content with <article> when the main content isn't an article
> in English sense.
> 
>> The observation that having one element on a page marked ? via class
>> or id ?  "main" is already a clear cowpath enhances the credibility
>> of the suggested solution. On the other hand, I agree that now
>> everyone heading down the cowpath was aiming for the same place; a
>> <div class=main> wrapping the whole page, headers, footers, and
>> all is clearly not the same as one that identifies the extent of the
>> primary content.
> 
> Right. So, assuming "skip to main" is the only use case for <main>,
> which I am not sure if Steve agrees, I think the proposal should use
> strong wording to prevent such misuse and the proposal should include
> one example of such misuse and explains it.
> 
> 
> Cheers,
> Kenny
> -- 
> Web Specialist, Oupeng Browser, Beijing
> Try Oupeng: http://www.oupeng.com/

From ben.schwarz at gmail.com  Wed Nov  7 14:11:50 2012
From: ben.schwarz at gmail.com (Ben Schwarz)
Date: Thu, 8 Nov 2012 09:11:50 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2mN-Sm9ULynUtgUBbpj6rBsBnHJS0BHy-LE5K7MbN2=sA@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190> <509A74C2.3000503@cs.tut.fi>
	<509A85A2.1010701@gmx.ch>
	<CAHp8n2mN-Sm9ULynUtgUBbpj6rBsBnHJS0BHy-LE5K7MbN2=sA@mail.gmail.com>
Message-ID: <BDE81AC5-A8A4-4694-87F7-016C5F2C99DF@gmail.com>

In response to Silvia's comments?

I think relying on <xxx role=""> is a pretty good result, I think we need to stretch further.

An <article> is a piece of content that isn't semantically defined on its parents. (right?)
Shouldn't we have a way to define this without confusing the "main" content of the 'page'?

On 08/11/2012, at 8:07 AM, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:

> On Thu, Nov 8, 2012 at 3:00 AM, Markus Ernst <derernst at gmx.ch> wrote:
> 
>> Am 07.11.2012 15:48 schrieb Jukka K. Korpela:
>> 
>> I suppose that the heuristics would include recognizing a <div> element
>>> to which class "main" has been assigned. Then one could argue that
>>> <main> is not needed, as authors can keep using <div class="main">, as
>>> millions of pages use.
>>> 
>> 
>> I doubt that this is useable for that kind of heuristics anyway - as there
>> is no standard for this, "main" as a class name may indicate the main
>> contents, but also a main container to center the whole page. Also,
>> non-english speaking coders may use their own language words as id or class
>> names.
>> 
> 
> Agreed.
> 
> Looking at existing uses of <div class="main"> to analyse whether we need a
> <main> element really doesn't make sense to me. I firmly believe that
> class="main" is mostly used for CSS purposes and not for semantic (and thus
> accessibility) purposes.
> 
> Instead, we should be looking at pages that use <xxx role=main> or more
> traditionally in older Web pages use a "skip to main" link as the use cases
> for a <main> element. Sometimes that may co-incide with <div class="main">,
> but not in general.
> 
> Therefore, I don't actually think that the introduction in Steve's
> document  is making a good case for the existence of the element with this
> sentence:
> "The main element formalises the common
> practice<https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html#common>of
> identification of the main content section of a document using the
> id values such as 'content' and 'main'."
> 
> I'd suggest explaining that there is currently no explicit means of
> identifying with 100% accuracy what part of a Web page is the single most
> important part. Instead we have a solution only for accessibility purposes
> with the @role="main" ARIA attribute, or more traditionally by providing a
> "skip to main" link on the top of the page. If there was a <main> element
> that semantically identified the important part of a Web page, that would
> improve accessibility, but also enable for example search engines to give
> that part of a Web page a higher importance.
> 
> On that latter part: I am always annoyed when a search engine gives me
> links to a particular topic that I was searching for which is only
> mentioned in a side bar as some related information. It would be possible
> to exclude such content if there was a <main> element. The argument that
> <article> and <aside> etc. will do away with such problems relies on
> authors actually making use of these elements. I am yet to see that happen
> - in fact I have seen people that started using these elements go away from
> them again, since they don't seem to have any obvious advantage. <main> on
> the other hand has a very real advantage - immediately for accessibility -
> and its easier to put a single <main> element on a page than to introduce a
> whole swag of new elements. It's the simplicity of that single element that
> will make it immediately usable by everyone, will reduce the probability of
> authoring error, and thus make it reliable for search engines and other
> semantic uses.
> 
> Regards,
> Silvia.

From ian at hixie.ch  Wed Nov  7 14:41:57 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 7 Nov 2012 22:41:57 +0000 (UTC)
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <16214F02-DC2D-4C99-A463-37AB6B7EE512@gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
	<16214F02-DC2D-4C99-A463-37AB6B7EE512@gmail.com>
Message-ID: <Pine.LNX.4.64.1211072240490.5442@ps20323.dreamhostps.com>

On Thu, 8 Nov 2012, Ben Schwarz wrote:
> 
> What does concern me, as a web builder, *every day*, is how I markup the 
> content in-between a <header> and a <footer>.

If you just want it for styling purposes, <div> is perfect.

> <article>
> <header>h1, h2, p</header>
> <div class="content"></div>
> <footer>time, a.permalink</footer>
> </article>

Exactly like that (or even without the class, if you just have one per 
article you can just do "article > div" to select it).

From gavinp at chromium.org  Wed Nov  7 14:47:16 2012
From: gavinp at chromium.org (=?UTF-8?B?R2F2aW4gUGV0ZXJzICjok4vmloflvbzlvrfmlq8p?=)
Date: Wed, 7 Nov 2012 17:47:16 -0500
Subject: [whatwg] Proposal: Link prerender events
Message-ID: <CAB2HWxjdwka2EebLB3Hj1S7cK0++bhxqGvdzg-86ecvSj+sYpg@mail.gmail.com>

Hi Whatwg!

I'm continuing to work on <link rel=prerender>, an API in WebKit,
implemented by Chrome, which allows applications to request pages be loaded
early for faster navigation. This is a leading cause of 0ms navigations on
the web!

As we've explored this feature, we've continued to add to the API to allow
more applications to benefit from prerender, and measure that benefit. At
launch time, prerenders lasted 30s in Chrome before being removed to
prevent stale navigations. Now, the default is 5m, in part because we use
application removal of a <link rel=prerender ...> element as a signal to
kill the prerender, similar to the <applet> or <object> element.

I just wrote up a short proposal at:
http://wiki.whatwg.org/wiki/Link_prerender_events discussing the next idea
we're working on.

By passing events to applications using prerenders, the applications will
better measure their use of prerender, and better control how they are
launched (serially or in parallel). The proposal has the details.

There's patches already in work to do this in WebKit and Chrome, see
https://bugs.webkit.org/show_bug.cgi?id=96474 for WebKit and
http://codereview.chromium.org/10918189/ for the embarrassingly out of date
Chrome version of this patch.

In the current revision of the patch, these events are webkit prefixed. I
would rather clear that sooner rather than later, but I'm inexperienced
enough not to know when is appropriate. What does whatwg think?

Thanks!

- Gavin

From esprehn at gmail.com  Wed Nov  7 17:10:44 2012
From: esprehn at gmail.com (Elliott Sprehn)
Date: Wed, 7 Nov 2012 17:10:44 -0800
Subject: [whatwg] Improving autocomplete
In-Reply-To: <CADnb78j8CW+Hasi4yD9u2HDU6NUB173mEfjszJ_TOaKWsJ1wkg@mail.gmail.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<CADnb78iHXJb4_C61ZQO0Am3gRQhNDpJ2Vqcuk17TyAARAid5pQ@mail.gmail.com>
	<CAJE5ia8-HSXL0UcEvssXee7ukiRnW3VmBcVFzME6NnUxOrCE8Q@mail.gmail.com>
	<CADnb78j8CW+Hasi4yD9u2HDU6NUB173mEfjszJ_TOaKWsJ1wkg@mail.gmail.com>
Message-ID: <CAPJYB1g2K9Od_P2v3iNdmj_jwiJmJHPiaAaEmixdY5-_1QSqpg@mail.gmail.com>

On Fri, Oct 26, 2012 at 3:09 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Fri, Oct 26, 2012 at 10:01 AM, Adam Barth <w3c at adambarth.com> wrote:
> > When should the UA offer to fill in the form (e.g., to select which
> > address they would like to use for shipping this particular order)?
>
> Presumably on page load.
>
>
It was our experience that making this judgement call is difficult, and
giving authors control is better than guessing. There's also technical
issues such as dynamically created forms when using page load, or our
primary use case which is hidden forms and a button that launches this UI
which is very attractive on mobile.

So to answer your original question about use cases, we want to make it
easy for an author to declaratively describe a data set and then request
the information from the browser. Using this we want to make it trivial,
especially on mobile, to request the information from the UA to allow
faster form filling experiences (ex. shipping forms, payment forms, login
forms, etc.)

> > In particular, Elliott wrote:
> >
> >> Authors can also display
> >> no forms at all to users of a browser who implements this proposal for
> >> one click checkout experiences which are important on mobile devices.
>
> I guess in that case it would be nice to know the user agent actually
> did display some UI.
>
>
Indeed, if the browser is incapable of displaying a UI we should fire an
error event.

Are we using "cancel" elsewhere by the way? Fullscreen uses "error" as
> suffix for the event type.
>

That's a great idea, I've unified the naming with fullscreen.

- E

From tkent at chromium.org  Wed Nov  7 22:52:05 2012
From: tkent at chromium.org (TAMURA, Kent)
Date: Thu, 8 Nov 2012 15:52:05 +0900
Subject: [whatwg] Incomplete user-input in some input types
In-Reply-To: <CAGH7WqETKxxpGT9DpOJmjcvYhUb50qvpk9vHgsaUfGQ342eTgg@mail.gmail.com>
References: <CAGH7WqETKxxpGT9DpOJmjcvYhUb50qvpk9vHgsaUfGQ342eTgg@mail.gmail.com>
Message-ID: <CAGH7WqEVZRVYUzR7s30PEkkEivH7LsGu_JNBhyDpsF15uGjqjQ@mail.gmail.com>

> A. In such case, make input.validity.typeMismatch true, or
> B. Introduce new IDL attribute to ValidityState.
> input.validity.invalidUserInput?

C. Just validity.valid becomes false.
    An implementation would have an internal flag like invalidUserInput, but
it won't be exposed via IDL.

C would have less impact to the standard.  If no one has concern about this
idea, I'd like to implement C in WebKit.

On Thu, Sep 13, 2012 at 3:18 PM, TAMURA, Kent <tkent at chromium.org> wrote:
> Proposal:

> Making an input element invalid state if the input has an invalid string
> specified by a user with browser UI. "An invalid string" means a string
> which doesn't match to a required format defined by a type.

>     e.g. If a user typed "-" to input[type=number], input.validity.valid
> would
> be false and form submission would be prevented.

> A. In such case, make input.validity.typeMismatch true, or
> B. Introduce new IDL attribute to ValidityState.
> input.validity.invalidUserInput?

> This behavior should be applied to the following types:
>     number, color, date, datetime, datettime-local, month, time, and week

> Background:
>     If an input type is implemented as a text field, it is very hard for UA
> to
> reject invalid strings for the type. For example, "-" is not a valid
> floating-point number, but UA can't prevent users from typing "-".  So the
> field can contain invalid strings though its value IDL attribute is empty.
> If a user tries to submit the form in such situation, the field is valid
> unless the required attribute is specified.
>     WebKit clears the invalid string when the field loses focus or the form
> is
> submitted.  A sanitized value (empty string) is submitted.
>     Opera doesn't clear the invalid string. It silently submits a sanitized
> value (empty string).
>     IE10 has a behavior similar to WebKit.  However if a user type "-1abc",
> "-1abc" is submitted.

> I don't like clearing user input.  It's not a good user experience.  Users
> don't expect their input strings are cleared by UA.
> Also, I don't like submitting empty value silently. Users expect their
> input
> strings are submitted.
> I think the best UI is to notify users about a field has an invalid
> string,
> and give a chance to correct it.  Applying the standard form validation
> mechanism must be reasonable.

> --
> TAMURA Kent
> Software Engineer, Google

-- 
TAMURA Kent
Software Engineer, Google

From annevk at annevk.nl  Thu Nov  8 00:50:35 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 8 Nov 2012 09:50:35 +0100
Subject: [whatwg] Incomplete user-input in some input types
In-Reply-To: <CAGH7WqEVZRVYUzR7s30PEkkEivH7LsGu_JNBhyDpsF15uGjqjQ@mail.gmail.com>
References: <CAGH7WqETKxxpGT9DpOJmjcvYhUb50qvpk9vHgsaUfGQ342eTgg@mail.gmail.com>
	<CAGH7WqEVZRVYUzR7s30PEkkEivH7LsGu_JNBhyDpsF15uGjqjQ@mail.gmail.com>
Message-ID: <CADnb78heLMPJOSS05bqmbs1SH8EV_a7mu1F-S1vg2O2g2sxyTA@mail.gmail.com>

On Thu, Nov 8, 2012 at 7:52 AM, TAMURA, Kent <tkent at chromium.org> wrote:
> C. Just validity.valid becomes false.
>    An implementation would have an internal flag like invalidUserInput, but
> it won't be exposed via IDL.
>
> C would have less impact to the standard.  If no one has concern about this
> idea, I'd like to implement C in WebKit.

I actually think exposing the UI state makes sense. It's also going to
be exposed through a selector:
http://dev.w3.org/csswg/selectors4/#user-error-pseudo

-- 
http://annevankesteren.nl/

From faulkner.steve at gmail.com  Thu Nov  8 01:51:19 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Thu, 8 Nov 2012 09:51:19 +0000
Subject: [whatwg] A plea to Hixie to adopt <main>,
 and main element parsing behaviour
In-Reply-To: <Pine.LNX.4.64.1211071919250.5442@ps20323.dreamhostps.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
	<Pine.LNX.4.64.1211071919250.5442@ps20323.dreamhostps.com>
Message-ID: <CA+ri+VnD2+RJPmPocCBrrdxdWsxcY2-S1C6=EpwMGyHi-by=0g@mail.gmail.com>

Hi all,

responses in line

On 7 November 2012 19:38, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 7 Nov 2012, Simon Pieters wrote:
> >
> > My impression from TPAC is that implementors are on board with the idea
> > of adding <main> to HTML, and we're left with Hixie objecting to it.
>
> If implementors wish to implement something, my objecting is irrelevant.
> :-)
>
> Just implement it.
>

It appears that some implementers would like Hixie to spec <main>, but he
is unwilling as he disagrees with the feature,

In a hallway discussion with a microsoft rep at TPAC he indicated that IE
would have no objections to implementing the feature was introduced via
the  HTML WG, which is what is happening at the moment. I also asked other
browser implementers who indicated that agreement from Hixie was not a
prerequisite for implementation. I suggest what is a prerequisite is clear
use cases and data to back them up and a well defined spec of the feature.
These are provided via the main spec and linked documents [1]

I have also spoken to various browser accessibility engineers who have
agreed that it would be a useful addition to complete the HTML element -
ARIA landmark mapping, and that the accessibility part would be trivial to
implement [4]:

I am generally in favor of a <main> element, and FWIW, implementation of
the semantics should be trivial in WebKit, or any UA that supports the ARIA
'main' landmark role already.

another data point: when i discussed the main element with one of the
mozilla accessibility engineers they suggested that it would be useful for
providing a built in skip to content link, which is one of the use cases.

> > Hixie's argument is, I think, that the use case that <main> is intended
> > to address is already possible by applying the Scooby-Doo algorithm, as
> > James put it -- remove all elements that are not main content, <header>,
> > <aside>, etc., and you're left with the main content.
>
> The reason there is no element <main> in the HTML spec currently is that
> there are no use cases for it that aren't already handled, right.
>

The use cases data and rationale have been provided [1]. If you have
objections it would be useful to respond to them rather than restating your
position.

> > I think the Scooby-Doo algorithm is a heuristic that is not reliable
> > enough in practice, since authors are likely to put stuff outside the
> > main content that do not get filtered out by the algorithm, and vice
> > versa.
>
> That people will get markup wrong is a given. This will not obviously be
> any less the case with an element named <main> than an element named
> <article> or elements named <nav> or <aside> or <header>.
>

Agreed that people get markup wrong, I don't agree with your supposition
that <main> would be just as prone to mistakes as the other elements you
cited.

<main> is a  simple concept, and its use is clearly defined, its limitation
of use once per page makes it less prone to mistakes in its use, it is
based on concepts that are evident in authoring practises and the evidence
of the strong correlation between elements (typically divs) identifying the
main content area and their use for role=main and the target of skip links
indicates the concept is already understood and in use.

>
> In fact, when we have looked at actual data for this (see e.g. the recent
> thread where I went through Steve's data, or the threads years ago when
> this first came up), it turns out authors are significantly more reliably
> using class names that relate to marking up navigation blocks and headers,
> than they are about marking up "main". Authors seem to put class="main"
> and equivalents around every possible combination of content in a page,
> purely based on their styling needs.
>

Problem is Ian,  you haven't responded to the data and use cases, you have
have misdirected the discussion by continuing to talk about class names,
when the data and use cases and rationale are based on the use of id values.

Did the year's old previous discussion take into account id value data or
skip link data or role=main placement data?

What the relevant new data clearly indicates is that in approx 80% of cases
when authors identify the main area of content it is the part of the
content that does not include header, footer or navigation content.

It also indicates that where skip links are present or role=main is used
their position correlates highly with the use of id values designating the
main content area of a page.

furthermore when ARIA role=main is used in 95% [3] of the cases in the data
sampled it is used once only which is a clear indicator that authors get
how to identify  the main content area of a page.

*  use of a descriptive id to value to identify the main content area of a
web page is common.
(id="main"|id="content"|id="
maincontent"|id="content-main"|id="main-content"
used on 39% of the pages in the sample [2])

* There is a strong correlation between use of role='main' on an element
with id values of 'content' or 'main' or permutations. (when used = 101
pages)  77% were on an element with id values of 'content' or 'main' or
permutations.
* There is a strong correlation between use of id values of 'content' or
'main' or permutations as targets for 'skip to content'/'skip to main
content' links (when used = 67 pages) 78% of skip link targets # were
elements with id values of 'content' or 'main' or permutations.
* There appears to be a strong correlation in the identification of content
areas (with id values of 'content' or 'main' or permutations.) as what is
described in the spec as appropriate content to be contained with a
<main> element [1]

>
> Thus if the use case is "determine where the boilerplate ends", i.e.
> skipping navigation blocks, headers, footers, and sidebars, the evidence
> I've examined suggests that it would be more reliable to have authors mark
> up those blocks than mark up "the main content".
>

as stated above you have been looking at class names not id values.

> > Implementations that want to support a "go to main content" or
> > "highlight the main content", like Safari's Reader Mode, or whatever
> > it's called, need to have various heuristics for detecting the main
> > content, and is expected to work even for pages that don't use any of
> > the new elements. However, I think using <main> as a way to opt out of
> > the heuristic works better than using <aside> to opt out of the
> > heuristic.
>
> On what basis do you draw that conclusion?
>
>
> > For instance, it seems reasonable to use <aside> for a pull-quote as
> > part of the main content, and you don't want that to be excluded, but
> > the Scooby-Doo algorithm does that.
>
> If it's a pull quote, why would you _not_ want it excluded?
>
>
> On Wed, 7 Nov 2012, Ojan Vafai wrote:
> >
> > This idea doesn't seem to address any pressing use-cases. I don't expect
> > authors to use it as intended consistently enough for it to be useful in
> > practice for things like Safari's Reader mode. You're stuck needing to
> > use something like the Scooby-Doo algorithm most of the time anyways.
>
> Exactly.
>

Exactly what? that the commenter agrees with your position, nothing else in
the statement is obvious.

>
>
> On Thu, 8 Nov 2012, Kang-Hao (Kenny) Lu wrote:
> >
> > [...] another argument, if I understand correctly, is to use <article>
> > in place of this role. I think the Web is probably full of mis-used
> > <article> already such that using the first <article> in document order
> > has no chance to work out, but it would nice if this can be verified,
> > even though I can already imagine that an author is unlikely to mark up
> > the main content with <article> when the main content isn't an article
> > in English sense.
>
> For the "jump to the start of the body" use case, <article> and <main>
> seem like they'd be misused exactly as much as each other.
>
>
A statement of supposition only, article is not as simply defined or simple
to know when and when not to use as the main element.

>
> > James Graham wrote:
> > > The observation that having one element on a page marked ? via class
> > > or id ? "main" is already a clear cowpath enhances the credibility
> > > of the suggested solution. On the other hand, I agree that now
> > > everyone heading down the cowpath was aiming for the same place; a
> > > <div class=main> wrapping the whole page, headers, footers, and all is
> > > clearly not the same as one that identifies the extent of the primary
> > > content.
> >
> > Right.
>
> Studying the data, as I have done in previous threads, has always
> indicated that there is actually no cowpath here for "main". As James says
> above, these classes and IDs are used for all kinds of combinations of
> content and headers, content and navigation, just content, etc. If this is
> any indication, <main> wouldn't be useful for its stated purpose.
>
>
> > So, assuming "skip to main" is the only use case for <main>, which I am
> > not sure if Steve agrees, I think the proposal should use strong wording
> > to prevent such misuse and the proposal should include one example of
> > such misuse and explains it.
>
> The strength of the wording will have basically no effect, let's be
> realistic here. Few authors read the spec. It doesn't matter most of the
> time, because the failure mode if an author uses <em> instead of <var> or
> vice versa is just that the styling will be slightly off or maintenance
> will be slightly harder. The failure mode for <main> would be that its
> entire reason for existing (making a heuristic simpler) is lost.
>
>
> On Wed, 7 Nov 2012, Simon Pieters wrote:
> >
> > I'm not convinced that we should freeze the parser now just because we
> > have reached interop.
>
> For the record, I personally do not consider the parser frozen.
>
> If an implementor wants to implement <main>, they should IMHO do so by
> supporting it the same way as <article> is supported in the parser, with
> the DOM interface HTMLElement, with the same styling and (for conformance
> checkers and authoring tools) content model as <div>. However, I would
> recommend against implementing <main>, for the reasons given above.
>
>
> > I think not changing the parser here makes <main> (and other future
> > elements; whatever we do here sets a precedent for future elements)
> > inconsistent with the rest of HTML. In the long term, having <main> and
> > <aside> parse differently just because we didn't want to change the
> > behavior from 2012-era browsers will seem silly.
>
> Indeed. Given how relatively painless transitioning from no parser spec at
> all to having one at all actually ended up being, at least relative to
> what I was expecting, I think adding new elements isn't a big deal at all.
> (Even in the <head>.) We shouldn't add elements in general, but that's
> more about not expanding the language, not about the parser.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[1]
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction
http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html

[2]
http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-data-for-the-masses/

[3]
http://www.paciellogroup.com/blog/2012/04/html5-accessibility-chops-real-world-aria-landmark-use/

[4] http://lists.w3.org/Archives/Public/public-html/2012Nov/0085.html
-- 
with regards

Steve Faulkner
Technical Director - TPG

From cmhjones at gmail.com  Thu Nov  8 02:43:37 2012
From: cmhjones at gmail.com (Cameron Jones)
Date: Thu, 8 Nov 2012 10:43:37 +0000
Subject: [whatwg] Sortable Tables
In-Reply-To: <op.wnehdwbridj3kv@device-23f190>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
	<50996B1A.7020601@mit.edu>
	<CAHp8n2mue9oZn=U8c7Opvx3iewvJGafT3UOEZKLuqHeJXs3B3g@mail.gmail.com>
	<509A2FCB.8030600@kosek.cz> <op.wnehdwbridj3kv@device-23f190>
Message-ID: <CALGrgev69chXjoam4R=_GszR2BFfBbaP3jWP=4-cV0EQPqtMyg@mail.gmail.com>

On Wed, Nov 7, 2012 at 11:42 AM, Simon Pieters <simonp at opera.com> wrote:

> On Wed, 07 Nov 2012 10:54:19 +0100, Jirka Kosek <jirka at kosek.cz> wrote:
>
>  On 6.11.2012 23:18, Silvia Pfeiffer wrote:
>>
>>  * data-type: date, number, text etc which determines the comparison
>>> function used in sort
>>>
>>
>> It would be very difficult to support sorting on dates and numbers as in
>> HTML they are usually present formatted using specific locale. So there
>> should be additional attribute added to td/th which can hold sort key
>> which will override cell contents, something like
>>
>> <td sortas="2012-11-07">11. listopadu 2012</td>
>>
>
> <time> exists, and <data> exists for non-time machine-readable data; maybe
> they can be utilized in some way?
>
>
I have done some investigation in this area too and having concrete
datatypes would make this more utilizable, ie from the proposal for <data
type="" value=""/>

http://www.w3.org/wiki/User:Cjones/ISSUE-184

The other area of integration would be with BCP-47 language tags and the
CLDR which include i18n collation information, for example british numeric
collation:

en-GB-*u-kn-true*

The significant benefit with this is that this standard is already
universal across server\client and is of course fully internationalized.

The other aspect of this is that there is a distinction between server
pagination including sort ordering defining the content of a page and the
client-based sorting which would be more of a presentational customization
and outside the scope of pagination. As such, it may be better for the HTML
to markup the structure of the content with sorting and collation but for
this to be configurable through CSS without the structural DOM changes.

This could also apply to HTML lists: <ul> <ol>, <dl>.

Thanks,
Cameron Jones

From slightlyoff at google.com  Thu Nov  8 04:17:52 2012
From: slightlyoff at google.com (Alex Russell)
Date: Thu, 8 Nov 2012 12:17:52 +0000
Subject: [whatwg] Sortable Tables
In-Reply-To: <CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
Message-ID: <CANr5HFUkPQjX0rU=fYfJwJkeqAEj85sk-MJk8eCSwmhe+dGNfQ@mail.gmail.com>

I'm much more inclined to solve this from the data axis. Asking the table
itself to do the sorting is weird. Instead, you most often want to have
some data source return you rows in sorted order (or indicate row order).
If you do something like MDV, sorting the table is applying a sort to the
template that stamped out the view. That works with DOM-table backed tables
as well as server or JS-backed tables.

On Tue, Nov 6, 2012 at 7:39 PM, Ojan Vafai <ojan at chromium.org> wrote:

> On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson <ian at hixie.ch> wrote:
>
> > On Thu, 1 Jul 2010, Christoph P?per wrote:
> > >
> > > It's a common task outside HTML to sort tables by one or more of its
> > > columns.
> > >
> > > There does seem interest among web content providers in making tables
> > > client-side sortable since there are several Javascript solutions to do
> > > just that, eg. <http://meta.wikimedia.org/wiki/Help:Sorting>,
> > > <http://tablesorter.com/docs/>. From these we can learn what would be
> > > needed from markup to help sorting algorithms. None of this must be
> > > behaviorial, but descriptionary.
> > >
> > > For starters, only rows inside ?tbody?s shall be reordered. For now
> > > columns don?t have to be reordered, ie. only vertical, no horizontal
> > > sorting. Nevertheless the design should make it possible to add the
> > > other direction later.
> > >
> > > Not every table has content that makes sense to be sorted in a
> different
> > > order. So sortable tables should be marked as such. Note that ?col? and
> > > ?colgroup? elements are hardly supported.
> > >
> > > Not every column has content that makes sense to be sorted in a
> > > different order. So non-sortable columns inside sortable tables should
> > > be marked as such.
> > >
> > > There are different ways to sort, eg. numeric, temporal or alphabetic
> > > and ascending or descending. Therefore columns should bear information
> > > how they should be sorted, ie. what kind of content their cells have.
> > >
> > > Several columns may be used for sorting by some kind of priority.
> > >
> > > The original order must be restorable.
> > >
> > > Cell content may not consist of the string that should be used verbatim
> > > for sorting purposes, eg. leading articles or similar numbers with
> > > different units (?g?, ?kg?, ?t? ?). Cells should have an optional
> > > attribute indicating their sort key. The ?time? element already
> provides
> > > the necessary metadata features for temporal sorting ? maybe there
> > > should be more of such elements instead.
> > >
> > > There may be columns that shall remain stable, eg. rank numbers.
> >
> > This is a very interesting idea.
> >
> > Is this something browser vendors would be interested in implementing?
> I'm
> > hesitant to add a feature for this (which could be somewhat involved)
> > before having the definite interest of some browser implementors.
>
>
> This is a use-case that I absolutely think it makes sense to address. This
> is extremely common whenever people use tables for actual tabular data and
> it's non-trivial to do in a way that performs well. I'd have to see a more
> concrete proposal in order to evaluate whether I'd be interested in
> implementing it.
>
> A couple thoughts off the top of my head:
> 1. Would sorting actually reorder the DOM nodes or just change their visual
> order? It's not clear to me which one is better. I think the former is what
> you'd want most of the time.
> 2. What values should the sort property allow. One idea is that it takes a
> JS function similar to what JavaScript's sort function takes. If you leave
> it out then it just does alphanumeric sort.
> 3. What elements does it go on? I don't see what it would do on a td. I
> could see putting it on a th though. Also, it's not clear to me what would
> get sorted. For example, in some tables, you would group trs inside tbodys
> and want to sort those.
>

From slightlyoff at google.com  Thu Nov  8 06:22:20 2012
From: slightlyoff at google.com (Alex Russell)
Date: Thu, 8 Nov 2012 14:22:20 +0000
Subject: [whatwg] [URL] DOM API Feedback
Message-ID: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>

Howdy all,

Anne asked me to send feedback on the DOM API for the new URL spec (
http://url.spec.whatwg.org/#api) to this list. Here goes:

First, I love that this looks sane, like what you need most of the time,
and will plumb through to the browser's parsing algorithm without requiring
me to re-write this sort of thing (badly) every time I need it. +1 for
adding a good DOM API!

Next, nicely done on having a meaningful constructor! I do wonder if the
"url" parameter should be optional as well as the base, since you may
either want to build a URL using a URL object (to be serialized later).

Looking at what URL/URLUtils provides, I noted a couple of things I'd like
to see that I miss from
google-url<http://code.google.com/p/google-url/source/browse/trunk/src/gurl.h>(a.k.a.
"GURL", the URL library we use in Chrome):

- GetWithEmptyPath() & GetOrigin() (despite their terrible C++ naming)
   are hugely useful for doing comparisons. I could imagine that there's some
   - "username" and "password" properties are missing
   - There aren't any provided comparison functions. I.e., there's no way
   to tell if two URL objects reference the same absolute URL, if
   one references a path in the same domain, etc.
   - Is there any attempt to parse query parameters and/or return a form
   data object from them?

Also, what's the default base URL? If I'm in a document with a base set,
are instances that don't specify one relative to the origin of the window
object from which the instance is created? I ask, because in the caes of:

new URL("/thinger.html");

I'd expect identical calls like that to have different toString() values if
executed on foo.com and bar.com. It was unclear to me if that's the case
today.

Anyhow, I like this. Nice work!

From christoph.paeper at crissov.de  Thu Nov  8 08:09:17 2012
From: christoph.paeper at crissov.de (=?iso-8859-1?Q?Christoph_P=E4per?=)
Date: Thu, 8 Nov 2012 17:09:17 +0100
Subject: [whatwg] Sortable Tables
In-Reply-To: <Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
Message-ID: <331FF9A8-81EB-4D19-B04F-AD442F48B003@crissov.de>

Ian Hickson:
> On Thu, 1 Jul 2010, Christoph P?per wrote:

Darn, my reply from yesterday got lost in data nirvana. This is a slightly shorter version thereof.

>> So sortable tables should be marked as such.

Opt-in:

?sortable=auto? should be the default and resolve to ?sortable? if at least one column has a sort key assigned, and to ?fixed? (or the like) otherwise.

(Row and column collapsing is a related, but different beast. Let?s deal with that separately, later.)

>> Note that ?col? and ?colgroup? elements are hardly supported.

Nevertheless, it?s usually sufficient to mark one column as containing values to use as sort key.

Columns inherit the key from their group, but may override it.

>> non-sortable columns inside sortable tables should be marked as such.

key=none

Not to be confused with fixed columns.

>> There are different ways to sort, eg. numeric, temporal or alphabetic

key=numeric 1 < 2 < 10
  key=alpha   ? = ? = Ä (= a?), 1 < 10 < 2
  key=date    2012-11-08 = 2012-W45-4
  key=value   1000 g = 1 kg = 0.001 t > 1 lb

key=style   although Excel can do this to some degree, it?s hardly useful
  key=class   slightly more useful
  key=id      ditto

>> and ascending or descending.

That?s better left to the UI: switch order when sorting for the second time.

>> Several columns may be used for sorting by some kind of priority.

Also primarily a UI question: use previously sorted column as secondary key.

key=1       primary key for heuristic sorting algorithm

>> The original order must be restorable.

UI again, e.g. tristate column sort: ascending, descending, original, ?

>> Cells should have an optional attribute indicating their sort key.

<td value=0.454>1 lb

>> There may be columns that shall remain stable, eg. rank numbers.

key=fixed

The sorting algorithm should not work on cells, but on slots (or slot values rather).

Cells spanning multiple rows or columns may have to be split into one cell per slot and should be rejoined afterwards if possible. Note that ?rowspan? itself is safe for vertical sorting, unless it spans a ?fixed? column. Also, ?colspan? is safe when it appears in the column to be sorted by.

td {color: green}
  [rowspan] {color: red}

<tr><td>1 <td rowspan=2>red                  1  red
  <tr><td>3                     =sort=col1=>   2  green
  <tr><td>2 <td>green                          3  red

The text reads its color! A cell at (1,1) ? counting starts from 0 ? never exists, the slot at the same position changes its value from ?red? to ?green?.

From ojan at chromium.org  Thu Nov  8 08:59:35 2012
From: ojan at chromium.org (Ojan Vafai)
Date: Thu, 8 Nov 2012 08:59:35 -0800
Subject: [whatwg] Sortable Tables
In-Reply-To: <CANr5HFUkPQjX0rU=fYfJwJkeqAEj85sk-MJk8eCSwmhe+dGNfQ@mail.gmail.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
	<CANr5HFUkPQjX0rU=fYfJwJkeqAEj85sk-MJk8eCSwmhe+dGNfQ@mail.gmail.com>
Message-ID: <CANMdWTsTWbJgRvmmw62=sHqpHSkZVQ+gtrpfdoqCHBcU=4O+wA@mail.gmail.com>

I like this approach. One thing this loses is having default styling for
sortable headers. It would be awesome if sortable tables looked the same
across pages instead of each page needing to invent their own up/down arrow
UI.

Also, is MDV intelligent enough to know that you just moved items around or
will it clobber and recreate the entire DOM?

On Thu, Nov 8, 2012 at 4:17 AM, Alex Russell <slightlyoff at google.com> wrote:

> I'm much more inclined to solve this from the data axis. Asking the table
> itself to do the sorting is weird. Instead, you most often want to have
> some data source return you rows in sorted order (or indicate row order).
> If you do something like MDV, sorting the table is applying a sort to the
> template that stamped out the view. That works with DOM-table backed tables
> as well as server or JS-backed tables.
>
>
> On Tue, Nov 6, 2012 at 7:39 PM, Ojan Vafai <ojan at chromium.org> wrote:
>
>> On Tue, Nov 6, 2012 at 11:25 AM, Ian Hickson <ian at hixie.ch> wrote:
>>
>> > On Thu, 1 Jul 2010, Christoph P?per wrote:
>> > >
>> > > It's a common task outside HTML to sort tables by one or more of its
>> > > columns.
>> > >
>> > > There does seem interest among web content providers in making tables
>> > > client-side sortable since there are several Javascript solutions to
>> do
>> > > just that, eg. <http://meta.wikimedia.org/wiki/Help:Sorting>,
>> > > <http://tablesorter.com/docs/>. From these we can learn what would be
>> > > needed from markup to help sorting algorithms. None of this must be
>> > > behaviorial, but descriptionary.
>> > >
>> > > For starters, only rows inside ?tbody?s shall be reordered. For now
>> > > columns don?t have to be reordered, ie. only vertical, no horizontal
>> > > sorting. Nevertheless the design should make it possible to add the
>> > > other direction later.
>> > >
>> > > Not every table has content that makes sense to be sorted in a
>> different
>> > > order. So sortable tables should be marked as such. Note that ?col?
>> and
>> > > ?colgroup? elements are hardly supported.
>> > >
>> > > Not every column has content that makes sense to be sorted in a
>> > > different order. So non-sortable columns inside sortable tables should
>> > > be marked as such.
>> > >
>> > > There are different ways to sort, eg. numeric, temporal or alphabetic
>> > > and ascending or descending. Therefore columns should bear information
>> > > how they should be sorted, ie. what kind of content their cells have.
>> > >
>> > > Several columns may be used for sorting by some kind of priority.
>> > >
>> > > The original order must be restorable.
>> > >
>> > > Cell content may not consist of the string that should be used
>> verbatim
>> > > for sorting purposes, eg. leading articles or similar numbers with
>> > > different units (?g?, ?kg?, ?t? ?). Cells should have an optional
>> > > attribute indicating their sort key. The ?time? element already
>> provides
>> > > the necessary metadata features for temporal sorting ? maybe there
>> > > should be more of such elements instead.
>> > >
>> > > There may be columns that shall remain stable, eg. rank numbers.
>> >
>> > This is a very interesting idea.
>> >
>> > Is this something browser vendors would be interested in implementing?
>> I'm
>> > hesitant to add a feature for this (which could be somewhat involved)
>> > before having the definite interest of some browser implementors.
>>
>>
>> This is a use-case that I absolutely think it makes sense to address. This
>> is extremely common whenever people use tables for actual tabular data and
>> it's non-trivial to do in a way that performs well. I'd have to see a more
>> concrete proposal in order to evaluate whether I'd be interested in
>> implementing it.
>>
>> A couple thoughts off the top of my head:
>> 1. Would sorting actually reorder the DOM nodes or just change their
>> visual
>> order? It's not clear to me which one is better. I think the former is
>> what
>> you'd want most of the time.
>> 2. What values should the sort property allow. One idea is that it takes a
>> JS function similar to what JavaScript's sort function takes. If you leave
>> it out then it just does alphanumeric sort.
>> 3. What elements does it go on? I don't see what it would do on a td. I
>> could see putting it on a th though. Also, it's not clear to me what would
>> get sorted. For example, in some tables, you would group trs inside tbodys
>> and want to sort those.
>>
>
>

From jackalmage at gmail.com  Thu Nov  8 09:29:06 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Thu, 8 Nov 2012 09:29:06 -0800
Subject: [whatwg] Sortable Tables
In-Reply-To: <CANMdWTsTWbJgRvmmw62=sHqpHSkZVQ+gtrpfdoqCHBcU=4O+wA@mail.gmail.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
	<CANMdWTvqU7YKXqmGaJYZVpY32MeHOPfGVQ7vkM05xB6VPT6BJw@mail.gmail.com>
	<CANr5HFUkPQjX0rU=fYfJwJkeqAEj85sk-MJk8eCSwmhe+dGNfQ@mail.gmail.com>
	<CANMdWTsTWbJgRvmmw62=sHqpHSkZVQ+gtrpfdoqCHBcU=4O+wA@mail.gmail.com>
Message-ID: <CAAWBYDCZv7wu_jBGc97q_xpQ5RCbC3Z0_u1nehY14UgYMt5tbQ@mail.gmail.com>

On Thu, Nov 8, 2012 at 8:59 AM, Ojan Vafai <ojan at chromium.org> wrote:
> On Thu, Nov 8, 2012 at 4:17 AM, Alex Russell <slightlyoff at google.com> wrote:
>> I'm much more inclined to solve this from the data axis. Asking the table
>> itself to do the sorting is weird. Instead, you most often want to have
>> some data source return you rows in sorted order (or indicate row order).
>> If you do something like MDV, sorting the table is applying a sort to the
>> template that stamped out the view. That works with DOM-table backed tables
>> as well as server or JS-backed tables.
>
> I like this approach. One thing this loses is having default styling for
> sortable headers. It would be awesome if sortable tables looked the same
> across pages instead of each page needing to invent their own up/down arrow
> UI.

Agreed, I favor a DOM-based solution because of this.

> Also, is MDV intelligent enough to know that you just moved items around or
> will it clobber and recreate the entire DOM?

It *should* be intelligent enough to recognize moves, as opposed to
just add/deletes.  Ask Raf or Adam about their progress on getting
this done.

~TJ

From bobbyholley at gmail.com  Thu Nov  8 10:19:02 2012
From: bobbyholley at gmail.com (Bobby Holley)
Date: Thu, 8 Nov 2012 10:19:02 -0800
Subject: [whatwg] Location object identity and navigation behavior
Message-ID: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>

The current spec for the Location object doesn't match reality. At the
moment, the spec says that Location is a per-Window object that describes
the associated Document. However, in our testing, it appears that none of
the user-agents (Gecko, WebKit, Trident, Presto) do this [1]. Instead, all
implementations of Location describe the active document in the browsing
context (that is to say, the referent of the WindowProxy). This suggests
that the spec's current language is likely not web-compatible.

If the Location object describes the browsing context, we're left to
consider whether there should be one Location object per Window or one
Location object per browsing context. Gecko and Webkit currently do the
former, and Trident and Presto do the latter (see again [1]). I would like
to change Gecko's behavior here [2], because would simplify a lot of
security invariants and generally make things more sane. How do WebKit
folks feel about this?

If Location follows the WindowProxy, an interesting question is what
happens to expando properties on navigation. I did some testing, and UAs
seem to have pretty inconsistent behavior here [3]. As such, I think the
sanest policy is simply to clear expandos on Location each time the page is
navigated. This is the approach I've taken in the patches in [2].

Thoughts?

Cheers,
bholley

[1] http://people.mozilla.org/~mwobensmith/window_test/doc_win.htm
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=808608
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=808608#c8

From w3c at adambarth.com  Thu Nov  8 17:58:24 2012
From: w3c at adambarth.com (Adam Barth)
Date: Thu, 8 Nov 2012 17:58:24 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
Message-ID: <CAJE5ia89Wz=bff9v3xHTfMCc2cR47T2a43iEw+KYzbAjwAQcEQ@mail.gmail.com>

On Thu, Nov 8, 2012 at 6:22 AM, Alex Russell <slightlyoff at google.com> wrote:
> Howdy all,
>
> Anne asked me to send feedback on the DOM API for the new URL spec (
> http://url.spec.whatwg.org/#api) to this list. Here goes:
>
> First, I love that this looks sane, like what you need most of the time,
> and will plumb through to the browser's parsing algorithm without requiring
> me to re-write this sort of thing (badly) every time I need it. +1 for
> adding a good DOM API!
>
> Next, nicely done on having a meaningful constructor! I do wonder if the
> "url" parameter should be optional as well as the base, since you may
> either want to build a URL using a URL object (to be serialized later).
>
> Looking at what URL/URLUtils provides, I noted a couple of things I'd like
> to see that I miss from
> google-url<http://code.google.com/p/google-url/source/browse/trunk/src/gurl.h>(a.k.a.
> "GURL", the URL library we use in Chrome):
>
>
>    - GetWithEmptyPath() & GetOrigin() (despite their terrible C++ naming)
>    are hugely useful for doing comparisons. I could imagine that there's some

http://url.spec.whatwg.org/#dom-url-origin is the equivalent to GURL's
GetOrigin().

>    - "username" and "password" properties are missing
>    - There aren't any provided comparison functions. I.e., there's no way
>    to tell if two URL objects reference the same absolute URL, if
>    one references a path in the same domain, etc.

The notion of "the same absolute URL" is a bit slippery.  It depends
on how well you understand various URL components (e.g., octal
encodings of IP addesss).  We could define something, of course, but
we'd just need to do so carefully.

>    - Is there any attempt to parse query parameters and/or return a form
>    data object from them?

Yes, the http://url.spec.whatwg.org/#urlquery interface lets you get
at parsed URL parameters.  I don't think there's currently a way to
turn them into form data objects, but that would make sense.

We might also want to add a bulk setter that takes a Dictionary.

> Also, what's the default base URL? If I'm in a document with a base set,
> are instances that don't specify one relative to the origin of the window
> object from which the instance is created? I ask, because in the caes of:
>
>     new URL("/thinger.html");
>
> I'd expect identical calls like that to have different toString() values if
> executed on foo.com and bar.com. It was unclear to me if that's the case
> today.

That's covered in step 1 of
<http://url.spec.whatwg.org/#constructors>.  If there's no explicit
base, the URL is resolved relative to about:blank.  To me, that seems
better that implicitly using the document's base URL.  You can always
supply the document's base URL from document.baseURI if you want.

Adam

From w3c at adambarth.com  Thu Nov  8 18:09:54 2012
From: w3c at adambarth.com (Adam Barth)
Date: Thu, 8 Nov 2012 18:09:54 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
Message-ID: <CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>

On Thu, Nov 8, 2012 at 10:19 AM, Bobby Holley <bobbyholley at gmail.com> wrote:
> The current spec for the Location object doesn't match reality. At the
> moment, the spec says that Location is a per-Window object that describes
> the associated Document. However, in our testing, it appears that none of
> the user-agents (Gecko, WebKit, Trident, Presto) do this [1]. Instead, all
> implementations of Location describe the active document in the browsing
> context (that is to say, the referent of the WindowProxy). This suggests
> that the spec's current language is likely not web-compatible.
>
> If the Location object describes the browsing context, we're left to
> consider whether there should be one Location object per Window or one
> Location object per browsing context. Gecko and Webkit currently do the
> former, and Trident and Presto do the latter (see again [1]). I would like
> to change Gecko's behavior here [2], because would simplify a lot of
> security invariants and generally make things more sane. How do WebKit
> folks feel about this?

I'm not sure I quite understand what you mean here.  Can you describe
an experiment that would distinguish these cases?  I looked at [1],
but it was too complicated for me to understand quickly.

Consider the following case:

== Document A ==
<script>
Object.prototype.foo = "A1";
window.location.bar = "A2";

function f() {
  var loc = window.location;
  print(loc.foo); // print is a magic function that lets me see this value
  print(loc.bar);
}
</script>

== Document B ==
<script>
Object.prototype.foo = "B1";
window.location.bar = "B2";
</script>

1) Document A is displayed in browsing context X.
2) Browsing context X is navigated and now displays document B.
3) Function f is called.

What values are printed?

> If Location follows the WindowProxy, an interesting question is what
> happens to expando properties on navigation. I did some testing, and UAs
> seem to have pretty inconsistent behavior here [3]. As such, I think the
> sanest policy is simply to clear expandos on Location each time the page is
> navigated. This is the approach I've taken in the patches in [2].

I don't think I quite understand what you mean, but the way this works
in WebKit is that each Window object has its own Location object.  The
location object operates on the current Window for the WindowProxy.
In WebKit at least, it would be a security vulnerability to expose
JavaScript objects that belong to Document B to Document A because
that would give Document A access to the prototype objects for
Document B.

Adam

From bzbarsky at MIT.EDU  Thu Nov  8 22:21:22 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 08 Nov 2012 22:21:22 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
Message-ID: <509CA0E2.9050206@mit.edu>

On 11/8/12 6:09 PM, Adam Barth wrote:
> I don't think I quite understand what you mean, but the way this works
> in WebKit is that each Window object has its own Location object.

That's not how it works in Presto and Trident, as far as we can tell 
based on testing with "==".  In those, each WindowProxy has its own 
Location object.

> The location object operates on the current Window for the WindowProxy.

Yes.  _That_ all browsers are consistent on, and is totally not what the 
spec says right now.  In the spec, there is one Location per Window, and 
the object operates on the Window it's associated with.  The fact that 
this does not match any browsers is what makes us suspect the spec is 
not web-compatible.

> In WebKit at least, it would be a security vulnerability to expose
> JavaScript objects that belong to Document B to Document A because
> that would give Document A access to the prototype objects for
> Document B.

You presumably have a solution for this situation for the WindowProxy 
case, right?  Certainly Gecko does, and we would be using the same 
solution for Location if we tie the lifetime of a Location to the 
lifetime of a WindowProxy.

-Boris

P.S.  I'll leave it to Matt and Bobby to answer your question about your 
testcase with function f(), because while I suspect I know what UAs do 
there in practice there is no way to tell without actually testing...

From jgraham at opera.com  Fri Nov  9 00:37:25 2012
From: jgraham at opera.com (James Graham)
Date: Fri, 09 Nov 2012 09:37:25 +0100
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
Message-ID: <509CC0C5.6050205@opera.com>

On 11/08/2012 07:19 PM, Bobby Holley wrote:
> The current spec for the Location object doesn't match reality. At the
> moment, the spec says that Location is a per-Window object that describes
> the associated Document. However, in our testing, it appears that none of
> the user-agents (Gecko, WebKit, Trident, Presto) do this [1]. Instead, all
> implementations of Location describe the active document in the browsing
> context (that is to say, the referent of the WindowProxy). This suggests
> that the spec's current language is likely not web-compatible.
>
> If the Location object describes the browsing context, we're left to
> consider whether there should be one Location object per Window or one
> Location object per browsing context. Gecko and Webkit currently do the
> former, and Trident and Presto do the latter (see again [1]). I would like
> to change Gecko's behavior here [2], because would simplify a lot of
> security invariants and generally make things more sane. How do WebKit
> folks feel about this?
>
> If Location follows the WindowProxy, an interesting question is what
> happens to expando properties on navigation. I did some testing, and UAs
> seem to have pretty inconsistent behavior here [3]. As such, I think the
> sanest policy is simply to clear expandos on Location each time the page is
> navigated. This is the approach I've taken in the patches in [2].
>
> Thoughts?

Nothing specific on the design, but whatever the final consensus here is 
*please* submit your testcases for everyone to use. This stuff is 
difficult, and very hard to write tests for when you are not actively 
implementing. Without a good shared library of tests in this area we 
will probably have bad interoperability for many years to come.

From contact at nickshanks.com  Fri Nov  9 02:04:52 2012
From: contact at nickshanks.com (Nicholas Shanks)
Date: Fri, 9 Nov 2012 10:04:52 +0000
Subject: [whatwg] Default scope for table headers
In-Reply-To: <CAPGwD7h9YofNCn2OoS29rbhRaUA7XWGFFF1x0ZOOAx1pXSy+vQ@mail.gmail.com>
References: <CA+hEJVXAmBD6nRrai2hK3=gQKyOA9ZcTgEgW5ccq9+f5Fz91jA@mail.gmail.com>
	<20121001092141.GG6434@sideshowbarker>
	<CA+hEJVXuTrJ_hzcxQzkHiiZzkL_gUN44-VW9BC7Cr79PK28XDQ@mail.gmail.com>
	<20121001111315.GL6434@sideshowbarker>
	<CAPGwD7h9YofNCn2OoS29rbhRaUA7XWGFFF1x0ZOOAx1pXSy+vQ@mail.gmail.com>
Message-ID: <CA+hEJVXJEGEYbYepQL7odgiRF40g6_QL16zg-OcZRBY03JKiwA@mail.gmail.com>

Merci beaucoup Pierre. That was quite a detailed reply!

-- 
Nicholas.

From bobbyholley at gmail.com  Fri Nov  9 08:59:12 2012
From: bobbyholley at gmail.com (Bobby Holley)
Date: Fri, 9 Nov 2012 08:59:12 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
Message-ID: <CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>

On Thu, Nov 8, 2012 at 6:09 PM, Adam Barth <w3c at adambarth.com> wrote:

> I'm not sure I quite understand what you mean here.  Can you describe
> an experiment that would distinguish these cases?  I looked at [1],
> but it was too complicated for me to understand quickly.
>
> Consider the following case:
>
> == Document A ==
> <script>
> Object.prototype.foo = "A1";
> window.location.bar = "A2";
>
> function f() {
>   var loc = window.location;
>   print(loc.foo); // print is a magic function that lets me see this value
>   print(loc.bar);
> }
> </script>
>
> == Document B ==
> <script>
> Object.prototype.foo = "B1";
> window.location.bar = "B2";
> </script>
>
> 1) Document A is displayed in browsing context X.
> 2) Browsing context X is navigated and now displays document B.
> 3) Function f is called.
>
> What values are printed?
>

Under the proposed behavior, both documents share the same Location object.
So when f() is called for on the navigated-away-from scope, loc.bar is "B2"
(assuming that print() is magic enough to get around origin restrictions).
"A2" is cleared on navigation per [3] (check out the automated tests in
Patch 7 in the bug), so if B2 was never set, loc.bar would be undefined.

As for loc.foo, our new implementation would give "B1", because the
Location object has entirely transplanted into the new Document's scope.
This seems sane to me, but it's certainly up for discussion. Matt, can you
add an expando on Object.prototype in your tests and see what happens?

Cheers,
bholley

From w3c at adambarth.com  Fri Nov  9 09:30:31 2012
From: w3c at adambarth.com (Adam Barth)
Date: Fri, 9 Nov 2012 09:30:31 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <509CA0E2.9050206@mit.edu>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
Message-ID: <CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>

On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 11/8/12 6:09 PM, Adam Barth wrote:
>> I don't think I quite understand what you mean, but the way this works
>> in WebKit is that each Window object has its own Location object.
>
> That's not how it works in Presto and Trident, as far as we can tell based
> on testing with "==".  In those, each WindowProxy has its own Location
> object.
>
>> The location object operates on the current Window for the WindowProxy.
>
> Yes.  _That_ all browsers are consistent on, and is totally not what the
> spec says right now.  In the spec, there is one Location per Window, and the
> object operates on the Window it's associated with.  The fact that this does
> not match any browsers is what makes us suspect the spec is not
> web-compatible.
>
>> In WebKit at least, it would be a security vulnerability to expose
>> JavaScript objects that belong to Document B to Document A because
>> that would give Document A access to the prototype objects for
>> Document B.
>
> You presumably have a solution for this situation for the WindowProxy case,
> right?  Certainly Gecko does, and we would be using the same solution for
> Location if we tie the lifetime of a Location to the lifetime of a
> WindowProxy.

The WindowProxy is a special, magical object because references to it
magically change which JavaScript object they refer to over time.  If
possible, I would like to avoid infecting other objects with its
magic.

Adam

From bobbyholley at gmail.com  Fri Nov  9 09:43:54 2012
From: bobbyholley at gmail.com (Bobby Holley)
Date: Fri, 9 Nov 2012 09:43:54 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
	<CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
Message-ID: <CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>

On Fri, Nov 9, 2012 at 9:30 AM, Adam Barth <w3c at adambarth.com> wrote:

> On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> > You presumably have a solution for this situation for the WindowProxy
> case,
> > right?  Certainly Gecko does, and we would be using the same solution for
> > Location if we tie the lifetime of a Location to the lifetime of a
> > WindowProxy.
>
> The WindowProxy is a special, magical object because references to it
> magically change which JavaScript object they refer to over time.  If
> possible, I would like to avoid infecting other objects with its
> magic.
>

That was my opinion for a while, too, but I eventually decided it was
necessary in Gecko. Right now, the Location object is the only object whose
security characteristics are not guaranteed to match its global, which is a
major pain point for us. I think the current spec language would be the
most ideal approach, but as noted I doubt it'll fly on the web.

FWIW, this turned out to be much simpler to implement than I thought. We've
already worked out where we need to put the logic to make WindowProxy
update appropriately, and we already had code to move objects like Location
between scopes (which we needed to do for document.write). I'd imagine
WebKit has the former, though I'm not sure about the latter.

bholley

From rescator at emsai.net  Fri Nov  9 11:01:06 2012
From: rescator at emsai.net (=?ISO-8859-1?Q?Roger_H=E5gensen?=)
Date: Fri, 09 Nov 2012 20:01:06 +0100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <Pine.LNX.4.64.1211072240490.5442@ps20323.dreamhostps.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
	<16214F02-DC2D-4C99-A463-37AB6B7EE512@gmail.com>
	<Pine.LNX.4.64.1211072240490.5442@ps20323.dreamhostps.com>
Message-ID: <509D52F2.3090101@emsai.net>

On 2012-11-07 23:41, Ian Hickson wrote:
> On Thu, 8 Nov 2012, Ben Schwarz wrote:
>> What does concern me, as a web builder, *every day*, is how I markup the
>> content in-between a <header> and a <footer>.
> If you just want it for styling purposes, <div> is perfect.
>
>> <article>
>> <header>h1, h2, p</header>
>> <div class="content"></div>
>> <footer>time, a.permalink</footer>
>> </article>
> Exactly like that (or even without the class, if you just have one per
> article you can just do "article > div" to select it).
>

I've begun to do this a lot now, the less I have to use class= or id= 
for styling the better.
In one of my current projects I'm basically only using id= for actual 
anchor/indedx use, and no class= at all.
In fact except the few id= for index shortcuts the stylingin is all done 
in the .css and the only css referencve in the html document is the 
inclusion of the css link url.
I guess you could call it "stealth css" as looking at the html document 
does not reveal that css is used at all (except the css link in the html 
header)
I wish more webauthors would do this, makes for very clean html indeed.
Now back to the topic (sorry for getting sidetracked).

As to the <main> thing, the only time I'd ever be for adding that to 
HTML markup was if it would be specced per the following.

<main> and </main> encloses the content of a document, can be used in 
place of a <div> or <article> but can only occur once in a document.
If more than one instance of <main> and </main> block is encounctered, 
then parsers should only accept the first and ignore any others.
If no <main> then the content in the document itself is considered the 
main content.

Maybe it's just me, but wouldn't a <main> sort of be a synonym for 
<body> almost? *scratches head*

-- 
Roger "Rescator" H?gensen.
Freelancer - http://www.EmSai.net/

From w3c at adambarth.com  Fri Nov  9 11:33:27 2012
From: w3c at adambarth.com (Adam Barth)
Date: Fri, 9 Nov 2012 11:33:27 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
	<CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
	<CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>
Message-ID: <CAJE5ia_GP_dMnDodfRv6uLOzik6TY05S5V+FcM+QMOpwMoYpcg@mail.gmail.com>

On Fri, Nov 9, 2012 at 9:43 AM, Bobby Holley <bobbyholley at gmail.com> wrote:
> On Fri, Nov 9, 2012 at 9:30 AM, Adam Barth <w3c at adambarth.com> wrote:
>> On Thu, Nov 8, 2012 at 10:21 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
>> > You presumably have a solution for this situation for the WindowProxy
>> > case,
>> > right?  Certainly Gecko does, and we would be using the same solution
>> > for
>> > Location if we tie the lifetime of a Location to the lifetime of a
>> > WindowProxy.
>>
>> The WindowProxy is a special, magical object because references to it
>> magically change which JavaScript object they refer to over time.  If
>> possible, I would like to avoid infecting other objects with its
>> magic.
>
> That was my opinion for a while, too, but I eventually decided it was
> necessary in Gecko.

Can you explain why you think it is necessary?  In WebKit, the
WindowProxy is the only object that has this magic.

> Right now, the Location object is the only object whose
> security characteristics are not guaranteed to match its global, which is a
> major pain point for us. I think the current spec language would be the most
> ideal approach, but as noted I doubt it'll fly on the web.
>
> FWIW, this turned out to be much simpler to implement than I thought. We've
> already worked out where we need to put the logic to make WindowProxy update
> appropriately, and we already had code to move objects like Location between
> scopes (which we needed to do for document.write). I'd imagine WebKit has
> the former, though I'm not sure about the latter.

We don't want to move objects between scopes.  That causes many
security complications that we don't want to deal with.

Can you answer the questions in my previous email?

Adam

From rescator at emsai.net  Fri Nov  9 11:36:30 2012
From: rescator at emsai.net (=?windows-1252?Q?Roger_H=E5gensen?=)
Date: Fri, 09 Nov 2012 20:36:30 +0100
Subject: [whatwg] A plea to Hixie to adopt <main>,
 and main element parsing behaviour
In-Reply-To: <CA+ri+VnD2+RJPmPocCBrrdxdWsxcY2-S1C6=EpwMGyHi-by=0g@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
	<Pine.LNX.4.64.1211071919250.5442@ps20323.dreamhostps.com>
	<CA+ri+VnD2+RJPmPocCBrrdxdWsxcY2-S1C6=EpwMGyHi-by=0g@mail.gmail.com>
Message-ID: <509D5B3E.7050004@emsai.net>

On 2012-11-08 10:51, Steve Faulkner wrote:
> What the relevant new data clearly indicates is that in approx 80% of cases
> when authors identify the main area of content it is the part of the
> content that does not include header, footer or navigation content.
>
>
> It also indicates that where skip links are present or role=main is used
> their position correlates highly with the use of id values designating the
> main content area of a page.
>

I'm wondering if maybe the following might satisfy both "camps" ?

Example1:
<!doctype html>
<html>
<head>
<title>test</title>
</head>
     <div>div before body</div>
     <body>body text</body>
     <div>div after body</div>
</html>

Example2:
<!doctype html>
<html>
<head>
<title>test</title>
</head>
     <header>header before body</header>
     <body>body text</body>
     <footer>footer after body</footer>
</html>

A html document ALWAYS has a body. So why not adjust the specs and free 
the placement of <body>,
thus allowing div and header and footer blocks before/after.
Curretly http://validator.w3.org/check gives warning, but that is easily 
fixed by allowing it.
The other issue is how will older browser handle this (backwards 
compatibility) and how much/little work is it to allow this in current 
browsers?

I'd rather see <body> unchained a little than having <main> added that 
would be almost the same thing.
And if you really need to layout/place something "inside" <body> then 
use a <article> or <div> instead of a <main>.

<body> already have a semantic meaning that's been around since way back 
when, so why not unchain it?
As long as <body> and </body> are within <html> and </html> it shouldn't 
matter if anything is before or after it.

Only issue that might be confusing would be
Example3:
<!doctype html>
<html>
<head>
<title>test</title>
</head>
     <header>header before body</header>
     <body>body text</body>
     <article>article outside body</article>
     <footer>footer after body</footer>
</html>

In my mind this does not make sense at all.
So maybe Example2 should be used to "unchain" <body> a little.

Example2:
<!doctype html>
<html>
<head>
<title>test</title>
</head>
     <header>header before body</header>
     <body>body text</body>
     <footer>footer after body</footer>
</html>

Example4:
<!doctype html>
<html>
<head>
<title>test</title>
</head>
     <body>
     <header>header before body</header>
     <div>body text</div>
     <footer>footer after body</footer>
    </body>
</html>

Example 4 is how I do it on some projects, while what I actually wish I 
could do is Example 2 above.
Maybe simply unchaining <body> enough to allow one <header> and one 
<footer> outside (but inside <html>) would be enough to satisfy people's 
need?
I wondered since the start why <header> and <footer> could not be 
outside <body>, it seems so logical after all!

-- 
Roger "Rescator" H?gensen.
Freelancer - http://www.EmSai.net/

From rescator at emsai.net  Fri Nov  9 12:04:00 2012
From: rescator at emsai.net (=?windows-1252?Q?Roger_H=E5gensen?=)
Date: Fri, 09 Nov 2012 21:04:00 +0100
Subject: [whatwg] header body footer
In-Reply-To: <509D5B3E.7050004@emsai.net>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
	<Pine.LNX.4.64.1211071919250.5442@ps20323.dreamhostps.com>
	<CA+ri+VnD2+RJPmPocCBrrdxdWsxcY2-S1C6=EpwMGyHi-by=0g@mail.gmail.com>
	<509D5B3E.7050004@emsai.net>
Message-ID: <509D61B0.9010605@emsai.net>

Starting a new subject on this to keep the email threads more clear:

Suggestion is that the following should be possible,
this would allow <body> to act as if it was a <main>.

<!doctype html>
<html>
<head>
<title>header and footer outside body</title>
<style>
body {border:1em solid #7f2424;}
header {border:1em solid #247f24;}
footer {border:1em solid #24247f;}
</style>
</head> 
<header>
This is the header of the document!
</header>
<body>
This is the main content of the document!
</body>
<footer>
This is the footer of the document!
</footer>
</html>

As can be seen in most modern browsers. Semantically the content appear 
correctly.
The only issue is the css styling of <body> as <body> is treated as the 
parent of <header> and <footer>.
I'm not sure how much work or not it would be to allow 1 
<header></header> and 1 <footer></footer> outside <body> and let those 
have <html> as their parent instead,
but if it's not too much work then this could "fix" the lack of a 
<main>, and it would avoid the need of using a extra <div> or similar 
inside <body> just for styling.

Any other pros (or cons)?

-- 
Roger "Rescator" H?gensen.
Freelancer - http://www.EmSai.net/

From bobbyholley at gmail.com  Fri Nov  9 12:06:55 2012
From: bobbyholley at gmail.com (Bobby Holley)
Date: Fri, 9 Nov 2012 12:06:55 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAJE5ia_GP_dMnDodfRv6uLOzik6TY05S5V+FcM+QMOpwMoYpcg@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
	<CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
	<CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>
	<CAJE5ia_GP_dMnDodfRv6uLOzik6TY05S5V+FcM+QMOpwMoYpcg@mail.gmail.com>
Message-ID: <CAKBxTc+AmYLr2VB4g+VFB2qF8hUcZ1ujTSbHjwj-wsKaAqdbtw@mail.gmail.com>

On Fri, Nov 9, 2012 at 11:33 AM, Adam Barth <w3c at adambarth.com> wrote:

> > That was my opinion for a while, too, but I eventually decided it was
> > necessary in Gecko.
>
> Can you explain why you think it is necessary?  In WebKit, the
> WindowProxy is the only object that has this magic.
>

As noted, the Location object is the only object whose security
characteristics don't match its scope. This requires a lot of extra goop in
our compartment-based security model, and the goop is brittle (recently
forcing us to release two out-of-band updates, 16.0.1 and 16.0.2). We've
got enough belt-and-suspenders code now that I'm not particularly worried,
but I still want to make Location just like any other object from a
security perspective.

If UAs were consistent or the spec matched reality, this would be a
different story. But given that we probably need to change the spec to
either the Trident/Presto model or the Gecko/WebKit model, I support the
former, because we've historically had problems implementing the latter
securely. Do you feel that it would be difficult to implement the former
securely in WebKit?

Also, FWIW, from the perspective of an average web-developer, IMO it makes
much more semantic sense to have one Location per WindowProxy if the
Location object describes the WindowProxy. But I doubt many people touch
this stuff in practice.

We don't want to move objects between scopes.  That causes many
> security complications that we don't want to deal with.
>

Are you able to just update references, like you do with WindowProxy?
That's essentially what we're doing. We actually create a new object in the
new scope and update all the old references to point to it.

> Can you answer the questions in my previous email?
>

Which ones? AFAICT Boris answered all of them except for the testcase thing
(which I answered). Did I miss some?

Cheers,
bholley

From w3c at adambarth.com  Fri Nov  9 12:17:59 2012
From: w3c at adambarth.com (Adam Barth)
Date: Fri, 9 Nov 2012 12:17:59 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAKBxTc+AmYLr2VB4g+VFB2qF8hUcZ1ujTSbHjwj-wsKaAqdbtw@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
	<CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
	<CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>
	<CAJE5ia_GP_dMnDodfRv6uLOzik6TY05S5V+FcM+QMOpwMoYpcg@mail.gmail.com>
	<CAKBxTc+AmYLr2VB4g+VFB2qF8hUcZ1ujTSbHjwj-wsKaAqdbtw@mail.gmail.com>
Message-ID: <CAJE5ia8p7gLuYwj9BjaDGNWgZecw=ymYGVmsf9akhLJaZAOONA@mail.gmail.com>

On Fri, Nov 9, 2012 at 12:06 PM, Bobby Holley <bobbyholley at gmail.com> wrote:
> On Fri, Nov 9, 2012 at 11:33 AM, Adam Barth <w3c at adambarth.com> wrote:
>> > That was my opinion for a while, too, but I eventually decided it was
>> > necessary in Gecko.
>>
>> Can you explain why you think it is necessary?  In WebKit, the
>> WindowProxy is the only object that has this magic.
>
> As noted, the Location object is the only object whose security
> characteristics don't match its scope. This requires a lot of extra goop in
> our compartment-based security model, and the goop is brittle (recently
> forcing us to release two out-of-band updates, 16.0.1 and 16.0.2). We've got
> enough belt-and-suspenders code now that I'm not particularly worried, but I
> still want to make Location just like any other object from a security
> perspective.
>
> If UAs were consistent or the spec matched reality, this would be a
> different story. But given that we probably need to change the spec to
> either the Trident/Presto model or the Gecko/WebKit model, I support the
> former, because we've historically had problems implementing the latter
> securely. Do you feel that it would be difficult to implement the former
> securely in WebKit?

That depends on the questions I asked earlier.

> Also, FWIW, from the perspective of an average web-developer, IMO it makes
> much more semantic sense to have one Location per WindowProxy if the
> Location object describes the WindowProxy. But I doubt many people touch
> this stuff in practice.

I don't think the average web developer will hit this case because it
depends on interacting with the Location object in an inactive
document.

>> We don't want to move objects between scopes.  That causes many
>> security complications that we don't want to deal with.
>
> Are you able to just update references, like you do with WindowProxy?

That's the magic I don't want to proliferate.

> That's
> essentially what we're doing. We actually create a new object in the new
> scope and update all the old references to point to it.
>
>> Can you answer the questions in my previous email?
>
> Which ones? AFAICT Boris answered all of them except for the testcase thing
> (which I answered). Did I miss some?

Maybe I didn't receive your email.  I gave some example code and asked
which values were printed:

---8<---
Consider the following case:

== Document A ==
<script>
Object.prototype.foo = "A1";
window.location.bar = "A2";

function f() {
  var loc = window.location;
  print(loc.foo); // print is a magic function that lets me see this value
  print(loc.bar);
}
</script>

== Document B ==
<script>
Object.prototype.foo = "B1";
window.location.bar = "B2";
</script>

1) Document A is displayed in browsing context X.
2) Browsing context X is navigated and now displays document B.
3) Function f is called.

What values are printed?
--->8---

Adam

From bobbyholley at gmail.com  Fri Nov  9 12:26:14 2012
From: bobbyholley at gmail.com (Bobby Holley)
Date: Fri, 9 Nov 2012 12:26:14 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAJE5ia8p7gLuYwj9BjaDGNWgZecw=ymYGVmsf9akhLJaZAOONA@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
	<CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
	<CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>
	<CAJE5ia_GP_dMnDodfRv6uLOzik6TY05S5V+FcM+QMOpwMoYpcg@mail.gmail.com>
	<CAKBxTc+AmYLr2VB4g+VFB2qF8hUcZ1ujTSbHjwj-wsKaAqdbtw@mail.gmail.com>
	<CAJE5ia8p7gLuYwj9BjaDGNWgZecw=ymYGVmsf9akhLJaZAOONA@mail.gmail.com>
Message-ID: <CAKBxTcJMRAxLuMBWbUVbhEpghDu5aQkBM1tMK9BbOZbbQC35aQ@mail.gmail.com>

On Fri, Nov 9, 2012 at 12:17 PM, Adam Barth <w3c at adambarth.com> wrote:

> I don't think the average web developer will hit this case because it
> depends on interacting with the Location object in an inactive
> document.
>

Agreed.

> Maybe I didn't receive your email.

Here's a link to it in the archives:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037850.html

From w3c at adambarth.com  Fri Nov  9 14:05:04 2012
From: w3c at adambarth.com (Adam Barth)
Date: Fri, 9 Nov 2012 14:05:04 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAKBxTcJMRAxLuMBWbUVbhEpghDu5aQkBM1tMK9BbOZbbQC35aQ@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
	<CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
	<CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>
	<CAJE5ia_GP_dMnDodfRv6uLOzik6TY05S5V+FcM+QMOpwMoYpcg@mail.gmail.com>
	<CAKBxTc+AmYLr2VB4g+VFB2qF8hUcZ1ujTSbHjwj-wsKaAqdbtw@mail.gmail.com>
	<CAJE5ia8p7gLuYwj9BjaDGNWgZecw=ymYGVmsf9akhLJaZAOONA@mail.gmail.com>
	<CAKBxTcJMRAxLuMBWbUVbhEpghDu5aQkBM1tMK9BbOZbbQC35aQ@mail.gmail.com>
Message-ID: <CAJE5ia8ec1=XsS_x-KF17A2O5j0pwYdE3y-fDpYrZrR5fvfReg@mail.gmail.com>

On Fri, Nov 9, 2012 at 12:26 PM, Bobby Holley <bobbyholley at gmail.com> wrote:
> On Fri, Nov 9, 2012 at 12:17 PM, Adam Barth <w3c at adambarth.com> wrote:
>> I don't think the average web developer will hit this case because it
>> depends on interacting with the Location object in an inactive
>> document.
>
> Agreed.
>
>> Maybe I didn't receive your email.
>
> Here's a link to it in the archives:
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2012-November/037850.html

Thanks for the link.  Somehow the message got routed to spam.

It's possible we could implement that in WebKit, but the
implementation would be very delicate.  We currently implement similar
security checks for Location because Location is visible across
origins.  The main difficulty would be implementing the
WindowProxy-like re-writing of existing references.  I understand that
implementing that behavior in Gecko is much easier than in WebKit
because Gecko makes extensive use of JavaScript wrapper objects.  We
have avoided introducing similar wrapper objects in WebKit because
they're quite subtle and can lead to security vulnerabilities if used
incorrectly.

I don't fully understand why the current behavior is fragile in Gecko.
 The approach we use in WebKit is quite simple---we just perform an
access check before doing any sensitive operations.  This access check
is required in any case because the underlying Location object is
visible across origins.  I guess the issue must be that Gecko performs
the access check based on some property of the JavaScript object.  In
WebKit, we simply perform the access check based on the operation
we're actually about to perform, irrespective of what API was used to
trigger the action.

Adam

From bzbarsky at MIT.EDU  Fri Nov  9 18:39:47 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 09 Nov 2012 18:39:47 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAJE5ia8ec1=XsS_x-KF17A2O5j0pwYdE3y-fDpYrZrR5fvfReg@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
	<CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
	<CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>
	<CAJE5ia_GP_dMnDodfRv6uLOzik6TY05S5V+FcM+QMOpwMoYpcg@mail.gmail.com>
	<CAKBxTc+AmYLr2VB4g+VFB2qF8hUcZ1ujTSbHjwj-wsKaAqdbtw@mail.gmail.com>
	<CAJE5ia8p7gLuYwj9BjaDGNWgZecw=ymYGVmsf9akhLJaZAOONA@mail.gmail.com>
	<CAKBxTcJMRAxLuMBWbUVbhEpghDu5aQkBM1tMK9BbOZbbQC35aQ@mail.gmail.com>
	<CAJE5ia8ec1=XsS_x-KF17A2O5j0pwYdE3y-fDpYrZrR5fvfReg@mail.gmail.com>
Message-ID: <509DBE73.7070109@mit.edu>

On 11/9/12 2:05 PM, Adam Barth wrote:
>   The approach we use in WebKit is quite simple---we just perform an
> access check before doing any sensitive operations.

The issue in Gecko, as I understand, is that security checks from C++ 
code require introspecting running JS to figure out what the right actor 
("subject") origin for the security check is.  This is somewhat fragile 
because it's easy to accidentally interpose other things that look like 
running JS between the caller and callee in many cases.  Note that this 
problem would be even worse for a self-hosted (implemented in JS) 
implementation of something like Location...

The upshot is that instead we aim to do security checks at points where 
control crosses from one origin to another, and use proxies to enforce 
the security invariants involved.

Bobby knows more about this than I do, so I'll let him correct any 
inaccuracies.

> This access check is required in any case because the underlying Location object is
> visible across origins.

In Gecko, it's actually not.  A proxy is visible.

One thing I'd like is some comment from Opera and Microsoft about what 
their situation is, since implementing what WebKit does would mean both 
of those changing.  This is probably the wrong venue to get hold of 
Microsoft for an official statement, sadly.  :(

-Boris

From duboisp2 at gmail.com  Fri Nov  9 20:00:52 2012
From: duboisp2 at gmail.com (Pierre Dubois)
Date: Fri, 9 Nov 2012 23:00:52 -0500
Subject: [whatwg] Sortable Tables
In-Reply-To: <Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
References: <F9859A39-E9E5-43AC-BFBA-0786EDC128BC@crissov.de>
	<Pine.LNX.4.64.1211061922450.2478@ps20323.dreamhostps.com>
Message-ID: <CAPGwD7iWT4Z_Ea14W0zapA69B-HaG_ZixwkF3jkg0=w3Jw0NyQ@mail.gmail.com>

On Tue Nov 6 11:25:21 PST 2012, Ian Hickson wrote:
>
> [snip]
> This is a very interesting idea.
>
> Is this something browser vendors would be interested in implementing? I'm
> hesitant to add a feature for this (which could be somewhat involved)
> before having the definite interest of some browser implementors.

I am not representating a browser vendors either a browser developper
but I will be welcome to create a javascript polyfill
for the sortable table as defined by the WHATWG spec on the current
browser supported by the WxT Toolbox.

On Tue Nov 6 11:39:35 PST 2012, Ojan Vafai wrote:
>
> [snip]
> A couple thoughts off the top of my head:
> 1. Would sorting actually reorder the DOM nodes or just change their visual
> order? It's not clear to me which one is better. I think the former is what
> you'd want most of the time.

>From my point of view, the DOM and the associated API should reflect
the re-order. That would allow to draw chart on the fly based on user
order preference.

> 2. What values should the sort property allow. One idea is that it takes a
> JS function similar to what JavaScript's sort function takes. If you leave
> it out then it just does alphanumeric sort.

I agree to takes JS function "callback" similar to what JavaScript's
sort function takes. The callback function can receive the DOM cell
element as parameter.
Instead of alphanumeric order by default, it would more relevant to
have numeric sort then alpha sort. That sort can be base on the first
word in the
cell then if required goes to next words to complete the comparaison.

> 3. What elements does it go on? I don't see what it would do on a td. I
> could see putting it on a th though.

Me also, I do not see the value added to apply sort on a td element.
Applying sort on th seem an interoperable solution with data table
that use the proper markup and are accessible.

> Also, it's not clear to me what would
> get sorted. For example, in some tables, you would group trs inside tbodys
> and want to sort those.

My opinion is that depends of the real scope of the "th" element.

If the "th" is an empty cell or used for "layout", the sorting
functionality would not be available.
If the "th" is an "group header", the sorting functionality would be
applied to the header cell along with their data fixed. Where the
header cell is a
subgroup header or/and an header that represent one or more row or column.
If the "th" is an "header", the sorting functionality could be applied
to the data cell associated and by default the sorting action would be
extended to the other axis [row|col].

I think it is very important to always keep the data relationships
with their associated cell headers. This could be required, in the
accessibility manner,
for a screen reader.

I think the vector (col|tr) get sorted in their respective group where
the sort is occuring. No group (tbody & colgroup) re-ordering should
happen during a
sorting applied on a cell header related to a vector (tr|col). A group
can get ordered only when the sorting action is applied to the group
header cell that
represent those group.

As the concept was already defined in a proposal I made
(http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-October/037679.html).
I would recommand that
the sort would not occur in vector (col|tr) into a summary group. But
the summary group would always follow their associated data group
during the grouping sorting.

Also currently there is no spec and/or official best practice on how
to get the full potential of the column grouping and the row grouping.
Before to enable any kind of official table sorting, the specification
should be able to handle properly the complex table relationships,
in an accessibility matter, without having the needs to take in
consideration the "scope" attribute and the "headers" attribute.
See the proposal to remove the headers and scope attribute:
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037475.html

On Tue Nov 6 11:55:06 PST 2012, Boris Zbarsky wrote:
>
> [snip]
> Another obvious question: how does (or should) sorting interact with
> rowspans?

May be the data cells that are rowspans and/or colspans could force
the column and/or row related to it to be fixed.
That would not break the cell relationships but could make the table
imposible to be sorted. Also when a sorting would affect
a rowspans/colspans cell, may be only the first cell value in the
sorting order can be considerated, the others cell would be ignored.

Use case: A data table that have row headers and column headers.
Row and column that is in the scope of an rowspans and colspans data
cell (td) would be fixed.

Use case: A data table that only have row headers.
Row that is in the scope of an rowspans data cell (td) would be fixed.

Use case: A data table that only have column headers.
Column that is in the scope of a colspans data cell (td) would be fixed.

On Tue Nov 6 16:17:09 PST 2012, Christoph P?per wrote:
>
> [snip]
> >> Note that ?col? and ?colgroup? elements are hardly supported.
> But they?re essential for assigning sort properties.
>
>   <col key=?>
>   <colgroup key=?>
>
> A ?col? inherits the ?key? from a parent ?colgroup?, but may override it.

I like the concept but that concept needs to be replicated to 'tbody',
'tr'. The same would be applicable to the group header cell defined
by the 'th' element.

> [snip]
> The default ?key? is ?auto? for explicit columns and ?none? for implicit columns.

I think the default 'key' should be also applied on implicit columns.

> [snip]
> >> Therefore columns should bear (?) what kind of content their cells have.
>
> Authors will mess this up of course, but then it?s their fault. Let?s not overload ?title? or ?abbr?.

By default, the sorting can be based on the inner text that the cell
have without considering any CSS effect and other Content Flow
elements.
eg.
<table sortable>
<tr><th>Column
<tr><td><a href="#">DDD</a>
<tr><td><span style="display:none">AAA</span> HHH
<tr><td><table><tr><td>BBB</table>
</table>
Could result like the following after ascending sorting applied to the
cell header "Column"
<table sortable>
<tr><th>Column
<tr><td><span style="display:none">AAA</span> HHH
<tr><td><table><tr><td>BBB</table>
<tr><td><a href="#">DDD</a>
</table>

If the data cell 'td' has a specialized structured content then the
callback function would be useful to do the sorting.

> >> Several columns may be used for sorting by some kind of priority.
>
> This is a UI question, though.

Is there a use case for that ? If so, I think that should be
explicitly specified in the same place as the proposed 'key'
attribute.

> [snip]
> >> Cell content may not consist of the string that should be used verbatim (?).
> >> Cells should have an optional attribute indicating their sort key.
>
>   <th value="Rolling Stones, The">The Rolling Stones
>   <td value="0.454">1 lb

I do not catch the value-add to have a 'value' attribute on th/td
element. That would just create duplication of the information already
contained in the cell. The use of an callback function can be a good
alternative to that issue. I do not see overloading the HTML code
as a best practice.

> [snip]
> To support this, cells must be splittable!
>
>   td {color: green;}
>   #split {color: red;}
>
>   <tr><td>3 <td id=split colspan=2> red
>   <tr><td>1
>   <tr><td>2 <td> green
>
> after sorting by the first column should look like
>
>   <tr><td>1 <td id=split> red
>   <tr><td>2 <td> green
>   <tr><td>3 <td id=split> red
>
> would if duplicate IDs were legal. The DOM tree, however, would not change! The value of the cell at position (1,1), i.e. second row and column since we count from zero, is always undefined, but the value of the slot at (1,1) changes from ?red? to ?green?.

That would break the tabular data integrety and the cells (data cell
and header cell) can loose their relationships.

> Once we have splittable cells, one could imagine additions to the CSS table model and Selectors that allowed arbitrary partial repositioning of slots, think 15-puzzle. Let?s not go there yet, and not here.

I do not have actual numbers, but my common sense and my experience
told me that the probability of an authors to create a puzzle from a
data table is
very very very LOW instead of having an author that would create a
complex table.

> User agents should not be required to sort tables that contain malformed slots,

I would say: User agents should not be required to sort tables that
contain malformed tabulars cells where the table width is inconsistant
between rows
and the height is inconsistant between columns.

A data table like this would be ignored because the second row are
missing a data cell in the second column

<table>
<tr><th>Column 1 <th>Column 2
<tr><td>Data 1
<tr><td>Data 1 <td>Data 2
</table>

> There may be rows that should always go to the top or the bottom of their group. This should be handled by table headers and footers in most cases, otherwise it is not covered yet.

As you see my proposal
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037475.html
and the associated working example available from here:
http://wet-boew.github.com/wet-boew/demos/tableparser/index-eng.html

On Wed Nov 7 01:54:19 PST 2012, Jirka Kosek wrote:
>
> [snip]
> It would be very difficult to support sorting on dates and numbers as in
> HTML they are usually present formatted using specific locale. So there
> should be additional attribute added to td/th which can hold sort key
> which will override cell contents, something like
>
> <td sortas="2012-11-07">11. listopadu 2012</td>

Not if is possible to use a callback function to sort the cells.

On Wed Nov 7 02:34:54 PST 2012, Stuart Langridge wrote:

>
> [snip]
> Therefore, it attempts to guess the type of a
> table column: if a column looks like it contains numbers, sorttable will
> use numeric sort (1 before 2 before 100) rather than alphanumeric sort (1
> before 100 before 2); if a column looks like it contains date information,
> then sorttable will sort by date (for formats DD/MM/YYYY and MM/DD/YYYY).
> The algorithm used for this guessing is pretty naive (check the first cell
> in a column; if it's blank, check the next one; etc). I think that this, by
> itself, has accounted for sorttable's popularity, because in most cases, it
> Just Works; you add a <script> element pointing to the script, and
> class="sortable" to the <table>, and do *nothing else*, and your table is
> sortable without any configuration.
>
> Everything else below here is configuration-based: something you'd have to
> do explicitly as an author. The above point is the critical one; guessing
> column types to make table sorting be zero-config. Some alternative scripts
> require you to explicitly tag date or numeric columns, and I think that
> authors see that as annoying. Anecdata, of course.
>
> Sorttable also allows authors to specify "alternate content" for a cell.
> That is (ignore the invalid HTML attribute here; I didn't know any better,
> and we didn't have data-* attributes when I wrote this stuff)
>
> <td sorttable_customkey="11">eleven</td>
>
> This is basically useful for when you have table data which has a definite
> order but it can't be autoguessed, or (more usefully still) when it could
> be autoguessed but that would be hard. The canonical example of this is
> dates: it would be exceedingly annoying, given
> <td>Wed 7th November, 10.00am GMT</td>
> to have to parse that cell content in JavaScript to turn it back into a
> Date() so it can be placed in sort order with other dates. The sorttable.js
> solution is to specify a "custom key", which sorttable pretends was the
> cell content for the purposes of sorting, so
> <td sorttable_customkey="20121107-100000">Wed 7th November, 10.00am GMT</td>
> and then the script can sort it. This feature is basically the get-out
> clause, an author hook for saying "I know what I want, but your fancy
> sorting thing can't handle it; how do I override that?" They can specify
> custom keys for all their TDs and then sorting will work fine. (Obviously,
> dates are less of a problem in theory today with <date> elements, but...
> how does the script know to use the datetime attribute of the <date> in
> <td><date>...</date></td>?)

That seems a good use case to add a javascript callback to sort
complex data cell.

> [snip]
> 3. Multiple header rows. Many authors have two or more <tr>s in the
> <thead>, one of which contains rowspanned <th>s, to group columns together.
> If this happens, which <th>s are clickable to sort the table? Which are
> not? This is hard to autodiagnose (and indeed sorttable punts on it and
> picks the first one, which is almost certainly wrong; even naively picking
> the last <tr> inside <thead> would be better, but still imperfect).

That is one thing the Table Usability Algorithm resolve.

> 4. Handling colspans and rowspans in the table. Sorttable.js basically
> punts on this, because what's expected to happen when you sort a column
> which contains only half a cell (because the other half's in another
> column, with rowspan=2) is wildly author-specific. But a properly specced
> solution doesn't get to punt and say "unsupported". This will need some
> thought.

As already proposed before, the data cell that have colspans and
rowspans would fix, freeze, the row and column that is related to it.
That would ensure to keep
the integrity of the tabular data. So a table can have a cell colspans
and rowspans and still sortable.

> 5. Numeric sort handling exponented numbers such as 1.5e6 (which do not
> match a naive "is this a number" regexp such as /^[0-9]+$/ )

Another use case to add a javascript callback.

> 6. Specifying how to display that a column is sorted. This would likely be
> done in this specification by leaving it to CSS and th::sorted-forward {
> after: content("v"); } or some such thing (I have no policy suggestions
> here), but authors want to be able to specify this, along with different
> styles for a sorted column. This is mildly more awkward because there's no
> real concept of a column in the DOM of an HTML table, but perhaps all the
> TDs could grow a pseudo ::sorted-forward or something (handwaving here like
> mad, obviously).

May instead of styling the data cell 'td' it would more relevant to
style the cell header 'th' where the last action of sorting happened.
Knowing where the last
sort happened can be an useful information to be provided to users
that use a screen reader.

> 7. Case sensitivity in alphannumeric sorting. Some people like it, some
> people don't; it's good to have some sort of author-controllable switch.
> (Obviously solveable with <td
> sorttable_customkey="INSENSITIVE">Insensitive</td> in the limit case, and
> this, like many other things on this list, suggests that some sort of "here
> is the JavaScript function I want you to use to produce sort keys for table
> cells in this column" function is a useful idea. Sorttable allows this, and
> people use it a lot.)

What is more usable, having default sort by being no case sensitivity
or with case sensitivity ? If the authors do not want the default case
sensitivity sort
he can use a javascript callback.

> [snip]
> but there's no <ol> concept for <tr>s).

'ol' is an ordered list. 'ul' is an unordered list. Because this
discussion is about to add the sortable functionality to table, 'tr'
and 'col' needs to be
considerated unordered.

> 9. A commonly requested type of things to know how to automatically sort is
> IP addresses. (I solve this by forwarding people the email explaining how
> to add a new sort type function to sorttable, because I've never got around
> to adding it to the script.)

Another use case to add a javascript callback.

> [snip]
> 13. What happens if a table has multiple <tbody> elements? Do they sort as
> independent units, or mingle together? Sorttable just sorts the first one
> and ignores the rest, because multiple tbodies are uncommon, but that's not
> really acceptable ;-)

The spec should take in consideration the grouping relationships as
proposed here: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-September/037475.html

> 14. Fixed-position rows. Many authors have a "totals" row at the bottom of
> their table which should remain at the bottom of the table even after
> sorting, which is easily handled (that's what <tfoot> is for), but some
> authors also have rows midway through the table which are "headers": this
> especially shows up in long tables, where the column headers from <thead>
> are repeated midway down the table and should remain in position even when
> the table is sorted. In general this means that they should remain the same
> number of rows away from <thead>. This case is odd, and sorttable.js
> doesn't handle it, but lots of people ask for it.

For me having midway "headers" used for columns could be an
accessibility/usability issue. Instead I see more relevant to have an
another option set on
the 'table' element to enable the posibility to keep the relevant
cells heading (columns and row group cell headers) in the available
view port.

On Thu Nov 8 08:09:17 PST 2012, Christoph P?per wrote:
>
> [snip]
> The sorting algorithm should not work on cells, but on slots (or slot values rather).
>
> Cells spanning multiple rows or columns may have to be split into one cell per slot and should be rejoined afterwards if possible. Note that ?rowspan? itself is safe for vertical sorting, unless it spans a ?fixed? column. Also, ?colspan? is safe when it appears in the column to be sorted by.

It is important that cells would always keep their relationships
during the sort. So even the cell is split in slots during the sort,
those slots needs
to be rejoined as it was before the sort. That is to keep the
integrity of the tabular data.

Cheers

:-)

Pierre Dubois

From mat at matcarey.co.uk  Sat Nov 10 01:04:09 2012
From: mat at matcarey.co.uk (Mat Carey)
Date: Sat, 10 Nov 2012 09:04:09 +0000
Subject: [whatwg] header body footer
In-Reply-To: <509D61B0.9010605@emsai.net>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
	<Pine.LNX.4.64.1211071919250.5442@ps20323.dreamhostps.com>
	<CA+ri+VnD2+RJPmPocCBrrdxdWsxcY2-S1C6=EpwMGyHi-by=0g@mail.gmail.com>
	<509D5B3E.7050004@emsai.net> <509D61B0.9010605@emsai.net>
Message-ID: <547DA23B-1E61-4A08-9E6A-8C22B4FBA39F@matcarey.co.uk>

Unfortunately that's not in-keeping with the backwards compatible nature of HTML5, if we were to specify that as the parsing approach from now on it would cause a major inconvenience to anyone actually trying to use that feature when some browsers have picked it up and others haven't.

> The only issue is the css styling of <body> as <body> is treated as the parent of <header> and <footer>.

This is by design.  A body element will wrap the body in the DOM even if there's no body tag in the markup, AFAIK this is partially to document the existing behaviour of not-so-modern browsers (which, of course, we have no influence over); just have a look at how the DOM is structured in the modern browser of your choice - in my case Chrome:

<html><head>
<title>header and footer outside body</title>
<style>
body {border:1em solid #7f2424;}
header {border:1em solid #247f24;}
footer {border:1em solid #24247f;}
</style>
</head> 
<body><header>
This is the header of the document!
</header>

This is the main content of the document!

<footer>
This is the footer of the document!
</footer>

</body></html>

This feature would be a U-Turn in HTML5 and I can't see any browser vendors going for implementing it at risk of 'breaking the web' ? and I agree that there is a major risk of that.

Mat Carey

Web Developer & Consultant 
mat at matcarey.co.uk
www.matcarey.co.uk

On 9 Nov 2012, at 20:04, Roger H?gensen <rescator at emsai.net> wrote:

> Starting a new subject on this to keep the email threads more clear:
> 
> Suggestion is that the following should be possible,
> this would allow <body> to act as if it was a <main>.
> 
> <!doctype html>
> <html>
> <head>
> <title>header and footer outside body</title>
> <style>
> body {border:1em solid #7f2424;}
> header {border:1em solid #247f24;}
> footer {border:1em solid #24247f;}
> </style>
> </head> 
> <header>
> This is the header of the document!
> </header>
> <body>
> This is the main content of the document!
> </body>
> <footer>
> This is the footer of the document!
> </footer>
> </html>
> 
> 
> As can be seen in most modern browsers. Semantically the content appear correctly.
> The only issue is the css styling of <body> as <body> is treated as the parent of <header> and <footer>.
> I'm not sure how much work or not it would be to allow 1 <header></header> and 1 <footer></footer> outside <body> and let those have <html> as their parent instead,
> but if it's not too much work then this could "fix" the lack of a <main>, and it would avoid the need of using a extra <div> or similar inside <body> just for styling.
> 
> Any other pros (or cons)?
> 
> 
> -- 
> Roger "Rescator" H?gensen.
> Freelancer - http://www.EmSai.net/
>

From mat at matcarey.co.uk  Sat Nov 10 01:26:13 2012
From: mat at matcarey.co.uk (Mat Carey)
Date: Sat, 10 Nov 2012 09:26:13 +0000
Subject: [whatwg] A plea to Hixie to adopt <main>,
	and main element parsing behaviour
In-Reply-To: <509D5B3E.7050004@emsai.net>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<509A9F01.1050905@opera.com> <509AA4E6.4060505@oupeng.com>
	<Pine.LNX.4.64.1211071919250.5442@ps20323.dreamhostps.com>
	<CA+ri+VnD2+RJPmPocCBrrdxdWsxcY2-S1C6=EpwMGyHi-by=0g@mail.gmail.com>
	<509D5B3E.7050004@emsai.net>
Message-ID: <9A2A4D65-B54F-4EDA-AACA-794F28535043@matcarey.co.uk>

Roger has put his recommendation on a new post (header body footer), I have put my response on there.  I don't see this particular suggestion as viable, for details please see the other post.

Personally I would love to have a <main> element because I think there is a really useful purpose; I find it much richer to use <article><header/><main/><footer/></article> than <article><header/><div/><footer/></article> but I have no specific use-cases which are not currently supported just a general feeling that we've documented a number of common idioms and this seems to be one that's missing.

Mat Carey

Web Developer & Consultant 
mat at matcarey.co.uk
www.matcarey.co.uk

On 9 Nov 2012, at 19:36, Roger H?gensen <rescator at emsai.net> wrote:

> On 2012-11-08 10:51, Steve Faulkner wrote:
>> What the relevant new data clearly indicates is that in approx 80% of cases
>> when authors identify the main area of content it is the part of the
>> content that does not include header, footer or navigation content.
>> 
>> 
>> It also indicates that where skip links are present or role=main is used
>> their position correlates highly with the use of id values designating the
>> main content area of a page.
>> 
> 
> I'm wondering if maybe the following might satisfy both "camps" ?
> 
> Example1:
> <!doctype html>
> <html>
> <head>
> <title>test</title>
> </head>
>    <div>div before body</div>
>    <body>body text</body>
>    <div>div after body</div>
> </html>
> 
> Example2:
> <!doctype html>
> <html>
> <head>
> <title>test</title>
> </head>
>    <header>header before body</header>
>    <body>body text</body>
>    <footer>footer after body</footer>
> </html>
> 
> 
> A html document ALWAYS has a body. So why not adjust the specs and free the placement of <body>,
> thus allowing div and header and footer blocks before/after.
> Curretly http://validator.w3.org/check gives warning, but that is easily fixed by allowing it.
> The other issue is how will older browser handle this (backwards compatibility) and how much/little work is it to allow this in current browsers?
> 
> I'd rather see <body> unchained a little than having <main> added that would be almost the same thing.
> And if you really need to layout/place something "inside" <body> then use a <article> or <div> instead of a <main>.
> 
> <body> already have a semantic meaning that's been around since way back when, so why not unchain it?
> As long as <body> and </body> are within <html> and </html> it shouldn't matter if anything is before or after it.
> 
> Only issue that might be confusing would be
> Example3:
> <!doctype html>
> <html>
> <head>
> <title>test</title>
> </head>
>    <header>header before body</header>
>    <body>body text</body>
>    <article>article outside body</article>
>    <footer>footer after body</footer>
> </html>
> 
> In my mind this does not make sense at all.
> So maybe Example2 should be used to "unchain" <body> a little.
> 
> Example2:
> <!doctype html>
> <html>
> <head>
> <title>test</title>
> </head>
>    <header>header before body</header>
>    <body>body text</body>
>    <footer>footer after body</footer>
> </html>
> 
> Example4:
> <!doctype html>
> <html>
> <head>
> <title>test</title>
> </head>
>    <body>
>    <header>header before body</header>
>    <div>body text</div>
>    <footer>footer after body</footer>
>   </body>
> </html>
> 
> Example 4 is how I do it on some projects, while what I actually wish I could do is Example 2 above.
> Maybe simply unchaining <body> enough to allow one <header> and one <footer> outside (but inside <html>) would be enough to satisfy people's need?
> I wondered since the start why <header> and <footer> could not be outside <body>, it seems so logical after all!
> 
> -- 
> Roger "Rescator" H?gensen.
> Freelancer - http://www.EmSai.net/
>

From mjs at apple.com  Sat Nov 10 21:17:32 2012
From: mjs at apple.com (Maciej Stachowiak)
Date: Sat, 10 Nov 2012 21:17:32 -0800
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
Message-ID: <72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>

On Nov 7, 2012, at 8:52 AM, Ojan Vafai <ojan at chromium.org> wrote:

> On Wed, Nov 7, 2012 at 6:23 AM, Simon Pieters <simonp at opera.com> wrote:
> 
>> My impression from TPAC is that implementors are on board with the idea of
>> adding <main> to HTML, and we're left with Hixie objecting to it.
>> 
> 
> For those of use who couldn't make it, which browser vendors voiced
> support? I assume Opera since you're writing this thread.

I personally think <main> would be useful. I don't think it has a huge benefit, but it has modest benefits, like <aside>, <header>, <footer> and <section>. I also think the implementation costs are low. The reasons I think it has some benefits:

- Even though heuristics (such as the scooby-doo algorithm or even guesses based on role or class, or the layout) will always be necessary in some cases, it's still good to have a simple and relatively trustworthy marker of the main content. This is useful both for accessibility purposes and for other browser features that want to find the main content. In many cases, we have found that even when semantics can be heuristically inferred, having an explicit marker is still useful. For example, you can usually guess that some text is an address, but we still have a microformat that helps identify such data unambiguously.

- From a language design perspective, it seems inelegant to identify the main content solely by what it is not. I realize that this is a matter of taste and that tastes may differ. By analogy, in imperative programming languages that have a main function, it is generally marked with as specific name rather than just by not being any of the non-main functions. This is not perfectly analogous, but it still seems motivating to me.

- The "Scooby-Doo algorithm" is not actually defined in HTML5 afaict so I am not sure what the spec recommends to find the main content or which elements should be excluded. I presume that header, nav, footer and aside are excluded. What about address? small? Arbitrary other elements with non-main ARIA landmark roles? It seems insufficient to me to say that the use case of finding the main content is satisfied by an algorithm that's ambiguous and not actually defined anywhere. Given the state of play, authors have no way to be confident that their main content can be identified correctly, and implementors have no way to know how to find it.

- I'm not confident that the sectioning elements in HTML5 exhaustively cover all possible forms of non-main content. If not, then it's likely that authors will have legitimate reason to have non-main content inside <body> which cannot reliably be skipped by the Scooby-Doo algorithm.

Overall, I would not fall on my sword to get the <main> element into WebKit but I would not reject a patch to add it either, assuming a sufficiently good spec exists for it somewhere.

> This idea doesn't seem to address any pressing use-cases. I don't expect
> authors to use it as intended consistently enough for it to be useful in
> practice for things like Safari's Reader mode. You're stuck needing to use
> something like the Scooby-Doo algorithm most of the time anyways. I don't
> outright object, but I think our time would be better spent on addressing
> more pressing problems with the web platform.

The same argument could have been made for <article>, but the implementation cost was so low that the benefit didn't have to be huge. I think the same applies to <main>.

Regards,
Maciej

From mjs at apple.com  Sat Nov 10 22:50:48 2012
From: mjs at apple.com (Maciej Stachowiak)
Date: Sat, 10 Nov 2012 22:50:48 -0800
Subject: [whatwg] Improving autocomplete
In-Reply-To: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
Message-ID: <BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>

(1) If this API fills in a form completely based on stored data, and not by completing the user's typing, then it is "autofill" rather than "autocomplete".

(2) If this API provides the ability to get user information without even having a visible form, then it's not clear that it is even really autofill. It's just "requestUserInformation()" or something.

(3) This API has important privacy and even security considerations. You have to tell the user exactly what you are going to fill in to the site before they approve. Unfortunately, most won't read it. If sites are asking for so much info that they have to split pages for usability, then it seems likely the UI that tells the user what the site is asking for will be impractical for most users to meaningfully review. This becomes especially dangerous if the mechanism can fill in credit card info. I would be very nervous if the browser could at any moment pop up a dialog that would submit all my credit card info to a dubious site if I slip and click the wrong button. Can you expand more on what thought you have given to the security considerations?

(4) Should this API be limited to initiation during a user interaction? That would reduce the ability of sites to spam the user with such forms.

(5) What makes the UI unspoofable? Is that an important part of the security model?

Regards,
Maciej

On Oct 26, 2012, at 12:24 AM, Elliott Sprehn <esprehn at gmail.com> wrote:

> Several of us on the Chrome team have been thinking about the
> challenges of filling out long forms full of personal information.
> We've noticed that site authors split up their forms across multiple
> pages to avoid overwhelming their users with one single massive form
> [1]. This is particularly bad on mobile where we've observed some
> popular retailers splitting their forms into six or more pages in an
> attempt to optimize their flow for a small screen. This unfortunately
> defeats many of the advantages of existing browser autocomplete.
> 
> In researching this we?ve found that with a few changes built on the
> existing HTML autocomplete spec [2] we can allow authors to recombine
> their forms and enable browsers to provide more useful autocomplete.
> 
> 1) HTMLFormElement.prototype.requestAutocomplete()
> Asks the user agent to asynchronously present a UI for performing full
> <form> autocomplete using the already spec?ed autocomplete attributes
> [2] used in the form. In concept this is very similar to prompt()
> except the UA could provide a streamlined experience for filling in
> information in large chunks. For example you could imagine choosing a
> shipping address from a drop down instead of presenting multiple
> inputs.
> 
> 2) Simple event named ?autocomplete?
> This event is dispatched on the form element after the UI presented by
> requestAutocomplete() is closed if the form validates after having
> filled each input and firing all necessary input events like ?change?.
> 
> 3) Simple event named ?autocompletecancel?
> This event is dispatched on the form if the UI is canceled.
> 
> Using this API authors may simplify their input flows from forms
> spread over multiple pages to just a few clicks on a single page all
> while getting all the autocomplete goodness! Authors can also display
> no forms at all to users of a browser who implements this proposal for
> one click checkout experiences which are important on mobile devices.
> 
> The proposed additions also improve security on the web as users will
> become accustomed to inputting their sensitive data through an
> unspoofable UI that could warn users of phishing sites or even allow
> them to choose per domain security images.
> 
> We?d love to hear the thoughts of other implementers on this proposal. :)
> 
> [1] ex. Retailers often split forms into credit card, billing address,
> and shipping address pages.
> [2] http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete
> 
> - E

From chaals at yandex-team.ru  Sun Nov 11 05:26:39 2012
From: chaals at yandex-team.ru (Charles McCathie Nevile)
Date: Sun, 11 Nov 2012 14:26:39 +0100
Subject: [whatwg] Improving autocomplete
In-Reply-To: <BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
Message-ID: <op.wnl2aps1y3oazb@chaals.local>

On Sun, 11 Nov 2012 07:50:48 +0100, Maciej Stachowiak <mjs at apple.com>  
wrote:

The key questions. I've added some more comments...

> (1) If this API fills in a form completely based on stored data, and not  
> by completing the user's typing, then it is "autofill" rather than  
> "autocomplete".

Yep.

> (2) If this API provides the ability to get user information without  
> even having a visible form, then it's not clear that it is even really  
> autofill. It's just "requestUserInformation()" or something.

Right. It's like openly shared super-cookies...

> (3) This API has important privacy and even security considerations.

Yes.

> You have to tell the user exactly what you are going to fill in to the
> site before they approve.

And because as soon as you put it into the input field the site can use  
it, as a basic security measure it seems like you should never autofill  
without explicit user confirmation.

> Unfortunately, most won't read it.

Indeed.

> If sites are asking for so much info that they have to split pages for
> usability, then it seems likely the UI that tells the user what the
> site is asking for will be impractical for most users to meaningfully
> review.

Yes. This is a problem I face from time to time, and I think its  
seriousness is underestimated. This process can be used to collect all  
sorts of information before the user realises they didn't want to hand it  
over.

> This becomes especially dangerous if the mechanism can fill in credit
> card info.

That assumes your most valuable info is about your credit card, which is  
only the case for a certain proportion of people.

> I would be very nervous if the browser could at any moment pop up a  
> dialog that would submit all my credit card info to a dubious site if I  
> slip and click the wrong button. Can you expand more on what thought you  
> have given to the security considerations?
>
> (4) Should this API be limited to initiation during a user interaction?

Yes...

> That would reduce the ability of sites to spam the user with such forms.
>
> (5) What makes the UI unspoofable? Is that an important part of the  
> security model?

cheers
Chaals

> Regards,
> Maciej
>
>
> On Oct 26, 2012, at 12:24 AM, Elliott Sprehn <esprehn at gmail.com> wrote:
>
>> Several of us on the Chrome team have been thinking about the
>> challenges of filling out long forms full of personal information.
>> We've noticed that site authors split up their forms across multiple
>> pages to avoid overwhelming their users with one single massive form
>> [1]. This is particularly bad on mobile where we've observed some
>> popular retailers splitting their forms into six or more pages in an
>> attempt to optimize their flow for a small screen. This unfortunately
>> defeats many of the advantages of existing browser autocomplete.
>>
>> In researching this we?ve found that with a few changes built on the
>> existing HTML autocomplete spec [2] we can allow authors to recombine
>> their forms and enable browsers to provide more useful autocomplete.
>>
>> 1) HTMLFormElement.prototype.requestAutocomplete()
>> Asks the user agent to asynchronously present a UI for performing full
>> <form> autocomplete using the already spec?ed autocomplete attributes
>> [2] used in the form. In concept this is very similar to prompt()
>> except the UA could provide a streamlined experience for filling in
>> information in large chunks. For example you could imagine choosing a
>> shipping address from a drop down instead of presenting multiple
>> inputs.
>>
>> 2) Simple event named ?autocomplete?
>> This event is dispatched on the form element after the UI presented by
>> requestAutocomplete() is closed if the form validates after having
>> filled each input and firing all necessary input events like ?change?.
>>
>> 3) Simple event named ?autocompletecancel?
>> This event is dispatched on the form if the UI is canceled.
>>
>> Using this API authors may simplify their input flows from forms
>> spread over multiple pages to just a few clicks on a single page all
>> while getting all the autocomplete goodness! Authors can also display
>> no forms at all to users of a browser who implements this proposal for
>> one click checkout experiences which are important on mobile devices.
>>
>> The proposed additions also improve security on the web as users will
>> become accustomed to inputting their sensitive data through an
>> unspoofable UI that could warn users of phishing sites or even allow
>> them to choose per domain security images.
>>
>> We?d love to hear the thoughts of other implementers on this proposal.  
>> :)
>>
>> [1] ex. Retailers often split forms into credit card, billing address,
>> and shipping address pages.
>> [2]  
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#attr-fe-autocomplete
>>
>> - E
>

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals at yandex-team.ru         Find more at http://yandex.com

From micovision at verizon.net  Sun Nov 11 05:41:37 2012
From: micovision at verizon.net (Joshua Smith)
Date: Sun, 11 Nov 2012 08:41:37 -0500
Subject: [whatwg] New CSS Properties
Message-ID: <AF8457F7-2F2A-41C0-890C-27FFA85B146A@verizon.net>

Hi,
I would like to suggest a few things to add to the CSS specifications.  I don't know the cost of implementation, but I am just giving you a few ideas that I had.

Foreground Property: like the background property, but layered above not below the object.  I really think this property would be helpful for development, and also, it would really streamline the HTML.
Adding to that: opacity properties for the background and foreground.  Could be seen as background-opacity.
Interior Styles: the capability to assign a style to an object from a different object's stylesheet.  The use of this may not be apparent up-front, but it would be very helpful especially with events like :hover.  For Example:
				
.someThing:hover {
	border-white;
	background: blue;
	.someThing .someChild {background: black;}; 
}

This brings me to two more suggestions: References and Routines.  Routines would be allowed for all elements to use.  They are similar to functions in other languages.  They could be expressed as ~referenceName {some-attribute: value;}.  References would be inside style declarations, and could be seen as .someThing ~referenceName.  They would evoke the specified Routine on the specified object.

Cheers,
Joshua Smith
micovision at verizon.net

From ian at hixie.ch  Sun Nov 11 09:52:45 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sun, 11 Nov 2012 17:52:45 +0000 (UTC)
Subject: [whatwg] New CSS Properties
In-Reply-To: <AF8457F7-2F2A-41C0-890C-27FFA85B146A@verizon.net>
References: <AF8457F7-2F2A-41C0-890C-27FFA85B146A@verizon.net>
Message-ID: <Pine.LNX.4.64.1211111752160.5442@ps20323.dreamhostps.com>

On Sun, 11 Nov 2012, Joshua Smith wrote:
>
> I would like to suggest a few things to add to the CSS specifications.

For CSS changes, please use the www-style at w3.org mailing list.

From esprehn at gmail.com  Sun Nov 11 10:58:34 2012
From: esprehn at gmail.com (Elliott Sprehn)
Date: Sun, 11 Nov 2012 10:58:34 -0800
Subject: [whatwg] Improving autocomplete
In-Reply-To: <BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
Message-ID: <CAPJYB1go+r_FCXknEJ_9MM7wVtvXj9ezygZD8A0rciVCqrw=wA@mail.gmail.com>

On Sat, Nov 10, 2012 at 10:50 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> (1) If this API fills in a form completely based on stored data, and not
> by completing the user's typing, then it is "autofill" rather than
> "autocomplete".
>

Yes, we considered requestAutofill() but it seems rather confusing since
the attribute on the form is "autocomplete". Perhaps we should revisit this.

> (2) If this API provides the ability to get user information without even
> having a visible form, then it's not clear that it is even really autofill.
> It's just "requestUserInformation()" or something.
>

It doesn't provide such a feature. A form is _always_ displayed. Think of
this like a fancy async prompt().

>
> (3) This API has important privacy and even security considerations. You
> have to tell the user exactly what you are going to fill in to the site
> before they approve. Unfortunately, most won't read it. If sites are asking
> for so much info that they have to split pages for usability, then it seems
> likely the UI that tells the user what the site is asking for will be
> impractical for most users to meaningfully review.

We don't believe this is the case. Think of an airline website: the last
step is going to ask you to review all your information, but you still had
to enter it across multiple steps. This is done for lots of reasons that
have to do with  optimizing click through. The goal is to avoid scaring the
user by making it look like they need to fill out tons of inputs.

Mobile is particularly egregious where we've seen one page worth of
information that's easy to review split across many different pages to
optimize the form completion rate.

This becomes especially dangerous if the mechanism can fill in credit card
> info. I would be very nervous if the browser could at any moment pop up a
> dialog that would submit all my credit card info to a dubious site if I
> slip and click the wrong button. Can you expand more on what thought you
> have given to the security considerations?
>

It requires a user gesture and is connected to the browser chrome. At the
limit this dialog could even show a per domain security image or require a
pin, though I don't think it's reasonable for the standard to require that
level of protection.

Ultimately protections against accidental clicks are up to the browser
vendor. You can slip and click and accidentally expose your location
information through navigator.geolocation's dialog as well, it's up to the
browser vendor to decide how to show the UI to prevent that.

> (4) Should this API be limited to initiation during a user interaction?
> That would reduce the ability of sites to spam the user with such forms.
>

Indeed, a user gesture should be required to launch the UI.

> (5) What makes the UI unspoofable? Is that an important part of the
> security model?
>

It overlaps/is connected to the browser chrome.

- E

From bzbarsky at MIT.EDU  Mon Nov 12 01:55:36 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 12 Nov 2012 01:55:36 -0800
Subject: [whatwg] Spec for handling runtime script errors doesn't seem to
	match reality
Message-ID: <50A0C798.30005@mit.edu>

Consider the attached testcase, which calls setTimeout on a window and 
passes in a function from a different window.

When this function is then called, it throws.

Gecko, WebKit, and Presto all seem to trigger the onerror handler of the 
window setTimeout was called on in this case.

Per spec, section 7.1.3.5.1, we have:

Whenever an uncaught runtime script error occurs in one of the
   scripts associated with a Document, the user agent must report
   the error at the URL of the resource containing the script (as
   established when the script was created), with the problematic
   position (line number and column number) in that resource, in
   the script's origin, using the onerror event handler of the
   script's global object.

But the global object is the window the function came from.  So the spec 
doesn't seem to match any of the above three rendering engines.  Does it 
match Trident?

I ask because I'm worried about web compat here.  While I agree that 
what the spec says to do is the sensible thing (and in fact, I had 
accidentally switched Gecko to doing what the spec says here as part of 
working on something else entirely), if none of the UAs do it then there 
may be web content that relies on it not happening.  There are certainly 
tests in Mozilla's regression test suite that inadvertently rely on 
Gecko's current behavior...

-Boris

From bzbarsky at MIT.EDU  Mon Nov 12 02:00:44 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 12 Nov 2012 02:00:44 -0800
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A0C798.30005@mit.edu>
References: <50A0C798.30005@mit.edu>
Message-ID: <50A0C8CC.8010401@mit.edu>

On 11/12/12 1:55 AM, Boris Zbarsky wrote:
> Consider the attached testcase, which calls setTimeout on a window and
> passes in a function from a different window.

Note that I observe the same behavior if I set onclick on another window 
too...  It seems just as bizarre there.  :(

-Boris

From bzbarsky at MIT.EDU  Mon Nov 12 02:04:37 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 12 Nov 2012 02:04:37 -0800
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A0C8CC.8010401@mit.edu>
References: <50A0C798.30005@mit.edu> <50A0C8CC.8010401@mit.edu>
Message-ID: <50A0C9B5.9000202@mit.edu>

On 11/12/12 2:00 AM, Boris Zbarsky wrote:
> On 11/12/12 1:55 AM, Boris Zbarsky wrote:
>> Consider the attached testcase, which calls setTimeout on a window and
>> passes in a function from a different window.
>
> Note that I observe the same behavior if I set onclick on another window
> too...

And with addEventListener, likewise.

-Boris

From simonp at opera.com  Mon Nov 12 05:45:32 2012
From: simonp at opera.com (Simon Pieters)
Date: Mon, 12 Nov 2012 14:45:32 +0100
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A0C798.30005@mit.edu>
References: <50A0C798.30005@mit.edu>
Message-ID: <op.wnnxt6i4idj3kv@simons-macbook-pro-2.local>

On Mon, 12 Nov 2012 10:55:36 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> Consider the attached testcase, which calls setTimeout on a window and
> passes in a function from a different window.
>
> When this function is then called, it throws.
>
> Gecko, WebKit, and Presto all seem to trigger the onerror handler of the
> window setTimeout was called on in this case.
>
> Per spec, section 7.1.3.5.1, we have:
>
>    Whenever an uncaught runtime script error occurs in one of the
>    scripts associated with a Document, the user agent must report
>    the error at the URL of the resource containing the script (as
>    established when the script was created), with the problematic
>    position (line number and column number) in that resource, in
>    the script's origin, using the onerror event handler of the
>    script's global object.
>
> But the global object is the window the function came from.  So the spec
> doesn't seem to match any of the above three rendering engines.  Does it
> match Trident?
>
> I ask because I'm worried about web compat here.  While I agree that
> what the spec says to do is the sensible thing (and in fact, I had
> accidentally switched Gecko to doing what the spec says here as part of
> working on something else entirely), if none of the UAs do it then there
> may be web content that relies on it not happening.  There are certainly
> tests in Mozilla's regression test suite that inadvertently rely on
> Gecko's current behavior...
>
> -Boris

I don't see any attachment. Maybe the whatwg list prunes them? Can you  
send it to www-archive?

Do browsers use the script's origin per spec, or do they use the  
function's global object's document's origin (for the purpose of tainting  
the arguments)?

-- 
Simon Pieters
Opera Software

From faulkner.steve at gmail.com  Mon Nov 12 05:46:51 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Mon, 12 Nov 2012 13:46:51 +0000
Subject: [whatwg] main spec updated with suggested changes to parser
	behaviour and rendering
Message-ID: <CA+ri+V=oKjJrDR=1uNDKcawem7Z=Z3_YMqoOCQn6+MDGQOWn9g@mail.gmail.com>

Hi all,

have updated the main spec with suggested changes to parser behaviour [1]
and rendering [2]

https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

feedback welcome!

[1]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0045.html
[2]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0054.html

-- 
with regards

Steve Faulkner
Technical Director - TPG

From hsivonen at iki.fi  Mon Nov 12 07:06:28 2012
From: hsivonen at iki.fi (Henri Sivonen)
Date: Mon, 12 Nov 2012 17:06:28 +0200
Subject: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard
In-Reply-To: <CAH4e3M5+rqf3QPv1pXDA0vR7O9CWsNKzD_P=sWL6Kco=6QHkKw@mail.gmail.com>
References: <CAH4e3M5+rqf3QPv1pXDA0vR7O9CWsNKzD_P=sWL6Kco=6QHkKw@mail.gmail.com>
Message-ID: <CAJQvAuexuPesG6CDyGEat06noieEt0JfHbUVw7Z2Cn_c4stBkw@mail.gmail.com>

Thanks for pursuing this.

Resending feedback previously written at
https://bugzilla.mozilla.org/show_bug.cgi?id=808593#c10 :

I think the bits ?type is equal to "font" or? and ?type is equal to
"archive" or? are highly questionable. The most popular font types are
in the process of getting application/ types and the most popular
archives already have application/ types.

I suspect the ?a reasonable amount of time has elapsed, as determined
by the user agent.? is unnecessary. The HTML spec has the same
provision for the <meta> prescan. Firefox didn?t implement it, a
couple of people complained, then fixed their code, and the sky didn?t
fall.

What are the use cases for ?Sniffing archives specifically?? It
appears that it sniffs ODF-style files
(http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.html#__RefHeading__752809_826425813
; EPUB, ODF, InDesign, etc.) and Open Packaging Conventions-based
files (https://en.wikipedia.org/wiki/Open_Packaging_Conventions ;
OOXML, XPS, etc.) files as zip archives. Is that intended and a
desirable outcome in the light of use cases? (In general, it would be
easier to review if the spec makes sense if the use cases and callers
of various sniffing functions were known.)

Otherwise, looks good to me.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From otakustay at live.com  Mon Nov 12 07:38:57 2012
From: otakustay at live.com (=?gb2312?B?1cXBosDt?=)
Date: Mon, 12 Nov 2012 15:38:57 +0000
Subject: [whatwg] Request for network diagnostic API
Message-ID: <COL002-W772607A1A1B1AF01C6F378D86D0@phx.gbl>

Hi all:
Recently we are digging into some performance issue related to our users' network, then we found we lack some methods to get required information about their network stats.
After some researches, we found a list of most frequently encountered issues:
1. User's IP, when mapped to our IP->ISP library, got a wrong result, so we respond the user with a wrong server, which dramatically slows down the transfer speed.2. User has his own network broken, but didn't know where the issue is.3. User couldn't even give us a simple network connectivity information so we were unable to confirm the problem.
As of above 3 issues, we think we should request some network diagnostic methods to help identify theses issues, including:
1. A `nslookup` method which gives the DNS lookup result, so we could help dianose whether our user connects the fastest server.2. A `traceroute` method which help us discover which section was out of work we we could, for example, contact out ISP to quickly fix it.3. A `ping` method which simply shows the connectivity between user's device and our server, and speed sometimes.
With these API we are quite sure we could identify most network issues quickly and easily, but without them, we have to send user a client application which collects all these information and then send to our server, however this is not a best choice, since user may suspect that we were giving some malware (e.g. keyboard monitoring app).
And also, with these API, if users could allow us to collect network informations, we could continuously research these data, finding where / when we do not give a best connectivity, and then improve to render a better service to our users.
We know these API are very privacy-sensitive, so it should **display a confirm panel** to user first just like the Geolocation API, telling user which website it willl be testing.

Gray Zhang-------------------------------------------otakustay at live.comhttp://www.otakustay.com (Broken)

From gphemsley at gmail.com  Mon Nov 12 08:57:59 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Mon, 12 Nov 2012 11:57:59 -0500
Subject: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard
In-Reply-To: <CAJQvAuexuPesG6CDyGEat06noieEt0JfHbUVw7Z2Cn_c4stBkw@mail.gmail.com>
References: <CAH4e3M5+rqf3QPv1pXDA0vR7O9CWsNKzD_P=sWL6Kco=6QHkKw@mail.gmail.com>
	<CAJQvAuexuPesG6CDyGEat06noieEt0JfHbUVw7Z2Cn_c4stBkw@mail.gmail.com>
Message-ID: <CAH4e3M5iOU3Mef1JvQOe5HfEBkpyz_EYDamDjKopsR=XPM6e5g@mail.gmail.com>

On Mon, Nov 12, 2012 at 10:06 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> Resending feedback previously written at
> https://bugzilla.mozilla.org/show_bug.cgi?id=808593#c10 :
>
> I think the bits ?type is equal to "font" or? and ?type is equal to
> "archive" or? are highly questionable. The most popular font types are
> in the process of getting application/ types and the most popular
> archives already have application/ types.

Buzzkill. ;(

> I suspect the ?a reasonable amount of time has elapsed, as determined
> by the user agent.? is unnecessary. The HTML spec has the same
> provision for the <meta> prescan. Firefox didn?t implement it, a
> couple of people complained, then fixed their code, and the sky didn?t
> fall.

This line was present in a previous draft of the spec, as was the
seeming allowance to begin matching the resource header before it had
finished loading. For simplicity in the algorithm, I removed the
latter, so I left the former in as an escape hatch for those who
wanted to emulate that behavior.

But if everyone vows to just wait for 512 bytes (or EOF), then that's
fine with me.

> What are the use cases for ?Sniffing archives specifically??

No idea. I only included it for completeness.

The 'rules for sniffing * specifically' are intended as hooks for
other specs to tie into. If no spec requires you to implement it, then
you have no need to implement it. HTML uses 'rules for sniffing images
specifically' (and 'rules for distinguishing if a resource is text or
binary'), and I imagine it could also find uses for 'rules for
sniffing audio specifically' and 'rules for sniffing video
specifically' (and maybe even 'rules for sniffing fonts
specifically').

> It
> appears that it sniffs ODF-style files
> (http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part3.html#__RefHeading__752809_826425813
> ; EPUB, ODF, InDesign, etc.) and Open Packaging Conventions-based
> files (https://en.wikipedia.org/wiki/Open_Packaging_Conventions ;
> OOXML, XPS, etc.) files as zip archives. Is that intended and a
> desirable outcome in the light of use cases? (In general, it would be
> easier to review if the spec makes sense if the use cases and callers
> of various sniffing functions were known.)

I don't think that's intended, but I don't know. The selection of
which bytes to sniff predates me, and I don't know what the use cases
are.

> Otherwise, looks good to me.

Thanks for the review!

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From mounir at lamouri.fr  Mon Nov 12 09:00:15 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Mon, 12 Nov 2012 17:00:15 +0000
Subject: [whatwg] 'datetime-local' and 'datetime' comments
Message-ID: <50A12B1F.1080200@lamouri.fr>

Hi,

We've been working on implementing date and time input types attributes
at Mozilla this summer and we found out that 'datetime-local' and
'datetime' have a quite odd behaviour.

'date' and 'time' are both timezone agnostic types: you just set a time
and date and we assume that it is relative to something. So, it seems
somewhat natural to assume that 'datetime' would be simply those types
added to each other. Instead of that, 'datetime' has a notion of
timezone and 'datetime-local' is the timezone agnostic type.

In addition of being more intuitive, it seems that a huge majority of
date/time usage are timezone agnostics because, usually, the timezone is
implicit. For example, booking flight/train tickets.
There is however some use cases I can think of, like scheduling a
meeting, where, sometimes, you might want to mess with timezones. But
those are quite rare.

Furthermore, there are currently two implementations for 'datetime' and
'datetime-local' I can think of:
- Opera: 'datetime' is like 'datetime-local' except that there is a
greyed 'UTC' text next to the datetime picker;
- Chrome Android: 'datetime' is exactly like 'datetime-local'.
I haven't checked what is actually sent when the form is submitted by
those implementations.

Last but not least, I have never seen any [good and simple] UI allowing
me to pick a date and time in a specific time zone. As far as I know,
there are no native UI for those things even on mobile where there are
UI for date and time pickers.

As a conclusion, given the lack of good UI and good implementations, I
think we should change the behaviour of 'datetime' to match the
behaviour of 'datetime-local' so developers don't use the former and
falsely expect the behaviour of the later.
Also, I would suggest that we remove 'datetime-local' from the
specifications. If later if find out that we really need a date-time
picker that is not timezone agnostic, we could add something. For the
moment, given the state of the implementations and the very tiny use
cases that could solve, I think having this type would hurt more than help.

Thanks,
--
Mounir

From tobie.langel at gmail.com  Mon Nov 12 09:07:20 2012
From: tobie.langel at gmail.com (Tobie Langel)
Date: Mon, 12 Nov 2012 18:07:20 +0100
Subject: [whatwg] Request for network diagnostic API
In-Reply-To: <COL002-W772607A1A1B1AF01C6F378D86D0@phx.gbl>
References: <COL002-W772607A1A1B1AF01C6F378D86D0@phx.gbl>
Message-ID: <CAMK=o4dfj4zxNpxYOODQhBakNCHg-620Y9=gcr9yjVXqQaLL2Q@mail.gmail.com>

You should look at the work going on in the WebPerf WG[1] which is
getting re-chartered right now.

--tobie

---
[1]: http://www.w3.org/2010/webperf/

On Mon, Nov 12, 2012 at 4:38 PM, ??? <otakustay at live.com> wrote:
> Hi all:
> Recently we are digging into some performance issue related to our users' network, then we found we lack some methods to get required information about their network stats.
> After some researches, we found a list of most frequently encountered issues:
> 1. User's IP, when mapped to our IP->ISP library, got a wrong result, so we respond the user with a wrong server, which dramatically slows down the transfer speed.2. User has his own network broken, but didn't know where the issue is.3. User couldn't even give us a simple network connectivity information so we were unable to confirm the problem.
> As of above 3 issues, we think we should request some network diagnostic methods to help identify theses issues, including:
> 1. A `nslookup` method which gives the DNS lookup result, so we could help dianose whether our user connects the fastest server.2. A `traceroute` method which help us discover which section was out of work we we could, for example, contact out ISP to quickly fix it.3. A `ping` method which simply shows the connectivity between user's device and our server, and speed sometimes.
> With these API we are quite sure we could identify most network issues quickly and easily, but without them, we have to send user a client application which collects all these information and then send to our server, however this is not a best choice, since user may suspect that we were giving some malware (e.g. keyboard monitoring app).
> And also, with these API, if users could allow us to collect network informations, we could continuously research these data, finding where / when we do not give a best connectivity, and then improve to render a better service to our users.
> We know these API are very privacy-sensitive, so it should **display a confirm panel** to user first just like the Geolocation API, telling user which website it willl be testing.
>
> Gray Zhang-------------------------------------------otakustay at live.comhttp://www.otakustay.com (Broken)

From bzbarsky at MIT.EDU  Mon Nov 12 09:12:32 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 12 Nov 2012 09:12:32 -0800
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <op.wnnxt6i4idj3kv@simons-macbook-pro-2.local>
References: <50A0C798.30005@mit.edu>
	<op.wnnxt6i4idj3kv@simons-macbook-pro-2.local>
Message-ID: <50A12E00.3090404@mit.edu>

On 11/12/12 5:45 AM, Simon Pieters wrote:
> I don't see any attachment. Maybe the whatwg list prunes them? Can you
> send it to www-archive?

Gah.

Here's the entire test case:

> Do browsers use the script's origin per spec, or do they use the
> function's global object's document's origin (for the purpose of
> tainting the arguments)?

This isn't even about origins and tainting so far; everything here is 
same-origin.  It's purely about which onerror gets called.

-Boris

From jens at meiert.com  Mon Nov 12 10:26:00 2012
From: jens at meiert.com (Jens O. Meiert)
Date: Mon, 12 Nov 2012 10:26:00 -0800
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
Message-ID: <CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>

Should <main> be optional or required?

I?d deem an optional <main> to be nonsense because it suggests
documents are inherently without goal, or focus.

I?d deem a required <main> to be nonsense because we already have an
(implied) <body> element, and because element proliferation doesn?t
work in anyone?s favor.

That <body> essentially means <main> always seemed reasonable to me.
There are plenty of options for authors to add styling hooks if they
need any, including <div role=main>.

-- 
Jens O. Meiert
http://meiert.com/en/

From Olli.Pettay at helsinki.fi  Mon Nov 12 10:45:05 2012
From: Olli.Pettay at helsinki.fi (Olli Pettay)
Date: Mon, 12 Nov 2012 20:45:05 +0200
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A0C798.30005@mit.edu>
References: <50A0C798.30005@mit.edu>
Message-ID: <50A143B1.9050403@helsinki.fi>

On 11/12/2012 11:55 AM, Boris Zbarsky wrote:
> Consider the attached testcase, which calls setTimeout on a window and passes in a function from a different window.
>
> When this function is then called, it throws.
>
> Gecko, WebKit, and Presto all seem to trigger the onerror handler of the window setTimeout was called on in this case.
>
> Per spec, section 7.1.3.5.1, we have:
>
>    Whenever an uncaught runtime script error occurs in one of the
>    scripts associated with a Document, the user agent must report
>    the error at the URL of the resource containing the script (as
>    established when the script was created), with the problematic
>    position (line number and column number) in that resource, in
>    the script's origin, using the onerror event handler of the
>    script's global object.
>
> But the global object is the window the function came from.  So the spec doesn't seem to match any of the above three rendering engines.  Does it
> match Trident?
>
> I ask because I'm worried about web compat here.  While I agree that what the spec says to do is the sensible thing (and in fact, I had accidentally
> switched Gecko to doing what the spec says here as part of working on something else entirely), if none of the UAs do it then there may be web content
> that relies on it not happening.  There are certainly tests in Mozilla's regression test suite that inadvertently rely on Gecko's current behavior...

First I thought the spec behavior would make more sense, but if the error is about executing something bound to
window A it would be quite surprising to get error event on window B.
But I don't feel strongly about this.

-Olli

>
> -Boris

From bzbarsky at MIT.EDU  Mon Nov 12 11:48:20 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 12 Nov 2012 11:48:20 -0800
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A143B1.9050403@helsinki.fi>
References: <50A0C798.30005@mit.edu> <50A143B1.9050403@helsinki.fi>
Message-ID: <50A15284.2060603@mit.edu>

On 11/12/12 10:45 AM, Olli Pettay wrote:
> First I thought the spec behavior would make more sense, but if the
> error is about executing something bound to
> window A it would be quite surprising to get error event on window B.

So I did a bit more experimenting, and at first glance when the function 
runs, even though the function's global is actually window A the "this" 
object seems to be set to window B... _That_'s not specced anywhere 
either, afaict.

The whole thing is a bit of a mess.  :(

-Boris

From ian at hixie.ch  Mon Nov 12 11:45:01 2012
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 12 Nov 2012 19:45:01 +0000 (UTC)
Subject: [whatwg] Request for network diagnostic API
In-Reply-To: <COL002-W772607A1A1B1AF01C6F378D86D0@phx.gbl>
References: <COL002-W772607A1A1B1AF01C6F378D86D0@phx.gbl>
Message-ID: <Pine.LNX.4.64.1211121942540.15000@ps20323.dreamhostps.com>

On Mon, 12 Nov 2012, ?????? wrote:
>
> 1. User's IP, when mapped to our IP->ISP library, got a wrong result, so 
> we respond the user with a wrong server, which dramatically slows down 
> the transfer speed.
>
> 2. User has his own network broken, but didn't know where the issue is.
>
> 3. User couldn't even give us a simple network connectivity information 
> so we were unable to confirm the problem.

Tobie's suggestion (to raise this on the Web Perf working group) is a 
reasonable one. As a general rule, though, these problems seem very 
specific. It's not clear that it would be worth providing features to 
solve these problems, since they really would have very few other use 
cases. We try to only solve problems that affect many sites, since there 
is a cost to each such feature.

From bobbyholley at gmail.com  Mon Nov 12 14:03:25 2012
From: bobbyholley at gmail.com (Bobby Holley)
Date: Mon, 12 Nov 2012 14:03:25 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <509DBE73.7070109@mit.edu>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<509CA0E2.9050206@mit.edu>
	<CAJE5ia-f4iLNnLaq=4-Fj2de9U5XeGOg+9MwpdfTHXGQwC5Ktg@mail.gmail.com>
	<CAKBxTcLztXVVOsQYoq7ARO21JS91q=0J1i1Y0vJCptbnk1ze=Q@mail.gmail.com>
	<CAJE5ia_GP_dMnDodfRv6uLOzik6TY05S5V+FcM+QMOpwMoYpcg@mail.gmail.com>
	<CAKBxTc+AmYLr2VB4g+VFB2qF8hUcZ1ujTSbHjwj-wsKaAqdbtw@mail.gmail.com>
	<CAJE5ia8p7gLuYwj9BjaDGNWgZecw=ymYGVmsf9akhLJaZAOONA@mail.gmail.com>
	<CAKBxTcJMRAxLuMBWbUVbhEpghDu5aQkBM1tMK9BbOZbbQC35aQ@mail.gmail.com>
	<CAJE5ia8ec1=XsS_x-KF17A2O5j0pwYdE3y-fDpYrZrR5fvfReg@mail.gmail.com>
	<509DBE73.7070109@mit.edu>
Message-ID: <CAKBxTcKKYB-U_LN9BCgrS844gm54HRXJhAJin4fiWBRTKUc8QA@mail.gmail.com>

Per various IRC discussions, it sounds like Gecko is going to align with
Trident and Presto here, and that WebKit probably isn't going to align
unless there's a compat issue or unless the implementation becomes simpler
for them somehow.

On Fri, Nov 9, 2012 at 6:39 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 11/9/12 2:05 PM, Adam Barth wrote:
>
>>   The approach we use in WebKit is quite simple---we just perform an
>> access check before doing any sensitive operations.
>>
>
> The issue in Gecko, as I understand, is that security checks from C++ code
> require introspecting running JS to figure out what the right actor
> ("subject") origin for the security check is.  This is somewhat fragile
> because it's easy to accidentally interpose other things that look like
> running JS between the caller and callee in many cases.  Note that this
> problem would be even worse for a self-hosted (implemented in JS)
> implementation of something like Location...
>
> The upshot is that instead we aim to do security checks at points where
> control crosses from one origin to another, and use proxies to enforce the
> security invariants involved.
>
> Bobby knows more about this than I do, so I'll let him correct any
> inaccuracies.
>
>
>  This access check is required in any case because the underlying Location
>> object is
>> visible across origins.
>>
>
> In Gecko, it's actually not.  A proxy is visible.
>
> One thing I'd like is some comment from Opera and Microsoft about what
> their situation is, since implementing what WebKit does would mean both of
> those changing.  This is probably the wrong venue to get hold of Microsoft
> for an official statement, sadly.  :(
>
> -Boris
>

From junov at chromium.org  Mon Nov 12 14:36:14 2012
From: junov at chromium.org (Justin Novosad)
Date: Mon, 12 Nov 2012 17:36:14 -0500
Subject: [whatwg] Enabling LCD Text in 2D canvases.
Message-ID: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>

Greetings,

Looking at the discussion archives, I saw that there have been proposals in
the past for exposing anti-aliasing related features to the 2D canvas
rendering context.  I realize these proposals met significant opposition
each time. Nonetheless, I would like to quickly re-open the discussion
because I feel there is a lot at stake for the web platform.  How about a
2d canvas rendering context attribute for controlling text anti-aliasing,
which could be used to enable LCD text filtering?

The main motivation is to make web apps better.  For many types of apps,
DOM-based rendering is uncompetitively slow (e.g. rendering a large number
of independently positioned text labels). On the other hand, 2D canvas can
deliver significantly better performance in many cases, but there is a
degradation in visual quality due to the lack of LCD text filtering.
 Current browsers don't enable LCD text in 2D canvas to prevent rendering
artifacts.  If LCD text were enable-able, authors would have to be mindful
of a number of caveats in order to avoid rendering artifacts. For example,
artifacts could result from certain use cases of canvas compositing,
transforms on the canvas element, canvas-to-canvas copying with drawImage
with a transform applied.  These are the same caveats native app developers
must face when using LCD text filtering.

Any thoughts?

From ian at hixie.ch  Mon Nov 12 15:08:46 2012
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 12 Nov 2012 23:08:46 +0000 (UTC)
Subject: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard
In-Reply-To: <CAH4e3M5iOU3Mef1JvQOe5HfEBkpyz_EYDamDjKopsR=XPM6e5g@mail.gmail.com>
References: <CAH4e3M5+rqf3QPv1pXDA0vR7O9CWsNKzD_P=sWL6Kco=6QHkKw@mail.gmail.com>
	<CAJQvAuexuPesG6CDyGEat06noieEt0JfHbUVw7Z2Cn_c4stBkw@mail.gmail.com>
	<CAH4e3M5iOU3Mef1JvQOe5HfEBkpyz_EYDamDjKopsR=XPM6e5g@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211122307050.15000@ps20323.dreamhostps.com>

On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
> 
> But if everyone vows to just wait for 512 bytes (or EOF), then that's 
> fine with me.

I don't think we should require tools to wait for 512 bytes. This is an 
area where if we have the requirement, some user agents are just going to 
have a timeout anyway and ignore the spec; we gain nothing by making it 
non-conforming to have a timeout.

> > What are the use cases for ?Sniffing archives specifically??
> 
> No idea. I only included it for completeness.

Please don't spec things for completeness without use cases. :-)

From gphemsley at gmail.com  Mon Nov 12 16:02:30 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Mon, 12 Nov 2012 19:02:30 -0500
Subject: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard
In-Reply-To: <Pine.LNX.4.64.1211122307050.15000@ps20323.dreamhostps.com>
References: <CAH4e3M5+rqf3QPv1pXDA0vR7O9CWsNKzD_P=sWL6Kco=6QHkKw@mail.gmail.com>
	<CAJQvAuexuPesG6CDyGEat06noieEt0JfHbUVw7Z2Cn_c4stBkw@mail.gmail.com>
	<CAH4e3M5iOU3Mef1JvQOe5HfEBkpyz_EYDamDjKopsR=XPM6e5g@mail.gmail.com>
	<Pine.LNX.4.64.1211122307050.15000@ps20323.dreamhostps.com>
Message-ID: <CAH4e3M5yCey0xOWtzjN=AFO15vzuj3+QQEH4Wn3GDvuMtBV6vQ@mail.gmail.com>

On Mon, Nov 12, 2012 at 6:08 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
>> But if everyone vows to just wait for 512 bytes (or EOF), then that's
>> fine with me.
>
> I don't think we should require tools to wait for 512 bytes. This is an
> area where if we have the requirement, some user agents are just going to
> have a timeout anyway and ignore the spec; we gain nothing by making it
> non-conforming to have a timeout.

I'm inclined to agree with you, but I'm curious what other
implementers have to say on the issue.

>> > What are the use cases for ?Sniffing archives specifically??
>>
>> No idea. I only included it for completeness.
>
> Please don't spec things for completeness without use cases. :-)

In that case, I need to know which you think you might want for HTML
and which you know you won't. (I don't know of any other specs reliant
on mimesniff.)

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From ian at hixie.ch  Mon Nov 12 16:12:53 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Nov 2012 00:12:53 +0000 (UTC)
Subject: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard
In-Reply-To: <CAH4e3M5yCey0xOWtzjN=AFO15vzuj3+QQEH4Wn3GDvuMtBV6vQ@mail.gmail.com>
References: <CAH4e3M5+rqf3QPv1pXDA0vR7O9CWsNKzD_P=sWL6Kco=6QHkKw@mail.gmail.com>
	<CAJQvAuexuPesG6CDyGEat06noieEt0JfHbUVw7Z2Cn_c4stBkw@mail.gmail.com>
	<CAH4e3M5iOU3Mef1JvQOe5HfEBkpyz_EYDamDjKopsR=XPM6e5g@mail.gmail.com>
	<Pine.LNX.4.64.1211122307050.15000@ps20323.dreamhostps.com>
	<CAH4e3M5yCey0xOWtzjN=AFO15vzuj3+QQEH4Wn3GDvuMtBV6vQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211130008590.15000@ps20323.dreamhostps.com>

On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
> On Mon, Nov 12, 2012 at 6:08 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
> >> But if everyone vows to just wait for 512 bytes (or EOF), then that's 
> >> fine with me.
> >
> > I don't think we should require tools to wait for 512 bytes. This is 
> > an area where if we have the requirement, some user agents are just 
> > going to have a timeout anyway and ignore the spec; we gain nothing by 
> > making it non-conforming to have a timeout.
> 
> I'm inclined to agree with you, but I'm curious what other implementers 
> have to say on the issue.
> 
> >> > What are the use cases for ?Sniffing archives specifically??
> >>
> >> No idea. I only included it for completeness.
> >
> > Please don't spec things for completeness without use cases. :-)
> 
> In that case, I need to know which you think you might want for HTML and 
> which you know you won't. (I don't know of any other specs reliant on 
> mimesniff.)

We definitely need (and are using) the generic sniffer, sniffing for 
images specifically, and the rules for text vs binary.

We may one day need a set of rules to sniff for a media resource (e.g. 
audio/wave vs video/webm), but whether we'll need this is as yet unclear 
(some browser vendors want to sniff, others don't).

CSS might need a font sniffer for @font-face, I don't know.

That's it, as far as I know.

From bzbarsky at MIT.EDU  Mon Nov 12 16:17:28 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 12 Nov 2012 16:17:28 -0800
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A15284.2060603@mit.edu>
References: <50A0C798.30005@mit.edu> <50A143B1.9050403@helsinki.fi>
	<50A15284.2060603@mit.edu>
Message-ID: <50A19198.8040606@mit.edu>

On 11/12/12 11:48 AM, Boris Zbarsky wrote:
> So I did a bit more experimenting, and at first glance when the function
> runs, even though the function's global is actually window A the "this"
> object seems to be set to window B... _That_'s not specced anywhere
> either, afaict.

And in fact what the spec said was both ambiguous and not matching reality.

I filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=19947 about the 
"this" issue.  Still looking into what IE does in terms of which onerror 
handler is called.

-Boris

From silviapfeiffer1 at gmail.com  Mon Nov 12 16:53:17 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 13 Nov 2012 11:53:17 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
Message-ID: <CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>

On Tue, Nov 13, 2012 at 5:26 AM, Jens O. Meiert <jens at meiert.com> wrote:

> Should <main> be optional or required?
>

> I?d deem an optional <main> to be nonsense because it suggests
> documents are inherently without goal, or focus.
>
> I?d deem a required <main> to be nonsense because we already have an
> (implied) <body> element, and because element proliferation doesn?t
> work in anyone?s favor.
>

I can imagine it to become "required", if we mean by that that the browsers
will need to parse a page and either find a <main> element or determine
heuristically with the Scooby-Doo algorithm which part of the page is
actually the main part and then add that to its DOM. Since we have the
Scooby-Doo algorithm, we have a means to stay backwards compatible.

That <body> essentially means <main> always seemed reasonable to me.
> There are plenty of options for authors to add styling hooks if they
> need any, including <div role=main>.

You are correct - there is no need for this for styling. However, <main> is
actually not for styling, but to provide a direct markup of the
*semantically* main piece of content on the page. A Scooby-Doo algorithm
can only heuristically determine what that is - with <main> the Web Dev
gets an actual vehicle to point their finger explicitly rather than
implicitly saying in a hand-wavy manner that it's what remains if you take
away all this other stuff (that is: if we're lucky and that "other stuff"
has actually been marked up).

Silvia.

From bzbarsky at MIT.EDU  Mon Nov 12 18:15:29 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 12 Nov 2012 18:15:29 -0800
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A19198.8040606@mit.edu>
References: <50A0C798.30005@mit.edu> <50A143B1.9050403@helsinki.fi>
	<50A15284.2060603@mit.edu> <50A19198.8040606@mit.edu>
Message-ID: <50A1AD41.8080406@mit.edu>

On 11/12/12 4:17 PM, Boris Zbarsky wrote:
> Still looking into what IE does in terms of which onerror handler is called.

Looks like IE, in all the modes I can test, does what the spec says 
right now.

I'll be changing Gecko to align with IE and the spec (and, arguably, 
sanity) here.

-Boris

From mnot at mnot.net  Mon Nov 12 22:41:42 2012
From: mnot at mnot.net (Mark Nottingham)
Date: Tue, 13 Nov 2012 17:41:42 +1100
Subject: [whatwg] Including
Message-ID: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>

Hi WHATWG,

I've maintained a little library for a while that does inclusion:
  https://github.com/mnot/hinclude
  http://mnot.github.com/hinclude/

It's used in a few different places, and is now part of Symfony <http://symfony.com>, apparently.

Besides the obvious issue of "should HTML5 have an inclusion tag?", something else has come up.

Right now, hinclude uses an XML namespace (hx:) to introduce a new tag. This was pretty widely tested to be interoperable way back, but AIUI that option is going away (whatever that means) in HTML5.

It's been suggested <https://github.com/mnot/hinclude/issues/13> that a data-* attribute on div could be used here, but reading the description there, I'm not so sure:

"[T]hese attributes are intended for use by the site's own scripts, and are not a generic extension mechanism for publicly-usable metadata."

<http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes>

hinclude is intended to be visible to software beyond the site's own scripts. So, what's the appropriate thing to do here? Keep on using hx:include (after all, it works)? use data-include or similar? Or?

Thanks,

--
Mark Nottingham   http://www.mnot.net/

From tkent at chromium.org  Tue Nov 13 01:42:30 2012
From: tkent at chromium.org (TAMURA, Kent)
Date: Tue, 13 Nov 2012 18:42:30 +0900
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50A12B1F.1080200@lamouri.fr>
References: <50A12B1F.1080200@lamouri.fr>
Message-ID: <CAGH7WqEoHmY8636V+ek6vGLLDizA8upiOxhYvOD49u=1=Chxog@mail.gmail.com>

The current UI implementations of Opera, iOS, and Chrome-Android spoil the
HTML standard. Web authors hardly have motivation to use type=datetime.
They can add 'UTC' text, and their code can append 'Z' to values easily.

I agree that the type names are not good.  People must think type=datetime
is a combination of type=date and type=time. It's not too late to rename
datetime-local to datetime because the number of type=datetime or
type=datetime-local in the Web is terribly smaller than the number of
type=date.

On Tue, Nov 13, 2012 at 2:00 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> Hi,

> We've been working on implementing date and time input types attributes
> at Mozilla this summer and we found out that 'datetime-local' and
> 'datetime' have a quite odd behaviour.

> 'date' and 'time' are both timezone agnostic types: you just set a time
> and date and we assume that it is relative to something. So, it seems
> somewhat natural to assume that 'datetime' would be simply those types
> added to each other. Instead of that, 'datetime' has a notion of
> timezone and 'datetime-local' is the timezone agnostic type.

> In addition of being more intuitive, it seems that a huge majority of
> date/time usage are timezone agnostics because, usually, the timezone is
> implicit. For example, booking flight/train tickets.
> There is however some use cases I can think of, like scheduling a
> meeting, where, sometimes, you might want to mess with timezones. But
> those are quite rare.

> Furthermore, there are currently two implementations for 'datetime' and
> 'datetime-local' I can think of:
> - Opera: 'datetime' is like 'datetime-local' except that there is a
> greyed 'UTC' text next to the datetime picker;
> - Chrome Android: 'datetime' is exactly like 'datetime-local'.
> I haven't checked what is actually sent when the form is submitted by
> those implementations.

> Last but not least, I have never seen any [good and simple] UI allowing
> me to pick a date and time in a specific time zone. As far as I know,
> there are no native UI for those things even on mobile where there are
> UI for date and time pickers.

> As a conclusion, given the lack of good UI and good implementations, I
> think we should change the behaviour of 'datetime' to match the
> behaviour of 'datetime-local' so developers don't use the former and
> falsely expect the behaviour of the later.
> Also, I would suggest that we remove 'datetime-local' from the
> specifications. If later if find out that we really need a date-time
> picker that is not timezone agnostic, we could add something. For the
> moment, given the state of the implementations and the very tiny use
> cases that could solve, I think having this type would hurt more than
> help.

> Thanks,
> --
> Mounir

-- 
TAMURA Kent
Software Engineer, Google

From silviapfeiffer1 at gmail.com  Tue Nov 13 02:11:48 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 13 Nov 2012 21:11:48 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
Message-ID: <CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>

By random chance, I just stumbled across this GitHub tool:
https://github.com/visualrevenue/reporter

It provides another heuristic approach - different from Scooby-Doo -  to
determining what is the main content on a page. This is from a journalist's
point of view and it is using a scoring and evaluation algorithm.

I'm sure a lot of other people had to solve this problem as well and have
done so in their own special way. Explicit author markup would make such a
task so much easier.

Regards,
Silvia.

On Tue, Nov 13, 2012 at 11:53 AM, Silvia Pfeiffer <silviapfeiffer1 at gmail.com
> wrote:

> On Tue, Nov 13, 2012 at 5:26 AM, Jens O. Meiert <jens at meiert.com> wrote:
>
>> Should <main> be optional or required?
>>
>
>> I?d deem an optional <main> to be nonsense because it suggests
>> documents are inherently without goal, or focus.
>>
>> I?d deem a required <main> to be nonsense because we already have an
>> (implied) <body> element, and because element proliferation doesn?t
>> work in anyone?s favor.
>>
>
> I can imagine it to become "required", if we mean by that that the
> browsers will need to parse a page and either find a <main> element or
> determine heuristically with the Scooby-Doo algorithm which part of the
> page is actually the main part and then add that to its DOM. Since we have
> the Scooby-Doo algorithm, we have a means to stay backwards compatible.
>
>
> That <body> essentially means <main> always seemed reasonable to me.
>> There are plenty of options for authors to add styling hooks if they
>> need any, including <div role=main>.
>
>
> You are correct - there is no need for this for styling. However, <main>
> is actually not for styling, but to provide a direct markup of the
> *semantically* main piece of content on the page. A Scooby-Doo algorithm
> can only heuristically determine what that is - with <main> the Web Dev
> gets an actual vehicle to point their finger explicitly rather than
> implicitly saying in a hand-wavy manner that it's what remains if you take
> away all this other stuff (that is: if we're lucky and that "other stuff"
> has actually been marked up).
>
> Silvia.
>

From philipj at opera.com  Tue Nov 13 02:35:03 2012
From: philipj at opera.com (=?utf-8?Q?Philip_J=C3=A4genstedt?=)
Date: Tue, 13 Nov 2012 11:35:03 +0100
Subject: [whatwg] [mimesniff] Review requested on MIME Sniffing Standard
In-Reply-To: <Pine.LNX.4.64.1211130008590.15000@ps20323.dreamhostps.com>
References: <CAH4e3M5+rqf3QPv1pXDA0vR7O9CWsNKzD_P=sWL6Kco=6QHkKw@mail.gmail.com>
	<CAJQvAuexuPesG6CDyGEat06noieEt0JfHbUVw7Z2Cn_c4stBkw@mail.gmail.com>
	<CAH4e3M5iOU3Mef1JvQOe5HfEBkpyz_EYDamDjKopsR=XPM6e5g@mail.gmail.com>
	<Pine.LNX.4.64.1211122307050.15000@ps20323.dreamhostps.com>
	<CAH4e3M5yCey0xOWtzjN=AFO15vzuj3+QQEH4Wn3GDvuMtBV6vQ@mail.gmail.com>
	<Pine.LNX.4.64.1211130008590.15000@ps20323.dreamhostps.com>
Message-ID: <op.wnpjopwpsr6mfa@kirk>

On Tue, 13 Nov 2012 01:12:53 +0100, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 12 Nov 2012, Gordon P. Hemsley wrote:
>
>> In that case, I need to know which you think you might want for HTML and
>> which you know you won't. (I don't know of any other specs reliant on
>> mimesniff.)
>
> We may one day need a set of rules to sniff for a media resource (e.g.
> audio/wave vs video/webm), but whether we'll need this is as yet unclear
> (some browser vendors want to sniff, others don't).

Opera has implemented the mimesniff spec and is using it for media  
resources, so I'd appreciate if this stayed in the spec even if not all  
browser vendors want to do the same.

-- 
Philip J?genstedt
Core Developer
Opera Software

From froidure_nicolas at yahoo.fr  Tue Nov 13 02:51:33 2012
From: froidure_nicolas at yahoo.fr (Nicolas Froidure)
Date: Tue, 13 Nov 2012 11:51:33 +0100
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50A12B1F.1080200@lamouri.fr>
References: <50A12B1F.1080200@lamouri.fr>
Message-ID: <50A22635.2090900@yahoo.fr>

Hi,

In my opinion, it's normal that datetime and datetime-local have 
timezone and date/time don't. A date is timezone independant and time is 
more a duration then a time relative to a particular instant of a 
particular day.

So making datetime having the behavior of datetime-local does not seem 
to be necessary for consistency. In any case, i think that we still need 
a way to define a datetime in a particular timezone since you cited one 
case in which it make sense.

Another problem is the ouput value that seems inconsistent between 
datetime, datetime himself and datetime-local. By example in the Google 
Chrome/Firefox console :
var f=document.createElement('input');
f.setAttribute('type','datetime');
f.value='2012-01-26 13:37:01';
console.log(f.value); // outputs 2012-01-26 13:37:01
f.value='2012-01-26T13:37:01Z';
console.log(f.value); // outputs 2012-01-26T13:37:01Z
f.setAttribute('type','datetime-local');
console.log(f.value); // outputs 2012-01-26T13:37:01Z
f.value='2012-01-26 13:37:01';
console.log(f.value); // outputs 2012-01-26 13:37:01

I think that whatever you decide for datetimes, it should always return 
a UTC value with only one format (yyyy-mm-dd hh:mm:ss or 
yyyy-mm-dd-Thh:mm:ssZ) to allow us to threat it the same way  whether it 
is relative to the user timezone or not.

On 12/11/2012 18:00, Mounir Lamouri wrote:
> Hi,
>
> We've been working on implementing date and time input types attributes
> at Mozilla this summer and we found out that 'datetime-local' and
> 'datetime' have a quite odd behaviour.
>
> 'date' and 'time' are both timezone agnostic types: you just set a time
> and date and we assume that it is relative to something. So, it seems
> somewhat natural to assume that 'datetime' would be simply those types
> added to each other. Instead of that, 'datetime' has a notion of
> timezone and 'datetime-local' is the timezone agnostic type.
>
> In addition of being more intuitive, it seems that a huge majority of
> date/time usage are timezone agnostics because, usually, the timezone is
> implicit. For example, booking flight/train tickets.
> There is however some use cases I can think of, like scheduling a
> meeting, where, sometimes, you might want to mess with timezones. But
> those are quite rare.
>
> Furthermore, there are currently two implementations for 'datetime' and
> 'datetime-local' I can think of:
> - Opera: 'datetime' is like 'datetime-local' except that there is a
> greyed 'UTC' text next to the datetime picker;
> - Chrome Android: 'datetime' is exactly like 'datetime-local'.
> I haven't checked what is actually sent when the form is submitted by
> those implementations.
>
> Last but not least, I have never seen any [good and simple] UI allowing
> me to pick a date and time in a specific time zone. As far as I know,
> there are no native UI for those things even on mobile where there are
> UI for date and time pickers.
>
> As a conclusion, given the lack of good UI and good implementations, I
> think we should change the behaviour of 'datetime' to match the
> behaviour of 'datetime-local' so developers don't use the former and
> falsely expect the behaviour of the later.
> Also, I would suggest that we remove 'datetime-local' from the
> specifications. If later if find out that we really need a date-time
> picker that is not timezone agnostic, we could add something. For the
> moment, given the state of the implementations and the very tiny use
> cases that could solve, I think having this type would hurt more than help.
>
> Thanks,
> --
> Mounir
>
>

From simonp at opera.com  Tue Nov 13 03:31:46 2012
From: simonp at opera.com (Simon Pieters)
Date: Tue, 13 Nov 2012 12:31:46 +0100
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A12E00.3090404@mit.edu>
References: <50A0C798.30005@mit.edu>
	<op.wnnxt6i4idj3kv@simons-macbook-pro-2.local>
	<50A12E00.3090404@mit.edu>
Message-ID: <op.wnpma8oridj3kv@simons-macbook-pro-2.local>

On Mon, 12 Nov 2012 18:12:32 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 11/12/12 5:45 AM, Simon Pieters wrote:
>> I don't see any attachment. Maybe the whatwg list prunes them? Can you
>> send it to www-archive?
>
> Gah.
>
> Here's the entire test case:
>
> <iframe></iframe>
> <script>
>      window.onload = function() {
>        window.onerror = function(msg, file, line) {
>          alert('Parent handler: ' + msg + " " + file + " " + line);
>        }
>        frames[0].onerror = function(msg, file, line) {
>          alert('Subframe handler: ' + msg + " " + file + " " + line);
>        }
>        frames[0].setTimeout(function() { throw "oops"; }, 100);
>      }
> </script>

Thanks.

>> Do browsers use the script's origin per spec, or do they use the
>> function's global object's document's origin (for the purpose of
>> tainting the arguments)?
>
> This isn't even about origins and tainting so far; everything here is  
> same-origin.  It's purely about which onerror gets called.

Yes, I understand that. I was just taking it a step further. I've now  
tested it:

<!doctype html>
<script>
document.domain = 'example.org';
onload=function(){
   onerror=function(a,b,c){alert('parent: '+[a,b,c].join(' '));};
   frames[0].onerror=function(){alert('child: '+[a,b,c].join(' '));};
   frames[0].setTimeout(function(){ throw 'oops' }, 0);
};
</script>
parent<br>
<iframe src='http://www.example.org/child.html'></iframe>

<!doctype html>
<script>
document.domain = 'example.org';
</script>
child

Results:
Opera and Chrome use child and taint (alert says "child: Script error.   
0").
Firefox uses child taints the url and line arguments but not the message  
argument (alert says "child: uncaught exception: oops  0").
IE8 uses parent and doesn't taint (alert says "parent: Exception thrown  
and not caught http://example.org/001.html 7").

I also tested the same as the above but with a string argument to  
setTimeout with a syntax error.

Results:
Opera uses child and taints (alert says "child: Script error.  0").
Firefox and Chrome use child and don't taint (alert says "child:  
SyntaxError: syntax error http://example.org/002.html 7" and "child:  
Uncaught SyntaxError: Unexpected token )  1", respectively).
IE8 doesn't invoke either onerror handler but shows a "broken script" icon  
in the status bar (and attributes the error to child.html).

-- 
Simon Pieters
Opera Software

From dveditz at mozilla.com  Tue Nov 13 08:04:16 2012
From: dveditz at mozilla.com (Dan Veditz)
Date: Tue, 13 Nov 2012 08:04:16 -0800
Subject: [whatwg] URL: file: URLs
In-Reply-To: <509137EC.2090509@smedbergs.us>
References: <CADnb78jJwxgLi4fn-DOKqbu4odSfv1_tCs9WzqEGg2Vpzz4nKw@mail.gmail.com>
	<508D70AA.4020802@mit.edu>
	<CADnb78jgYh_2VQ6x3xi_Y=EdOmBG-7T4DekvnMBJ1r+x1whANA@mail.gmail.com>
	<508E8F03.4090504@mit.edu>
	<CADnb78hS8eLzmwjURkwXAs3jh_qKgTu-7UsObmkfUiQ+A9Wj7Q@mail.gmail.com>
	<508E9F91.4090109@mit.edu>
	<CADnb78hDtjnKe+aK=9d3MjG=FzLV6Hy4hTAUti_nf9BUhbwm-g@mail.gmail.com>
	<op.wm0mrgfl2q99of@coruscant> <509137EC.2090509@smedbergs.us>
Message-ID: <50A26F80.7030002@mozilla.com>

On 10/31/12 7:38 AM, Benjamin Smedberg wrote:
> On 10/30/2012 7:41 PM, Jo?o Eiras wrote:
>>
>>
>> I currently do not have Windows to test but I think I recall IE (or
>> Opera?) opening file://server/share if there was a network share at
>> \\server\share
> Firefox has considered and rejected that kind of proposal for security
> reasons. I can't find the bug right now, but I suspect that we would not
> implement that feature even if it were specced.

On Windows Firefox file:////server/path works, though. After the initial 
two slashes are satisfied we take "//server/path" as the path and hand 
it off to the OS which happily treats that as a UNC path.

-Dan Veditz

From bzbarsky at MIT.EDU  Tue Nov 13 09:19:18 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 13 Nov 2012 09:19:18 -0800
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <op.wnpma8oridj3kv@simons-macbook-pro-2.local>
References: <50A0C798.30005@mit.edu>
	<op.wnnxt6i4idj3kv@simons-macbook-pro-2.local>
	<50A12E00.3090404@mit.edu>
	<op.wnpma8oridj3kv@simons-macbook-pro-2.local>
Message-ID: <50A28116.5000504@mit.edu>

On 11/13/12 3:31 AM, Simon Pieters wrote:
> onload=function(){
>    onerror=function(a,b,c){alert('parent: '+[a,b,c].join(' '));};
>    frames[0].onerror=function(){alert('child: '+[a,b,c].join(' '));};
>    frames[0].setTimeout(function(){ throw 'oops' }, 0);
> };
...
> Opera and Chrome use child and taint (alert says "child: Script error.
> 0").

OK.

> Firefox uses child taints the url and line arguments but not the message
> argument (alert says "child: uncaught exception: oops  0").

Actually, Firefox is not tainting anything here.  A manually thrown 
string exception like that in Spidermonkey just seems to not have a url 
and line number attached to it.

I believe right now Gecko uses the effective script origin for 
determining whether to taint, so in your case the two pages are actually 
same-origin for tainting purposes in Gecko.

> IE8 uses parent and doesn't taint (alert says "parent: Exception thrown
> and not caught http://example.org/001.html 7").

Indeed.  I'm working on switching Gecko to using the parent in this case 
(and still not tainting, of course).

> I also tested the same as the above but with a string argument to
> setTimeout with a syntax error.

This one is simpler in terms of which error handler to use, because the 
string is compiled in the child to start with.  Though I agree it's very 
interesting for tainting purposes!

What does Opera base its tainting decision on here, exactly?  The actual 
origin of the script that made the setTimeout call (as opposed to the 
origin it has due to being loaded by some web page)?  Or just its page's 
origin?  Or does it track origins on individual strings?

-Boris

From zzzzbov at gmail.com  Tue Nov 13 09:25:37 2012
From: zzzzbov at gmail.com (Tim Leverett)
Date: Tue, 13 Nov 2012 12:25:37 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
Message-ID: <CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>

> Explicit author markup would make such a task so much easier.

Only if every author marked up their code correctly. If some authors use
incorrect markup, then an algorithm would still be necessary for
determining if each usage was correct.

On Tue, Nov 13, 2012 at 5:11 AM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> By random chance, I just stumbled across this GitHub tool:
> https://github.com/visualrevenue/reporter
>
> It provides another heuristic approach - different from Scooby-Doo -  to
> determining what is the main content on a page. This is from a journalist's
> point of view and it is using a scoring and evaluation algorithm.
>
> I'm sure a lot of other people had to solve this problem as well and have
> done so in their own special way. Explicit author markup would make such a
> task so much easier.
>
> Regards,
> Silvia.
>
>
> On Tue, Nov 13, 2012 at 11:53 AM, Silvia Pfeiffer <
> silviapfeiffer1 at gmail.com
> > wrote:
>
> > On Tue, Nov 13, 2012 at 5:26 AM, Jens O. Meiert <jens at meiert.com> wrote:
> >
> >> Should <main> be optional or required?
> >>
> >
> >> I?d deem an optional <main> to be nonsense because it suggests
> >> documents are inherently without goal, or focus.
> >>
> >> I?d deem a required <main> to be nonsense because we already have an
> >> (implied) <body> element, and because element proliferation doesn?t
> >> work in anyone?s favor.
> >>
> >
> > I can imagine it to become "required", if we mean by that that the
> > browsers will need to parse a page and either find a <main> element or
> > determine heuristically with the Scooby-Doo algorithm which part of the
> > page is actually the main part and then add that to its DOM. Since we
> have
> > the Scooby-Doo algorithm, we have a means to stay backwards compatible.
> >
> >
> > That <body> essentially means <main> always seemed reasonable to me.
> >> There are plenty of options for authors to add styling hooks if they
> >> need any, including <div role=main>.
> >
> >
> > You are correct - there is no need for this for styling. However, <main>
> > is actually not for styling, but to provide a direct markup of the
> > *semantically* main piece of content on the page. A Scooby-Doo algorithm
> > can only heuristically determine what that is - with <main> the Web Dev
> > gets an actual vehicle to point their finger explicitly rather than
> > implicitly saying in a hand-wavy manner that it's what remains if you
> take
> > away all this other stuff (that is: if we're lucky and that "other stuff"
> > has actually been marked up).
> >
> > Silvia.
> >
>

From ian at hixie.ch  Tue Nov 13 09:37:38 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Nov 2012 17:37:38 +0000 (UTC)
Subject: [whatwg] Including
In-Reply-To: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>
References: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>
Message-ID: <Pine.LNX.4.64.1211131725150.15000@ps20323.dreamhostps.com>

On Tue, 13 Nov 2012, Mark Nottingham wrote:
> 
> I've maintained a little library for a while that does inclusion:
>   https://github.com/mnot/hinclude
>   http://mnot.github.com/hinclude/
> 
> It's used in a few different places, and is now part of Symfony 
> <http://symfony.com>, apparently.
> 
> Besides the obvious issue of "should HTML5 have an inclusion tag?", 
> something else has come up.

(For what it's worth, inclusion in HTML is done using <iframe seamless>.)

> Right now, hinclude uses an XML namespace (hx:) to introduce a new tag.

In application/xhtml+xml (XML), this is and has always been non-conforming 
HTML (in the same sense that any non-HTML vocabulary is not HTML), and 
will continue to work exactly as it does today indefinitely.

In text/html, this is and has always been non-conforming (in the same 
sense that any bogus syntax or tag name is non-conforming), and will 
continue to work exactly as it does today indefinitely.

Note that in XML and HTML these conformance errors are treated very 
differently (in particular, the element ends up in the HTML namespace in 
text/html, and in its own namespace in XML).

> This was pretty widely tested to be interoperable way back, but AIUI 
> that option is going away (whatever that means) in HTML5.

Nothing is changing in terms of how it is to be interpreted by browsers.

It's definitely not a recommended syntax, though, as it results in such 
divergent DOMs depending on whether it's used in HTML or XML.

(Another dodgy part of this feature, from a conformance perspective, is 
the include files themselves. They seem to be in a proprietary format 
derived from HTML, not HTML, which has all kinds of implications on where 
hinclude can be used and where it can't and what would happen with 
handling any errors in the includes, and so forth. Also, the script 
completely ignores the Content-Type of these files.)

> It's been suggested <https://github.com/mnot/hinclude/issues/13> that a 
> data-* attribute on div could be used here, but reading the description 
> there, I'm not so sure:
> 
> "[T]hese attributes are intended for use by the site's own scripts, and 
> are not a generic extension mechanism for publicly-usable metadata."
> 
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes>
> 
> hinclude is intended to be visible to software beyond the site's own 
> scripts.

What else is it intended to be used by?

> So, what's the appropriate thing to do here? Keep on using hx:include 
> (after all, it works)? use data-include or similar? Or?

Appropriate in what sense?

From jackalmage at gmail.com  Tue Nov 13 09:49:08 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 13 Nov 2012 09:49:08 -0800
Subject: [whatwg] Including
In-Reply-To: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>
References: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>
Message-ID: <CAAWBYDB+9TV+7eDOm-iOwZYSjqd7WGZDmJW7TeqKKAUNv0j0Og@mail.gmail.com>

On Mon, Nov 12, 2012 at 10:41 PM, Mark Nottingham <mnot at mnot.net> wrote:
> I've maintained a little library for a while that does inclusion:
>   https://github.com/mnot/hinclude
>   http://mnot.github.com/hinclude/
>
> It's used in a few different places, and is now part of Symfony <http://symfony.com>, apparently.
>
> Besides the obvious issue of "should HTML5 have an inclusion tag?", something else has come up.
>
> Right now, hinclude uses an XML namespace (hx:) to introduce a new tag. This was pretty widely tested to be interoperable way back, but AIUI that option is going away (whatever that means) in HTML5.

Namespaces have always been and will always be fine in the XHTML
serialization.  They have never been and will never be fine in the
HTML serialization.  Fake namespace prefixes "work" to some extent in
the HTML serialization, but you're better off using a dash instead of
a colon - you'll get more or less the same DOM, but saner, and it'll
work the same between the two serializations.

> It's been suggested <https://github.com/mnot/hinclude/issues/13> that a data-* attribute on div could be used here, but reading the description there, I'm not so sure:
>
> "[T]hese attributes are intended for use by the site's own scripts, and are not a generic extension mechanism for publicly-usable metadata."
>
> <http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes>
>
> hinclude is intended to be visible to software beyond the site's own scripts. So, what's the appropriate thing to do here? Keep on using hx:include (after all, it works)? use data-include or similar? Or?

No, if it's included in the page, it's "the site's own scripts".  That
line is meant to exclude data-* attributes from being used to pass
information to crawlers/browsers/extensions/etc, so that the use of
data-* is guaranteed to always be safe for a site author, without any
unintended side effects.

If you intend this to be parsed by server-side software, you move into
grayer territory.  If it's really personal scripts, fine.  If it's
meant to be an Apache extension, not fine, for the same reason as
above.

~TJ

From eoconnor at apple.com  Tue Nov 13 13:49:32 2012
From: eoconnor at apple.com (Edward O'Connor)
Date: Tue, 13 Nov 2012 13:49:32 -0800
Subject: [whatwg] hidden="" should be "display:none !important" in the UA
	stylesheet
Message-ID: <m2txst8977.fsf@eoconnor.apple.com>

Hi,

I don't recall if this was in person or in email, but I think Tab made a
compelling argument in favor of changing the implementation of hidden=""
to be

[hidden] {
    display: none !important;
  }

in the UA stylesheet.

Consider a bunch of thingies, represented in the DOM with a pile of
<div>s. Some of them are hidden.

These thingies are flexboxes:

.thing {
    display: flex;
  }

As things stand now, all of the thingies are visible, including the ones
the author intended to remain hidden. This is really unfortunate.

Ted

From jackalmage at gmail.com  Tue Nov 13 14:18:30 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 13 Nov 2012 14:18:30 -0800
Subject: [whatwg] hidden="" should be "display:none !important" in the
	UA stylesheet
In-Reply-To: <m2txst8977.fsf@eoconnor.apple.com>
References: <m2txst8977.fsf@eoconnor.apple.com>
Message-ID: <CAAWBYDDnNW4Po0S=k0pLj5oMmQiLVqse=fXw2EJe9Rgw_+3d8w@mail.gmail.com>

On Tue, Nov 13, 2012 at 1:49 PM, Edward O'Connor <eoconnor at apple.com> wrote:
> Hi,
>
> I don't recall if this was in person or in email, but I think Tab made a
> compelling argument in favor of changing the implementation of hidden=""
> to be
>
>   [hidden] {
>     display: none !important;
>   }
>
> in the UA stylesheet.

As a further bit of info, the UA-important level is defined in the
Cascade module at <http://dev.w3.org/csswg/css3-cascade/#cascade>.
It's higher than everything except Transitions (and maybe Animations,
depending on the browser right now, but that'll settle down soonish).
This means that it's impossible for author-level code to override the
property, but I think that's what the correct and desirable behavior
is for this.

~TJ

From ian at hixie.ch  Tue Nov 13 14:38:20 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 13 Nov 2012 22:38:20 +0000 (UTC)
Subject: [whatwg] hidden="" should be "display:none !important" in the
 UA stylesheet
In-Reply-To: <m2txst8977.fsf@eoconnor.apple.com>
References: <m2txst8977.fsf@eoconnor.apple.com>
Message-ID: <Pine.LNX.4.64.1211132233150.15000@ps20323.dreamhostps.com>

On Tue, 13 Nov 2012, Edward O'Connor wrote:
> 
> I don't recall if this was in person or in email, but I think Tab made a 
> compelling argument in favor of changing the implementation of hidden="" 
> to be
> 
>   [hidden] {
>     display: none !important;
>   }
> 
> in the UA stylesheet.

It's a non-starter (assuming !important in the UA style sheet means that 
it cascades after the !important user sheet), because it means that you 
can't change [hidden] from being implemented using 'display' to being 
implemented using 'opacity' or some similar solution, which you typically 
want for transitions to work well.

> Consider a bunch of thingies, represented in the DOM with a pile of
> <div>s. Some of them are hidden.
> 
>   <div id=thing0 class=thing>...</div>
>   <div id=thing1 class=thing>...</div>
>   ...
>   <div id=thing46 class=thing>...</div>
>   <div id=thing47 class=thing hidden>...</div>
>   <div id=thing48 class=thing>...</div>
>   ...
>   <div id=thing84 class=thing>...</div>
>   <div id=thing85 class=thing hidden>...</div>
>   <div id=thing86 class=thing>...</div>
>   ...
>   <div id=thingN class=thing>...</div>
> 
> These thingies are flexboxes:
> 
>   .thing {
>     display: flex;
>   }

You just have to write .thing:not([hidden]), or have an explicit [hidden] 
rule. It's not a big deal.

It's like how if you say

* { font: inherit; }

...you break <pre> and <h1>. It's not a big deal, you just set the fonts 
on those too.

The better solution would be for us to cascade the display type separately 
from the rendering tree inclusion/exclusion decision, but that boat sailed 
a long time ago.

(You get similar problems e.g. with:

strong { text-decoration: blink; }
   .thing { text-decoration: underline; }

<strong>...</strong>
   <span class="thing">...</span>
   <strong class="thing">...</strong> -- oops

...here the last one cascades unexpectedly because orthogonal decisions 
are being cascaded together.)

From mnot at mnot.net  Tue Nov 13 15:04:21 2012
From: mnot at mnot.net (Mark Nottingham)
Date: Wed, 14 Nov 2012 10:04:21 +1100
Subject: [whatwg] Including
In-Reply-To: <Pine.LNX.4.64.1211131725150.15000@ps20323.dreamhostps.com>
References: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>
	<Pine.LNX.4.64.1211131725150.15000@ps20323.dreamhostps.com>
Message-ID: <C8DFA5F2-928B-4616-BF68-3CA778B5161A@mnot.net>

On 14/11/2012, at 4:37 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 13 Nov 2012, Mark Nottingham wrote:
>> 
>> I've maintained a little library for a while that does inclusion:
>>  https://github.com/mnot/hinclude
>>  http://mnot.github.com/hinclude/
>> 
>> It's used in a few different places, and is now part of Symfony 
>> <http://symfony.com>, apparently.
>> 
>> Besides the obvious issue of "should HTML5 have an inclusion tag?", 
>> something else has come up.
> 
> (For what it's worth, inclusion in HTML is done using <iframe seamless>.)

Ah. Does that work with older browsers (from the 2005 era onwards)?

>> This was pretty widely tested to be interoperable way back, but AIUI 
>> that option is going away (whatever that means) in HTML5.
> 
> Nothing is changing in terms of how it is to be interpreted by browsers.

Ack; thx.

> It's definitely not a recommended syntax, though, as it results in such 
> divergent DOMs depending on whether it's used in HTML or XML.

I see.

> (Another dodgy part of this feature, from a conformance perspective, is 
> the include files themselves. They seem to be in a proprietary format 
> derived from HTML, not HTML, which has all kinds of implications on where 
> hinclude can be used and where it can't and what would happen with 
> handling any errors in the includes, and so forth. Also, the script 
> completely ignores the Content-Type of these files.)

Yes.

>> It's been suggested <https://github.com/mnot/hinclude/issues/13> that a 
>> data-* attribute on div could be used here, but reading the description 
>> there, I'm not so sure:
>> 
>> "[T]hese attributes are intended for use by the site's own scripts, and 
>> are not a generic extension mechanism for publicly-usable metadata."
>> 
>> <http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#embedding-custom-non-visible-data-with-the-data-*-attributes>
>> 
>> hinclude is intended to be visible to software beyond the site's own 
>> scripts.
> 
> What else is it intended to be used by?

Mumble. The intent was that browsers would be able to process it directly without the JS, and that (for example) search engine spiders would be able to recognise and process it (since it's uniquely identified by the namespace). However, that was in ~2005; now, it's obvious that JS is pretty much required for browsing, and search engines just use a headless browser.

Some people might also want to process it server-side or in intermediaries (a la ESI - <http://en.wikipedia.org/wiki/Edge_Side_Includes>), which is used surprisingly often.

>> So, what's the appropriate thing to do here? Keep on using hx:include 
>> (after all, it works)? use data-include or similar? Or?
> 
> Appropriate in what sense?

Well, it works now, so I'm happy to leave it as is. However, if there were an argument to move to a different syntax that improved interoperability / forward compatibility, I'd probably add a mode where it worked that way too.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

From silviapfeiffer1 at gmail.com  Tue Nov 13 16:03:09 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 14 Nov 2012 11:03:09 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
Message-ID: <CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>

On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett <zzzzbov at gmail.com> wrote:

> > Explicit author markup would make such a task so much easier.
>
> Only if every author marked up their code correctly. If some authors use
> incorrect markup, then an algorithm would still be necessary for
> determining if each usage was correct.
>

Hope you're not just trolling.

>From a browser perspective, if there is one <main> element and it sits
within <body>, that would be sufficiently correct.

Whether it's semantically correct for a particular application, that's not
something the HTML spec should or could deal with. We don't protect people
from putting the wrong text in tags - not in microdata, not in <article> or
anywhere else. An application may care - or they may trust the author and
if the author cares enough, they will fix up their markup if it doesn't
achieve the right goal.

But I'm sure you were just trolling... ;-)

Cheers,
Silvia.

From ian at hixie.ch  Tue Nov 13 16:09:18 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Nov 2012 00:09:18 +0000 (UTC)
Subject: [whatwg] Including
In-Reply-To: <C8DFA5F2-928B-4616-BF68-3CA778B5161A@mnot.net>
References: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>
	<Pine.LNX.4.64.1211131725150.15000@ps20323.dreamhostps.com>
	<C8DFA5F2-928B-4616-BF68-3CA778B5161A@mnot.net>
Message-ID: <Pine.LNX.4.64.1211140004060.15000@ps20323.dreamhostps.com>

On Wed, 14 Nov 2012, Mark Nottingham wrote:
> On 14/11/2012, at 4:37 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Tue, 13 Nov 2012, Mark Nottingham wrote:
> > 
> > (For what it's worth, inclusion in HTML is done using <iframe 
> > seamless>.)
> 
> Ah. Does that work with older browsers (from the 2005 era onwards)?

No, it doesn't reliably work in today's browsers, even.

> >> hinclude is intended to be visible to software beyond the site's own 
> >> scripts.
> > 
> > What else is it intended to be used by?
> 
> Mumble. The intent was that browsers would be able to process it 
> directly without the JS, and that (for example) search engine spiders 
> would be able to recognise and process it (since it's uniquely 
> identified by the namespace).

If it's intended to be implemented by user agents, then it should just be 
part of HTML (either specced in the HTML spec, or a separate spec, e.g. 
the way that the HTML Editing APIs are specified in a separate spec). No 
need for prefixes or anything.

> However, that was in ~2005; now, it's obvious that JS is pretty much 
> required for browsing, and search engines just use a headless browser.

If it's only intended for scripts in the page, then data-* attributes are 
the intended framework for the solution.

> Some people might also want to process it server-side or in 
> intermediaries (a la ESI - 
> <http://en.wikipedia.org/wiki/Edge_Side_Includes>), which is used 
> surprisingly often.

If it's not exposed to the client, then it should just be a language on 
top of HTML, like PHP or SSIs, which is irrelevant to HTML clients.

> >> So, what's the appropriate thing to do here? Keep on using hx:include 
> >> (after all, it works)? use data-include or similar? Or?
> > 
> > Appropriate in what sense?
> 
> Well, it works now, so I'm happy to leave it as is. However, if there 
> were an argument to move to a different syntax that improved 
> interoperability / forward compatibility, I'd probably add a mode where 
> it worked that way too.

If it works, then I'd just leave it.

From jmuizelaar at mozilla.com  Tue Nov 13 16:46:38 2012
From: jmuizelaar at mozilla.com (Jeff Muizelaar)
Date: Tue, 13 Nov 2012 16:46:38 -0800
Subject: [whatwg] [canvas] Proposal isPointInStroke(x, y)
Message-ID: <254F3EC3-38AE-4451-921E-02C081968083@mozilla.com>

We have recently implemented isPointInStroke(x,y) in Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=803124).
This is a parallel to isPointInPath(x,y) and returns true if the point is inside the area contained by the stroking of a path.
It was easily implemented on top of Direct2D, Cairo, Skia, and CoreGraphics and shouldn't be difficult for other systems.

We implemented this to help support functionality needed for shumway (flash on html)

-Jeff

From glenn at zewt.org  Tue Nov 13 16:59:41 2012
From: glenn at zewt.org (Glenn Maynard)
Date: Tue, 13 Nov 2012 18:59:41 -0600
Subject: [whatwg] hidden="" should be "display:none !important" in the
	UA stylesheet
In-Reply-To: <Pine.LNX.4.64.1211132233150.15000@ps20323.dreamhostps.com>
References: <m2txst8977.fsf@eoconnor.apple.com>
	<Pine.LNX.4.64.1211132233150.15000@ps20323.dreamhostps.com>
Message-ID: <CABirCh_rTXBOiKoG_fG=QfDa6mWMWQGE7n1LDAbO+TUJNAfw-Q@mail.gmail.com>

On Tue, Nov 13, 2012 at 4:38 PM, Ian Hickson <ian at hixie.ch> wrote:

>  You just have to write .thing:not([hidden]), or have an explicit [hidden]
> rule. It's not a big deal.
>

This is a cumbersome, hackish workaround.  I shouldn't have to care about
whether an element might have its @hidden property set when I set an
element to inline-block, and I shouldn't need to hack up my CSS when I hide
an element.

The better solution would be for us to cascade the display type separately
> from the rendering tree inclusion/exclusion decision, but that boat sailed
> a long time ago.
>

Surely nothing prevents adding a CSS property, eg. "shown: no", which takes
precedence over display when set to "no" and does nothing when set to
"yes".  It's probably too late to change @hidden to use it, though maybe
not; it would probably break a roughly equal number of sites as the change
proposed here would.

-- 
Glenn Maynard

From ian at hixie.ch  Tue Nov 13 17:34:57 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Nov 2012 01:34:57 +0000 (UTC)
Subject: [whatwg] hidden="" should be "display:none !important" in the
 UA stylesheet
In-Reply-To: <CABirCh_rTXBOiKoG_fG=QfDa6mWMWQGE7n1LDAbO+TUJNAfw-Q@mail.gmail.com>
References: <m2txst8977.fsf@eoconnor.apple.com>
	<Pine.LNX.4.64.1211132233150.15000@ps20323.dreamhostps.com>
	<CABirCh_rTXBOiKoG_fG=QfDa6mWMWQGE7n1LDAbO+TUJNAfw-Q@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211140129200.15000@ps20323.dreamhostps.com>

On Tue, 13 Nov 2012, Glenn Maynard wrote: k
> On Tue, Nov 13, 2012 at 4:38 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > You just have to write .thing:not([hidden]), or have an explicit 
> > [hidden] rule. It's not a big deal.
> 
> This is a cumbersome, hackish workaround.

To be honest, in practice I almost always have a rule for [hidden] because 
I rarely want it to use 'display: none' anyway. So I don't really agree 
that it's hackish or cumbersome, at least not in my case.

> I shouldn't have to care about whether an element might have its @hidden 
> property set when I set an element to inline-block, and I shouldn't need 
> to hack up my CSS when I hide an element.

That's like saying you shouldn't have to care whether a form control is 
disabled when you set its color, or whether a link is visited when you set 
its color, or whether a <details> or <dialog> element is open when you set 
its dimensions, or what the rel="" value on a link is when you set its 
cursor, or various other similar cases.

> > The better solution would be for us to cascade the display type 
> > separately from the rendering tree inclusion/exclusion decision, but 
> > that boat sailed a long time ago.
> 
> Surely nothing prevents adding a CSS property, eg. "shown: no", which 
> takes precedence over display when set to "no" and does nothing when set 
> to "yes".  It's probably too late to change @hidden to use it, though 
> maybe not; it would probably break a roughly equal number of sites as 
> the change proposed here would.

I meant the ship had sailed for making 'display' a shorthand, but I guess 
in theory we could still do this. In fact, people periodically say 
display-inner/display-outer should be introduced. This kind of thing, if 
done right, would certainly avoid this particular issue in the future for 
hidden="". Not a quick fix, though.

From kanghaol at oupeng.com  Tue Nov 13 18:30:10 2012
From: kanghaol at oupeng.com (Kang-Hao (Kenny) Lu)
Date: Wed, 14 Nov 2012 10:30:10 +0800
Subject: [whatwg] hidden="" should be "display:none !important" in the
 UA	stylesheet
In-Reply-To: <m2txst8977.fsf@eoconnor.apple.com>
References: <m2txst8977.fsf@eoconnor.apple.com>
Message-ID: <50A30232.2080908@oupeng.com>

There's relevant discussion in Bugzilla too [1].

(12/11/14 5:49), Edward O'Connor wrote:
> I don't recall if this was in person or in email, but I think Tab made a
> compelling argument in favor of changing the implementation of hidden=""
> to be
> 
>   [hidden] {
>     display: none !important;
>   }
> 
> in the UA stylesheet.

Would it be possible to treat this as !important presentation hint so
that it overrides all author-level non-important declarations but not
important ones? So that for Hixie's use cases, you can still do

[hidden] {
    display: block !important;
    opacity: 0;
  }

. This is assuming that Hixie's use cases are not strong and that this
is implementable. All other presentation hints are not !important so
this might indeed not be implementable.

(12/11/14 8:59), Glenn Maynard wrote:
> On Tue, Nov 13, 2012 at 4:38 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>>  You just have to write .thing:not([hidden]), or have an explicit
>> [hidden] rule. It's not a big deal.
>
> This is a cumbersome, hackish workaround.  I shouldn't have to care
> about whether an element might have its @hidden property set when I
> set an element to inline-block, and I shouldn't need to hack up my
> CSS when I hide an element.

The less hackish way is probably to remember to add

[hidden] {
  display: none !important;
}

at the beginning of your stylesheet and remember not to use !important
'display' later. This is pretty much equivalent to the suggestion above.

(12/11/14 8:59), Glenn Maynard wrote:
>> The better solution would be for us to cascade the display type separately
>> from the rendering tree inclusion/exclusion decision, but that boat sailed
>> a long time ago.
> 
> Surely nothing prevents adding a CSS property, eg. "shown: no", which takes
> precedence over display when set to "no" and does nothing when set to
> "yes".  It's probably too late to change @hidden to use it, though maybe
> not; it would probably break a roughly equal number of sites as the change
> proposed here would.

So there's 'display-box: none'[2] in css-display-3, but yes, by the time
browsers ship this property, if browsers ever do, it's probably too late
to change the UA style for [style]. And also, I don't see how this
solves Tab's problem because 'display' expands to 'display-box' too.

(12/11/14 5:49), Edward O'Connor wrote:
> Consider a bunch of thingies, represented in the DOM with a pile of
> <div>s. Some of them are hidden.
> 
> [...]
> 
> These thingies are flexboxes:
> 
>   .thing {
>     display: flex;
>   }

You can do 'display-outside: flex' in the future, but it seems a bit
long and if you actually remember this problem, you should just place

[hidden] {
  display: none !important;
}

at the beginning.

[1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19277
[2] http://dev.w3.org/csswg/css-display-3/#the-display-box

Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/

From robert at ocallahan.org  Tue Nov 13 18:37:34 2012
From: robert at ocallahan.org (Robert O'Callahan)
Date: Tue, 13 Nov 2012 18:37:34 -0800
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
Message-ID: <CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>

On Mon, Nov 12, 2012 at 2:36 PM, Justin Novosad <junov at chromium.org> wrote:

> Any thoughts?
>

We'd have to define what happens when you use subpixel antialiasing
"incorrectly", because we can be pretty sure authors will use it
incorrectly and expect to get interoperable behavior.

Mozilla supports a "mozOpaque" attribute which makes the canvas buffer RGBX
(initialized to solid black) and enables subpixel antialiasing for most
text drawing. That might be enough to address your use-cases.

From zzzzbov at gmail.com  Tue Nov 13 22:21:30 2012
From: zzzzbov at gmail.com (Tim Leverett)
Date: Wed, 14 Nov 2012 01:21:30 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
Message-ID: <CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>

> Hope you're not just trolling

I was just trying to make the point that an algorithmic approach to finding
the main content of a document would still be necessary with or without the
<main> element.

On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett <zzzzbov at gmail.com> wrote:
>
>> > Explicit author markup would make such a task so much easier.
>>
>> Only if every author marked up their code correctly. If some authors use
>> incorrect markup, then an algorithm would still be necessary for
>> determining if each usage was correct.
>>
>
> Hope you're not just trolling.
>
> From a browser perspective, if there is one <main> element and it sits
> within <body>, that would be sufficiently correct.
>
> Whether it's semantically correct for a particular application, that's not
> something the HTML spec should or could deal with. We don't protect people
> from putting the wrong text in tags - not in microdata, not in <article> or
> anywhere else. An application may care - or they may trust the author and
> if the author cares enough, they will fix up their markup if it doesn't
> achieve the right goal.
>
> But I'm sure you were just trolling... ;-)
>
> Cheers,
> Silvia.
>

From faulkner.steve at gmail.com  Wed Nov 14 03:01:41 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Wed, 14 Nov 2012 11:01:41 +0000
Subject: [whatwg] A plea to Hixie to adopt <main>
Message-ID: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>

Hi *Tim*,

> I was just trying to make the point that an algorithmic approach to
finding
> the main content of a document would still be necessary with or without
the
> <main> element.

The same can be said for any of the structural semantic elements, what we
know is that some authors mark up headings, nav, footer, articles etc
incorrectly or not at all.

What we also know is that user agents do not generally implement heuristics
to provide semantic information to users, they rely upon explicit markup to
expose semantic structures to convey meaning and provide navigation of
content.

For example, ARIA landmark roles are now supported in most browsers and
assistive technology and used by browsers for built in mapping of roles for
new HTML structural elements that do not have platform accessibility API
specific roles (most do not).

regards
SteveF

> > > Hope you're not just trolling
> >
> > I was just trying to make the point that an algorithmic approach to
> finding
> > the main content of a document would still be necessary with or without
> the
> > <main> element.
> >
> > ?
> >
> >
> > On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer
> > <silviapfeiffer1 at gmail.com>wrote:
> >
> > > On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett <zzzzbov at gmail.com>
> wrote:
> > >
> > >> > Explicit author markup would make such a task so much easier.
> > >>
> > >> Only if every author marked up their code correctly. If some authors
> use
> > >> incorrect markup, then an algorithm would still be necessary for
> > >> determining if each usage was correct.
> > >>
> > >
> > > Hope you're not just trolling.
> > >
> > > From a browser perspective, if there is one <main> element and it sits
> > > within <body>, that would be sufficiently correct.
> > >
> > > Whether it's semantically correct for a particular application, that's
> not
> > > something the HTML spec should or could deal with. We don't protect
> people
> > > from putting the wrong text in tags - not in microdata, not in
> <article> or
> > > anywhere else. An application may care - or they may trust the author
> and
> > > if the author cares enough, they will fix up their markup if it doesn't
> > > achieve the right goal.
> > >
> > > But I'm sure you were just trolling... ;-)
> > >
> > > Cheers,
> > > Silvia.
> > >
>

<http://www.paciellogroup.com/resources/wat-ie-about.html>

From simonp at opera.com  Wed Nov 14 03:34:37 2012
From: simonp at opera.com (Simon Pieters)
Date: Wed, 14 Nov 2012 12:34:37 +0100
Subject: [whatwg] Spec for handling runtime script errors doesn't seem
 to match reality
In-Reply-To: <50A28116.5000504@mit.edu>
References: <50A0C798.30005@mit.edu>
	<op.wnnxt6i4idj3kv@simons-macbook-pro-2.local>
	<50A12E00.3090404@mit.edu>
	<op.wnpma8oridj3kv@simons-macbook-pro-2.local>
	<50A28116.5000504@mit.edu>
Message-ID: <op.wnrg3zv9idj3kv@simons-macbook-pro-2.local>

On Tue, 13 Nov 2012 18:19:18 +0100, Boris Zbarsky <bzbarsky at mit.edu> wrote:

> On 11/13/12 3:31 AM, Simon Pieters wrote:
>> onload=function(){
>>    onerror=function(a,b,c){alert('parent: '+[a,b,c].join(' '));};
>>    frames[0].onerror=function(){alert('child: '+[a,b,c].join(' '));};
>>    frames[0].setTimeout(function(){ throw 'oops' }, 0);
>> };
> ...
>> Opera and Chrome use child and taint (alert says "child: Script error.
>> 0").
>
> OK.
>
>> Firefox uses child taints the url and line arguments but not the message
>> argument (alert says "child: uncaught exception: oops  0").
>
> Actually, Firefox is not tainting anything here.  A manually thrown  
> string exception like that in Spidermonkey just seems to not have a url  
> and line number attached to it.
>
> I believe right now Gecko uses the effective script origin for  
> determining whether to taint, so in your case the two pages are actually  
> same-origin for tainting purposes in Gecko.
>
>> IE8 uses parent and doesn't taint (alert says "parent: Exception thrown
>> and not caught http://example.org/001.html 7").
>
> Indeed.  I'm working on switching Gecko to using the parent in this case  
> (and still not tainting, of course).
>
>> I also tested the same as the above but with a string argument to
>> setTimeout with a syntax error.
>
> This one is simpler in terms of which error handler to use, because the  
> string is compiled in the child to start with.  Though I agree it's very  
> interesting for tainting purposes!
>
> What does Opera base its tainting decision on here, exactly?  The actual  
> origin of the script that made the setTimeout call (as opposed to the  
> origin it has due to being loaded by some web page)?  Or just its page's  
> origin?  Or does it track origins on individual strings?
>
> -Boris

I asked our implementor to answer this.

[[
Opera compares teh script's URL (the string that gets sent as second  
argument to onerror) with the security context of the document in which  
the onerror handler runs (in my example, basically  
frames[0].location.href).

The script's URL is the URL from which the script's source was fetched  
(the document for inline scripts or <script src="...">). The script's  
source in question is the source that contains the row where the error  
occurred (according to the information we'd send as argument to onerror).

For the case where frames[0].setTimeout is called with a string argument,  
we compile it in the frames[0] context, but send the called script's URL  
as the new script's URL.
]]

HTH

-- 
Simon Pieters
Opera Software

From zzzzbov at gmail.com  Wed Nov 14 07:11:43 2012
From: zzzzbov at gmail.com (Tim Leverett)
Date: Wed, 14 Nov 2012 10:11:43 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
Message-ID: <CAOiS3y7RkLsyP5T+yzMmKwZEJTS8i+qz7p7pWoKhaxza9Q8Xuw@mail.gmail.com>

Steve,

> What we also know is that user agents do not generally implement
heuristics to provide semantic information to users, they rely upon
explicit markup to expose semantic structures to convey meaning and provide
navigation of content.

I am aware of that, but the point I was making was in regard to Silvia's
email about the github visualreference tool that she found.

>From a non-UA standpoint, such as crawling service for a search
engine, heuristics
would still be needed to accurately identify primary content.

So when Silvia said:

> I'm sure a lot of other people had to solve this problem as well and have
done so in their own special way. Explicit author markup would make such a
task so much easier.

I was disagreeing with that point because there's no way to implicitly
trust the author, in the same way that search engines can't trust <meta
name="keywords" />

I probably should have made that all explicit to begin with,
?

On Wed, Nov 14, 2012 at 6:01 AM, Steve Faulkner <faulkner.steve at gmail.com>wrote:

> Hi *Tim*,
>
> > I was just trying to make the point that an algorithmic approach to
> finding
> > the main content of a document would still be necessary with or without
> the
> > <main> element.
>
> The same can be said for any of the structural semantic elements, what we
> know is that some authors mark up headings, nav, footer, articles etc
> incorrectly or not at all.
>
> What we also know is that user agents do not generally implement
> heuristics to provide semantic information to users, they rely upon
> explicit markup to expose semantic structures to convey meaning and provide
> navigation of content.
>
> For example, ARIA landmark roles are now supported in most browsers and
> assistive technology and used by browsers for built in mapping of roles for
> new HTML structural elements that do not have platform accessibility API
> specific roles (most do not).
>
>
> regards
> SteveF
>
>
>
>> > > Hope you're not just trolling
>> >
>> > I was just trying to make the point that an algorithmic approach to
>> finding
>> > the main content of a document would still be necessary with or without
>> the
>> > <main> element.
>> >
>> > ?
>> >
>> >
>> > On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer
>> > <silviapfeiffer1 at gmail.com>wrote:
>> >
>> > > On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett <zzzzbov at gmail.com>
>> wrote:
>> > >
>> > >> > Explicit author markup would make such a task so much easier.
>> > >>
>> > >> Only if every author marked up their code correctly. If some authors
>> use
>> > >> incorrect markup, then an algorithm would still be necessary for
>> > >> determining if each usage was correct.
>> > >>
>> > >
>> > > Hope you're not just trolling.
>> > >
>> > > From a browser perspective, if there is one <main> element and it sits
>> > > within <body>, that would be sufficiently correct.
>> > >
>> > > Whether it's semantically correct for a particular application,
>> that's not
>> > > something the HTML spec should or could deal with. We don't protect
>> people
>> > > from putting the wrong text in tags - not in microdata, not in
>> <article> or
>> > > anywhere else. An application may care - or they may trust the author
>> and
>> > > if the author cares enough, they will fix up their markup if it
>> doesn't
>> > > achieve the right goal.
>> > >
>> > > But I'm sure you were just trolling... ;-)
>> > >
>> > > Cheers,
>> > > Silvia.
>> > >
>>
>
>
>  <http://www.paciellogroup.com/resources/wat-ie-about.html>
>

From junov at chromium.org  Wed Nov 14 08:09:49 2012
From: junov at chromium.org (Justin Novosad)
Date: Wed, 14 Nov 2012 11:09:49 -0500
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
Message-ID: <CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>

On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Mon, Nov 12, 2012 at 2:36 PM, Justin Novosad <junov at chromium.org>wrote:
>
>> Any thoughts?
>>
>
> We'd have to define what happens when you use subpixel antialiasing
> "incorrectly", because we can be pretty sure authors will use it
> incorrectly and expect to get interoperable behavior.
>
> Mozilla supports a "mozOpaque" attribute which makes the canvas buffer
> RGBX (initialized to solid black) and enables subpixel antialiasing for
> most text drawing. That might be enough to address your use-cases.
>
>
On top of that, subpixel antialiasing would have to get turned off if a
rotation or scale (or any transform that breaks pixel alignment), is
applied to the canvas element.

That is an interesting solution but it is still not 100% safe from the
author's perspective, since there are still several use cases that could
cause artifacts (e.g. applying transforms post rasterization) Even with
this feature, it still requires a lot of care to do everything right 100%
of the time.  For example, suppose the page gets zoomed after the canvas
contents were rendered.
Advanced authors will be able to deal with this by triggering a canvas
re-draw, they might even preserve subpixel AA by resizing the canvas and
applying a reciprocal scale to bring the canvas element's effective zoom
back to 1.

Given how 2d canvas currently works, I don't see any killer solution that
would allow subpixel antialiased text without any caveats.
Are there precedents for exposing features with documented caveats?
(excluding caveats that were discovered after the fact)

Anyone with brilliant ideas: please speak up!

Thanks,

-Justin

> Rob
> --
> Jesus called them together and said, ?You know that the rulers of the
> Gentiles lord it over them, and their high officials exercise authority
> over them. Not so with you. Instead, whoever wants to become great among
> you must be your servant, and whoever wants to be first must be your
> slave ? just as the Son of Man did not come to be served, but to serve,
> and to give his life as a ransom for many.? [Matthew 20:25-28]
>
>

From robin at w3.org  Wed Nov 14 08:15:14 2012
From: robin at w3.org (Robin Berjon)
Date: Wed, 14 Nov 2012 17:15:14 +0100
Subject: [whatwg] Including
In-Reply-To: <C8DFA5F2-928B-4616-BF68-3CA778B5161A@mnot.net>
References: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>
	<Pine.LNX.4.64.1211131725150.15000@ps20323.dreamhostps.com>
	<C8DFA5F2-928B-4616-BF68-3CA778B5161A@mnot.net>
Message-ID: <50A3C392.6060302@w3.org>

On 14/11/2012 00:04 , Mark Nottingham wrote:
> On 14/11/2012, at 4:37 AM, Ian Hickson <ian at hixie.ch> wrote:
>> (For what it's worth, inclusion in HTML is done using <iframe seamless>.)
>
> Ah. Does that work with older browsers (from the 2005 era onwards)?

Nope. But if you want something that's future-enabled you could 
transition your library into being a shim for seamless iframes.

That involves more than inclusion though (see 
http://benvinegar.github.com/seamless-talk/) so you should probably 
double-check that seamless is what your use case calls for.

-- 
Robin Berjon - http://berjon.com/ - @robinberjon

From mounir at lamouri.fr  Wed Nov 14 09:20:38 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 14 Nov 2012 17:20:38 +0000
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50A22635.2090900@yahoo.fr>
References: <50A12B1F.1080200@lamouri.fr> <50A22635.2090900@yahoo.fr>
Message-ID: <50A3D2E6.3050609@lamouri.fr>

On 13/11/12 10:51, Nicolas Froidure wrote:
> So making datetime having the behavior of datetime-local does not seem
> to be necessary for consistency. In any case, i think that we still need
> a way to define a datetime in a particular timezone since you cited one
> case in which it make sense.

Having *a* use case doesn't make a feature a must have. Developers can
write this feature themselves and as said, having a browser
implementation isn't going to help them here. It might be the opposite
actually.

> I think that whatever you decide for datetimes, it should always return
> a UTC value with only one format (yyyy-mm-dd hh:mm:ss or
> yyyy-mm-dd-Thh:mm:ssZ) to allow us to threat it the same way  whether it
> is relative to the user timezone or not.

'datetime' should indeed return something like "yyyy-mm-dd hh:mm:ss" so,
there is no timezone involved.

Cheers,
--
Mounir

From mounir at lamouri.fr  Wed Nov 14 09:23:58 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 14 Nov 2012 17:23:58 +0000
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <CAGH7WqEoHmY8636V+ek6vGLLDizA8upiOxhYvOD49u=1=Chxog@mail.gmail.com>
References: <50A12B1F.1080200@lamouri.fr>
	<CAGH7WqEoHmY8636V+ek6vGLLDizA8upiOxhYvOD49u=1=Chxog@mail.gmail.com>
Message-ID: <50A3D3AE.904@lamouri.fr>

On 13/11/12 09:42, TAMURA, Kent wrote:
> The current UI implementations of Opera, iOS, and Chrome-Android spoil the
> HTML standard. Web authors hardly have motivation to use type=datetime.
> They can add 'UTC' text, and their code can append 'Z' to values easily.
> 
> I agree that the type names are not good.  People must think type=datetime
> is a combination of type=date and type=time. It's not too late to rename
> datetime-local to datetime because the number of type=datetime or
> type=datetime-local in the Web is terribly smaller than the number of
> type=date.

Tamura, do you think Webkit/Chrome can do this change?
Gecko/Mozilla would be willing to implement 'datetime' that way and not
implement 'datetime-local' but having other vendors committed to this
change would be helpful and prevent us from going alone in this path.

Cheers,
--
Mounir

From annevk at annevk.nl  Wed Nov 14 10:35:57 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 14 Nov 2012 10:35:57 -0800
Subject: [whatwg] URL: IPv6 parsing and model/serializing
Message-ID: <CADnb78jnyYt1+5SRX7QBzHmo5Ux0K519MfZksmGk6Kobb0A+CA@mail.gmail.com>

IPv6 Parsing:

* Opera does not appear to support IPv4 addresses in the parser, is
that intentional? Putting http://[fd::2.2.3.4]/ in <a> gives protocol
opera: and pathname illegal-url-... href returns the input.
* Chrome supports "IPv4-like" syntax no other browser supports, e.g.
http://[::129.144.52]/ (missing fourth IPv4 component). I do not plan
on allowing that.

IPv6 Model/Serializing:

* All browsers lowercase. http://[FFFF::]/ -> http://[ffff::]/
* Chrome normalizes IPv4 away. I kinda a like that, but wonder if it's
problematic? http://[fD::2.2.3.4]/ -> http://[fd::202:304]/
* Chrome follows http://tools.ietf.org/html/rfc5952#section-4 but no
other browser does. I think it makes sense to follow Chrome here.

Chrome's implementation (except for parsing invalid IPv4) makes a lot
of sense I think as it allows for minimizing what needs to be stored
internally. It only requires a sequence of eight 16-bit components.

Feedback appreciated.

-- 
http://annevankesteren.nl/

From annevk at annevk.nl  Wed Nov 14 10:54:26 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 14 Nov 2012 10:54:26 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CAJE5ia89Wz=bff9v3xHTfMCc2cR47T2a43iEw+KYzbAjwAQcEQ@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<CAJE5ia89Wz=bff9v3xHTfMCc2cR47T2a43iEw+KYzbAjwAQcEQ@mail.gmail.com>
Message-ID: <CADnb78izUBfDvZQ_0ELn6jVjj7sq3UyjTiDVTXyEpWEDFpCe4Q@mail.gmail.com>

On Thu, Nov 8, 2012 at 5:58 PM, Adam Barth <w3c at adambarth.com> wrote:
> On Thu, Nov 8, 2012 at 6:22 AM, Alex Russell <slightlyoff at google.com> wrote:
>>    - "username" and "password" properties are missing
>>    - There aren't any provided comparison functions. I.e., there's no way
>>    to tell if two URL objects reference the same absolute URL, if
>>    one references a path in the same domain, etc.
>
> The notion of "the same absolute URL" is a bit slippery.  It depends
> on how well you understand various URL components (e.g., octal
> encodings of IP addesss).  We could define something, of course, but
> we'd just need to do so carefully.

Yeah, it would be useful to have some use cases and examples here to
work from. E.g. I suspect we may want to have a method at some point
that considers these equal:

http://x/?test&test2
http://x/?test2&test

even though they would always be considered strictly distinct
currently (and some servers reportedly rely on this distinction).

> Yes, the http://url.spec.whatwg.org/#urlquery interface lets you get
> at parsed URL parameters.  I don't think there's currently a way to
> turn them into form data objects, but that would make sense.
>
> We might also want to add a bulk setter that takes a Dictionary.

Concrete suggestions for URLQuery are very much welcome. For behavior too.

get()/getAll() are clear.

set() not so much:
  "?x&y&x=5&y"
  set("x","1")

what happens? Or with set("x", [1,2])? And set("x", [1,2,3]? Idea:

"?x=1&y&y"
  "?x=1&y&x=2&y"
  "?x=1&y&x=2&y&x3"

So set() replaces values in order, removes parameters for which no
values are set, and adds parameters if there are no existing
parameters.

I think that calls for add() as well, which simply appends a
parameter, irrespective of what is there now.

Allowing new FormData(URLQuery) makes sense to me.

> That's covered in step 1 of
> <http://url.spec.whatwg.org/#constructors>.  If there's no explicit
> base, the URL is resolved relative to about:blank.  To me, that seems
> better that implicitly using the document's base URL.  You can always
> supply the document's base URL from document.baseURI if you want.

Yeah, that was my thinking too.

-- 
http://annevankesteren.nl/

From bzbarsky at MIT.EDU  Wed Nov 14 11:05:20 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 14 Nov 2012 11:05:20 -0800
Subject: [whatwg] URL: IPv6 parsing and model/serializing
In-Reply-To: <CADnb78jnyYt1+5SRX7QBzHmo5Ux0K519MfZksmGk6Kobb0A+CA@mail.gmail.com>
References: <CADnb78jnyYt1+5SRX7QBzHmo5Ux0K519MfZksmGk6Kobb0A+CA@mail.gmail.com>
Message-ID: <50A3EB70.1030308@mit.edu>

On 11/14/12 10:35 AM, Anne van Kesteren wrote:
> Chrome's implementation (except for parsing invalid IPv4) makes a lot
> of sense I think as it allows for minimizing what needs to be stored
> internally. It only requires a sequence of eight 16-bit components.

I believe Gecko simply stores the original string (lowercased), modulo 
IDN stuff.  Since this works for both DNS names and IP addresses, a 
requirement that some other representation be stored is actually a bit 
of an implementation annoyance...

-Boris

From w3c at adambarth.com  Wed Nov 14 11:12:50 2012
From: w3c at adambarth.com (Adam Barth)
Date: Wed, 14 Nov 2012 11:12:50 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CADnb78izUBfDvZQ_0ELn6jVjj7sq3UyjTiDVTXyEpWEDFpCe4Q@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<CAJE5ia89Wz=bff9v3xHTfMCc2cR47T2a43iEw+KYzbAjwAQcEQ@mail.gmail.com>
	<CADnb78izUBfDvZQ_0ELn6jVjj7sq3UyjTiDVTXyEpWEDFpCe4Q@mail.gmail.com>
Message-ID: <CAJE5ia_Hoi_uumhjbx75d-0XptKSwuKgkNfF-vioXAP5HJyAdQ@mail.gmail.com>

On Wed, Nov 14, 2012 at 10:54 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Thu, Nov 8, 2012 at 5:58 PM, Adam Barth <w3c at adambarth.com> wrote:
>> On Thu, Nov 8, 2012 at 6:22 AM, Alex Russell <slightlyoff at google.com> wrote:
>>>    - "username" and "password" properties are missing
>>>    - There aren't any provided comparison functions. I.e., there's no way
>>>    to tell if two URL objects reference the same absolute URL, if
>>>    one references a path in the same domain, etc.
>>
>> The notion of "the same absolute URL" is a bit slippery.  It depends
>> on how well you understand various URL components (e.g., octal
>> encodings of IP addesss).  We could define something, of course, but
>> we'd just need to do so carefully.
>
> Yeah, it would be useful to have some use cases and examples here to
> work from. E.g. I suspect we may want to have a method at some point
> that considers these equal:
>
> http://x/?test&test2
> http://x/?test2&test
>
> even though they would always be considered strictly distinct
> currently (and some servers reportedly rely on this distinction).
>
>
>> Yes, the http://url.spec.whatwg.org/#urlquery interface lets you get
>> at parsed URL parameters.  I don't think there's currently a way to
>> turn them into form data objects, but that would make sense.
>>
>> We might also want to add a bulk setter that takes a Dictionary.
>
> Concrete suggestions for URLQuery are very much welcome. For behavior too.
>
> get()/getAll() are clear.
>
> set() not so much:
>   "?x&y&x=5&y"
>   set("x","1")
>
> what happens? Or with set("x", [1,2])? And set("x", [1,2,3]? Idea:
>
>   "?x=1&y&y"
>   "?x=1&y&x=2&y"
>   "?x=1&y&x=2&y&x3"
>
> So set() replaces values in order, removes parameters for which no
> values are set, and adds parameters if there are no existing
> parameters.
>
> I think that calls for add() as well, which simply appends a
> parameter, irrespective of what is there now.

Having multiple parameters with the same name seems like a bit of an
edge case to me.  I wonder if we can get a better API by treating it
as an edge case?  Here's a proposal:

add("foo", "bar") <--- Appends a parameter foo=bar to the existing
query string (even if there's already a parameter foo earlier.)
set({
  "foo": "bar",
  "qux": "baz"
}) <--- Blows away the existing query string and replaces it with
"foo=bar&qux=baz".

In this approach, set() doesn't support having multiple parameters
with the same name.  If you need that, you need to use add().

Adam

> Allowing new FormData(URLQuery) makes sense to me.
>
>
>> That's covered in step 1 of
>> <http://url.spec.whatwg.org/#constructors>.  If there's no explicit
>> base, the URL is resolved relative to about:blank.  To me, that seems
>> better that implicitly using the document's base URL.  You can always
>> supply the document's base URL from document.baseURI if you want.
>
> Yeah, that was my thinking too.
>
>
> --
> http://annevankesteren.nl/

From robert at ocallahan.org  Wed Nov 14 11:51:18 2012
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 14 Nov 2012 11:51:18 -0800
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
Message-ID: <CAOp6jLbE7fB1qkvPgPfxHgRpfPaenndu6S7NnxfofbBqP7Z_Qw@mail.gmail.com>

On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org> wrote:

> On top of that, subpixel antialiasing would have to get turned off if a
> rotation or scale (or any transform that breaks pixel alignment), is
> applied to the canvas element.
>

We don't do that. Anything we could about that would only be partially
effective since a transform could be applied after the canvas has been
drawn into.

That is an interesting solution but it is still not 100% safe from the
> author's perspective, since there are still several use cases that could
> cause artifacts (e.g. applying transforms post rasterization) Even with
> this feature, it still requires a lot of care to do everything right 100%
> of the time.  For example, suppose the page gets zoomed after the canvas
> contents were rendered.
>

Yes.

Given how 2d canvas currently works, I don't see any killer solution that
> would allow subpixel antialiased text without any caveats.
>

We could keep two copies of the canvas buffer: one rendered with subpixel
AA and one without, and use the latter for rendering if we think it might
be resampled. Of course, this isn't going to perform very well.

Are there precedents for exposing features with documented caveats?
> (excluding caveats that were discovered after the fact)
>

Yes, and many of them have been extremely problematic, because Web authors
will ignore the caveats. However, it can be acceptable as long as the bad
behavior is well-defined and implemented consistently across browsers.

From junov at chromium.org  Wed Nov 14 12:48:15 2012
From: junov at chromium.org (Justin Novosad)
Date: Wed, 14 Nov 2012 15:48:15 -0500
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <CAOp6jLbE7fB1qkvPgPfxHgRpfPaenndu6S7NnxfofbBqP7Z_Qw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<CAOp6jLbE7fB1qkvPgPfxHgRpfPaenndu6S7NnxfofbBqP7Z_Qw@mail.gmail.com>
Message-ID: <CABpaAqSHxtMqXNAAGm35cSofEVFBetyFPdECMAyCWt2tA5ZS4g@mail.gmail.com>

On Wed, Nov 14, 2012 at 2:51 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>
> Given how 2d canvas currently works, I don't see any killer solution that
>> would allow subpixel antialiased text without any caveats.
>>
>
> We could keep two copies of the canvas buffer: one rendered with subpixel
> AA and one without, and use the latter for rendering if we think it might
> be resampled. Of course, this isn't going to perform very well.
>

Hmmm... you might be on to something here. Performance may not be that bad
if the buffers are lazily resolved. And if it is an opt-in option, then
everyone is a fast as possible by default.

> Are there precedents for exposing features with documented caveats?
>> (excluding caveats that were discovered after the fact)
>>
>
> Yes, and many of them have been extremely problematic, because Web authors
> will ignore the caveats. However, it can be acceptable as long as the bad
> behavior is well-defined and implemented consistently across browsers.
>

Yeah, it is a slippery slope.

>
>

From robert at ocallahan.org  Wed Nov 14 12:51:16 2012
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 14 Nov 2012 12:51:16 -0800
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <CABpaAqSHxtMqXNAAGm35cSofEVFBetyFPdECMAyCWt2tA5ZS4g@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<CAOp6jLbE7fB1qkvPgPfxHgRpfPaenndu6S7NnxfofbBqP7Z_Qw@mail.gmail.com>
	<CABpaAqSHxtMqXNAAGm35cSofEVFBetyFPdECMAyCWt2tA5ZS4g@mail.gmail.com>
Message-ID: <CAOp6jLYmJbKNc1hzNp46biJuVUZ8WCgv1fjvdWNrRqBhFnGvDQ@mail.gmail.com>

On Wed, Nov 14, 2012 at 12:48 PM, Justin Novosad <junov at chromium.org> wrote:

> On Wed, Nov 14, 2012 at 2:51 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>
>> We could keep two copies of the canvas buffer: one rendered with subpixel
>> AA and one without, and use the latter for rendering if we think it might
>> be resampled. Of course, this isn't going to perform very well.
>>
>
> Hmmm... you might be on to something here. Performance may not be that bad
> if the buffers are lazily resolved.
>

What do you mean "lazily resolved"?

> And if it is an opt-in option, then everyone is a fast as possible by
> default.
>

Yes. If your use-cases are willing to sacrifice some performance for this,
it could work.

From junov at chromium.org  Wed Nov 14 13:14:09 2012
From: junov at chromium.org (Justin Novosad)
Date: Wed, 14 Nov 2012 16:14:09 -0500
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <CAOp6jLYmJbKNc1hzNp46biJuVUZ8WCgv1fjvdWNrRqBhFnGvDQ@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<CAOp6jLbE7fB1qkvPgPfxHgRpfPaenndu6S7NnxfofbBqP7Z_Qw@mail.gmail.com>
	<CABpaAqSHxtMqXNAAGm35cSofEVFBetyFPdECMAyCWt2tA5ZS4g@mail.gmail.com>
	<CAOp6jLYmJbKNc1hzNp46biJuVUZ8WCgv1fjvdWNrRqBhFnGvDQ@mail.gmail.com>
Message-ID: <CABpaAqSj6e+4hSevC34Rvw2WWxVx6V0uhneuDJZ3282zYsEXyw@mail.gmail.com>

On Wed, Nov 14, 2012 at 3:51 PM, Robert O'Callahan <robert at ocallahan.org>wrote:

> On Wed, Nov 14, 2012 at 12:48 PM, Justin Novosad <junov at chromium.org>wrote:
>
>> On Wed, Nov 14, 2012 at 2:51 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
>>
>>> We could keep two copies of the canvas buffer: one rendered with
>>> subpixel AA and one without, and use the latter for rendering if we think
>>> it might be resampled. Of course, this isn't going to perform very well.
>>>
>>
>> Hmmm... you might be on to something here. Performance may not be that
>> bad if the buffers are lazily resolved.
>>
>
> What do you mean "lazily resolved"?
>

There is a recent improvement in Chrome called "deferred 2D canvas
rendering" (enabled by default as of Chrome 23).  It is a mechanism that
records 2d canvas commands during JS execution, and only executes them for
real when the render buffer needs to be resolved (draw to screen,
getImageData, toDataURL, etc.).  If you want to check it out, the guts are
in Skia: SkGPipe is a sort of FIFO for graphics commands, SkDeferredCanvas
is a wrapper that manages the GPipe and automatically flushes it and
applies some command culling optimizations.

So to come back to the problem of with and without subpixel AA buffers: if
rendering is deferred, the non-AA buffer would never get rasterized (and
possibly never even allocated), unless it needs to be.  Obviously there are
practical limitations, for example we cannot store an unlimited stream of
recorded commands, so if the canvas draws indefinitely without ever being
cleared, at some point we have to rasterize the non-AA buffer just so that
we can safely discard the recording data. Also, if at record time the
necessary conditions for subpixel AA are not met, perhaps we just forget
about it.

I admit this is a complex solution for implementors, but it makes the
management of subpixel-AA safety transparent to web authors.

>
>> And if it is an opt-in option, then everyone is a fast as possible by
>> default.
>>
>
> Yes. If your use-cases are willing to sacrifice some performance for this,
> it could work.
>
>
> Rob
> --
> Jesus called them together and said, ?You know that the rulers of the
> Gentiles lord it over them, and their high officials exercise authority
> over them. Not so with you. Instead, whoever wants to become great among
> you must be your servant, and whoever wants to be first must be your
> slave ? just as the Son of Man did not come to be served, but to serve,
> and to give his life as a ransom for many.? [Matthew 20:25-28]
>
>

From robert at ocallahan.org  Wed Nov 14 14:24:46 2012
From: robert at ocallahan.org (Robert O'Callahan)
Date: Wed, 14 Nov 2012 14:24:46 -0800
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <CABpaAqSj6e+4hSevC34Rvw2WWxVx6V0uhneuDJZ3282zYsEXyw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<CAOp6jLbE7fB1qkvPgPfxHgRpfPaenndu6S7NnxfofbBqP7Z_Qw@mail.gmail.com>
	<CABpaAqSHxtMqXNAAGm35cSofEVFBetyFPdECMAyCWt2tA5ZS4g@mail.gmail.com>
	<CAOp6jLYmJbKNc1hzNp46biJuVUZ8WCgv1fjvdWNrRqBhFnGvDQ@mail.gmail.com>
	<CABpaAqSj6e+4hSevC34Rvw2WWxVx6V0uhneuDJZ3282zYsEXyw@mail.gmail.com>
Message-ID: <CAOp6jLbDuvN74qmEuY1rrdT3jcVA7gT6YjTtp-D8A7e74u+49g@mail.gmail.com>

On Wed, Nov 14, 2012 at 1:14 PM, Justin Novosad <junov at chromium.org> wrote:

> I admit this is a complex solution for implementors, but it makes the
> management of subpixel-AA safety transparent to web authors.
>

Yes, that makes sense.

From ian at hixie.ch  Wed Nov 14 14:44:19 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 14 Nov 2012 22:44:19 +0000 (UTC)
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CAJE5ia_Hoi_uumhjbx75d-0XptKSwuKgkNfF-vioXAP5HJyAdQ@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<CAJE5ia89Wz=bff9v3xHTfMCc2cR47T2a43iEw+KYzbAjwAQcEQ@mail.gmail.com>
	<CADnb78izUBfDvZQ_0ELn6jVjj7sq3UyjTiDVTXyEpWEDFpCe4Q@mail.gmail.com>
	<CAJE5ia_Hoi_uumhjbx75d-0XptKSwuKgkNfF-vioXAP5HJyAdQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211142243340.16964@ps20323.dreamhostps.com>

On Wed, 14 Nov 2012, Adam Barth wrote:
> 
> Having multiple parameters with the same name seems like a bit of an
> edge case to me.

<select multiple> is output as multiple names with different values. It's 
also pretty normal to have e.g. a series of checkboxes with different 
values but the same name.

From mnot at mnot.net  Wed Nov 14 16:11:42 2012
From: mnot at mnot.net (Mark Nottingham)
Date: Thu, 15 Nov 2012 11:11:42 +1100
Subject: [whatwg] Including
In-Reply-To: <50A3C392.6060302@w3.org>
References: <A958BA71-FB4D-4C81-BFDE-593D1157E0AE@mnot.net>
	<Pine.LNX.4.64.1211131725150.15000@ps20323.dreamhostps.com>
	<C8DFA5F2-928B-4616-BF68-3CA778B5161A@mnot.net>
	<50A3C392.6060302@w3.org>
Message-ID: <EAC3C852-A385-43A0-AB4C-772F80D35BC0@mnot.net>

On 15/11/2012, at 3:15 AM, Robin Berjon <robin at w3.org> wrote:

> On 14/11/2012 00:04 , Mark Nottingham wrote:
>> On 14/11/2012, at 4:37 AM, Ian Hickson <ian at hixie.ch> wrote:
>>> (For what it's worth, inclusion in HTML is done using <iframe seamless>.)
>> 
>> Ah. Does that work with older browsers (from the 2005 era onwards)?
> 
> Nope. But if you want something that's future-enabled you could transition your library into being a shim for seamless iframes.
> 
> That involves more than inclusion though (see http://benvinegar.github.com/seamless-talk/) so you should probably double-check that seamless is what your use case calls for.

Thanks, Robin - very helpful.

The upside of the seamless approach seems to be that it does the right thing WRT the included content's type, etc. (as Ian mentioned). However, making it work in older browsers looks a lot more involved. Turning my library into a shim for seamless would require code both in the including context and included content, AIUI.

If there's interest in specifying an 'include' tag, I'd be willing to do the work (spec and code), but otherwise it sounds like leaving things as-is is the right thing to do.

Cheers,

--
Mark Nottingham   http://www.mnot.net/

From silviapfeiffer1 at gmail.com  Wed Nov 14 16:23:55 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 15 Nov 2012 11:23:55 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
Message-ID: <CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>

Apologies for misunderstanding - the smiley led me to believe it may not
have been a real concern. I did answer in good faith though, so back to the
concern.

You are absolutely correct that an algorithmic approach would still be
necessary to resolve the situation when <main> is not provided in the same
way that browsers create a <body> tag when it's not provided or a <head>
etc. Scooby-Doo seems both simple enough and appropriate for this.

>> I'm sure a lot of other people had to solve this problem as well and have
>> done so in their own special way. Explicit author markup would make such
a
>> task so much easier.
>
> I was disagreeing with that point because there's no way to implicitly
trust the author, in the same way that search engines can't trust <meta
> name="keywords" />

Are you fundamentally distrusting the author in all semantic markup? Why
then did we introduce <article>, <header>, <nav>, <aside>, <footer> etc
when we can't trust the author to put the correct content in there? I don't
really see the difference.

Cheers,
Silvia.

On Wed, Nov 14, 2012 at 5:21 PM, Tim Leverett <zzzzbov at gmail.com> wrote:

> > Hope you're not just trolling
>
> I was just trying to make the point that an algorithmic approach to
> finding the main content of a document would still be necessary with or
> without the <main> element.
>
> ?
>
>
>
> On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer <
> silviapfeiffer1 at gmail.com> wrote:
>
>> On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett <zzzzbov at gmail.com> wrote:
>>
>>> > Explicit author markup would make such a task so much easier.
>>>
>>> Only if every author marked up their code correctly. If some authors use
>>> incorrect markup, then an algorithm would still be necessary for
>>> determining if each usage was correct.
>>>
>>
>> Hope you're not just trolling.
>>
>> From a browser perspective, if there is one <main> element and it sits
>> within <body>, that would be sufficiently correct.
>>
>> Whether it's semantically correct for a particular application, that's
>> not something the HTML spec should or could deal with. We don't protect
>> people from putting the wrong text in tags - not in microdata, not in
>> <article> or anywhere else. An application may care - or they may trust the
>> author and if the author cares enough, they will fix up their markup if it
>> doesn't achieve the right goal.
>>
>> But I'm sure you were just trolling... ;-)
>>
>> Cheers,
>> Silvia.
>>
>
>

From fredandw at live.com  Wed Nov 14 17:07:30 2012
From: fredandw at live.com (Fred Andrews)
Date: Thu, 15 Nov 2012 01:07:30 +0000
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>,
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>,
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
Message-ID: <BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>

The canvas that scripts draw into could be over-sized with the UA down sampling this to
fit the target size and taking into account the sub-pixel screen layout when doing so.

cheers
Fred

> Date: Wed, 14 Nov 2012 11:09:49 -0500
> From: junov at chromium.org
> To: robert at ocallahan.org
> CC: whatwg at lists.whatwg.org
> Subject: Re: [whatwg] Enabling LCD Text in 2D canvases.
> 
> On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan <robert at ocallahan.org>wrote:
> 
> > On Mon, Nov 12, 2012 at 2:36 PM, Justin Novosad <junov at chromium.org>wrote:
> >
> >> Any thoughts?
> >>
> >
> > We'd have to define what happens when you use subpixel antialiasing
> > "incorrectly", because we can be pretty sure authors will use it
> > incorrectly and expect to get interoperable behavior.
> >
> > Mozilla supports a "mozOpaque" attribute which makes the canvas buffer
> > RGBX (initialized to solid black) and enables subpixel antialiasing for
> > most text drawing. That might be enough to address your use-cases.
> >
> >
> On top of that, subpixel antialiasing would have to get turned off if a
> rotation or scale (or any transform that breaks pixel alignment), is
> applied to the canvas element.
> 
> That is an interesting solution but it is still not 100% safe from the
> author's perspective, since there are still several use cases that could
> cause artifacts (e.g. applying transforms post rasterization) Even with
> this feature, it still requires a lot of care to do everything right 100%
> of the time.  For example, suppose the page gets zoomed after the canvas
> contents were rendered.
> Advanced authors will be able to deal with this by triggering a canvas
> re-draw, they might even preserve subpixel AA by resizing the canvas and
> applying a reciprocal scale to bring the canvas element's effective zoom
> back to 1.
> 
> Given how 2d canvas currently works, I don't see any killer solution that
> would allow subpixel antialiased text without any caveats.
> Are there precedents for exposing features with documented caveats?
> (excluding caveats that were discovered after the fact)
> 
> Anyone with brilliant ideas: please speak up!
> 
> Thanks,
> 
>     -Justin
> 
> 
> > Rob
> > --
> > Jesus called them together and said, ?You know that the rulers of the
> > Gentiles lord it over them, and their high officials exercise authority
> > over them. Not so with you. Instead, whoever wants to become great among
> > you must be your servant, and whoever wants to be first must be your
> > slave ? just as the Son of Man did not come to be served, but to serve,
> > and to give his life as a ransom for many.? [Matthew 20:25-28]
> >
> >

From zzzzbov at gmail.com  Wed Nov 14 17:17:34 2012
From: zzzzbov at gmail.com (Tim Leverett)
Date: Wed, 14 Nov 2012 20:17:34 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
Message-ID: <CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>

> the smiley led me to believe it may not have been a real concern.

I've been using a smiley as my signature for some time now, although I am
new to the whatwg mailing list, so I do understand the confusion.

> Are you fundamentally distrusting the author in all semantic markup?

In some circumstances, yes. Most of the work I've done so far has been in
environments where programmers write code, and editors write content.
Typically the content is via a CMS. If the editor is good but the
programmer is not, the content is still worth having even if its surrounded
by rubbish markup. From a data analytics and processing standpoint, there's
no reason to discard good content just because its held in bad code in the
same way that there's no reason to accept bad content just because its well
formatted.

> Why then did we introduce <article>, <header>, <nav>, <aside>, <footer>
etc when we can't trust the author to put the correct content in there? I
don't really see the difference.

Steve made a good point about user agents being able to tune into semantic
elements for assistive tech. But I would guess (with no data to support my
claim) that most programmers *want* to do things the right way. I find
that, semantically, most of the time most websites are mostly correct.
Headings tend to be in <h#> elements, paragraphs tend to be in <p>
elements, etc. Heuristic analysis of content can take advantage of semantic
markup by giving it a heavier weight than, say...a <div> element, but that
doesn't mean the heuristics are any less complex.

On Wed, Nov 14, 2012 at 7:23 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> Apologies for misunderstanding - the smiley led me to believe it may not
> have been a real concern. I did answer in good faith though, so back to the
> concern.
>
> You are absolutely correct that an algorithmic approach would still be
> necessary to resolve the situation when <main> is not provided in the same
> way that browsers create a <body> tag when it's not provided or a <head>
> etc. Scooby-Doo seems both simple enough and appropriate for this.
>
>
>
> >> I'm sure a lot of other people had to solve this problem as well and
> have
> >> done so in their own special way. Explicit author markup would make
> such a
> >> task so much easier.
> >
> > I was disagreeing with that point because there's no way to implicitly
> trust the author, in the same way that search engines can't trust <meta
> > name="keywords" />
>
> Are you fundamentally distrusting the author in all semantic markup? Why
> then did we introduce <article>, <header>, <nav>, <aside>, <footer> etc
> when we can't trust the author to put the correct content in there? I don't
> really see the difference.
>
> Cheers,
> Silvia.
>
>
>
> On Wed, Nov 14, 2012 at 5:21 PM, Tim Leverett <zzzzbov at gmail.com> wrote:
>
>> > Hope you're not just trolling
>>
>> I was just trying to make the point that an algorithmic approach to
>> finding the main content of a document would still be necessary with or
>> without the <main> element.
>>
>> ?
>>
>>
>>
>> On Tue, Nov 13, 2012 at 7:03 PM, Silvia Pfeiffer <
>> silviapfeiffer1 at gmail.com> wrote:
>>
>>> On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett <zzzzbov at gmail.com> wrote:
>>>
>>>> > Explicit author markup would make such a task so much easier.
>>>>
>>>> Only if every author marked up their code correctly. If some authors
>>>> use incorrect markup, then an algorithm would still be necessary for
>>>> determining if each usage was correct.
>>>>
>>>
>>> Hope you're not just trolling.
>>>
>>> From a browser perspective, if there is one <main> element and it sits
>>> within <body>, that would be sufficiently correct.
>>>
>>> Whether it's semantically correct for a particular application, that's
>>> not something the HTML spec should or could deal with. We don't protect
>>> people from putting the wrong text in tags - not in microdata, not in
>>> <article> or anywhere else. An application may care - or they may trust the
>>> author and if the author cares enough, they will fix up their markup if it
>>> doesn't achieve the right goal.
>>>
>>> But I'm sure you were just trolling... ;-)
>>>
>>> Cheers,
>>> Silvia.
>>>
>>
>>
>

From silviapfeiffer1 at gmail.com  Wed Nov 14 18:52:01 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Thu, 15 Nov 2012 13:52:01 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
Message-ID: <CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>

On Thu, Nov 15, 2012 at 12:17 PM, Tim Leverett <zzzzbov at gmail.com> wrote:

>
> > Are you fundamentally distrusting the author in all semantic markup?
>
> In some circumstances, yes. Most of the work I've done so far has been in
> environments where programmers write code, and editors write content.
> Typically the content is via a CMS. If the editor is good but the
> programmer is not, the content is still worth having even if its surrounded
> by rubbish markup. From a data analytics and processing standpoint, there's
> no reason to discard good content just because its held in bad code in the
> same way that there's no reason to accept bad content just because its well
> formatted.
>
>
> > Why then did we introduce <article>, <header>, <nav>, <aside>, <footer>
> etc when we can't trust the author to put the correct content in there? I
> don't really see the difference.
>
> Steve made a good point about user agents being able to tune into semantic
> elements for assistive tech. But I would guess (with no data to support my
> claim) that most programmers *want* to do things the right way.

I agree.

> I find that, semantically, most of the time most websites are mostly
> correct. Headings tend to be in <h#> elements, paragraphs tend to be in <p>
> elements, etc. Heuristic analysis of content can take advantage of semantic
> markup by giving it a heavier weight than, say...a <div> element, but that
> doesn't mean the heuristics are any less complex.
>

Are you saying we should not introduce a <main> element because where there
is no <main> element we may need to come up with a complex heuristic to
determine where it should have been?

Silvia.

From zzzzbov at gmail.com  Wed Nov 14 20:59:56 2012
From: zzzzbov at gmail.com (Tim Leverett)
Date: Wed, 14 Nov 2012 23:59:56 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
Message-ID: <CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>

> Are you saying we should not introduce a <main> element...

I don't believe I ever said anything about not introducing a
<main>element. I'm very much on the fence about it. I've been trying
to carefully
balance the pros and cons to avoid a biased judgement. Here are some of
what I've come up with.

Pro: Adding a <main> element will provide a semantic element that
developers can use to indicate primary content of a document.
Con: Adding a <main> element adds redundancy to the [role="main"] attribute.
Pro: Adding a <main> element will allow developers to use a format such as:
<body>
  <header />
  <main />
  <footer />
</body>
which tends to be quite clean and understandable (the easier it is to read
code, the easier it is to fix code).
Con: Implementing the <main> element in a backwards compatible manner
requires JavaScript.
Pro: Assistive technologies can use the <main> element as a means to
rapidly navigate to the primary content.
Con: The <main> element can only be used once per page. Pages with multiple
content areas, or fragmented content would need to pick a single content
region as primary, or not use the element. This restriction will likely
cause more confusion than if multiple <main> elements were allowed.
Pro: The <main> element can only be used once per page. This forces the
author to decide exactly where the main focus of the page lies, rather than
relying on assumptions.
Con: The <main> element is supposed to exclude content that is repetitious
across pages, but content is often interspersed with blocks of
advertisements, modules, CTAs and the like.

Personally, I'd rather see <main> be more about marking up content in
general, such as in this example which is invalid given the current state
of the spec:
<article id=1>
  <header />
  <main />
  <footer />
</article>
<article id=2>
  <header />
  <main />
  <footer />
</article>

...although this would probably fit better as a <content> element, and
would require a whole other line of discussion that can wait for another
day.

On Wed, Nov 14, 2012 at 9:52 PM, Silvia Pfeiffer
<silviapfeiffer1 at gmail.com>wrote:

> On Thu, Nov 15, 2012 at 12:17 PM, Tim Leverett <zzzzbov at gmail.com> wrote:
>
>>
>> > Are you fundamentally distrusting the author in all semantic markup?
>>
>> In some circumstances, yes. Most of the work I've done so far has been in
>> environments where programmers write code, and editors write content.
>> Typically the content is via a CMS. If the editor is good but the
>> programmer is not, the content is still worth having even if its surrounded
>> by rubbish markup. From a data analytics and processing standpoint, there's
>> no reason to discard good content just because its held in bad code in the
>> same way that there's no reason to accept bad content just because its well
>> formatted.
>>
>>
>> > Why then did we introduce <article>, <header>, <nav>, <aside>, <footer>
>> etc when we can't trust the author to put the correct content in there? I
>> don't really see the difference.
>>
>> Steve made a good point about user agents being able to tune into
>> semantic elements for assistive tech. But I would guess (with no data to
>> support my claim) that most programmers *want* to do things the right
>> way.
>
>
> I agree.
>
>
>> I find that, semantically, most of the time most websites are mostly
>> correct. Headings tend to be in <h#> elements, paragraphs tend to be in <p>
>> elements, etc. Heuristic analysis of content can take advantage of semantic
>> markup by giving it a heavier weight than, say...a <div> element, but that
>> doesn't mean the heuristics are any less complex.
>>
>
> Are you saying we should not introduce a <main> element because where
> there is no <main> element we may need to come up with a complex heuristic
> to determine where it should have been?
>
> Silvia.
>
>

From dbk at google.com  Wed Nov 14 21:07:22 2012
From: dbk at google.com (David Barrett-Kahn)
Date: Wed, 14 Nov 2012 21:07:22 -0800
Subject: [whatwg] Proposal for a debugging information API
Message-ID: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>

Hi whatwg.  I have a proposal for a new web standard, and would value your
feedback.  This is based on my experiences working on Google Docs, which
has a well developed ability to send crash reports back to the server for
analysis.  We often find these crash reports to be lacking in crucial
information though, because that information is not available on the JS
APIs.

My proposal is to have a class of information which can be made available
to an app only after the display of a generic 'this application has
crashed' dialog, which could be drilled into to show what is being
disclosed, and which of course can be denied.

Good examples of the information in question are the system's precise
hardware and network configuration, what Chrome extensions it has
installed, and perhaps a screenshot of the failed application.

I've fleshed this out in the following document, and would value opinions
on the value of a feature of this kind, and the merits of this particular
approach.

https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk

Thanks!

-Dave

From gphemsley at gmail.com  Wed Nov 14 21:12:56 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Thu, 15 Nov 2012 00:12:56 -0500
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
Message-ID: <CAH4e3M4BwhxmfFebLhKo_78q=d5e_i+dAGZ7VgxPBDxCvdEXDQ@mail.gmail.com>

Recent blog posts that coincidentally may be useful in this discussion:

http://vocamus.net/dave/?p=1532
http://www.twobraids.com/2012/11/socorro-as-service.html

On Thu, Nov 15, 2012 at 12:07 AM, David Barrett-Kahn <dbk at google.com> wrote:

> Hi whatwg.  I have a proposal for a new web standard, and would value your
> feedback.  This is based on my experiences working on Google Docs, which
> has a well developed ability to send crash reports back to the server for
> analysis.  We often find these crash reports to be lacking in crucial
> information though, because that information is not available on the JS
> APIs.
>
> My proposal is to have a class of information which can be made available
> to an app only after the display of a generic 'this application has
> crashed' dialog, which could be drilled into to show what is being
> disclosed, and which of course can be denied.
>
> Good examples of the information in question are the system's precise
> hardware and network configuration, what Chrome extensions it has
> installed, and perhaps a screenshot of the failed application.
>
> I've fleshed this out in the following document, and would value opinions
> on the value of a feature of this kind, and the merits of this particular
> approach.
>
>
> https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk
>
> Thanks!
>
> -Dave
>

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From dbk at google.com  Wed Nov 14 21:26:54 2012
From: dbk at google.com (David Barrett-Kahn)
Date: Wed, 14 Nov 2012 21:26:54 -0800
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <CAH4e3M4BwhxmfFebLhKo_78q=d5e_i+dAGZ7VgxPBDxCvdEXDQ@mail.gmail.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
	<CAH4e3M4BwhxmfFebLhKo_78q=d5e_i+dAGZ7VgxPBDxCvdEXDQ@mail.gmail.com>
Message-ID: <CA+iXHYOUTvsDrgChmMfMy5GxDPECQ0M7WYt+K74SN2yRv7wJAA@mail.gmail.com>

Yes, thanks, these are just the sorts of systems which would be used to
collect this information were it available.  I believe that as it becomes
easier for less well resourced development teams to have crash reporting of
this kind its use will become more widespread, and that it will eventually
become part of the standard toolkit.

-Dave

On Wed, Nov 14, 2012 at 9:12 PM, Gordon P. Hemsley <gphemsley at gmail.com>wrote:

> Recent blog posts that coincidentally may be useful in this discussion:
>
> http://vocamus.net/dave/?p=1532
> http://www.twobraids.com/2012/11/socorro-as-service.html
>
>
> On Thu, Nov 15, 2012 at 12:07 AM, David Barrett-Kahn <dbk at google.com>wrote:
>
>> Hi whatwg.  I have a proposal for a new web standard, and would value your
>> feedback.  This is based on my experiences working on Google Docs, which
>> has a well developed ability to send crash reports back to the server for
>> analysis.  We often find these crash reports to be lacking in crucial
>> information though, because that information is not available on the JS
>> APIs.
>>
>> My proposal is to have a class of information which can be made available
>> to an app only after the display of a generic 'this application has
>> crashed' dialog, which could be drilled into to show what is being
>> disclosed, and which of course can be denied.
>>
>> Good examples of the information in question are the system's precise
>> hardware and network configuration, what Chrome extensions it has
>> installed, and perhaps a screenshot of the failed application.
>>
>> I've fleshed this out in the following document, and would value opinions
>> on the value of a feature of this kind, and the merits of this particular
>> approach.
>>
>>
>> https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk
>>
>> Thanks!
>>
>> -Dave
>>
>
>
>
> --
> Gordon P. Hemsley
> me at gphemsley.org
> http://gphemsley.org/ ? http://gphemsley.org/blog/
>

-- 
-Dave

From ian at hixie.ch  Wed Nov 14 23:23:24 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 15 Nov 2012 07:23:24 +0000 (UTC)
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211150717250.16964@ps20323.dreamhostps.com>

On Wed, 14 Nov 2012, David Barrett-Kahn wrote:
> 
> My proposal is to have a class of information which can be made 
> available to an app only after the display of a generic 'this 
> application has crashed' dialog, which could be drilled into to show 
> what is being disclosed, and which of course can be denied.
> 
> Good examples of the information in question are the system's precise 
> hardware and network configuration, what Chrome extensions it has 
> installed, and perhaps a screenshot of the failed application.

There's basically no way we could ever do this without a lot of user 
opt-in, because of the privacy concerns (a hostile site could embed a 
user's facebook page, trigger a crash to get a screenshot, and then 
scrape the screenshot and compare it to the hardware information to work 
out what device they were using, who they were, etc).

Just having a dialog as you propose here:

> https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk

...would probably not be enough; users can easily be tricked into clicking 
that kind of dialog (e.g. by using misleading domain names, or by having 
them play a game that involves hitting "enter" a lot).

Clearly though this kind of thing would be hugely helpful for debugging. 
My recommendation would be to approach browser vendors directly with the 
proposal and experiment with different ideas to find one that balances 
user concerns with practical results, somewhat as discussed here:

http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

From tobie.langel at gmail.com  Thu Nov 15 01:46:08 2012
From: tobie.langel at gmail.com (Tobie Langel)
Date: Thu, 15 Nov 2012 10:46:08 +0100
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
Message-ID: <CAMK=o4eziZ+7qs-OVgAWiPe89UKD_AqtZ1X4v=R527eVhUDgfA@mail.gmail.com>

On Thu, Nov 15, 2012 at 6:07 AM, David Barrett-Kahn <dbk at google.com> wrote:
> Hi whatwg.  I have a proposal for a new web standard, and would value your
> feedback.  This is based on my experiences working on Google Docs, which
> has a well developed ability to send crash reports back to the server for
> analysis.  We often find these crash reports to be lacking in crucial
> information though, because that information is not available on the JS
> APIs.
>
> My proposal is to have a class of information which can be made available
> to an app only after the display of a generic 'this application has
> crashed' dialog, which could be drilled into to show what is being
> disclosed, and which of course can be denied.
>
> Good examples of the information in question are the system's precise
> hardware and network configuration, what Chrome extensions it has
> installed, and perhaps a screenshot of the failed application.

There is directly related work[1] being included in the WebPerf
WG[2]'s upcoming charter. Given the privacy and fingerprinting
constraints are the same, you should probably bring your suggestions
there.

--tobie
---
[1]: https://docs.google.com/document/d/1Yw_qNMCnGsWQRsdcrifzh_kzFey-ThQ3yp-DmxuJxvg/edit
[2]: http://www.w3.org/2010/webperf/

From faulkner.steve at gmail.com  Thu Nov 15 02:30:41 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Thu, 15 Nov 2012 10:30:41 +0000
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
Message-ID: <CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>

Hi Tim,

> Are you saying we should not introduce a <main> element...
>
> I don't believe I ever said anything about not introducing a
> <main>element. I'm very much on the fence about it. I've been trying
> to carefully
> balance the pros and cons to avoid a biased judgement. Here are some of
> what I've come up with.
>
> Pro: Adding a <main> element will provide a semantic element that
> developers can use to indicate primary content of a document.
> Con: Adding a <main> element adds redundancy to the [role="main"]
> attribute.
>

I don't see why this is a con, if main is mapped to role=main in the
browser it means that authors won't have to. Also adding
aside/article/footer etc adds redundancy to the matching ARIA roles.

> Pro: Adding a <main> element will allow developers to use a format such as:
> <body>
>   <header />
>   <main />
>   <footer />
> </body>
> which tends to be quite clean and understandable (the easier it is to read
> code, the easier it is to fix code).
> Con: Implementing the <main> element in a backwards compatible manner
> requires JavaScript.
>

it is/was the same for any of the new structural elements.

> Pro: Assistive technologies can use the <main> element as a means to
> rapidly navigate to the primary content.
> Con: The <main> element can only be used once per page. Pages with multiple
> content areas, or fragmented content would need to pick a single content
> region as primary, or not use the element. This restriction will likely
> cause more confusion than if multiple <main> elements were allowed.
>

>From the data it does not appear that authors are confused about use of
role=main or the use of semantic id values to designate the main content
area.

Authors do not appear to have an issue with marking up <div id="main"> and
using it once per page.  I think that the restrictions make it easier to
use and understand rather than harder.

> Pro: The <main> element can only be used once per page. This forces the
> author to decide exactly where the main focus of the page lies, rather than
> relying on assumptions.
> Con: The <main> element is supposed to exclude content that is repetitious
> across pages, but content is often interspersed with blocks of
> advertisements, modules, CTAs and the like.

authors can use more granular elements within the <main> element, to
structure content, example:

<main>
<article/>
<aside> advertisements</aside>
<article/>
</main>

can you provide some examples of the sort of pages you are talking about?
It would be useful.

>
> Personally, I'd rather see <main> be more about marking up content in
> general, such as in this example which is invalid given the current state
> of the spec:
> <article id=1>
>   <header />
>   <main />
>   <footer />
> </article>
> <article id=2>
>   <header />
>   <main />
>   <footer />
> </article>
>
> ...although this would probably fit better as a <content> element, and
> would require a whole other line of discussion that can wait for another
> day.
>

Indeed, this appears to be something different from what the <main> element
is designed for.

Regards
SteveF

From ian at invigoreight.com  Thu Nov 15 03:27:31 2012
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 15 Nov 2012 19:27:31 +0800
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
	<CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
Message-ID: <CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>

On Thu, Nov 15, 2012 at 12:59 PM, Tim Leverett <zzzzbov at gmail.com> wrote:

> Personally, I'd rather see <main> be more about marking up content in
> general, such as in this example which is invalid given the current state
> of the spec:
> <article id=1>
>   <header />
>   <main />
>   <footer />
> </article>
> <article id=2>
>   <header />
>   <main />
>   <footer />
> </article>
>
> ...although this would probably fit better as a <content> element, and
> would require a whole other line of discussion that can wait for another
> day.
>
> ?
>

That's a good idea. We really need an element to wrap all the <p>s, <ul>s,
<ol>s, <figure>s, <table>s ... etc of a blog post.

From ian at invigoreight.com  Thu Nov 15 03:43:09 2012
From: ian at invigoreight.com (Ian Yang)
Date: Thu, 15 Nov 2012 19:43:09 +0800
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
	<CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
	<CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>
Message-ID: <CABr1FseFvHxS7_98cF9Xn2WBGDJdkL7mq+yXFCR0+fDvykq+5Q@mail.gmail.com>

On Thu, Nov 15, 2012 at 7:27 PM, Ian Yang <ian at invigoreight.com> wrote:

> On Thu, Nov 15, 2012 at 12:59 PM, Tim Leverett <zzzzbov at gmail.com> wrote:
>
>> Personally, I'd rather see <main> be more about marking up content in
>> general, such as in this example which is invalid given the current state
>> of the spec:
>> <article id=1>
>>   <header />
>>   <main />
>>   <footer />
>> </article>
>> <article id=2>
>>   <header />
>>   <main />
>>   <footer />
>> </article>
>>
>> ...although this would probably fit better as a <content> element, and
>> would require a whole other line of discussion that can wait for another
>> day.
>>
>> ?
>>
>
> That's a good idea. We really need an element to wrap all the <p>s, <ul>s,
> <ol>s, <figure>s, <table>s ... etc of a blog post.
>

I'm sorry, but I have to eat my above words.

Previously I proposed that <main> being a sectioning element for a better
document outline (
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591#c0). So the use
of <main>s in all blog posts won't help improving the
document outline.

Regards,
Ian Yang

From annevk at annevk.nl  Thu Nov 15 05:45:36 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 15 Nov 2012 05:45:36 -0800
Subject: [whatwg] URL: IPv6 parsing and model/serializing
In-Reply-To: <50A3EB70.1030308@mit.edu>
References: <CADnb78jnyYt1+5SRX7QBzHmo5Ux0K519MfZksmGk6Kobb0A+CA@mail.gmail.com>
	<50A3EB70.1030308@mit.edu>
Message-ID: <CADnb78hQjWTiyZZL8vQqVeGQ4y+2+jfLCskrFfaBqT7wn3xZkA@mail.gmail.com>

On Wed, Nov 14, 2012 at 11:05 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> I believe Gecko simply stores the original string (lowercased), modulo IDN
> stuff.  Since this works for both DNS names and IP addresses, a requirement
> that some other representation be stored is actually a bit of an
> implementation annoyance...

Well and it is validated. You definitely parse the string, but I can
see how that is cheaper than transforming the string. And that string
is then passed to the DNS layer?

We could define that instead I suppose although it seems kind of weird
to normalise domain names, but not IP addresses. We could offer an API
instead I suppose that does implement
http://tools.ietf.org/html/rfc5952#section-4

-- 
http://annevankesteren.nl/

From junov at chromium.org  Thu Nov 15 06:26:06 2012
From: junov at chromium.org (Justin Novosad)
Date: Thu, 15 Nov 2012 09:26:06 -0500
Subject: [whatwg] Enabling LCD Text in 2D canvases.
In-Reply-To: <BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
Message-ID: <CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>

On Wed, Nov 14, 2012 at 8:07 PM, Fred Andrews <fredandw at live.com> wrote:

>
> The canvas that scripts draw into could be over-sized with the UA down
> sampling this to
> fit the target size and taking into account the sub-pixel screen layout
> when doing so.
>
>
Obviously, that would be costly (x3 pixels), but I think it is a very
realistic solution and relatively low hanging fruit. The over-sizing of the
canvas would have to be handled under the hood by the UA though, because it
depends on LCD component ordering and orientation, which means querying the
OS/display driver. A lot of the kinks with the over-sized canvas approach
have already been ironed out for solving the problem of High-DPI support (
put/getImageDataHD ), and I like the idea of unifying the two. Implementing
this would mostly be a matter of adding per color component compositing of
canvases. Also, the pixel aspect ratio would have to be taken into account
for line drawing.

Regarding the concerns about accessibility, I think the problem can be
solved by using HitRegions with labels.  Come to think of it, there should
be an option to make the UA do this automatically: create a HitRegion with
a label every time text is drawn to a canvas.

From zzzzbov at gmail.com  Thu Nov 15 06:45:44 2012
From: zzzzbov at gmail.com (Tim Leverett)
Date: Thu, 15 Nov 2012 09:45:44 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CABr1FseFvHxS7_98cF9Xn2WBGDJdkL7mq+yXFCR0+fDvykq+5Q@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
	<CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
	<CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>
	<CABr1FseFvHxS7_98cF9Xn2WBGDJdkL7mq+yXFCR0+fDvykq+5Q@mail.gmail.com>
Message-ID: <CAOiS3y5GGb7iZ1ZxNK8t9Wo7NmAk5P3LG_e-Ot4LeTRezurh=w@mail.gmail.com>

>> Con: Adding a <main> element adds redundancy to the [role="main"]
attribute.
> I don't see why this is a con, if main is mapped to role=main in the
browser it means that authors won't have to. Also adding
aside/article/footer etc adds redundancy to the matching ARIA roles.

Redundancy tends to be a source of error if they get out of sync. If one
browser supports [role="main"] and another supports <main>, both would be
needed to provide compatibility. Obviously this is a bit contrived, as
browsers supporting <main> would likely also support [role="main"], but
older versions would not support <main> . Going forward, this would mean
that authors wanting to use <main> would have to use <main role="main"> for
backwards compatibility.

I could be wrong on this, but I was pretty certain that <article> and the
rest were supported by browsers before the ARIA roles model.

>> Con: Implementing the <main> element in a backwards compatible manner requires
JavaScript.
> it is/was the same for any of the new structural elements.

Yes, and that's a con for using any of the newer HTML5 elements over ARIA
roles.

> authors can use more granular elements within the <main> element, to
structure content, example:
> <main>
> <article/>
> <aside> advertisements</aside>
> <article/>
> </main>

Good point on the <aside> I hadn't thought of that.

On Thu, Nov 15, 2012 at 6:43 AM, Ian Yang <ian at invigoreight.com> wrote:

> On Thu, Nov 15, 2012 at 7:27 PM, Ian Yang <ian at invigoreight.com> wrote:
>
> > On Thu, Nov 15, 2012 at 12:59 PM, Tim Leverett <zzzzbov at gmail.com>
> wrote:
> >
> >> Personally, I'd rather see <main> be more about marking up content in
> >> general, such as in this example which is invalid given the current
> state
> >> of the spec:
> >> <article id=1>
> >>   <header />
> >>   <main />
> >>   <footer />
> >> </article>
> >> <article id=2>
> >>   <header />
> >>   <main />
> >>   <footer />
> >> </article>
> >>
> >> ...although this would probably fit better as a <content> element, and
> >> would require a whole other line of discussion that can wait for another
> >> day.
> >>
> >> ?
> >>
> >
> > That's a good idea. We really need an element to wrap all the <p>s,
> <ul>s,
> > <ol>s, <figure>s, <table>s ... etc of a blog post.
> >
>
> I'm sorry, but I have to eat my above words.
>
> Previously I proposed that <main> being a sectioning element for a better
> document outline (
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=19591#c0). So the use
> of <main>s in all blog posts won't help improving the
> document outline.
>
>
> Regards,
> Ian Yang
>

From bzbarsky at MIT.EDU  Thu Nov 15 07:02:17 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 15 Nov 2012 07:02:17 -0800
Subject: [whatwg] URL: IPv6 parsing and model/serializing
In-Reply-To: <CADnb78hQjWTiyZZL8vQqVeGQ4y+2+jfLCskrFfaBqT7wn3xZkA@mail.gmail.com>
References: <CADnb78jnyYt1+5SRX7QBzHmo5Ux0K519MfZksmGk6Kobb0A+CA@mail.gmail.com>
	<50A3EB70.1030308@mit.edu>
	<CADnb78hQjWTiyZZL8vQqVeGQ4y+2+jfLCskrFfaBqT7wn3xZkA@mail.gmail.com>
Message-ID: <50A503F9.3090302@mit.edu>

On 11/15/12 5:45 AM, Anne van Kesteren wrote:
> Well and it is validated. You definitely parse the string

Yes, absolutely.

> but I can
> see how that is cheaper than transforming the string. And that string
> is then passed to the DNS layer?

I don't know offhand.  I'd have to go dig...

> We could define that instead I suppose although it seems kind of weird
> to normalise domain names, but not IP addresses. We could offer an API
> instead I suppose that does implement
> http://tools.ietf.org/html/rfc5952#section-4

Just to be clear, I don't necessarily object to normalizing IPv6 
addresses.  Especially since I'm no longer actively working on 
networking code, so it's not like it would be work for _me_.  I just 
mentioned the only concern I had about your proposal, which in general 
sounds excellent.

-Boris

From faulkner.steve at gmail.com  Thu Nov 15 07:16:17 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Thu, 15 Nov 2012 15:16:17 +0000
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
	<CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
Message-ID: <CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>

yes this is true, same goes for the other new elements today. I see little
issue with the redundancy though as the roles match the elements.

I could be wrong on this, but I was pretty certain that <article> and the
rest were supported by browsers before the ARIA roles model.

no - the majority of accessibility APIs did/do not have non ARIA based
roles specified for header/footer/article/aside etc
some APIs are adding roles based on ARIA (Mac AX, Iaccessible2 etc)

accessibility implementation in browsers for the semantics of these
elements is variable [1]

[1] http://www.html5accessibility.com/

regards
SteveF

From whatwg-owner at lists.whatwg.org  Thu Nov 15 13:07:42 2012
From: whatwg-owner at lists.whatwg.org (whatwg-owner at lists.whatwg.org)
Date: Thu, 15 Nov 2012 13:07:42 -0800
Subject: [whatwg] Proposal: implement a <usescookies> tag.
Message-ID: <mailman.2017.1353013662.34820.whatwg-whatwg.org@lists.whatwg.org>

To post feedback to the WHATWG list, please subscribe first (and post
from the same e-mail address as you subscribed from). We require this
because of the level of spam the list would otherwise receive.

If you just want to submit drive-by feedback and aren't concerned
about receiving a reply, you can also file a bug using the "review
comments" tool found at the bottom right of the screen when viewing
the spec:

http://whatwg.org/html

If you have any questions about any of this or if you want to send
private feedback, please feel free to e-mail Ian at ian at hixie.ch.
Thanks!

Opnieuw-verstuurd-door: Eric Imthorn <ericimthorn at me.com>
Van: Eric Imthorn <eric.imthorn at gmail.com>
Onderwerp: Proposal: implement a <usescookies> tag.
Datum: 15 november 2012 21:52:33 CET
Opnieuw-verstuurd-aan: "whatwg at lists.whatwg.org" <whatwg at lists.whatwg.org>
Aan: whatwg at lists.whatwg.org

Because of European legislation, all sites must warn users about the usage of cookies on the sites.
Over 90% of European websites use cookies, which could make a "We use cookies" block become more common than a footer.
So assuming the law is here to stay, this common mandatory block might as well get his own <usescookies> tag (or something in that nature).

Another advantage is that browser-builders can implement an option to automatically "display:none" these elements (redering the whole legislation useless).

From silviapfeiffer1 at gmail.com  Thu Nov 15 16:20:53 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 16 Nov 2012 11:20:53 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAOiS3y5GGb7iZ1ZxNK8t9Wo7NmAk5P3LG_e-Ot4LeTRezurh=w@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
	<CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
	<CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>
	<CABr1FseFvHxS7_98cF9Xn2WBGDJdkL7mq+yXFCR0+fDvykq+5Q@mail.gmail.com>
	<CAOiS3y5GGb7iZ1ZxNK8t9Wo7NmAk5P3LG_e-Ot4LeTRezurh=w@mail.gmail.com>
Message-ID: <CAHp8n2k0A8i_McCjpwAYTiXjri=UPSUb5CyuNNf2+PAC6LGMXw@mail.gmail.com>

On Fri, Nov 16, 2012 at 1:45 AM, Tim Leverett <zzzzbov at gmail.com> wrote:

> >> Con: Adding a <main> element adds redundancy to the [role="main"]
> attribute.
> > I don't see why this is a con, if main is mapped to role=main in the
> browser it means that authors won't have to. Also adding
> aside/article/footer etc adds redundancy to the matching ARIA roles.
>
> Redundancy tends to be a source of error if they get out of sync. If one
> browser supports [role="main"] and another supports <main>, both would be
> needed to provide compatibility. Obviously this is a bit contrived, as
> browsers supporting <main> would likely also support [role="main"], but
> older versions would not support <main> . Going forward, this would mean
> that authors wanting to use <main> would have to use <main role="main"> for
> backwards compatibility.
>

Actually, there's a good point: I would actually add this: if <main> or an
element with @role="main" exist on the page, there is no need to run the
Scooby-Doo algorithm and that element can just be chosen as the <main>
element.

Silvia.

From tkent at chromium.org  Thu Nov 15 16:59:39 2012
From: tkent at chromium.org (TAMURA, Kent)
Date: Fri, 16 Nov 2012 09:59:39 +0900
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50A3D3AE.904@lamouri.fr>
References: <50A12B1F.1080200@lamouri.fr>
	<CAGH7WqEoHmY8636V+ek6vGLLDizA8upiOxhYvOD49u=1=Chxog@mail.gmail.com>
	<50A3D3AE.904@lamouri.fr>
Message-ID: <CAGH7WqGmPO1tckuEXivN2SrmgJq9mVkzs+CrQqU=LR3vWvjg5g@mail.gmail.com>

I think I can do it for WebKit if WHATWG specification and W3C
specification are changed so.

On Thu, Nov 15, 2012 at 2:23 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:
> On 13/11/12 09:42, TAMURA, Kent wrote:
>> The current UI implementations of Opera, iOS, and Chrome-Android spoil
>> the
>> HTML standard. Web authors hardly have motivation to use type=datetime.
>> They can add 'UTC' text, and their code can append 'Z' to values easily.

>> I agree that the type names are not good.  People must think
>> type=datetime
>> is a combination of type=date and type=time. It's not too late to rename
>> datetime-local to datetime because the number of type=datetime or
>> type=datetime-local in the Web is terribly smaller than the number of
>> type=date.

> Tamura, do you think Webkit/Chrome can do this change?
> Gecko/Mozilla would be willing to implement 'datetime' that way and not
> implement 'datetime-local' but having other vendors committed to this
> change would be helpful and prevent us from going alone in this path.

> Cheers,
> --
> Mounir

-- 
TAMURA Kent
Software Engineer, Google

From lists at eitanadler.com  Thu Nov 15 17:21:03 2012
From: lists at eitanadler.com (Eitan Adler)
Date: Thu, 15 Nov 2012 20:21:03 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2k0A8i_McCjpwAYTiXjri=UPSUb5CyuNNf2+PAC6LGMXw@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
	<CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
	<CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>
	<CABr1FseFvHxS7_98cF9Xn2WBGDJdkL7mq+yXFCR0+fDvykq+5Q@mail.gmail.com>
	<CAOiS3y5GGb7iZ1ZxNK8t9Wo7NmAk5P3LG_e-Ot4LeTRezurh=w@mail.gmail.com>
	<CAHp8n2k0A8i_McCjpwAYTiXjri=UPSUb5CyuNNf2+PAC6LGMXw@mail.gmail.com>
Message-ID: <CAF6rxg=2Wh6VQtmbGqc0BWzctuXSK6hbmNcc2vRzd5eSSTMuvw@mail.gmail.com>

On 15 November 2012 19:20, Silvia Pfeiffer <silviapfeiffer1 at gmail.com> wrote:
> On Fri, Nov 16, 2012 at 1:45 AM, Tim Leverett <zzzzbov at gmail.com> wrote:
>
>> >> Con: Adding a <main> element adds redundancy to the [role="main"]
>> attribute.
>> > I don't see why this is a con, if main is mapped to role=main in the
>> browser it means that authors won't have to. Also adding
>> aside/article/footer etc adds redundancy to the matching ARIA roles.
>>
>> Redundancy tends to be a source of error if they get out of sync. If one
>> browser supports [role="main"] and another supports <main>, both would be
>> needed to provide compatibility. Obviously this is a bit contrived, as
>> browsers supporting <main> would likely also support [role="main"], but
>> older versions would not support <main> . Going forward, this would mean
>> that authors wanting to use <main> would have to use <main role="main"> for
>> backwards compatibility.
>>
>
>
> Actually, there's a good point: I would actually add this: if <main> or an
> element with @role="main" exist on the page, there is no need to run the
> Scooby-Doo algorithm and that element can just be chosen as the <main>
> element.

What if both exist but are different elements?

-- 
Eitan Adler

From dbk at google.com  Thu Nov 15 17:28:20 2012
From: dbk at google.com (David Barrett-Kahn)
Date: Thu, 15 Nov 2012 17:28:20 -0800
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <CAMK=o4eziZ+7qs-OVgAWiPe89UKD_AqtZ1X4v=R527eVhUDgfA@mail.gmail.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
	<CAMK=o4eziZ+7qs-OVgAWiPe89UKD_AqtZ1X4v=R527eVhUDgfA@mail.gmail.com>
Message-ID: <CA+iXHYOL6kM8gVaXm+Vxai5Pdq2hFr-ZTOtHqBg05g+=SaYR=w@mail.gmail.com>

Thanks Tobie, that does sound related, but not quite the same use case.
 That proposal seems to want to make the creation of memory/network/runtime
performance profiles scriptable if the user allows it.  Presumably you
wouldn't do that routinely, which raises the question of when you would do
it.  Once the app has crashed it's probably too late.  I foresee this
mainly being used by groups of users 'friendly' to the application author,
such as employees of their firm, qa testers, etc.  Their privacy issue
isn't so bad, either, as there would be nothing in those profiles which the
app author didn't in principal have access to before.  I'm also not sure my
use case falls inside the performance working group's charter.  In any
case, I'll reach out to them and see if they're interested, thanks.

Ian, I'd be interested in what you had in mind when you said 'a lot of
user opt-in'.
 Presumably you don't feel a permission dialog raised at the time of the
API call enough, were you thinking of a browser configuration setting, off
by default?  That's very limiting, you'd be down to 'friendly users' again.
 Your other objections I think could mostly be dealt with.  I've specified
that user agents supporting the screenshot have to provide a blackout tool.
 Also, in some ways the more annoying this dialog is the better, as it's
supposed to be something devs only use if they really need to.  You could
focus the 'no' button by default, or make it unresponsive until a timeout,
stuff like that.

I'll raise this with some of the browser vendors directly as Ian suggested.

Thanks,

-Dave

On Thu, Nov 15, 2012 at 1:46 AM, Tobie Langel <tobie.langel at gmail.com>wrote:

> On Thu, Nov 15, 2012 at 6:07 AM, David Barrett-Kahn <dbk at google.com>
> wrote:
> > Hi whatwg.  I have a proposal for a new web standard, and would value
> your
> > feedback.  This is based on my experiences working on Google Docs, which
> > has a well developed ability to send crash reports back to the server for
> > analysis.  We often find these crash reports to be lacking in crucial
> > information though, because that information is not available on the JS
> > APIs.
> >
> > My proposal is to have a class of information which can be made available
> > to an app only after the display of a generic 'this application has
> > crashed' dialog, which could be drilled into to show what is being
> > disclosed, and which of course can be denied.
> >
> > Good examples of the information in question are the system's precise
> > hardware and network configuration, what Chrome extensions it has
> > installed, and perhaps a screenshot of the failed application.
>
> There is directly related work[1] being included in the WebPerf
> WG[2]'s upcoming charter. Given the privacy and fingerprinting
> constraints are the same, you should probably bring your suggestions
> there.
>
> --tobie
> ---
> [1]:
> https://docs.google.com/document/d/1Yw_qNMCnGsWQRsdcrifzh_kzFey-ThQ3yp-DmxuJxvg/edit
> [2]: http://www.w3.org/2010/webperf/
>

-- 
-Dave

From silviapfeiffer1 at gmail.com  Thu Nov 15 17:42:23 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Fri, 16 Nov 2012 12:42:23 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAF6rxg=2Wh6VQtmbGqc0BWzctuXSK6hbmNcc2vRzd5eSSTMuvw@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
	<CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
	<CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>
	<CABr1FseFvHxS7_98cF9Xn2WBGDJdkL7mq+yXFCR0+fDvykq+5Q@mail.gmail.com>
	<CAOiS3y5GGb7iZ1ZxNK8t9Wo7NmAk5P3LG_e-Ot4LeTRezurh=w@mail.gmail.com>
	<CAHp8n2k0A8i_McCjpwAYTiXjri=UPSUb5CyuNNf2+PAC6LGMXw@mail.gmail.com>
	<CAF6rxg=2Wh6VQtmbGqc0BWzctuXSK6hbmNcc2vRzd5eSSTMuvw@mail.gmail.com>
Message-ID: <CAHp8n2kn1sDxZqC3r1X1XgLdFVo0MVCmHw-DfU6BvoE4PpH-8A@mail.gmail.com>

On Fri, Nov 16, 2012 at 12:21 PM, Eitan Adler <lists at eitanadler.com> wrote:

> On 15 November 2012 19:20, Silvia Pfeiffer <silviapfeiffer1 at gmail.com>
> wrote:
> > On Fri, Nov 16, 2012 at 1:45 AM, Tim Leverett <zzzzbov at gmail.com> wrote:
> >
> >> >> Con: Adding a <main> element adds redundancy to the [role="main"]
> >> attribute.
> >> > I don't see why this is a con, if main is mapped to role=main in the
> >> browser it means that authors won't have to. Also adding
> >> aside/article/footer etc adds redundancy to the matching ARIA roles.
> >>
> >> Redundancy tends to be a source of error if they get out of sync. If one
> >> browser supports [role="main"] and another supports <main>, both would
> be
> >> needed to provide compatibility. Obviously this is a bit contrived, as
> >> browsers supporting <main> would likely also support [role="main"], but
> >> older versions would not support <main> . Going forward, this would mean
> >> that authors wanting to use <main> would have to use <main role="main">
> for
> >> backwards compatibility.
> >>
> >
> >
> > Actually, there's a good point: I would actually add this: if <main> or
> an
> > element with @role="main" exist on the page, there is no need to run the
> > Scooby-Doo algorithm and that element can just be chosen as the <main>
> > element.
>
> What if both exist but are different elements?
>

Good question. I'd likely choose <main> over @role=main.

Silvia.

From hugh.guiney at gmail.com  Thu Nov 15 17:48:52 2012
From: hugh.guiney at gmail.com (Hugh Guiney)
Date: Thu, 15 Nov 2012 20:48:52 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAF6rxg=2Wh6VQtmbGqc0BWzctuXSK6hbmNcc2vRzd5eSSTMuvw@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
	<CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
	<CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>
	<CABr1FseFvHxS7_98cF9Xn2WBGDJdkL7mq+yXFCR0+fDvykq+5Q@mail.gmail.com>
	<CAOiS3y5GGb7iZ1ZxNK8t9Wo7NmAk5P3LG_e-Ot4LeTRezurh=w@mail.gmail.com>
	<CAHp8n2k0A8i_McCjpwAYTiXjri=UPSUb5CyuNNf2+PAC6LGMXw@mail.gmail.com>
	<CAF6rxg=2Wh6VQtmbGqc0BWzctuXSK6hbmNcc2vRzd5eSSTMuvw@mail.gmail.com>
Message-ID: <CAEHyr+abHswWNawPYKFa-BNnKxr7pMkGy8ACnX5j0fGwg=r7Pg@mail.gmail.com>

On Thu, Nov 15, 2012 at 8:21 PM, Eitan Adler <lists at eitanadler.com> wrote:

>  > Actually, there's a good point: I would actually add this: if <main> or
> an
> > element with @role="main" exist on the page, there is no need to run the
> > Scooby-Doo algorithm and that element can just be chosen as the <main>
> > element.
>
> What if both exist but are different elements?

Favor the first or most ancestral occurrence.

From zzzzbov at gmail.com  Thu Nov 15 18:45:26 2012
From: zzzzbov at gmail.com (Tim Leverett)
Date: Thu, 15 Nov 2012 21:45:26 -0500
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAEHyr+abHswWNawPYKFa-BNnKxr7pMkGy8ACnX5j0fGwg=r7Pg@mail.gmail.com>
References: <op.wnepv6u9idj3kv@device-23f190>
	<CANMdWTsPJ5qy4O5WuFSmmYX3W3s_NVNGXYJOtGF0kA-e-fr3hQ@mail.gmail.com>
	<72C23BCC-A75A-4995-92D3-17DC0EEE17E8@apple.com>
	<CAJ0g8QQ+uNgoCTPxT=yJhbFq954xV57FUqoPpR2KakJnLXsbLQ@mail.gmail.com>
	<CAHp8n2=auPfHWCYvgXpuwY+ZwZVbD26bDQniWpSGw0h1r9FbyA@mail.gmail.com>
	<CAHp8n2ntJNyn1kwbBSzG3TAAgUnrgGM8ddk9fbXqj2QrpJXsYQ@mail.gmail.com>
	<CAOiS3y7c_7wMyuUyTjYPx4UhZTwuzO7eD9gz_dsFTiiXx8Z7uQ@mail.gmail.com>
	<CAHp8n2=UmtQYBmvtgvNKs64Mu9GwiHEqOvmzhiWEH74a5oo0Lg@mail.gmail.com>
	<CAOiS3y6kETDFwvLuODtqzqovJf_oOYOPjeiq00=uN=Uj8q9_Vw@mail.gmail.com>
	<CAHp8n2mGDxmDcUdP6orcWWwGM-adJo+N=mU5sOMZQXTaOOWA8Q@mail.gmail.com>
	<CAOiS3y6mBXGy4f7W0YwmAePEd+LEMsFvOuEYypDSpLYhU5630w@mail.gmail.com>
	<CAHp8n2ntMsc7hoQER1mkb23g+fJgXYmxtApJeFSWVG5Ce8NLRg@mail.gmail.com>
	<CAOiS3y5Z16h_TQZ7+-NxOL0DW1xxb6yPujBpqyJ7nrhZmDFSLA@mail.gmail.com>
	<CABr1Fsf1QXhux-FE6DZhCZtNE2nJtCVP=-9DAFHxTiRB1ABWSQ@mail.gmail.com>
	<CABr1FseFvHxS7_98cF9Xn2WBGDJdkL7mq+yXFCR0+fDvykq+5Q@mail.gmail.com>
	<CAOiS3y5GGb7iZ1ZxNK8t9Wo7NmAk5P3LG_e-Ot4LeTRezurh=w@mail.gmail.com>
	<CAHp8n2k0A8i_McCjpwAYTiXjri=UPSUb5CyuNNf2+PAC6LGMXw@mail.gmail.com>
	<CAF6rxg=2Wh6VQtmbGqc0BWzctuXSK6hbmNcc2vRzd5eSSTMuvw@mail.gmail.com>
	<CAEHyr+abHswWNawPYKFa-BNnKxr7pMkGy8ACnX5j0fGwg=r7Pg@mail.gmail.com>
Message-ID: <CAOiS3y4kNbpV7hehqKES3gSzgo_-jSaBtuawrOCMbjVmxPp3rw@mail.gmail.com>

>> What if both exist but are different elements?
> Favor the first or most ancestral occurrence.

I concur.

On Thu, Nov 15, 2012 at 8:48 PM, Hugh Guiney <hugh.guiney at gmail.com> wrote:

> On Thu, Nov 15, 2012 at 8:21 PM, Eitan Adler <lists at eitanadler.com> wrote:
>
>>  > Actually, there's a good point: I would actually add this: if <main>
>> or an
>> > element with @role="main" exist on the page, there is no need to run the
>> > Scooby-Doo algorithm and that element can just be chosen as the <main>
>> > element.
>>
>> What if both exist but are different elements?
>
>
> Favor the first or most ancestral occurrence.
>

From bzbarsky at MIT.EDU  Thu Nov 15 19:37:51 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 15 Nov 2012 19:37:51 -0800
Subject: [whatwg] Document.setCapture/releaseCapture
Message-ID: <50A5B50F.3020307@mit.edu>

Are setCapture/releaseCapture specified on document anywhere?  The last 
thing I see about it is 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017415.html 
and then nothing...

Note that I suspect we do need a releaseCapture() so pages can call it 
without throwing, even if we decide it should do nothing when called.

-Boris

From ajvincent at gmail.com  Fri Nov 16 09:09:21 2012
From: ajvincent at gmail.com (Alex Vincent)
Date: Fri, 16 Nov 2012 09:09:21 -0800
Subject: [whatwg] DOM serialization: A new level perhaps?
Message-ID: <CAEZ844350kyx77Roj6zH8=b3RCN=WnfK9c7=pMd0YaFZ+JKO5w@mail.gmail.com>

I've been looking at the new DOM serialization spec, and I have a concern.
 The serialization algorithms assume that the document is being serialized
without having been parsed from a block of source code before.  It doesn't
preserve existing formatting.

For reference:  http://domparsing.spec.whatwg.org/#concept-serialize-xml

Example:  If I parse this:

The resulting DOM is fine.  When I reserialize it, I get:

When I perform a diff in SVN or Mercurial before committing, the source
code shows changes that I did not intend.  Forget the fact that the latter
is 'prettier' - the authoring style has been altered.  This may be
significant when there are several attributes on an element, pushing the
line length well above 80 characters.

I'm starting some experiments using Mozilla's SAX parser and JavaScript to
attempt to figure out some solutions.  First, the DOMParser may elect to
cache starting and closing tags for elements (and the original source for
non-elements) as a private property of nodes which the DOMSerializer may
use if the node has not mutated.  Second, I'm going to try defining a
"MarkupIndent" data type in JS to try capturing the source document's
indentation style(s), so that when a node changes (adding a new attribute,
for example), the DOMSerializer will have some information to make an
educated guess about how the author wants it formatted.

I expect within a month or so I can deliver a working implementation with
documentation and tests.  I hope that we could add a chapter to the
DOMParsing spec, making this an optional feature.

--
"The first step in confirming there is a bug in someone else's work is
confirming there are no bugs in your own."
-- Alexander J. Vincent, June 30, 2001

From ian at hixie.ch  Fri Nov 16 10:06:31 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 16 Nov 2012 18:06:31 +0000 (UTC)
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <CA+iXHYOL6kM8gVaXm+Vxai5Pdq2hFr-ZTOtHqBg05g+=SaYR=w@mail.gmail.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
	<CAMK=o4eziZ+7qs-OVgAWiPe89UKD_AqtZ1X4v=R527eVhUDgfA@mail.gmail.com>
	<CA+iXHYOL6kM8gVaXm+Vxai5Pdq2hFr-ZTOtHqBg05g+=SaYR=w@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211161801120.16964@ps20323.dreamhostps.com>

On Thu, 15 Nov 2012, David Barrett-Kahn wrote:
> 
> Ian, I'd be interested in what you had in mind when you said 'a lot of 
> user opt-in'.

I don't know, exactly. It has to be something where we're confident that 
the user understands that he is about to send sensitive information to a 
stranger.

The concern isn't when this is used by a company like Apple or Facebook; 
the worst such companies are going to do with sensitive data is target ads 
better or make their products more streamlined. The concern is when some 
attacker wants to get information about your company's intranet's 
topology, or wants to know what potentially vulnerable plugins or 
extensions you have installed, or wants to know what software you are 
running, so that they can more precisely target you. Such an attacker can 
trivially provide you with a game to play, and then have the game crash, 
misleading you into thinking they're a perfectly honest game developer and 
causing you to eagerly send them all the sensitive information they want.

These are not hypothetical concerns. Over the last few years, targetted 
attacks of this nature have become much more common and are a real threat.

From ian at hixie.ch  Fri Nov 16 10:07:50 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 16 Nov 2012 18:07:50 +0000 (UTC)
Subject: [whatwg] Document.setCapture/releaseCapture
In-Reply-To: <50A5B50F.3020307@mit.edu>
References: <50A5B50F.3020307@mit.edu>
Message-ID: <Pine.LNX.4.64.1211161807060.16964@ps20323.dreamhostps.com>

On Thu, 15 Nov 2012, Boris Zbarsky wrote:
>
> Are setCapture/releaseCapture specified on document anywhere?  The last 
> thing I see about it is 
> http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017415.html 
> and then nothing...

We don't actually have a solid spec defining mouse events at all, let 
alone setCapture(). I agree that we should. Just needs an editor with a 
lot of time, really.

From ian at hixie.ch  Fri Nov 16 12:25:08 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 16 Nov 2012 20:25:08 +0000 (UTC)
Subject: [whatwg] Canvas in Workers
In-Reply-To: <20120330143901.155050@gmx.com>
References: <20120330143901.155050@gmx.com>
Message-ID: <Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>

Over the years, there have been lots of requests for asynchronous image 
manipulation APIs, and each time we discuss it we end up concluding that 
what we should really do is just put canvas on workers.

I've now specced a concrete proposal for this.

Since we can't literally put <canvas> in a worker since workers don't have 
DOMs, I was faced with two options:

Option A: Provide an API for off-screen graphics in workers, requiring 
that every frame you package the whole thing up, send it over to the main 
thread, and blt it there.

Option B: Provide a mechanism by which a worker can actually paint 
directly onto a main thread <canvas> element.

I ended up specifying something that lets you do both. You can instantiate 
a CanvasRenderingContext2D object anywhere, including a worker; when a 
rendering context is not bound to a specific canvas, it can be used as an 
off-screen drawing surface. You can then bind such a rendering context to 
a canvas; when you do this, there is a commit() method that you can use 
which tells the user agent to push the bitmap drawn on the 
CanvasRenderingContext2D object to the canvas bitmap / screen.

A quick example of how this can work:

// main.html
   <canvas></canvas>
   <script>
    var canvas = document.getElementsByTagName('canvas')[0];
    var worker = new Worker('clock.js');
    var proxy = canvas.transferControlToProxy());
    worker.postMessage(proxy, [proxy]);
   </script>

// clock.js worker
   onmessage = function (event) {
     var context = new CanvasRenderingContext2d();
     event.data.setContext(context);
     setInterval(function () {
       context.clearRect(0, 0, context.width, context.height);
       context.fillText(0, 100, new Date());
       context.commit();
     }, 1000);
   };

There are several difficulties in a canvas-in-worker solution that I'd 
like to mention here, with a brief pointer to the solutions I used:

1. Workers had no way to represent images (e.g. sprites) before, which is 
rather limiting for a bitmap canvas API. I have introduced a new object 
called ImageBitmap that can be constructed from a Blob obtained from XHR 
in a worker, or that can be created from <img>, <video>, and <canvas> 
elements and transfered over to a worker. This can then be used to render 
images in workers.

2. The 2D rendering context API has several features that actually 
interact with the page, e.g. scrollIntoView(). I've tried to make these 
work too; there's a mechanism by which these actions are queued up and 
then when you call commit() they're run as a task on the main thread.

3. Since the main thread paints on its own schedule, and the worker might 
be half-way through its drawing when the main thread wants to paint, I've 
had to introduce an explicit commit() that tells the UA to push the data 
from the worker to the rendering.

4. Since you can read the image from the main thread (for example, using 
the context.drawImage(canvas, ...) method, or even, now that there's the 
ImageBitmap object, using "new ImageBitmap(canvas)"), as well as read the 
image from the worker (using the same mechanisms, but using the context as 
the source instead of the canvas -- we have to support this, because it's 
common to do things like fade out the current scene, or shift it a bit, or 
otherwise manipulate the image itself), and given that the rendered bitmap 
is not the same as the currently drawing one (since we have to commit, see 
above), I've ended up having to specify that when you're on a worker, a 
canvas really has two bitmaps, the scratch bitmap and the output bitmap. 
This does, if the author actually tries to read the scratch bitmap, mean 
that there's a greater memory requirement when working on a worker, but I 
really don't see a way around it.

5. We don't yet have a way to access Web Fonts in a worker. I'm relying on 
the CSS Fonts module's FontLoader proposal for this.

At the same time, the WebGL community has been looking for a way to bind a 
single rendering context to a several rendering contexts in sequence, 
allowing the same scene to be painted from different angles. I also tried 
to support this model; it will require some additions to WebGL to use the 
hooks that have been provided. Specifically:

- define the WebGLRenderingContext constructor.

- define the "binding steps" and the "unbinding steps".

- define a way to specify the settings for how to render to bitmaps, for 
   example whether to anti-alias or not. If you want to have this 
   information be on the canvas elements themselves, please let me know; 
   you'll need to come up with a mechanism for how to do this cross-thread
   without race conditions.

- define when pixels are pushed to "the canvas's bitmap". In particular, 
   this needs to handle how to do it when the canvas is in a different 
   thread, such that it is well-defined what bitmap an author gets if they
   use the HTMLCanvasElement itself in a drawImage() call. (See the 
   definition of commit() and the "commit the scratch bitmap" algorithm 
   for how the 2D case does it now.)

- manage the canvas bitmap's "clean-origin" flag.

If WebGLRenderingContext is supposed to react to the <canvas> element's 
"width" and "height" attributes being mutated, please let me know so that 
I can update the spec accordingly.

I've tried to leave the old getContext() mechanism mostly untouched, in 
terms of normative requirements. The new model is alongside it. So for 
example, the new model involves a scratch bitmap that you commit() to the 
output bitmap, whereas if you use getContext() you end up with a rendering 
context where the scratch bitmap andhhte output bitmap _are the same 
bitmap_ so anything you do immediately gets rendered (and commit() is not 
useful -- indeed it throws in this case).

As a result of this rewrite, and the way that the canvas spec now has to 
have much more intimate knowledge of rendering contexts, I've dropped the 
attempt to use a registry for rendering contexts. If a new one comes up, 
I'll just update the spec. (Proprietary extensions have a hook in the 
spec, in case anyone wants to spec them.)

Another result of this rewrite is that things like drawImage() are now 
specced much more precisely. I've also moved the 'origin-clean' stuff into 
the parts of the spec that actually affect it, rather than off in a 
separate section.

I haven't done anything to make requestAnimationFrame() be available on a 
worker, but we should do that. This will require changes to the rAF() 
spec, however.

Obviously all of this is just a proposal; if it turns out I took a huge 
wrong turn early on here then I'll happily throw it all out and try again!

Feedback is very welcome! :-)

From waldron.rick at gmail.com  Fri Nov 16 12:58:29 2012
From: waldron.rick at gmail.com (Rick Waldron)
Date: Fri, 16 Nov 2012 15:58:29 -0500
Subject: [whatwg] Canvas in Workers
In-Reply-To: <Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
Message-ID: <CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>

On Fri, Nov 16, 2012 at 3:25 PM, Ian Hickson <ian at hixie.ch> wrote:

>
>
>     var proxy = canvas.transferControlToProxy());
>

Proxy with a capital P is an API in ES6 for creating Proxy objects. While I
recognize that this is obviously just a conceptual sketch of your idea and
that you're merely following the camel case tradition, now is probably the
best time to be informed of potential naming conflicts.

Rick

From oliver at apple.com  Fri Nov 16 13:03:11 2012
From: oliver at apple.com (Oliver Hunt)
Date: Fri, 16 Nov 2012 13:03:11 -0800
Subject: [whatwg] Canvas in Workers
In-Reply-To: <CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
Message-ID: <52EDCCCE-E8DB-4AB9-B292-8F2000B7146B@apple.com>

postMessage already has an ownership transfer list, we could always extend the set of transferable types to include a canvas like thing (the context or some such).

IIRC the last time I suggested having canvas (or at least canvas-like) APIs available in workers it turned into a spec for rotating and scaling images (which i still don't fully understand).

--Oliver

On Nov 16, 2012, at 12:58 PM, Rick Waldron <waldron.rick at gmail.com> wrote:

> On Fri, Nov 16, 2012 at 3:25 PM, Ian Hickson <ian at hixie.ch> wrote:
> 
>> 
>> 
>>    var proxy = canvas.transferControlToProxy());
>> 
> 
> <bikeshed>
> 
> Proxy with a capital P is an API in ES6 for creating Proxy objects. While I
> recognize that this is obviously just a conceptual sketch of your idea and
> that you're merely following the camel case tradition, now is probably the
> best time to be informed of potential naming conflicts.
> 
> 
> Rick

From ian at hixie.ch  Fri Nov 16 13:11:33 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 16 Nov 2012 21:11:33 +0000 (UTC)
Subject: [whatwg] Canvas in Workers
In-Reply-To: <CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>

On Fri, 16 Nov 2012, Rick Waldron wrote:
> On Fri, Nov 16, 2012 at 3:25 PM, Ian Hickson <ian at hixie.ch> wrote:
> >
> >     var proxy = canvas.transferControlToProxy());
> 
> <bikeshed>
> 
> Proxy with a capital P is an API in ES6 for creating Proxy objects. 
> While I recognize that this is obviously just a conceptual sketch of 
> your idea and that you're merely following the camel case tradition, now 
> is probably the best time to be informed of potential naming conflicts.

The word Proxy is used all over the place on the Web platform, I'm not too 
worried about that. Right now the object returned above is "CanvasProxy", 
which is the kind of proxy that it refers to. I'm certainly open to 
another name, any suggestions?

From jackalmage at gmail.com  Fri Nov 16 13:12:58 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 16 Nov 2012 13:12:58 -0800
Subject: [whatwg] Canvas in Workers
In-Reply-To: <52EDCCCE-E8DB-4AB9-B292-8F2000B7146B@apple.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<52EDCCCE-E8DB-4AB9-B292-8F2000B7146B@apple.com>
Message-ID: <CAAWBYDAz1TM=gDvzp0z=f6H+UEYeM+TBdiZrVqmma0US-qUwPw@mail.gmail.com>

On Fri, Nov 16, 2012 at 1:03 PM, Oliver Hunt <oliver at apple.com> wrote:
> postMessage already has an ownership transfer list, we could always extend the set of transferable types to include a canvas like thing (the context or some such).

Transferring contexts is tolerable for 2d, but a non-starter for webgl
- there's too much stuff that can be loaded into a context that would
have to be transferred cross-process.  Hixie's approach uses a
lightweight canvas proxy instead.

> IIRC the last time I suggested having canvas (or at least canvas-like) APIs available in workers it turned into a spec for rotating and scaling images (which i still don't fully understand).

That was an attempt to solve the use-cases without doing the work to
actually port <canvas> to the worker.  Hixie's now done the latter.

~TJ

From ian at hixie.ch  Fri Nov 16 13:13:21 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 16 Nov 2012 21:13:21 +0000 (UTC)
Subject: [whatwg] Canvas in Workers
In-Reply-To: <52EDCCCE-E8DB-4AB9-B292-8F2000B7146B@apple.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<52EDCCCE-E8DB-4AB9-B292-8F2000B7146B@apple.com>
Message-ID: <Pine.LNX.4.64.1211162111450.16964@ps20323.dreamhostps.com>

On Fri, 16 Nov 2012, Oliver Hunt wrote:
>
> postMessage already has an ownership transfer list, we could always 
> extend the set of transferable types to include a canvas like thing (the 
> context or some such).

That's what CanvasProxy is.

> IIRC the last time I suggested having canvas (or at least canvas-like) 
> APIs available in workers it turned into a spec for rotating and scaling 
> images (which i still don't fully understand).

Yeah, this is intended to make that kind of thing unnecessary.

From waldron.rick at gmail.com  Fri Nov 16 13:14:43 2012
From: waldron.rick at gmail.com (Rick Waldron)
Date: Fri, 16 Nov 2012 16:14:43 -0500
Subject: [whatwg] Canvas in Workers
In-Reply-To: <Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
Message-ID: <CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>

CanvasProxy is a fine disambiguation.

Rick

On Fri, Nov 16, 2012 at 4:11 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 16 Nov 2012, Rick Waldron wrote:
> > On Fri, Nov 16, 2012 at 3:25 PM, Ian Hickson <ian at hixie.ch> wrote:
> > >
> > >     var proxy = canvas.transferControlToProxy());
> >
> > <bikeshed>
> >
> > Proxy with a capital P is an API in ES6 for creating Proxy objects.
> > While I recognize that this is obviously just a conceptual sketch of
> > your idea and that you're merely following the camel case tradition, now
> > is probably the best time to be informed of potential naming conflicts.
>
> The word Proxy is used all over the place on the Web platform, I'm not too
> worried about that. Right now the object returned above is "CanvasProxy",
> which is the kind of proxy that it refers to. I'm certainly open to
> another name, any suggestions?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

From ian at hixie.ch  Fri Nov 16 13:48:28 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 16 Nov 2012 21:48:28 +0000 (UTC)
Subject: [whatwg] Canvas in Workers
In-Reply-To: <CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
	<CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211162147040.16964@ps20323.dreamhostps.com>

On Fri, 16 Nov 2012, Rick Waldron wrote:
> On Fri, Nov 16, 2012 at 4:11 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 16 Nov 2012, Rick Waldron wrote:
> > > On Fri, Nov 16, 2012 at 3:25 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > >
> > > >     var proxy = canvas.transferControlToProxy());
> > >
> > > <bikeshed>
> > >
> > > Proxy with a capital P is an API in ES6 for creating Proxy objects.
> > > While I recognize that this is obviously just a conceptual sketch of
> > > your idea and that you're merely following the camel case tradition, now
> > > is probably the best time to be informed of potential naming conflicts.
> >
> > The word Proxy is used all over the place on the Web platform, I'm not too
> > worried about that. Right now the object returned above is "CanvasProxy",
> > which is the kind of proxy that it refers to. I'm certainly open to
> > another name, any suggestions?
>
> CanvasProxy is a fine disambiguation.

Do you think we should rename the method above to say that too?

"canvas.transferControlToCanvasProxy()" is a bit verbose. :-)

I had shortened it to just "canvas.transferControlToProxy" on the 
assumption that the fact that it was called on a canvas would disambiguate 
that it was a canvas proxy, but I'm certainly open to other suggestions.

From fantasai.lists at inkedblade.net  Fri Nov 16 14:14:22 2012
From: fantasai.lists at inkedblade.net (fantasai)
Date: Fri, 16 Nov 2012 14:14:22 -0800
Subject: [whatwg] [html-media-capture] capture vs. accept ( LC-2642)
In-Reply-To: <1CB2E0B458B211478C85E11A404A2B27018197BD@008-AM1MPN1-035.mgdnok.nokia.com>
References: <E1TBWdI-0004w8-HR@jessica.w3.org>
	<1CB2E0B458B211478C85E11A404A2B27018197BD@008-AM1MPN1-035.mgdnok.nokia.com>
Message-ID: <50A6BABE.1000502@inkedblade.net>

On 11/16/2012 07:38 AM, Frederick.Hirsch at nokia.com wrote:
> fantasai
>
> Is the WG response (see below) to your Last Call issue (LC-2642)  [1]
> on HTML Media Capture [2] regarding clarification of accept and capture
> [attributes of <input>] sufficient for us to close the issue?

If timeless and/or hixie are happy with it, I am satisfied.

> A rough summary is that
>
> 1. Accept indicates what is to be captured (e.g. image/*) and Capture
>    indicates the source type, there can be more than one source type
>    for a given 'what'

Other than filesystem vs. live (which could be satisfied by a boolean),
I don't see how the values of 'capture' are adding any information beyond
what can (and should) be provided by 'accept'.

> 2. Conflict is avoided by precedence rule in the specification that
>    the accept attribute takes precedence over the capture attribute

This is fair. I still don't see why you are duplicating the type
information, though. As a general design principle, it's better
to make it impossible for the user/author to provide invalid
combinations than to provide error handling for it.

Btw, thank you for your careful tracking of issues: I appreciate
your meticulousness in addressing them.

~fantasai

> [1] https://www.w3.org/2006/02/lc-comments-tracker/43696/WD-html-media-capture-20120712/2642
>     representing
>     - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0046.html
>     - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0047.html
>     - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0048.html
>     - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0049.html
>     - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0059.html
>     - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0060.html
>     - http://lists.w3.org/Archives/Public/public-device-apis/2012Jul/0064.html
>
> [2] http://dev.w3.org/2009/dap/camera/ (revised editors draft)
>
>> fantasai wrote:
>>> Hi!
>>> I was wondering, how is 'capture' different from 'accept'? It seems to me the
>>> following are equivalent:
>>>
>>>    capture      accept
>>>   ----------------------
>>>    camera       image/*
>>>    camcorder    video/*
>>>    microphone   audio/*
>>>    filesystem   */*
>>>
>>> ~fantasai
>>
>>
>> Working Group Resolution (LC-2642):
>> No changes to the specification are needed, please see
>> http://www.w3.org/mid/50127EC5.2080705 at opera.com
>>
>> [[
>>
>>> Not only would this avoid duplication, it also avoids conflicts like
>>>
>>> <input capture=microphone accept='image/*'>
>>
>> I believe the spec does address this:
>>
>> "The HTMLInputElement interface's accept attribute takes precedence over
>> the capture attribute. That is, if the accept attribute's value is set
>> to a MIME type that is not accepted in a defined capture state, the user
>> agent must act as if there was no capture attribute."
>>
>> ]]
>>
>> ----

From gphemsley at gmail.com  Fri Nov 16 14:19:37 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Fri, 16 Nov 2012 17:19:37 -0500
Subject: [whatwg] [mimesniff] The X-Content-Type-Options header
Message-ID: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>

https://www.w3.org/Bugs/Public/show_bug.cgi?id=19865

Microsoft introduced the X-Content-Type-Options header in IE8 back in 2008:

http://blogs.msdn.com/b/ie/archive/2008/09/02/ie8-security-part-vi-beta-2-update.aspx

I would like to integrate the header into mimesniff and describe its
proper usage.

Right now, it allows one parameter: 'nosniff'. I would like to allow
the presence of this parameter to set the 'no-sniff flag' that I just
introduced into mimesniff (in addition to that flag's existing
duties):

http://mimesniff.spec.whatwg.org/#no-sniff-flag

But I would also like to fully spec the header, while leaving open the
possibility that other values may be added in the future.

In addition, I would like to, if I could, also allow the header to be
specified without the 'X-' prefix (so as 'Content-Type-Options'), for
that reason (and because of best current practice).

Does anyone have any questions, comments, or objections about this issue?

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From annevk at annevk.nl  Fri Nov 16 14:28:32 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 16 Nov 2012 14:28:32 -0800
Subject: [whatwg] [mimesniff] The X-Content-Type-Options header
In-Reply-To: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>
References: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>
Message-ID: <CADnb78hebV_4R7pCSxviMgzsLg0b0_RAgXai7zb68wtsyCA2fg@mail.gmail.com>

On Fri, Nov 16, 2012 at 2:19 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> In addition, I would like to, if I could, also allow the header to be
> specified without the 'X-' prefix (so as 'Content-Type-Options'), for
> that reason (and because of best current practice).
>
> Does anyone have any questions, comments, or objections about this issue?

Not sure why you would drop the prefix if it's not supported. Doesn't
seem like best practice to me to needlessly break compatibility. ;-)

Also, are we sure they are not sniffing still? E.g. how is mislabeled
image content treated? I vaguely recall a image/png resource that's
actually a GIF, still working even in the presence of this header.
<script> probably still executes too, although I guess MIME sniff
currently has no say in how <script> loading does not care about the
MIME type.

-- 
http://annevankesteren.nl/

From gphemsley at gmail.com  Fri Nov 16 14:43:32 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Fri, 16 Nov 2012 17:43:32 -0500
Subject: [whatwg] [mimesniff] The X-Content-Type-Options header
In-Reply-To: <CADnb78hebV_4R7pCSxviMgzsLg0b0_RAgXai7zb68wtsyCA2fg@mail.gmail.com>
References: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>
	<CADnb78hebV_4R7pCSxviMgzsLg0b0_RAgXai7zb68wtsyCA2fg@mail.gmail.com>
Message-ID: <CAH4e3M7hjUe8hg5iK6uGD4onK=q+iej5oXkoODc5MEgkAD7Rug@mail.gmail.com>

On Fri, Nov 16, 2012 at 5:28 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Fri, Nov 16, 2012 at 2:19 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
>> In addition, I would like to, if I could, also allow the header to be
>> specified without the 'X-' prefix (so as 'Content-Type-Options'), for
>> that reason (and because of best current practice).
>>
>> Does anyone have any questions, comments, or objections about this issue?
>
> Not sure why you would drop the prefix if it's not supported. Doesn't
> seem like best practice to me to needlessly break compatibility. ;-)
>
> Also, are we sure they are not sniffing still? E.g. how is mislabeled
> image content treated? I vaguely recall a image/png resource that's
> actually a GIF, still working even in the presence of this header.
> <script> probably still executes too, although I guess MIME sniff
> currently has no say in how <script> loading does not care about the
> MIME type.

Well, it was my (unverified) understanding that the header wasn't
widely implemented yet.

Gecko has a bug on file (which notes that it's for parity with Chrome):

https://bugzilla.mozilla.org/show_bug.cgi?id=471020

So my intent was actually to specify exactly what browsers should do,
rather than what they currently do. (This spec is a mixture of both in
that department, modeled off of what Chrome does.)

Regarding your anecdote, it's possible that you were using a browser
that didn't support the header (thus performing the sniffing even when
told not to). If you weren't, though, I think that's Bad?. If browsers
ignore the header, then there's no point in having it.

Unless, of course, we only want to limit it to scriptable media types.
That wasn't what I was originally considering, but it doesn't
necessarily conflict with the IE team's original intent. (Their
example is content marked as 'text/plain' being sniffed as
'text/html'.)

So, what do the implementors think?

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From dbk at google.com  Fri Nov 16 15:26:02 2012
From: dbk at google.com (David Barrett-Kahn)
Date: Fri, 16 Nov 2012 15:26:02 -0800
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <Pine.LNX.4.64.1211161801120.16964@ps20323.dreamhostps.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
	<CAMK=o4eziZ+7qs-OVgAWiPe89UKD_AqtZ1X4v=R527eVhUDgfA@mail.gmail.com>
	<CA+iXHYOL6kM8gVaXm+Vxai5Pdq2hFr-ZTOtHqBg05g+=SaYR=w@mail.gmail.com>
	<Pine.LNX.4.64.1211161801120.16964@ps20323.dreamhostps.com>
Message-ID: <CA+iXHYNQeYtbavABGdwXVtWrV-2aRmxD2NBbtmJrqdb3BugU1w@mail.gmail.com>

Thanks Ian. So here's what confuses me, why is the bar so much higher for
traditional webapps than it is for browser extensions, chrome apps, native
apps, mobile apps or nearly anything else? Extensions, chrome apps, and
mobile apps have a consent experience, but it's hard to argue that users
are making an informed decision there and that the consent experience
really protects them. Native apps have no consent experience at all.

I guess I'm hoping you can point me to some guidelines you've developed or
which you agree with on where the limits of the web sandbox should be.  I'd
rather not force you to re-have a discussion I'm sure you've had far too
many times :-)

Regards,

-Dave

On Fri, Nov 16, 2012 at 10:06 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Thu, 15 Nov 2012, David Barrett-Kahn wrote:
> >
> > Ian, I'd be interested in what you had in mind when you said 'a lot of
> > user opt-in'.
>
> I don't know, exactly. It has to be something where we're confident that
> the user understands that he is about to send sensitive information to a
> stranger.
>
> The concern isn't when this is used by a company like Apple or Facebook;
> the worst such companies are going to do with sensitive data is target ads
> better or make their products more streamlined. The concern is when some
> attacker wants to get information about your company's intranet's
> topology, or wants to know what potentially vulnerable plugins or
> extensions you have installed, or wants to know what software you are
> running, so that they can more precisely target you. Such an attacker can
> trivially provide you with a game to play, and then have the game crash,
> misleading you into thinking they're a perfectly honest game developer and
> causing you to eagerly send them all the sensitive information they want.
>
> These are not hypothetical concerns. Over the last few years, targetted
> attacks of this nature have become much more common and are a real threat.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

-- 
-Dave

From ian at hixie.ch  Fri Nov 16 16:01:18 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 17 Nov 2012 00:01:18 +0000 (UTC)
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
	<CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
	<CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>

Very few of the e-mails on this thread added new information. Please 
remember to not post to the list if you are not adding information that 
has not been previously considered -- just repeating previously provided 
information is not going to change the result, and in the meantime it 
makes it harder for people to read the list.

On Thu, 8 Nov 2012, Steve Faulkner wrote:
> >
> > The reason there is no element <main> in the HTML spec currently is 
> > that there are no use cases for it that aren't already handled
> 
> The use cases data and rationale have been provided [1].
> https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html

This page doesn't seem to list any use cases.

> http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction

This page has the following:

| Enable users to be able to navigate to and recognise the boundaries of 
| the main content area

This is done by <main> (because of the likely authoring failures) no more 
reliably, and possibly in fact less reliably, than is already possible 
with things like <aside>.

http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0067.html
   http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html

| Enable authors to style the main content area of a page specifically.

This is already possible with <div>. It would make sense to have a more 
specific element if there was a cowpath, but there isn't:

http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html

| Enable authors to markup an area of a page as the main content area, 
| that builds on existing authoring practices

This is not a use case.

| Provide a means for browsers to map role, state and property information 
| to a HTML structure representing a common significant distinct content 
| structure.

I don't know what this means. It doesn't sound like a use case, though. 
Use cases are problems users currently face.

| Re-use an existing ARIA semantic that currently has to be bolted on by 
| authors and for which where there is already an existing relationship 
| and use with common HTML authoring practices.

This is not a use case. There's no reason to specify this role in the 
first place, if you use HTML semantics already. (If you did have to 
specify it, the entire Web would be unusable. Clearly that's not viable 
for a user agent or accessibility tool, so they have to be able to handle 
the lack of a "main" role already... and handle it well, for it's the most 
common situation to be in.)

| Bake in to HTML an existing ARIA role semantic which is interoperably 
| supported across browsers and AT and utilised in AT to provide 
| understanding and utility of an HTML content structure, to the benefit 
| of end users.

That's not a use case.

> http://lists.w3.org/Archives/Public/public-html/2012Oct/0109.html

Already responded to that here:

http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html

So again, the reason there is no element <main> in the HTML spec currently 
is that there are no use cases for it that aren't already handled.

> Agreed that people get markup wrong, I don't agree with your supposition 
> that <main> would be just as prone to mistakes as the other elements you 
> cited.

With all due respect, you have to ignore the data to come to that 
conclusion. Look at your own data: authors put this semantic all over the 
place. There is _no_ evidence that they'd do better with <main>.

http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html

> Did the year's old previous discussion take into account id value data or
> skip link data or role=main placement data?

I do not recall the specifics. ARIA didn't exist back then, so clearly it 
wasn't examined, though.

> What the relevant new data clearly indicates is that in approx 80% of 
> cases when authors identify the main area of content it is the part of 
> the content that does not include header, footer or navigation content.

Where do you get this number from?

> It also indicates that where skip links are present or role=main is used 
> their position correlates highly with the use of id values designating 
> the main content area of a page.

How do you determine this correlation? (Are you just using the word 
colloquially?)

What does this correlation mean? Are they all using both incorrectly? 
(That would get you good correlation too.)

What about pages that do not give skip links or role=main? (Pages that use 
those features are going to be disproportionally biased towards competent 
authors, which makes it dangerous to draw conclusions from that sample.)

> furthermore when ARIA role=main is used in 95% [3] of the cases in the 
> data sampled it is used once only which is a clear indicator that 
> authors get how to identify the main content area of a page.

I think that's a wildly optimistic conclusion. Lots of pages only use 
<body> once, that doesn't mean they use it correctly. :-)

> *  use of a descriptive id to value to identify the main content area of a
> web page is common.
> (id="main"|id="content"|id="
> maincontent"|id="content-main"|id="main-content"
> used on 39% of the pages in the sample [2])

As I discuss in the e-mail cited several times above, the area they 
indicate with these IDs is not reliably the "main content". For example, 
it might or might not include the footer, sidebars, navigation links, 
headings, etc.

>  * There is a strong correlation between use of role='main' on an element
> with id values of 'content' or 'main' or permutations. (when used = 101
> pages)  77% were on an element with id values of 'content' or 'main' or
> permutations.

I don't see what this tells us. Obviously if someone is going to mark an 
element as role=main, they'll use the same element for id=main. Doesn't 
mean it's correct use of role=main, nor that it's necessary use. (If they 
can use role=main, seems reasonable to expect them to use modern HTML 
elements too.)

> * There is a strong correlation between use of id values of 'content' or 
> 'main' or permutations as targets for 'skip to content'/'skip to main 
> content' links (when used = 67 pages) 78% of skip link targets # were 
> elements with id values of 'content' or 'main' or permutations.

Again, that seems obvious, but doesn't tell us anything useful.

> * There appears to be a strong correlation in the identification of 
> content areas (with id values of 'content' or 'main' or permutations.) 
> as what is described in the spec as appropriate content to be contained 
> with a <main> element

How do you determine this?

On Fri, 9 Nov 2012, Roger H?gensen wrote:
> 
> I'm wondering if maybe the following might satisfy both "camps" ?
> 
> Example1:
> <!doctype html>
> <html>
> <head>
> <title>test</title>
> </head>
>     <div>div before body</div>
>     <body>body text</body>
>     <div>div after body</div>
> </html>

This wouldn't be Web-compatible due to legacy <body> parsing behaviour.

On Sat, 10 Nov 2012, Mat Carey wrote:
> 
> Personally I would love to have a <main> element because I think there 
> is a really useful purpose; I find it much richer to use 
> <article><header/><main/><footer/></article> than 
> <article><header/><div/><footer/></article> but I have no specific 
> use-cases which are not currently supported just a general feeling that 
> we've documented a number of common idioms and this seems to be one 
> that's missing.

Why do you need an element there at all?

On Sat, 10 Nov 2012, Maciej Stachowiak wrote:
> 
> I personally think <main> would be useful. I don't think it has a huge 
> benefit, but it has modest benefits, like <aside>, <header>, <footer> 
> and <section>. I also think the implementation costs are low. The 
> reasons I think it has some benefits:
> 
> - Even though heuristics (such as the scooby-doo algorithm or even 
> guesses based on role or class, or the layout) will always be necessary 
> in some cases, it's still good to have a simple and relatively 
> trustworthy marker of the main content. This is useful both for 
> accessibility purposes and for other browser features that want to find 
> the main content. In many cases, we have found that even when semantics 
> can be heuristically inferred, having an explicit marker is still 
> useful. For example, you can usually guess that some text is an address, 
> but we still have a microformat that helps identify such data 
> unambiguously.

But we already have this. The main content is whatever content isn't 
marked up as not being main content (anything not marked up with <header>, 
<aside>, <nav>, etc).

> - From a language design perspective, it seems inelegant to identify the 
> main content solely by what it is not. I realize that this is a matter 
> of taste and that tastes may differ. By analogy, in imperative 
> programming languages that have a main function, it is generally marked 
> with as specific name rather than just by not being any of the non-main 
> functions. This is not perfectly analogous, but it still seems 
> motivating to me.

There are plenty of languages where this isn't the case. JavaScript. Bash 
scripting. Perl. Python. Lisp. BASIC. To some extent, Pascal. Assembly. 
ALGOL 68. APL. Erlang. F#. Logo. Etc.

> - The "Scooby-Doo algorithm" is not actually defined in HTML5 afaict so 
> I am not sure what the spec recommends to find the main content or which 
> elements should be excluded.

There's nothing in the spec that talks about "main content" currently. No 
implementor has asked for an algorithm to do that, and I hadn't considered 
it to be something that was needed -- it seems self-evident that the page 
is the content, and if you want to know what the content that isn't, say, 
an <aside> or <nav> block, you just exclude those from the tree.

> I presume that header, nav, footer and aside are excluded. What about 
> address? small? Arbitrary other elements with non-main ARIA landmark 
> roles?

What's the UI you're going for? I don't know that it makes sense to define 
something here. I don't know what we're defining.

> It seems insufficient to me to say that the use case of finding the main 
> content is satisfied by an algorithm that's ambiguous and not actually 
> defined anywhere. Given the state of play, authors have no way to be 
> confident that their main content can be identified correctly, and 
> implementors have no way to know how to find it.

What browser makes any attempt to identify "main content", and what do 
they mean by it?

> - I'm not confident that the sectioning elements in HTML5 exhaustively 
> cover all possible forms of non-main content.

What isn't covered?

> > This idea doesn't seem to address any pressing use-cases. I don't 
> > expect authors to use it as intended consistently enough for it to be 
> > useful in practice for things like Safari's Reader mode. You're stuck 
> > needing to use something like the Scooby-Doo algorithm most of the 
> > time anyways. I don't outright object, but I think our time would be 
> > better spent on addressing more pressing problems with the web 
> > platform.
>
> The same argument could have been made for <article>, but the 
> implementation cost was so low that the benefit didn't have to be huge. 
> I think the same applies to <main>.

The same argument _was_ made for <article>. The exact same argument. It 
was added so that you could indicate the main content. This is even 
mentioned here:

https://developers.google.com/webmasters/state-of-the-web/2005/classes

The <main> element Steve is proposing isn't quite the same as <article>, 
because different people have different ideas of what class="main" is for, 
but <article> could just as easily have been spelt <main>. It was spelt 
<article> because that allowed it to cover some other (more useful) use 
cases as well, such as those around syndication.

On Wed, 14 Nov 2012, Silvia Pfeiffer wrote:
> On Wed, Nov 14, 2012 at 4:25 AM, Tim Leverett <zzzzbov at gmail.com> wrote:
> > > 
> > > Explicit author markup would make such a task so much easier.
> >
> > Only if every author marked up their code correctly. If some authors 
> > use incorrect markup, then an algorithm would still be necessary for 
> > determining if each usage was correct.
> 
> From a browser perspective, if there is one <main> element and it sits 
> within <body>, that would be sufficiently correct.

That's not at all clear. It depends what the use case is. If the use case 
is for helping users of ATs jump to the relevant point, and it turns out 
that pages misuse <main> a lot, or use it suboptimally a lot (like, on 20% 
of pages, as Steve suggests will happen with his stats above, though I 
don't know where they're derived from and am skeptical that it'd be even 
that good) then browsers are going to find themselves forced to find a 
better solution. This is what killed longdesc="", for instance (though in 
the case of longdesc="", the numbers were a lot worse than 20%).

> Whether it's semantically correct for a particular application, that's 
> not something the HTML spec should or could deal with.

I don't know about that, that's one of the spec's main purposes!

> We don't protect people from putting the wrong text in tags - not in 
> microdata, not in <article> or anywhere else.

We can't "protect" them, but we _can_ make it non-conforming.

On Wed, 14 Nov 2012, Tim Leverett wrote:
> 
> Pro: Adding a <main> element will provide a semantic element that 
> developers can use to indicate primary content of a document.

(But this is already possible in other ways.)

This is already possible in two ways:

...or, if you need an element for whatever reason:

> Pro: Assistive technologies can use the <main> element as a means to 
> rapidly navigate to the primary content.

As mentioned above, this is already possible with existing elements, and a 
new element would only help if authors used it reliably. However, there is 
evidence to suggest that <main> wouldn't be reliably used in this way.

> Pro: The <main> element can only be used once per page. This forces the 
> author to decide exactly where the main focus of the page lies, rather 
> than relying on assumptions.

There are plenty of pages with multiple sections with main content; if we 
did introduce it, it would be once-per-section, not once-per-page.

> Con: The <main> element is supposed to exclude content that is 
> repetitious across pages, but content is often interspersed with blocks 
> of advertisements, modules, CTAs and the like.

That's one of the reasons authors are unlikely to use it reliably, yes.

On Thu, 15 Nov 2012, Ian Yang wrote:
>
> That's a good idea. We really need an element to wrap all the <p>s, 
> <ul>s, <ol>s, <figure>s, <table>s ... etc of a blog post.

That's called <article>.

On Wed, 14 Nov 2012, Steve Faulkner wrote:
> 
> The same can be said for any of the structural semantic elements, what 
> we know is that some authors mark up headings, nav, footer, articles etc 
> incorrectly or not at all.

The difference is that misusing those elements doesn't defeat their 
purpose, while misusing <main> leaves it with no reason for being. The use 
cases for <main> rely on it not being misused by the majority of authors. 
The use cases for things like <aside> benefit from it not being misused, 
but are not lost if other authors misuse them.

> What we also know is that user agents do not generally implement 
> heuristics to provide semantic information to users, they rely upon 
> explicit markup to expose semantic structures to convey meaning and 
> provide navigation of content.

The user agents that do the most to get semantics out of HTML pages, 
namely search engines, use absolutely gigantic amounts of heuristics.

From ian at hixie.ch  Fri Nov 16 16:04:00 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 17 Nov 2012 00:04:00 +0000 (UTC)
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <CA+iXHYNQeYtbavABGdwXVtWrV-2aRmxD2NBbtmJrqdb3BugU1w@mail.gmail.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
	<CAMK=o4eziZ+7qs-OVgAWiPe89UKD_AqtZ1X4v=R527eVhUDgfA@mail.gmail.com>
	<CA+iXHYOL6kM8gVaXm+Vxai5Pdq2hFr-ZTOtHqBg05g+=SaYR=w@mail.gmail.com>
	<Pine.LNX.4.64.1211161801120.16964@ps20323.dreamhostps.com>
	<CA+iXHYNQeYtbavABGdwXVtWrV-2aRmxD2NBbtmJrqdb3BugU1w@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211170001590.16964@ps20323.dreamhostps.com>

On Fri, 16 Nov 2012, David Barrett-Kahn wrote:
>
> Thanks Ian. So here's what confuses me, why is the bar so much higher 
> for traditional webapps than it is for browser extensions, chrome apps, 
> native apps, mobile apps or nearly anything else?

Browser extensions, chrome apps, native apps, and mobile apps aren't 
anywhere near as secure as Web apps.

The bar shouldn't be any lower for them than for the Web, but that it is 
is one of the Web's biggest strengths. You can, by and large, follow any 
random link, and be assured that you're not going to get scammed (modulo 
security bugs). If you just install any random native program you come 
across, your machine is going to become a nest of malware.

> Extensions, chrome apps, and mobile apps have a consent experience, but 
> it's hard to argue that users are making an informed decision there and 
> that the consent experience really protects them. Native apps have no 
> consent experience at all.

Right. Compare the average amount of malware on a Windows machine to that 
on a Chrome OS machine. :-)

> I guess I'm hoping you can point me to some guidelines you've developed 
> or which you agree with on where the limits of the web sandbox should 
> be.  I'd rather not force you to re-have a discussion I'm sure you've 
> had far too many times :-)

I don't think there's anything formally written down.

From waldron.rick at gmail.com  Fri Nov 16 17:23:33 2012
From: waldron.rick at gmail.com (Rick Waldron)
Date: Fri, 16 Nov 2012 20:23:33 -0500
Subject: [whatwg] Canvas in Workers
In-Reply-To: <Pine.LNX.4.64.1211162147040.16964@ps20323.dreamhostps.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
	<CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>
	<Pine.LNX.4.64.1211162147040.16964@ps20323.dreamhostps.com>
Message-ID: <CAHfnhfq0cgZSVgc5e+DuU0QGQ2+HykTiNN0yiLgKfydjjuK-4A@mail.gmail.com>

On Fri, Nov 16, 2012 at 4:48 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 16 Nov 2012, Rick Waldron wrote:
> > On Fri, Nov 16, 2012 at 4:11 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Fri, 16 Nov 2012, Rick Waldron wrote:
> > > > On Fri, Nov 16, 2012 at 3:25 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > > >
> > > > >     var proxy = canvas.transferControlToProxy());
> > > >
> > > > <bikeshed>
> > > >
> > > > Proxy with a capital P is an API in ES6 for creating Proxy objects.
> > > > While I recognize that this is obviously just a conceptual sketch of
> > > > your idea and that you're merely following the camel case tradition,
> now
> > > > is probably the best time to be informed of potential naming
> conflicts.
> > >
> > > The word Proxy is used all over the place on the Web platform, I'm not
> too
> > > worried about that. Right now the object returned above is
> "CanvasProxy",
> > > which is the kind of proxy that it refers to. I'm certainly open to
> > > another name, any suggestions?
> >
> > CanvasProxy is a fine disambiguation.
>
> Do you think we should rename the method above to say that too?
>
> "canvas.transferControlToCanvasProxy()" is a bit verbose. :-)
>
> I had shortened it to just "canvas.transferControlToProxy" on the
>

Is there any other thing that control can be transferred to?
canvas.transferControl() would be sufficient...

Rick

> assumption that the fact that it was called on a canvas would disambiguate
> that it was a canvas proxy, but I'm certainly open to other suggestions.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

From annevk at annevk.nl  Fri Nov 16 18:03:12 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 16 Nov 2012 18:03:12 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
Message-ID: <CADnb78jKzPM2JHZQxZ-OhdCeG6cLNYEjaek4k-c-54UQ03-46Q@mail.gmail.com>

On Thu, Nov 8, 2012 at 6:22 AM, Alex Russell <slightlyoff at google.com> wrote:
> Next, nicely done on having a meaningful constructor! I do wonder if the
> "url" parameter should be optional as well as the base, since you may either
> want to build a URL using a URL object (to be serialized later).

That seems potentially difficult as the components are inter-dependent.

> GetWithEmptyPath() & GetOrigin() (despite their terrible C++ naming) are
> hugely useful for doing comparisons. I could imagine that there's some

Something seems omitted here. What exactly is GetWithEmptyPath()? As
Adam mentioned we have origin covered.

> "username" and "password" properties are missing

Added.

> There aren't any provided comparison functions. I.e., there's no way to tell
> if two URL objects reference the same absolute URL, if one references a path
> in the same domain, etc.

Would need more details here on what this is going to be used for as
there are many possible ways to compare URLs (starting with simple
string comparison, which is supported :-)).

-- 
http://annevankesteren.nl/

From faulkner.steve at gmail.com  Sat Nov 17 02:00:59 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Sat, 17 Nov 2012 10:00:59 +0000
Subject: [whatwg] A plea to Hixie to adopt <main>
Message-ID: <CA+ri+Vk97pZc6cXazb5BZcUkPG5A8=u89RkznfASthQ=LviGmw@mail.gmail.com>

Hi Ian,

Responses in line.

FYI

For any implementers or other interested parties the <main> element
specification [2] is currently in a call for consensus to publish as a
first public working draft (over at the W3C) [3]

> > On Thu, 8 Nov 2012, Steve Faulkner wrote:
>
> >
> >
> > >
> http://www.w3.org/html/wg/wiki/User:Sfaulkne/main-usecases#Introduction
> >
> > This page has the following:
> >
> > | Enable users to be able to navigate to and recognise the boundaries of
> > | the main content area
> >
> > This is done by <main> (because of the likely authoring failures) no more
> > reliably, and possibly in fact less reliably, than is already possible
> > with things like <aside>.
>

Requiring a the presence of number of elements and having those elements
used correctly, (some of which from anecdotal reports author,s find
difficult to use correctly),  to provide an indication of something else,
appears wholey more prone to failure than using one element that as specced
[2] is clear in its use and based on current authoring practices.

> >
> >
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0067.html
> >
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html
> >
> >
> > | Enable authors to style the main content area of a page specifically.
> >
> > This is already possible with <div>. It would make sense to have a more
> > specific element if there was a cowpath, but there isn't:
>

there is a clear cowpath and the data has been provided.

> > > Agreed that people get markup wrong, I don't agree with your
> supposition
> > > that <main> would be just as prone to mistakes as the other elements
> you
> > > cited.
> >
> > With all due respect, you have to ignore the data to come to that
> > conclusion. Look at your own data: authors put this semantic all over the
> > place. There is _no_ evidence that they'd do better with <main>.
>

I have looked at the data and no they do not put <div id=main content> all
over the place they put it approx 80% of the time in the right place.

> >
> >
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Oct/0162.html
> >
> >
> > > Did the year's old previous discussion take into account id value data
> or
> > > skip link data or role=main placement data?
> >
> > I do not recall the specifics. ARIA didn't exist back then, so clearly it
> > wasn't examined, though.
> >
> >
> > > What the relevant new data clearly indicates is that in approx 80% of
> > > cases when authors identify the main area of content it is the part of
> > > the content that does not include header, footer or navigation content.
> >
> > Where do you get this number from?
>

I looked at a couple of hundred pages [1] in the sample that I have added
styling to show the use of id=main or id=content noting the borders and
what content is and is not contained within them.

> >
> > > It also indicates that where skip links are present or role=main is
> used
> > > their position correlates highly with the use of id values designating
> > > the main content area of a page.
> >
> > How do you determine this correlation? (Are you just using the word
> > colloquially?)
> >
> > What does this correlation mean? Are they all using both incorrectly?
> > (That would get you good correlation too.)
> >
> > What about pages that do not give skip links or role=main? (Pages that
> use
> > those features are going to be disproportionally biased towards competent
> > authors, which makes it dangerous to draw conclusions from that sample.
> >
>

see above , approx 80% I have provided the data set from which my
statements are derived, if you want to disprove them you can analyse the
same data set.

> > > furthermore when ARIA role=main is used in 95% [3] of the cases in the
> > > data sampled it is used once only which is a clear indicator that
> > > authors get how to identify the main content area of a page.
> >
> > I think that's a wildly optimistic conclusion. Lots of pages only use
> > <body> once, that doesn't mean they use it correctly. :-)
>

again I have provided the data set if you disagree you can analyse the data.

> >
> > > *  use of a descriptive id to value to identify the main content area
> of a
> > > web page is common.
> > > (id="main"|id="content"|id="
> > > maincontent"|id="content-main"
>
> |id="main-content"
> > used on 39% of the pages in the sample [2])
>
> As I discuss in the e-mail cited several times above, the area they
> indicate with these IDs is not reliably the "main content". For example,
> it might or might not include the footer, sidebars, navigation links,
> headings, etc.
>

well no, you are making suppositions again, the data set is available for
analysis if you disagree with my conclusions based on my analysis of the
data you can run your own analysis.

>
>
> >  * There is a strong correlation between use of role='main' on an element
> > with id values of 'content' or 'main' or permutations. (when used = 101
> > pages)  77% were on an element with id values of 'content' or 'main' or
> > permutations.
>
> I don't see what this tells us. Obviously if someone is going to mark an
> element as role=main, they'll use the same element for id=main. Doesn't
> mean it's correct use of role=main, nor that it's necessary use. (If they
> can use role=main, seems reasonable to expect them to use modern HTML
> elements too.)
>
>
analyse the data and it shows that in a good majority of cases it is
correct, which is why it is useful information.

>
> > * There is a strong correlation between use of id values of 'content' or
> > 'main' or permutations as targets for 'skip to content'/'skip to main
> > content' links (when used = 67 pages) 78% of skip link targets # were
> > elements with id values of 'content' or 'main' or permutations.
>
> Again, that seems obvious, but doesn't tell us anything useful.
>
>
again,analyse the data and it shows that in a good majority of cases it is
correct, which is why it is useful information.

>
> > * There appears to be a strong correlation in the identification of
> > content areas (with id values of 'content' or 'main' or permutations.)
> > as what is described in the spec as appropriate content to be contained
> > with a <main> element
>
> How do you determine this?
>

again, I manually reviewed a couple of hundred pages form the sample
looking at what content is and is not contained within content areas (with
id values of 'content' or 'main' or permutations.)

> On Wed, 14 Nov 2012, Steve Faulkner wrote:
> >
> > The same can be said for any of the structural semantic elements, what
> > we know is that some authors mark up headings, nav, footer, articles etc
> > incorrectly or not at all.
>
> The difference is that misusing those elements doesn't defeat their
> purpose, while misusing <main> leaves it with no reason for being. The use
> cases for <main> rely on it not being misused by the majority of authors.
> The use cases for things like <aside> benefit from it not being misused,
> but are not lost if other authors misuse them.
>
>
Misusing those elements does defeat their purpose as useful semantic
identifiers for users who benefit from the semantics. It is difficult to
know what other purposes they may or may not have as thee use cases are not
defined in

>
> > What we also know is that user agents do not generally implement
> > heuristics to provide semantic information to users, they rely upon
> > explicit markup to expose semantic structures to convey meaning and
> > provide navigation of content.
>
> The user agents that do the most to get semantics out of HTML pages,
> namely search engines, use absolutely gigantic amounts of heuristics.
>

the usefulness of the main to search engines has not been a  consideration
in tis development, the focus has been on its usefulness to users and
authors. Having said that I am certainly open to exploring the
possibilities. I had a conversation with one rep from search engine
provider and he indicated that they would consider using it in thier search
algorithm.

Ian wrote:

There are plenty of pages with multiple sections with main content; if we
> did introduce it, it would be once-per-section, not once-per-page.
>

If you have any good use cases for allowing multiple <main> elements per
page please file a bug agains the spec [2]

[1] http://www.html5accessibility.com/tests/HTML5-main-content/
[2]
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
[3] http://lists.w3.org/Archives/Public/public-html/2012Nov/0129.html
-- 
with regards

Steve Faulkner
Technical Director - TPG

From w3c at adambarth.com  Sat Nov 17 10:17:35 2012
From: w3c at adambarth.com (Adam Barth)
Date: Sat, 17 Nov 2012 10:17:35 -0800
Subject: [whatwg] [mimesniff] The X-Content-Type-Options header
In-Reply-To: <CAH4e3M7hjUe8hg5iK6uGD4onK=q+iej5oXkoODc5MEgkAD7Rug@mail.gmail.com>
References: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>
	<CADnb78hebV_4R7pCSxviMgzsLg0b0_RAgXai7zb68wtsyCA2fg@mail.gmail.com>
	<CAH4e3M7hjUe8hg5iK6uGD4onK=q+iej5oXkoODc5MEgkAD7Rug@mail.gmail.com>
Message-ID: <CAJE5ia_mBQNmBRweuZT01S6=FfLy38hb7JD+5Tq2GvNw7LYRuA@mail.gmail.com>

On Fri, Nov 16, 2012 at 2:43 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> On Fri, Nov 16, 2012 at 5:28 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
>> On Fri, Nov 16, 2012 at 2:19 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
>>> In addition, I would like to, if I could, also allow the header to be
>>> specified without the 'X-' prefix (so as 'Content-Type-Options'), for
>>> that reason (and because of best current practice).
>>>
>>> Does anyone have any questions, comments, or objections about this issue?
>>
>> Not sure why you would drop the prefix if it's not supported. Doesn't
>> seem like best practice to me to needlessly break compatibility. ;-)
>>
>> Also, are we sure they are not sniffing still? E.g. how is mislabeled
>> image content treated? I vaguely recall a image/png resource that's
>> actually a GIF, still working even in the presence of this header.
>> <script> probably still executes too, although I guess MIME sniff
>> currently has no say in how <script> loading does not care about the
>> MIME type.
>
> Well, it was my (unverified) understanding that the header wasn't
> widely implemented yet.
>
> Gecko has a bug on file (which notes that it's for parity with Chrome):
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=471020
>
> So my intent was actually to specify exactly what browsers should do,
> rather than what they currently do. (This spec is a mixture of both in
> that department, modeled off of what Chrome does.)
>
> Regarding your anecdote, it's possible that you were using a browser
> that didn't support the header (thus performing the sniffing even when
> told not to). If you weren't, though, I think that's Bad?. If browsers
> ignore the header, then there's no point in having it.
>
> Unless, of course, we only want to limit it to scriptable media types.
> That wasn't what I was originally considering, but it doesn't
> necessarily conflict with the IE team's original intent. (Their
> example is content marked as 'text/plain' being sniffed as
> 'text/html'.)
>
> So, what do the implementors think?

I would prefer if the spec described what implementations actually do
rather than your opinion about what they should do.  To answer your
specific questions:

1) Don't bother dropping the "X-".  Everyone who implements this
feature uses the X- and dropping it is just going to cause unnecessary
interoperability problems.

2) When deciding what to specify about values other than nosniff,
please reverse engineer the existing implementations rather than just
making up how you wish they behave.

3) With regards to <img>, Chromium does not consider the
X-Content-Type-Options header when determining what to do, but IE
does.  It's not clear to me what the spec should say given that there
is lack of interop here and I don't think you have buy-in from either
implementor to change the current behavior.

4) With regards to <script>, Chromium does not consider the
X-Content-Type-Options header when determining what to do.  I'm not
sure whether IE does.  You'll need to do some reverse engineering to
figure it out.

5) With regards to <iframe> and the main frame, both IE and Chromium
do consider the X-Content-Type-Options header.

6) One of the more interesting cases to study is what happens when the
server both supplies an X-Content-Type-Options header and also fails
to supply a Content-Type header.  My recollection is that both IE and
Chromium treat the response as text/plain regardless of its contents.
However, please don't take my recollection as fact.  Instead, you
should reverse engineer the implementations in question.

Adam

From bruant.d at gmail.com  Sun Nov 18 14:34:58 2012
From: bruant.d at gmail.com (David Bruant)
Date: Sun, 18 Nov 2012 23:34:58 +0100
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
Message-ID: <50A96292.7080201@gmail.com>

Hi,

I feel the URLQuery object could be a regular object. Or maybe an ES6 
Map. If not an ES6 Map, maybe its API could be mapped exactly to ES6 
Map. It would increase interoperability.

David

From annevk at annevk.nl  Sun Nov 18 15:17:54 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 19 Nov 2012 00:17:54 +0100
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50A96292.7080201@gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
Message-ID: <CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>

On Sun, Nov 18, 2012 at 11:34 PM, David Bruant <bruant.d at gmail.com> wrote:
> I feel the URLQuery object could be a regular object. Or maybe an ES6 Map.
> If not an ES6 Map, maybe its API could be mapped exactly to ES6 Map. It
> would increase interoperability.

It cannot be a regular object because it modifies an underlying
string. I suppose the same goes for ES6 Map. And URLQuery represents
an ordered list of key-value pairs so I'm not sure how close it can
be.

-- 
http://annevankesteren.nl/

From jackalmage at gmail.com  Sun Nov 18 15:47:27 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Sun, 18 Nov 2012 15:47:27 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
Message-ID: <CAAWBYDBRYvxa-uzBbp2AHYMMMPP2qe6GhEAYs1m8n+JiWKdnGA@mail.gmail.com>

On Sun, Nov 18, 2012 at 3:17 PM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Sun, Nov 18, 2012 at 11:34 PM, David Bruant <bruant.d at gmail.com> wrote:
>> I feel the URLQuery object could be a regular object. Or maybe an ES6 Map.
>> If not an ES6 Map, maybe its API could be mapped exactly to ES6 Map. It
>> would increase interoperability.
>
> It cannot be a regular object because it modifies an underlying
> string. I suppose the same goes for ES6 Map. And URLQuery represents
> an ordered list of key-value pairs so I'm not sure how close it can
> be.

URLQuery is already *almost* duck-typed as a Map.  It's only missing:
* the has() function (strictly unnecessary given the restriction that
values are all strings, but nearly free, and useful for API
consistency)
* the iteration functions keys(), values(), and items().

It would be nice if, as previously mentioned, you could do a bulk-set.
 Just use the same meaning as the Map constructor, where it takes any
iterable, converts the keys and values to strings, and goes through it
in iteration order, adding each pair.

Even though it has magic behavior underneath, I think it should still
be possible to be a subclass of Map, which would be the best thing.
Then, the missing parts I described above would come for free.

~TJ

From ian at invigoreight.com  Sun Nov 18 21:22:07 2012
From: ian at invigoreight.com (Ian Yang)
Date: Mon, 19 Nov 2012 13:22:07 +0800
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
	<CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
	<CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>
	<Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>
Message-ID: <CABr1Fse4Z0v-ALmFVh72GcMTEe8QOx_NyimA1u05aX=tPKC5uQ@mail.gmail.com>

On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson <ian at hixie.ch> wrote:

>
> On Thu, 15 Nov 2012, Ian Yang wrote:
> >
> > That's a good idea. We really need an element to wrap all the <p>s,
> > <ul>s, <ol>s, <figure>s, <table>s ... etc of a blog post.
>
> That's called <article>.
>

Thanks Hickson. Actually I had turned down my own opinion (
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0182.html
).

And isn't <article> used to wrap an entire blog post? Like this:

Are you suggesting that we code it like the following one?

Regards,
Ian Yang

From gman at google.com  Sun Nov 18 21:26:11 2012
From: gman at google.com (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=)
Date: Mon, 19 Nov 2012 14:26:11 +0900
Subject: [whatwg] Canvas in Workers
In-Reply-To: <CAHfnhfq0cgZSVgc5e+DuU0QGQ2+HykTiNN0yiLgKfydjjuK-4A@mail.gmail.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
	<CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>
	<Pine.LNX.4.64.1211162147040.16964@ps20323.dreamhostps.com>
	<CAHfnhfq0cgZSVgc5e+DuU0QGQ2+HykTiNN0yiLgKfydjjuK-4A@mail.gmail.com>
Message-ID: <CAKZ+BNoFMP8PqnfBnfK9PEPALip4mxc9GcRzcE_AO=Sd0z5cfw@mail.gmail.com>

Sorry if this is clear in the specs but can you explain how sizing the
canvas works?

setTimeout(function() {
        canvas.width = 200;   // does this work? What happens?
    }, 4000);
   </script>

// clock.js worker
   onmessage = function (event) {
     var context = new CanvasRenderingContext2d();
     event.data.setContext(context);
     setInterval(function () {
       context.width = 400;  // Can I do this? What happens when I do?
       context.clearRect(0, 0, context.width, context.height);
       context.fillText(0, 100, new Date());
       context.commit();
     }, 1000);
   };

On Sat, Nov 17, 2012 at 10:23 AM, Rick Waldron <waldron.rick at gmail.com>wrote:

> On Fri, Nov 16, 2012 at 4:48 PM, Ian Hickson <ian at hixie.ch> wrote:
>
> > On Fri, 16 Nov 2012, Rick Waldron wrote:
> > > On Fri, Nov 16, 2012 at 4:11 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > > On Fri, 16 Nov 2012, Rick Waldron wrote:
> > > > > On Fri, Nov 16, 2012 at 3:25 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > > > >
> > > > > >     var proxy = canvas.transferControlToProxy());
> > > > >
> > > > > <bikeshed>
> > > > >
> > > > > Proxy with a capital P is an API in ES6 for creating Proxy objects.
> > > > > While I recognize that this is obviously just a conceptual sketch
> of
> > > > > your idea and that you're merely following the camel case
> tradition,
> > now
> > > > > is probably the best time to be informed of potential naming
> > conflicts.
> > > >
> > > > The word Proxy is used all over the place on the Web platform, I'm
> not
> > too
> > > > worried about that. Right now the object returned above is
> > "CanvasProxy",
> > > > which is the kind of proxy that it refers to. I'm certainly open to
> > > > another name, any suggestions?
> > >
> > > CanvasProxy is a fine disambiguation.
> >
> > Do you think we should rename the method above to say that too?
> >
> > "canvas.transferControlToCanvasProxy()" is a bit verbose. :-)
> >
> > I had shortened it to just "canvas.transferControlToProxy" on the
> >
>
> Is there any other thing that control can be transferred to?
> canvas.transferControl() would be sufficient...
>
> Rick
>
>
> > assumption that the fact that it was called on a canvas would
> disambiguate
> > that it was a canvas proxy, but I'm certainly open to other suggestions.
> >
> > --
> > Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> > http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> > Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
> >
>

From bruant.d at gmail.com  Sun Nov 18 23:36:22 2012
From: bruant.d at gmail.com (David Bruant)
Date: Mon, 19 Nov 2012 08:36:22 +0100
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
Message-ID: <50A9E176.2010906@gmail.com>

Le 19/11/2012 00:17, Anne van Kesteren a ?crit :
> On Sun, Nov 18, 2012 at 11:34 PM, David Bruant <bruant.d at gmail.com> wrote:
>> I feel the URLQuery object could be a regular object. Or maybe an ES6 Map.
>> If not an ES6 Map, maybe its API could be mapped exactly to ES6 Map. It
>> would increase interoperability.
> It cannot be a regular object because it modifies an underlying
> string.
An ES6 proxy could do the trick here.

> I suppose the same goes for ES6 Map.
As Tab suggested, a Map subclass could certainly work

> And URLQuery represents
> an ordered list of key-value pairs so I'm not sure how close it can
> be.
"ordered list of key-value pairs"
=> Both objects and maps can be ordered list of key-value pairs (objects 
can be more with getters and setters, but we don't need to care about that)
The ordered part for objects wasn't true in ES5 (implementation specific 
order), but is considered for ES6 [1] since all web engines do the same 
order which some content relies on, making it a de facto standard.

David

[1] http://wiki.ecmascript.org/doku.php?id=strawman:enumeration

From faulkner.steve at gmail.com  Mon Nov 19 04:40:32 2012
From: faulkner.steve at gmail.com (Steve Faulkner)
Date: Mon, 19 Nov 2012 12:40:32 +0000
Subject: [whatwg] Use of article to identify the main content of a web page
 (was Re: A plea to Hixie to adopt <main>)
Message-ID: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>

Hi Ian,

hixies suggestion to use article to act as a main content identifier [3] is
incorrect, as per the HTML spec [1]

The article element represents a self-contained composition in a document,
> page, application, or site and that is, in principle, independently
> distributable or reusable, e.g. in syndication. This could be a forum post,
> a magazine or newspaper article, a blog entry, a user-submitted comment, an
> interactive widget or gadget, or any other independent item of content.
>

The main element as per the main  element spec [2]:

The main element represents the main content section of the body of a
> document or application. The main content section consists of content that
> is directly related to or expands upon the central topic of a document or
> central functionality of an application.
>

The article and main roles as defined in ARIA  have distinct
characteristics and those distinctions are also expressed via  how they
(and the article element) are exposed via accessibility APIs in browsers.

[1]
http://dev.w3.org/html5/spec/the-article-element.html#the-article-element
[2]
https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
[3]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0221.html

-- 
with regards

Steve Faulkner
Technical Director - TPG

From bzbarsky at MIT.EDU  Mon Nov 19 05:38:49 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 19 Nov 2012 08:38:49 -0500
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50A9E176.2010906@gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com>
Message-ID: <50AA3669.3040607@mit.edu>

On 11/19/12 2:36 AM, David Bruant wrote:
> An ES6 proxy could do the trick here.

But then it's not a Map at all, right?  It's a proxy for maybe a Map, 
maybe something else.  In what sense would it be a Map at that point?

>> I suppose the same goes for ES6 Map.
> As Tab suggested, a Map subclass could certainly work

How close are "subclasses" to not being vaporware (both in spec and 
implementation terms)?  Speccing things in terms of vaporware makes them 
pretty hard to implement in actual implementations...  Doesn't mean we 
shouldn't do it, but I'm a bit wary of it, in general.

> The ordered part for objects wasn't true in ES5 (implementation specific
> order), but is considered for ES6 [1] since all web engines do the same
> order

Except they don't.  Here's a trivial example:

var obj = {};
   obj["2"] = 5;
   obj["1"] = 0;

which is handled differently by different UAs.  The "same order" bit is 
only true for property names that don't look like array indices.  Per 
proposed spec you linked to, by the way, this will enumerate properties 
in the order "1" followed by "2".

Of course nothing really stops pages from using url parameters whose 
names look like array indices.  So if we want ordered here, we just 
can't use a object to do it.

-Boris

From ian at invigoreight.com  Mon Nov 19 06:38:26 2012
From: ian at invigoreight.com (Ian Yang)
Date: Mon, 19 Nov 2012 22:38:26 +0800
Subject: [whatwg] Use of article to identify the main content of a web
 page (was Re: A plea to Hixie to adopt <main>)
In-Reply-To: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>
References: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>
Message-ID: <CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>

On Mon, Nov 19, 2012 at 8:40 PM, Steve Faulkner <faulkner.steve at gmail.com>wrote:

> Hi Ian,
>
> hixies suggestion to use article to act as a main content identifier [3] is
> incorrect, as per the HTML spec [1]
>
> The article element represents a self-contained composition in a document,
> > page, application, or site and that is, in principle, independently
> > distributable or reusable, e.g. in syndication. This could be a forum
> post,
> > a magazine or newspaper article, a blog entry, a user-submitted comment,
> an
> > interactive widget or gadget, or any other independent item of content.
> >
>
> The main element as per the main  element spec [2]:
>
> The main element represents the main content section of the body of a
> > document or application. The main content section consists of content
> that
> > is directly related to or expands upon the central topic of a document or
> > central functionality of an application.
> >
>
> The article and main roles as defined in ARIA  have distinct
> characteristics and those distinctions are also expressed via  how they
> (and the article element) are exposed via accessibility APIs in browsers.
>
> [1]
> http://dev.w3.org/html5/spec/the-article-element.html#the-article-element
> [2]
> https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
> [3]
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0221.html
>

Thanks Steve for explanation. Could you please suggest an appropriate
element for the wrapper of the content of a blog post?

Regards,
Ian Yang

From bruant.d at gmail.com  Mon Nov 19 08:00:10 2012
From: bruant.d at gmail.com (David Bruant)
Date: Mon, 19 Nov 2012 17:00:10 +0100
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50AA3669.3040607@mit.edu>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
Message-ID: <50AA578A.5040702@gmail.com>

Le 19/11/2012 14:38, Boris Zbarsky a ?crit :
> On 11/19/12 2:36 AM, David Bruant wrote:
>> An ES6 proxy could do the trick here.
>
> But then it's not a Map at all, right?  It's a proxy for maybe a Map, 
> maybe something else.  In what sense would it be a Map at that point?
I initially suggested either objects or maps. ES6 proxy was a followup 
for the idea of objects.

>>> I suppose the same goes for ES6 Map.
>> As Tab suggested, a Map subclass could certainly work
>
> How close are "subclasses" to not being vaporware (both in spec and 
> implementation terms)?
I don't understand what you mean by vaporware. ES6 Maps are a reality in 
Firefox and Chrome (behind a flag for the latter). Subclassing of ES6 
maps will be possible as soon as ES6 classes do (which I admit are still 
unimplemented)... well... it's actually possible today with __proto__ I 
guess.

> Speccing things in terms of vaporware makes them pretty hard to 
> implement in actual implementations...  Doesn't mean we shouldn't do 
> it, but I'm a bit wary of it, in general.
It's still possible for the spec to define an API that maps (no pun) the 
ES6 Map API (and does some additional magic). For those who'd care 
enough, it'll be possible to make this object a map.
If not an ES6 map, the same API will be good enough to avoid API diversity.

>
>> The ordered part for objects wasn't true in ES5 (implementation specific
>> order), but is considered for ES6 [1] since all web engines do the same
>> order
>
> Except they don't.  Here's a trivial example:
>
>   var obj = {};
>   obj["2"] = 5;
>   obj["1"] = 0;
>
> which is handled differently by different UAs.  The "same order" bit 
> is only true for property names that don't look like array indices.  
> Per proposed spec you linked to, by the way, this will enumerate 
> properties in the order "1" followed by "2".
Interesting, I thought the proposal was meant to capture de facto 
standard. Did UAs converge for that behavior recently? More 
specifically, what does IE9 do? (I guess oldIE are the ones diverging 
from the others?)

> Of course nothing really stops pages from using url parameters whose 
> names look like array indices.  So if we want ordered here, we just 
> can't use a object to do it.
Indeed. I have to admit, I was also worried about __proto__ and 
__defineGetter__ too, because they could have ended up being sources of 
security issues.

If it's an ES6 map or interoperable API, that's fine by me.

David

From bzbarsky at MIT.EDU  Mon Nov 19 08:16:23 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 19 Nov 2012 11:16:23 -0500
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50AA578A.5040702@gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
	<50AA578A.5040702@gmail.com>
Message-ID: <50AA5B57.7060605@mit.edu>

On 11/19/12 11:00 AM, David Bruant wrote:
>> How close are "subclasses" to not being vaporware (both in spec and
>> implementation terms)?
> I don't understand what you mean by vaporware. ES6 Maps are a reality in
> Firefox and Chrome (behind a flag for the latter).

Yes, I know that.

> Subclassing of ES6
> maps will be possible as soon as ES6 classes do (which I admit are still
> unimplemented)

Yes, that's what I mean by "vaporware".  ;)

> ... well... it's actually possible today with __proto__ I guess.

Is it?  It's not terrible possible for arrays, right?  Have we checked 
that it is for maps?

> It's still possible for the spec to define an API that maps (no pun) the
> ES6 Map API (and does some additional magic). For those who'd care
> enough, it'll be possible to make this object a map.

So... the question is whether the spec will require that this object 
"is" a Map, whatever that means.

> If not an ES6 map, the same API will be good enough to avoid API diversity.

I have no problem with "same API".  The issue is how to define this in a 
way that UAs actually end up interoperable in the end.  If some use Map 
and some don't, that's not exactly great.

> Interesting, I thought the proposal was meant to capture de facto
> standard. Did UAs converge for that behavior recently? More
> specifically, what does IE9 do? (I guess oldIE are the ones diverging
> from the others?)

All UAs agree on ordering of non-index properties.

For index properties, they don't agree in all sorts of ways.  The 
behaviors I know about:

1)  V8 enumerates indexed properties in index order always, for all
     objects, as far as I know.
2)  Spidermonkey enumerates indexed properties on "fast" arrays (the
     ones that have no non-index props and don't have too many holes,
     and some other conditions) in index order.  In all other cases it
     enumerates them in set order, where set order when an array
     transitions from "fast" to "slow" is index order.  I believe we
     plan to change this behavior to match that of V8 sometime, but the
     timeframe is many months at best.
3)  JSC enumerates indexed properties in set order on my testcase
     earlier in this thread.  I didn't experiment more, because frankly
     you can do that just as well as I can.  ;)
4)  Carakan enumerates indexed properties in index order on my small
     testcase.  Again, further experimentation is open to anyone who
     cares.

Basically, the spec here codified the de-facto standard in the case 
where there was interop (non-index properties) and just picked a random 
behavior from the wide range of available behaviors for the case where 
there was so little interop that it was clear the web didn't depend on 
any particular behavior too much (index properties).  In particular, the 
V8 behavior was picked, as far as I can tell.

-Boris

From jackalmage at gmail.com  Mon Nov 19 08:16:45 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 19 Nov 2012 08:16:45 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50AA3669.3040607@mit.edu>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
Message-ID: <CAAWBYDDszLNjqprz6qMxOoMFbpv7cQLVvQ26bV=X9rBDiMCtXQ@mail.gmail.com>

On Mon, Nov 19, 2012 at 5:38 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 11/19/12 2:36 AM, David Bruant wrote:
>>> I suppose the same goes for ES6 Map.
>>
>> As Tab suggested, a Map subclass could certainly work
>
> How close are "subclasses" to not being vaporware (both in spec and
> implementation terms)?  Speccing things in terms of vaporware makes them
> pretty hard to implement in actual implementations...  Doesn't mean we
> shouldn't do it, but I'm a bit wary of it, in general.

Subclasses aren't anything new - we're just referring to the standard
prototype-based subclassing.

~TJ

From bzbarsky at MIT.EDU  Mon Nov 19 08:19:17 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 19 Nov 2012 11:19:17 -0500
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CAAWBYDDszLNjqprz6qMxOoMFbpv7cQLVvQ26bV=X9rBDiMCtXQ@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
	<CAAWBYDDszLNjqprz6qMxOoMFbpv7cQLVvQ26bV=X9rBDiMCtXQ@mail.gmail.com>
Message-ID: <50AA5C05.9080607@mit.edu>

On 11/19/12 11:16 AM, Tab Atkins Jr. wrote:
> Subclasses aren't anything new - we're just referring to the standard
> prototype-based subclassing.

OK.  That's different from ES6 classes/subclasses, so it might be good 
to get terminology straight here to reduce confusion....

-Boris

From jackalmage at gmail.com  Mon Nov 19 08:20:43 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 19 Nov 2012 08:20:43 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50AA5C05.9080607@mit.edu>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
	<CAAWBYDDszLNjqprz6qMxOoMFbpv7cQLVvQ26bV=X9rBDiMCtXQ@mail.gmail.com>
	<50AA5C05.9080607@mit.edu>
Message-ID: <CAAWBYDDBSZZngGA9V5Kz9TT+Gh=Hy5+D5TY+Lsecq22BueZTvA@mail.gmail.com>

On Mon, Nov 19, 2012 at 8:19 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 11/19/12 11:16 AM, Tab Atkins Jr. wrote:
>> Subclasses aren't anything new - we're just referring to the standard
>> prototype-based subclassing.
>
> OK.  That's different from ES6 classes/subclasses, so it might be good to
> get terminology straight here to reduce confusion....

To a first approximation, they shouldn't be.  ES6 classes desugar into
functions and prototypes.

~TJ

From bzbarsky at MIT.EDU  Mon Nov 19 08:22:15 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 19 Nov 2012 11:22:15 -0500
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <CAAWBYDDBSZZngGA9V5Kz9TT+Gh=Hy5+D5TY+Lsecq22BueZTvA@mail.gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
	<CAAWBYDDszLNjqprz6qMxOoMFbpv7cQLVvQ26bV=X9rBDiMCtXQ@mail.gmail.com>
	<50AA5C05.9080607@mit.edu>
	<CAAWBYDDBSZZngGA9V5Kz9TT+Gh=Hy5+D5TY+Lsecq22BueZTvA@mail.gmail.com>
Message-ID: <50AA5CB7.4030000@mit.edu>

On 11/19/12 11:20 AM, Tab Atkins Jr. wrote:
> To a first approximation, they shouldn't be.  ES6 classes desugar into
> functions and prototypes.

Hmm.  They didn't completely at some point, but maybe something got 
changed since I last looked.

"first approximation" is not great if we actually expect people to 
implement stuff interoperably, not just interoperably to a first 
approximation.  ;)

-Boris

From jackalmage at gmail.com  Mon Nov 19 09:07:06 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 19 Nov 2012 09:07:06 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50AA5CB7.4030000@mit.edu>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
	<CAAWBYDDszLNjqprz6qMxOoMFbpv7cQLVvQ26bV=X9rBDiMCtXQ@mail.gmail.com>
	<50AA5C05.9080607@mit.edu>
	<CAAWBYDDBSZZngGA9V5Kz9TT+Gh=Hy5+D5TY+Lsecq22BueZTvA@mail.gmail.com>
	<50AA5CB7.4030000@mit.edu>
Message-ID: <CAAWBYDB7+KpPaBan+utUd0x+hjqS4mQp6TWcPtokCABqArPCaA@mail.gmail.com>

On Mon, Nov 19, 2012 at 8:22 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 11/19/12 11:20 AM, Tab Atkins Jr. wrote:
>> To a first approximation, they shouldn't be.  ES6 classes desugar into
>> functions and prototypes.
>
> Hmm.  They didn't completely at some point, but maybe something got changed
> since I last looked.
>
> "first approximation" is not great if we actually expect people to implement
> stuff interoperably, not just interoperably to a first approximation.  ;)

I think it's valid to say in general, I'm just not 100% sure.  I only
follow es-discuss, I'm not part of tc39 and don't actually track
things too closely.

Even if it doesn't, the part of "subclassing" that you need to make
"URLQuery as subclass of Map" work is doable with existing ES5.

~TJ

From chaals at yandex-team.ru  Mon Nov 19 09:42:42 2012
From: chaals at yandex-team.ru (Charles McCathie Nevile)
Date: Mon, 19 Nov 2012 18:42:42 +0100
Subject: [whatwg] Use of article to identify the main content of a web
 page (was Re: A plea to Hixie to adopt <main>)
In-Reply-To: <CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>
References: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>
	<CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>
Message-ID: <op.wn07hgzzy3oazb@v3-151-181.yandex.net>

On Mon, 19 Nov 2012 15:38:26 +0100, Ian Yang <ian at invigoreight.com> wrote:

> On Mon, Nov 19, 2012 at 8:40 PM, Steve Faulkner  
> <faulkner.steve at gmail.com>wrote:
>
>> Hi Ian,
>>
>> hixies suggestion to use article to act as a main content identifier  
>> [3] is
>> incorrect, as per the HTML spec [1]
>>
>> The article element represents a self-contained composition in a  
>> document,
>> > page, application, or site and that is, in principle, independently
>> > distributable or reusable, e.g. in syndication. This could be a forum
>> post,
>> > a magazine or newspaper article, a blog entry, a user-submitted  
>> comment,
>> an
>> > interactive widget or gadget, or any other independent item of  
>> content.
>> >
>>
>> The main element as per the main  element spec [2]:
>>
>> The main element represents the main content section of the body of a
>> > document or application. The main content section consists of content
>> that
>> > is directly related to or expands upon the central topic of a  
>> document or
>> > central functionality of an application.
>> >
>>
>> The article and main roles as defined in ARIA  have distinct
>> characteristics and those distinctions are also expressed via  how they
>> (and the article element) are exposed via accessibility APIs in  
>> browsers.
>>
>> [1]
>> http://dev.w3.org/html5/spec/the-article-element.html#the-article-element
>> [2]
>> https://dvcs.w3.org/hg/html-extensions/raw-file/tip/maincontent/index.html
>> [3]
>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0221.html
>>
>
>
> Thanks Steve for explanation. Could you please suggest an appropriate
> element for the wrapper of the content of a blog post?

I'm not Steve. But I've been looking at the proposal. So IMHO...

If it is a single post on a page, you could wrap it in article or in main.
If it is a forum, where multiple threads are displayed, you would wrap
each in article. Main would cover the collection of threads on the page
(but not the navigation etc.)

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals at yandex-team.ru         Find more at http://yandex.com

From ian at hixie.ch  Mon Nov 19 10:04:27 2012
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 19 Nov 2012 18:04:27 +0000 (UTC)
Subject: [whatwg] Canvas in Workers
In-Reply-To: <CAKZ+BNoFMP8PqnfBnfK9PEPALip4mxc9GcRzcE_AO=Sd0z5cfw@mail.gmail.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
	<CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>
	<Pine.LNX.4.64.1211162147040.16964@ps20323.dreamhostps.com>
	<CAHfnhfq0cgZSVgc5e+DuU0QGQ2+HykTiNN0yiLgKfydjjuK-4A@mail.gmail.com>
	<CAKZ+BNoFMP8PqnfBnfK9PEPALip4mxc9GcRzcE_AO=Sd0z5cfw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211191754320.16964@ps20323.dreamhostps.com>

On Mon, 19 Nov 2012, Gregg Tavares (????~T?) wrote:
>
> Sorry if this is clear in the specs but can you explain how sizing the 
> canvas works?

There's two sizes involved in a canvas: the size of the bitmap, and the 
size of the rendering. Both default to 300x150 in the absence of explicit 
sizing.

The size of the bitmap, for getContext()-based canvases, is given by the 
<canvas> element's width and height attributes. For rendering contexts 
created by their constructor, it's initially set by the arguments to the 
constructor. It can be changed using the width and height attributes on 
the rendering context. When a context is bound to a canvas, it takes on 
the dimensions of the canvas bitmap. To change the canvas bitmap 
dimensions before calling setContext() or transferControlToProxy(), you 
use the width and height attributes as before. Once you've called 
setContext() or transferControlToProxy(), though, to avoid race conditions 
with workers, only the width and height attributes on the rendering 
context affect the canvas, so you have to first bind the rendering context 
and then set the size if you need the size changed.

The size of the rendering is set by CSS, and defaults to whatever the 
width and height attributes of the canvas element are. Note that if you 
are drawing to the canvas from a worker and you have changed the 
dimensions of the bitmap after you called setContext() or 
transferControlToProxy(), you will have to explicitly set the dimensions 
of the canvas using the element's attributes or CSS, otherwise the canvas 
bitmap will be resized for rendering.

>    // main.html
>    <canvas></canvas>

Here the bitmap and rendering are 300x150.

>    <script>
>     var canvas = document.getElementsByTagName('canvas')[0];
>     var worker = new Worker('clock.js');
>     var proxy = canvas.transferControlToProxy());

At this point, canvas.width/.height no longer affect the bitmap size.

>     worker.postMessage(proxy, [proxy]);
> 
>     setTimeout(function() {
>         canvas.width = 200;   // does this work? What happens?

This just changes the rendered width.

>     }, 4000);
>    </script>
> 
>    // clock.js worker
>    onmessage = function (event) {
>      var context = new CanvasRenderingContext2d();

The constructor could be called with arguments, as in new 
   CanvasRenderingContext2d(200, 150);

That size will have no effect though, since the context is immediately 
bound to a canvas bitmap and takes the bitmap's size:

>      event.data.setContext(context);
>      setInterval(function () {
>        context.width = 400;  // Can I do this? What happens when I do?

This changes the canvas bitmap's dimensions (and resets all state of the 
rendering context). It doesn't change the canvas element's rendered 
dimensions, however (we could push the state out like the bitmap itself, I 
guess, but that would make the DOM change out of the blue which is weird).

>        context.clearRect(0, 0, context.width, context.height);
>        context.fillText(0, 100, new Date());
>        context.commit();
>      }, 1000);
>    };

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

From ian at hixie.ch  Mon Nov 19 10:08:05 2012
From: ian at hixie.ch (Ian Hickson)
Date: Mon, 19 Nov 2012 18:08:05 +0000 (UTC)
Subject: [whatwg] Use of article to identify the main content of a web
 page
In-Reply-To: <op.wn07hgzzy3oazb@v3-151-181.yandex.net>
References: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>
	<CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>
	<op.wn07hgzzy3oazb@v3-151-181.yandex.net>
Message-ID: <Pine.LNX.4.64.1211191805470.26354@ps20323.dreamhostps.com>

On Mon, 19 Nov 2012, Ian Yang wrote:
> On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 15 Nov 2012, Ian Yang wrote:
> > >
> > > That's a good idea. We really need an element to wrap all the <p>s, 
> > > <ul>s, <ol>s, <figure>s, <table>s ... etc of a blog post.
> >
> > That's called <article>.
> 
> Thanks Hickson. Actually I had turned down my own opinion ( 
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0182.html 
> ).
> 
> And isn't <article> used to wrap an entire blog post? Like this:
> 
> <article>
>     <header />
>     <div />
>     <footer />
> </article>

Right. It wraps all the elements of a blog post. All the <p>s, <ul>s, 
<ol>s, <figure>s, <table>s, <h1>s, <footer>s, etc.

If you just want to wrap a subpart of that for rendering purposes, <div> 
is the element you want. Basically <div> is always the answer if the 
question is "how do I provide myself a hook for CSS styling".

From allen at wirfs-brock.com  Mon Nov 19 10:15:08 2012
From: allen at wirfs-brock.com (Allen Wirfs-Brock)
Date: Mon, 19 Nov 2012 10:15:08 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50AA578A.5040702@gmail.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
	<50AA578A.5040702@gmail.com>
Message-ID: <4C42AD8B-D7D5-48C6-B401-EF274BC5E67F@wirfs-brock.com>

On Nov 19, 2012, at 8:00 AM, David Bruant wrote:

> Le 19/11/2012 14:38, Boris Zbarsky a ?crit :
>> On 11/19/12 2:36 AM, David Bruant wrote:
>>> ...
> 
>>>> I suppose the same goes for ES6 Map.
>>> As Tab suggested, a Map subclass could certainly work
>> 
>> How close are "subclasses" to not being vaporware (both in spec and implementation terms)?
> I don't understand what you mean by vaporware. ES6 Maps are a reality in Firefox and Chrome (behind a flag for the latter). Subclassing of ES6 maps will be possible as soon as ES6 classes do (which I admit are still unimplemented)... well... it's actually possible today with __proto__ I guess.

In the ES6 draft, the Map built-in constructor is explicitly defined to be "subclassable". This is done in a manner that does not require the use of ES6 class declarations.  It simply means that if an arbitrary object is initialized by calling the Map constructor (as a function) on the object then the object will have the necessary internal state to act as a map object and the built-int Map.prototype methods that depend upon such state will work with the object.

Practically it means things like this:

class SpecialMap extends Map {
   constructor(...args) {super(...args)};
   set(key,value) {
        super.set(key,value);
        DoSomethingSpecialWhenSettingAMapElement(this,key,value);
    }
}

or without class declarations

SpecialMap.prototype = Object.create(Map.prototype); 
SpecialMap.prototype.constructor = SpecialMap;
function SpecialMap() {
      Map.call(this);      // initialize new object with internal state needed to operate as a map
}
SpecialMap.prototype.set = function(key,value) {
   Map.prototype.set.call(this,key,value);
   DoSomethingSpecialWhenSettingAMapElement(this,key,value);
}

The necessary mechanisms to make this work are specified but as far as I know have not yet been implemented.  I'm hopeful that they will soon be incorporated into one or more of the experimental Map implementations.

Allen

From julian.reschke at gmx.de  Mon Nov 19 10:17:41 2012
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 19 Nov 2012 19:17:41 +0100
Subject: [whatwg] [mimesniff] The X-Content-Type-Options header
In-Reply-To: <CAJE5ia_mBQNmBRweuZT01S6=FfLy38hb7JD+5Tq2GvNw7LYRuA@mail.gmail.com>
References: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>
	<CADnb78hebV_4R7pCSxviMgzsLg0b0_RAgXai7zb68wtsyCA2fg@mail.gmail.com>
	<CAH4e3M7hjUe8hg5iK6uGD4onK=q+iej5oXkoODc5MEgkAD7Rug@mail.gmail.com>
	<CAJE5ia_mBQNmBRweuZT01S6=FfLy38hb7JD+5Tq2GvNw7LYRuA@mail.gmail.com>
Message-ID: <50AA77C5.4020408@gmx.de>

On 2012-11-17 19:17, Adam Barth wrote:
> ...
> I would prefer if the spec described what implementations actually do
> rather than your opinion about what they should do.  To answer your
> specific questions:
> ...

That works well if something is widely supported already. It works less 
well if you have one initial and one incomplete implementation only.

> 1) Don't bother dropping the "X-".  Everyone who implements this
> feature uses the X- and dropping it is just going to cause unnecessary
> interoperability problems.

There's no *need* to drop it, but if research on this topic leads to the 
conclusion that the functionality is needed, but the current X- 
prototype isn't sufficient anyway it might be worth considering.

> ...

Best regards, Julian

From allen at wirfs-brock.com  Mon Nov 19 10:26:01 2012
From: allen at wirfs-brock.com (Allen Wirfs-Brock)
Date: Mon, 19 Nov 2012 10:26:01 -0800
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <50AA5CB7.4030000@mit.edu>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
	<CAAWBYDDszLNjqprz6qMxOoMFbpv7cQLVvQ26bV=X9rBDiMCtXQ@mail.gmail.com>
	<50AA5C05.9080607@mit.edu>
	<CAAWBYDDBSZZngGA9V5Kz9TT+Gh=Hy5+D5TY+Lsecq22BueZTvA@mail.gmail.com>
	<50AA5CB7.4030000@mit.edu>
Message-ID: <E7D6F289-286C-455B-8E3E-C075432C5BAD@wirfs-brock.com>

On Nov 19, 2012, at 8:22 AM, Boris Zbarsky wrote:

> On 11/19/12 11:20 AM, Tab Atkins Jr. wrote:
>> To a first approximation, they shouldn't be.  ES6 classes desugar into
>> functions and prototypes.
> 
> Hmm.  They didn't completely at some point, but maybe something got changed since I last looked.

They do now, see https://people.mozilla.com/~jorendorff/es6-draft.html#sec-13.5

> 
> "first approximation" is not great if we actually expect people to implement stuff interoperably, not just interoperably to a first approximation.  ;)

Classes and everything else in ES6 will be precisely specified within interoperability being a paramount goal

Allen

From w3c at adambarth.com  Mon Nov 19 10:27:45 2012
From: w3c at adambarth.com (Adam Barth)
Date: Mon, 19 Nov 2012 10:27:45 -0800
Subject: [whatwg] [mimesniff] The X-Content-Type-Options header
In-Reply-To: <50AA77C5.4020408@gmx.de>
References: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>
	<CADnb78hebV_4R7pCSxviMgzsLg0b0_RAgXai7zb68wtsyCA2fg@mail.gmail.com>
	<CAH4e3M7hjUe8hg5iK6uGD4onK=q+iej5oXkoODc5MEgkAD7Rug@mail.gmail.com>
	<CAJE5ia_mBQNmBRweuZT01S6=FfLy38hb7JD+5Tq2GvNw7LYRuA@mail.gmail.com>
	<50AA77C5.4020408@gmx.de>
Message-ID: <CAJE5ia8mAzj6uiLHekua6meBPPHdJ9813M+kxKtPsCPY92H4mQ@mail.gmail.com>

On Mon, Nov 19, 2012 at 10:17 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2012-11-17 19:17, Adam Barth wrote:
>> ...
>>
>> I would prefer if the spec described what implementations actually do
>> rather than your opinion about what they should do.  To answer your
>> specific questions:
>> ...
>
> That works well if something is widely supported already. It works less well
> if you have one initial and one incomplete implementation only.

Which implementation is initial and which is incomplete?  AFAIK, both
IE and Chromium consider their implementation of this feature done.

>> 1) Don't bother dropping the "X-".  Everyone who implements this
>> feature uses the X- and dropping it is just going to cause unnecessary
>> interoperability problems.
>
> There's no *need* to drop it, but if research on this topic leads to the
> conclusion that the functionality is needed, but the current X- prototype
> isn't sufficient anyway it might be worth considering.

Currently, I don't see a use case for dropping the X- prefix.  Perhaps
there's one I don't understand?

Adam

From esprehn at chromium.org  Mon Nov 19 10:33:40 2012
From: esprehn at chromium.org (Elliott Sprehn)
Date: Mon, 19 Nov 2012 13:33:40 -0500
Subject: [whatwg] Canvas in Workers
In-Reply-To: <CAKZ+BNoFMP8PqnfBnfK9PEPALip4mxc9GcRzcE_AO=Sd0z5cfw@mail.gmail.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
	<CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>
	<Pine.LNX.4.64.1211162147040.16964@ps20323.dreamhostps.com>
	<CAHfnhfq0cgZSVgc5e+DuU0QGQ2+HykTiNN0yiLgKfydjjuK-4A@mail.gmail.com>
	<CAKZ+BNoFMP8PqnfBnfK9PEPALip4mxc9GcRzcE_AO=Sd0z5cfw@mail.gmail.com>
Message-ID: <CAO9Q3iLfrHp8mS7Bg9aLzwT81f87NLad5Z=W5JE5FWs4cEbqjQ@mail.gmail.com>

On Mon, Nov 19, 2012 at 12:26 AM, Gregg Tavares (??) <gman at google.com>wrote:

> Sorry if this is clear in the specs but can you explain how sizing the
> canvas works?
>
>
>    // main.html
>    <canvas></canvas>
>    <script>
>     var canvas = document.getElementsByTagName('canvas')[0];
>     var worker = new Worker('clock.js');
>     var proxy = canvas.transferControlToProxy());
>     worker.postMessage(proxy, [proxy]);
>
>     setTimeout(function() {
>         canvas.width = 200;   // does this work? What happens?
>

You resize the output surface that the image coming from the worker will be
drawn into. This is different than changing the buffer used for drawing.

}, 4000);
>    </script>
>
>    // clock.js worker
>    onmessage = function (event) {
>      var context = new CanvasRenderingContext2d();
>      event.data.setContext(context);
>      setInterval(function () {
>        context.width = 400;  // Can I do this? What happens when I do?
>

You resize the buffer that's inside of the worker.

- E

From julian.reschke at gmx.de  Mon Nov 19 10:41:21 2012
From: julian.reschke at gmx.de (Julian Reschke)
Date: Mon, 19 Nov 2012 19:41:21 +0100
Subject: [whatwg] [mimesniff] The X-Content-Type-Options header
In-Reply-To: <CAJE5ia8mAzj6uiLHekua6meBPPHdJ9813M+kxKtPsCPY92H4mQ@mail.gmail.com>
References: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>
	<CADnb78hebV_4R7pCSxviMgzsLg0b0_RAgXai7zb68wtsyCA2fg@mail.gmail.com>
	<CAH4e3M7hjUe8hg5iK6uGD4onK=q+iej5oXkoODc5MEgkAD7Rug@mail.gmail.com>
	<CAJE5ia_mBQNmBRweuZT01S6=FfLy38hb7JD+5Tq2GvNw7LYRuA@mail.gmail.com>
	<50AA77C5.4020408@gmx.de>
	<CAJE5ia8mAzj6uiLHekua6meBPPHdJ9813M+kxKtPsCPY92H4mQ@mail.gmail.com>
Message-ID: <50AA7D51.8030002@gmx.de>

On 2012-11-19 19:27, Adam Barth wrote:
> On Mon, Nov 19, 2012 at 10:17 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
>> On 2012-11-17 19:17, Adam Barth wrote:
>>> ...
>>>
>>> I would prefer if the spec described what implementations actually do
>>> rather than your opinion about what they should do.  To answer your
>>> specific questions:
>>> ...
>>
>> That works well if something is widely supported already. It works less well
>> if you have one initial and one incomplete implementation only.
>
> Which implementation is initial and which is incomplete?  AFAIK, both
> IE and Chromium consider their implementation of this feature done.

"initial" -> the one done first, and by the vendor that invented the 
functionality

"incomplete" -> the one that copies one part and not the other part of 
he behavior of the initial implementation

> ...

>> 1) Don't bother dropping the "X-".  Everyone who implements this
>>> feature uses the X- and dropping it is just going to cause unnecessary
>>> interoperability problems.
>>
>> There's no *need* to drop it, but if research on this topic leads to the
>> conclusion that the functionality is needed, but the current X- prototype
>> isn't sufficient anyway it might be worth considering.
>
> Currently, I don't see a use case for dropping the X- prefix.  Perhaps
> there's one I don't understand?

A use case for *renaming* (which might be more than dropping the prefix) 
actually would be saving bytes on the wire. Another one would be to make 
it possible to make incompatible changes to the field value syntax, when 
needed.

Best regards, Julian

From chaals at yandex-team.ru  Mon Nov 19 10:54:45 2012
From: chaals at yandex-team.ru (Charles McCathie Nevile)
Date: Mon, 19 Nov 2012 19:54:45 +0100
Subject: [whatwg] Use of article to identify the main content of a web
 page (was Re: A plea to Hixie to adopt <main>)
In-Reply-To: <CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>
References: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>
	<CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>
Message-ID: <op.wn1atjtgy3oazb@v3-151-181.yandex.net>

On Mon, 19 Nov 2012 15:38:26 +0100, Ian Yang <ian at invigoreight.com> wrote:

I'm not Steve. But I've been looking at the proposal. So IMHO...

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
         chaals at yandex-team.ru         Find more at http://yandex.com

From bzbarsky at MIT.EDU  Mon Nov 19 11:00:43 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 19 Nov 2012 14:00:43 -0500
Subject: [whatwg] [URL] DOM API Feedback
In-Reply-To: <E7D6F289-286C-455B-8E3E-C075432C5BAD@wirfs-brock.com>
References: <CANr5HFVQ0e_svEE8JUqG1zNoB+ODfyN20_83qKzk3fXNi3g2jw@mail.gmail.com>
	<50A96292.7080201@gmail.com>
	<CADnb78hwCfJt_V9kO-b14hk3Q9i3i8zX4faD3bBwe517Eu=Gsw@mail.gmail.com>
	<50A9E176.2010906@gmail.com> <50AA3669.3040607@mit.edu>
	<CAAWBYDDszLNjqprz6qMxOoMFbpv7cQLVvQ26bV=X9rBDiMCtXQ@mail.gmail.com>
	<50AA5C05.9080607@mit.edu>
	<CAAWBYDDBSZZngGA9V5Kz9TT+Gh=Hy5+D5TY+Lsecq22BueZTvA@mail.gmail.com>
	<50AA5CB7.4030000@mit.edu>
	<E7D6F289-286C-455B-8E3E-C075432C5BAD@wirfs-brock.com>
Message-ID: <50AA81DB.40307@mit.edu>

On 11/19/12 1:26 PM, Allen Wirfs-Brock wrote:
> Classes and everything else in ES6 will be precisely specified within
> interoperability being a paramount goal

Of course.  My concern is with web specs handwavily specifying things 
without defining them (which they have a regrettable tendency to do), 
not with ES doing that (because historically, it does not have such a 
tendency).

-Boris

From w3c at adambarth.com  Mon Nov 19 11:19:22 2012
From: w3c at adambarth.com (Adam Barth)
Date: Mon, 19 Nov 2012 11:19:22 -0800
Subject: [whatwg] [mimesniff] The X-Content-Type-Options header
In-Reply-To: <50AA7D51.8030002@gmx.de>
References: <CAH4e3M61gS3ENDfgYRaQc-HdGinY18hV80DHW35-NWnahtzFeA@mail.gmail.com>
	<CADnb78hebV_4R7pCSxviMgzsLg0b0_RAgXai7zb68wtsyCA2fg@mail.gmail.com>
	<CAH4e3M7hjUe8hg5iK6uGD4onK=q+iej5oXkoODc5MEgkAD7Rug@mail.gmail.com>
	<CAJE5ia_mBQNmBRweuZT01S6=FfLy38hb7JD+5Tq2GvNw7LYRuA@mail.gmail.com>
	<50AA77C5.4020408@gmx.de>
	<CAJE5ia8mAzj6uiLHekua6meBPPHdJ9813M+kxKtPsCPY92H4mQ@mail.gmail.com>
	<50AA7D51.8030002@gmx.de>
Message-ID: <CAJE5ia-x4daVimkKqQoCj7d7k=wYUdF2r2R5P6MXLw=CU4PqDA@mail.gmail.com>

On Mon, Nov 19, 2012 at 10:41 AM, Julian Reschke <julian.reschke at gmx.de> wrote:
> On 2012-11-19 19:27, Adam Barth wrote:
>> On Mon, Nov 19, 2012 at 10:17 AM, Julian Reschke <julian.reschke at gmx.de>
>> wrote:
>>>
>>> On 2012-11-17 19:17, Adam Barth wrote:
>>>>
>>>> ...
>>>>
>>>> I would prefer if the spec described what implementations actually do
>>>> rather than your opinion about what they should do.  To answer your
>>>> specific questions:
>>>> ...
>>>
>>>
>>> That works well if something is widely supported already. It works less
>>> well
>>> if you have one initial and one incomplete implementation only.
>>
>>
>> Which implementation is initial and which is incomplete?  AFAIK, both
>> IE and Chromium consider their implementation of this feature done.
>
> "initial" -> the one done first, and by the vendor that invented the
> functionality
>
> "incomplete" -> the one that copies one part and not the other part of he
> behavior of the initial implementation

I can't speak for the IE team, but I can tell you that I don't view
the Chromium implementation as either initial or incomplete.

>>> 1) Don't bother dropping the "X-".  Everyone who implements this
>>>>
>>>> feature uses the X- and dropping it is just going to cause unnecessary
>>>> interoperability problems.
>>>
>>> There's no *need* to drop it, but if research on this topic leads to the
>>> conclusion that the functionality is needed, but the current X- prototype
>>> isn't sufficient anyway it might be worth considering.
>>
>> Currently, I don't see a use case for dropping the X- prefix.  Perhaps
>> there's one I don't understand?
>
> A use case for *renaming* (which might be more than dropping the prefix)
> actually would be saving bytes on the wire. Another one would be to make it
> possible to make incompatible changes to the field value syntax, when
> needed.

I don't have any interest in making any incompatible changes to this
feature in Chromium at this time.

Adam

From annevk at annevk.nl  Mon Nov 19 13:12:48 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 19 Nov 2012 22:12:48 +0100
Subject: [whatwg] URL: percent-encoded host
Message-ID: <CADnb78g54Zryb9WYa=Kqrw1PgcVjM2mLQ9e3uS7_h6Y-D4MMwQ@mail.gmail.com>

What to do with percent-encoded bytes in the host? Examples (prepend
http:// for a full URL):

1. x%2ex
2. %80
3. %41
4. %C3%A9

(Append % to each of them for confusing results, e.g. Opera handles
%41% and %C3%A9% differently.
http://dump.testsuite.org/url/inspect.html can be used for testing.)

There's a bunch of different approaches we could take (and most of
these seem to be done in one way or another):

1. Convert percent-encoded bytes to bytes, decode as utf-8.
2. Convert percent-encoded bytes to bytes, only decode those as utf-8
that represent a valid sequence.
3. Ignore percent-encoded bytes.

Chrome seems to do 1 (although with weird results when you hit a decoder error).
Opera and Safari seem to do 2.
Firefox seems to do 3.

Personally I'm leaning towards either 1 (without the weirdness) or 3.
The potential downside may be that with either of those you can no
longer transmit bytes higher than 0x7F over DNS or equivalent system.
Not sure if that's a problem in practice as user agents seem to mostly
fail already...

-- 
http://annevankesteren.nl/

From chaals at yandex-team.ru  Mon Nov 19 14:36:05 2012
From: chaals at yandex-team.ru (Charles McCathie Nevile)
Date: Mon, 19 Nov 2012 23:36:05 +0100
Subject: [whatwg] Use of article to identify the main content of a web
 page
In-Reply-To: <Pine.LNX.4.64.1211191805470.26354@ps20323.dreamhostps.com>
References: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>
	<CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>
	<op.wn07hgzzy3oazb@v3-151-181.yandex.net>
	<Pine.LNX.4.64.1211191805470.26354@ps20323.dreamhostps.com>
Message-ID: <op.wn1k2fm8y3oazb@v3-151-181.yandex.net>

On Mon, 19 Nov 2012 19:08:05 +0100, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 19 Nov 2012, Ian Yang wrote:
>> On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Thu, 15 Nov 2012, Ian Yang wrote:
>> > >
>> > > That's a good idea. We really need an element to wrap all the <p>s,
>> > > <ul>s, <ol>s, <figure>s, <table>s ... etc of a blog post.
>> >
>> > That's called <article>.
>>
>> Thanks Hickson. Actually I had turned down my own opinion (
>> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0182.html
>> ).
>>
>> And isn't <article> used to wrap an entire blog post? Like this:
>>
>> <article>
>>     <header />
>>     <div />
>>     <footer />
>> </article>
>
> Right. It wraps all the elements of a blog post. All the <p>s, <ul>s,
> <ol>s, <figure>s, <table>s, <h1>s, <footer>s, etc.

Sure, but what about multiple articles, in a page like the front of a US  
newspaper or a forum page with multiple threads, or the front page of my  
blog (which offers the last n articles on the same page)?

> If you just want to wrap a subpart of that for rendering purposes, <div>
> is the element you want. Basically <div> is always the answer if the
> question is "how do I provide myself a hook for CSS styling".

Sure, but that isn't the question I have. I'd like to know "what is the  
main content of the page"?

There are a set of use cases that have some overlap (but not a whole lot),  
where I'd like to seperate out "articles" in the sense of "things" - like  
"things in a newsletter" or "things that people are talking about".

cheers

Chaals

-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals at yandex-team.ru         Find more at http://yandex.com

From ian at hixie.ch  Mon Nov 19 17:38:02 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 01:38:02 +0000 (UTC)
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>

On Thu, 8 Nov 2012, Bobby Holley wrote:
>
> The current spec for the Location object doesn't match reality. At the 
> moment, the spec says that Location is a per-Window object that 
> describes the associated Document. However, in our testing, it appears 
> that none of the user-agents (Gecko, WebKit, Trident, Presto) do this 
> [1]. Instead, all implementations of Location describe the active 
> document in the browsing context (that is to say, the referent of the 
> WindowProxy). This suggests that the spec's current language is likely 
> not web-compatible.

Fixed.

> If the Location object describes the browsing context, we're left to 
> consider whether there should be one Location object per Window or one 
> Location object per browsing context. Gecko and Webkit currently do the 
> former, and Trident and Presto do the latter (see again [1]).

It seems IE changed in IE10 and now acts like WebKit.

Arguments for the one-LocationProxy-per-WindowProxy behaviour:

- it would likely improve Gecko's security story since it would simplify 
   Gecko's security invariants.

- it's what Opera and old IEs implement (I think?).

Arguments for the one-Location-per-Window behaviour:

- it would likely improve WebKit's security story since it would simplify
   Webkit's security checks (relative to the other option).

- it's what WebKit and new IEs implement (I think?).

- it has the clearer story for authors. Objects that change identity, or 
   that gain or lose properties when a page navigates, are unintuitive.

On Thu, 8 Nov 2012, Boris Zbarsky wrote:
> On 11/8/12 6:09 PM, Adam Barth wrote:
> > 
> > In WebKit at least, it would be a security vulnerability to expose 
> > JavaScript objects that belong to Document B to Document A because 
> > that would give Document A access to the prototype objects for 
> > Document B.
> 
> You presumably have a solution for this situation for the WindowProxy 
> case, right?  Certainly Gecko does, and we would be using the same 
> solution for Location if we tie the lifetime of a Location to the 
> lifetime of a WindowProxy.

This problem exists regardless of whether we have proxies, since the 
Location object is visible cross-origin. Whether we proxy or not is 
orthogonal. The question is just how we should protect the object.

On Fri, 9 Nov 2012, Adam Barth wrote:
> 
> The WindowProxy is a special, magical object because references to it 
> magically change which JavaScript object they refer to over time.  If 
> possible, I would like to avoid infecting other objects with its magic.

I do agree with this. I don't see why we would ever introduce an object 
like this if we can help it.

On Fri, 9 Nov 2012, Bobby Holley wrote:
> 
> Right now, the Location object is the only object whose security 
> characteristics are not guaranteed to match its global, which is a major 
> pain point for us.

The Window object, the Document object, and the Location object, per spec, 
all have exactly the same security characteristics, except that Window and 
Location have certain properties that can be accessed. (This is also quite 
similar to the Storage model, except Storage uses the actual origin, not 
the effective script origin.)

On Fri, 9 Nov 2012, Bobby Holley wrote:
> 
> As noted, the Location object is the only object whose security 
> characteristics don't match its scope. This requires a lot of extra goop 
> in our compartment-based security model, and the goop is brittle 
> (recently forcing us to release two out-of-band updates, 16.0.1 and 
> 16.0.2). We've got enough belt-and-suspenders code now that I'm not 
> particularly worried, but I still want to make Location just like any 
> other object from a security perspective.

I don't think making it one of those proxy objects, of which there's only 
one so far and it's very complicated, is making it "just like any other 
object", but I understand that the Gecko security model does make this 
different than it first appears.

> Also, FWIW, from the perspective of an average web-developer, IMO it 
> makes much more semantic sense to have one Location per WindowProxy if 
> the Location object describes the WindowProxy.

It has some pretty serious implications. It means if you have the object 
in an iframe and install a shim to implement some of Anne's new features, 
your shim will break as soon as you navigate the iframe. That's very odd. 
It also means that the object's "instanceof" characteristic will keep 
changing. Again, very unusual and not something authors normally see.

On Fri, 9 Nov 2012, Boris Zbarsky wrote:
> 
> One thing I'd like is some comment from Opera and Microsoft about what 
> their situation is, since implementing what WebKit does would mean both 
> of those changing.  This is probably the wrong venue to get hold of 
> Microsoft for an official statement, sadly.  :(

Microsoft seems to have already changed, from what I hear of IE10 (I 
unfortunately don't have access to an instance to test for myself).

Input from Opera people would indeed be welcome.

On Fri, 9 Nov 2012, Bobby Holley wrote:
> On Thu, Nov 8, 2012 at 6:09 PM, Adam Barth <w3c at adambarth.com> wrote:
> >
> > == Document A ==
> > <script>
> > Object.prototype.foo = "A1";
> > window.location.bar = "A2";
> >
> > function f() {
> >   var loc = window.location;
> >   print(loc.foo); // print is a magic function that lets me see this value
> >   print(loc.bar);
> > }
> > </script>
> >
> > == Document B ==
> > <script>
> > Object.prototype.foo = "B1";
> > window.location.bar = "B2";
> > </script>
> >
> > 1) Document A is displayed in browsing context X.
> > 2) Browsing context X is navigated and now displays document B.
> > 3) Function f is called.
> >
> > What values are printed?
> 
> Under the proposed behavior, both documents share the same Location 
> object.

Well, the proposal is that there's two Location objects, but 
window.location always returns an object that refers to the active 
document's one, right? Or is the proposal that there really only be one 
instance? If the latter, whose prototype does it have? I don't see how we 
could do the latter really.

> As for loc.foo, our new implementation would give "B1", because the 
> Location object has entirely transplanted into the new Document's scope. 
> This seems sane to me, but it's certainly up for discussion.

I don't think it seems sane from the author's perspective.

For now I've tightened up the spec so it should be implementable, secure, 
and Web-compatible, but it still has a unique instance per Document, not 
the one-object-whose-prototype-keeps-changing model, nor the proxy model 
(it's not entirely clear to me which is being proposed for Gecko).

But more input on this is definitely welcome. I'm in particular curious 
about what authors would find most intuitive, about what Gecko's plans are 
regarding which Location interface object to use for the prototype of the 
Location object instance(s), whether the proposal would enable 
cross-origin shims (or indeed same-origin shims) on Location instances, 
etc. I'm also curious as to why figuring out the "entry script"'s 
characteristics needs to use the stack introspection rather than just 
having an event-loop global "first script" variable, much as the spec 
describes it -- the latter seems safer and more efficient to me. If the 
spec's description can't be implemented, then it's something that should 
be fixed.

From ian at hixie.ch  Mon Nov 19 17:40:58 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 01:40:58 +0000 (UTC)
Subject: [whatwg] Spec for location object needs to make some properties
 unforgeable; need supporting WebIDL changes
In-Reply-To: <50613CB3.5030302@mit.edu>
References: <50613CB3.5030302@mit.edu>
Message-ID: <Pine.LNX.4.64.1211200138210.26354@ps20323.dreamhostps.com>

On Tue, 25 Sep 2012, Boris Zbarsky wrote:
>
> Turns out, some things care about at least the .href and .toString of 
> Location objects for security-check purposes.  So they need to be 
> unforgeable.  But of course WebIDL doesn't provide a way to make 
> anything other than readonly attributes unforgeable.  It seems like it 
> needs to.

I'm going to assume heycam is going to add an interface-level 
[Unforgeable] annotation that does this.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20008

I've updated HTML accordingly.

From bzbarsky at MIT.EDU  Mon Nov 19 18:38:02 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 19 Nov 2012 21:38:02 -0500
Subject: [whatwg] URL: percent-encoded host
In-Reply-To: <CADnb78g54Zryb9WYa=Kqrw1PgcVjM2mLQ9e3uS7_h6Y-D4MMwQ@mail.gmail.com>
References: <CADnb78g54Zryb9WYa=Kqrw1PgcVjM2mLQ9e3uS7_h6Y-D4MMwQ@mail.gmail.com>
Message-ID: <50AAED0A.80808@mit.edu>

On 11/19/12 4:12 PM, Anne van Kesteren wrote:
> 3. Ignore percent-encoded bytes.
...
> Firefox seems to do 3.

This actually causes problems; see 
https://bugzilla.mozilla.org/show_bug.cgi?id=309671

So I don't think we should require this behavior.

-Boris

From bzbarsky at MIT.EDU  Mon Nov 19 18:46:25 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Mon, 19 Nov 2012 21:46:25 -0500
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
	<Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
Message-ID: <50AAEF01.4000004@mit.edu>

On 11/19/12 8:38 PM, Ian Hickson wrote:
> For now I've tightened up the spec so it should be implementable, secure,
> and Web-compatible

I don't believe it's secure as currently written, actually.  Filed 
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20012

> I'm also curious as to why figuring out the "entry script"'s
> characteristics needs to use the stack introspection rather than just
> having an event-loop global "first script" variable

You can maintain a stack of entry scripts.  You can't use a global, 
because you need to push and pop entry scripts as various things happen 
(e.g. invoking event listeners sets the entry script to the event 
listener function's script for the duration of the event listener 
invocation).

There is no such stack of entry scripts in Gecko yet, but we're working 
on changing that.

The thing that _really_ requires stack introspection is when you need to 
look at the caller script instead of the entry script.  Which is what 
you need to do when performing Location security checks (or indeed, any 
security checks).

-Boris

From ian at invigoreight.com  Mon Nov 19 21:02:45 2012
From: ian at invigoreight.com (Ian Yang)
Date: Tue, 20 Nov 2012 13:02:45 +0800
Subject: [whatwg] Use of article to identify the main content of a web
	page
In-Reply-To: <Pine.LNX.4.64.1211191805470.26354@ps20323.dreamhostps.com>
References: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>
	<CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>
	<op.wn07hgzzy3oazb@v3-151-181.yandex.net>
	<Pine.LNX.4.64.1211191805470.26354@ps20323.dreamhostps.com>
Message-ID: <CABr1FseMsb2xjMTVCO4pCFe74A1eqyxJyzFi0wA6req37=UaRQ@mail.gmail.com>

On Tue, Nov 20, 2012 at 2:08 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Mon, 19 Nov 2012, Ian Yang wrote:
> > On Sat, Nov 17, 2012 at 8:01 AM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Thu, 15 Nov 2012, Ian Yang wrote:
> > > >
> > > > That's a good idea. We really need an element to wrap all the <p>s,
> > > > <ul>s, <ol>s, <figure>s, <table>s ... etc of a blog post.
> > >
> > > That's called <article>.
> >
> > Thanks Hickson. Actually I had turned down my own opinion (
> >
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Nov/0182.html
> > ).
> >
> > And isn't <article> used to wrap an entire blog post? Like this:
> >
> > <article>
> >     <header />
> >     <div />
> >     <footer />
> > </article>
>
> Right. It wraps all the elements of a blog post. All the <p>s, <ul>s,
> <ol>s, <figure>s, <table>s, <h1>s, <footer>s, etc.
>
> If you just want to wrap a subpart of that for rendering purposes, <div>
> is the element you want. Basically <div> is always the answer if the
> question is "how do I provide myself a hook for CSS styling".

"A hook for CSS styling" is just a side benefit. That's not the primary
thing I want. Personally I care about the meaningfulness and the semantic
aspect of HTML. Therefore what I want is a meaningful element which is
designed to wrap the content of a blog post.

Regards,
Ian Yang

From ian at hixie.ch  Mon Nov 19 21:47:33 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 05:47:33 +0000 (UTC)
Subject: [whatwg] Proposal: location.parentOrigin
In-Reply-To: <CAJE5ia8pnaay=ZMwARSPCoavaT5JmLaDUyUQHpPQt2ewD5vtoQ@mail.gmail.com>
References: <CAJE5ia_dm1tfObx5_eWfhPkzroV63THc+BYLsDJiEjcppBCfag@mail.gmail.com>
	<CAJE5ia_J4P4iJ_BS5H8m5ANSzXDewDq3HFf1XZMGYve2oSAKYQ@mail.gmail.com>
	<Pine.LNX.4.64.1204032330550.22654@ps20323.dreamhostps.com>
	<CAJE5ia9q3mzT7m9GHmkK8TSd1-VEtrbSpmjdENCanofPrhpGSw@mail.gmail.com>
	<Pine.LNX.4.64.1204040153400.22654@ps20323.dreamhostps.com>
	<CAJE5ia9dh9Wvh6V1wXFp35WVNaXfdUzhanM7Zo30bL9RLkxzjA@mail.gmail.com>
	<Pine.LNX.4.64.1204041758470.22654@ps20323.dreamhostps.com>
	<CAJE5ia8H0svt8hQetFudk8XUq1WSYD4Jg6ZzV1=LOiKQ1cd4oA@mail.gmail.com>
	<CA+c2ei_uiu-0NJ8_rgiQ-SjVOHg1beok2n0HY_y8ZwUXHB-Wfw@mail.gmail.com>
	<CALx_OUCMFr+wyyCXWyvzKj_Xm863oJiCYRqn9vJui8+2WB45bw@mail.gmail.com>
	<CALx_OUCco-kp2DSFr_MekPCTV+cMR6Jop9cT-cXGuGm6gyaS2Q@mail.gmail.com>
	<Pine.LNX.4.64.1204051759050.22654@ps20323.dreamhostps.com>
	<CALx_OUA2EJ8+SbPkQpncq6jPpxRYzxSufv=TeqWiRMh719cGbw@mail.gmail.com>
	<CAJE5ia8pnaay=ZMwARSPCoavaT5JmLaDUyUQHpPQt2ewD5vtoQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211200539480.26354@ps20323.dreamhostps.com>

On Mon, 26 Mar 2012, Adam Barth wrote:
> 
> For nested browsing contexts, expose the origin of the parent browsing 
> context via location.parentOrigin.  (For non-nested browsing context, 
> the property would null.)

This ended up implemented in WebKit as Location.ancestorOrigins(), a 
method that returns a static DOMStringList with the origins of the 
ancestor browsing contexts in reverse order (top-level browsing context 
last, parent browsing context first). It doesn't respect sandboxing.

Are other browser vendors interested in implementing this?

From ian at hixie.ch  Mon Nov 19 22:17:17 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 06:17:17 +0000 (UTC)
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50A12B1F.1080200@lamouri.fr>
References: <50A12B1F.1080200@lamouri.fr>
Message-ID: <Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>

On Mon, 12 Nov 2012, Mounir Lamouri wrote:
> 
> We've been working on implementing date and time input types attributes 
> at Mozilla this summer and we found out that 'datetime-local' and 
> 'datetime' have a quite odd behaviour.
> 
> 'date' and 'time' are both timezone agnostic types: you just set a time 
> and date and we assume that it is relative to something. So, it seems 
> somewhat natural to assume that 'datetime' would be simply those types 
> added to each other. Instead of that, 'datetime' has a notion of 
> timezone and 'datetime-local' is the timezone agnostic type.
> 
> In addition of being more intuitive, it seems that a huge majority of 
> date/time usage are timezone agnostics because, usually, the timezone is 
> implicit. For example, booking flight/train tickets. There is however 
> some use cases I can think of, like scheduling a meeting, where, 
> sometimes, you might want to mess with timezones. But those are quite 
> rare.

Actually I think the ones that are rare are the agnostic ones -- and 
they're agnostic just because the site already has other information, such 
as the geographical location at which the time is relevant (as in the case 
of plane tickets) or because they follow the user's time zone regardless 
(as in some cases for alarm clocks).

However, if you think it would help to rename "datetime-local" to 
"datetime", and rename the old "datetime" to "datetime-global" or some 
such, and if browser vendors are willing to make that change, then I guess 
we can do that. Anyone from Opera have any input on that, in particular?

FWIW, the UI I'd expect for today's datetime, maybe renamed to 
"datetime-global", would be a date/time picker that works just like the 
one without a timezone, except that it then converts the time you give 
into UTC. So far example, I'm in the PST time zone, so if I said November 
19th, 5pm, it would send that as November 20th, 1am UTC.

The idea is to be able to get a precise time from the user without having 
to worry about what time zone the user's in, and without the user having 
to worry about what time zone other users are in. This would be very 
useful for scheduling global events, e.g. when a hangout is to happen, or 
when a game is to start, etc. I really don't think this is a rare thing. 
In fact I think mostly it's the one to encourage people to use, which is 
why it's called "datetime" currently, with the one without timezones, 
which I think will overall be rarer, having the longer name.

I agree that existing UIs are unfortunate, but they should be fixed. It 
would be unfortunate to push people towards the timezone-less control just 
because we screwed up the UI and then renamed the type in shame.

From ian at hixie.ch  Mon Nov 19 22:23:55 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 06:23:55 +0000 (UTC)
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <50AAEF01.4000004@mit.edu>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
	<Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
	<50AAEF01.4000004@mit.edu>
Message-ID: <Pine.LNX.4.64.1211200618280.26354@ps20323.dreamhostps.com>

On Mon, 19 Nov 2012, Boris Zbarsky wrote:
> On 11/19/12 8:38 PM, Ian Hickson wrote:
> > For now I've tightened up the spec so it should be implementable, 
> > secure, and Web-compatible
> 
> I don't believe it's secure as currently written, actually.  Filed 
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20012

Could you elaborate in the bug? I've no idea what you think is wrong.

> > I'm also curious as to why figuring out the "entry script"'s 
> > characteristics needs to use the stack introspection rather than just 
> > having an event-loop global "first script" variable
> 
> You can maintain a stack of entry scripts.  You can't use a global, 
> because you need to push and pop entry scripts as various things happen 
> (e.g. invoking event listeners sets the entry script to the event 
> listener function's script for the duration of the event listener 
> invocation).

The way the spec does it, the stack is implemented as the actual call 
stack, with nested calls to "jump to a code entry-point" storing the old 
value, updating the global, running the script, then restoring the global 
to the stored old value.

> There is no such stack of entry scripts in Gecko yet, but we're working 
> on changing that.
>
> The thing that _really_ requires stack introspection is when you need to 
> look at the caller script instead of the entry script.  Which is what 
> you need to do when performing Location security checks (or indeed, any 
> security checks).

Can you show an example of when that is needed?

As far as I can tell, the entry script always has the same origin as the 
running script. I guess this isn't necessarily true of the effective 
origin, which is what we're using for the Location object security? Is 
that the problem here?

If so, why don't we just make it be an origin check of the entry script 
instead of an effective origin check? If that would make it simpler for 
Gecko, that's fine by me. I don't really see why it would matter in this 
case anyway; if you have both calling each other then you can almost 
certainly trick the script into doing what you want either way.

From ian at hixie.ch  Mon Nov 19 22:25:13 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 06:25:13 +0000 (UTC)
Subject: [whatwg] Use of article to identify the main content of a web
 page
In-Reply-To: <CABr1FseMsb2xjMTVCO4pCFe74A1eqyxJyzFi0wA6req37=UaRQ@mail.gmail.com>
References: <CA+ri+VnsR8EzCWO0Y15jh7__8Pb+HU-2eYMVM9RX-6QfpucEeA@mail.gmail.com>
	<CABr1Fsc7x82q1bniqEO4yWMo+gKQPWt+882z+2zipZDD6ZB3+A@mail.gmail.com>
	<op.wn07hgzzy3oazb@v3-151-181.yandex.net>
	<Pine.LNX.4.64.1211191805470.26354@ps20323.dreamhostps.com>
	<CABr1FseMsb2xjMTVCO4pCFe74A1eqyxJyzFi0wA6req37=UaRQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211200624090.26354@ps20323.dreamhostps.com>

On Tue, 20 Nov 2012, Ian Yang wrote:
> 
> "A hook for CSS styling" is just a side benefit. That's not the primary 
> thing I want. Personally I care about the meaningfulness and the 
> semantic aspect of HTML. Therefore what I want is a meaningful element 
> which is designed to wrap the content of a blog post.

Semantics for the sake of semantics is not a use case.

From bzbarsky at MIT.EDU  Mon Nov 19 23:20:11 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 20 Nov 2012 02:20:11 -0500
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <Pine.LNX.4.64.1211200618280.26354@ps20323.dreamhostps.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
	<Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
	<50AAEF01.4000004@mit.edu>
	<Pine.LNX.4.64.1211200618280.26354@ps20323.dreamhostps.com>
Message-ID: <50AB2F2B.1080007@mit.edu>

On 11/20/12 1:23 AM, Ian Hickson wrote:
> Could you elaborate in the bug? I've no idea what you think is wrong.

Done, but what's wrong is that the security checks described in the spec 
check the origin of the wrong document.

>> You can maintain a stack of entry scripts.  You can't use a global,
>> because you need to push and pop entry scripts as various things happen
>> (e.g. invoking event listeners sets the entry script to the event
>> listener function's script for the duration of the event listener
>> invocation).
>
> The way the spec does it, the stack is implemented as the actual call
> stack, with nested calls to "jump to a code entry-point" storing the old
> value, updating the global, running the script, then restoring the global
> to the stored old value.

Sure, that works.  One way or another, you need to have a stack.  ;) 
And if part of your WebAPI/DOM/etc implementation itself is done in JS 
you have to be careful to not update the entry-point stuff when calling 
into that JS, of course.

>> The thing that _really_ requires stack introspection is when you need to
>> look at the caller script instead of the entry script.  Which is what
>> you need to do when performing Location security checks (or indeed, any
>> security checks).
>
> Can you show an example of when that is needed?

Uh... any time you do a security check, in general.

> As far as I can tell, the entry script always has the same origin as the
> running script.

All you need for script A to be able to call script B as the spec us 
currently written is that sometime in the past the effective script 
origin of A matched the effective script origin of some script C and 
that at some point in the past (possibly a completely different point) 
the effective script origin of B matched the effective script origin of 
C (which may not have been the same at that point as when C matched A!). 
  There is no requirement that A ever matched B, or even that the sets 
of effective script origins A and B have had in the past have nonempty 
intersection.

And even that may not be true depending on whether UAs allow 
"privileged" JS in various settings.  If they do, then the entry script 
becomes very useless for origin determination unless crossing origin 
barriers resets the entry script.  Which, again, is not the case in 
Gecko right now.  But that's obviously Gecko's problem, for the moment.

> I guess this isn't necessarily true of the effective
> origin, which is what we're using for the Location object security? Is
> that the problem here?

I think the problem is that you're assuming invariants that just don't 
hold.  There is no current requirement in the spec that there be any 
relationship between either the origin or effective script origin of the 
entry script and the origins of the currently running script.

> If so, why don't we just make it be an origin check of the entry script
> instead of an effective origin check?

Because that would be totally wrong; see above.

> If that would make it simpler for Gecko

As things stand, it wouldn't, particularly.  It would actually introduce 
security bugs.

> if you have both calling each other then you can almost
> certainly trick the script into doing what you want either way.

Who said anything about both calling each other?  Gecko's security model 
is asymmetric in practice.

-Boris

From tobie.langel at gmail.com  Mon Nov 19 23:27:47 2012
From: tobie.langel at gmail.com (Tobie Langel)
Date: Tue, 20 Nov 2012 08:27:47 +0100
Subject: [whatwg] Proposal: location.parentOrigin
In-Reply-To: <Pine.LNX.4.64.1211200539480.26354@ps20323.dreamhostps.com>
References: <CAJE5ia_dm1tfObx5_eWfhPkzroV63THc+BYLsDJiEjcppBCfag@mail.gmail.com>
	<CAJE5ia_J4P4iJ_BS5H8m5ANSzXDewDq3HFf1XZMGYve2oSAKYQ@mail.gmail.com>
	<Pine.LNX.4.64.1204032330550.22654@ps20323.dreamhostps.com>
	<CAJE5ia9q3mzT7m9GHmkK8TSd1-VEtrbSpmjdENCanofPrhpGSw@mail.gmail.com>
	<Pine.LNX.4.64.1204040153400.22654@ps20323.dreamhostps.com>
	<CAJE5ia9dh9Wvh6V1wXFp35WVNaXfdUzhanM7Zo30bL9RLkxzjA@mail.gmail.com>
	<Pine.LNX.4.64.1204041758470.22654@ps20323.dreamhostps.com>
	<CAJE5ia8H0svt8hQetFudk8XUq1WSYD4Jg6ZzV1=LOiKQ1cd4oA@mail.gmail.com>
	<CA+c2ei_uiu-0NJ8_rgiQ-SjVOHg1beok2n0HY_y8ZwUXHB-Wfw@mail.gmail.com>
	<CALx_OUCMFr+wyyCXWyvzKj_Xm863oJiCYRqn9vJui8+2WB45bw@mail.gmail.com>
	<CALx_OUCco-kp2DSFr_MekPCTV+cMR6Jop9cT-cXGuGm6gyaS2Q@mail.gmail.com>
	<Pine.LNX.4.64.1204051759050.22654@ps20323.dreamhostps.com>
	<CALx_OUA2EJ8+SbPkQpncq6jPpxRYzxSufv=TeqWiRMh719cGbw@mail.gmail.com>
	<CAJE5ia8pnaay=ZMwARSPCoavaT5JmLaDUyUQHpPQt2ewD5vtoQ@mail.gmail.com>
	<Pine.LNX.4.64.1211200539480.26354@ps20323.dreamhostps.com>
Message-ID: <CAMK=o4cgLn4sV3vyfY7kX9SrpeRhtcpjJzaNq7Br+hATE3Cvng@mail.gmail.com>

On Tue, Nov 20, 2012 at 6:47 AM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 26 Mar 2012, Adam Barth wrote:
>>
>> For nested browsing contexts, expose the origin of the parent browsing
>> context via location.parentOrigin.  (For non-nested browsing context,
>> the property would null.)
>
> This ended up implemented in WebKit as Location.ancestorOrigins(), a
> method that returns a static DOMStringList with the origins of the
> ancestor browsing contexts in reverse order (top-level browsing context
> last, parent browsing context first). It doesn't respect sandboxing.

This API is painful to use and doesn't contain any info for
window.opener or sibling browsing contexts (see WebKit bug[1] and
related discussion on G+[2]) which makes it useless for some of the
use cases.

A better API would allow to get the origin of a referenced browsing
context, e.g.:

window.getOrigin(otherWindow);

and to check whether it came from the same origin (sugar around
window.getOrigin(otherWindow) == window.getOrigin(window)):

window.isSameOrigin(otherWindow);

That said, one of the key use cases for this API is to code around a
Webkit bug[3] so maybe that should be fixed first.

--tobie

---
[1]: https://bugs.webkit.org/show_bug.cgi?id=83493
[2]: https://plus.google.com/116910304844117268718/posts/QyHfGL9GBd5
[3]: https://bugs.webkit.org/show_bug.cgi?id=43504

From ian at hixie.ch  Mon Nov 19 23:38:36 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 07:38:36 +0000 (UTC)
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <50AB2F2B.1080007@mit.edu>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
	<Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
	<50AAEF01.4000004@mit.edu>
	<Pine.LNX.4.64.1211200618280.26354@ps20323.dreamhostps.com>
	<50AB2F2B.1080007@mit.edu>
Message-ID: <Pine.LNX.4.64.1211200733470.16964@ps20323.dreamhostps.com>

On Tue, 20 Nov 2012, Boris Zbarsky wrote:
> 
> All you need for script A to be able to call script B as the spec us 
> currently written is that sometime in the past the effective script 
> origin of A matched the effective script origin of some script C and 
> that at some point in the past (possibly a completely different point) 
> the effective script origin of B matched the effective script origin of 
> C (which may not have been the same at that point as when C matched A!).

I have great difficulty worrying about C accessing A. If you set 
document.domain and yet don't trust the other side, you've basically lost. 
Don't do that.

IMHO there's no point us trying to keep things locked down when you set 
document.domain. I'd be fine with making all the security checks still use 
the entry script's real origin, except that Window would now allow you 
access to stuff you didn't have access to before.

> I think the problem is that you're assuming invariants that just don't 
> hold. There is no current requirement in the spec that there be any 
> relationship between either the origin or effective script origin of the 
> entry script and the origins of the currently running script.

Because of document.domain. Yeah.

Man I wish we could just kill document.domain.

> > if you have both calling each other then you can almost certainly 
> > trick the script into doing what you want either way.
> 
> Who said anything about both calling each other?

If they're not calling each other, how are they both on the stack?

From ian at hixie.ch  Mon Nov 19 23:49:52 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 07:49:52 +0000 (UTC)
Subject: [whatwg] Font Resize Event
In-Reply-To: <506F5C35.3070009@mozilla.com>
References: <CAEHyr+ZhyytWCt0xPct8UuV15Sh+idpwJr86FGO4rXRteaNR7w@mail.gmail.com>
	<506F5C35.3070009@mozilla.com>
Message-ID: <Pine.LNX.4.64.1211200749010.26354@ps20323.dreamhostps.com>

On Wed, 26 Sep 2012, Hugh Guiney wrote:
>
> My use case: I have a <div> with overflow: hidden that contains slides 
> as part of a JavaScript carousel. It has to be overflow: hidden because 
> otherwise the unseen slides are visible/stretch the page. And because 
> each slide is different, the containing <div> therefore needs to 
> grow/shrink in height depending on the content currently being 
> displayed. This is trivial enough to do, by changing the height to match 
> its contents whenever a slide change occurs, or a resize or 
> orientationchange event is fired, but currently if I increase or 
> decrease the font size, the content can get cut off, or there will be a 
> ton of extra white space, since the <div> height is out of sync with the 
> height of its contents. This could be easily remedied with a fontresize 
> (or textresize) event.

This sounds more like a rendering-time feature, so I would recommend 
approaching the CSS working group at www-style at w3.org with the idea. (The 
WHATWG specs currently don't cover this area of the Web platform.)

From froidure_nicolas at yahoo.fr  Tue Nov 20 00:37:35 2012
From: froidure_nicolas at yahoo.fr (Nicolas Froidure)
Date: Tue, 20 Nov 2012 09:37:35 +0100
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
References: <50A12B1F.1080200@lamouri.fr>
	<Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
Message-ID: <50AB414F.8090108@yahoo.fr>

On 20/11/2012 07:17, Ian Hickson wrote:
> a date/time picker that works just like the
> one without a timezone, except that it then converts the time you give
> into UTC.
>    
That's exactly the behavior i would like to have. From the server side 
it seems nice.

The bad is that Javascript Date objects are initialized with local time 
and prints local time (toString 
<https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toString>). 
Web developers could expect the same behavior for date inputs and date 
objects.

Regards, Nicolas Froidure.

From froidure_nicolas at yahoo.fr  Tue Nov 20 02:27:24 2012
From: froidure_nicolas at yahoo.fr (Nicolas Froidure)
Date: Tue, 20 Nov 2012 11:27:24 +0100
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
References: <50A12B1F.1080200@lamouri.fr>
	<Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
Message-ID: <50AB5B0C.9050109@yahoo.fr>

Regards, Nicolas Froidure.

From mounir at lamouri.fr  Tue Nov 20 03:49:51 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Tue, 20 Nov 2012 11:49:51 +0000
Subject: [whatwg] Make stepUp() and stepDown() more developer-friendly
Message-ID: <50AB6E5F.5050803@lamouri.fr>

Hi,

Currently stepUp(n) and stepDown(n) are very basic methods. They more or
less do value += n * allowedValueStep; with n = -n; if stepDown() was
called. In addition of being pretty dumb, there are a lot of reasons why
they can throw.

At Mozilla, we think that the main use case for stepUp() and stepDown()
is to create a UI with spin buttons: clicking on the up arrow would call
stepUp() and clicking on the down arrow would call stepDown(). Such a
use case needs methods that do better than just adding n * allowedValueStep.
In addition, we think that throwing is very often a bad idea and that
should happen when the developer clearly did something wrong.

So, we would like to change the stepUp()/stepDown() algorithm to match
the following behaviour:
- we only throw if the input type doesn't allow those methods or if
there is no allowed value step;
- if the value isn't a number (aka empty string), we should just exit
the steps;
- if the value is below the minimal allowed value and n is negative, we
should exit the steps;
- if the value is above the maximal allowed value and n is positive, we
should exit the steps;
- if the element is suffering from a step mismatch, and n is negative,
the value should be changed to the next valid value. Otherwise, it
should be changed to the previous allowed value;
- newValue = value + n * allodValueStep;
- if the newValue is below the minimal allowed value, the newValue
should be equal the minimal allowed value;
- if the newValue is higher than the minimal allowed value, the newValue
should be equal the minimal allowed value.

Such a behaviour creates a real added value in stepUp() and stepDown()
that make those methods useful compared to simply do value += n *
allowedValueStep; and prevent throwing when there is no need to.

It is interesting to see that <input type=number> spin buttons in Chrome
have that behaviour [1] but stepUp() and stepDown() do not.

Opera has the same kind of UI behaviour than Chrome and
stepUp()/stepDown() tries to be more clever than what the specifications
say (it is clamping to the nearest allowed value). However, it is still
throwing too much.

You can try the implementation of stepUp() and stepDown() in Firefox
desktop by enablinig the pref "dom.experimental_forms" or by using
Firefox Android (no need to toggle any pref).

You can use this page to test:
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918

[1] The only difference between Chrome's spin buttons behaviour and our
proposal is that when value is the empty string, it is setting value to
0 and continue to the next steps (unless the 0 is below the minimal
allowed value and n < 0, in that case value=min). It might be
interesting to specify something better than "do nothing" if value="".

Cheers,
--
Mounir

From bzbarsky at MIT.EDU  Tue Nov 20 08:23:44 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 20 Nov 2012 11:23:44 -0500
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <Pine.LNX.4.64.1211200733470.16964@ps20323.dreamhostps.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
	<Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
	<50AAEF01.4000004@mit.edu>
	<Pine.LNX.4.64.1211200618280.26354@ps20323.dreamhostps.com>
	<50AB2F2B.1080007@mit.edu>
	<Pine.LNX.4.64.1211200733470.16964@ps20323.dreamhostps.com>
Message-ID: <50ABAE90.7010709@mit.edu>

On 11/20/12 2:38 AM, Ian Hickson wrote:
> IMHO there's no point us trying to keep things locked down when you set
> document.domain.

I believe sites actually rely on a certain amount of lockdown in 
situations like this...  Adam can fill you in, I'm sure.

But in general, as people work more and more on Widgety and Appy stuff 
in HTML, with various expanded privileges, granted permissions, etc, the 
assumption that the security model is completely symmetric just becomes 
false.  I'd rather we didn't paint ourselves into a corner by assuming 
otherwise here and requiring behavior that UAs would simply refuse to 
implement because they view it as insecure.

>>> if you have both calling each other then you can almost certainly
>>> trick the script into doing what you want either way.
>>
>> Who said anything about both calling each other?
>
> If they're not calling each other, how are they both on the stack?

This only requires one of them calling the other.  It doesn't require 
"the other" being able to call back into "one".

Maybe that's not what you meant, though.  So let me give you a concrete 
not-exactly-hypothetical example.

Say I'm implementing a debugger in a web browser, and I implement my UI 
in HTML+JS as browsers are tending to do now.  When I examine properties 
with scripted getters in this debugger, what should happen?  I will bet 
money that the debugger is not, generally, running with the permissions 
of the page, because it needs to be able to do things that web pages 
aren't allowed to do.  However the getters in question had better run 
with the permissions of the page; otherwise you open up the debugger to 
attacks from the web page.  This problem is not solvable using the 
"separate worlds" approaches browsers use to provide extensions with an 
unmodified view of the DOM, since the debugger really does want to see 
what's going on in the web page itself; it just doesn't want to allow 
the page to escalate permissions.

Now I know there are several possible objections to this use case, so 
let me just pre-address some:

1)  "It's not the web, so we don't have to specify it."  That's true, 
sure.  I suspect as time goes on we might in fact need to specify 
something like this for apps, however.  And more importantly, just 
because it's not the web doesn't mean UAs are not implementing it, and 
if they're implementing it they need to make it work with their security 
model, whatever it is.

2)  "The debugger can have some magic to make it all work."  Yes, but 
then the question is how it interacts with the web security model and 
how the result can be implemented.

3)  "The debugger should set the entry script before invoking the 
getter."  This is a plausible approach, but it makes it very error-prone 
and complicated to create things like the above-described debugger: you 
have to manually keep track of which objects come from where instead of 
just having the web platform implementation (which already has that 
information) keep track of it for you.

4)  "Entry script should always be set when crossing origins" (for some 
definition of "crossing origins").  This seems plausible as well.  Maybe 
it's doable.

One other note: Gecko's current model is at least somewhat influenced by 
the fact that in the past Gecko had expanded privileges on a 
per-function basis.  This obviously made using the entry script a 
non-starter...  Maybe it's more of a starter now.  I'll let Bobby worry 
about it.  ;)

-Boris

From dbk at google.com  Tue Nov 20 08:34:14 2012
From: dbk at google.com (David Barrett-Kahn)
Date: Tue, 20 Nov 2012 10:34:14 -0600
Subject: [whatwg] Proposal for a debugging information API
In-Reply-To: <Pine.LNX.4.64.1211170001590.16964@ps20323.dreamhostps.com>
References: <CA+iXHYNOtDvgR4JpR4=94tMoPc9fDO1agrNpswQN4fmrNZSFyw@mail.gmail.com>
	<CAMK=o4eziZ+7qs-OVgAWiPe89UKD_AqtZ1X4v=R527eVhUDgfA@mail.gmail.com>
	<CA+iXHYOL6kM8gVaXm+Vxai5Pdq2hFr-ZTOtHqBg05g+=SaYR=w@mail.gmail.com>
	<Pine.LNX.4.64.1211161801120.16964@ps20323.dreamhostps.com>
	<CA+iXHYNQeYtbavABGdwXVtWrV-2aRmxD2NBbtmJrqdb3BugU1w@mail.gmail.com>
	<Pine.LNX.4.64.1211170001590.16964@ps20323.dreamhostps.com>
Message-ID: <CA+iXHYM9PyzXQ0cpOQoEFEg6gGZgpLwDpSSCj=cbUNFEWdpWfQ@mail.gmail.com>

I'm not sensing a lot of enthusiasm about this proposal, and am guessing it
would be an uphill slog with all the privacy/security issues involved.  I'm
therefore thinking I won't take it any further.  If you feel something
important is being lost here and that you could help me move this forward
do let me know though.

Thanks,

-Dave

On Fri, Nov 16, 2012 at 6:04 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 16 Nov 2012, David Barrett-Kahn wrote:
> >
> > Thanks Ian. So here's what confuses me, why is the bar so much higher
> > for traditional webapps than it is for browser extensions, chrome apps,
> > native apps, mobile apps or nearly anything else?
>
> Browser extensions, chrome apps, native apps, and mobile apps aren't
> anywhere near as secure as Web apps.
>
> The bar shouldn't be any lower for them than for the Web, but that it is
> is one of the Web's biggest strengths. You can, by and large, follow any
> random link, and be assured that you're not going to get scammed (modulo
> security bugs). If you just install any random native program you come
> across, your machine is going to become a nest of malware.
>
>
> > Extensions, chrome apps, and mobile apps have a consent experience, but
> > it's hard to argue that users are making an informed decision there and
> > that the consent experience really protects them. Native apps have no
> > consent experience at all.
>
> Right. Compare the average amount of malware on a Windows machine to that
> on a Chrome OS machine. :-)
>
>
> > I guess I'm hoping you can point me to some guidelines you've developed
> > or which you agree with on where the limits of the web sandbox should
> > be.  I'd rather not force you to re-have a discussion I'm sure you've
> > had far too many times :-)
>
> I don't think there's anything formally written down.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

-- 
-Dave

From scott.gonzalez at gmail.com  Tue Nov 20 09:34:36 2012
From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=)
Date: Tue, 20 Nov 2012 12:34:36 -0500
Subject: [whatwg] Make stepUp() and stepDown() more developer-friendly
In-Reply-To: <50AB6E5F.5050803@lamouri.fr>
References: <50AB6E5F.5050803@lamouri.fr>
Message-ID: <CAO8i3icCK=WYhMe=ToaRw7VWerBi5CmuYidFfoi9nNOaMXAnkA@mail.gmail.com>

Can you explain why these methods should be no-ops if the value is above
the max or below the min? In jQuery UI, we decided that using these methods
should always result in a valid value.

I can list out the steps we take for all conditions, but I'd like to hear
everyone's thoughts on the various cases where you're suggesting that the
methods do nothing.

On Tue, Nov 20, 2012 at 6:49 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:

> Hi,
>
> Currently stepUp(n) and stepDown(n) are very basic methods. They more or
> less do value += n * allowedValueStep; with n = -n; if stepDown() was
> called. In addition of being pretty dumb, there are a lot of reasons why
> they can throw.
>
> At Mozilla, we think that the main use case for stepUp() and stepDown()
> is to create a UI with spin buttons: clicking on the up arrow would call
> stepUp() and clicking on the down arrow would call stepDown(). Such a
> use case needs methods that do better than just adding n *
> allowedValueStep.
> In addition, we think that throwing is very often a bad idea and that
> should happen when the developer clearly did something wrong.
>
> So, we would like to change the stepUp()/stepDown() algorithm to match
> the following behaviour:
> - we only throw if the input type doesn't allow those methods or if
> there is no allowed value step;
> - if the value isn't a number (aka empty string), we should just exit
> the steps;
> - if the value is below the minimal allowed value and n is negative, we
> should exit the steps;
> - if the value is above the maximal allowed value and n is positive, we
> should exit the steps;
> - if the element is suffering from a step mismatch, and n is negative,
> the value should be changed to the next valid value. Otherwise, it
> should be changed to the previous allowed value;
> - newValue = value + n * allodValueStep;
> - if the newValue is below the minimal allowed value, the newValue
> should be equal the minimal allowed value;
> - if the newValue is higher than the minimal allowed value, the newValue
> should be equal the minimal allowed value.
>
> Such a behaviour creates a real added value in stepUp() and stepDown()
> that make those methods useful compared to simply do value += n *
> allowedValueStep; and prevent throwing when there is no need to.
>
> It is interesting to see that <input type=number> spin buttons in Chrome
> have that behaviour [1] but stepUp() and stepDown() do not.
>
> Opera has the same kind of UI behaviour than Chrome and
> stepUp()/stepDown() tries to be more clever than what the specifications
> say (it is clamping to the nearest allowed value). However, it is still
> throwing too much.
>
> You can try the implementation of stepUp() and stepDown() in Firefox
> desktop by enablinig the pref "dom.experimental_forms" or by using
> Firefox Android (no need to toggle any pref).
>
> You can use this page to test:
> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918
>
> [1] The only difference between Chrome's spin buttons behaviour and our
> proposal is that when value is the empty string, it is setting value to
> 0 and continue to the next steps (unless the 0 is below the minimal
> allowed value and n < 0, in that case value=min). It might be
> interesting to specify something better than "do nothing" if value="".
>
> Cheers,
> --
> Mounir
>

From ian at hixie.ch  Tue Nov 20 09:46:38 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 17:46:38 +0000 (UTC)
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <50ABAE90.7010709@mit.edu>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
	<Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
	<50AAEF01.4000004@mit.edu>
	<Pine.LNX.4.64.1211200618280.26354@ps20323.dreamhostps.com>
	<50AB2F2B.1080007@mit.edu>
	<Pine.LNX.4.64.1211200733470.16964@ps20323.dreamhostps.com>
	<50ABAE90.7010709@mit.edu>
Message-ID: <Pine.LNX.4.64.1211201724560.16964@ps20323.dreamhostps.com>

On Tue, 20 Nov 2012, Boris Zbarsky wrote:
> On 11/20/12 2:38 AM, Ian Hickson wrote:
> > IMHO there's no point us trying to keep things locked down when you 
> > set document.domain.
> 
> I believe sites actually rely on a certain amount of lockdown in 
> situations like this...  Adam can fill you in, I'm sure.

I would certainly be interested in concrete examples of this. I would be 
shocked if such sites weren't already vulnerable to something or other.

> But in general, as people work more and more on Widgety and Appy stuff 
> in HTML, with various expanded privileges, granted permissions, etc, the 
> assumption that the security model is completely symmetric just becomes 
> false. I'd rather we didn't paint ourselves into a corner by assuming 
> otherwise here and requiring behavior that UAs would simply refuse to 
> implement because they view it as insecure.

Given the way JavaScript works, I just don't see a sane way to make a 
non-symmetric model work. JS just allows too much introspection. Any time 
you pass a string from one to the other, you're also passing a way for the 
callee to call back into the caller, for example (via the string's 
methods). Passing any sort of structured objects similarly means passing 
mehods. Callbacks are also a very widely used pattern.

We have mechanisms for safe passing of data from one context to another, 
such as postMessage(). Doing it by having one-way glass in JS just seems 
like asking for trouble.

> Say I'm implementing a debugger in a web browser, and I implement my UI in
> HTML+JS as browsers are tending to do now.  When I examine properties with
> scripted getters in this debugger, what should happen?  I will bet money that
> the debugger is not, generally, running with the permissions of the page,
> because it needs to be able to do things that web pages aren't allowed to do.

Yeah, like running getters with the ability to abort them if they don't 
return promptly.

> However the getters in question had better run with the permissions of 
> the page; otherwise you open up the debugger to attacks from the web 
> page.  This problem is not solvable using the "separate worlds" 
> approaches browsers use to provide extensions with an unmodified view of 
> the DOM, since the debugger really does want to see what's going on in 
> the web page itself; it just doesn't want to allow the page to escalate 
> permissions.
> 
> Now I know there are several possible objections to this use case, so 
> let me just pre-address some:
> 
> 1)  "It's not the web, so we don't have to specify it."  That's true, 
> sure.

I'd go even further. Debuggers are a rare exception, IMHO, which can't be 
fully specified because the whole point is that they want to examine 
everything that _is_ specified. I have no problem leaving the specific 
case of debuggers, profilers, and similar development tools out of what we 
need to specify to get interoperability.

But your underlying point, that we can't rely on the entry script and the 
real origin, is sound. In particular, anything that's to be affected by 
document.domain has to use the calling script, not the entry script, and 
has to use the effective origin, not the real origin. It would be useful 
if someone (other than me) were to review the spec's uses of the term 
"entry script" and "origin" and verify that the checks all make sense.

Anyway, we're kind of getting away from the original topic here, which 
isn't fully resolved; Location.

In thinking about this further last night, it struck me that while the 
proposed proxy mechanism was IMHO overly complex, there might be a simpler 
mechanism that still gets all the compatibility needs, and works for 
Mozilla, and isn't quite so crazy. I'm not a huge fan of this, but I'd be 
interested in what Adam thinks of it.

Right now, as specced, each Document gets a Location object, but they all 
act the same: they all work on the active document and they all do 
security checks based on the active document, not the Location's Document.

But what if, instead, we had one Location per Document, and it worked on 
that Document (not the active document), with the security policy being 
like Window, specific to its Document's effective origin, but instead of 
ever getting references to it, you only got references to a proxy that 
acted on the active document's Location?

Then you wouldn't need to do anything with properties added by the author, 
either, they'd just work normally (like on Window).

I'm not a big fan of this, but if this simplified model works for WebKit, 
maybe it's worth it?

It's still less intuitive than just having unique Location objects, 
though.

From bobbyholley at gmail.com  Tue Nov 20 10:40:16 2012
From: bobbyholley at gmail.com (Bobby Holley)
Date: Tue, 20 Nov 2012 10:40:16 -0800
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <Pine.LNX.4.64.1211201724560.16964@ps20323.dreamhostps.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
	<Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
	<50AAEF01.4000004@mit.edu>
	<Pine.LNX.4.64.1211200618280.26354@ps20323.dreamhostps.com>
	<50AB2F2B.1080007@mit.edu>
	<Pine.LNX.4.64.1211200733470.16964@ps20323.dreamhostps.com>
	<50ABAE90.7010709@mit.edu>
	<Pine.LNX.4.64.1211201724560.16964@ps20323.dreamhostps.com>
Message-ID: <CAKBxTcKoaV64huR=7QxK4Y245WONoMnqqV_yA15JFrb+FGX7DA@mail.gmail.com>

On Tue, Nov 20, 2012 at 9:46 AM, Ian Hickson <ian at hixie.ch> wrote:

> Given the way JavaScript works, I just don't see a sane way to make a
> non-symmetric model work. JS just allows too much introspection. Any time
> you pass a string from one to the other, you're also passing a way for the
> callee to call back into the caller, for example (via the string's
> methods). Passing any sort of structured objects similarly means passing
> mehods. Callbacks are also a very widely used pattern.
>

We actually implement this. It's pretty off-topic for the thread at this
point, but I'd be happy to talk about it in a separate thread or on IRC if
you're interested. I'd also be interested to hear your thoughts about it.

Anyway, we're kind of getting away from the original topic here, which
> isn't fully resolved; Location.
>
> In thinking about this further last night, it struck me that while the
> proposed proxy mechanism was IMHO overly complex, there might be a simpler
> mechanism that still gets all the compatibility needs, and works for
> Mozilla, and isn't quite so crazy. I'm not a huge fan of this, but I'd be
> interested in what Adam thinks of it.
>
> Right now, as specced, each Document gets a Location object, but they all
> act the same: they all work on the active document and they all do
> security checks based on the active document, not the Location's Document.
>
> But what if, instead, we had one Location per Document, and it worked on
> that Document (not the active document), with the security policy being
> like Window, specific to its Document's effective origin, but instead of
> ever getting references to it, you only got references to a proxy that
> acted on the active document's Location?
>

Wouldn't this effectively mean having a LocationProxy, just like
WindowProxy? I'm certainly all for it, and think that it makes things much
more sane, though I don't understand why this wouldn't "propagate the
magic" that Adam doesn't want to propagate. I might be misunderstanding you
though. Can you clarify?

From bzbarsky at MIT.EDU  Tue Nov 20 10:50:59 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Tue, 20 Nov 2012 13:50:59 -0500
Subject: [whatwg] Location object identity and navigation behavior
In-Reply-To: <Pine.LNX.4.64.1211201724560.16964@ps20323.dreamhostps.com>
References: <CAKBxTcKwBsXjZ995v=RsFGfVdMSVw_56DHw3o=sygWwp-ZvHVg@mail.gmail.com>
	<CAJE5ia89K12wopOijQ0AYR3FG3g3vjGoxKuu6YhNOVC9kxSk=w@mail.gmail.com>
	<CAKBxTc+L=HWaaForrA+B+cVro-91F9kjmWoueC_RxTbT-Dj2NQ@mail.gmail.com>
	<Pine.LNX.4.64.1211192313430.26354@ps20323.dreamhostps.com>
	<50AAEF01.4000004@mit.edu>
	<Pine.LNX.4.64.1211200618280.26354@ps20323.dreamhostps.com>
	<50AB2F2B.1080007@mit.edu>
	<Pine.LNX.4.64.1211200733470.16964@ps20323.dreamhostps.com>
	<50ABAE90.7010709@mit.edu>
	<Pine.LNX.4.64.1211201724560.16964@ps20323.dreamhostps.com>
Message-ID: <50ABD113.1010901@mit.edu>

On 11/20/12 12:46 PM, Ian Hickson wrote:
> Given the way JavaScript works, I just don't see a sane way to make a
> non-symmetric model work.

How does "JavaScript work" in your mind?  We have a good amount of 
experience making a non-symmetric model work in Gecko, for what it's worth.

> Any time you pass a string from one to the other, you're also passing a way for the
> callee to call back into the caller, for example (via the string's
> methods).

Spidermonkey effectively copies strings when passing across globals; the 
callee never gets the caller's actual string.  The methods the callee 
sees on strings are its own methods, not the callers.

> Passing any sort of structured objects similarly means passing
> mehods.

In the case of Gecko, what the caller gets in this case is a proxy for 
the actual object which enforces security invariants like "only 
properties on a whitelist are exposed" for cases when the security check 
is asymmetric.  This is handled completely on the underlying JS 
implementation level; individual callers don't have to do anything 
special to be safe this way.

> We have mechanisms for safe passing of data from one context to another,
> such as postMessage(). Doing it by having one-way glass in JS just seems
> like asking for trouble.

postMessage doesn't work unless both sides are cooperating...

> Yeah, like running getters with the ability to abort them if they don't
> return promptly.

Perhaps, yes.  ;)  I agree that debuggers have all sorts of weird going 
on, obviously!

> But your underlying point, that we can't rely on the entry script and the
> real origin, is sound. In particular, anything that's to be affected by
> document.domain has to use the calling script, not the entry script, and
> has to use the effective origin, not the real origin. It would be useful
> if someone (other than me) were to review the spec's uses of the term
> "entry script" and "origin" and verify that the checks all make sense.

I'll see what I can do about finding someone for this.  Might be a few 
weeks given holidays and whatnot, obviously.

I'll let Bobby handle the Location parts of this.  ;)

-Boris

From ian at hixie.ch  Tue Nov 20 14:51:10 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 22:51:10 +0000 (UTC)
Subject: [whatwg] Forms-related feedback
In-Reply-To: <50AB6E5F.5050803@lamouri.fr>
References: <50AB6E5F.5050803@lamouri.fr>
Message-ID: <Pine.LNX.4.64.1211201954290.26354@ps20323.dreamhostps.com>

On Fri, 7 Sep 2012, TAMURA, Kent wrote:
>
> Proposal:
> 
> I'd like to propose adding new IDL attribute to HTMLInputElement.
>    readonly attribute DOMString rawValue;
> 
> It returns text content which a user actually see in an input field.
> [...]
> * For email type, it returns a string which a user is editing.  It means it
> returns a string without Unicode -> Punycode conversion and without
> normalization of whitespace and commas.

This only makes sense if the control is a text control, which is not 
necessarily the ideal UI. For example, consider the GMail UI for typing 
e-mail addresses. What would you expose as the rawValue when the control 
contains two user chips, one word that is not yet converted to an e-mail 
address, and the user is dragging one of the chips to the end?

> * For number type, it returns user-editing string. If a user typed '123+++'
> into a number field, rawValue would be '123+++' as is.

What if the number control is a spin dial and the user has the dial 
between numbers "1" and "2"?

> * For date, datetime, datetime-local, month, time, week, the attribute 
> returns a string in a field. If a field is text-editable, it should 
> return user-editing string like email and number.  If a field has a 
> fixed localized date/time string chosen by a date/time picker, the 
> attribute should return the localized string.
> [...]
> - We can enable text field selection APIs for email, number, and other 
> types

How would this work when the control isn't a text control? I don't 
understand. For example, consider a date control that is actually three 
separate text fields (year month day); how do you envisage the selection 
API working and how would rawValue help with this?

> - JavaScript-based screen readers can read user-visible content of input 
> fields.

Screen readers don't have to be limited to the HTML APIs. I'd expect a 
screen reader to have a much more intimate API to talk to the UA.

> Strings returned by rawValue attribute may be browser-dependent and 
> locale-dependent. However it would be useful.

I think browser-dependent and locale-dependent APIs are a recipe for 
interoperability disaster.

I agree with the underlying use case of more detailed control over the 
widgets. But the way to fix that isn't to bolt on more and more 
browser-specific APIs to <input>, IMHO; the long-term fix is to implement 
a Web components model and allow the controls to be directly overridden.

On Mon, 10 Sep 2012, Kang-Hao (Kenny) Lu wrote:
> 
> For inputs that are being edited (date, datetime, datetime-local, month, 
> time, week, number), I wonder if we should instead remove restrictions 
> like this:
> 
>   # User agents must not allow the user to set the value to a non-empty
>   # string that is not a valid floating-point number.
> 
> and just let .value returns the raw input while a user is editing the 
> value and let value sanitization algorithm happen afterward.

I don't really understand the value in this. Why can't the page just get 
out of the way and let the browser and user work together?

On Tue, 11 Sep 2012, TAMURA, Kent wrote:
> 
> Yes, I'd like to enable selection API for at least type=email and 
> type=number.  All of their existing implementations are text fields. I 
> haven't seen a request to suport selection API for type=email, etc.. 
> However lack of selection API looks a defect to me.

Why does the page need to touch the selection?

On Fri, 7 Sep 2012, Mikko Rantalainen wrote:
> 2012-09-07 07:35 Europe/Helsinki: Ian Hickson:
> > On Thu, 30 Aug 2012, Jonas Sicking wrote:
> >> 
> >> I think while in theory we could rely on UAs to enable barcode entry 
> >> anywhere, which definitely would provide the maximum capabilities for 
> >> [...]
> > 
> > In this respect it's similar to the WebKit-proprietary x-webkit-speech 
> > attribute on <input>. In fact, this suggests that if other browsers 
> > are interested in supporting speech input, maybe we should standardise 
> > it as an inputmode value, e.g. inputmode="speech". Possible the 
> > inputmode="" attribute in that case could be switched to a list of 
> > tokens, so you could in fact do inputmode="latin-prose speech" or 
> > inputmode="numeric barcode" in order to provide the user agent with 
> > more flexibility in the UI.
> 
> While I agree that inputmode attribute should be made a space separated 
> list of tokens, I'd avoid stuff like "latin-prose". Expected input 
> language should be specified via lang or xml:lang attributes instead.

"Latin" here doesn't refer to the language, but to the input method (e.g. 
QWERTY or QWERTZ keyboard as opposed to hiragana mode in Japan).

> Examples of somewhat sensible inputmode values for input type=text:
> 
> - "unicode" or "text"

This isn't "sensible" since it doesn't say whether a dual-label 
latin/hiragana keyboard should be in latin mode or hiragana mode or 
whether a dual-label numeric/alphabetic phone keypad should be in numeric 
or alphabetic mode.

> - "numeric" (prefer numeric input but allow any text)

That one is fine.

> - "barcode"

Barcode is borderline (and is the topic of this subthread). I could see 
having a barcode input method, e.g. on a phone the on-screen keyboard 
could be replaced by a viewfinder. However, this seems more theoretical 
than practical.

> - "speech" or "voice" (prefer voice input)

While I could see this being an explicit input method, in practice I think 
it's more likely that authors would prefer to switch their input device 
into this mode rather than focusing the control and finding themselves 
already in this mode. But it's borderline, like barcode.

> - "word"
> - "sentence"

Word with what kind of script? Sentence with what kind of script?

> - "letters" (e.g. "letters voice" means spell by letter)
> - "ascii" (prefer real 7 bit ascii over unicode text)

I don't understand how these would be used or why they're input methods 
rather than types or patterns.

On Fri, 7 Sep 2012, Tobie Langel wrote:
> 
> There seems to be some overlap, at least in semantics, with the capture 
> attribute described in HTML Media Capture[1] and recently filed for 
> inclusion in the Living Standard HTML spec[2].
> [1]: http://dev.w3.org/2009/dap/camera/
> [2]: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17879
> 
> Anyway these two concepts can be reconciled or their distinction 
> clarified?

I must admit that I don't really see the point of the capture="" 
attribute. But in any case I don't think type="file"-specific features 
should be overloaded onto type="text"-specific features; that's just going 
to cause problems. Better to keep them separate.

On Thu, 13 Sep 2012, TAMURA, Kent wrote:
> 
> Making an input element invalid state if the input has an invalid string 
> specified by a user with browser UI. "An invalid string" means a string 
> which doesn't match to a required format defined by a type.
> 
>   e.g. If a user typed "-" to input[type=number], input.validity.valid
> would be false and form submission would be prevented.
> 
> A. In such case, make input.validity.typeMismatch true, or
> B. Introduce new IDL attribute to ValidityState.
> input.validity.invalidUserInput?
> 
> This behavior should be applied to the following types:
>   number, color, date, datetime, datettime-local, month, time, and week
> 
> Background:
>   If an input type is implemented as a text field, it is very hard for UA
> to reject invalid strings for the type. For example, "-" is not a valid
> floating-point number, but UA can't prevent users from typing "-".  So the
> field can contain invalid strings though its value IDL attribute is empty.
> If a user tries to submit the form in such situation, the field is valid
> unless the required attribute is specified.
>   WebKit clears the invalid string when the field loses focus or the form
> is submitted.  A sanitized value (empty string) is submitted.
>   Opera doesn't clear the invalid string. It silently submits a sanitized
> value (empty string).
>   IE10 has a behavior similar to WebKit.  However if a user
> type "-1abc", "-1abc" is submitted.
> 
> I don't like clearing user input.  It's not a good user experience.  Users
> don't expect their input strings are cleared by UA.
> Also, I don't like submitting empty value silently. Users expect their
> input strings are submitted.
> I think the best UI is to notify users about a field has an invalid string,
> and give a chance to correct it.  Applying the standard form validation
> mechanism must be reasonable.

Done ("badInput").

On Tue, 20 Nov 2012, Mounir Lamouri wrote:
> 
> Currently stepUp(n) and stepDown(n) are very basic methods. They more or 
> less do value += n * allowedValueStep; with n = -n; if stepDown() was 
> called. In addition of being pretty dumb, there are a lot of reasons why 
> they can throw.
> 
> At Mozilla, we think that the main use case for stepUp() and stepDown() 
> is to create a UI with spin buttons: clicking on the up arrow would call 
> stepUp() and clicking on the down arrow would call stepDown(). Such a 
> use case needs methods that do better than just adding n * 
> allowedValueStep. In addition, we think that throwing is very often a 
> bad idea and that should happen when the developer clearly did something 
> wrong.
> 
> So, we would like to change the stepUp()/stepDown() algorithm to match
> the following behaviour:
> - we only throw if the input type doesn't allow those methods or if
> there is no allowed value step;
> - if the value isn't a number (aka empty string), we should just exit
> the steps;
> - if the value is below the minimal allowed value and n is negative, we
> should exit the steps;
> - if the value is above the maximal allowed value and n is positive, we
> should exit the steps;
> - if the element is suffering from a step mismatch, and n is negative,
> the value should be changed to the next valid value. Otherwise, it
> should be changed to the previous allowed value;
> - newValue = value + n * allodValueStep;
> - if the newValue is below the minimal allowed value, the newValue
> should be equal the minimal allowed value;
> - if the newValue is higher than the minimal allowed value, the newValue
> should be equal the minimal allowed value.
> 
> Such a behaviour creates a real added value in stepUp() and stepDown() 
> that make those methods useful compared to simply do value += n * 
> allowedValueStep; and prevent throwing when there is no need to.

Done, though I described it in a different way. (I hope it's equivalent.)

> [1] The only difference between Chrome's spin buttons behaviour and our 
> proposal is that when value is the empty string, it is setting value to 
> 0 and continue to the next steps (unless the 0 is below the minimal 
> allowed value and n < 0, in that case value=min). It might be 
> interesting to specify something better than "do nothing" if value="".

I'm open to doing that too; what would you preference be?

From ian at hixie.ch  Tue Nov 20 14:55:52 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 22:55:52 +0000 (UTC)
Subject: [whatwg] Make stepUp() and stepDown() more developer-friendly
In-Reply-To: <CAO8i3icCK=WYhMe=ToaRw7VWerBi5CmuYidFfoi9nNOaMXAnkA@mail.gmail.com>
References: <50AB6E5F.5050803@lamouri.fr>
	<CAO8i3icCK=WYhMe=ToaRw7VWerBi5CmuYidFfoi9nNOaMXAnkA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211202253300.16964@ps20323.dreamhostps.com>

On Tue, 20 Nov 2012, Scott Gonz?lez wrote:
>
> Can you explain why these methods should be no-ops if the value is above 
> the max or below the min? In jQuery UI, we decided that using these 
> methods should always result in a valid value.

I actually missed that in Mounir's suggestion, and the spec now rounds to 
the nearest allowed value in that case, rather than doing nothing.

Mounir: is that ok?

> I can list out the steps we take for all conditions, but I'd like to 
> hear everyone's thoughts on the various cases where you're suggesting 
> that the methods do nothing.

Mostly I agree with Mounir here, but I'm curious about what you think 
should happen for the case where there's no value, and the case where the 
control isn't a numeric/date/time type. I could see an argument for 
stepping from the default in the former case (Mounir, what do you think 
about doing that?) but for the latter case I don't really see any point 
doing anything but throw an exception, as Mounir suggested.

From ian at hixie.ch  Tue Nov 20 15:30:50 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 20 Nov 2012 23:30:50 +0000 (UTC)
Subject: [whatwg] Feedback on Web Worker specification
In-Reply-To: <CAArhhitgJawaJVu9BNF4940Tst3Vuco64VhhLw5q=XgyqgbXZw@mail.gmail.com>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>
	<BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>
	<CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>
	<BLU002-W147F9FEEEA6218FC696F05FAA6B0@phx.gbl>
	<CAArhhitgJawaJVu9BNF4940Tst3Vuco64VhhLw5q=XgyqgbXZw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211202302220.26354@ps20323.dreamhostps.com>

On Wed, 22 Aug 2012, Jeffrey Pfau wrote:
> 
> While working on enhancing WebKit's privacy infrastructure, I noticed 
> that shared workers don't have a UA security policy escape clause like 
> localStorage and other APIs. The process to create a shared worker does 
> not allow UAs to abort creation with a SecurityError if it decides that 
> a document, origin, or script violates the UA's security policy.

Fixed.

On Sat, 3 Nov 2012, Fred Andrews wrote:
> 
> Feedback and suggestions for appropriate markup to declare web workers 
> would be appreciated.

Workers are only usable from script, so just start them in script. No need 
for anything declarative.

> The use case is a document with JS disabled or restricted so that it can 
> not create web workers, yet still wants to create web workers to process 
> page input and to update the document.

If it's been restricted to not run JS, then starting a worker is 
pointless, since workers only run JS.

If it's been restricted from starting Web workers, then it doesn't matter 
how the mechanism to start workers is presented, the page still won't be 
able to start a worker. It'd be pointless to have a mechanism to block 
workers that could just be circumvented.

> The use case is a document with JS disabled or restricted so that it can 
> not use JS to receive a message and update the DOM, yet still wants to 
> support AJAX style designs.

Why would the user disable JavaScript if they wanted the page to act like 
JavaScript was enabled?

> For example the document JS may be disabled but a declarative mechanism 
> may be defined to enable web workers to be create and these need to be 
> able to post changes to the document.

The whole point of disabling JS is presumably to prevent this, so 
allowing it would defeat the point, as far as I can tell.

> A mechanism specific to the need may be better for security.  For 
> example, being able to bind a HTML <div> element to a specific web 
> worker.  A general mechanism that allows a message to update any element 
> by ID may be less desirable for security.

I don't understand. What attack scenario are you envisaging?

> Would it be appropriate to add a new attribute to HTML elements that 
> allows their inner HTML to be replaced from a received message?

If JS is enabled, you can replace any element's contents at will.

If JS is disabled, presumably it's because the author doesn't want the 
page to be manipulated in this way. I don't see why they'd like a feature 
that circuments JS being disabled.

> For example, a form in a parent document with document JS disabled that 
> still wants to be able to post a submitted form to a web worker for 
> processing, or posting a message when a button is clicked.

If JS is disabled, the worker isn't going to be able to do anything, since 
it's just JS. So posting messages to the worker, or even starting a 
worker, doesn't seem useful. It could't do anything.

On Sat, 3 Nov 2012, Fred Andrews wrote:
> 
> The use case really is to be able to use web workers rather than the 
> document JS. An extension to disable or restrict the document JS will 
> also be added.  The design is intended to limit a large range of 
> security issues.

Could you elaborate on these security issues?

On Mon, 5 Nov 2012, Fred Andrews wrote:
> 
> The use I have in mind is a work-in-progress, see: 
> http://www.w3.org/community/pua/wiki/Draft#Examples

Limiting JS to workers, or indeed disabling JS entirely, doesn't help you 
at all as far as I can tell. It's trivial to fingerprint a user by 
collecting things like the user's IP address, the TCP/IP stack's 
characteristics, the browser's characteristics, the hardware's 
capabilities, etc. And it doesn't matter. When your government is a 
threat, they can just put you under surveillance, and your browser is the 
least of your problems. Advertisers aren't a threat; the worst they can do 
is provide you with ads that are more applicable to your interests; they 
couldn't care less about your personal details, they only care about broad 
demographic trends. Commercial providers like credit card companies, 
ecommerce retailers, utilities, ISPs, phone companies, and the like, 
already have your financial information, personal purchasing habits, 
personal address, geographical position history, and other private 
information, which they are willingly given in exchange for services. 
Stalkers aren't going to be using fingerprinting or data in shared workers 
to stalk you, they'll go through your friends or place of work.

In short, I think the entire approach here (and indeed the concern over 
shared workers in general mentioned at the top of this e-mail) to be 
rather misguided.

On Tue, 6 Nov 2012, Fred Andrews wrote:
> 
> Some concerns (lack of understanding) I have with the Web Worker spec. at:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html
> 
> "9.2.3 The worker's lifetime
> ... Otherwise, o is a Window object, and the relevant Document is just 
> the Document that is the active document of the Window object o."
> 
> Does this mean that the Document object of the caller is made available 
> to be web worker?  I can't see an interface to it?

No, this is just talking about the lifetime, not the API.

> "9.2.4 Processing model
> ...
> 5. A new script is now created, as follows.
> ...
> Set the script's browsing context to owner browsing context.
> ...
> Set the script's document to owner document."
> 
> There does not appear to be an API to actually effect the owner browsing 
> context or document?

Yeah, off-hand I can't actually think of anything that is available in a 
worker that uses the script's browsing context or document.

> Is this just laying a foundation for future work?

All scripts have a browsing context and document. They're used for all 
kinds of things in browsing contexts (e.g. knowing which tab to block 
when you call alert()).

> Are web workers expected to someday be able to cause navigation of the 
> creators browsing context etc?

Workers will never have shared state.

> "9.3 APIs available to workers
> ...
> The DOM APIs (Node objects, Document objects, etc) are not available to 
> workers in this version of this specification."
> 
> Are there plans to allow web workers access to the DOM of their creator?

No plans, only hopes.

> Does this apply to documents created by the web worker, such as via XHR?

Yes.

> Looking at the source code for some implementations will help clarify 
> the current state, but it would also be of interest to know of planned 
> web workers extensions?

Very little is planned, per se, before it happens. :-)

From ian at hixie.ch  Tue Nov 20 17:17:10 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 21 Nov 2012 01:17:10 +0000 (UTC)
Subject: [whatwg] Autocomplete and autofill features and feedback thereon
In-Reply-To: <CAPJYB1go+r_FCXknEJ_9MM7wVtvXj9ezygZD8A0rciVCqrw=wA@mail.gmail.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<CAPJYB1go+r_FCXknEJ_9MM7wVtvXj9ezygZD8A0rciVCqrw=wA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211202332400.26354@ps20323.dreamhostps.com>

On Tue, 16 Oct 2012, Ilya Sherman wrote:
> On Thu, Aug 2, 2012 at 11:42 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Mon, 23 Jul 2012, Ian Hickson wrote:
> > >
> > > So we could define the autocomplete="" field's value as follows: 
> > > [...]
> >
> > I've now specced this, with some minor changes.
> 
> My only high-level question is: Why did you choose to drop the proposed 
> aliases like "city" for "locality" and "province" for "region"?

The short answer is that I wanted to avoid redundant terms because aliases 
tend to cause all kinds of issues (people set both because they don't know 
which to use, or they set both thinking they're separate and they end up 
conflicting, or they start long threads on mailing lists asking which one 
is the most appropriate one...).

I did do quite some research to figure out which term to use. In the end, 
mostly on Tantek's encouragement, I ended up picking the terms that are 
the most inclusive and happen to be the terms used by vocabularies such as 
those based on vCard, like hCard/adr.

> While "locality" and "region" are probably the most technically correct 
> terms -- they're certainly the best that I found while researching -- 
> they're not terms that I'd expect most web developers to be familiar 
> with.

That's true, certainly, but I think consistency with things like hCard 
will somewhat mitigate that problem.

> I think including the proposed aliases allows for a more "natural" way 
> to express many site's forms; and I think that more natural/readable 
> source HTML code is a Good Thing???.

I understand the attraction of having redundant terms, but the cost is 
pretty high (as described in the parenthetical above). I'm not sure it's 
worth it.

For "provice" and "region", I think they're a wash. In the US, "state" is 
the familiar term; in the UK, "county", in Switzerland, "canton"... each 
place has their own, I don't think it really matters what term we use, 
but supporting all of them would be highly confusing.

As for "city", one problem specific to this value is that it encourages 
authors to forget that many of their users aren't in cities at all. I wish 
there was a better term than "locality", though, I agree.

> Otherwise, a bunch of minor typos and the like, all related to the parsing
> algorithm and subsequent sections:
> * In step 13.3, "hint set" should be "hint tokens".
> * It seems like step 13.6 should precede step 13.5.
> * In step 14.3, "hint set" should be "hint tokens".
> * In step 14.3, "contact" should be "mode".
> * It seems like step 14.6 should precede step 14.5.
> * In the paragraph beginning with "Suppose a user agent knows of two phone
> numbers", there is a typo: "pefilled" -> "prefilled".

Fixed.

> * In step 14.4, I think "either is" is more natural than "either be".

Fixed to "will either be", which was the intent (I deleted too many words 
when copy/pasting the previous block).

> * Step 18 is the last mention of the "scope tokens" data in the parsing
> algorithm, as well as in the subsequent commentary.  What is the intended
> function of the scope tokens -- should they be combined with the hint set,
> or is there a separate notion of scope that should be invoked by the UA
> when parsing this attribute?

Wow, I totally dropped the scope thing on the floor. Oops. Fixed.

> * For terms like "autofill hint set", should the spec use "autocomplete" 
> rather than "autofill", or is there an intentional distinction being 
> made here?

"Autocomplete" is the feature wherein the user types half of some piece of 
data and the user agent provides the rest. "Autofill" is the feature 
wherein the user selects from previously-provided data and the user agent 
provides all the data based on that selection.

The fact that the HTML spec uses the "autocomplete" attribute to control 
the autofill feature is a historical accident. It's similar to how the 
feature for providing alternative style sheets is rel="alternate", even 
though the word "alternate" is a non-sequitur in this context.

> > > So instead of <input type=tel autocomplete="work tel"> you would 
> > > just say <input type=tel autocomplete=work> (and would not be able 
> > > to say <input type=text autocomplete="work tel">, which would be an 
> > > inferior user experience when tel is given special behavior, or 
> > > <input type=email autocomplete="work tel">, which would be 
> > > inconsistent).
> >
> > I'm a little wary about adding more magic here, these attributes are 
> > already pretty complicated. See the autocomplete section's algorithms 
> > and let me know if you still think we should do something along those 
> > lines. If it's something people are willing to implement, I wouldn't 
> > want to stand in the way; I agree that it has some good side-effects 
> > (like making it impossible to have certain combinations).
> >
> > I could also introduce some conformance requirements to make the bogus 
> > combinations non-conforming; currently I haven't made type=tel 
> > autocomplete=email non-conforming for instance.
> 
> Since the autocomplete type hints are just hints, I think it's ok to 
> leave this behavior undefined

Ok. Currently the spec says that autocomplete="work" should be treated the 
same as autocomplete="on", which is basically "do magic" (i.e. undefined, 
as you say).

> but I also don't see any problem with making such mismatches 
> non-conforming, other than that makes the spec even longer/more verbose.

That's not a completely trivial problem. :-)

> > I haven't added this [government ID numbers].
> >
> > I also haven't added:
> >  - payment instrument type
> >  - payment instrument start date
> >  - payment instrument issue number (for Maestro)
> >
> > I also haven't removed, as some people suggested, the three cc-name 
> > subfields.
> >
> > I'm open to making all these changes, but figured I would get some 
> > more input on them first, in particular from Ilya who did the research 
> > to come up with the original set of fields.
> 
> I have seen a relatively high number of Chrome bug reports requesting 
> better handling of (e.g. government) ID numbers.  One example: [ 
> http://code.google.com/p/chromium/issues/detail?id=64433 ].

The better handling requested there is just for Chrome to not do any 
special handling. So no need to add anything to the spec for that.

> I think it would be helpful to add these to the spec; though as 
> subsequent posters have noted, there's a lot of potential complexity in 
> how these should be represented.  This might fall under the broader 
> class of "identity"-related fields, which I think merit their own 
> carefully thought out set of tokens. There was some work done on the 
> beginnings of such a specification -- see 
> https://wiki.mozilla.org/Identity-inputs -- but my current understanding 
> is that this is an area in need of further development.

I'm happy to add more things like this to the spec, but I don't know what 
to add exactly. If there is a concrete description of what fields I should 
add here, I'd be happy to do so.

> The payment instrument type is almost certainly appropriate to add -- it 
> is included on almost every website that I've encountered that includes 
> payment card fields.  It was an oversight on my part to omit it from the 
> initial proposal.

It's redundant data, the credit card number itself says what type it is.

More importantly, I don't know how to store the information. What values 
should we be expecting here? If a site has radio buttons "v", "m" and "a", 
and another has a <select> with "4", "5", and "3", and yet another has 
three buttons which set a type=hidden with the values "visa", "mastercard" 
and "amex", how is the user agent to figure out what's going on? This 
makes the magic needed around dates look positively easy.

> The other two payment instrument field types I haven't encountered on the
> Web, as far as I can recall.  So, based on my data set accumulated while
> working on Chrome Autofill, I'm ok with leaving these out of the spec for
> now.  However, my experience is biased toward US websites; it's possible
> that these fields are more prominent internationally.

I did some more research and it seems start date and issue number are 
specific to the old Switch and Solo cards (for a while branded Maestro, 
though they weren't technically Maestro cards as the rest of the world 
knows them). These seem to be obsolete now.

> The three cc-name subfields are split out surprisingly often on existing 
> websites.  I was initially opposed to including these in the spec; but 
> that data in support of them was overwhelming.

I've left these.

> Finally, I have gotten a request to include a field type for bank 
> account numbers, though I have only seen this info actually requested on 
> a small handful of extremely prominent (and generally trusted) websites: 
> Amazon, PayPal, and I think Google Wallet.

Is there any reason we shouldn't just treat bank accounts like just 
another credit card, and use cc-number for these?

On 26 Oct 2012, Elliott Sprehn wrote:
> 
> Several of us on the Chrome team have been thinking about the challenges 
> of filling out long forms full of personal information. We've noticed 
> that site authors split up their forms across multiple pages to avoid 
> overwhelming their users with one single massive form [1]. This is 
> particularly bad on mobile where we've observed some popular retailers 
> splitting their forms into six or more pages in an attempt to optimize 
> their flow for a small screen. This unfortunately defeats many of the 
> advantages of existing browser autocomplete.
> 
> In researching this we?ve found that with a few changes built on the 
> existing HTML autocomplete spec [2] we can allow authors to recombine 
> their forms and enable browsers to provide more useful autocomplete.
> 
> 1) HTMLFormElement.prototype.requestAutocomplete()
> Asks the user agent to asynchronously present a UI for performing full
> <form> autocomplete using the already spec?ed autocomplete attributes
> [2] used in the form. In concept this is very similar to prompt()
> except the UA could provide a streamlined experience for filling in
> information in large chunks. For example you could imagine choosing a
> shipping address from a drop down instead of presenting multiple
> inputs.
>
> 2) Simple event named ?autocomplete?
> This event is dispatched on the form element after the UI presented by
> requestAutocomplete() is closed if the form validates after having
> filled each input and firing all necessary input events like ?change?.
> 
> 3) Simple event named ?autocompletecancel?
> This event is dispatched on the form if the UI is canceled.

This seems reasonable. I recommend implementing it (without a prefix); if, 
based on your implementation experience, other browser vendors want to 
implement it, we would then add it to the spec.

Getting positive indications from a second browser vendor that they want 
to implement this would be the next step towards getting this in the spec.

On Fri, 26 Oct 2012, Anne van Kesteren wrote:
> 
> I'm missing the scenario that requires such interference from a web 
> developer. Can't a UA just offer to autocomplete a form for me once it 
> finds one? (Or in other words, unless I'm missing something this seems 
> like a solution without a provided use case.)

One-page apps don't have a relevant onload for the UA to use. In 
high-latency environments you _really_ want to minimise page loads.

On Wed, 31 Oct 2012, Dan Beam wrote:
> 
> The experimental implementation [1] has been updated to dispatch an 
> "autocompleteerror" as per convention/your feedback.

"autocompleteerror" seems like it'd be fired for an error, not user 
cancelation. User cancelation is usually called either "abort" or 
"cancel". I think autocompletecancel is fine. It's consistent with 
oncancel, which we used for <dialog>. (Fullscreen's "error" event is for a 
slightly different case, based on what the spec says.)

On Sat, 10 Nov 2012, Maciej Stachowiak wrote:
> 
> (1) If this API fills in a form completely based on stored data, and not 
> by completing the user's typing, then it is "autofill" rather than 
> "autocomplete".

Indeed, but the terminology in the API should probably remain consistent 
with the existing attributes.

> (2) If this API provides the ability to get user information without 
> even having a visible form, then it's not clear that it is even really 
> autofill. It's just "requestUserInformation()" or something.

It's intended to fill a form; whether the form is visible or not is 
somewhat academic, the author (who sees the API) still sees the form.

> (3) This API has important privacy and even security considerations. You 
> have to tell the user exactly what you are going to fill in to the site 
> before they approve. Unfortunately, most won't read it. If sites are 
> asking for so much info that they have to split pages for usability, 
> then it seems likely the UI that tells the user what the site is asking 
> for will be impractical for most users to meaningfully review. This 
> becomes especially dangerous if the mechanism can fill in credit card 
> info. I would be very nervous if the browser could at any moment pop up 
> a dialog that would submit all my credit card info to a dubious site if 
> I slip and click the wrong button.

Certainly the UI needs to be made clear, but at some point, we have to 
either let the device submit the credit card information, or have the user 
type it manually. I can tell you from personal experience that I'd rather 
never have to do the latter.

> (4) Should this API be limited to initiation during a user interaction? 
> That would reduce the ability of sites to spam the user with such forms.

That seems reasonable.

From ian at hixie.ch  Tue Nov 20 17:47:10 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 21 Nov 2012 01:47:10 +0000 (UTC)
Subject: [whatwg] Declarative unload data
In-Reply-To: <CAAWBYDAYuHdZCk7BbJ8EtRbKOTk9J44uQyq817g12wVQ8a4Kjw@mail.gmail.com>
References: <39274AD4-E17E-4506-A927-0D590082D721@netflix.com>
	<CAAWBYDAYuHdZCk7BbJ8EtRbKOTk9J44uQyq817g12wVQ8a4Kjw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211210124430.26354@ps20323.dreamhostps.com>

On Mon, 7 May 2012, Tab Atkins Jr. wrote:
>
> Besides those annoying "Are you sure you want to leave this page?" 
> dialogs, the primary use of the unload events is a final, desperate 
> attempt to throw a message at the server, either to save some data or 
> release some server-held resource.

Do you have any examples of these I could study?

How do they handle the user just closing his laptop and walking away, or 
being on the phone and switching to a non-browser app, or entering a 
tunnel and losing signal, or the browser crashing, or the user forgetting 
to pay his bills and getting cut off by the ISP, or the user leaving the 
tab open for five weeks before coming back to it, or the user's house 
catching fire and the computer melting, or the user opening up multiple 
copies of the tab with the same Web app and then closing the first one, 
or if the user closes the tab by mistake and then reopens it?

> However, this is tricky to do reliably, because browsers kill pending 
> XHRs as they unload the page. Right now, I think the most reliable 
> method is to create an <img> and set its @src, because of an old quirk 
> in IE that other browsers have copied which means that pending image 
> loads are carried to completion rather than being killed.

(Incidentally, this isn't specced currently; if anyone has any test cases 
demonstrating this, please do file a bug so I can spec it.)

> Can we fix this?

It's not entirely clear to me that it's a problem. :-)

If the app just wants to save user data, the app can just show an 
indicator of what data has been saved, or when data was last saved, or 
whether there is unsaved data, with an explicit "save now" control when 
there is unsaved data, and then save everything else asynchronously as it 
is modified. This is then resilient to the events described above.

If the app has server-side resources, then it's probably best to just keep 
them around on a timeout, bringing them back if the page returns from the 
dead, so that long-lived tabs don't waste resources, so that suddenly 
suspended tabs don't waste resources, and so that tabs that are closed and 
then resumed don't need to waste time getting the resources back.

(Having said that, another way to do this is just to hold a TCP connection 
open (e.g. using WebSocket or an <iframe>), and then doing the cleanup on 
the server side when the connection dies.)

> var foo = new unloadHandler('http://example.com/ajax');
> foo.data = "bar"
> /* Now, if the page ever gets unloaded, you're guaranteed that
> "http://example.com/ajax" will eventually get a request with the value
> "bar". */
> 
> Presumably you'd be able to set other relevant XHR properties, like 
> un/pw and get/post and such, on the unloadhandler object.

This seems like a very close relation to XMLHttpRequest. My suggestion 
would be that if we want to implement this, we implement it as a feature 
of XHR, e.g.:

var foo = new XMLHttpRequest({ autoSendOnUnload: true });
   foo.open('GET', 'http://example.com/ajax');
   foo.addData('bar');

...or some such.

So I'm punting this over to Anne.

But before we spec this, I think we should make sure that there's browser 
vendors who want to implement it. The thread (which I haven't quoted here) 
raised a number of serious concerns about whether it would be a good idea.

From dbeam at chromium.org  Tue Nov 20 17:51:08 2012
From: dbeam at chromium.org (Dan Beam)
Date: Tue, 20 Nov 2012 17:51:08 -0800
Subject: [whatwg] Autocomplete and autofill features and feedback thereon
In-Reply-To: <Pine.LNX.4.64.1211202332400.26354@ps20323.dreamhostps.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<CAPJYB1go+r_FCXknEJ_9MM7wVtvXj9ezygZD8A0rciVCqrw=wA@mail.gmail.com>
	<Pine.LNX.4.64.1211202332400.26354@ps20323.dreamhostps.com>
Message-ID: <CANpe7K3K7o-ktyp+1CY8=_UAEKRE0wuMHExJBoxrTVWAKfdqmQ@mail.gmail.com>

On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Tue, 16 Oct 2012, Ilya Sherman wrote:
>> On Thu, Aug 2, 2012 at 11:42 AM, Ian Hickson <ian at hixie.ch> wrote:
>> > On Mon, 23 Jul 2012, Ian Hickson wrote:
>> > >
>> > > So we could define the autocomplete="" field's value as follows:
>> > > [...]
>> >
>> > I've now specced this, with some minor changes.
>>
>> My only high-level question is: Why did you choose to drop the proposed
>> aliases like "city" for "locality" and "province" for "region"?
>
> The short answer is that I wanted to avoid redundant terms because aliases
> tend to cause all kinds of issues (people set both because they don't know
> which to use, or they set both thinking they're separate and they end up
> conflicting, or they start long threads on mailing lists asking which one
> is the most appropriate one...).
>
> I did do quite some research to figure out which term to use. In the end,
> mostly on Tantek's encouragement, I ended up picking the terms that are
> the most inclusive and happen to be the terms used by vocabularies such as
> those based on vCard, like hCard/adr.
>
>
>> While "locality" and "region" are probably the most technically correct
>> terms -- they're certainly the best that I found while researching --
>> they're not terms that I'd expect most web developers to be familiar
>> with.
>
> That's true, certainly, but I think consistency with things like hCard
> will somewhat mitigate that problem.
>
>
>> I think including the proposed aliases allows for a more "natural" way
>> to express many site's forms; and I think that more natural/readable
>> source HTML code is a Good Thing?.
>
> I understand the attraction of having redundant terms, but the cost is
> pretty high (as described in the parenthetical above). I'm not sure it's
> worth it.
>
> For "provice" and "region", I think they're a wash. In the US, "state" is
> the familiar term; in the UK, "county", in Switzerland, "canton"... each
> place has their own, I don't think it really matters what term we use,
> but supporting all of them would be highly confusing.
>
> As for "city", one problem specific to this value is that it encourages
> authors to forget that many of their users aren't in cities at all. I wish
> there was a better term than "locality", though, I agree.
>
>
>> Otherwise, a bunch of minor typos and the like, all related to the parsing
>> algorithm and subsequent sections:
>> * In step 13.3, "hint set" should be "hint tokens".
>> * It seems like step 13.6 should precede step 13.5.
>> * In step 14.3, "hint set" should be "hint tokens".
>> * In step 14.3, "contact" should be "mode".
>> * It seems like step 14.6 should precede step 14.5.
>> * In the paragraph beginning with "Suppose a user agent knows of two phone
>> numbers", there is a typo: "pefilled" -> "prefilled".
>
> Fixed.
>
>
>> * In step 14.4, I think "either is" is more natural than "either be".
>
> Fixed to "will either be", which was the intent (I deleted too many words
> when copy/pasting the previous block).
>
>
>> * Step 18 is the last mention of the "scope tokens" data in the parsing
>> algorithm, as well as in the subsequent commentary.  What is the intended
>> function of the scope tokens -- should they be combined with the hint set,
>> or is there a separate notion of scope that should be invoked by the UA
>> when parsing this attribute?
>
> Wow, I totally dropped the scope thing on the floor. Oops. Fixed.
>
>
>> * For terms like "autofill hint set", should the spec use "autocomplete"
>> rather than "autofill", or is there an intentional distinction being
>> made here?
>
> "Autocomplete" is the feature wherein the user types half of some piece of
> data and the user agent provides the rest. "Autofill" is the feature
> wherein the user selects from previously-provided data and the user agent
> provides all the data based on that selection.
>
> The fact that the HTML spec uses the "autocomplete" attribute to control
> the autofill feature is a historical accident. It's similar to how the
> feature for providing alternative style sheets is rel="alternate", even
> though the word "alternate" is a non-sequitur in this context.
>
>
>> > > So instead of <input type=tel autocomplete="work tel"> you would
>> > > just say <input type=tel autocomplete=work> (and would not be able
>> > > to say <input type=text autocomplete="work tel">, which would be an
>> > > inferior user experience when tel is given special behavior, or
>> > > <input type=email autocomplete="work tel">, which would be
>> > > inconsistent).
>> >
>> > I'm a little wary about adding more magic here, these attributes are
>> > already pretty complicated. See the autocomplete section's algorithms
>> > and let me know if you still think we should do something along those
>> > lines. If it's something people are willing to implement, I wouldn't
>> > want to stand in the way; I agree that it has some good side-effects
>> > (like making it impossible to have certain combinations).
>> >
>> > I could also introduce some conformance requirements to make the bogus
>> > combinations non-conforming; currently I haven't made type=tel
>> > autocomplete=email non-conforming for instance.
>>
>> Since the autocomplete type hints are just hints, I think it's ok to
>> leave this behavior undefined
>
> Ok. Currently the spec says that autocomplete="work" should be treated the
> same as autocomplete="on", which is basically "do magic" (i.e. undefined,
> as you say).
>
>
>> but I also don't see any problem with making such mismatches
>> non-conforming, other than that makes the spec even longer/more verbose.
>
> That's not a completely trivial problem. :-)
>
>
>> > I haven't added this [government ID numbers].
>> >
>> > I also haven't added:
>> >  - payment instrument type
>> >  - payment instrument start date
>> >  - payment instrument issue number (for Maestro)
>> >
>> > I also haven't removed, as some people suggested, the three cc-name
>> > subfields.
>> >
>> > I'm open to making all these changes, but figured I would get some
>> > more input on them first, in particular from Ilya who did the research
>> > to come up with the original set of fields.
>>
>> I have seen a relatively high number of Chrome bug reports requesting
>> better handling of (e.g. government) ID numbers.  One example: [
>> http://code.google.com/p/chromium/issues/detail?id=64433 ].
>
> The better handling requested there is just for Chrome to not do any
> special handling. So no need to add anything to the spec for that.
>
>
>> I think it would be helpful to add these to the spec; though as
>> subsequent posters have noted, there's a lot of potential complexity in
>> how these should be represented.  This might fall under the broader
>> class of "identity"-related fields, which I think merit their own
>> carefully thought out set of tokens. There was some work done on the
>> beginnings of such a specification -- see
>> https://wiki.mozilla.org/Identity-inputs -- but my current understanding
>> is that this is an area in need of further development.
>
> I'm happy to add more things like this to the spec, but I don't know what
> to add exactly. If there is a concrete description of what fields I should
> add here, I'd be happy to do so.
>
>
>> The payment instrument type is almost certainly appropriate to add -- it
>> is included on almost every website that I've encountered that includes
>> payment card fields.  It was an oversight on my part to omit it from the
>> initial proposal.
>
> It's redundant data, the credit card number itself says what type it is.
>
> More importantly, I don't know how to store the information. What values
> should we be expecting here? If a site has radio buttons "v", "m" and "a",
> and another has a <select> with "4", "5", and "3", and yet another has
> three buttons which set a type=hidden with the values "visa", "mastercard"
> and "amex", how is the user agent to figure out what's going on? This
> makes the magic needed around dates look positively easy.
>
>
>> The other two payment instrument field types I haven't encountered on the
>> Web, as far as I can recall.  So, based on my data set accumulated while
>> working on Chrome Autofill, I'm ok with leaving these out of the spec for
>> now.  However, my experience is biased toward US websites; it's possible
>> that these fields are more prominent internationally.
>
> I did some more research and it seems start date and issue number are
> specific to the old Switch and Solo cards (for a while branded Maestro,
> though they weren't technically Maestro cards as the rest of the world
> knows them). These seem to be obsolete now.
>
>
>> The three cc-name subfields are split out surprisingly often on existing
>> websites.  I was initially opposed to including these in the spec; but
>> that data in support of them was overwhelming.
>
> I've left these.
>
>
>> Finally, I have gotten a request to include a field type for bank
>> account numbers, though I have only seen this info actually requested on
>> a small handful of extremely prominent (and generally trusted) websites:
>> Amazon, PayPal, and I think Google Wallet.
>
> Is there any reason we shouldn't just treat bank accounts like just
> another credit card, and use cc-number for these?
>
>
> On 26 Oct 2012, Elliott Sprehn wrote:
>>
>> Several of us on the Chrome team have been thinking about the challenges
>> of filling out long forms full of personal information. We've noticed
>> that site authors split up their forms across multiple pages to avoid
>> overwhelming their users with one single massive form [1]. This is
>> particularly bad on mobile where we've observed some popular retailers
>> splitting their forms into six or more pages in an attempt to optimize
>> their flow for a small screen. This unfortunately defeats many of the
>> advantages of existing browser autocomplete.
>>
>> In researching this we?ve found that with a few changes built on the
>> existing HTML autocomplete spec [2] we can allow authors to recombine
>> their forms and enable browsers to provide more useful autocomplete.
>>
>> 1) HTMLFormElement.prototype.requestAutocomplete()
>> Asks the user agent to asynchronously present a UI for performing full
>> <form> autocomplete using the already spec?ed autocomplete attributes
>> [2] used in the form. In concept this is very similar to prompt()
>> except the UA could provide a streamlined experience for filling in
>> information in large chunks. For example you could imagine choosing a
>> shipping address from a drop down instead of presenting multiple
>> inputs.
>>
>> 2) Simple event named ?autocomplete?
>> This event is dispatched on the form element after the UI presented by
>> requestAutocomplete() is closed if the form validates after having
>> filled each input and firing all necessary input events like ?change?.
>>
>> 3) Simple event named ?autocompletecancel?
>> This event is dispatched on the form if the UI is canceled.
>
> This seems reasonable. I recommend implementing it (without a prefix); if,
> based on your implementation experience, other browser vendors want to
> implement it, we would then add it to the spec.

Right now this functionality is implemented unprefixed in
WebKit/Chrome behind various compile/runtime flags.

>
> Getting positive indications from a second browser vendor that they want
> to implement this would be the next step towards getting this in the spec.
>
>
> On Fri, 26 Oct 2012, Anne van Kesteren wrote:
>>
>> I'm missing the scenario that requires such interference from a web
>> developer. Can't a UA just offer to autocomplete a form for me once it
>> finds one? (Or in other words, unless I'm missing something this seems
>> like a solution without a provided use case.)
>
> One-page apps don't have a relevant onload for the UA to use. In
> high-latency environments you _really_ want to minimise page loads.
>
>
> On Wed, 31 Oct 2012, Dan Beam wrote:
>>
>> The experimental implementation [1] has been updated to dispatch an
>> "autocompleteerror" as per convention/your feedback.
>
> "autocompleteerror" seems like it'd be fired for an error, not user
> cancelation. User cancelation is usually called either "abort" or
> "cancel". I think autocompletecancel is fine. It's consistent with
> oncancel, which we used for <dialog>. (Fullscreen's "error" event is for a
> slightly different case, based on what the spec says.)
>
>
> On Sat, 10 Nov 2012, Maciej Stachowiak wrote:
>>
>> (1) If this API fills in a form completely based on stored data, and not
>> by completing the user's typing, then it is "autofill" rather than
>> "autocomplete".
>
> Indeed, but the terminology in the API should probably remain consistent
> with the existing attributes.
>
>
>> (2) If this API provides the ability to get user information without
>> even having a visible form, then it's not clear that it is even really
>> autofill. It's just "requestUserInformation()" or something.
>
> It's intended to fill a form; whether the form is visible or not is
> somewhat academic, the author (who sees the API) still sees the form.
>
>
>> (3) This API has important privacy and even security considerations. You
>> have to tell the user exactly what you are going to fill in to the site
>> before they approve. Unfortunately, most won't read it. If sites are
>> asking for so much info that they have to split pages for usability,
>> then it seems likely the UI that tells the user what the site is asking
>> for will be impractical for most users to meaningfully review. This
>> becomes especially dangerous if the mechanism can fill in credit card
>> info. I would be very nervous if the browser could at any moment pop up
>> a dialog that would submit all my credit card info to a dubious site if
>> I slip and click the wrong button.
>
> Certainly the UI needs to be made clear, but at some point, we have to
> either let the device submit the credit card information, or have the user
> type it manually. I can tell you from personal experience that I'd rather
> never have to do the latter.
>
>
>> (4) Should this API be limited to initiation during a user interaction?
>> That would reduce the ability of sites to spam the user with such forms.
>
> That seems reasonable.

This has been filed here, btw -
https://bugs.webkit.org/show_bug.cgi?id=102320 - and will be done
soon.

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

From jackalmage at gmail.com  Tue Nov 20 18:05:29 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 20 Nov 2012 18:05:29 -0800
Subject: [whatwg] Declarative unload data
In-Reply-To: <Pine.LNX.4.64.1211210124430.26354@ps20323.dreamhostps.com>
References: <39274AD4-E17E-4506-A927-0D590082D721@netflix.com>
	<CAAWBYDAYuHdZCk7BbJ8EtRbKOTk9J44uQyq817g12wVQ8a4Kjw@mail.gmail.com>
	<Pine.LNX.4.64.1211210124430.26354@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDB_ZFwanW=w3JXMvL6y2vAe6R9Sg9Zdyv25SW1shdZ1CA@mail.gmail.com>

On Tue, Nov 20, 2012 at 5:47 PM, Ian Hickson <ian at hixie.ch> wrote:
> But before we spec this, I think we should make sure that there's browser
> vendors who want to implement it. The thread (which I haven't quoted here)
> raised a number of serious concerns about whether it would be a good idea.

Feel free to put it on the back-burner now.  Further investigation
with some internal Google teams revealed that the use-cases are more
varied and complicated than previously thought.  I haven't had time to
work through the issues and come up an improved proposal yet.

As for implementor interest, I know Ojan's interested in solving this
problem, so Chrome has some interest.

~TJ

From esprehn at chromium.org  Tue Nov 20 20:49:00 2012
From: esprehn at chromium.org (Elliott Sprehn)
Date: Tue, 20 Nov 2012 23:49:00 -0500
Subject: [whatwg] Feedback on Web Worker specification
In-Reply-To: <Pine.LNX.4.64.1211202302220.26354@ps20323.dreamhostps.com>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>
	<BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>
	<CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>
	<BLU002-W147F9FEEEA6218FC696F05FAA6B0@phx.gbl>
	<CAArhhitgJawaJVu9BNF4940Tst3Vuco64VhhLw5q=XgyqgbXZw@mail.gmail.com>
	<Pine.LNX.4.64.1211202302220.26354@ps20323.dreamhostps.com>
Message-ID: <CAO9Q3iLuGjctfwiePwU2y2MFRhUUQ=9vw41YHTc0JJe99TQZQg@mail.gmail.com>

On Tue, Nov 20, 2012 at 6:30 PM, Ian Hickson <ian at hixie.ch> wrote:

> ...
> On Sat, 3 Nov 2012, Fred Andrews wrote:
> >
> > Feedback and suggestions for appropriate markup to declare web workers
> > would be appreciated.
>
> Workers are only usable from script, so just start them in script. No need
> for anything declarative.
>

This has come up a couple times with developers and I think being able to
do:

and then being able to access the worker to post message it by id would be
extremely useful.

document.getElementById('taskQueue').worker.postMessage(...);

Forcing the code into a separate file or requiring a data URL is annoying.

- E

From mounir at lamouri.fr  Wed Nov 21 03:31:36 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 21 Nov 2012 11:31:36 +0000
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50AB414F.8090108@yahoo.fr>
References: <50A12B1F.1080200@lamouri.fr>
	<Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
	<50AB414F.8090108@yahoo.fr>
Message-ID: <50ACBB98.9060803@lamouri.fr>

On 20/11/12 08:37, Nicolas Froidure wrote:
> On 20/11/2012 07:17, Ian Hickson wrote:
>> a date/time picker that works just like the
>> one without a timezone, except that it then converts the time you give
>> into UTC.
>>    
> That's exactly the behavior i would like to have. From the server side
> it seems nice.
> 
> The bad is that Javascript Date objects are initialized with local time
> and prints local time (toString
> <https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toString>).
> Web developers could expect the same behavior for date inputs and date
> objects.

Aren't you looking for this:
https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Date/toUTCString

--
Mounir

From mounir at lamouri.fr  Wed Nov 21 03:51:32 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 21 Nov 2012 11:51:32 +0000
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
References: <50A12B1F.1080200@lamouri.fr>
	<Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
Message-ID: <50ACC044.2060006@lamouri.fr>

On 20/11/12 06:17, Ian Hickson wrote:
> FWIW, the UI I'd expect for today's datetime, maybe renamed to 
> "datetime-global", would be a date/time picker that works just like the 
> one without a timezone, except that it then converts the time you give 
> into UTC. So far example, I'm in the PST time zone, so if I said November 
> 19th, 5pm, it would send that as November 20th, 1am UTC.

Then, maybe a better naming could be "datetime-utc"?

> The idea is to be able to get a precise time from the user without having 
> to worry about what time zone the user's in, and without the user having 
> to worry about what time zone other users are in. This would be very 
> useful for scheduling global events, e.g. when a hangout is to happen, or 
> when a game is to start, etc. I really don't think this is a rare thing. 
> In fact I think mostly it's the one to encourage people to use, which is 
> why it's called "datetime" currently, with the one without timezones, 
> which I think will overall be rarer, having the longer name.

I feel like the main issue is that we disagree in which type is the most
used. I guess it highly depends on who you ask. I tend to book way more
often trains or flights than I arrange meetings.

> I agree that existing UIs are unfortunate, but they should be fixed. It 
> would be unfortunate to push people towards the timezone-less control just 
> because we screwed up the UI and then renamed the type in shame.

What do you think would be a good UI? Does something that would allow
selecting a date/time in the current user's TZ and then have the
information sent to the server in UTC would be a good UI?
But then, there would be no real difference between the "datetime" and
the "datetime-foo" widget, right?

If the main difference between "datetime" and "datetime-foo" is the
format of the value we send to the server, can't we simply always send
the timezone information? So, servers who care about the user's timezone
could do the conversion, and others could simply ignore the information.

Cheers,
--
Mounir

From mounir at lamouri.fr  Wed Nov 21 05:08:26 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 21 Nov 2012 13:08:26 +0000
Subject: [whatwg] Forms-related feedback
In-Reply-To: <Pine.LNX.4.64.1211201954290.26354@ps20323.dreamhostps.com>
References: <50AB6E5F.5050803@lamouri.fr>
	<Pine.LNX.4.64.1211201954290.26354@ps20323.dreamhostps.com>
Message-ID: <50ACD24A.7050903@lamouri.fr>

On 20/11/12 22:51, Ian Hickson wrote:
> On Tue, 20 Nov 2012, Mounir Lamouri wrote:
>> > 
>> > Currently stepUp(n) and stepDown(n) are very basic methods. They more or 
>> > less do value += n * allowedValueStep; with n = -n; if stepDown() was 
>> > called. In addition of being pretty dumb, there are a lot of reasons why 
>> > they can throw.
>> > 
>> > At Mozilla, we think that the main use case for stepUp() and stepDown() 
>> > is to create a UI with spin buttons: clicking on the up arrow would call 
>> > stepUp() and clicking on the down arrow would call stepDown(). Such a 
>> > use case needs methods that do better than just adding n * 
>> > allowedValueStep. In addition, we think that throwing is very often a 
>> > bad idea and that should happen when the developer clearly did something 
>> > wrong.
>> > 
>> > So, we would like to change the stepUp()/stepDown() algorithm to match
>> > the following behaviour:
>> > - we only throw if the input type doesn't allow those methods or if
>> > there is no allowed value step;
>> > - if the value isn't a number (aka empty string), we should just exit
>> > the steps;
>> > - if the value is below the minimal allowed value and n is negative, we
>> > should exit the steps;
>> > - if the value is above the maximal allowed value and n is positive, we
>> > should exit the steps;
>> > - if the element is suffering from a step mismatch, and n is negative,
>> > the value should be changed to the next valid value. Otherwise, it
>> > should be changed to the previous allowed value;
>> > - newValue = value + n * allodValueStep;
>> > - if the newValue is below the minimal allowed value, the newValue
>> > should be equal the minimal allowed value;
>> > - if the newValue is higher than the minimal allowed value, the newValue
>> > should be equal the minimal allowed value.
>> > 
>> > Such a behaviour creates a real added value in stepUp() and stepDown() 
>> > that make those methods useful compared to simply do value += n * 
>> > allowedValueStep; and prevent throwing when there is no need to.
>
> Done, though I described it in a different way. (I hope it's equivalent.)

I think there are two behaviour that you seem to have described differently:
- in step 12, if you take the example page [1], setting the value to 21
and calling stepDown() should change the value to 20 and setting it to
19 and calling stepUp() should change it to 20. This how it is
implemented in Opera and Firefox and this how the Chrome's UI behaves.
As far as I understand the spec you wrote, those two examples would give
respectively 10 and 30.
- I believe that when the value is set to below min and n < 0, we should
not change the value. Same thing for value below max and n > 0. This is
the behaviour all UA currently have with stepUp() and stepDown()
(though, the previous spec was requiring that) and this is Chrome's UI
behaviour. I think that behaviour makes more sense UX-wise because going
down or up and having the value going the opposite way is just weird and
unexpected.

>> > [1] The only difference between Chrome's spin buttons behaviour and our 
>> > proposal is that when value is the empty string, it is setting value to 
>> > 0 and continue to the next steps (unless the 0 is below the minimal 
>> > allowed value and n < 0, in that case value=min). It might be 
>> > interesting to specify something better than "do nothing" if value="".
>
> I'm open to doing that too; what would you preference be?

Maybe if value isn't valid, we could have it changed to the step base or
|min + (max - min)/2| and exit the steps if stepDown() or stepUp() is
called. (I think even if stepDown(hugeNumber) is called, we should still
just set the value and do nothing else.)
I would tend to prefer step base mostly because it would know set it to
the default value if there is a default value. However, I think step
base is quite a bad solution for some types. Maybe we could use the
"default value" if there is such a concept for the type or the "step
base" otherwise?

[1] http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=1918

Thank you for the prompt change, Ian.

--
Mounir

From mounir at lamouri.fr  Wed Nov 21 06:12:35 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 21 Nov 2012 14:12:35 +0000
Subject: [whatwg] Make stepUp() and stepDown() more developer-friendly
In-Reply-To: <Pine.LNX.4.64.1211202253300.16964@ps20323.dreamhostps.com>
References: <50AB6E5F.5050803@lamouri.fr>
	<CAO8i3icCK=WYhMe=ToaRw7VWerBi5CmuYidFfoi9nNOaMXAnkA@mail.gmail.com>
	<Pine.LNX.4.64.1211202253300.16964@ps20323.dreamhostps.com>
Message-ID: <50ACE153.70805@lamouri.fr>

On 20/11/12 22:55, Ian Hickson wrote:
> On Tue, 20 Nov 2012, Scott Gonz?lez wrote:
>>
>> Can you explain why these methods should be no-ops if the value is above 
>> the max or below the min? In jQuery UI, we decided that using these 
>> methods should always result in a valid value.
> 
> I actually missed that in Mounir's suggestion, and the spec now rounds to 
> the nearest allowed value in that case, rather than doing nothing.
> 
> Mounir: is that ok?

As said in my reply to "Forms-related feedback" thread, I think it is
weird to have stepDown() going up or stepUp() going down. Users should
understand that they can't go down if the down arrow isn't doing nothing.
FWIW, this is the behaviour Opera and Chrome UI's have. This is also the
behaviour stepUp() and stepDown() have in Gecko and Presto.

>> I can list out the steps we take for all conditions, but I'd like to 
>> hear everyone's thoughts on the various cases where you're suggesting 
>> that the methods do nothing.
> 
> Mostly I agree with Mounir here, but I'm curious about what you think 
> should happen for the case where there's no value, and the case where the 
> control isn't a numeric/date/time type. I could see an argument for 
> stepping from the default in the former case (Mounir, what do you think 
> about doing that?) but for the latter case I don't really see any point 
> doing anything but throw an exception, as Mounir suggested.

I also replied about the no value case in "Forms-related feedback"
thread. I believe it might be better to set the value to something. I'm
not sure which value should be used for that.

Cheers,
--
Mounir

From froidure_nicolas at yahoo.fr  Wed Nov 21 08:07:07 2012
From: froidure_nicolas at yahoo.fr (Nicolas Froidure)
Date: Wed, 21 Nov 2012 17:07:07 +0100
Subject: [whatwg] Provide data chunk with the ProgressEvent
Message-ID: <50ACFC2B.9090209@yahoo.fr>

I'm currently working on a way to update UI before the all XHR datas to 
be loaded (sample 
<http://server.elitwork.com/experiments/pagestream/index.html>)

For that need i used the progress listener 
<http://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html#progressevent> but 
it's particularly unadapted to it's use.

Indeed, the only way to access to the data chunk loaded is to keep a 
reference to the previous value of xhr.responseText.

I think it could be more usefull if the progress event was providing a 
chunk property containing only the new datas loaded. So we could do that :

var myXhr=new XMLHttpRequest();
var mylist=document.getElementById('mylist');
myXhr.open("GET", "entries.dat", true);
myXhr.onprogress=function(event)
	{
	var item=document.createElement('li');
	item.innerHTML=event.chunk;
	myList.appendChild(item);
	}
myXhr.send(null);

Instead of :

var myXhr=new XMLHttpRequest();
var mylist=document.getElementById('mylist');
myXhr.open("GET", "entries.dat", true);
var previousContentLength=0;
myXhr.onprogress=function()
	{
	var item=document.createElement('li');
	item.innerHTML=myXhr.responseText.substr(previousContentLength);
	previousContentLength=myXhr.responseText.length;
	myList.appendChild(item);
	}
myXhr.send(null);

Regards, Nicolas Froidure.

From jussi.kalliokoski at gmail.com  Wed Nov 21 08:30:23 2012
From: jussi.kalliokoski at gmail.com (Jussi Kalliokoski)
Date: Wed, 21 Nov 2012 18:30:23 +0200
Subject: [whatwg] Provide data chunk with the ProgressEvent
In-Reply-To: <50ACFC2B.9090209@yahoo.fr>
References: <50ACFC2B.9090209@yahoo.fr>
Message-ID: <CAJhzemVSyQa6K-fLteWBqp6Aa=yWVtV-07b-bbN1WE92kV1NNQ@mail.gmail.com>

There is something like this cooking in the form of

responseType = "chunked-text"
and
responseType = "chunked-arraybuffer"

For reference, see [1] and [2]. Would be cool to hear a status update on
specifying these. Anyway, apparently the right forum of discussion for this
is the webapps mailing list.

Cheers,
Jussi

[1] http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html(Jonas'
original suggestion to solve the problem)
[2]
http://lists.w3.org/Archives/Public/public-whatwg-archive/2012Aug/0210.html(my
mail on the same subject as yours)

On Wed, Nov 21, 2012 at 6:07 PM, Nicolas Froidure <froidure_nicolas at yahoo.fr
> wrote:

> I'm currently working on a way to update UI before the all XHR datas to be
> loaded (sample <http://server.elitwork.com/**experiments/pagestream/index.
> **html <http://server.elitwork.com/experiments/pagestream/index.html>>)
>
> For that need i used the progress listener <http://dvcs.w3.org/hg/**
> progress/raw-file/tip/**Overview.html#progressevent<http://dvcs.w3.org/hg/progress/raw-file/tip/Overview.html#progressevent>>
> but it's particularly unadapted to it's use.
>
> Indeed, the only way to access to the data chunk loaded is to keep a
> reference to the previous value of xhr.responseText.
>
> I think it could be more usefull if the progress event was providing a
> chunk property containing only the new datas loaded. So we could do that :
>
> var myXhr=new XMLHttpRequest();
> var mylist=document.**getElementById('mylist');
> myXhr.open("GET", "entries.dat", true);
> myXhr.onprogress=function(**event)
>         {
>         var item=document.createElement('**li');
>         item.innerHTML=event.chunk;
>         myList.appendChild(item);
>         }
> myXhr.send(null);
>
> Instead of :
>
> var myXhr=new XMLHttpRequest();
> var mylist=document.**getElementById('mylist');
> myXhr.open("GET", "entries.dat", true);
> var previousContentLength=0;
> myXhr.onprogress=function()
>         {
>         var item=document.createElement('**li');
>         item.innerHTML=myXhr.**responseText.substr(**
> previousContentLength);
>         previousContentLength=myXhr.**responseText.length;
>         myList.appendChild(item);
>         }
> myXhr.send(null);
>
> Regards, Nicolas Froidure.
>

From annevk at annevk.nl  Wed Nov 21 08:34:22 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 21 Nov 2012 17:34:22 +0100
Subject: [whatwg] URL: query string
Message-ID: <CADnb78gHTiF1qh=Q7D+zY8gG3oAeTNH28uP2x2S=4D8g4GRzCw@mail.gmail.com>

Writing and parsing currently distinguish between URLs that can be
written relatively and those that cannot. URLs with a relative scheme
http://url.spec.whatwg.org/#relative-scheme have a relative syntax and
the others do not. Fragment makes sense to have on both, although for
setting hash (not getting) I ended up special casing the scheme
"javascript" because that would make little sense.

For query I think I might have made the wrong judgment, it is
currently not supported. mailto: I suppose is an obvious candidate
where it does make sense to have it separate and not rely on the
mailto: specific-processing for that, but for data: and javascript:
(again) and also about: it is less clear. Does anyone know whether
Internet Explorer supports "about:blank?test"? Always parsing query in
the base URL parser is also closer to STD 66.

(Browser support is all over the map. For "mailto:test?test" Firefox
gives neither pathname/search, Opera/Safari give pathname/search,
Chrome only gives pathname, which is "test?test". No access to
Internet Explorer unfortunately.)

-- 
http://annevankesteren.nl/

From annevk at annevk.nl  Wed Nov 21 08:36:08 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 21 Nov 2012 17:36:08 +0100
Subject: [whatwg] URL: percent-encoded host
In-Reply-To: <50AAED0A.80808@mit.edu>
References: <CADnb78g54Zryb9WYa=Kqrw1PgcVjM2mLQ9e3uS7_h6Y-D4MMwQ@mail.gmail.com>
	<50AAED0A.80808@mit.edu>
Message-ID: <CADnb78h0-CS2MvZD6-MF3YvJc6m1bFd2etEA2nJ0CuFtFxR3Vw@mail.gmail.com>

On Tue, Nov 20, 2012 at 3:38 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> So I don't think we should require this behavior.

Thanks, I went with requiring decoding per UTF-8 for now causing
sequences such as "%80" to turn into U+FFFD. I think that
simplification over just decoding valid utf-8 sequences is justified
because once you run the Punycode algorithm the original byte sequence
meaning is lost anyway.

-- 
http://annevankesteren.nl/

From annevk at annevk.nl  Wed Nov 21 08:37:06 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 21 Nov 2012 17:37:06 +0100
Subject: [whatwg] URL: IPv6 parsing and model/serializing
In-Reply-To: <50A503F9.3090302@mit.edu>
References: <CADnb78jnyYt1+5SRX7QBzHmo5Ux0K519MfZksmGk6Kobb0A+CA@mail.gmail.com>
	<50A3EB70.1030308@mit.edu>
	<CADnb78hQjWTiyZZL8vQqVeGQ4y+2+jfLCskrFfaBqT7wn3xZkA@mail.gmail.com>
	<50A503F9.3090302@mit.edu>
Message-ID: <CADnb78iuesQgQWp9m1erxS2vHFt=zBqnYq0exQ+BV4awwYFpxA@mail.gmail.com>

On Thu, Nov 15, 2012 at 4:02 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Just to be clear, I don't necessarily object to normalizing IPv6 addresses.
> Especially since I'm no longer actively working on networking code, so it's
> not like it would be work for _me_.  I just mentioned the only concern I had
> about your proposal, which in general sounds excellent.

Thanks, I went with requiring the Chrome behavior for now as that
matches the recommendation for IPv6 representation and is also more in
line with the normalization that is already present for domain names.

-- 
http://annevankesteren.nl/

From annevk at annevk.nl  Wed Nov 21 08:38:57 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 21 Nov 2012 17:38:57 +0100
Subject: [whatwg] Provide data chunk with the ProgressEvent
In-Reply-To: <50ACFC2B.9090209@yahoo.fr>
References: <50ACFC2B.9090209@yahoo.fr>
Message-ID: <CADnb78jE0Z5e2T9BocE8eOZJAO++rF1XO7FowVMMKuoNq_6V-g@mail.gmail.com>

On Wed, Nov 21, 2012 at 5:07 PM, Nicolas Froidure
<froidure_nicolas at yahoo.fr> wrote:
> I think it could be more usefull if the progress event was providing a chunk
> property containing only the new datas loaded.

The plan for this is that you set responseType to "stream" and use the
Stream object returned by response for incremental updates.

See http://xhr.spec.whatwg.org/ for details.

-- 
http://annevankesteren.nl/

From bzbarsky at MIT.EDU  Wed Nov 21 08:44:48 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 21 Nov 2012 11:44:48 -0500
Subject: [whatwg] Provide data chunk with the ProgressEvent
In-Reply-To: <50ACFC2B.9090209@yahoo.fr>
References: <50ACFC2B.9090209@yahoo.fr>
Message-ID: <50AD0500.2050504@mit.edu>

On 11/21/12 11:07 AM, Nicolas Froidure wrote:
> Indeed, the only way to access to the data chunk loaded is to keep a
> reference to the previous value of xhr.responseText.

Nicolas, see 
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html 
(implemented in Gecko as the "moz-chunked-text" and 
"moz-chunked-arraybuffer" response types so people can experiment with 
it).  Would that address your use case?

-Boris

From froidure_nicolas at yahoo.fr  Wed Nov 21 08:53:25 2012
From: froidure_nicolas at yahoo.fr (Nicolas Froidure)
Date: Wed, 21 Nov 2012 17:53:25 +0100
Subject: [whatwg] Provide data chunk with the ProgressEvent
In-Reply-To: <50AD0500.2050504@mit.edu>
References: <50ACFC2B.9090209@yahoo.fr> <50AD0500.2050504@mit.edu>
Message-ID: <50AD0705.10609@yahoo.fr>

Perfectly ! Thanks. Registered to webapps list too, sorry for the noise.

On 21/11/2012 17:44, Boris Zbarsky wrote:
> On 11/21/12 11:07 AM, Nicolas Froidure wrote:
>> Indeed, the only way to access to the data chunk loaded is to keep a
>> reference to the previous value of xhr.responseText.
>
> Nicolas, see 
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html (implemented 
> in Gecko as the "moz-chunked-text" and "moz-chunked-arraybuffer" 
> response types so people can experiment with it).  Would that address 
> your use case?
>
> -Boris
>

From annevk at annevk.nl  Wed Nov 21 08:58:56 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 21 Nov 2012 17:58:56 +0100
Subject: [whatwg] Provide data chunk with the ProgressEvent
In-Reply-To: <50AD0500.2050504@mit.edu>
References: <50ACFC2B.9090209@yahoo.fr>
	<50AD0500.2050504@mit.edu>
Message-ID: <CADnb78jzXuFNAzpFYQdmKRKnkz-w4SN0V-==kwA0OLvuAdF=Ag@mail.gmail.com>

On Wed, Nov 21, 2012 at 5:44 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Nicolas, see
> http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html
> (implemented in Gecko as the "moz-chunked-text" and
> "moz-chunked-arraybuffer" response types so people can experiment with it).
> Would that address your use case?

See http://lists.w3.org/Archives/Public/public-webapps/2012JulSep/0858.html
for why we didn't go with that.

-- 
http://annevankesteren.nl/

From mounir at lamouri.fr  Wed Nov 21 09:00:18 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Wed, 21 Nov 2012 17:00:18 +0000
Subject: [whatwg] Improving autocomplete
In-Reply-To: <op.wnl2aps1y3oazb@chaals.local>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<op.wnl2aps1y3oazb@chaals.local>
Message-ID: <50AD08A2.2060808@lamouri.fr>

On 11/11/12 13:26, Charles McCathie Nevile wrote:
> On Sun, 11 Nov 2012 07:50:48 +0100, Maciej Stachowiak <mjs at apple.com>
> wrote:
>> (1) If this API fills in a form completely based on stored data, and
>> not by completing the user's typing, then it is "autofill" rather than
>> "autocomplete".
> 
> Yep.
> 
>> (2) If this API provides the ability to get user information without
>> even having a visible form, then it's not clear that it is even really
>> autofill. It's just "requestUserInformation()" or something.
> 
> Right. It's like openly shared super-cookies...
> 
>> (3) This API has important privacy and even security considerations.
> 
> Yes.
> 
>> You have to tell the user exactly what you are going to fill in to the
>> site before they approve.
> 
> And because as soon as you put it into the input field the site can use
> it, as a basic security measure it seems like you should never autofill
> without explicit user confirmation.
> 
>> Unfortunately, most won't read it.
> 
> Indeed.
> 
>> If sites are asking for so much info that they have to split pages for
>> usability, then it seems likely the UI that tells the user what the
>> site is asking for will be impractical for most users to meaningfully
>> review.
> 
> Yes. This is a problem I face from time to time, and I think its
> seriousness is underestimated. This process can be used to collect all
> sorts of information before the user realises they didn't want to hand
> it over.
> 
>> This becomes especially dangerous if the mechanism can fill in credit
>> card info.
> 
> That assumes your most valuable info is about your credit card, which is
> only the case for a certain proportion of people.
> 
>> I would be very nervous if the browser could at any moment pop up a
>> dialog that would submit all my credit card info to a dubious site if
>> I slip and click the wrong button. Can you expand more on what thought
>> you have given to the security considerations?

I share the same concerns as Charles and Maciej (see above).

Especially, even if there is an unspoofable UI that is clearly
recognised as part of the browser chrome, any malicious author would be
a click close from getting your credit card number information. If I
understand it correctly, it would be as easy as writing a <form> with
some <input autocomplete="cc-{number,name,...}"> and then call
requestAutocomplete(). If the user press "OK", the page will got those
information, right?
This might be the same security mechanism as geolocation but the outcome
would be so tempting that people might try way harder to get your credit
card information than your location.

In addition, I wonder how valid the use cases of this feature are.
Nowadays, I feel like most websites will, by default or trough opt-in,
save all information so when you come back, you do not have to enter
your address, credit card information and anything else. Seems like
those websites have solved the issue themselves.
I feel like the real use case is when a user wants to make custom with a
web site for the first time. It might be indeed harder to get a good
transformation ration if the user has to write all those information.
However, I doubt we should add such a scary feature for that use case.

Cheers,
--
Mounir

From pkasting at google.com  Wed Nov 21 12:04:56 2012
From: pkasting at google.com (Peter Kasting)
Date: Wed, 21 Nov 2012 12:04:56 -0800
Subject: [whatwg] Improving autocomplete
In-Reply-To: <50AD08A2.2060808@lamouri.fr>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<op.wnl2aps1y3oazb@chaals.local> <50AD08A2.2060808@lamouri.fr>
Message-ID: <CAAHOzFBGQ9qYKwxqAPrMq0R6918866Kpgyv-zosOacwsy1bTNA@mail.gmail.com>

On Wed, Nov 21, 2012 at 9:00 AM, Mounir Lamouri <mounir at lamouri.fr> wrote:

> I feel like the real use case is when a user wants to make custom with a
> web site for the first time. It might be indeed harder to get a good
> transformation ration if the user has to write all those information.
> However, I doubt we should add such a scary feature for that use case.

On the contrary, as a user I find that case extremely compelling.  Maybe
I'm too easily frustrated, but it's intensely annoying when I have to fill
out all my personal information yet again just because I've gone to some
new site to buy something.  This is far harder on mobile because typing is
just a huge pain there and the screen is small enough that I can only see a
few fields at once.  Existing UA autofill is nice but pages often defeat it
due to the sorts of problems described in the original root post.

It's already the case that Chrome can autofill my credit card number into a
form that asks for it, so I'm not totally sure why the proposed
capabilities here are viewed as new and scary.  It seems like we're just
trying to expose a slightly nicer event system for letting authors interact
with the existing UA feature set.

I totally agree that we should think hard about privacy and security issues
with form autofilling.  It's just that I think we're already in a world
where we have to think about those concerns (indeed, have been so for
awhile), and the specific proposals here don't really amount to a
systematic difference in that respect.

From silver at warwickcompsoc.co.uk  Wed Nov 21 12:07:37 2012
From: silver at warwickcompsoc.co.uk (James Ross)
Date: Wed, 21 Nov 2012 20:07:37 +0000
Subject: [whatwg] URL: query string
In-Reply-To: <CADnb78gHTiF1qh=Q7D+zY8gG3oAeTNH28uP2x2S=4D8g4GRzCw@mail.gmail.com>
References: <CADnb78gHTiF1qh=Q7D+zY8gG3oAeTNH28uP2x2S=4D8g4GRzCw@mail.gmail.com>
Message-ID: <DUB002-W66E625C8F98B398B174B30E3540@phx.gbl>

> (Browser support is all over the map. For "mailto:test?test" Firefox
> gives neither pathname/search, Opera/Safari give pathname/search,
> Chrome only gives pathname, which is "test?test". No access to
> Internet Explorer unfortunately.)
FWIW, according to http://dump.testsuite.org/url/inspect.html, IE10 gives pathname/search as "test"/"?test" in both IE10 and IE9 modes.

-- 
James Ross silver at warwickcompsoc.co.uk

From annevk at annevk.nl  Wed Nov 21 13:05:46 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Wed, 21 Nov 2012 22:05:46 +0100
Subject: [whatwg] URL: query string
In-Reply-To: <DUB002-W66E625C8F98B398B174B30E3540@phx.gbl>
References: <CADnb78gHTiF1qh=Q7D+zY8gG3oAeTNH28uP2x2S=4D8g4GRzCw@mail.gmail.com>
	<DUB002-W66E625C8F98B398B174B30E3540@phx.gbl>
Message-ID: <CADnb78huJySE-C4RjbO1taXpVONQtZY0XDCdpfu1ksR=u4je-w@mail.gmail.com>

On Wed, Nov 21, 2012 at 9:07 PM, James Ross <silver at warwickcompsoc.co.uk> wrote:
> FWIW, according to http://dump.testsuite.org/url/inspect.html, IE10 gives pathname/search as "test"/"?test" in both IE10 and IE9 modes.

Sweet, is that true for "test:test?test", "about:blank?test", and
"data:test?test" too? In any case it sounds like this change should be
made.

-- 
http://annevankesteren.nl/

From silver at warwickcompsoc.co.uk  Wed Nov 21 13:10:47 2012
From: silver at warwickcompsoc.co.uk (James Ross)
Date: Wed, 21 Nov 2012 21:10:47 +0000
Subject: [whatwg] URL: query string
In-Reply-To: <CADnb78huJySE-C4RjbO1taXpVONQtZY0XDCdpfu1ksR=u4je-w@mail.gmail.com>
References: <CADnb78gHTiF1qh=Q7D+zY8gG3oAeTNH28uP2x2S=4D8g4GRzCw@mail.gmail.com>,
	<DUB002-W66E625C8F98B398B174B30E3540@phx.gbl>,
	<CADnb78huJySE-C4RjbO1taXpVONQtZY0XDCdpfu1ksR=u4je-w@mail.gmail.com>
Message-ID: <DUB002-W589A022F68C3D67A9C083AE3540@phx.gbl>

> On Wed, Nov 21, 2012 at 9:07 PM, James Ross <silver at warwickcompsoc.co.uk> wrote:
> > FWIW, according to http://dump.testsuite.org/url/inspect.html, IE10 gives pathname/search as "test"/"?test" in both IE10 and IE9 modes.
> 
> Sweet, is that true for "test:test?test", "about:blank?test", and
> "data:test?test" too? In any case it sounds like this change should be
> made.
 Alas not quite; for "test:test?test" and "data:test?test" it works, but for "about:blank?test" it gives pathname="blank?test" and search="". The behaviour change appears to be specific to the "about:" scheme (it happens no matter what I put after). It also doesn't split out the hash, if there is one, when the scheme is "about:".
-- 
James Ross silver at warwickcompsoc.co.uk

From fredandw at live.com  Wed Nov 21 15:45:14 2012
From: fredandw at live.com (Fred Andrews)
Date: Wed, 21 Nov 2012 23:45:14 +0000
Subject: [whatwg] Feedback on Web Worker specification
In-Reply-To: <CAO9Q3iLuGjctfwiePwU2y2MFRhUUQ=9vw41YHTc0JJe99TQZQg@mail.gmail.com>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>,
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>,
	<BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>,
	<CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>,
	<BLU002-W147F9FEEEA6218FC696F05FAA6B0@phx.gbl>,
	<CAArhhitgJawaJVu9BNF4940Tst3Vuco64VhhLw5q=XgyqgbXZw@mail.gmail.com>,
	<Pine.LNX.4.64.1211202302220.26354@ps20323.dreamhostps.com>,
	<CAO9Q3iLuGjctfwiePwU2y2MFRhUUQ=9vw41YHTc0JJe99TQZQg@mail.gmail.com>
Message-ID: <BLU002-W192688BFED71612C5A9B775AA540@phx.gbl>

Hi Elliot,

Thank you for the suggestion.  Using the <script> element seems like a good
approach to explore.

Overloading the 'type' attribute could be problematic because the script type
may well be orthogonal to the JS context to which the script applies.  Could I
suggest a new attribute, for example 'context' that declares the script context.

I presume allowing multiple script elements to declare code for a single worker
would be a complex a thread synchronization problem and thus might be best
avoided?

If so then using the element id seems ok.  Otherwise perhaps giving the workers
a name would be better so that multiple script elements could declare code for
a particular worker?  Or could the 'class' attribute suit?

For example:
<script type="text/javascript" context="worker" name="taskQueue1">
...
</script>

...more...

</script>

If the starting of the worker could be deferred until the page had all loaded then
perhaps the above usage could be thread safe.

I presume allowing the document JS to inject new script elements for a worker
would also be a complex thread synchronization problem and might also be best
avoided?

For the use case I have in mind the worker needs to be created from only static
markup so such a restriction would suit.

Supporting the 'src' attribute would also be useful, particularly for pages using a CSP.
For example:
<script type="text/javascript" context="worker" name="taskQueue1" src="taskqueue1.js"></script>

cheers
Fred

> From: esprehn at chromium.org
> Date: Tue, 20 Nov 2012 23:49:00 -0500
> To: ian at hixie.ch
> CC: whatwg at whatwg.org
> Subject: Re: [whatwg] Feedback on Web Worker specification
> 
> On Tue, Nov 20, 2012 at 6:30 PM, Ian Hickson <ian at hixie.ch> wrote:
> 
> > ...
> > On Sat, 3 Nov 2012, Fred Andrews wrote:
> > >
> > > Feedback and suggestions for appropriate markup to declare web workers
> > > would be appreciated.
> >
> > Workers are only usable from script, so just start them in script. No need
> > for anything declarative.
> >
> 
> This has come up a couple times with developers and I think being able to
> do:
> 
> <script type="worker" id="taskQueue">
>   ...
> </script>
> 
> and then being able to access the worker to post message it by id would be
> extremely useful.
> 
> document.getElementById('taskQueue').worker.postMessage(...);
> 
> Forcing the code into a separate file or requiring a data URL is annoying.
> 
> - E

From isherman at chromium.org  Wed Nov 21 15:55:00 2012
From: isherman at chromium.org (Ilya Sherman)
Date: Wed, 21 Nov 2012 15:55:00 -0800
Subject: [whatwg] Autocomplete and autofill features and feedback thereon
In-Reply-To: <Pine.LNX.4.64.1211202332400.26354@ps20323.dreamhostps.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<CAPJYB1go+r_FCXknEJ_9MM7wVtvXj9ezygZD8A0rciVCqrw=wA@mail.gmail.com>
	<Pine.LNX.4.64.1211202332400.26354@ps20323.dreamhostps.com>
Message-ID: <CAA3nRagyu0L1iHenL3P5HuA=495ZsbA24GVcNi2B25enr8BCsQ@mail.gmail.com>

On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Tue, 16 Oct 2012, Ilya Sherman wrote:
> > The payment instrument type is almost certainly appropriate to add -- it
> > is included on almost every website that I've encountered that includes
> > payment card fields.  It was an oversight on my part to omit it from the
> > initial proposal.
>
> It's redundant data, the credit card number itself says what type it is.
>
> More importantly, I don't know how to store the information. What values
> should we be expecting here? If a site has radio buttons "v", "m" and "a",
> and another has a <select> with "4", "5", and "3", and yet another has
> three buttons which set a type=hidden with the values "visa", "mastercard"
> and "amex", how is the user agent to figure out what's going on? This
> makes the magic needed around dates look positively easy.
>

I agree that it's redundant data, but many websites ask for it separately
anyway.  One common reason for this is that the website only supports a
subset of all possible credit card issuers -- for example, many do not
support DiscoverCard.  While the site *could* theoretically infer from the
entered card number that the card is not supported, and show the user an
error, most sites instead force the user to select the card type, and
inform the user of unsupported card types by omitting them from the list.

Regarding storing of the data: I think being able to fill the data is more
important than being able to store it.  For example, Chrome stores just the
card number, and not the type; but Chrome supports filling the type by
inferring it from the stored card number.  For filling the card type, I
think it's strictly easier than filling a <select> dropdown containing
country names, since localization issues don't come into play as much.  The
user agent is presumably not going to be able to handle *every* case; but
in my experience, it's not too hard to handle many/most of the real-world
cases.  Since this attribute is used just as a hint, esoteric difficult
cases don't seem like enough reason to omit the card type as a known token
in the spec.

> > Finally, I have gotten a request to include a field type for bank
> > account numbers, though I have only seen this info actually requested on
> > a small handful of extremely prominent (and generally trusted) websites:
> > Amazon, PayPal, and I think Google Wallet.
>
> Is there any reason we shouldn't just treat bank accounts like just
> another credit card, and use cc-number for these?
>

Yes: Most websites that support credit card numbers as inputs do not
support bank account numbers.  The few websites that do support bank
account numbers use separate fields for these vs. credit card number
inputs.  Labeling both fields identically would leave the browser unable to
distinguish which field to fill with what info.

> On Wed, 31 Oct 2012, Dan Beam wrote:
> >
> > The experimental implementation [1] has been updated to dispatch an
> > "autocompleteerror" as per convention/your feedback.
>
> "autocompleteerror" seems like it'd be fired for an error, not user
> cancelation. User cancelation is usually called either "abort" or
> "cancel". I think autocompletecancel is fine. It's consistent with
> oncancel, which we used for <dialog>. (Fullscreen's "error" event is for a
> slightly different case, based on what the spec says.)
>

There are also cases where we'd want to return actual errors.  For example,
in Chrome, we are only planning to support this dialog for sites served
over HTTPS and without security errors.  We might also want to fire an
error in case the input fails to pass the form's validation requirements.
 Should we use autocompleteerror for the errors, and autocompletecancel for
user cancelations?  Firing separate events for cancelations vs. errors
forces developers to check for each of these cases separately, which seems
like a less convenient API than just checking for one sort of failure
event.  Perhaps we should have a single event named something like
autocompletefail or something like that?

From ian at hixie.ch  Wed Nov 21 16:51:39 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 22 Nov 2012 00:51:39 +0000 (UTC)
Subject: [whatwg] Checkboxes that control other checkboxes
In-Reply-To: <CANEus2rzPK9GJr7bLr2cq0wnONxz3mve2j_Nbo5kbC5NqiEM8w@mail.gmail.com>
References: <CANEus2rzPK9GJr7bLr2cq0wnONxz3mve2j_Nbo5kbC5NqiEM8w@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211220047421.15705@ps20323.dreamhostps.com>

On Sun, 14 Aug 2011, Timo Beermann wrote:
>
> It should be able to implemet checkboxes, where by only 
> activating/deactivating this single checkbox you can active/deactivate 
> multiple other checkboxes. That is possible with scripting today, but it 
> should be possible without scripting, only with HTML/CSS. Because some 
> users deactivate Scripting (for security or whatever other reason) and 
> on other computers (school, university, work,...) you are not able to 
> change the settings, even if you want to. E.g. I use NoScript and only 
> allow scripting on very few trusted sites, that really need it.

I haven't added this yet, but it is already logged as a possible future 
extension, so it's possible it may be added in the future.

What would be helpful though is examples of sites that do this kind of 
thing, so that we can study how necessary it is, and how to implement it. 
For instance, are the dependent fields always in a <fieldset>? Are they 
always other checkboxes? Is there more complex logic than just "check box 
A is checked so those controls are enabled"?

From nils at dieweltistgarnichtso.net  Wed Nov 21 17:11:38 2012
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Thu, 22 Nov 2012 02:11:38 +0100
Subject: [whatwg] Improving autocomplete
In-Reply-To: <CAAHOzFBGQ9qYKwxqAPrMq0R6918866Kpgyv-zosOacwsy1bTNA@mail.gmail.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<op.wnl2aps1y3oazb@chaals.local> <50AD08A2.2060808@lamouri.fr>
	<CAAHOzFBGQ9qYKwxqAPrMq0R6918866Kpgyv-zosOacwsy1bTNA@mail.gmail.com>
Message-ID: <20121122021138.3de85d0d@desudesudesu>

Peter Kasting <pkasting at google.com> schrieb am Wed, 21 Nov 2012
12:04:56 -0800:

> [?]
>
> On the contrary, as a user I find that case extremely compelling.
> Maybe I'm too easily frustrated, but it's intensely annoying when I
> have to fill out all my personal information yet again just because
> I've gone to some new site to buy something.  This is far harder on
> mobile because typing is just a huge pain there and the screen is
> small enough that I can only see a few fields at once.

I have noticed this as well: Several platforms seem to intentionally
make it harder to write text ? mainly through removal of physical
keyboards, taking away pressure feedback and, to a lesser extent
modificator keys.

The proper solution is to let people vote with their wallet for devices
that are perceived as making input easier ? not to hand over power to
site users making it easier to sniff data.

> It's already the case that Chrome can autofill my credit card number
> into a form that asks for it, so I'm not totally sure why the proposed
> capabilities here are viewed as new and scary.  It seems like we're
> just trying to expose a slightly nicer event system for letting
> authors interact with the existing UA feature set.

Looks like an is-ought-problem to me. The descriptive (?It's already
the case ??) can not tell us much about what should be done by virtue
of its existence alone. Did you use ?new and scary? to imply opponents
appeal to tradition?

What Chrome can do is started by users; even then a warning is given:
<http://support.google.com/chrome/bin/answer.py?hl=en&answer=142893>

> It's important that you use Autofill only on websites you trust, as
> certain websites might try to capture your information in hidden or
> hard-to-see fields.

Back to your text:

> I totally agree that we should think hard about privacy and security
> issues with form autofilling.  It's just that I think we're already
> in a world where we have to think about those concerns (indeed, have
> been so for awhile), and the specific proposals here don't really
> amount to a systematic difference in that respect.

The systematic difference ? for me ? is that the proposed functionality
may make easier to trick a user into agreeing to ?autocomplete
everything? than the current functionality does.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From nils at dieweltistgarnichtso.net  Wed Nov 21 17:16:22 2012
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Thu, 22 Nov 2012 02:16:22 +0100
Subject: [whatwg] Improving autocomplete
In-Reply-To: <20121122021138.3de85d0d@desudesudesu>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<op.wnl2aps1y3oazb@chaals.local> <50AD08A2.2060808@lamouri.fr>
	<CAAHOzFBGQ9qYKwxqAPrMq0R6918866Kpgyv-zosOacwsy1bTNA@mail.gmail.com>
	<20121122021138.3de85d0d@desudesudesu>
Message-ID: <20121122021622.5506c6f7@desudesudesu>

Nils Dagsson Moskopp <nils at dieweltistgarnichtso.net> schrieb am Thu, 22
Nov 2012 02:11:38 +0100:

> [?]

> The proper solution is to let people vote with their wallet for
> devices that are perceived as making input easier ? not to hand over
> power to site users making it easier to sniff data.

s/users/owners/g ?

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From pkasting at google.com  Wed Nov 21 17:26:07 2012
From: pkasting at google.com (Peter Kasting)
Date: Wed, 21 Nov 2012 17:26:07 -0800
Subject: [whatwg] Improving autocomplete
In-Reply-To: <20121122021138.3de85d0d@desudesudesu>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<op.wnl2aps1y3oazb@chaals.local> <50AD08A2.2060808@lamouri.fr>
	<CAAHOzFBGQ9qYKwxqAPrMq0R6918866Kpgyv-zosOacwsy1bTNA@mail.gmail.com>
	<20121122021138.3de85d0d@desudesudesu>
Message-ID: <CAAHOzFCMUSHcvw6VWYHzpcBUWxJShqLO2cS9NTa8y-1=ikD9iQ@mail.gmail.com>

On Wed, Nov 21, 2012 at 5:11 PM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

> The proper solution is to let people vote with their wallet for devices
> that are perceived as making input easier ? not to hand over power to
> site users making it easier to sniff data.
>

This contains what I think are multiple false assumptions:
(1) It's reasonable to discriminate against devices that don't make input
as easy as my desktop computer with its full-size keyboard.  Given the rise
of mobile web usage, it seems clear that users will increasingly access the
web with devices that physically can never be as accommodating as my
desktop computer can.  I don't think that allows us to simply say "oh well"
and ignore the problem.
(2) The proposals make it "easier to sniff data".  The entire point of my
email was that IMO this is simply false.

> It's already the case that Chrome can autofill my credit card number
> > into a form that asks for it, so I'm not totally sure why the proposed
> > capabilities here are viewed as new and scary.  It seems like we're
> > just trying to expose a slightly nicer event system for letting
> > authors interact with the existing UA feature set.
>
> Looks like an is-ought-problem to me. The descriptive (?It's already
> the case ??) can not tell us much about what should be done by virtue
> of its existence alone. Did you use ?new and scary? to imply opponents
> appeal to tradition?
>

No, I used it to make clear that, at least for some UAs, there is no new
user data being exposed in these proposals, nor is existing data being
exposed to whole new types of sites.  A consideration of whether new APIs
represent an additional security or privacy risk must take these factors
into account.  It is also possible that UAs with existing autofill
capabilities (like Chrome) are already insecure today, in which case it'd
be very useful to note existing problems so that these UAs can fix them and
other vendors can avoid the problems.

What Chrome can do is started by users; even then a warning is given:
> <http://support.google.com/chrome/bin/answer.py?hl=en&answer=142893>
>
> > It's important that you use Autofill only on websites you trust, as
> > certain websites might try to capture your information in hidden or
> > hard-to-see fields.
>

And those same properties -- that these APIs require a user gesture, that
the UA is in control of the presentation, and that ultimately it is up to
users to use them responsibly -- are all true here as well.

> The systematic difference ? for me ? is that the proposed functionality
> may make easier to trick a user into agreeing to ?autocomplete
> everything? than the current functionality does.

Please explain precisely how you see this occurring, because this is the
key part of your argument that I don't grasp, but you've provided no
explanation for it.

An informative reply might be a detailed scenario complete with an
explanation of why the malicious site in question could not accomplish a
similar effect with existing UA capabilities.  This would be very helpful
in informing the design here.

From dbeam at chromium.org  Wed Nov 21 18:36:08 2012
From: dbeam at chromium.org (Dan Beam)
Date: Wed, 21 Nov 2012 18:36:08 -0800
Subject: [whatwg] Autocomplete and autofill features and feedback thereon
In-Reply-To: <CAA3nRagyu0L1iHenL3P5HuA=495ZsbA24GVcNi2B25enr8BCsQ@mail.gmail.com>
References: <CAPJYB1hJvrAk7wyT_wq9=hTkgCkrTqGxaVbw7FcriPTPnP2JyQ@mail.gmail.com>
	<BCD96A46-F5B6-4DDE-B48B-BB25E2BFB379@apple.com>
	<CAPJYB1go+r_FCXknEJ_9MM7wVtvXj9ezygZD8A0rciVCqrw=wA@mail.gmail.com>
	<Pine.LNX.4.64.1211202332400.26354@ps20323.dreamhostps.com>
	<CAA3nRagyu0L1iHenL3P5HuA=495ZsbA24GVcNi2B25enr8BCsQ@mail.gmail.com>
Message-ID: <CANpe7K0n3x_hv2CDust5-N=cPkfzu1iAyHZgd8EDhx_BKJRzjg@mail.gmail.com>

On Wed, Nov 21, 2012 at 3:55 PM, Ilya Sherman <isherman at chromium.org> wrote:
> On Tue, Nov 20, 2012 at 5:17 PM, Ian Hickson <ian at hixie.ch> wrote:
>
>> On Tue, 16 Oct 2012, Ilya Sherman wrote:
>> > The payment instrument type is almost certainly appropriate to add -- it
>> > is included on almost every website that I've encountered that includes
>> > payment card fields.  It was an oversight on my part to omit it from the
>> > initial proposal.
>>
>> It's redundant data, the credit card number itself says what type it is.
>>
>> More importantly, I don't know how to store the information. What values
>> should we be expecting here? If a site has radio buttons "v", "m" and "a",
>> and another has a <select> with "4", "5", and "3", and yet another has
>> three buttons which set a type=hidden with the values "visa", "mastercard"
>> and "amex", how is the user agent to figure out what's going on? This
>> makes the magic needed around dates look positively easy.
>>
>
> I agree that it's redundant data, but many websites ask for it separately
> anyway.  One common reason for this is that the website only supports a
> subset of all possible credit card issuers -- for example, many do not
> support DiscoverCard.  While the site *could* theoretically infer from the
> entered card number that the card is not supported, and show the user an
> error, most sites instead force the user to select the card type, and
> inform the user of unsupported card types by omitting them from the list.
>
> Regarding storing of the data: I think being able to fill the data is more
> important than being able to store it.  For example, Chrome stores just the
> card number, and not the type; but Chrome supports filling the type by
> inferring it from the stored card number.  For filling the card type, I
> think it's strictly easier than filling a <select> dropdown containing
> country names, since localization issues don't come into play as much.  The
> user agent is presumably not going to be able to handle *every* case; but
> in my experience, it's not too hard to handle many/most of the real-world
> cases.  Since this attribute is used just as a hint, esoteric difficult
> cases don't seem like enough reason to omit the card type as a known token
> in the spec.
>
>
>> > Finally, I have gotten a request to include a field type for bank
>> > account numbers, though I have only seen this info actually requested on
>> > a small handful of extremely prominent (and generally trusted) websites:
>> > Amazon, PayPal, and I think Google Wallet.
>>
>> Is there any reason we shouldn't just treat bank accounts like just
>> another credit card, and use cc-number for these?
>>
>
> Yes: Most websites that support credit card numbers as inputs do not
> support bank account numbers.  The few websites that do support bank
> account numbers use separate fields for these vs. credit card number
> inputs.  Labeling both fields identically would leave the browser unable to
> distinguish which field to fill with what info.
>
>
>> On Wed, 31 Oct 2012, Dan Beam wrote:
>> >
>> > The experimental implementation [1] has been updated to dispatch an
>> > "autocompleteerror" as per convention/your feedback.
>>
>> "autocompleteerror" seems like it'd be fired for an error, not user
>> cancelation. User cancelation is usually called either "abort" or
>> "cancel". I think autocompletecancel is fine. It's consistent with
>> oncancel, which we used for <dialog>. (Fullscreen's "error" event is for a
>> slightly different case, based on what the spec says.)
>>
>
> There are also cases where we'd want to return actual errors.  For example,
> in Chrome, we are only planning to support this dialog for sites served
> over HTTPS and without security errors.  We might also want to fire an
> error in case the input fails to pass the form's validation requirements.
>  Should we use autocompleteerror for the errors, and autocompletecancel for
> user cancelations?  Firing separate events for cancelations vs. errors
> forces developers to check for each of these cases separately, which seems
> like a less convenient API than just checking for one sort of failure
> event.  Perhaps we should have a single event named something like
> autocompletefail or something like that?

I don't particularly care about the naming (fail vs. error), I just
knew we had a pre-existing *error event and agreed with Anne that I
might as well go with the convention (of 1).  I can change it quite
easily to whatever the consensus is.

I definitely agree to a single event.  It would be great to do this
and give enumerable failure reasons (if this is deemed secure enough).
 An example:

enum ErrorCause {
    FROM_FRAME,
    NEEDS_GESTURE,
    NOT_SECURE,
  };

This could be a property on the event (event.cause, event.reason?)
argument passed to the error event (kind of like DOM exceptions).
This seems akin to event.property in CSS transition end events (and
disputably many other examples).

From ian at hixie.ch  Wed Nov 21 19:39:42 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 22 Nov 2012 03:39:42 +0000 (UTC)
Subject: [whatwg] restricted palette for input type=color
In-Reply-To: <4FA23E4A.3020104@gmx.ch>
References: <4D75158F.20205@gmx.ch> <4D75FC33.5040908@gmx.ch>
	<5CFD5F04A8944D5596D65E5FAFEDD2F7@JukanPC>
	<op.vr1dpxsi64w2qv@anne-van-kesterens-macbook-pro.local>
	<4D767991.9020909@gmx.ch>
	<AANLkTimpGsbmhnKDttq-DfutZgwi5Vxx+DDeq+FQBBFz@mail.gmail.com>
	<40b7b34cfa192516f197943689728cac@thinkdigital.pt>
	<4D778F94.80301@gmx.ch>
	<Pine.LNX.4.64.1205022214170.1631@ps20323.dreamhostps.com>
	<4FA23E4A.3020104@gmx.ch>
Message-ID: <Pine.LNX.4.64.1211220053250.15705@ps20323.dreamhostps.com>

On Thu, 3 May 2012, Markus Ernst wrote:
> Am 03.05.2012 00:50 schrieb Ian Hickson:
> > On Mon, 7 Mar 2011, Markus Ernst wrote:
> > > 
> > > A content management or blog system for a corporate website allows 
> > > to set font and background colors. The designers define allowed 
> > > color sets the way that the corporate design guidelines are 
> > > respected, and that the text is always readable - e.g. three light 
> > > color shades for backgrounds, and two corporate colors and black for 
> > > text.
> > 
> > You don't really need a colour picker for that... it's more a<select> 
> > than a colour picker. Or a series of radio buttons. If the 
> > presentation is more the concern, then we should probably rely on Web 
> > Components to solve the problem (styling a<select> with a new 
> > presentation, e.g.).
> 
> It is actually an input field that requires a valid color to be entered; 
> whether it is presented as a color picker or a select box may be up to 
> the UA. I don't see any consistency in having to use different HTML 
> elements whether the selection of colors is defined by the UA (e.g. 
> showing a picker with all colors of the web palette) or by the author.

The difference is the same as the difference between:

What kind of credit card do you have? <input type=text name=cc>

...and:

What kind of credit card do you have? <select name=cc>...</select>

> Anyway, 4.10.7.1.15 of the spec states in the bookkeeping details that 
> the @list content and IDL attributes apply to input type=color - if I 
> understand this correctly, it addresses my proposal.

That provides a list of suggestions but doesn't restrict the input to only 
those values.

> > > - The fact that most CMS do not have restricted color sets so far, 
> > > does not mean there is no demand for it, but rather shows the 
> > > difficulty of customizing tools such as TinyMCE. It is a hassle for 
> > > CMS implementors (who are often not highly skilled JS programmers), 
> > > if they are expected to respect corporate design guidelines.
> > 
> > I don't follow. Right now (before type=color is widely implemented) 
> > it's easier to provide a limited set of colours than all colours. 
> > Surely then we should see more CMSes have restricted colour sets if 
> > it's a matter of difficulty.
> 
> The CMS I know are shipped with TinyMCE or KHTML or whatever rich text 
> editors. They usually provide a color picker with a predefined set of 
> colors (iirc it is mostly the web palette) by default, which is 
> non-trivial to override or customize; IMHO this is the reason why 
> customized color pickers are not widely used. There are definitely use 
> cases for them.

Ah, fair enough.

Anyway, I don't disagree that there's a use case. It's already handled, 
using <select>. The thing that isn't handled is making it look more like a 
colour picker, and that's to be handled by Web Components.

From ian at hixie.ch  Wed Nov 21 21:15:39 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 22 Nov 2012 05:15:39 +0000 (UTC)
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50ACC044.2060006@lamouri.fr>
References: <50A12B1F.1080200@lamouri.fr>
	<Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
	<50ACC044.2060006@lamouri.fr>
Message-ID: <Pine.LNX.4.64.1211220344070.15705@ps20323.dreamhostps.com>

On Wed, 21 Nov 2012, Mounir Lamouri wrote:
> On 20/11/12 06:17, Ian Hickson wrote:
> > FWIW, the UI I'd expect for today's datetime, maybe renamed to 
> > "datetime-global", would be a date/time picker that works just like 
> > the one without a timezone, except that it then converts the time you 
> > give into UTC. So far example, I'm in the PST time zone, so if I said 
> > November 19th, 5pm, it would send that as November 20th, 1am UTC.
> 
> Then, maybe a better naming could be "datetime-utc"?

I think that would mislead authors into thinking that the UI that users 
will see is one that asks for a UTC time. That kind of UI is the worst UI 
for this kind of feature, so that would be misleading.

> > The idea is to be able to get a precise time from the user without 
> > having to worry about what time zone the user's in, and without the 
> > user having to worry about what time zone other users are in. This 
> > would be very useful for scheduling global events, e.g. when a hangout 
> > is to happen, or when a game is to start, etc. I really don't think 
> > this is a rare thing. In fact I think mostly it's the one to encourage 
> > people to use, which is why it's called "datetime" currently, with the 
> > one without timezones, which I think will overall be rarer, having the 
> > longer name.
> 
> I feel like the main issue is that we disagree in which type is the most 
> used. I guess it highly depends on who you ask. I tend to book way more 
> often trains or flights than I arrange meetings.

It's not a question of which is _used_ more, it's a question of which is 
_authored_ more. As far as I can tell, the use cases for floating times 
are basically cross-time-zone transport facilities, e.g. plane tickets, 
while the use cases for absolute times are anything involving coordination 
amongst multiple people in multiple time zones, e.g. meetings (in person 
or online), game events, product launches, online live streaming events...

You might book more tickets than you organise meetings, but there are far 
more people doing cross-time-zone multi-person events than there are 
people selling plane and cross-continental plane tickets, IMHO.

> > I agree that existing UIs are unfortunate, but they should be fixed. 
> > It would be unfortunate to push people towards the timezone-less 
> > control just because we screwed up the UI and then renamed the type in 
> > shame.
> 
> What do you think would be a good UI? Does something that would allow 
> selecting a date/time in the current user's TZ and then have the 
> information sent to the server in UTC would be a good UI?

That would probably be a reasonable first UI. A more mature UI would also 
let you pick the time for a specific other time zone (e.g. because you 
know you'll be there), or compare multiple time zones at the same time to 
pick a time convenient for multiple people, etc.

> But then, there would be no real difference between the "datetime" and 
> the "datetime-foo" widget, right?

There doesn't have to be a difference between any of the widgets. They 
could all just be a text field. I wouldn't recommend getting rid of all 
the values though. :-)

> If the main difference between "datetime" and "datetime-foo" is the 
> format of the value we send to the server, can't we simply always send 
> the timezone information? So, servers who care about the user's timezone 
> could do the conversion, and others could simply ignore the information.

I don't think the controls should be the same.

Even if they were, I don't think we should encourage authors to consider 
the time zone field meaningful. That's just asking for errors. Time zone 
manipulation can get really complicated. Did you know that Libya just 
changed time zone this month? And if you start dealing with things like 
daylight savings time, it can become positively ridiculous, having to 
track the whims of goverments around the world.

IMHO, we really want all the complicated time zone manipulation to happen 
either on the client (where we only have to worry about a small number of 
expert implementors), or in display code, where the impact of errors is 
just render-time, not in the database. Back-end code should really only 
have to worry about one time zone for everything.

Also, it's really weird to have the client send a time and then 
intentionally ignore the time zone. That just seems wrong.

From derernst at gmx.ch  Thu Nov 22 02:23:19 2012
From: derernst at gmx.ch (Markus Ernst)
Date: Thu, 22 Nov 2012 11:23:19 +0100
Subject: [whatwg] Checkboxes that control other checkboxes
In-Reply-To: <Pine.LNX.4.64.1211220047421.15705@ps20323.dreamhostps.com>
References: <CANEus2rzPK9GJr7bLr2cq0wnONxz3mve2j_Nbo5kbC5NqiEM8w@mail.gmail.com>
	<Pine.LNX.4.64.1211220047421.15705@ps20323.dreamhostps.com>
Message-ID: <50ADFD17.1090609@gmx.ch>

Am 22.11.2012 01:51 schrieb Ian Hickson:
> On Sun, 14 Aug 2011, Timo Beermann wrote:
>>
>> It should be able to implemet checkboxes, where by only
>> activating/deactivating this single checkbox you can active/deactivate
>> multiple other checkboxes. That is possible with scripting today, but it
>> should be possible without scripting, only with HTML/CSS. Because some
>> users deactivate Scripting (for security or whatever other reason) and
>> on other computers (school, university, work,...) you are not able to
>> change the settings, even if you want to. E.g. I use NoScript and only
>> allow scripting on very few trusted sites, that really need it.
>
> I haven't added this yet, but it is already logged as a possible future
> extension, so it's possible it may be added in the future.
>
> What would be helpful though is examples of sites that do this kind of
> thing, so that we can study how necessary it is, and how to implement it.
> For instance, are the dependent fields always in a <fieldset>? Are they
> always other checkboxes? Is there more complex logic than just "check box
> A is checked so those controls are enabled"?
>
This seems to be a special case of a larger problem to me. In order to 
make forms behave intelligently without scripting, there are more 
similar tasks:
- Check/uncheck check and radio boxes based on the selected value of a 
select element (or even on the values of other input elements)
- Enable/disable or make readonly any kinds of controls based on the 
state or value of an other element
- Or even show/hide a set of elements based on the state or value of an 
other element

Maybe, instead of adding that kind of functionalities to form elements, 
it might be worth thinking of a different way. E.g., define a set of 
scripting actions that are considered as very useful for UIs, and have 
no security issues, and let UAs execute that kind of scripts even if 
scripting is actually disabled, or let UAs offer a user setting such as 
"Allow only useful form actions" or whatever.

From fredandw at live.com  Thu Nov 22 06:13:45 2012
From: fredandw at live.com (Fred Andrews)
Date: Thu, 22 Nov 2012 14:13:45 +0000
Subject: [whatwg] Checkboxes that control other checkboxes
In-Reply-To: <50ADFD17.1090609@gmx.ch>
References: <CANEus2rzPK9GJr7bLr2cq0wnONxz3mve2j_Nbo5kbC5NqiEM8w@mail.gmail.com>,
	<Pine.LNX.4.64.1211220047421.15705@ps20323.dreamhostps.com>,
	<50ADFD17.1090609@gmx.ch>
Message-ID: <BLU002-W191BF3CC7BC57C0081BFC7AA5B0@phx.gbl>

> Date: Thu, 22 Nov 2012 11:23:19 +0100
> From: derernst at gmx.ch
...
> Maybe, instead of adding that kind of functionalities to form elements, 
> it might be worth thinking of a different way. E.g., define a set of 
> scripting actions that are considered as very useful for UIs, and have 
> no security issues, and let UAs execute that kind of scripts even if 
> scripting is actually disabled, or let UAs offer a user setting such as 
> "Allow only useful form actions" or whatever.

Supporting scripts that can implement a rich UI with reduced security
risk is of interest to the work of the W3C PUA CG and some options
have been proposed, see:
http://www.w3.org/community/pua/wiki/Draft

If the sharing of state accessible via the DOM and APIs is seen as a
security risk then scripts that can modify input buttons need to have
very restricted access to the DOM and APIs otherwise they could
implement a UI redressing attack on the input buttons - for example
disabling buttons to discriminate against users or changing the buttons
to leak state when the form is submitted.

If the buttons are being used purely for operations within the UA then
they could be controlled by script in a context restricted from access
to outgoing communication channels (the PUA Private Context).
A prototype proxy implementing these restriction shows that many
rich website UI elements can still operate under such restrictions.

If the buttons are part of an outgoing form then placing them in a
context without JS enabled would seem to be the simplest approach
to protect the DOM and API security.  One option being explored is to
allow a  restricted 'web worker' style context to have some limited
access to page elements, and since this worker does not have general
DOM access the risk of leaking state is reduced.

For example, the check box could have a declarative attribute that
defines a message to post to a worker when it changes, and the
controlled checkbox could have a declarative attribute that defines
a message listener that can change the element.  The form UI logic
and would be implemented in the worker.

Another alternatively is to place the form in an iframe with JS disabled,
but with a declarative extension that allows the form state to be posted
to the worker upon a change in the checkbox or other defined state
changes.  The worker could implement the form state logic and post
back new iframe content with the controlled buttons enabled or disabled
as necessary.  The worker is effectively a local web server using messages
to receive requests and send responses.  An advantage to this approach
is that the form could have a fallback URL so that a server could
implement the logical even if the UA does not support JS.

If targeting UAs without JS then a polyfill is not an option for backwards
compatibility and so forms would still need a fallback for legacy UAs. Have
you though how this might work?   Perhaps include an 'update' button in
the webpage design that posts the form to the server?

cheers
Fred

From fredandw at live.com  Thu Nov 22 07:08:21 2012
From: fredandw at live.com (Fred Andrews)
Date: Thu, 22 Nov 2012 15:08:21 +0000
Subject: [whatwg] Feedback on Web Worker specification
In-Reply-To: <Pine.LNX.4.64.1211202302220.26354@ps20323.dreamhostps.com>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>,
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>,
	<BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>,
	<CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>,
	<BLU002-W147F9FEEEA6218FC696F05FAA6B0@phx.gbl>,
	<CAArhhitgJawaJVu9BNF4940Tst3Vuco64VhhLw5q=XgyqgbXZw@mail.gmail.com>,
	<Pine.LNX.4.64.1211202302220.26354@ps20323.dreamhostps.com>
Message-ID: <BLU002-W184CFCAFC664DF456131BBDAA5B0@phx.gbl>

Dear Ian,

Thank you for sharing you views.

> Date: Tue, 20 Nov 2012 23:30:50 +0000
> From: ian at hixie.ch
> To: whatwg at whatwg.org
> Subject: Re: [whatwg] Feedback on Web Worker specification
> 
> On Wed, 22 Aug 2012, Jeffrey Pfau wrote:
> > 
> > While working on enhancing WebKit's privacy infrastructure, I noticed 
> > that shared workers don't have a UA security policy escape clause like 
> > localStorage and other APIs. The process to create a shared worker does 
> > not allow UAs to abort creation with a SecurityError if it decides that 
> > a document, origin, or script violates the UA's security policy.
> 
> Fixed.
> 
> 
> On Sat, 3 Nov 2012, Fred Andrews wrote:
> > 
> > Feedback and suggestions for appropriate markup to declare web workers 
> > would be appreciated.
> 
> Workers are only usable from script, so just start them in script. No need 
> for anything declarative.

The use case requires a JS context without DOM access and with restricted
API access.  Web workers seem the closest match, but this need not be the
same as a 'web worker'.

> > The use case is a document with JS disabled or restricted so that it can 
> > not create web workers, yet still wants to create web workers to process 
> > page input and to update the document.
> 
> If it's been restricted to not run JS, then starting a worker is 
> pointless, since workers only run JS.

Just to clarify, the proposal is to separately control the document JS context
and another 'web worker' like JS context.  So the document JS may be disabled
or just restricted, while the 'web worker' like JS context can still be enabled.
The contexts may well even be in different principles.
 
> If it's been restricted from starting Web workers, then it doesn't matter 
> how the mechanism to start workers is presented, the page still won't be 
> able to start a worker. It'd be pointless to have a mechanism to block 
> workers that could just be circumvented.

The point is that the parent document JS context has DOM and API access to
read potentially private information and if it can use script to create a worker
that has access to outgoing channels then it also gains a capability to leak
this state.  If the work is created by a declarative mechanism then this channel
is closed.
 
> > The use case is a document with JS disabled or restricted so that it can 
> > not use JS to receive a message and update the DOM, yet still wants to 
> > support AJAX style designs.
> 
> Why would the user disable JavaScript if they wanted the page to act like 
> JavaScript was enabled?

To avoid scripts leaking private state accessible via the DOM and other APIs
the user could disable or restrict JS in contexts that have access to the
DOM or other APIs.  The 'web worker' like context would not have access to
the DOM or other APIs and thus not be a security risk and could be allowed
access to the web to forward information into the UA secure context.  It
is also proposed that the 'web worker' like context receive defined intentional
input from users.
 
> > For example the document JS may be disabled but a declarative mechanism 
> > may be defined to enable web workers to be create and these need to be 
> > able to post changes to the document.
> 
> The whole point of disabling JS is presumably to prevent this, so 
> allowing it would defeat the point, as far as I can tell.

No, the point is to control the covert leaking of UA state.
 
> > A mechanism specific to the need may be better for security.  For 
> > example, being able to bind a HTML <div> element to a specific web 
> > worker.  A general mechanism that allows a message to update any element 
> > by ID may be less desirable for security.
> 
> I don't understand. What attack scenario are you envisaging?

Web page content that includes scripts to covertly read the UA state and
leak this to the web.
 
> > Would it be appropriate to add a new attribute to HTML elements that 
> > allows their inner HTML to be replaced from a received message?
> 
> If JS is enabled, you can replace any element's contents at will.
> 
> If JS is disabled, presumably it's because the author doesn't want the 
> page to be manipulated in this way. I don't see why they'd like a feature 
> that circuments JS being disabled.

There are contexts in which it is safest to just prohibit JS, such as documents
with user input forms, and there is still a use case for these to be able to be
updated.  Information flowing into a context does not pose a risk of leaking
state from this context.  Enabling JS in the secure context poses a risk of
leaking state out.

> > For example, a form in a parent document with document JS disabled that 
> > still wants to be able to post a submitted form to a web worker for 
> > processing, or posting a message when a button is clicked.
> 
> If JS is disabled, the worker isn't going to be able to do anything, since 
> it's just JS. So posting messages to the worker, or even starting a 
> worker, doesn't seem useful. It could't do anything.

The proposal is to control JS separately in different contexts.  JS could be
disabled or restricted in the document JS but enabled in a 'web worker' like
context.

If there are declarative mechanisms to send events from the document to
a worker, and to update the document from worker messages then the worker
could implement a lot of webpage logic (even with the document JS context disabled).

> 
> On Sat, 3 Nov 2012, Fred Andrews wrote:
> > 
> > The use case really is to be able to use web workers rather than the 
> > document JS. An extension to disable or restrict the document JS will 
> > also be added.  The design is intended to limit a large range of 
> > security issues.
> 
> Could you elaborate on these security issues?

Generally the leaking of UA state that the user may well consider private.
The DOM and APIs expose a lot of information about the users use of the UA.
 
> On Mon, 5 Nov 2012, Fred Andrews wrote:
> > 
> > The use I have in mind is a work-in-progress, see: 
> > http://www.w3.org/community/pua/wiki/Draft#Examples
> 
> Limiting JS to workers, or indeed disabling JS entirely, doesn't help you 
> at all as far as I can tell. It's trivial to fingerprint a user by 
> collecting things like the user's IP address, the TCP/IP stack's 
> characteristics, the browser's characteristics, the hardware's 
> capabilities, etc. And it doesn't matter. When your government is a 
> threat, they can just put you under surveillance, and your browser is the 
> least of your problems. Advertisers aren't a threat; the worst they can do 
> is provide you with ads that are more applicable to your interests; they 
> couldn't care less about your personal details, they only care about broad 
> demographic trends. Commercial providers like credit card companies, 
> ecommerce retailers, utilities, ISPs, phone companies, and the like, 
> already have your financial information, personal purchasing habits, 
> personal address, geographical position history, and other private 
> information, which they are willingly given in exchange for services. 
> Stalkers aren't going to be using fingerprinting or data in shared workers 
> to stalk you, they'll go through your friends or place of work.
> 
> In short, I think the entire approach here (and indeed the concern over 
> shared workers in general mentioned at the top of this e-mail) to be 
> rather misguided.

Your feedback suggests to me that the issue was not communicated well,
sorry it is a work in progress.  Perhaps in future the issues can be
communicated better and an implementation will help demonstrate the
design.

cheer
Freed

From fredandw at live.com  Fri Nov 23 03:25:05 2012
From: fredandw at live.com (Fred Andrews)
Date: Fri, 23 Nov 2012 11:25:05 +0000
Subject: [whatwg] Feedback on Web Worker specification
In-Reply-To: <BLU002-W192688BFED71612C5A9B775AA540@phx.gbl>
References: <BLU002-W1847886B307CB6443DF454FAA660@phx.gbl>, ,
	<op.wnajt9jlidj3kv@dhcp26-236.enst.fr>, ,
	<BLU002-W207ECA3296A6889DA9C1E40AA640@phx.gbl>, ,
	<CAArhhisuBCm13NzEfWxMyDwuBjVTJaNoozMeCTntTtoRJ4CsEw@mail.gmail.com>,
	, <BLU002-W147F9FEEEA6218FC696F05FAA6B0@phx.gbl>, ,
	<CAArhhitgJawaJVu9BNF4940Tst3Vuco64VhhLw5q=XgyqgbXZw@mail.gmail.com>,
	, <Pine.LNX.4.64.1211202302220.26354@ps20323.dreamhostps.com>, ,
	<CAO9Q3iLuGjctfwiePwU2y2MFRhUUQ=9vw41YHTc0JJe99TQZQg@mail.gmail.com>,
	<BLU002-W192688BFED71612C5A9B775AA540@phx.gbl>
Message-ID: <BLU002-W200BEF45CC8474FBCDD0C7CAA5A0@phx.gbl>

> From: fredandw at live.com
...
> Thank you for the suggestion.  Using the <script> element seems like a good
> approach to explore.
> 
> Overloading the 'type' attribute could be problematic because the script type
> may well be orthogonal to the JS context to which the script applies.  Could I
> suggest a new attribute, for example 'context' that declares the script context.

Just to follow up.  Perhaps I understand now why you suggested a different
'type' - so that the script is not interpreted as javascript by legacy browsers.

It would not seem appropriate for a legacy browser to load script intended
for a worker into the document JS context.  While it might be possible to
write code that works in both contexts, it would seem too much of a burden
on the programmer.

So it would seem that overloading the script element 'type' attribute would be
a possible solution if it were really necessary to support inline script for workers.
If it were not necessary to supporting inline script then a 'meta' or 'link' element
might be more appropriate declarative markup for starting workers.

cheers
Fred

From shadow2531 at gmail.com  Fri Nov 23 06:33:06 2012
From: shadow2531 at gmail.com (Michael A. Puls II)
Date: Fri, 23 Nov 2012 09:33:06 -0500
Subject: [whatwg] Checkboxes that control other checkboxes
In-Reply-To: <Pine.LNX.4.64.1211220047421.15705@ps20323.dreamhostps.com>
References: <CANEus2rzPK9GJr7bLr2cq0wnONxz3mve2j_Nbo5kbC5NqiEM8w@mail.gmail.com>
	<Pine.LNX.4.64.1211220047421.15705@ps20323.dreamhostps.com>
Message-ID: <op.wn8ddgai1ejg13@vertiform346>

On Wed, 21 Nov 2012 19:51:39 -0500, Ian Hickson <ian at hixie.ch> wrote:

> On Sun, 14 Aug 2011, Timo Beermann wrote:
>>
>> It should be able to implemet checkboxes, where by only
>> activating/deactivating this single checkbox you can active/deactivate
>> multiple other checkboxes. That is possible with scripting today, but it
>> should be possible without scripting, only with HTML/CSS. Because some
>> users deactivate Scripting (for security or whatever other reason) and
>> on other computers (school, university, work,...) you are not able to
>> change the settings, even if you want to. E.g. I use NoScript and only
>> allow scripting on very few trusted sites, that really need it.
>
> I haven't added this yet, but it is already logged as a possible future
> extension, so it's possible it may be added in the future.
>
> What would be helpful though is examples of sites that do this kind of
> thing, so that we can study how necessary it is, and how to implement it.
> For instance, are the dependent fields always in a <fieldset>? Are they
> always other checkboxes? Is there more complex logic than just "check box
> A is checked so those controls are enabled"?

My non-web use-case is with  
<https://addons.opera.com/en/extensions/details/gmail-compose/?display=en>  
(options.html in the unzipped package). I *disable* a checkbox when  
another checkbox is checked. I just use addEventListener('input') and  
check for e.target.checked to decide what to do.

However, it'd be cool if there were @disables and @enables for checkboxes  
(at least) where you can specify a list of controls (that match @name I  
guess). Those controls would still fire 'input' and 'change'.

In my case, since I'm already using JS, it's no biggie, but it'd still be  
cool to do that part without JS.

-- 
Michael

From chris at lookout.net  Fri Nov 23 11:39:00 2012
From: chris at lookout.net (Chris Weber)
Date: Fri, 23 Nov 2012 11:39:00 -0800
Subject: [whatwg] URL testing
Message-ID: <50AFD0D4.6070207@lookout.net>

Hello, I've been trying to follow Anne's work with the URL spec, and
working on using the W3C testharness.js for URL testing.  I have some
URL testing running, with still more work to do:

http://www.lookout.net/test/url/

The test cases and harness are available at:

https://github.com/cweb/url-testing

I've aggregated about 600 test cases and their expected results from
several sources, and converted them into JSON format (urls.json).  A
majority come from Webkit's fast/url suite as referenced in the
urls.json file.  A few test cases had to be modified to suit JSON, but
not many.

If this is of use to you I'm happy to hear your suggestions and make
adjustments to the test cases, format, or approach.  I do have plans to
narrate each test case with a descriptive comment, reduce duplication,
and add more distinct cases.

Another goal I have is to look beyond the DOM, and capture a test case's
resultant HTTP request as it appears on the wire, or at the server.
Capturing the HTTP request would make it possible to compare a test
case's path, query, and hostname components in the HTTP GET request,
with he DOM's representation of the same test case - to find
discrepancies between the two.

Best regards,
Chris

From ian at hixie.ch  Fri Nov 23 14:01:30 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 23 Nov 2012 22:01:30 +0000 (UTC)
Subject: [whatwg] HTML5 video seeking
In-Reply-To: <CAAWBYDDk_hLXD1E3LyTke955+c=jzZBEKu+YfdAhTb+8PDAJrA@mail.gmail.com>
References: <CAEHyr+ZgCOhCdH2-i4ryBxDmfV3uTGoV2d5QDmyH7eJVFdJ1KQ@mail.gmail.com>
	<CAAWBYDDk_hLXD1E3LyTke955+c=jzZBEKu+YfdAhTb+8PDAJrA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211232139480.15705@ps20323.dreamhostps.com>

On Mon, 14 Nov 2011, Aaron Colwell wrote:
> 
> I was looking at the seeking algorithm and had a question about step 10.
> 
># 10. Wait until the user agent has established whether or not the media 
># data for the new playback position is available, and, if it is, until 
># it has decoded enough data to play back that position.
> 
> Does this mean the user agent must resume playback at the exact location 
> specified?

Since you asked this question, the spec has been updated to explicitly 
support, in certain cases, approximate seeking. The answer, therefore, is 
now "yes, unless the approximate-for-speed flag is set". The flag gets set 
by the fastSeek() method, and optionally by native seek bars.

> What if the nearest keyframe is several seconds away? Is the UA expected 
> to decode and toss the frames instead of starting playback at the 
> nearest keyframe?

Yes.

> On desktop machines I don't think this would be a problem, but on mobile 
> devices it might be since the hardware may not be able to decode 
> significantly faster than realtime. What is the intended behavior for 
> such constrained devices?

Same as for desktop.

Having said that:

On Mon, 14 Nov 2011, Ralph Giles wrote:
> 
> Maybe you can muck with the 'media.seekable' TimeRanges object to only 
> show keyframes?

This would indeed be a plausible solution.

On Tue, 15 Nov 2011, Aaron Colwell wrote:
> 
> Yeah I thought about this, but it seems a little hacky and not what the 
> spec intended for seekable.

Well, it's really intended for cases where the format simply has no way to 
seek to the given position, but if you don't want to implement seeking to 
a particular position, then you don't have to, so long as you don't 
include it in seekable.

This is a quality of implementation feature. The idea UA would cache all 
incoming data and implement instantaneous arbitrary seeking and still 
miraculously use no memory, but real implementations have to make 
tradeoffs. The media element feature exposes a number of ways for authors 
to detect those tradeoffs; one of them is "seekable".

On Wed, 16 Nov 2011, Ralph Giles wrote:
> 
> Video splicing/mixing was a use case we wanted to support, and such 
> applications aren't really possible without frame-accurate seeking. 
> Thus, it's better to require it up front and possibly allow applications 
> to relax it later, as with Frank and Philip's 'strict' attribute, than 
> to disallow such applications by leaving this to implementation 
> variance.

Right, exactly. The seekable attribute can be used to indicate that this 
isn't supported, so that the author can detect such implementations, but I 
would indeed not expect authors to like such an implementation.

On Thu, 17 Nov 2011, Philip J??genstedt wrote:
> On Wed, 16 Nov 2011 19:36:26 +0100, Frank Galligan 
> <fgalligan at google.com> wrote:
> > Here is another link where Ian mentions that the seek should be the 
> > exact frame. 
> > http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017225.html 
> > This came up from 2 years ago, where I wanted to add an optional 
> > "strict" parameter to the seek call, which would default to false. 
> > Exactly the same as what Philip suggested. I'm all for it.
> > 
> > I think Chrome added frame accurate seeking in version 7.
> 
> I filed http://www.w3.org/Bugs/Public/show_bug.cgi?id=14851 to see if we 
> can make this happen.

This ended up resulting in fastSeek();

On Fri, 13 Jan 2012, Hugh Guiney wrote:
>
> I'm currently creating a custom HTML video player UI. What I'm trying to 
> achieve is a seek bar control?a horizontal slider that allows the user 
> to seek to a specific point in time. Right now the basic functionality 
> of this can be achieved using a range input with a max value set to the 
> video's duration, and which sets the video's currentTime onchange. 
> However, there are two problems with this:
> 
> The first is that I'd like to be able to show the user, before selecting 
> a point in the range, what point they are about to seek to. At present, 
> even if there is an element that exposes currentTime to the user, 
> there's no way to show them what currentTime *will* be until they 
> actually select a point on the range. Although I realize range inputs 
> are meant to be imprecise, it's often helpful to be able to see more 
> precise values one at a time, so that if there is a value they're aiming 
> for, they can find it or get close enough with less trial and error than 
> blind selection.
>
> It has become a ubiquitous UI convention on the Web to provide time code 
> and/or frame previews in a tooltip as the user scans the seek bar (but 
> before seeking). This can be seen for example on YouTube, Vimeo, Hulu, 
> blip.tv, Brightcove, Firefox, and many JS library players. And although 
> the effect is most common in video players, it would be helpful in audio 
> players, or any other situation where a user wants to browse available 
> options within a range without committing to any right away and 
> triggering an unwanted action.
>
> The second problem is that at present, range inputs are not quite
> sufficient semantically for marking up seek bars. Seek bars typically
> display not only a thumb, but also a progress bar that displays what
> percentage of the video is loaded. Obviously, we have <progress> for this,
> and so theoretically one could use both a range input and a progress bar
> together, this falls short for a few reasons: [...]

There's basically two ways we can address this:

1. Extend <input type=range> and <progress> to support more complicated 
UIs, e.g. including data in the range control to visualise buffering, 
playback, etc; having a way to provide a tooltip; having a way to have 
more careful positioning like YouTube's seek bar on long videos; having a 
way to get information about the position the user is hovering over before 
the user clicks; etc.

2. Have something like Web Components, enabling authors to create custom 
widgets that support whatever they want.

I expect we'll do both, on the long term. However, on the short term, I 
think we should delay #1 until we have much better implementations of the 
current widgets in all the major browsers. #2 is ongoing, but might take a 
long time also.

So in the meantime, you're kind of stuck without a good solution. Sorry. I 
would recommend going to the old standby, <div>s and lots of CSS, script, 
and ARIA attributes (this is what ARIA is useful for!).

From ian at hixie.ch  Fri Nov 23 14:14:15 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 23 Nov 2012 22:14:15 +0000 (UTC)
Subject: [whatwg] <canvas> and high-density displays
In-Reply-To: <CABirCh9_rDG8Wyd=u50VrU_+zpB0_tAYjN+KfgS97-6Qkutwog@mail.gmail.com>
References: <20120416204043.70B74200210@homiemail-mx22.g.dreamhost.com>
	<Pine.LNX.4.64.1209241911530.27765@ps20323.dreamhostps.com>
	<CABirCh9_rDG8Wyd=u50VrU_+zpB0_tAYjN+KfgS97-6Qkutwog@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211232213180.15705@ps20323.dreamhostps.com>

On Mon, 24 Sep 2012, Glenn Maynard wrote:
> On Mon, Sep 24, 2012 at 6:40 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > We could add an event that fires on ImageData (or even ArrayBuffer) 
> > that fires when the data is available. If we add it to ArrayBuffer 
> > it's something that could be used in other contexts, too.
> >
> > Is this something that people think we should do? If so, should we add 
> > it to TypedArray generically?
> 
> If it's done this way, a nonblocking function may be needed to request 
> that the event be fired, without the blocking side-effects of actually 
> performing a pixel read.  Otherwise, implementations that don't perform 
> the readback at all until it knows it's really needed (eg. that it can't 
> be done with an in-GPU blit) would simply never fire the event at all. 
> Passing in a callback probably makes more sense this way than having it 
> request that an event be fired.
> 
> That would also allow waiting for readability without knowing in advance 
> whether the event was already fired or not, which would be important eg. 
> if you just received the ArrayBuffer in a message. (An attribute could 
> do this as well, but that might be more prone to developer error.)

Indeed.

If this is something that people want to follow up on, I recommend 
suggesting it to the WebGL mailing list where Typed Array lives. I don't 
think it makes sense for us to do a version just for canvas.

From ian at hixie.ch  Fri Nov 23 14:36:08 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 23 Nov 2012 22:36:08 +0000 (UTC)
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
Message-ID: <Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>

On Fri, 21 Sep 2012, Tyler Larson wrote:
> On Sep 20, 2012, at 6:49 PM, Ian Hickson <ian at hixie.ch> wrote:
> > Can't you do this using clip() easily enough? Maybe I'm missing 
> > something important here. Can you elaborate?
> 
> Here is an example of what I am talking about. 
> http://i.imgur.com/Sy4xM.png
> Clip would mask something but adding an inner shadow is different and 
> pretty difficult to reproduce when you take into account complex shapes.

Ah, yeah, I see what you mean. The problem is that the canvas rendering 
model always renders the shadow under the shape, and uses the shape's 
alpha to work out where to paint the shape.

What we could do is offer control that would change the shadows from 
rendering under the shape to rendering over the shape, or, maybe even 
better, have a mode that only renders the shadows. Then you could achieve 
these effects relatively easily (by clipping to the shape so that the 
shadow only renders inside the shape).

Is this something implementors would be interested in?

From ian at hixie.ch  Fri Nov 23 15:04:11 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 23 Nov 2012 23:04:11 +0000 (UTC)
Subject: [whatwg]  Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>

On Thu, 29 Mar 2012, Jeremy Apthorp wrote:
> On Thu, Mar 29, 2012 at 10:25 AM, Jeremy Apthorp <jeremya at chromium.org>wrote:
> > On Thu, Mar 29, 2012 at 8:41 AM, Ian Hickson <ian at hixie.ch> wrote:
> >> On Fri, 13 Jan 2012, Jeremy Apthorp wrote:
> >> >
> >> > I'd like to draw non-antialiased lines in a <canvas>. Currently it 
> >> > seems that the only way to do this is to directly access the pixel 
> >> > data.
> >> >
> >> > Is there a reason there's no way to turn off antialiasing?
> >>
> >> What's the use case?
> >
> > Pixel-art style games.
> 
> Specifically: even with the new image smoothing stuff in place for 
> drawImage, a 1:2 diagonal line will still be anti-aliased (only the 
> antialiasing will look silly scaled up to 2x).

Do you have an example of a game where lines are drawn using a line API 
without antialiasing, then scaled up? Most "pixel art" games I've seen 
tend to use bitmaps for that kind of thing.

On Mon, 12 Nov 2012, Justin Novosad wrote:
> 
> For many types of apps, DOM-based rendering is uncompetitively slow
> [so we should make text rendering in canvas more controllable]

This seems like something we should fix, not something we should work 
around by having people use canvas instead. Using canvas has all kinds of 
terrible side-effects, like reducing the likely accessibility of the page, 
making searcheability much worse, etc.

Also, do you have any metrics showing the magnitude of this problem on 
real-world sites that might consider using canvas instead?

> If LCD text were enable-able, authors would have to be mindful of a 
> number of caveats in order to avoid rendering artifacts.

Do we have any reason to believe the majority of authors would make the 
right decisions here?

(The main reason we haven't provided control over things like antialiasing 
is that many authors tend to make terribly bad decisions.) (Before anyone 
gets offended, by the way: that you are reading this almost guarantees 
that you are above average in terms of authoring ability.)

On Tue, Nov 13, 2012 at 9:37 PM, Robert O'Callahan wrote:
>
> We'd have to define what happens when you use subpixel antialiasing 
> "incorrectly", because we can be pretty sure authors will use it 
> incorrectly and expect to get interoperable behavior.

That's certainly true.

> Mozilla supports a "mozOpaque" attribute which makes the canvas buffer 
> RGBX (initialized to solid black) and enables subpixel antialiasing for 
> most text drawing. That might be enough to address your use-cases.

I haven't specified this; if other vendors intend to implement this let me 
know and I can spec it. I'm not sure it's worth it though.

On Wed, 14 Nov 2012, Robert O'Callahan wrote:
> On Wed, Nov 14, 2012 at 8:09 AM, Justin Novosad <junov at chromium.org> wrote:
> > 
> > Are there precedents for exposing features with documented caveats? 
> > (excluding caveats that were discovered after the fact)
> 
> Yes, and many of them have been extremely problematic, because Web 
> authors will ignore the caveats.

Right. I'd really like to avoid adding more if we can help it.

On Wed, 14 Nov 2012, Justin Novosad wrote:
> 
> There is a recent improvement in Chrome called "deferred 2D canvas 
> rendering" (enabled by default as of Chrome 23).  It is a mechanism that 
> records 2d canvas commands during JS execution, and only executes them 
> for real when the render buffer needs to be resolved (draw to screen, 
> getImageData, toDataURL, etc.).  If you want to check it out, the guts 
> are in Skia: SkGPipe is a sort of FIFO for graphics commands, 
> SkDeferredCanvas is a wrapper that manages the GPipe and automatically 
> flushes it and applies some command culling optimizations.
> 
> So to come back to the problem of with and without subpixel AA buffers: 
> if rendering is deferred, the non-AA buffer would never get rasterized 
> (and possibly never even allocated), unless it needs to be.  Obviously 
> there are practical limitations, for example we cannot store an 
> unlimited stream of recorded commands, so if the canvas draws 
> indefinitely without ever being cleared, at some point we have to 
> rasterize the non-AA buffer just so that we can safely discard the 
> recording data. Also, if at record time the necessary conditions for 
> subpixel AA are not met, perhaps we just forget about it.
> 
> I admit this is a complex solution for implementors, but it makes the 
> management of subpixel-AA safety transparent to web authors.

I think it'd be reasonable (for some definition of reasonable that 
relates to whether it's compatible with the spec, anyway) for implementors 
to do this today, without having to expose any control to the author.

On Thu, 15 Nov 2012, Fred Andrews wrote:
> 
> The canvas that scripts draw into could be over-sized with the UA down 
> sampling this to fit the target size and taking into account the 
> sub-pixel screen layout when doing so.

On Thu, 15 Nov 2012, Justin Novosad wrote:
>
> Obviously, that would be costly (x3 pixels), but I think it is a very 
> realistic solution and relatively low hanging fruit. The over-sizing of 
> the canvas would have to be handled under the hood by the UA though, 
> because it depends on LCD component ordering and orientation, which 
> means querying the OS/display driver. A lot of the kinks with the 
> over-sized canvas approach have already been ironed out for solving the 
> problem of High-DPI support ( put/getImageDataHD ), and I like the idea 
> of unifying the two. Implementing this would mostly be a matter of 
> adding per color component compositing of canvases. Also, the pixel 
> aspect ratio would have to be taken into account for line drawing.

getImageDataHD() requires that the pixels be square, but so long as that 
is taken into consideration (e.g. by dropping down to square pixels if the 
author calls putImageDataHD()) I think this could probably be made to work 
within the spec's current requirements.

> Regarding the concerns about accessibility, I think the problem can be 
> solved by using HitRegions with labels.

Oh it _can_ be solved. That's not the problem. Accessibility is not about 
what is _possible_, it's about what actually _is_. Most authors, 
realistically speaking, aren't goin to be using hit regions sufficiently 
for us to declare victory here.

> Come to think of it, there should be an option to make the UA do this 
> automatically: create a HitRegion with a label every time text is drawn 
> to a canvas.

I considered doing that, but it gets really fiddly when you're doing 
things like text that fades over multiple frames. In the end I decided 
that the magic wasn't worth it, as it would likely screw up more often 
than it would actually help.

From cabanier at gmail.com  Fri Nov 23 15:38:41 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 23 Nov 2012 15:38:41 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
Message-ID: <CAGN7qDB4-3CH8DMcGqpMGch85Ts-jU0zhEax4JAezzchXt2iAQ@mail.gmail.com>

On Fri, Nov 23, 2012 at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 21 Sep 2012, Tyler Larson wrote:
> > On Sep 20, 2012, at 6:49 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > Can't you do this using clip() easily enough? Maybe I'm missing
> > > something important here. Can you elaborate?
> >
> > Here is an example of what I am talking about.
> > http://i.imgur.com/Sy4xM.png
> > Clip would mask something but adding an inner shadow is different and
> > pretty difficult to reproduce when you take into account complex shapes.
>
> Ah, yeah, I see what you mean. The problem is that the canvas rendering
> model always renders the shadow under the shape, and uses the shape's
> alpha to work out where to paint the shape.
>
> What we could do is offer control that would change the shadows from
> rendering under the shape to rendering over the shape, or, maybe even
> better, have a mode that only renders the shadows. Then you could achieve
> these effects relatively easily (by clipping to the shape so that the
> shadow only renders inside the shape).
>

It would still be quite complex to draw an inner shadow this way because
the blur is calculated on the inverse of the shape.
A user will need to draw to another canvas and then 'clear' it to get the
inverse.

However, I like the fact that this is a primitive that can be used to
create other effects.

>
> Is this something implementors would be interested in?

It seems like this would be easy for them to implement...

From glenn at zewt.org  Fri Nov 23 15:47:06 2012
From: glenn at zewt.org (Glenn Maynard)
Date: Fri, 23 Nov 2012 17:47:06 -0600
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CAGN7qDDwnd0x0SFgbbmWToyfEmi1oVKcnu_hgP6KhU-o1jyXaQ@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<CAGN7qDDwnd0x0SFgbbmWToyfEmi1oVKcnu_hgP6KhU-o1jyXaQ@mail.gmail.com>
Message-ID: <CABirCh-2SVhtbV53Nvnk_thr9xEhLFZ1A=V1A_qNC6nYi-UStA@mail.gmail.com>

On Fri, Sep 21, 2012 at 7:49 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> With both types of shadow, you take the shape of the element and calculate
> the blur image.
>
> With an outer shadow, you take the result of the blur and composite it.
> After this, you composite the original shape.
> With an inner shadow, you draw the shape first followed by the blur image.
> Importantly, the blur image also needs to clipped by the shape before it is
> composited.
>

Also, the blurred image's alpha is inverted.

-- 
Glenn Maynard

From dschulze at adobe.com  Fri Nov 23 15:49:53 2012
From: dschulze at adobe.com (Dirk Schulze)
Date: Fri, 23 Nov 2012 15:49:53 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
Message-ID: <C7E8EB76-CDC6-4403-B5F3-CC306DEDB242@adobe.com>

On Nov 23, 2012, at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 21 Sep 2012, Tyler Larson wrote:
>> On Sep 20, 2012, at 6:49 PM, Ian Hickson <ian at hixie.ch> wrote:
>>> Can't you do this using clip() easily enough? Maybe I'm missing 
>>> something important here. Can you elaborate?
>> 
>> Here is an example of what I am talking about. 
>> http://i.imgur.com/Sy4xM.png
>> Clip would mask something but adding an inner shadow is different and 
>> pretty difficult to reproduce when you take into account complex shapes.
> 
> Ah, yeah, I see what you mean. The problem is that the canvas rendering 
> model always renders the shadow under the shape, and uses the shape's 
> alpha to work out where to paint the shape.
> 
> What we could do is offer control that would change the shadows from 
> rendering under the shape to rendering over the shape, or, maybe even 
> better, have a mode that only renders the shadows. Then you could achieve 
> these effects relatively easily (by clipping to the shape so that the 
> shadow only renders inside the shape).

Dependent if Canvas supports Filter Effects in the future or not (including SVG filters), the overlay shadow can be done with a combination of SourceAlpha and gaussian blur. There are already Canvas libraries that offer SVG Filters on Canvas.

Greetings,
Dirk

> 
> Is this something implementors would be interested in?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From ian at hixie.ch  Fri Nov 23 15:57:56 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 23 Nov 2012 23:57:56 +0000 (UTC)
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
Message-ID: <Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>

On Fri, 23 Nov 2012, Ian Hickson wrote:
> On Fri, 21 Sep 2012, Tyler Larson wrote:
> > On Sep 20, 2012, at 6:49 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > Can't you do this using clip() easily enough? Maybe I'm missing 
> > > something important here. Can you elaborate?
> > 
> > Here is an example of what I am talking about. 
> > http://i.imgur.com/Sy4xM.png
> > Clip would mask something but adding an inner shadow is different and 
> > pretty difficult to reproduce when you take into account complex shapes.
>
> Ah, yeah, I see what you mean.

I was wrong, I didn't see what you mean. Turns out it's relatively easy to 
do today in canvas; after you've drawn your shape and filled it, just add 
the following code:

c.save();
  c.clip();
  c.moveTo(0,0);
  c.lineTo(0,height);
  c.lineTo(width,height);
  c.lineTo(width,0);
  c.closePath();
  c.shadowColor = 'black';
  c.shadowBlur = 30;
  c.fill();
  c.restore();

From cabanier at gmail.com  Fri Nov 23 15:58:40 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 23 Nov 2012 15:58:40 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CABirCh-2SVhtbV53Nvnk_thr9xEhLFZ1A=V1A_qNC6nYi-UStA@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<CAGN7qDDwnd0x0SFgbbmWToyfEmi1oVKcnu_hgP6KhU-o1jyXaQ@mail.gmail.com>
	<CABirCh-2SVhtbV53Nvnk_thr9xEhLFZ1A=V1A_qNC6nYi-UStA@mail.gmail.com>
Message-ID: <CAGN7qDDSBkkvroxt+nnjNDSYP2T7Kv0E6bL7PM0UoCg=d=mApQ@mail.gmail.com>

On Fri, Nov 23, 2012 at 3:47 PM, Glenn Maynard <glenn at zewt.org> wrote:

> On Fri, Sep 21, 2012 at 7:49 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> With both types of shadow, you take the shape of the element and calculate
>> the blur image.
>>
>> With an outer shadow, you take the result of the blur and composite it.
>> After this, you composite the original shape.
>> With an inner shadow, you draw the shape first followed by the blur image.
>> Importantly, the blur image also needs to clipped by the shape before it
>> is
>> composited.
>>
>
> Also, the blurred image's alpha is inverted.
>
>
You're right. It's not 'clear' for the compositing more, but 'source-out'

From ian at hixie.ch  Fri Nov 23 16:03:25 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 24 Nov 2012 00:03:25 +0000 (UTC)
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <C7E8EB76-CDC6-4403-B5F3-CC306DEDB242@adobe.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<C7E8EB76-CDC6-4403-B5F3-CC306DEDB242@adobe.com>
Message-ID: <Pine.LNX.4.64.1211232358100.29456@ps20323.dreamhostps.com>

On Fri, 23 Nov 2012, Rik Cabanier wrote:
> 
> It would still be quite complex to draw an inner shadow this way because
> the blur is calculated on the inverse of the shape.
> A user will need to draw to another canvas and then 'clear' it to get the
> inverse.

Turns out it's much easier than that; see my e-mail just now.

> > Is this something implementors would be interested in?
> 
> It seems like this would be easy for them to implement...

That's not really the question. :-)

There's a cost to every feature. We have to prioritise.

From cabanier at gmail.com  Fri Nov 23 16:13:28 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 23 Nov 2012 16:13:28 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <Pine.LNX.4.64.1211232358100.29456@ps20323.dreamhostps.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<C7E8EB76-CDC6-4403-B5F3-CC306DEDB242@adobe.com>
	<Pine.LNX.4.64.1211232358100.29456@ps20323.dreamhostps.com>
Message-ID: <CAGN7qDCfvLTvMOLQsJH+DpVbxyDmQuq_mZ+_7cHYxwdZKj2rNA@mail.gmail.com>

On Fri, Nov 23, 2012 at 4:03 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 23 Nov 2012, Rik Cabanier wrote:
> >
> > It would still be quite complex to draw an inner shadow this way because
> > the blur is calculated on the inverse of the shape.
> > A user will need to draw to another canvas and then 'clear' it to get the
> > inverse.
>
> Turns out it's much easier than that; see my e-mail just now.
>

No. You don't want to see a black shadow with blurred edges.
For an 'inner' shadow, the shadow image sits outside the shape so you have
to calculate that.

>
>
> > > Is this something implementors would be interested in?
> >
> > It seems like this would be easy for them to implement...
>
> That's not really the question. :-)
>
> There's a cost to every feature. We have to prioritise.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

From ian at hixie.ch  Fri Nov 23 16:21:03 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 24 Nov 2012 00:21:03 +0000 (UTC)
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CAGN7qDCfvLTvMOLQsJH+DpVbxyDmQuq_mZ+_7cHYxwdZKj2rNA@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<C7E8EB76-CDC6-4403-B5F3-CC306DEDB242@adobe.com>
	<Pine.LNX.4.64.1211232358100.29456@ps20323.dreamhostps.com>
	<CAGN7qDCfvLTvMOLQsJH+DpVbxyDmQuq_mZ+_7cHYxwdZKj2rNA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211240020380.29456@ps20323.dreamhostps.com>

On Fri, 23 Nov 2012, Rik Cabanier wrote:
> On Fri, Nov 23, 2012 at 4:03 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 23 Nov 2012, Rik Cabanier wrote:
> > >
> > > It would still be quite complex to draw an inner shadow this way 
> > > because the blur is calculated on the inverse of the shape. A user 
> > > will need to draw to another canvas and then 'clear' it to get the 
> > > inverse.
> >
> > Turns out it's much easier than that; see my e-mail just now.
> 
> No. You don't want to see a black shadow with blurred edges. For an 
> 'inner' shadow, the shadow image sits outside the shape so you have to 
> calculate that.

I don't follow. Why would you see a black shadow?

Do you have an example of what you mean?

From cabanier at gmail.com  Fri Nov 23 19:52:53 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 23 Nov 2012 19:52:53 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
Message-ID: <CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>

On Fri, Nov 23, 2012 at 3:57 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 23 Nov 2012, Ian Hickson wrote:
> > On Fri, 21 Sep 2012, Tyler Larson wrote:
> > > On Sep 20, 2012, at 6:49 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > > Can't you do this using clip() easily enough? Maybe I'm missing
> > > > something important here. Can you elaborate?
> > >
> > > Here is an example of what I am talking about.
> > > http://i.imgur.com/Sy4xM.png
> > > Clip would mask something but adding an inner shadow is different and
> > > pretty difficult to reproduce when you take into account complex
> shapes.
> >
> > Ah, yeah, I see what you mean.
>
> I was wrong, I didn't see what you mean. Turns out it's relatively easy to
> do today in canvas; after you've drawn your shape and filled it, just add
> the following code:
>
>   c.save();
>   c.clip();
>   c.moveTo(0,0);
>   c.lineTo(0,height);
>   c.lineTo(width,height);
>   c.lineTo(width,0);
>   c.closePath();
>   c.shadowColor = 'black';
>   c.shadowBlur = 30;
>   c.fill();
>   c.restore();

I don't think that will work.
Shadows are calculated before clipping [1] so they don't follow the
clipping path.

Even if it was right, it would only apply to shapes and only if those
shapes didn't have strokes and were completely opaque.

1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-model

From ian at hixie.ch  Fri Nov 23 20:58:53 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 24 Nov 2012 04:58:53 +0000 (UTC)
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>

On Fri, 23 Nov 2012, Rik Cabanier wrote:
> >
> > Turns out it's relatively easy to do today in canvas; after you've 
> > drawn your shape and filled it, just add the following code:
> >
> >   c.save();
> >   c.clip();
> >   c.moveTo(0,0);
> >   c.lineTo(0,height);
> >   c.lineTo(width,height);
> >   c.lineTo(width,0);
> >   c.closePath();
> >   c.shadowColor = 'black';
> >   c.shadowBlur = 30;
> >   c.fill();
> >   c.restore();
> 
> I don't think that will work. Shadows are calculated before clipping so 
> they don't follow the clipping path.

What matters is how they're painted, and that does follow the clipping 
path, as far as I can tell (step 4 of the drawing model).

> Even if it was right, it would only apply to shapes and only if those 
> shapes didn't have strokes and were completely opaque.

That's easy enough, though, you only need to make a shape that is what you 
want the inner shadow to go over, and then set the fill to black (or 
anything completely opaque). It's even easier with the new Path primitives 
since you can construct a combined path by stroking them all into one.

From cabanier at gmail.com  Fri Nov 23 21:11:57 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Fri, 23 Nov 2012 21:11:57 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
	<Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
Message-ID: <CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>

On Fri, Nov 23, 2012 at 8:58 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 23 Nov 2012, Rik Cabanier wrote:
> > >
> > > Turns out it's relatively easy to do today in canvas; after you've
> > > drawn your shape and filled it, just add the following code:
> > >
> > >   c.save();
> > >   c.clip();
> > >   c.moveTo(0,0);
> > >   c.lineTo(0,height);
> > >   c.lineTo(width,height);
> > >   c.lineTo(width,0);
> > >   c.closePath();
> > >   c.shadowColor = 'black';
> > >   c.shadowBlur = 30;
> > >   c.fill();
> > >   c.restore();
> >
> > I don't think that will work. Shadows are calculated before clipping so
> > they don't follow the clipping path.
>
> What matters is how they're painted, and that does follow the clipping
> path, as far as I can tell (step 4 of the drawing model).
>

What matters is the shape that is used to calculate the blur (step 1)
In your example, that shape is a rectangle so just the rectangle edges will
be blurred.
That slightly blurred rectangle is then composited with the clipping region
in step 4.

The end result is a solid rectangle in the shadowcolor that composites on
top of the shape.

>
>
> > Even if it was right, it would only apply to shapes and only if those
> > shapes didn't have strokes and were completely opaque.
>
> That's easy enough, though, you only need to make a shape that is what you
> want the inner shadow to go over, and then set the fill to black (or
> anything completely opaque).

How about the strokes?

> It's even easier with the new Path primitives
> since you can construct a combined path by stroking them all into one.
>
>
Unfortunately, the current path logic does not support unions.
It just does path accumulation which will not give you the desired result.

From mike at w3.org  Fri Nov 23 22:11:27 2012
From: mike at w3.org (Michael[tm] Smith)
Date: Sat, 24 Nov 2012 15:11:27 +0900
Subject: [whatwg] URL testing
In-Reply-To: <50AFD0D4.6070207@lookout.net>
References: <50AFD0D4.6070207@lookout.net>
Message-ID: <20121124061126.GC5064@sideshowbarker>

Chris Weber <chris at lookout.net>, 2012-11-23 11:39 -0800:

> Hello, I've been trying to follow Anne's work with the URL spec, and
> working on using the W3C testharness.js for URL testing.  I have some
> URL testing running, with still more work to do:
> 
> http://www.lookout.net/test/url/

A lot of these tests -- e.g., test "64" and most all of the "host" tests
after that -- seem to be failing not because of the specific cases they're
testing but because of a common failure caused by that fact that the URL
being tested has no pathname -- and so the expected URL should have no
pathname -- but the actual URL has a "/" appended.

I wonder if it might make more sense for the URLs being tested for all
those cases to include a "/" for the pathname. That way they would be
further isolated to just testing what they're actually intended to test,
rather that what they're instead inadvertently testing currently (the
problem of the "/" being appended).

Then, separate test or tests could be added that are isolated to just
testing whether a "/" gets appended to a pathless URL.

> The test cases and harness are available at:
> 
> https://github.com/cweb/url-testing

I've sent a pull request with the changes described above.

--Mike

-- 
Michael[tm] Smith http://people.w3.org/mike

From ian at hixie.ch  Fri Nov 23 22:30:45 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 24 Nov 2012 06:30:45 +0000 (UTC)
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
	<Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
	<CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211240626180.29456@ps20323.dreamhostps.com>

On Fri, 23 Nov 2012, Rik Cabanier wrote:
> On Fri, Nov 23, 2012 at 8:58 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 23 Nov 2012, Rik Cabanier wrote:
> > > >
> > > > Turns out it's relatively easy to do today in canvas; after you've
> > > > drawn your shape and filled it, just add the following code:
> > > >
> > > >   c.save();
> > > >   c.clip();
> > > >   c.moveTo(0,0);
> > > >   c.lineTo(0,height);
> > > >   c.lineTo(width,height);
> > > >   c.lineTo(width,0);
> > > >   c.closePath();
> > > >   c.shadowColor = 'black';
> > > >   c.shadowBlur = 30;
> > > >   c.fill();
> > > >   c.restore();
> > >
> > > I don't think that will work. Shadows are calculated before clipping so
> > > they don't follow the clipping path.
> >
> > What matters is how they're painted, and that does follow the clipping
> > path, as far as I can tell (step 4 of the drawing model).
> 
> What matters is the shape that is used to calculate the blur (step 1) In 
> your example, that shape is a rectangle--

No, no, the rectangle is just added to the existing path. The code snippet 
above comes _after_ you've drawn the shape.

> > > Even if it was right, it would only apply to shapes and only if 
> > > those shapes didn't have strokes and were completely opaque.
> >
> > That's easy enough, though, you only need to make a shape that is what 
> > you want the inner shadow to go over, and then set the fill to black 
> > (or anything completely opaque).
> 
> How about the strokes?

The example in the OP didn't have them, but you'd have to include them in 
the fill area. With the new Path objects, you'd just use
addPathByStrokingPath(), which would be relatively simple.

> > It's even easier with the new Path primitives since you can construct 
> > a combined path by stroking them all into one.
>
> Unfortunately, the current path logic does not support unions. It just 
> does path accumulation which will not give you the desired result.

So long as they don't overlap, that's not generally a problem. But sure, 
for some complex shapes you'd need some new feature or other, whether it's 
in shadows or path construction or elsewhere.

From annevk at annevk.nl  Sat Nov 24 01:34:01 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Sat, 24 Nov 2012 10:34:01 +0100
Subject: [whatwg] URL testing
In-Reply-To: <50AFD0D4.6070207@lookout.net>
References: <50AFD0D4.6070207@lookout.net>
Message-ID: <CADnb78iYSgawKgBNRevOey1yTiAUSp-6TWK2k4b2vsy3kNkoQQ@mail.gmail.com>

On Fri, Nov 23, 2012 at 8:39 PM, Chris Weber <chris at lookout.net> wrote:
> If this is of use to you I'm happy to hear your suggestions and make
> adjustments to the test cases, format, or approach.  I do have plans to
> narrate each test case with a descriptive comment, reduce duplication,
> and add more distinct cases.

This is super awesome. Glad you continued with this. I have a few
generic points for now:

* No special handling for IPv4. IPv4 should work the same as domain
names. I.e. the host of http://192/ is 192, not 0.0.0.192.
* It's still a bit unclear to me what the best solution is for
fragment identifiers. Whether they should be percent escaped or not
and whether that should differ between .href and .hash.
* IDNA is a rathole.
* Ports other than 0-9 will cause a parsing failure (e.g. ? will do that).

When are you planning on doing the further cleanup you mention? At
some point I can try to go through them in detail and suggest fixes
(e.g. via a pull request).

-- 
http://annevankesteren.nl/

From mike at w3.org  Sat Nov 24 01:42:33 2012
From: mike at w3.org (Michael[tm] Smith)
Date: Sat, 24 Nov 2012 18:42:33 +0900
Subject: [whatwg] URL testing
In-Reply-To: <20121124061126.GC5064@sideshowbarker>
References: <50AFD0D4.6070207@lookout.net>
	<20121124061126.GC5064@sideshowbarker>
Message-ID: <20121124094232.GE5064@sideshowbarker>

"Michael[tm] Smith" <mike at w3.org>, 2012-11-24 15:11 +0900:

> Chris Weber <chris at lookout.net>, 2012-11-23 11:39 -0800:
> 
> > Hello, I've been trying to follow Anne's work with the URL spec, and
> > working on using the W3C testharness.js for URL testing.  I have some
> > URL testing running, with still more work to do:
> > 
> > http://www.lookout.net/test/url/
> 
> A lot of these tests -- e.g., test "64" and most all of the "host" tests
> after that -- seem to be failing not because of the specific cases they're
> testing but because of a common failure caused by that fact that the URL
> being tested has no pathname -- and so the expected URL should have no
> pathname -- but the actual URL has a "/" appended.

Anne just now pointed out to me that per the spec, those are not failures
anyway because the expected result is that a "/" gets appended even if the
URL has no path. See step 5 here:

http://url.spec.whatwg.org/#concept-url-serializer

-- 
Michael[tm] Smith http://people.w3.org/mike

From glenn at zewt.org  Sat Nov 24 07:59:26 2012
From: glenn at zewt.org (Glenn Maynard)
Date: Sat, 24 Nov 2012 09:59:26 -0600
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
	<Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
	<CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
Message-ID: <CABirCh9N7FbncNH_DaJPqb4jF4Ub7s9vRNQra77__KHqmNeEgg@mail.gmail.com>

On Fri, Nov 23, 2012 at 11:11 PM, Rik Cabanier <cabanier at gmail.com> wrote:

> What matters is the shape that is used to calculate the blur (step 1)
> In your example, that shape is a rectangle so just the rectangle edges will
> be blurred.
> That slightly blurred rectangle is then composited with the clipping region
> in step 4.
>
> The end result is a solid rectangle in the shadowcolor that composites on
> top of the shape.
>

Testing with Hixie's code (https://zewt.org/~glenn/canvas-glow.html), the
output is very close to "inner shadow" in Photoshop (distance 0, size 22):
https://zewt.org/~glenn/canvas-glow.png.

(I'm testing against inner shadow instead of inner glow; inner glow seems
to do something a little more complex at the blur step than a gaussian
blur.  Tested in Chrome 21; output in Firefox is different, but I probably
need to update.)

-- 
Glenn Maynard

From cabanier at gmail.com  Sat Nov 24 08:21:20 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 24 Nov 2012 08:21:20 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CABirCh9N7FbncNH_DaJPqb4jF4Ub7s9vRNQra77__KHqmNeEgg@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
	<Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
	<CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
	<CABirCh9N7FbncNH_DaJPqb4jF4Ub7s9vRNQra77__KHqmNeEgg@mail.gmail.com>
Message-ID: <CAGN7qDCdcvtvGLQ_K-Cy57pj8NH=eQm71FvzSfXqyg_JEQ9kEw@mail.gmail.com>

On Sat, Nov 24, 2012 at 7:59 AM, Glenn Maynard <glenn at zewt.org> wrote:

> On Fri, Nov 23, 2012 at 11:11 PM, Rik Cabanier <cabanier at gmail.com> wrote:
>
>> What matters is the shape that is used to calculate the blur (step 1)
>> In your example, that shape is a rectangle so just the rectangle edges
>> will
>> be blurred.
>> That slightly blurred rectangle is then composited with the clipping
>> region
>> in step 4.
>>
>> The end result is a solid rectangle in the shadowcolor that composites on
>> top of the shape.
>>
>
> Testing with Hixie's code (https://zewt.org/~glenn/canvas-glow.html), the
> output is very close to "inner shadow" in Photoshop (distance 0, size 22):
> https://zewt.org/~glenn/canvas-glow.png.
>

yes! I forgot that clip doesn't clear the path so his example works.

I think it's possible to calculate to calculate the reverse shadow today
with temporary backing and compositing.
If so, the function to calculate them is not really necessary though it
would be still be nice to have a direct way to do an inner shadow.

> (I'm testing against inner shadow instead of inner glow; inner glow seems
> to do something a little more complex at the blur step than a gaussian
> blur.  Tested in Chrome 21; output in Firefox is different, but I probably
> need to update.)

True. Glow is a bit more complex than a plain (but not much).
Photoshop also does a 'multiply' blend with the shadow by default which
improves the look.

From cabanier at gmail.com  Sat Nov 24 08:28:08 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 24 Nov 2012 08:28:08 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <Pine.LNX.4.64.1211240626180.29456@ps20323.dreamhostps.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
	<Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
	<CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
	<Pine.LNX.4.64.1211240626180.29456@ps20323.dreamhostps.com>
Message-ID: <CAGN7qDAJzdE1F8Jkvi3+XXtwYWOokRd04sqE3gE+wZhPTSssgA@mail.gmail.com>

On Fri, Nov 23, 2012 at 10:30 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Fri, 23 Nov 2012, Rik Cabanier wrote:
> > On Fri, Nov 23, 2012 at 8:58 PM, Ian Hickson <ian at hixie.ch> wrote:
> > > On Fri, 23 Nov 2012, Rik Cabanier wrote:
> > > > >
> > > > > Turns out it's relatively easy to do today in canvas; after you've
> > > > > drawn your shape and filled it, just add the following code:
> > > > >
> > > > >   c.save();
> > > > >   c.clip();
> > > > >   c.moveTo(0,0);
> > > > >   c.lineTo(0,height);
> > > > >   c.lineTo(width,height);
> > > > >   c.lineTo(width,0);
> > > > >   c.closePath();
> > > > >   c.shadowColor = 'black';
> > > > >   c.shadowBlur = 30;
> > > > >   c.fill();
> > > > >   c.restore();
> > > >
> > > > I don't think that will work. Shadows are calculated before clipping
> so
> > > > they don't follow the clipping path.
> > >
> > > What matters is how they're painted, and that does follow the clipping
> > > path, as far as I can tell (step 4 of the drawing model).
> >
> > What matters is the shape that is used to calculate the blur (step 1) In
> > your example, that shape is a rectangle--
>
> No, no, the rectangle is just added to the existing path. The code snippet
> above comes _after_ you've drawn the shape.
>

True. I forgot that the clip doesn't do a newpath. Sorry about that!

>
>
> > > > Even if it was right, it would only apply to shapes and only if
> > > > those shapes didn't have strokes and were completely opaque.
> > >
> > > That's easy enough, though, you only need to make a shape that is what
> > > you want the inner shadow to go over, and then set the fill to black
> > > (or anything completely opaque).
> >
> > How about the strokes?
>
> The example in the OP didn't have them, but you'd have to include them in
> the fill area. With the new Path objects, you'd just use
> addPathByStrokingPath(), which would be relatively simple.
>

Unfortunately the winding rules will mess up your shape. (non-zero winding)

Take for instance a stroked circle.
The stroke which is added with addPathByStrokingPath will always create a
hole so you end up with a donut instead of just a slightly larger circle.

>
>
> > > It's even easier with the new Path primitives since you can construct
> > > a combined path by stroking them all into one.
> >
> > Unfortunately, the current path logic does not support unions. It just
> > does path accumulation which will not give you the desired result.
>
> So long as they don't overlap, that's not generally a problem. But sure,
> for some complex shapes you'd need some new feature or other, whether it's
> in shadows or path construction or elsewhere.
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

From ian at hixie.ch  Sat Nov 24 08:36:34 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 24 Nov 2012 16:36:34 +0000 (UTC)
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CAGN7qDAJzdE1F8Jkvi3+XXtwYWOokRd04sqE3gE+wZhPTSssgA@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
	<Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
	<CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
	<Pine.LNX.4.64.1211240626180.29456@ps20323.dreamhostps.com>
	<CAGN7qDAJzdE1F8Jkvi3+XXtwYWOokRd04sqE3gE+wZhPTSssgA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211241635010.29456@ps20323.dreamhostps.com>

On Sat, 24 Nov 2012, Rik Cabanier wrote:
> > >
> > > How about the strokes?
> >
> > The example in the OP didn't have them, but you'd have to include them 
> > in the fill area. With the new Path objects, you'd just use 
> > addPathByStrokingPath(), which would be relatively simple.
> 
> Unfortunately the winding rules will mess up your shape. (non-zero 
> winding)
> 
> Take for instance a stroked circle. The stroke which is added with 
> addPathByStrokingPath will always create a hole so you end up with a 
> donut instead of just a slightly larger circle.

Right:

> > So long as they don't overlap, that's not generally a problem. But 
> > sure, for some complex shapes you'd need some new feature or other, 
> > whether it's in shadows or path construction or elsewhere.

In the case of a circle, if you wanted to draw the inner shadow over the 
stroke and the fill, you'd have to create the path as just a fill with the 
radius increased by half the line width.

From cabanier at gmail.com  Sat Nov 24 09:03:36 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 24 Nov 2012 09:03:36 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <Pine.LNX.4.64.1211241635010.29456@ps20323.dreamhostps.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
	<Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
	<CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
	<Pine.LNX.4.64.1211240626180.29456@ps20323.dreamhostps.com>
	<CAGN7qDAJzdE1F8Jkvi3+XXtwYWOokRd04sqE3gE+wZhPTSssgA@mail.gmail.com>
	<Pine.LNX.4.64.1211241635010.29456@ps20323.dreamhostps.com>
Message-ID: <CAGN7qDD9Q9_O5n1LPRpLv=1qzhg9F8_S-Q9gt-wW5e1NX1H=zg@mail.gmail.com>

On Sat, Nov 24, 2012 at 8:36 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Sat, 24 Nov 2012, Rik Cabanier wrote:
> > > >
> > > > How about the strokes?
> > >
> > > The example in the OP didn't have them, but you'd have to include them
> > > in the fill area. With the new Path objects, you'd just use
> > > addPathByStrokingPath(), which would be relatively simple.
> >
> > Unfortunately the winding rules will mess up your shape. (non-zero
> > winding)
> >
> > Take for instance a stroked circle. The stroke which is added with
> > addPathByStrokingPath will always create a hole so you end up with a
> > donut instead of just a slightly larger circle.
>
> Right:
>
> > > So long as they don't overlap, that's not generally a problem. But
> > > sure, for some complex shapes you'd need some new feature or other,
> > > whether it's in shadows or path construction or elsewhere.
>
> In the case of a circle, if you wanted to draw the inner shadow over the
> stroke and the fill, you'd have to create the path as just a fill with the
> radius increased by half the line width.
>
>
That seems like a heavy burden to place on the developer.
Hopefully there are no round joins, endcaps or dashes.

I think addPathByStrokingPath is almost useless. Those methods should all
do unions...

From nils at dieweltistgarnichtso.net  Sat Nov 24 12:19:54 2012
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sat, 24 Nov 2012 21:19:54 +0100
Subject: [whatwg] Feature Request: Media Elements as Targets for Links
Message-ID: <20121124211954.5e47c5d2@desudesudesu>

Excuse me if I am doing something wrong by submitting this by mail. I
am doing this for the first time, trying to fill in the template given
at <http://wiki.whatwg.org/wiki/Problem_Solving> as good as I could.

Use Case Description:

Linking to specific fragments of media is possible via media fragment
  URIs [1]. However, it is not possible to apply a link to embedded
  media declaratively, for example to link to a specific point in time
  for a media element on a page.

[1] <http://www.w3.org/TR/media-frags/>

- Current Limitations:

Linking to media using media fragment URIs changes browsing context.

- Current Usage and Workarounds:

1. metavid (Videos of United States Congress) uses JavaScript, even
  though they have CMML transcripts and SRT.

2. I have a podcast ?Warum nicht?? generated by a software called
  redokast. Annotations need JavaScript: Click on the timestamps.
  <http://warumnicht.dieweltistgarnichtso.net/wn-15.html>
  <https://github.com/erlehmann/redokast>

- Benefits: Declarative markup would make referring to timed
  annotations easier. Referring to a specific point in time in a podcast
  on the same comments, for example, could be possible.

Proposed Solutions:

- My Solution:
  Give HTML media elements a name attribut. Make them valid targets for
  links with a target attribut.

- Processing Model:
    Processing for media elements and the <a> element needs to change.

<http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#attr-hyperlink-target>
    Change ?The target attribute, if present, must be a valid browsing
    context name or keyword. It gives the name of the browsing context
    that will be used.? to ?The target attribute, if present, must be a
    valid browsing context name or keyword or the name of a media
    element in the current browsing context. It gives the name of the
    browsing context or media element that will be used.?

<http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks-0>
    Append after ?If the user indicated a specific browsing context when
    following the hyperlink, or if the user agent is configured to
    follow hyperlinks by navigating a particular browsing context, then
    that must be the browsing context that is navigated.? the paragraph
    ?If the user indicated a media element on the current page when
    following the hyperlink, then change the currentSrc attribute of
    the media element to the absolute URL given by the href attribute
    relative to the URL given by the currentSrc of the media element.?.

(I am unsure about relative URIs. Would we need to change only the
    media fragment, and not re-run the initialization steps? What about
    the media formats given by <source> elements?)

- Limitations
    (No idea.)

- Implementation:
    (I am not a very clever guy. Someone would need to fill this in.)

- Adoption:
    Users could easily link to parts of media resources on a page. The
    solution would be backwards compatible for existing UAs that are
    able to process media fragment URIs as long as absolute URIs are
    used. A JavaScript polyfill could be used while not all UAs support
    this feature. Consumers of web pages could easily see what a
    discussion about a media resource refers to.

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From chris at lookout.net  Sat Nov 24 14:10:12 2012
From: chris at lookout.net (Chris Weber)
Date: Sat, 24 Nov 2012 14:10:12 -0800
Subject: [whatwg] URL testing
In-Reply-To: <20121124061126.GC5064@sideshowbarker>
References: <50AFD0D4.6070207@lookout.net>
	<20121124061126.GC5064@sideshowbarker>
Message-ID: <50B145C4.9010805@lookout.net>

On 11/23/2012 10:11 PM, Michael[tm] Smith wrote:
> I wonder if it might make more sense for the URLs being tested for all
> those cases to include a "/" for the pathname. That way they would be
> further isolated to just testing what they're actually intended to test,
> rather that what they're instead inadvertently testing currently (the
> problem of the "/" being appended).
>

You're right, and it looks like this was a bug during my conversion of
the Webkit test cases which did actually concat the trailing "/" in some
tests like host.js.

> 
> I've sent a pull request with the changes described above.
>

Awesome, thank you!

-Chris

From chris at lookout.net  Sat Nov 24 14:49:08 2012
From: chris at lookout.net (Chris Weber)
Date: Sat, 24 Nov 2012 14:49:08 -0800
Subject: [whatwg] URL testing
In-Reply-To: <CADnb78iYSgawKgBNRevOey1yTiAUSp-6TWK2k4b2vsy3kNkoQQ@mail.gmail.com>
References: <50AFD0D4.6070207@lookout.net>
	<CADnb78iYSgawKgBNRevOey1yTiAUSp-6TWK2k4b2vsy3kNkoQQ@mail.gmail.com>
Message-ID: <50B14EE4.5020909@lookout.net>

On 11/24/2012 1:34 AM, Anne van Kesteren wrote:
> This is super awesome. Glad you continued with this. I have a few
> generic points for now:
> 
> * No special handling for IPv4. IPv4 should work the same as domain
> names. I.e. the host of http://192/ is 192, not 0.0.0.192.
> * It's still a bit unclear to me what the best solution is for
> fragment identifiers. Whether they should be percent escaped or not
> and whether that should differ between .href and .hash.

There also appears to be some differences in Unicode normalization
(assuming I tested this enough), see:

http://web.lookout.net/2012/03/unicode-normalization-in-urls.html

In my tests:

Safari applied NFC normalization to the path, query, and fragment.
Chrome applied NFC normalization to the fragment only.
MSIE, Firefox, and Opera did not apply normalization anywhere.

> * IDNA is a rathole.
But it makes for interesting test cases :-)

> When are you planning on doing the further cleanup you mention? At
> some point I can try to go through them in detail and suggest fixes
> (e.g. via a pull request).

I plan to do it slowly over the course of the next week or two.

- Chris

From w3c at adambarth.com  Sat Nov 24 19:10:29 2012
From: w3c at adambarth.com (Adam Barth)
Date: Sat, 24 Nov 2012 19:10:29 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
Message-ID: <CAJE5ia84pP83vHnjiirFG7ZeH+FCcCurAe7YvYfELWgFHXuwjA@mail.gmail.com>

On Fri, Nov 23, 2012 at 3:04 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Mon, 12 Nov 2012, Justin Novosad wrote:
>> For many types of apps, DOM-based rendering is uncompetitively slow
>> [so we should make text rendering in canvas more controllable]
>
> This seems like something we should fix, not something we should work
> around by having people use canvas instead. Using canvas has all kinds of
> terrible side-effects, like reducing the likely accessibility of the page,
> making searcheability much worse, etc.
>
> Also, do you have any metrics showing the magnitude of this problem on
> real-world sites that might consider using canvas instead?

The metrics I've seen show that the magnitude of this problem is
approximately 8x (to the extent that it's sensible to represent the
magnitude with a number).

As far as I can tell, the issue really boils down to the DOM being
retained mode and canvas being immediate mode.  As the size of the
underlying model grows, uploading the entire model into the DOM
becomes increasingly uncompetitive with having the application manage
the model and drawing using immediate mode because the application can
use application-specific knowledge to avoid having to process large
portions of the model.

I'm unsure what details I'm able to share about these experiments.
Justin might know better what we're able to share, but the outcomes
are roughly:

1) Uploading the entire document model into DOM (say for a model that
requires 1 million elements to represent) causes the application to
become completely unusable.  Memory consumption goes off the charts,
hit testing noticeably lags, etc.  We've been working to improve
performance here, but there are limits to what we'll be able to
achieve.  For example, DOM is always going to be a less memory
efficient than an application-specific representation.  On some
rendering benchmarks, a variety of browsers are able to render these
models at about 8 fps.

2) Remarkably, the current best candidate is a rendering pipeline that
attempts to use the DOM in immediate mode.  The application performs
some application-specific processing to determine which portions of
the model can actually affect what's drawn on screen, and then the
application uses innerHTML to create DOM for that portion of the
model.  (They've experimented with a bunch of choices and innerHTML
appears to be the fastest way to use the DOM as an immediate mode
API.)  Using this pipeline, the application uses reasonable amounts of
memory and hit testing, etc, aren't impacted.  This pipeline gets
about 20 fps.

3) Once they've moved from (1) to (2), you can understand why the next
logical step is to use a real immediate mode API, like canvas or
WebGL.  Approach (2) is totally nutty: there's no way the right design
is to build up a giant string of markup and then run it through the
parser for every frame.  Using canvas, the application has no trouble
achieving 60 fps.

I think the real question here is how do we want applications with
very large models to render?  Do we really want them to upload their
entire models into DOM?  If not, how can we provide them with a
high-quality immediate model rendering pipeline.

Adam

From bzbarsky at MIT.EDU  Sat Nov 24 20:41:59 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Sat, 24 Nov 2012 23:41:59 -0500
Subject: [whatwg] URL testing
In-Reply-To: <50B14EE4.5020909@lookout.net>
References: <50AFD0D4.6070207@lookout.net>
	<CADnb78iYSgawKgBNRevOey1yTiAUSp-6TWK2k4b2vsy3kNkoQQ@mail.gmail.com>
	<50B14EE4.5020909@lookout.net>
Message-ID: <50B1A197.6030908@mit.edu>

On 11/24/12 5:49 PM, Chris Weber wrote:
> There also appears to be some differences in Unicode normalization
> (assuming I tested this enough), see:
>
> http://web.lookout.net/2012/03/unicode-normalization-in-urls.html

A question.  What OS or OSes did you test on?  Unicode normalization 
differs in some browsers depending on the OS (e.g. different behavior on 
Windows and Mac)...

-Boris

From cabanier at gmail.com  Sat Nov 24 21:21:23 2012
From: cabanier at gmail.com (Rik Cabanier)
Date: Sat, 24 Nov 2012 21:21:23 -0800
Subject: [whatwg] [canvas] inner shadows
In-Reply-To: <CAGN7qDCdcvtvGLQ_K-Cy57pj8NH=eQm71FvzSfXqyg_JEQ9kEw@mail.gmail.com>
References: <682C6256-94F6-4351-9583-271294731B2B@gmail.com>
	<Pine.LNX.4.64.1209202249260.27765@ps20323.dreamhostps.com>
	<DCE06D4F-DAAD-4421-AAFC-2B4FC9559AEF@gmail.com>
	<Pine.LNX.4.64.1211232233510.15705@ps20323.dreamhostps.com>
	<Pine.LNX.4.64.1211232356080.29456@ps20323.dreamhostps.com>
	<CAGN7qDBxkjS30OtEbtyJsJtMmR40c1FgXJayOif0HKSoeXNEMA@mail.gmail.com>
	<Pine.LNX.4.64.1211240454430.29456@ps20323.dreamhostps.com>
	<CAGN7qDA2RYx8tc9s_Ah=TDRRmeUmdDq3Y_5hyR1Ft=kwh1-PRw@mail.gmail.com>
	<CABirCh9N7FbncNH_DaJPqb4jF4Ub7s9vRNQra77__KHqmNeEgg@mail.gmail.com>
	<CAGN7qDCdcvtvGLQ_K-Cy57pj8NH=eQm71FvzSfXqyg_JEQ9kEw@mail.gmail.com>
Message-ID: <CAGN7qDCqtrDbgpocWx+aiRp-njnhzVTAP785neHBjbAyY3M5DQ@mail.gmail.com>

On Sat, Nov 24, 2012 at 8:21 AM, Rik Cabanier <cabanier at gmail.com> wrote:

> On Sat, Nov 24, 2012 at 7:59 AM, Glenn Maynard <glenn at zewt.org> wrote:
>
>> On Fri, Nov 23, 2012 at 11:11 PM, Rik Cabanier <cabanier at gmail.com>wrote:
>>
>>> What matters is the shape that is used to calculate the blur (step 1)
>>> In your example, that shape is a rectangle so just the rectangle edges
>>> will
>>> be blurred.
>>> That slightly blurred rectangle is then composited with the clipping
>>> region
>>> in step 4.
>>>
>>> The end result is a solid rectangle in the shadowcolor that composites on
>>> top of the shape.
>>>
>>
>> Testing with Hixie's code (https://zewt.org/~glenn/canvas-glow.html),
>> the output is very close to "inner shadow" in Photoshop (distance 0, size
>> 22): https://zewt.org/~glenn/canvas-glow.png.
>>
>
> yes! I forgot that clip doesn't clear the path so his example works.
>
> I think it's possible to calculate to calculate the reverse shadow today
> with temporary backing and compositing.
> If so, the function to calculate them is not really necessary though it
> would be still be nice to have a direct way to do an inner shadow.
>

I put an example of this here: http://jsfiddle.net/cabanier/eav5V/
Unfortunately, Chrome has a bug in its handling of shadows so you have to
use a different browser.

This case uses a png with an alpha channel, but it can apply to shapes as
well.
It shows how you can calculate the inner shadow and how you can draw it on
top of your content.
The fourth canvas contains just the shadow. This is probably what Ian's
proposed function would return.

>
>
>> (I'm testing against inner shadow instead of inner glow; inner glow seems
>> to do something a little more complex at the blur step than a gaussian
>> blur.  Tested in Chrome 21; output in Firefox is different, but I probably
>> need to update.)
>
>
> True. Glow is a bit more complex than a plain (but not much).
> Photoshop also does a 'multiply' blend with the shadow by default which
> improves the look.
>

From annevk at annevk.nl  Sun Nov 25 01:33:32 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Sun, 25 Nov 2012 10:33:32 +0100
Subject: [whatwg] URL testing
In-Reply-To: <50B14EE4.5020909@lookout.net>
References: <50AFD0D4.6070207@lookout.net>
	<CADnb78iYSgawKgBNRevOey1yTiAUSp-6TWK2k4b2vsy3kNkoQQ@mail.gmail.com>
	<50B14EE4.5020909@lookout.net>
Message-ID: <CADnb78hWkRdExJWVpmTLeGP8_gaYXtKM5mhZwmwwW9RUUkVRzA@mail.gmail.com>

On Sat, Nov 24, 2012 at 11:49 PM, Chris Weber <chris at lookout.net> wrote:
> There also appears to be some differences in Unicode normalization
> (assuming I tested this enough), see:
>
> http://web.lookout.net/2012/03/unicode-normalization-in-urls.html
>
> In my tests:
>
> Safari applied NFC normalization to the path, query, and fragment.
> Chrome applied NFC normalization to the fragment only.
> MSIE, Firefox, and Opera did not apply normalization anywhere.

I don't think we should allow normalization (other than for the host
name). Since you are testing fragment, you might want to compare .hash
and .href. The results are different there. I've not yet reached a
conclusion there for what the specification should align with.
(Currently both are percent-escaped, but I could go with neither, or
one or the other I suppose).

>> * IDNA is a rathole.
>
> But it makes for interesting test cases :-)

The problem is that it's not clear what to test (or define in the
specification): http://wiki.whatwg.org/wiki/URL#IDNA

> I plan to do it slowly over the course of the next week or two.

Cool! Having some kind of infrastructure in place for setting (and
getting I suppose) individual components would also be good to have.
Are you planning on adding that? I'll try to allocate some time to
review the tests in more detail.

-- 
http://annevankesteren.nl/

From silviapfeiffer1 at gmail.com  Sun Nov 25 05:01:52 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 26 Nov 2012 00:01:52 +1100
Subject: [whatwg] Feature Request: Media Elements as Targets for Links
In-Reply-To: <20121124211954.5e47c5d2@desudesudesu>
References: <20121124211954.5e47c5d2@desudesudesu>
Message-ID: <CAHp8n2nHv7ygjQPOKVMqn7x+vg_X3Py0WU5JAeWLhdZZu3p5Ug@mail.gmail.com>

Can you provide an example markup and an example URL that you think will
solve your use case?

I'm asking because we don't use the name attribute any more in HTML5,
because we have the id attribute on all elements. Thus, it is always
possible to hyperlink directly to a video element using a hash on a URL and
the value of the id element. But I still wonder what you think is missing.

Regards,
Silvia.

On Sun, Nov 25, 2012 at 7:19 AM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

> Excuse me if I am doing something wrong by submitting this by mail. I
> am doing this for the first time, trying to fill in the template given
> at <http://wiki.whatwg.org/wiki/Problem_Solving> as good as I could.
>
> Use Case Description:
>
>   Linking to specific fragments of media is possible via media fragment
>   URIs [1]. However, it is not possible to apply a link to embedded
>   media declaratively, for example to link to a specific point in time
>   for a media element on a page.
>
>   [1] <http://www.w3.org/TR/media-frags/>
>
> - Current Limitations:
>
>   Linking to media using media fragment URIs changes browsing context.
>
> - Current Usage and Workarounds:
>
>   1. metavid (Videos of United States Congress) uses JavaScript, even
>   though they have CMML transcripts and SRT.
>
>   2. I have a podcast ?Warum nicht?? generated by a software called
>   redokast. Annotations need JavaScript: Click on the timestamps.
>   <http://warumnicht.dieweltistgarnichtso.net/wn-15.html>
>   <https://github.com/erlehmann/redokast>
>
> - Benefits: Declarative markup would make referring to timed
>   annotations easier. Referring to a specific point in time in a podcast
>   on the same comments, for example, could be possible.
>
> Proposed Solutions:
>
> - My Solution:
>   Give HTML media elements a name attribut. Make them valid targets for
>   links with a target attribut.
>
>   - Processing Model:
>     Processing for media elements and the <a> element needs to change.
>
>     <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#attr-hyperlink-target
> >
>     Change ?The target attribute, if present, must be a valid browsing
>     context name or keyword. It gives the name of the browsing context
>     that will be used.? to ?The target attribute, if present, must be a
>     valid browsing context name or keyword or the name of a media
>     element in the current browsing context. It gives the name of the
>     browsing context or media element that will be used.?
>
>     <
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#following-hyperlinks-0
> >
>     Append after ?If the user indicated a specific browsing context when
>     following the hyperlink, or if the user agent is configured to
>     follow hyperlinks by navigating a particular browsing context, then
>     that must be the browsing context that is navigated.? the paragraph
>     ?If the user indicated a media element on the current page when
>     following the hyperlink, then change the currentSrc attribute of
>     the media element to the absolute URL given by the href attribute
>     relative to the URL given by the currentSrc of the media element.?.
>
>     (I am unsure about relative URIs. Would we need to change only the
>     media fragment, and not re-run the initialization steps? What about
>     the media formats given by <source> elements?)
>
>   - Limitations
>     (No idea.)
>
>   - Implementation:
>     (I am not a very clever guy. Someone would need to fill this in.)
>
>   - Adoption:
>     Users could easily link to parts of media resources on a page. The
>     solution would be backwards compatible for existing UAs that are
>     able to process media fragment URIs as long as absolute URIs are
>     used. A JavaScript polyfill could be used while not all UAs support
>     this feature. Consumers of web pages could easily see what a
>     discussion about a media resource refers to.
>
> --
> Nils Dagsson Moskopp // erlehmann
> <http://dieweltistgarnichtso.net>
>

From scott.gonzalez at gmail.com  Sun Nov 25 07:30:35 2012
From: scott.gonzalez at gmail.com (=?ISO-8859-1?Q?Scott_Gonz=E1lez?=)
Date: Sun, 25 Nov 2012 10:30:35 -0500
Subject: [whatwg] Make stepUp() and stepDown() more developer-friendly
In-Reply-To: <Pine.LNX.4.64.1211202253300.16964@ps20323.dreamhostps.com>
References: <50AB6E5F.5050803@lamouri.fr>
	<CAO8i3icCK=WYhMe=ToaRw7VWerBi5CmuYidFfoi9nNOaMXAnkA@mail.gmail.com>
	<Pine.LNX.4.64.1211202253300.16964@ps20323.dreamhostps.com>
Message-ID: <CAO8i3idci4C8hkgj12rPSt4hw1C+BdNv90YxV0ECKrY45R-h6w@mail.gmail.com>

On Tue, Nov 20, 2012 at 5:55 PM, Ian Hickson <ian at hixie.ch> wrote:

> > I can list out the steps we take for all conditions, but I'd like to
> > hear everyone's thoughts on the various cases where you're suggesting
> > that the methods do nothing.
>
> Mostly I agree with Mounir here, but I'm curious about what you think
> should happen for the case where there's no value, and the case where the
> control isn't a numeric/date/time type. I could see an argument for
> stepping from the default in the former case (Mounir, what do you think
> about doing that?) but for the latter case I don't really see any point
> doing anything but throw an exception, as Mounir suggested.

For any non-parsable value (including no value), we start at 0, take the
step, then confine to a valid step within min/max.

I think it makes sense to throw if the control doesn't support stepping.

From nils at dieweltistgarnichtso.net  Sun Nov 25 09:47:18 2012
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Sun, 25 Nov 2012 18:47:18 +0100
Subject: [whatwg] Feature Request: Media Elements as Targets for Links
In-Reply-To: <CAHp8n2nHv7ygjQPOKVMqn7x+vg_X3Py0WU5JAeWLhdZZu3p5Ug@mail.gmail.com>
References: <20121124211954.5e47c5d2@desudesudesu>
	<CAHp8n2nHv7ygjQPOKVMqn7x+vg_X3Py0WU5JAeWLhdZZu3p5Ug@mail.gmail.com>
Message-ID: <20121125184718.228f4dfa@desudesudesu>

Silvia Pfeiffer <silviapfeiffer1 at gmail.com> schrieb am Mon, 26 Nov 2012
00:01:52 +1100:

> Can you provide an example markup and an example URL that you think
> will solve your use case?

Example markup. Assume I have an audio element in a blog:

Someone could comment it like:

<a href="#t=01:23" target="audio">When Alice mentioned Bob</a> ?

When someone clicks the link, the browsing context would not change,
but the media element would jump to that point (and possibly play).

> I'm asking because we don't use the name attribute any more in HTML5,
> because we have the id attribute on all elements. Thus, it is always
> possible to hyperlink directly to a video element using a hash on a
> URL and the value of the id element. But I still wonder what you
> think is missing.

I want to hyperlink directly to a embedded media content at a specific
time while preserving the context without going through brittle
JavaScript hoops. Maybe an element-specific second-hash is possible?

Something like <http://example.org/podcast.html#episode1#t=01:23> could
link to the audio element on the page at a specific point in time. (I
am just conjecturing now, though ? is that even legal URL synthax?)

Greetings,
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From silviapfeiffer1 at gmail.com  Sun Nov 25 17:17:34 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Mon, 26 Nov 2012 12:17:34 +1100
Subject: [whatwg] Feature Request: Media Elements as Targets for Links
In-Reply-To: <20121125184718.228f4dfa@desudesudesu>
References: <20121124211954.5e47c5d2@desudesudesu>
	<CAHp8n2nHv7ygjQPOKVMqn7x+vg_X3Py0WU5JAeWLhdZZu3p5Ug@mail.gmail.com>
	<20121125184718.228f4dfa@desudesudesu>
Message-ID: <CAHp8n2=oOjOWbwhn1H1iABbu9xjHpY6tjUN5GeHcmXce4j7riw@mail.gmail.com>

On Mon, Nov 26, 2012 at 4:47 AM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

> Silvia Pfeiffer <silviapfeiffer1 at gmail.com> schrieb am Mon, 26 Nov 2012
> 00:01:52 +1100:
>
> > Can you provide an example markup and an example URL that you think
> > will solve your use case?
>
> Example markup. Assume I have an audio element in a blog:
>
> <audio id="episode1">
>   <source src="episode1.oga" type="audio/ogg; codecs=vorbis">
>   <source src="episode1.mp3" type="audio/mpeg">
> </audio>
>
> Someone could comment it like:
>
> <a href="#t=01:23" target="audio">When Alice mentioned Bob</a> ?
>
> When someone clicks the link, the browsing context would not change,
> but the media element would jump to that point (and possibly play).
>
> > I'm asking because we don't use the name attribute any more in HTML5,
> > because we have the id attribute on all elements. Thus, it is always
> > possible to hyperlink directly to a video element using a hash on a
> > URL and the value of the id element. But I still wonder what you
> > think is missing.
>
> I want to hyperlink directly to a embedded media content at a specific
> time while preserving the context without going through brittle
> JavaScript hoops. Maybe an element-specific second-hash is possible?
>
> Something like <http://example.org/podcast.html#episode1#t=01:23> could
> link to the audio element on the page at a specific point in time. (I
> am just conjecturing now, though ? is that even legal URL synthax?)
>

No, that is invalid since you can only have one fragment on a URL - at best
you could do http://example.org/podcast.html#episode1&t=01:23.

What is currently possible is  <a href="#episode1" target="audio">When
Alice mentioned Bob</a> and doing the time offsetting in JavaScript, either
by changing the currentSrc to something like "episode1.oga#t=01:23" or by
setting the currentTime to 83.

I agree that this is a frustrating situation and a declarative means of
setting the media fragment offset would be much preferred. I have used
@data-time attributes for this before (while of course still using JS to
actually implement it).

I would support introduction of a standard attribute for this. Maybe
something like @mediafrag="t=01:23" on <a> elements would be really useful
and can be converted by browsers to be added to a <video> or <audio>
element currentSrc if the <a> links to the @id of a media element.

The biggest problem that I see, however, is that you really want the URL of
the Web page be changed to reflect the time offset status of the media
resource, e.g. http://example.com/AliceAndBobVideo.html ->
http://example.com/AliceAndBobVideo.html#t=01:23 . In this way people can
cut-and-paste the URL and share it with the time offset intact.

(I also have an example of such a use case
http://eopas.rnld.unimelb.edu.au/transcripts/113#t=17.36,19.08 )

I don't think there is a simple way to achieve this with the way that the
Web currently works because the interpretation of the fragment parameters
of the HTML page are controlled by the Web application where they don't
apply to an @id attribute on the page. We would need to change the way in
which URL fragments are interpreted by Web pages.

Regards,
Silvia.

From robert at ocallahan.org  Mon Nov 26 02:50:41 2012
From: robert at ocallahan.org (Robert O'Callahan)
Date: Mon, 26 Nov 2012 23:50:41 +1300
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAJE5ia84pP83vHnjiirFG7ZeH+FCcCurAe7YvYfELWgFHXuwjA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAJE5ia84pP83vHnjiirFG7ZeH+FCcCurAe7YvYfELWgFHXuwjA@mail.gmail.com>
Message-ID: <CAOp6jLbeOgG2F11ntBsWj-X2Tb=yQbR8ez8hggYnDV1_zSiMaQ@mail.gmail.com>

It's hard to analyze your use-case without knowing what it is.

For some kinds of "large data model" applications, I can think of DOM-based
implementation techniques that might be a lot more performant than those
you have mentioned. I agree that this is a very challenging domain.

From annevk at annevk.nl  Mon Nov 26 06:20:27 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Mon, 26 Nov 2012 15:20:27 +0100
Subject: [whatwg] URL: query string
In-Reply-To: <DUB002-W589A022F68C3D67A9C083AE3540@phx.gbl>
References: <CADnb78gHTiF1qh=Q7D+zY8gG3oAeTNH28uP2x2S=4D8g4GRzCw@mail.gmail.com>
	<DUB002-W66E625C8F98B398B174B30E3540@phx.gbl>
	<CADnb78huJySE-C4RjbO1taXpVONQtZY0XDCdpfu1ksR=u4je-w@mail.gmail.com>
	<DUB002-W589A022F68C3D67A9C083AE3540@phx.gbl>
Message-ID: <CADnb78hw5ZoB5ZOBusNWEEevRafW4NnPFbh4e+httyZgeLkozg@mail.gmail.com>

On Wed, Nov 21, 2012 at 10:10 PM, James Ross
<silver at warwickcompsoc.co.uk> wrote:
>  Alas not quite; for "test:test?test" and "data:test?test" it works, but for "about:blank?test" it gives pathname="blank?test" and search="". The behaviour change appears to be specific to the "about:" scheme (it happens no matter what I put after). It also doesn't split out the hash, if there is one, when the scheme is "about:".

Thanks, I guess we'll treat that as a bug.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20044

-- 
http://annevankesteren.nl/

From mounir at lamouri.fr  Mon Nov 26 07:05:35 2012
From: mounir at lamouri.fr (Mounir Lamouri)
Date: Mon, 26 Nov 2012 15:05:35 +0000
Subject: [whatwg] Make stepUp() and stepDown() more developer-friendly
In-Reply-To: <CAO8i3idci4C8hkgj12rPSt4hw1C+BdNv90YxV0ECKrY45R-h6w@mail.gmail.com>
References: <50AB6E5F.5050803@lamouri.fr>
	<CAO8i3icCK=WYhMe=ToaRw7VWerBi5CmuYidFfoi9nNOaMXAnkA@mail.gmail.com>
	<Pine.LNX.4.64.1211202253300.16964@ps20323.dreamhostps.com>
	<CAO8i3idci4C8hkgj12rPSt4hw1C+BdNv90YxV0ECKrY45R-h6w@mail.gmail.com>
Message-ID: <50B3853F.5020207@lamouri.fr>

On 25/11/12 15:30, Scott Gonz?lez wrote:
> On Tue, Nov 20, 2012 at 5:55 PM, Ian Hickson <ian at hixie.ch> wrote:
> 
>>> I can list out the steps we take for all conditions, but I'd like to
>>> hear everyone's thoughts on the various cases where you're suggesting
>>> that the methods do nothing.
>>
>> Mostly I agree with Mounir here, but I'm curious about what you think
>> should happen for the case where there's no value, and the case where the
>> control isn't a numeric/date/time type. I could see an argument for
>> stepping from the default in the former case (Mounir, what do you think
>> about doing that?) but for the latter case I don't really see any point
>> doing anything but throw an exception, as Mounir suggested.
> 
> 
> For any non-parsable value (including no value), we start at 0, take the
> step, then confine to a valid step within min/max.

Why I don't really like in beginning at the closest valid value from 0
is that the general behaviour for the user might be a bit inconsistent.
I don't know if using the step base would really solve that but it might
work better. Using the value between max and min if max and min are
defined might work all the time though.

--
Mounir

From jackalmage at gmail.com  Mon Nov 26 09:57:15 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Mon, 26 Nov 2012 09:57:15 -0800
Subject: [whatwg] Enabling LCD Text and antialiasing in canvas
In-Reply-To: <CAJE5ia84pP83vHnjiirFG7ZeH+FCcCurAe7YvYfELWgFHXuwjA@mail.gmail.com>
References: <CABpaAqSg6kg=Mhw+=M9vu5evo7f7WTq-O2iToGf1itYfxkAa2w@mail.gmail.com>
	<CAOp6jLYNw6DjXUi=0aA=eOOHpDciNHfLA2ZdgVz60rDTQP1HgQ@mail.gmail.com>
	<CABpaAqTens8M2nFia=+mKCZnNayjy-jDtObTt3m5_F25AydVCg@mail.gmail.com>
	<BLU002-W5512952023FBBF99D4C531AA520@phx.gbl>
	<CABpaAqQpFr73BMhYT=VoxxDq0hbmcrLF9-Wk6ikD4myXJaYusw@mail.gmail.com>
	<Pine.LNX.4.64.1211232249070.15705@ps20323.dreamhostps.com>
	<CAJE5ia84pP83vHnjiirFG7ZeH+FCcCurAe7YvYfELWgFHXuwjA@mail.gmail.com>
Message-ID: <CAAWBYDDrRVksHrjN-=NespSRmxkn6LMyMqqRXdAHx-wUTSkZhA@mail.gmail.com>

On Sat, Nov 24, 2012 at 7:10 PM, Adam Barth <w3c at adambarth.com> wrote:
> 2) Remarkably, the current best candidate is a rendering pipeline that
> attempts to use the DOM in immediate mode.  The application performs
> some application-specific processing to determine which portions of
> the model can actually affect what's drawn on screen, and then the
> application uses innerHTML to create DOM for that portion of the
> model.  (They've experimented with a bunch of choices and innerHTML
> appears to be the fastest way to use the DOM as an immediate mode
> API.)  Using this pipeline, the application uses reasonable amounts of
> memory and hit testing, etc, aren't impacted.  This pipeline gets
> about 20 fps.

I'm working on ways to make this process easier and more performant,
first on the CSS side, then on the DOM side.  Right now it's internal,
but as soon as I have something that's not crap, I'll be posting it
here for review, feedback, and iteration.

My current plan is:

* On the CSS side, provide some nice new primitives for "isolating"
layout of elements, so that you can be sure that your DOM-tweaking
won't break out and cause unexpected reflow in the rest of the
document.  That's a perf-killer.  Connected to that, provide a way to
guarantee that an element's rendering doesn't extend outside of itself
(or a bounds around itself), so that we can, behind the scenes,
destroy renderers that are off-screen and which we predict won't be
viewed again in the near future.

* On the DOM side, at the lowest level, provide some primitives that
do the ugly grunt-work that people are already doing in JS (prediction
of the area that is visible and which is soon-to-be-visible), and
hopefully neuter some related problems of very large lists as well
(such as simply running out of coordinate space - it appears that you
start hitting problems when an element exceeds 1M-16M (varies by
browser) pixels in one dimension).  Building atop that, some
convenient declarative tools that take even more of the work out of
the author's hands and let us do more stuff automatically and with
higher performance: for example, perhaps the author can just provide a
JS array of data and a <template> element, and the browser generates
and destroys DOM on the fly from this.

~TJ

From dbk at google.com  Mon Nov 26 10:00:36 2012
From: dbk at google.com (David Barrett-Kahn)
Date: Mon, 26 Nov 2012 12:00:36 -0600
Subject: [whatwg] AppCache Error events
Message-ID: <CA+iXHYO4CrvH27cOX15g1_RFQCjqDVLnynbD34U3HRhVoZoDrQ@mail.gmail.com>

Right now this event contains no structured information, just an error
message.  It'd be helpful to us to know more about what failed, so we can
know what to report to the server and take action on.  It's hard to
distinguish cache update failures due to just being offline from those
which are actually causing trouble.  In the second case it's also hard to
work out which resource is proving unavailable and why.

One way to do this would be to create an AppCacheError subclass, with an
errorCode parameter, and also nullable url and httpResponseCode properties.
 Potential error codes:
* couldn't fetch manifest (includes url and httpResponseCode)
* pre and post update manifest fetches mismatched (includes url)
* fetching a resource failed (includes url and httpResponseCode)

Related bug:
https://code.google.com/p/chromium/issues/detail?id=161753

Thoughts?

-Dave

From gphemsley at gmail.com  Mon Nov 26 14:38:02 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Mon, 26 Nov 2012 17:38:02 -0500
Subject: [whatwg] [mimesniff] Audio and video sniffing
Message-ID: <CAH4e3M6rV+GSODuD344KxX+hyW4ChtJ__05snZfG=FLdOQ4JNQ@mail.gmail.com>

Upon looking through the code for Gecko's media sniffing, I noticed
that they seem to combine sniffing for audio and video elements. Given
that Opera has said that it uses the specific sniffing algorithms, and
that some media containers (like Ogg) can be used for either audio or
video, I wonder if it would make sense to combine audio and video
sniffing under a single audiovisual category? This would affect the
"matching audio/video type pattern" sections and the "sniffing
audio/video specifically" sections.

Any objections? Other thoughts?

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From gphemsley at gmail.com  Mon Nov 26 14:59:17 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Mon, 26 Nov 2012 17:59:17 -0500
Subject: [whatwg] [mimesniff] Handling container formats like Ogg
Message-ID: <CAH4e3M43dLb+GSE1z=FurHPBJ04pOXrcPo3gi1pz7hRYPF6scQ@mail.gmail.com>

Container formats like Ogg can be used to store many different audio
and video formats, all of which can be identified generically as
"application/ogg". Determining which individual format to use (which
can be identified interchangeably as the slightly-less-generic
"audio/ogg" or "video/ogg", or using a 'codecs' parameter, or using a
dedicated media type) is much more complex, because they all use the
same "OggS" signature. It would requiring actually attempting to parse
the Ogg container to determine which audio or video format it is using
(perhaps not unsimilar to what is done for MP4 video and what might
have to be done with MP3 files without ID3 tags).

Would this be something UAs would prefer to handle in their Ogg
library, or should I spec it as part of sniffing?

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From w3c at adambarth.com  Mon Nov 26 15:45:11 2012
From: w3c at adambarth.com (Adam Barth)
Date: Mon, 26 Nov 2012 15:45:11 -0800
Subject: [whatwg] [mimesniff] Handling container formats like Ogg
In-Reply-To: <CAH4e3M43dLb+GSE1z=FurHPBJ04pOXrcPo3gi1pz7hRYPF6scQ@mail.gmail.com>
References: <CAH4e3M43dLb+GSE1z=FurHPBJ04pOXrcPo3gi1pz7hRYPF6scQ@mail.gmail.com>
Message-ID: <CAJE5ia_H7+itUOk5ua3xvPG-wPtHF3NFLY4ecmuANC-MFv+OCw@mail.gmail.com>

I included H.264 sniffing in the spec because some implementors
specifically asked for it (and it wasn't all that complicated).  For
Ogg, I'd wait until implementors ask you to include it.

Adam

On Mon, Nov 26, 2012 at 2:59 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> Container formats like Ogg can be used to store many different audio
> and video formats, all of which can be identified generically as
> "application/ogg". Determining which individual format to use (which
> can be identified interchangeably as the slightly-less-generic
> "audio/ogg" or "video/ogg", or using a 'codecs' parameter, or using a
> dedicated media type) is much more complex, because they all use the
> same "OggS" signature. It would requiring actually attempting to parse
> the Ogg container to determine which audio or video format it is using
> (perhaps not unsimilar to what is done for MP4 video and what might
> have to be done with MP3 files without ID3 tags).
>
> Would this be something UAs would prefer to handle in their Ogg
> library, or should I spec it as part of sniffing?
>
> --
> Gordon P. Hemsley
> me at gphemsley.org
> http://gphemsley.org/ ? http://gphemsley.org/blog/

From nils at dieweltistgarnichtso.net  Mon Nov 26 16:10:04 2012
From: nils at dieweltistgarnichtso.net (Nils Dagsson Moskopp)
Date: Tue, 27 Nov 2012 01:10:04 +0100
Subject: [whatwg] Fw: Feature Request: Media Elements as Targets for Links
Message-ID: <20121127011004.633ae726@desudesudesu>

Sorry, forgot to include list.

Date: Mon, 26 Nov 2012 21:09:01 +0100
From: Nils Dagsson Moskopp <nils at dieweltistgarnichtso.net>
To: Silvia Pfeiffer <silviapfeiffer1 at gmail.com>
Subject: Re: [whatwg] Feature Request: Media Elements as Targets for
Links

Silvia Pfeiffer <silviapfeiffer1 at gmail.com> schrieb am Mon, 26 Nov 2012
12:17:34 +1100:

> [?]
>
> What is currently possible is  <a href="#episode1" target="audio">When
> Alice mentioned Bob</a> and doing the time offsetting in JavaScript,
> either by changing the currentSrc to something like
> "episode1.oga#t=01:23" or by setting the currentTime to 83.

I do something like that already in redokast.

> [?]
> 
> I would support introduction of a standard attribute for this. Maybe
> something like @mediafrag="t=01:23" on <a> elements would be really
> useful and can be converted by browsers to be added to a <video> or
> <audio> element currentSrc if the <a> links to the @id of a media
> element.
>
> The biggest problem that I see, however, is that you really want the
> URL of the Web page be changed to reflect the time offset status of
> the media resource, e.g. http://example.com/AliceAndBobVideo.html ->
> http://example.com/AliceAndBobVideo.html#t=01:23 . In this way people
> can cut-and-paste the URL and share it with the time offset intact.

I think that solving the problem on the URL level would be much more
useful than requiring an additional attribute.

Podcasters from Germany calling themselves Podlove initiative are
planning to re-use fragment identifiers and a part of media fragments
already, but AFAIK there is no implementation of their proposal.
<http://podlove.org/deep-link/>

Your example of <http://example.org/podcast.html#episode1&t=01:23>
seems very usable to me ? it would make it possible to have multiple
media elements on a page and target them accurately. Maybe one should
use another character than the ampersand for compatibility reasons, but
that is an empiric question that looking at data can solve.

> [?]
>
> I don't think there is a simple way to achieve this with the way that
> the Web currently works because the interpretation of the fragment
> parameters of the HTML page are controlled by the Web application
> where they don't apply to an @id attribute on the page. We would need
> to change the way in which URL fragments are interpreted by Web pages.

Maybe I am misunderstanding you here, but I think the fragment
identifier abuse by JavaScript authors can be of use here ? it would
allow for a simple polyfill that could quickly propagate use and
knowledge of such a feature before someone else invents yet another
slightly incompatible way of doing the same thing.

Greetings,
-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

-- 
Nils Dagsson Moskopp // erlehmann
<http://dieweltistgarnichtso.net>

From giles at mozilla.com  Mon Nov 26 16:18:34 2012
From: giles at mozilla.com (Ralph Giles)
Date: Mon, 26 Nov 2012 16:18:34 -0800
Subject: [whatwg] metadata attribute for media
In-Reply-To: <op.wlac76p9sr6mfa@kirk>
References: <505BA783.2030202@mozilla.com> <op.wlac76p9sr6mfa@kirk>
Message-ID: <50B406DA.70708@mozilla.com>

On 12-09-27 1:44 AM, Philip J?genstedt wrote:

> I'm skeptical that all that we want from ID3v2 or common VorbisComment
> tags can be mapped to Dublin Core, it seems better to define mappings
> directly from the underlying format to the WebIDL interface.

You're right.

> Given the open-endedness of metadata contained in actual media
> resources, I'm personally a bit skeptical that there's something we
> could add to the Web platform that would be better than just letting
> authors pass that metadata out-of-band using any representation they
> like, but what use cases are you trying to cover here?

Two use cases I'm trying to address:

- A web application presents some view of a media library. If the libray
resides on a server, then yes, the server-side component of the app can
parse, cache, and deliver the metadata out-of-band. But the library
could also be local, in which case the webapp must do its own parsing,
e.g. from a list of blob urls returned by the file api.

- An author wants to display the embedded track title and artist name
with simple scripting on a webpage.

One of the goals of html media was to make video and audio as simple to
include as images. User agents are generally parsing this metadata
anyway; exposing it is straightforward, and greatly simplifies the two
tasks above.

In any case, the media.mozGetMetadata() method I described earlier is
available in Firefox 17, released last week, with support for Vorbis
tags in .ogg files. Firefox 18, now in beta, adds support for .opus
files as well. Here's an example:

https://people.xiph.org/~giles/2012/metadata.html

You should see 'Title', 'Album', etc. below the controls if your browser
supports mozGetMetadata().

We're continuing to implement this interface for other formats we support.

I still think it's useful to define both this 'raw' metadata interface,
returning just the data out of the file, and a more structured metadata
object with standardized tag names. I've left off implementing the
second one for lack of feedback on what the basic tags should be, and
how useful they are. There certainly wasn't consensus here.

So, what do you think of these two proposals:

1. Define the 'raw' getMetadata method in an unprefixed form:

interface HTMLMediaElement {
  ...
  object getMetadata();
};

After the metadataloaded event fires, this method would return a new
object containing a copy of the metadata read from the resource, in
whatever format the decoder implementation supplies. It would be up to
the caller to do any semantic interpretation. The same method should be
present on AudioTrack, VideoTrack, (TextTrack?) and Image elements.

2. Define a parsed metadata attribute with some standard tags:

interface Metadata {
  readonly attribute DOMString title;
  readonly attribute DOMString artist;
  readonly attribute DOMString album;
  readonly attribute Blob? artwork;
};

interface MediaElement {
  ...
  Metadata metadata;
};

So you could say something as simple as

img.src = audio.metadata.artwork;

to display the cover art embedded in a download single. DOMString
attributes would have the value of an empty string if the underlying
data isn't available. These four attributes are the absolute minimum, I
think, for the use cases above. More could be added later as usage of
the api evolves. For example: date, publisher, tracknumber, tracktotal,
description, genre, sort-artist, sort-title, copyright, license, url.

If having both media.getMetadata() (raw) and media.metadata is
confusing, the first proposal could be named media.getRawMetadata() as well.

Does it make sense to include more technical metadata here? For example:
samplerate, channels, duration, width, height, framerate, aspect-ratio.
Firefox currently has prefixed properties for the number of channels and
the audio sample rate, and including these in the metadata interface
would let us deprecate the prefixed versions. On the other hand,
properties like duration, width, and height are available directly on
media elements today, so maybe it makes more sense to do the same for
the others.

In that case, do we want the indirection of the Metadata inferface?
Saying 'video.title' or 'img.src = audio.artwork' instead is shorter.

Feedback welcome,
 -r

From chris at lookout.net  Mon Nov 26 18:11:21 2012
From: chris at lookout.net (Chris Weber)
Date: Mon, 26 Nov 2012 18:11:21 -0800
Subject: [whatwg] URL testing
In-Reply-To: <50B1A197.6030908@mit.edu>
References: <50AFD0D4.6070207@lookout.net>
	<CADnb78iYSgawKgBNRevOey1yTiAUSp-6TWK2k4b2vsy3kNkoQQ@mail.gmail.com>
	<50B14EE4.5020909@lookout.net> <50B1A197.6030908@mit.edu>
Message-ID: <50B42149.9010908@lookout.net>

On 11/24/2012 8:41 PM, Boris Zbarsky wrote:
> A question.  What OS or OSes did you test on?  Unicode normalization
> differs in some browsers depending on the OS (e.g. different behavior on
> Windows and Mac)...

Thanks for bringing that up Boris, I only tested this on Windows.  I'll
try to take a look at this on Mac or Linux and update the results.

-Chris

From simonp at opera.com  Mon Nov 26 21:51:03 2012
From: simonp at opera.com (Simon Pieters)
Date: Tue, 27 Nov 2012 06:51:03 +0100
Subject: [whatwg] [mimesniff] Audio and video sniffing
In-Reply-To: <CAH4e3M6rV+GSODuD344KxX+hyW4ChtJ__05snZfG=FLdOQ4JNQ@mail.gmail.com>
References: <CAH4e3M6rV+GSODuD344KxX+hyW4ChtJ__05snZfG=FLdOQ4JNQ@mail.gmail.com>
Message-ID: <op.woe3vdpzidj3kv@device-56497e>

On Mon, 26 Nov 2012 23:38:02 +0100, Gordon P. Hemsley  
<gphemsley at gmail.com> wrote:

> Upon looking through the code for Gecko's media sniffing, I noticed
> that they seem to combine sniffing for audio and video elements. Given
> that Opera has said that it uses the specific sniffing algorithms, and
> that some media containers (like Ogg) can be used for either audio or
> video, I wonder if it would make sense to combine audio and video
> sniffing under a single audiovisual category? This would affect the
> "matching audio/video type pattern" sections and the "sniffing
> audio/video specifically" sections.
>
> Any objections? Other thoughts?

Yes, I think it makes sense to have the same sniffing for both. <audio> is  
like <video> without the rendering area.

-- 
Simon Pieters
Opera Software

From marnix.tjaeckx at gmail.com  Mon Nov 26 23:33:05 2012
From: marnix.tjaeckx at gmail.com (Marnix T'Jaeckx)
Date: Tue, 27 Nov 2012 09:33:05 +0200
Subject: [whatwg] web preprocessing
Message-ID: <CAKOPQodTr4Zo+Txrjowrmd3jum241=ueKk+1SUD9pLJvA+_ojQ@mail.gmail.com>

I would like to propose and request a feature for the web standards. The
best way to describe it: a html preprocessor.
In a similar vein to the C preprocessor and the like, the syntax would
allow constants to be defined to be accessible across both html, css and js.
Scenario's where this is useful occur quite frequently, if not on every
webpage. For instance, when lay-out contstants need to be duplicated in css
and js, or when user messages need to be duplicated in html and js.
In many cases, code clarity and brevity would be helped as well as a
reduction in bandwidth, accordingly.

Implementations could make use of the meta elements or a new syntactic
layer could be added.

example:
HTML head: <meta name="boxWidth" content="640"/>
CSS: #box{width:meta(boxWidth)}
 (or #box{width:meta('boxWidth')})
JS:  box.style.width=document.meta(
'boxWidth');

another example:
HTML head: <meta name="labelPlay" content="Let me hear you sing it!"/>
HTML body:  <button><meta name="labelPlay"></button>
JS:  box.innerHTML=document.meta('labelPlay');

Have a good one,
Marnix T'Jaeckx
http://aelgoa.50webs.com/#marnix

From mikko.rantalainen at peda.net  Tue Nov 27 00:18:58 2012
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Tue, 27 Nov 2012 10:18:58 +0200
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <Pine.LNX.4.64.1211220344070.15705@ps20323.dreamhostps.com>
References: <50A12B1F.1080200@lamouri.fr>
	<Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
	<50ACC044.2060006@lamouri.fr>
	<Pine.LNX.4.64.1211220344070.15705@ps20323.dreamhostps.com>
Message-ID: <50B47772.5030703@peda.net>

Ian Hickson, 2012-11-22 07:15 (Europe/Helsinki):
> On Wed, 21 Nov 2012, Mounir Lamouri wrote:
>> Then, maybe a better naming could be "datetime-utc"?
> 
> I think that would mislead authors into thinking that the UI that users 
> will see is one that asks for a UTC time. That kind of UI is the worst UI 
> for this kind of feature, so that would be misleading.

I'd suggest "datetime-absolute" because the other variant is "floating"
or "relative" (to local politically decided time which may vary
depending on future political decisions).

> It's not a question of which is _used_ more, it's a question of which is 
> _authored_ more. As far as I can tell, the use cases for floating times 
> are basically cross-time-zone transport facilities, e.g. plane tickets, 
> while the use cases for absolute times are anything involving coordination 
> amongst multiple people in multiple time zones, e.g. meetings (in person 
> or online), game events, product launches, online live streaming events...

At least here in Finland, floating times are also used for scheduling
repeating events (e.g. meetings or lectures). I'd much prefer always
scheduling everything in absolute time (UTC) but usually other people
are not happy with that.

A good UI for relative/floating datetime would be to request user to
define date and time without any hint about the timezone.

A *possible* UI for absolute datetime would be to request user to define
date and time in his own timezone (maybe with an option to use UTC
instead) and clearly spell out the timezone in the UI. For example, I'd
be happy to have UI say something along the lines

Date:
    [2012-11-27]
    Time:
    [10:00:00]
    (Europe/Helsinki)

That would fit perfectly fine on the display of my phone and this would
make it perfectly clear that the event would not happen at 10:00 in London.

>> If the main difference between "datetime" and "datetime-foo" is the 
>> format of the value we send to the server, can't we simply always send 
>> the timezone information? So, servers who care about the user's timezone 
>> could do the conversion, and others could simply ignore the information.
> 
> I don't think the controls should be the same.

I agree. The server should either (a) get relative time which is known
to be floating around and cannot be trusted to mean any absolute time
because floating time is subject to political time zone changes that
sometimes come with very short notice, or (b) absolute time in which
case the server should always get UTC time.

However, I'm not sure how this can be presented to the user. In the
example above I suggested that time input UI should be accompanied with
local time zone ("Europe/Helsinki" in my example). However, that would
suggest that this info would be transferred to the server and that the
server is expected to follow political time zone changes to that
timezone. The user could be assuming that he has defined a specific time
in a specific timezone (an absolute time as far has he knows).

In the reality, the server would like to transfer *the responsibility*
for the possible future time zone changes to the user -- the server
expects user to come by and modify the absolute time in case the user
local timezone has been modified since entering this absolute time. I
have absolutely no idea how on earth this could be explained to casual
user. And even if it could be explained, I'm pretty sure the end user
wouldn't be happy with that responsibility.

As a server software developer, I'd *love* to have timezone-absolute but
I'm not sure how that would ever work in practice (given that
politicians keep up modifying local time at will).

The next best choice would be to have datetime-with-timezone but
unfortunately

(1) Official database for all timezones does not exist
(2) Official timezone names (or labels) do not exist
(3) Timezones are subject to future political decisions

The problems (1) and (2) make transferring the timezone information from
the end user to the server very problematic and the problem (3) makes
any work to fix (1) and (2) a bit pointless. This is because even if UA
could successfully inform the server about the correct timezone, the
server could be using a week old timezone data that is not up to the
latest political events. Or the server might be using latest timezone
data but the UA could be using three year old data. In either case, the
absolute time in UTC could be different for the server and UA.

-- 
Mikko

From silviapfeiffer1 at gmail.com  Tue Nov 27 00:28:54 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 27 Nov 2012 19:28:54 +1100
Subject: [whatwg] Fw: Feature Request: Media Elements as Targets for
	Links
In-Reply-To: <20121127011004.633ae726@desudesudesu>
References: <20121127011004.633ae726@desudesudesu>
Message-ID: <CAHp8n2k2U4z5mCY0_Dbr7Fpf9gfAQK-UumABRL+AQT0Q25yMKA@mail.gmail.com>

On Tue, Nov 27, 2012 at 11:10 AM, Nils Dagsson Moskopp <
nils at dieweltistgarnichtso.net> wrote:

>
> Maybe I am misunderstanding you here, but I think the fragment
> identifier abuse by JavaScript authors can be of use here ? it would
> allow for a simple polyfill that could quickly propagate use and
> knowledge of such a feature before someone else invents yet another
> slightly incompatible way of doing the same thing.
>

Nobody will stop you from writing a JS library to interpret the pattern of <
http://example.org/podcast.html#episode1&t=01:23> in the way that you
expect it to be interpreted. However, IIUC, browsers will interpret this as
an offset to an element on the html page that has an id of
id="episode1&t=01:23". If such an element happens to exist, the page will
scroll to it. You can additionally run the JS, but that won't stop the page
from getting scrolled.

Fortunately, it's not very likely that HTML pages have an element with such
an @id value, so a polyfill as you describe could indeed be very useful.

Regards,
Silvia.

From mikko.rantalainen at peda.net  Tue Nov 27 00:39:45 2012
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Tue, 27 Nov 2012 10:39:45 +0200
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50A22635.2090900@yahoo.fr>
References: <50A12B1F.1080200@lamouri.fr> <50A22635.2090900@yahoo.fr>
Message-ID: <50B47C51.40003@peda.net>

Nicolas Froidure, 2012-11-13 12:51 (Europe/Helsinki):
> In my opinion, it's normal that datetime and datetime-local have
> timezone and date/time don't. A date is timezone independant and time is
> more a duration then a time relative to a particular instant of a
> particular day.

Unfortunately, "date" is definitely NOT timezone independent. When do
you think "2012-11-28" does start? Some possible "correct choices":

2012-11-27T16:00:00Z (Googleplex in Mountain View, California)
	2012-11-28T00:00:00Z (UTC)
	2012-11-28T02:00:00Z (Europe/Helsinki, my time zone)
	2012-11-28T11:00:00Z (Ian's time zone, I believe)

Note that all those times are "midnight" in some timezone (and usually
considered official date change in that location). Also note that
"midnight" is happening at some location on earth the very moment you
read this sentence!

I hope that we agree that that date ends about 24 hours (give or take
about one hour if somebody has daylight time change) after the start of
that date.

One would think that we could agree globally on time but normal people
don't even understand the mess that the politicians have created with
timezones and daylight saving time changes.

The problem with absolute time pickers is that there's no way cleanly
fix the issue without normal people understanding the situation. On the
other hand, the problem with non-absolute time pickers is that nobody
really knows what time is meant.

-- 
Mikko

From silviapfeiffer1 at gmail.com  Tue Nov 27 00:40:02 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Tue, 27 Nov 2012 19:40:02 +1100
Subject: [whatwg] [mimesniff] Handling container formats like Ogg
In-Reply-To: <CAJE5ia_H7+itUOk5ua3xvPG-wPtHF3NFLY4ecmuANC-MFv+OCw@mail.gmail.com>
References: <CAH4e3M43dLb+GSE1z=FurHPBJ04pOXrcPo3gi1pz7hRYPF6scQ@mail.gmail.com>
	<CAJE5ia_H7+itUOk5ua3xvPG-wPtHF3NFLY4ecmuANC-MFv+OCw@mail.gmail.com>
Message-ID: <CAHp8n2nrzdZ0uueAz2f0PaShN_UhFMH=HJ2VafmnxYfA65YNCQ@mail.gmail.com>

For Ogg, if you rely on the Ogg files having a Skeleton track [1], it's not
actually difficult at all, since the mime type of the codecs used in the
tracks that Skeleton is describing are explicitly included in Skeleton.

Then all you have to do is check which codec mime types are present to make
to file mime types: http://wiki.xiph.org/MIME_Types_and_File_Extensions ,
e.g. if you find audio/* and video/*, then you have a file mime type of
video/ogg .

HTH.

Cheers,
Silvia.

[1] http://wiki.xiph.org/Ogg_Skeleton_4

On Tue, Nov 27, 2012 at 10:45 AM, Adam Barth <w3c at adambarth.com> wrote:

> I included H.264 sniffing in the spec because some implementors
> specifically asked for it (and it wasn't all that complicated).  For
> Ogg, I'd wait until implementors ask you to include it.
>
> Adam
>
>
> On Mon, Nov 26, 2012 at 2:59 PM, Gordon P. Hemsley <gphemsley at gmail.com>
> wrote:
> > Container formats like Ogg can be used to store many different audio
> > and video formats, all of which can be identified generically as
> > "application/ogg". Determining which individual format to use (which
> > can be identified interchangeably as the slightly-less-generic
> > "audio/ogg" or "video/ogg", or using a 'codecs' parameter, or using a
> > dedicated media type) is much more complex, because they all use the
> > same "OggS" signature. It would requiring actually attempting to parse
> > the Ogg container to determine which audio or video format it is using
> > (perhaps not unsimilar to what is done for MP4 video and what might
> > have to be done with MP3 files without ID3 tags).
> >
> > Would this be something UAs would prefer to handle in their Ogg
> > library, or should I spec it as part of sniffing?
> >
> > --
> > Gordon P. Hemsley
> > me at gphemsley.org
> > http://gphemsley.org/ ? http://gphemsley.org/blog/
>

From mikko.rantalainen at peda.net  Tue Nov 27 00:58:58 2012
From: mikko.rantalainen at peda.net (Mikko Rantalainen)
Date: Tue, 27 Nov 2012 10:58:58 +0200
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50B47772.5030703@peda.net>
References: <50A12B1F.1080200@lamouri.fr>
	<Pine.LNX.4.64.1211200609040.26354@ps20323.dreamhostps.com>
	<50ACC044.2060006@lamouri.fr>
	<Pine.LNX.4.64.1211220344070.15705@ps20323.dreamhostps.com>
	<50B47772.5030703@peda.net>
Message-ID: <50B480D2.6040100@peda.net>

Mikko Rantalainen, 2012-11-27 10:18 (Europe/Helsinki):
> (3) Timezones are subject to future political decisions

If you think this is a real problem, see
http://www.timeanddate.com/news/time/ for examples.

Current examples from the top of the page:

26-Oct-2012 Russia remains on summer time after all
A bill proposing to permanently switch back to winter time in Russia has
been recalled in the Russian Duma. Russians will remain on permanent
summer time until further notice.

25-Oct-2012 (updated 5-Nov-2012) DST in Israel to be extended in 2013
Daylight Saving Time (DST) in Israel will last until October 6, 2013,
instead of Sunday, 8 September, as long as the Knesset approves a bill
before the election in January 2013.

25-Oct-2012 Jordan remains on Summer Time
Jordan's government has canceled the switch from Daylight Saving Time to
Standard Time this year. The Middle Eastern country was originally set
to turn the clocks back 1 hour on Friday, October 26, 2012.

Notice the date for the piece of news in the last one! The decision was
made only two (2) days before the time was supposed to change. Good luck
on getting *any* computer system to follow this logic.

-- 
Mikko

From hsivonen at iki.fi  Tue Nov 27 01:39:02 2012
From: hsivonen at iki.fi (Henri Sivonen)
Date: Tue, 27 Nov 2012 11:39:02 +0200
Subject: [whatwg] [mimesniff] Handling container formats like Ogg
In-Reply-To: <CAH4e3M43dLb+GSE1z=FurHPBJ04pOXrcPo3gi1pz7hRYPF6scQ@mail.gmail.com>
References: <CAH4e3M43dLb+GSE1z=FurHPBJ04pOXrcPo3gi1pz7hRYPF6scQ@mail.gmail.com>
Message-ID: <CAJQvAufOCj9Y+UPXoanoHzOiHGErrLXPnWFeUjbb-Mkedr9j2w@mail.gmail.com>

On Tue, Nov 27, 2012 at 12:59 AM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> Container formats like Ogg can be used to store many different audio
> and video formats, all of which can be identified generically as
> "application/ogg". Determining which individual format to use (which
> can be identified interchangeably as the slightly-less-generic
> "audio/ogg" or "video/ogg", or using a 'codecs' parameter, or using a
> dedicated media type) is much more complex, because they all use the
> same "OggS" signature. It would requiring actually attempting to parse
> the Ogg container to determine which audio or video format it is using
> (perhaps not unsimilar to what is done for MP4 video and what might
> have to be done with MP3 files without ID3 tags).
>
> Would this be something UAs would prefer to handle in their Ogg
> library, or should I spec it as part of sniffing?

What would be the use case for handling it as part of sniffing layer?

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/

From froidure_nicolas at yahoo.fr  Tue Nov 27 08:54:59 2012
From: froidure_nicolas at yahoo.fr (Nicolas Froidure)
Date: Tue, 27 Nov 2012 17:54:59 +0100
Subject: [whatwg] 'datetime-local' and 'datetime' comments
In-Reply-To: <50B47C51.40003@peda.net>
References: <50A12B1F.1080200@lamouri.fr> <50A22635.2090900@yahoo.fr>
	<50B47C51.40003@peda.net>
Message-ID: <50B4F063.5020008@yahoo.fr>

On 27/11/2012 09:39, Mikko Rantalainen wrote:
> Nicolas Froidure, 2012-11-13 12:51 (Europe/Helsinki):
>    
>> In my opinion, it's normal that datetime and datetime-local have
>> timezone and date/time don't. A date is timezone independant and time is
>> more a duration then a time relative to a particular instant of a
>> particular day.
>>      
> Unfortunately, "date" is definitely NOT timezone independent. When do
> you think "2012-11-28" does start? Some possible "correct choices":
>
> 	2012-11-27T16:00:00Z (Googleplex in Mountain View, California)
> 	2012-11-28T00:00:00Z (UTC)
> 	2012-11-28T02:00:00Z (Europe/Helsinki, my time zone)
> 	2012-11-28T11:00:00Z (Ian's time zone, I believe)
>    
I think you're wrong. My birthday is 1983-04-28, i'll not program a 
party on 2012-04-29 if i live on a different timezone. I don't know the 
time of my birth, i just remember the date. So, for me a date is a 
generalization of a time with an error range of 24h.

If you want to save a time, just use a datetime field. I you ask a date 
you probably won't to save a precise time, just a day. Christmas day, a 
birthday or the mother's day.

Given that things, i suppose a date is timezone independent.
---
Nicolas Froidure

From gphemsley at gmail.com  Tue Nov 27 09:19:13 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Tue, 27 Nov 2012 12:19:13 -0500
Subject: [whatwg] [mimesniff] Handling container formats like Ogg
In-Reply-To: <CAJQvAufOCj9Y+UPXoanoHzOiHGErrLXPnWFeUjbb-Mkedr9j2w@mail.gmail.com>
References: <CAH4e3M43dLb+GSE1z=FurHPBJ04pOXrcPo3gi1pz7hRYPF6scQ@mail.gmail.com>
	<CAJQvAufOCj9Y+UPXoanoHzOiHGErrLXPnWFeUjbb-Mkedr9j2w@mail.gmail.com>
Message-ID: <CAH4e3M4s3VWDkaA4WVuH2WEs=r-gLYhUahZBcKDiDtwW9LXrVw@mail.gmail.com>

On Tue, Nov 27, 2012 at 4:39 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
> On Tue, Nov 27, 2012 at 12:59 AM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
>> Would this be something UAs would prefer to handle in their Ogg
>> library, or should I spec it as part of sniffing?
>
> What would be the use case for handling it as part of sniffing layer?

I don't know; that's why I'm asking! :)

Is it sufficient to sniff just for "application/ogg" and then let the
UA's Ogg library determine whether or not the contents of the file can
be handled? (I'm sensing the consensus is yes.)

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From gphemsley at gmail.com  Tue Nov 27 10:03:43 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Tue, 27 Nov 2012 13:03:43 -0500
Subject: [whatwg] [mimesniff] Audio and video sniffing
In-Reply-To: <op.woe3vdpzidj3kv@device-56497e>
References: <CAH4e3M6rV+GSODuD344KxX+hyW4ChtJ__05snZfG=FLdOQ4JNQ@mail.gmail.com>
	<op.woe3vdpzidj3kv@device-56497e>
Message-ID: <CAH4e3M62xKk4Bp7HJck8yfztqJjLCtN1H9n3LosSyz0eiiVN4Q@mail.gmail.com>

Done: https://github.com/whatwg/mimesniff/commit/77ee676c8852f4e76facd7d6c1174ac0ec41696e

Note that this also affects the "media type sniffing algorithm" and
the "rules for identifying an unknown media type".

On Tue, Nov 27, 2012 at 12:51 AM, Simon Pieters <simonp at opera.com> wrote:
> On Mon, 26 Nov 2012 23:38:02 +0100, Gordon P. Hemsley <gphemsley at gmail.com>
> wrote:
>
>> Upon looking through the code for Gecko's media sniffing, I noticed
>> that they seem to combine sniffing for audio and video elements. Given
>> that Opera has said that it uses the specific sniffing algorithms, and
>> that some media containers (like Ogg) can be used for either audio or
>> video, I wonder if it would make sense to combine audio and video
>> sniffing under a single audiovisual category? This would affect the
>> "matching audio/video type pattern" sections and the "sniffing
>> audio/video specifically" sections.
>>
>> Any objections? Other thoughts?
>
>
> Yes, I think it makes sense to have the same sniffing for both. <audio> is
> like <video> without the rendering area.
>
> --
> Simon Pieters
> Opera Software

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From l.laurent.p at gmail.com  Tue Nov 27 10:52:28 2012
From: l.laurent.p at gmail.com (Laurent Perez)
Date: Tue, 27 Nov 2012 19:52:28 +0100
Subject: [whatwg] Support of link rel=prefetch
Message-ID: <CACqpeO-h7pwgZtZ__SfNNih6H06h7dGwuTQetcZJtZf0uycdiQ@mail.gmail.com>

I'm testing the prefetch attribute of <link> tags described at
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-prefetch

I've only seen it work on Firefox desktop and mobile, on Chrome desktop,
and on Android 4.0 stock browser. Mobile Safari, Opera, IE10 or Chrome for
Android do not support it.

Has this feature been abandoned because of lack of vendors interest ?

laurent

----
http://laurentperez.fr
J2EE tips and best practices

From w3c at adambarth.com  Tue Nov 27 12:41:05 2012
From: w3c at adambarth.com (Adam Barth)
Date: Tue, 27 Nov 2012 12:41:05 -0800
Subject: [whatwg] Support of link rel=prefetch
In-Reply-To: <CACqpeO-h7pwgZtZ__SfNNih6H06h7dGwuTQetcZJtZf0uycdiQ@mail.gmail.com>
References: <CACqpeO-h7pwgZtZ__SfNNih6H06h7dGwuTQetcZJtZf0uycdiQ@mail.gmail.com>
Message-ID: <CAJE5ia90RRapAiky8QWfouo+em0rXCtpNDfv_r7amebeG-xNEw@mail.gmail.com>

I consider it not working on Chrome for Android a bug.  It's something
we'd like to fix.

Adam

On Tue, Nov 27, 2012 at 10:52 AM, Laurent Perez <l.laurent.p at gmail.com> wrote:
> Hi
>
> I'm testing the prefetch attribute of <link> tags described at
> http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-prefetch
>
> I've only seen it work on Firefox desktop and mobile, on Chrome desktop,
> and on Android 4.0 stock browser. Mobile Safari, Opera, IE10 or Chrome for
> Android do not support it.
>
> Has this feature been abandoned because of lack of vendors interest ?
>
> laurent
>
> ----
> http://laurentperez.fr
> J2EE tips and best practices

From giles at mozilla.com  Tue Nov 27 13:19:13 2012
From: giles at mozilla.com (Ralph Giles)
Date: Tue, 27 Nov 2012 13:19:13 -0800
Subject: [whatwg] metadata attribute for media
In-Reply-To: <50B406DA.70708@mozilla.com>
References: <505BA783.2030202@mozilla.com> <op.wlac76p9sr6mfa@kirk>
	<50B406DA.70708@mozilla.com>
Message-ID: <50B52E51.1000707@mozilla.com>

On 12-11-26 4:18 PM, Ralph Giles wrote:

> interface HTMLMediaElement {
>   ...
>   object getMetadata();
> };
> 
> After the metadataloaded event fires, this method would return a new
> object containing a copy of the metadata read from the resource, in
> whatever format the decoder implementation supplies. It would be up to
> the caller to do any semantic interpretation. The same method should be
> present on AudioTrack, VideoTrack, (TextTrack?) and Image elements.

The prefixed version of this in Firefox is documented in the 'Methods'
section of https://developer.mozilla.org/en-US/docs/DOM/HTMLMediaElement

-r

From silviapfeiffer1 at gmail.com  Tue Nov 27 13:28:42 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 28 Nov 2012 08:28:42 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
	<CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
	<CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>
	<Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>
Message-ID: <CAHp8n2=EWa6_3CBTsJeafiQBisWbF=fOd1cCXTCcxe=gDVAAtg@mail.gmail.com>

On Sat, Nov 17, 2012 at 11:01 AM, Ian Hickson <ian at hixie.ch> wrote:
[..]

>
> On Sat, 10 Nov 2012, Maciej Stachowiak wrote:
> >
> > I personally think <main> would be useful. I don't think it has a huge
> > benefit, but it has modest benefits, like <aside>, <header>, <footer>
> > and <section>. I also think the implementation costs are low. The
> > reasons I think it has some benefits:
> >
> > - Even though heuristics (such as the scooby-doo algorithm or even
> > guesses based on role or class, or the layout) will always be necessary
> > in some cases, it's still good to have a simple and relatively
> > trustworthy marker of the main content. This is useful both for
> > accessibility purposes and for other browser features that want to find
> > the main content. In many cases, we have found that even when semantics
> > can be heuristically inferred, having an explicit marker is still
> > useful. For example, you can usually guess that some text is an address,
> > but we still have a microformat that helps identify such data
> > unambiguously.
>
> But we already have this. The main content is whatever content isn't
> marked up as not being main content (anything not marked up with <header>,
> <aside>, <nav>, etc).
>

I tried to validate that claim. It's not really possible with today's Web
pages, since they haven't moved to making use of these elements, but I made
some educated guesses as to where they would be used sensibly on a normal
Web page. I have applied this to Google search results, Facebook user
pages, YouTube video pages, and Wikipedia articles as examples of some of
the most used content on the Web. You can see my results at
http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/.

I believe that none of the heuristic approaches work 100% of the time. In
particular Scooby Doo doesn't work because there are far too many
layout-only elements that cannot be grasped with <header>, <aside> etc and
for which we cannot clearly say that the first top-level such element
should be regarded as the main content element.

Hope that bit of research helps.

Regards,
Silvia.

From giles at mozilla.com  Tue Nov 27 14:24:57 2012
From: giles at mozilla.com (Ralph Giles)
Date: Tue, 27 Nov 2012 14:24:57 -0800
Subject: [whatwg] [mimesniff] Handling container formats like Ogg
In-Reply-To: <CAH4e3M4s3VWDkaA4WVuH2WEs=r-gLYhUahZBcKDiDtwW9LXrVw@mail.gmail.com>
References: <CAH4e3M43dLb+GSE1z=FurHPBJ04pOXrcPo3gi1pz7hRYPF6scQ@mail.gmail.com>
	<CAJQvAufOCj9Y+UPXoanoHzOiHGErrLXPnWFeUjbb-Mkedr9j2w@mail.gmail.com>
	<CAH4e3M4s3VWDkaA4WVuH2WEs=r-gLYhUahZBcKDiDtwW9LXrVw@mail.gmail.com>
Message-ID: <50B53DB9.3070601@mozilla.com>

On 12-11-27 9:19 AM, Gordon P. Hemsley wrote:

> Is it sufficient to sniff just for "application/ogg" and then let the
> UA's Ogg library determine whether or not the contents of the file can
> be handled? (I'm sensing the consensus is yes.)

I think so.

Defining a codec enumerating algorithm and mime type decision tree is
going to be several pages of spec for container formats like Ogg and
Matroska.

As an example, the 'file' tool reads the first codec header present in
an Ogg file, which can be found at a set of fixed offsets. This lets it
get some useful information for a lot of files, especially since it's
RECOMMENDED that primary codecs are listed first. I.e. theora should be
first in a 'video/ogg', opus should be first in an 'audio/ogg; codecs=opus'.

But files can be muxed without following the priority rule and will
still play fine, and there can be a 'skeleton' header in front of the
other codec data, obcuring primary role. Just looking at fixed offsets
isn't sufficient to distinguish audio and video reliably.

IMHO,
 -r

From ian at hixie.ch  Tue Nov 27 15:35:08 2012
From: ian at hixie.ch (Ian Hickson)
Date: Tue, 27 Nov 2012 23:35:08 +0000 (UTC)
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2=EWa6_3CBTsJeafiQBisWbF=fOd1cCXTCcxe=gDVAAtg@mail.gmail.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
	<CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
	<CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>
	<Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>
	<CAHp8n2=EWa6_3CBTsJeafiQBisWbF=fOd1cCXTCcxe=gDVAAtg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211272321210.12469@ps20323.dreamhostps.com>

On Wed, 28 Nov 2012, Silvia Pfeiffer wrote:
> >
> > But we already have this. The main content is whatever content isn't 
> > marked up as not being main content (anything not marked up with 
> > <header>, <aside>, <nav>, etc).
> 
> I tried to validate that claim. It's not really possible with today's 
> Web pages, since they haven't moved to making use of these elements, but 
> I made some educated guesses as to where they would be used sensibly on 
> a normal Web page. I have applied this to Google search results, 
> Facebook user pages, YouTube video pages, and Wikipedia articles as 
> examples of some of the most used content on the Web. You can see my 
> results at 
> http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/.

I think you're massively over-complicating what needs to be authored here.

For example, with a Google search, just mark up everything up to the 
id="main" in a <header>, mark up the id="top_nav" as a <nav>, and mark up 
the id="foot" in a <footer>, and what's left is the main content. (Note 
that this does _not_ map to what the authors would have marked up using 
<main>, as determined by looking at what they marked up with id="main" -- 
that contains the navigation.)

I don't have a Facebook account so haven't checked that one.

I don't know what you'd mark up on youtube.com because I don't know what 
is the main content there. But marking up all the children of 
id="body-container" as <header> except the id="page-container" child, and 
marking the id="guide-container" and first class="branded-page-v2- 
secondary-col" as <aside>, would make the stream in the middle be the 
first "main" content, which is probably what the page author intended. 
This again doesn't match what the author would likely use for <main> -- 
id="content" -- which contains the second of those <aside>s currently.

Wikipedia already has role=main on the appropriate element, and all the 
stuff that isn't main (except the appeal) comes after that, so they're 
fine either way, even without ARIA. Their <div>s map pretty directly to 
the elements in HTML so that the algorithm I describe above would surface 
the main content fine.

> I believe that none of the heuristic approaches work 100% of the time.

Sure. Nor would <main>. However, on pages written correctly, <main> would 
work no better than what HTML already has. Moreover, the difference is 
that this is <main>'s only purpose, and so the fact that it doesn't solve 
it all the time means it can't be relied upon, whereas the other elements 
have other purposes, so that they don't satisfy this 100% of the time 
doesn't make them pointless.

From ian at hixie.ch  Tue Nov 27 16:12:08 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 28 Nov 2012 00:12:08 +0000 (UTC)
Subject: [whatwg] Menus and Toolbars
Message-ID: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>

(If you're cc'ed, your opinion likely affects implementations of this and 
so your input is especially requested. See the question at the end. If you 
reply to this, please strip the cc list as the mailing list software will 
otherwise block your post for having too many cc's. Thanks.)

There's a big section in the spec that tries to do three things:

* context menus
 * toolbars
 * menu buttons

Right now it's not implemented by anyone, though Firefox has a variant.

http://whatwg.org/html/#the-menu-element

This section has two big problems:

1. Styling of toolbars and menu buttons is just not defined.

Toolbars could be a purely stylistic issue, to be solved either excluively 
by CSS, or CSS plus a component/widget binding model (whatever solution we 
end up with for that).

Menu buttons are a real widget, though, so we can't just leave them to CSS 
styling of <div>s, there needs to be some real styling going on. Right 
now, because of the algorithm mentioned in #2 below, this is very 
complicated. I'll get back to this.

(Styling for context menus is not a big deal, they just use native UI.)

2. Nobody is implementing it, in particular, the algorithm that converts 
HTML elements into a menu structure seems unpopular.

Right now, the spec has this algorithm that defines how to map existing 
HTML semantics to a context menu or menu button (or toolbar, though the 
latter is less important if we move to a pure-CSS rendering model for 
toolbars, since we'd just drop the algorithm for them then).

The idea here is that you don't have to use JavaScript to replicate the 
effects of existing semantics. For example, if you want a menu button 
which acts as a navigation mechanism, you just put <a> elements in your 
markup and they automatically get turned into menu items.

There's also a generic <command> element for when you don't need an 
existing element to be used. Firefox essentially only implements this, 
though it's called <menuitem> in Firefox. <command> also supports an 
attribute that points at other elements to indirectly define features.

To move forward on this, here are some proposals:

#1: Drop <menu> and all related features. I don't think we should do this, 
but if we can't get agreement on what to implement, this is the only 
option left, so it's on the table.

#2: A design that supports context menus and menu buttons using dedicated 
markup, with support for indirect defining of commands.

First, we make <menu type=""> take three values: "toolbar", which just 
means to render the element using CSS (the default value for legacy pages, 
too), and "context" and "button", which define menus. "context" menus 
would be hidden by default, "button" menus would render as a button, 
which, when clicked, shows the menu. contextmenu="" can be used to point 
to a <menu type=contextmenu>.

The <menu> element in "context" and "button" modes would only have three 
elements as descendants: <menuitem> elements, <menu> elements, and <hr> 
elements. (Or maybe no <hr>s, and we do separators by using groups of 
<menu> elements without labels.) Other children are ignored.

<menuitem> elements would just have a label="" attribute and, optionally, 
a command="" attribute. The command="" attribute would work as it does in 
the spec now, deferring to some existing element. When the menu item is 
selected, it would fire click on the <menuitem>, and then as a default 
action do whatever the action of the command="" is, if specified. (We can 
talk about whether to bother supporting icons in the <menuitem>, and if so 
how, especially given high-res screens, but that's a minor detail.)

With type=button, CSS would apply to the <menu> and <menuitem> elements, 
maybe with a limited set of properties applying. Long term, we look to XBL 
or Web components or whatever for styling.

We drop <command> entirely.

#2a: Same as #2, except we keep <command> as a way to introduce commands 
without using existing elements.

#3: We forget the non-JS case; so, the same as #2, but <menuitem> doesn't 
get a command="" attribute. We add radio menu items, checkbox menu items, 
and the like, over time, as features on <menuitem>. (Defined much like 
<command> has some of them defined today.)

#4: We do what the spec has now.

#5: We do what the spec has now, except we change the type=toolbar to just 
be rendered in CSS (and remove type=list, making toolbar the default).

#6: Your idea here.

So, implementors: Which of these would you be willing to implement? Are 
there constraints I've not thought of? Are there features that we need to 
deal with that I haven't mentioned above? Are there use cases that we 
should just abandon that could simplify the solution drastically?

From jackalmage at gmail.com  Tue Nov 27 18:42:16 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Tue, 27 Nov 2012 18:42:16 -0800
Subject: [whatwg] <ruby> markup problems
Message-ID: <CAAWBYDDgsMnpy4AVanu528gDNXCFyEeQQK2VDLrJ5aB3G2aapw@mail.gmail.com>

The current HTML <ruby> markup has a few issues where it does not
properly solve the relevant use-cases.  In this email I'll outline
these problems, and suggest some simple fixes that maintain the
overall simplicity of the ruby model.

1. Inlining ruby
=============

The current ruby model explicitly uses a "column-based" model of ruby,
where runs of base text and ruby text must alternate in the markup, so
that ruby text is associated with the immediately preceding ruby base.

This does *not* work well for common ruby inlining cases.  For
example, the word Tokyo is written as ?? in kanji and ????? in kana.
The base-text pairs are ?-?? ?-???, and the ruby markup must create
those associations accordingly. However, when rendered inline, the
correct rendering is ??(?????) with the word kept together as one
unit, not ?(??)?(???).  The current ruby model in HTML, though,
requires that you either mark up the ruby correctly and get the latter
display, or incorrectly group the entire thing as one ruby text over
one ruby base to get the former display.

This is important, because inlining is not just a fallback measure for
down-level clients.  Inlining is often done as a legitimate stylistic
choice, such as when there's only a small amount of ruby in the text
(to avoid the increased line-height on the few lines that contain
ruby) or when the base text is already small (to avoid making the ruby
text unreadably small).

This can be solved easily by also allowing a "row-based" model, where
runs of <rb> elements can be followed by runs of <rt> elements, and
they're matched up index-wise.  If you can then switch back to <rb>,
you still retain the convenience of "column-based" when that's
sufficient.

2. Double-sided ruby
=================

When you want to create double-sided ruby, with the ruby text on both
sides of base text, the current HTML model posits two separate and
fairly different markup models.

In the first, when the group boundaries for both ruby text runs are
the same, it allows you to have two <rt>s following an <rb>, with the
obvious meaning.

In the second, when the group boundaries do *not* line up (in
particular, for the common case where one line of ruby is
per-character and the other is for the whole group, such as with a
pinyin and English translation), it requires you to nest two <ruby>
elements, with the inner one supplying the per-character annotations
and the outer supplying the whole-group ones.

Having to learn and use two different markup patterns for two nearly
identical use-cases is sub-optimal for authors.  It would be best if
they could just learn one model that works for both.

On the implementation side, this also requires two different layout
models for essentially the exact same thing.  This is unnecessarily
complicated; again, one simple way to get both would be preferred.

This is easy to address.  Add an <rtc> element (name taken from the
XHTML Ruby module), which is used for the second line of text.  You
can fill an <rtc> with <rt> elements, in which case they match up
index-wise with the preceding run of <rb> elements.  The last <rt>
(or, if no <rt>s were given at all, the naked text that was implicitly
wrapped in an <rt>) automatically spans the remaining bases in the
preceding run.

This makes both cases trivial.  If both runs of ruby are
per-character, you can just write:

Or, in the pure column-based model:

Alternately, if the second line of ruby text spans the entire group,
that's also trivial, and very simlar:

As you can see, the only difference is that the <rtc> contains a
single (implicit) <rt>, rather than two <rt>s.  It seems plainly
obviously that this is simpler for authors; it's also simpler for
implementors, because we don't have to infer that we should be
formatting something as double-ruby from the presence of nested <ruby>
elements.

Based on fantasai's research at
<http://fantasai.inkedblade.net/weblog/2011/ruby/#double> and her
subsequent conversations with i18n folks and CJK publishing experts,
these are the only two real failures of the current markup model.
These two simple changes would make the HTML side of ruby work great;
anything left (like jukugo ruby) can be handled fine by the CSS side
(when we rewrite the Ruby spec to not be sucky).

~TJ

From silviapfeiffer1 at gmail.com  Tue Nov 27 20:28:23 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 28 Nov 2012 15:28:23 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <Pine.LNX.4.64.1211272321210.12469@ps20323.dreamhostps.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
	<CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
	<CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>
	<Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>
	<CAHp8n2=EWa6_3CBTsJeafiQBisWbF=fOd1cCXTCcxe=gDVAAtg@mail.gmail.com>
	<Pine.LNX.4.64.1211272321210.12469@ps20323.dreamhostps.com>
Message-ID: <CAHp8n2nyrUwAPojQSPJdhcTN4B6u9eW7fBm6EhKoT5XUG0EOGA@mail.gmail.com>

On Wed, Nov 28, 2012 at 10:35 AM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 28 Nov 2012, Silvia Pfeiffer wrote:
> > >
> > > But we already have this. The main content is whatever content isn't
> > > marked up as not being main content (anything not marked up with
> > > <header>, <aside>, <nav>, etc).
> >
> > I tried to validate that claim. It's not really possible with today's
> > Web pages, since they haven't moved to making use of these elements, but
> > I made some educated guesses as to where they would be used sensibly on
> > a normal Web page. I have applied this to Google search results,
> > Facebook user pages, YouTube video pages, and Wikipedia articles as
> > examples of some of the most used content on the Web. You can see my
> > results at
> >
> http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/
> .
>
> I think you're massively over-complicating what needs to be authored here.
>
> For example, with a Google search, just mark up everything up to the
> id="main" in a <header>, mark up the id="top_nav" as a <nav>, and mark up
> the id="foot" in a <footer>, and what's left is the main content. (Note
> that this does _not_ map to what the authors would have marked up using
> <main>, as determined by looking at what they marked up with id="main" --
> that contains the navigation.)
>

Agreed. But what the authors have marked up as @id=main is not relevant for
this discussion - it's not what <main> tries to achieve. We need to look at
what is marked up with @role=main and that's a completely different element.

"Google actually placed a @role=main on a different element, namely the one
that encapsulates all the search results." This is where the <main> should
be and that excludes all the columns on the right and left of the search
results.

> I don't know what you'd mark up on youtube.com because I don't know what
> is the main content there.

The feedback that I get from blind users is: "the main content is the video
and I can't find it".

> But marking up all the children of
> id="body-container" as <header> except the id="page-container" child, and
> marking the id="guide-container" and first class="branded-page-v2-
> secondary-col" as <aside>, would make the stream in the middle be the
> first "main" content, which is probably what the page author intended.
>

Actually, no - see above.

> This again doesn't match what the author would likely use for <main> --
> id="content" -- which contains the second of those <aside>s currently.
>

No, the element with @id=content is also not the one that <main> should
contain - see above.

Wikipedia already has role=main on the appropriate element, and all the
> stuff that isn't main (except the appeal) comes after that, so they're
> fine either way, even without ARIA. Their <div>s map pretty directly to
> the elements in HTML so that the algorithm I describe above would surface
> the main content fine.
>

Agreed - it's the simple case.

> I believe that none of the heuristic approaches work 100% of the time.
>
> Sure. Nor would <main>.

When authored correctly or corrected after feedback from blind users, it
will work - and it will always work better than the heuristic approach. In
addition, there is a large enough blind community in the world to make sure
that where it doesn't work they will speak up to get it fixed. For that
reason, <main> is a hint that is always better than any heuristic approach,
in particular as accessibility tools do not support any heuristic
approaches.

Regards,
Silvia.

From ian at hixie.ch  Tue Nov 27 20:45:34 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 28 Nov 2012 04:45:34 +0000 (UTC)
Subject: [whatwg] <ruby> markup problems
In-Reply-To: <CAAWBYDDgsMnpy4AVanu528gDNXCFyEeQQK2VDLrJ5aB3G2aapw@mail.gmail.com>
References: <CAAWBYDDgsMnpy4AVanu528gDNXCFyEeQQK2VDLrJ5aB3G2aapw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211280440540.12469@ps20323.dreamhostps.com>

On Tue, 27 Nov 2012, Tab Atkins Jr. wrote:
>
> The current HTML <ruby> markup has a few issues where it does not 
> properly solve the relevant use-cases.  In this email I'll outline these 
> problems, and suggest some simple fixes that maintain the overall 
> simplicity of the ruby model.

Thanks.

My mail client has many great features, but handles non-ASCII 
embarassingly poorly. To avoid that getting in the way of discussing this 
particular topic, I've filed two bugs from your e-mail and will use them 
to track this specific issue:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20114
   https://www.w3.org/Bugs/Public/show_bug.cgi?id=20115

(As a general rule I encourage people to prefer e-mail for feedback; this 
is an exception.)

From ian at hixie.ch  Tue Nov 27 21:26:00 2012
From: ian at hixie.ch (Ian Hickson)
Date: Wed, 28 Nov 2012 05:26:00 +0000 (UTC)
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <CAHp8n2nyrUwAPojQSPJdhcTN4B6u9eW7fBm6EhKoT5XUG0EOGA@mail.gmail.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
	<CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
	<CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>
	<Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>
	<CAHp8n2=EWa6_3CBTsJeafiQBisWbF=fOd1cCXTCcxe=gDVAAtg@mail.gmail.com>
	<Pine.LNX.4.64.1211272321210.12469@ps20323.dreamhostps.com>
	<CAHp8n2nyrUwAPojQSPJdhcTN4B6u9eW7fBm6EhKoT5XUG0EOGA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211280511270.12469@ps20323.dreamhostps.com>

On Wed, 28 Nov 2012, Silvia Pfeiffer wrote:
> On Wed, Nov 28, 2012 at 10:35 AM, Ian Hickson <ian at hixie.ch> wrote:
> > On Wed, 28 Nov 2012, Silvia Pfeiffer wrote:
> > > >
> > > > But we already have this. The main content is whatever content 
> > > > isn't marked up as not being main content (anything not marked up 
> > > > with <header>, <aside>, <nav>, etc).
> > >
> > > I tried to validate that claim. It's not really possible with 
> > > today's Web pages, since they haven't moved to making use of these 
> > > elements, but I made some educated guesses as to where they would be 
> > > used sensibly on a normal Web page. I have applied this to Google 
> > > search results, Facebook user pages, YouTube video pages, and 
> > > Wikipedia articles as examples of some of the most used content on 
> > > the Web. You can see my results at
> >
> > http://blog.gingertech.net/2012/11/28/the-use-cases-for-a-main-element-in-html/ 
> >
> > I think you're massively over-complicating what needs to be authored 
> > here.
> >
> > For example, with a Google search, just mark up everything up to the 
> > id="main" in a <header>, mark up the id="top_nav" as a <nav>, and mark 
> > up the id="foot" in a <footer>, and what's left is the main content. 
> > (Note that this does _not_ map to what the authors would have marked 
> > up using <main>, as determined by looking at what they marked up with 
> > id="main" -- that contains the navigation.)
> 
> Agreed. But what the authors have marked up as @id=main is not relevant 
> for this discussion -

Yes, it is, because by and large that's exactly the element that people 
are going to use <main> for.

Most people aren't going to use <main> for accessibility reasons. That's 
not how most authors think. They'll use it for styling. We have to design 
the language with that in mind. That's why we have things like <header> 
and <nav> and <aside> _instead_ of something like <main>.

> The feedback that I get from blind users is: "the main content is the 
> video and I can't find it".

Then browsers should let blind users have the ability to jump to video 
elements. No need for the page to be marked up at all being <video>.

(But not that there's no video on the youtube.com home page, unless you 
mean the ad.)

> When authored correctly or corrected after feedback from blind users, it
> will work -

Exactly. In other words, it won't work, because it's unlikely to be 
authored correctly, and feedback from blind users by and large has no 
effect on sites.

There's also the assumption that what you want is just to jump to a part 
of the page, rather than read the page from top to bottom, just skipping 
the parts of the page that aren't hugely interesting, like navigation.
I actually think that's the better UI here. That is, rather than:

"DALLAS - On a rainy night in early Summer, a tiny kitten with..."

...getting:

"Pegasus News. (skipping navigation, press space to hear skipped 
   sections.) Help Charlie the kitten find a new home. (skipping 
   navigation.) DALLAS - On a rainy night in early Summer, a tiny
   kitten with..."

Even in the best-case scenario, <main> gets you the worse UI above, 
whereas using <nav> and <aside> and so forth can get you the second.

http://www.pegasusnews.com/news/2012/nov/27/help-charlie-kitten-find-new-home/

All of this has already been discussed on this mailing list, so this is 
not new information. I would please refer you to the earlier messages on 
this topic. In general, unless there is substantial new information, 
please don't keep posting on a thread in this mailing list -- the list is 
high-traffic enough without us covering old ground (which is unlikely to 
result in a different outcome if nothing has changed).

From silviapfeiffer1 at gmail.com  Wed Nov 28 00:16:15 2012
From: silviapfeiffer1 at gmail.com (Silvia Pfeiffer)
Date: Wed, 28 Nov 2012 19:16:15 +1100
Subject: [whatwg] A plea to Hixie to adopt <main>
In-Reply-To: <Pine.LNX.4.64.1211280511270.12469@ps20323.dreamhostps.com>
References: <CA+ri+V=ZzTWrG40Way=Tj0=H__XoQ02cizBa+3s3hM2y=Rfhxw@mail.gmail.com>
	<CA+ri+Vm=iH-ujUHOWSW-CM6+rYeb49p5NZcyMe++BfWPmpdH9Q@mail.gmail.com>
	<CA+ri+VmVO9TZ1zykohDXLH5pxXd2PkgX3xvTwfs+64+Vx4+Zrg@mail.gmail.com>
	<Pine.LNX.4.64.1211162154030.26354@ps20323.dreamhostps.com>
	<CAHp8n2=EWa6_3CBTsJeafiQBisWbF=fOd1cCXTCcxe=gDVAAtg@mail.gmail.com>
	<Pine.LNX.4.64.1211272321210.12469@ps20323.dreamhostps.com>
	<CAHp8n2nyrUwAPojQSPJdhcTN4B6u9eW7fBm6EhKoT5XUG0EOGA@mail.gmail.com>
	<Pine.LNX.4.64.1211280511270.12469@ps20323.dreamhostps.com>
Message-ID: <CAHp8n2mHCtvY23vpma4DzFwZZ6btqHgoFJEcSKYsb-O8ny2_Jg@mail.gmail.com>

On Wed, Nov 28, 2012 at 4:26 PM, Ian Hickson <ian at hixie.ch> wrote:

>
> All of this has already been discussed on this mailing list, so this is
> not new information. I would please refer you to the earlier messages on
> this topic. In general, unless there is substantial new information,
> please don't keep posting on a thread in this mailing list -- the list is
> high-traffic enough without us covering old ground (which is unlikely to
> result in a different outcome if nothing has changed).
>

I think there are misunderstandings here - in particular about how blind
users perceive a Web page. I was trying to be helpful. It seems the cards
have fallen and we will just need to continue authoring and preaching
@role=main. Sorry about the noise.

Regards,
Silvia.

From l.laurent.p at gmail.com  Wed Nov 28 00:56:03 2012
From: l.laurent.p at gmail.com (Laurent Perez)
Date: Wed, 28 Nov 2012 09:56:03 +0100
Subject: [whatwg] Support of link rel=prefetch
In-Reply-To: <CAJE5ia90RRapAiky8QWfouo+em0rXCtpNDfv_r7amebeG-xNEw@mail.gmail.com>
References: <CACqpeO-h7pwgZtZ__SfNNih6H06h7dGwuTQetcZJtZf0uycdiQ@mail.gmail.com>
	<CAJE5ia90RRapAiky8QWfouo+em0rXCtpNDfv_r7amebeG-xNEw@mail.gmail.com>
Message-ID: <CACqpeO_NLzgyfHDn=bmMFzK1FZXVs=US_gMRxDQgAhof2di6qA@mail.gmail.com>

I can confirm this does not work on Android 4.2 where Chrome is the default
browser. In fact, it does not work on Chrome 23 desktop either.

Adam, should I fill a bug report on https://bugs.webkit.org/ or
http://code.google.com/p/android/issues/list ? I believe this is a Webkit
problem.

Thanks

laurent

On Tuesday, November 27, 2012, Adam Barth <w3c at adambarth.com> wrote:
> I consider it not working on Chrome for Android a bug.  It's something
> we'd like to fix.
>
> Adam
>
>
> On Tue, Nov 27, 2012 at 10:52 AM, Laurent Perez <l.laurent.p at gmail.com>
wrote:
>> Hi
>>
>> I'm testing the prefetch attribute of <link> tags described at
>>
http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-prefetch
>>
>> I've only seen it work on Firefox desktop and mobile, on Chrome desktop,
>> and on Android 4.0 stock browser. Mobile Safari, Opera, IE10 or Chrome
for
>> Android do not support it.
>>
>> Has this feature been abandoned because of lack of vendors interest ?
>>
>> laurent
>>
>> ----
>> http://laurentperez.fr
>> J2EE tips and best practices
>

-- 
http://laurentperez.fr
J2EE tips and best practices

From fredandw at live.com  Wed Nov 28 04:01:27 2012
From: fredandw at live.com (Fred Andrews)
Date: Wed, 28 Nov 2012 12:01:27 +0000
Subject: [whatwg] Menus and Toolbars
In-Reply-To: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
Message-ID: <BLU002-W142BAA3F982A3381E7632EDAA5D0@phx.gbl>

Dear Ian,

Thank you opening a discussion about these interactive elements.  It would be disappointing to see these abandoned, for those who would like to see more interactive non-javascript content.

I would note that CSS alone is able to implement styled menus but only for 'hover to activate' and not for 'click to activate'.  Might there be an alternative approach using a 'click to toggle' property on elements that might allow CSS alone to implement click activated menus etc?

cheers
Fred

> Date: Wed, 28 Nov 2012 00:12:08 +0000
> From: ian at hixie.ch
> To: whatwg at whatwg.org
> CC: jackalmage at gmail.com; dglazkov at chromium.org; tkent at chromium.org; rniwa at webkit.org; eoconnor at apple.com; koivisto at iki.fi; jan.varga at gmail.com; adele at apple.com; jonlee at apple.com; simonp at opera.com; hsivonen at iki.fi; jgraham at opera.com; mounir at lamouri.fr; jonas at sicking.cc; ojan at chromium.org
> Subject: [whatwg] Menus and Toolbars
> 
> 
> (If you're cc'ed, your opinion likely affects implementations of this and 
> so your input is especially requested. See the question at the end. If you 
> reply to this, please strip the cc list as the mailing list software will 
> otherwise block your post for having too many cc's. Thanks.)
> 
> There's a big section in the spec that tries to do three things:
> 
>  * context menus
>  * toolbars
>  * menu buttons
> 
> Right now it's not implemented by anyone, though Firefox has a variant.
> 
>    http://whatwg.org/html/#the-menu-element
> 
> This section has two big problems:
> 
> 1. Styling of toolbars and menu buttons is just not defined.
> 
> Toolbars could be a purely stylistic issue, to be solved either excluively 
> by CSS, or CSS plus a component/widget binding model (whatever solution we 
> end up with for that).
> 
> Menu buttons are a real widget, though, so we can't just leave them to CSS 
> styling of <div>s, there needs to be some real styling going on. Right 
> now, because of the algorithm mentioned in #2 below, this is very 
> complicated. I'll get back to this.
> 
> (Styling for context menus is not a big deal, they just use native UI.)
> 
> 
> 2. Nobody is implementing it, in particular, the algorithm that converts 
> HTML elements into a menu structure seems unpopular.
> 
> Right now, the spec has this algorithm that defines how to map existing 
> HTML semantics to a context menu or menu button (or toolbar, though the 
> latter is less important if we move to a pure-CSS rendering model for 
> toolbars, since we'd just drop the algorithm for them then).
> 
> The idea here is that you don't have to use JavaScript to replicate the 
> effects of existing semantics. For example, if you want a menu button 
> which acts as a navigation mechanism, you just put <a> elements in your 
> markup and they automatically get turned into menu items.
> 
> There's also a generic <command> element for when you don't need an 
> existing element to be used. Firefox essentially only implements this, 
> though it's called <menuitem> in Firefox. <command> also supports an 
> attribute that points at other elements to indirectly define features.
> 
> 
> To move forward on this, here are some proposals:
> 
> #1: Drop <menu> and all related features. I don't think we should do this, 
> but if we can't get agreement on what to implement, this is the only 
> option left, so it's on the table.
> 
> 
> #2: A design that supports context menus and menu buttons using dedicated 
> markup, with support for indirect defining of commands.
> 
> First, we make <menu type=""> take three values: "toolbar", which just 
> means to render the element using CSS (the default value for legacy pages, 
> too), and "context" and "button", which define menus. "context" menus 
> would be hidden by default, "button" menus would render as a button, 
> which, when clicked, shows the menu. contextmenu="" can be used to point 
> to a <menu type=contextmenu>.
> 
> The <menu> element in "context" and "button" modes would only have three 
> elements as descendants: <menuitem> elements, <menu> elements, and <hr> 
> elements. (Or maybe no <hr>s, and we do separators by using groups of 
> <menu> elements without labels.) Other children are ignored.
> 
> <menuitem> elements would just have a label="" attribute and, optionally, 
> a command="" attribute. The command="" attribute would work as it does in 
> the spec now, deferring to some existing element. When the menu item is 
> selected, it would fire click on the <menuitem>, and then as a default 
> action do whatever the action of the command="" is, if specified. (We can 
> talk about whether to bother supporting icons in the <menuitem>, and if so 
> how, especially given high-res screens, but that's a minor detail.)
> 
> With type=button, CSS would apply to the <menu> and <menuitem> elements, 
> maybe with a limited set of properties applying. Long term, we look to XBL 
> or Web components or whatever for styling.
> 
> We drop <command> entirely.
> 
> 
> #2a: Same as #2, except we keep <command> as a way to introduce commands 
> without using existing elements.
> 
> 
> #3: We forget the non-JS case; so, the same as #2, but <menuitem> doesn't 
> get a command="" attribute. We add radio menu items, checkbox menu items, 
> and the like, over time, as features on <menuitem>. (Defined much like 
> <command> has some of them defined today.)
> 
> 
> #4: We do what the spec has now.
> 
> 
> #5: We do what the spec has now, except we change the type=toolbar to just 
> be rendered in CSS (and remove type=list, making toolbar the default).
> 
> 
> #6: Your idea here.
> 
> 
> So, implementors: Which of these would you be willing to implement? Are 
> there constraints I've not thought of? Are there features that we need to 
> deal with that I haven't mentioned above? Are there use cases that we 
> should just abandon that could simplify the solution drastically?
> 
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

From gphemsley at gmail.com  Wed Nov 28 09:18:49 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Wed, 28 Nov 2012 12:18:49 -0500
Subject: [whatwg] [mimesniff] Sniffing archives
Message-ID: <CAH4e3M7-K+5+gzd6mVHJVcx2TE7OWZCho16Z3=2d7WGZ9Ui+qQ@mail.gmail.com>

The mimesniff spec currently includes signatures for ZIP, gzip, and
RAR archive formats. However, no major browser seems to support them
natively (they all prompt for download), and it's not clear whether
the type detection is a product of the browser code or the OS, or
whether it is used beyond choosing an appropriate file extension for
the download.

Are there any valid usecases for explicitly sniffing archive formats
instead of letting them default to application/octet-stream like other
binary files would? Note that Henri Sivonen has previously raised the
issue that ZIP-based formats (like office suite documents), for
example, would be misleadingly sniffed as ZIP files, and there is no
easy way around that.

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From imelven at mozilla.com  Wed Nov 28 11:48:17 2012
From: imelven at mozilla.com (Ian Melven)
Date: Wed, 28 Nov 2012 11:48:17 -0800 (PST)
Subject: [whatwg] iframe sandbox and top navigation
In-Reply-To: <910775351.1390983.1354131452614.JavaMail.root@mozilla.com>
Message-ID: <951993145.1391696.1354132097113.JavaMail.root@mozilla.com>

Hi,

while working on https://bugzilla.mozilla.org/show_bug.cgi?id=785310 (block setting
window.top.location from a document sandboxed without 'allow-top-navigation') and discussing
the correct behavior with Bobby Holley, I found some interesting differences
between what Chrome and IE have implemented around top navigation and iframe sandbox.

In my testing with Chrome, if you have a sandboxed document with the same
origin as the top level document and the sandboxed document has 'allow-same-origin allow-scripts',
the sandboxed document can NOT navigate the top level document via setting window.top.location 
ie it's blocked. Bobby pointed out that blocking top navigation when the sandboxed document
is same origin with the top level document is difficult, since the sandboxed document
can do window.top.eval('window.location = "http://foo.com"') - this bypasses the block in Chrome
and the top navigation happens.

In IE 10, at least in the Windows 8 consumer preview which is the latest
version i have at the moment unfortunately, you can set window.top.location from a document that's same origin
with the top level document which is contained in an <iframe sandbox = 'allow-same-origin allow-scripts'> ie it doesn't
need allow-top-navigation.

It would be great if the spec could clarify the correct behavior around top navigation
when the sandboxed document is/is not same origin with the top level document.

One option would be for Chrome/Webkit to also block the window.top.eval loophole, but in general
we feel that trying to stop this when the documents are same origin would possibly be problematic. 
Another option would be to not block top navigation when the sandboxed document is same origin
with the top level document (which implies it's been sandboxed with 'allow-same-origin' of course).

>From discussions with Bobby, I think we prefer the second option. The restriction on navigating
window.top would only be applied in the cross domain case.

thanks !
ian

From herenvardo at gmail.com  Wed Nov 28 11:46:35 2012
From: herenvardo at gmail.com (Eduard Pascual)
Date: Wed, 28 Nov 2012 20:46:35 +0100
Subject: [whatwg] Menus and Toolbars
In-Reply-To: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
Message-ID: <CACb57T0cSiR2mwDrr7bMPE+xZWs__NQ3EX=pfCGi+T=ivu98jA@mail.gmail.com>

Greetings,

I'm not a browser implementor, but I have been dealing quite a bit with
menus and other GUI stuff from the web development perspective; so here it
goes some comments I hope implementors might find interesting:

I have put a first example on http://std.dragon-tech.org/mainmenu.png
All you can see there is doable with plain CSS and HTML. It doesn't even
use any CSS3 features. In fact, the whole thing works fine in IE8.
As Fred Andrews mentioned, menus are quite easy to achieve with no
scripting, as long as one stays within "hover-based" menus.
Of course, most of the buttons and items in the screenshot require JS to
actually do anything, but that's because of the app's own complexity.
All the stuff in that window should be pretty much accessible (everything
in there are ul's, li's, and img's with matching @alt and @title for the
toolbar, which contains only shortcuts anyway, and load's of @onclick
attributes that could be easily replaced by <a>'s with @href's on a more
"web-ish" scenario).

In summary, menu bars and tool bars are quite a solved problem

Now, here is when stuff gets serious:
http://std.dragon-tech.org/contextmenu.png
To be honest, I hate most of the code behind that with a passion... and I
wrote it! I get paid for making stuff work, and thus I make stuff work, no
matter what it takes.
The context menu requires JS to display at all. It "overrides" the
browser's native menu (which sometimes would be useful). There is a huge,
empty, transparent div covering the whole iframe (the main area on the
screen with the table on it) just so it can catch clicks and dismiss the
menu. The "context menu key" (that nice thing between right Ctrl and the
"Windows" key) doesn't do anything (doesn't trigger neither my menu nor the
browser's) when the iframe has focus.
Don't get me wrong, I quite love what I pulled off, and so do most of the
app's users; but I loathe the truckload of crap code I have to feed the
browser for everything to work as intended.

So, in summary, context menus are somewhat achievable with significant
scripting, some creativity, and epic x-browser patience; but it's still a
problem far from solved.

----

As a web developer, what I'd love to see implemented natively would be:

* A mechanism (most probably an attribute + a CSS pseudo-class, or maybe
even recycling :hover) to show click-based menu bars some script-less love.
* A mechanism to deal with context menus in a sane way. It all boils down
to UA's natively handling the showing and dismissing of the menus; and
maybe enabling a mechanism to define a default (did you noticed the bolded
option at the start of the menu on the screenshot? Yay, double-clicking
instead of right-clicking does invoke it, skipping the whole "show the
menu" step! ). That would cause it to work with any native method the
browser or platform already supports for displaying context menus.

As a user, I would hope any context menu implementation grants me the
ultimate control on which menu is used (native vs. app-provided).

Of course, other users, authors, and developers may have other needs, but I
can only talk about the ones that I know about.

Re-capping, my needs could be solved with this (element and attribute names
are meant to be verbose and descriptive, not practical nor "final"):
- A @enable-toggling-hover-state-by-clicking attribute.
- A <context-menu> or similar element, plus a mechanism to "bind" it to
other elements on the page. As long as the browser deals with show/dismiss
logics, I could handle everything else. If it had a @default-action
attribute that would be great, but I could live without it (or, more
likely, toss in a @data-* attribute, and loop through elements bound to the
menu to hack in the double-click handlers).

Regards,
Eduard Pascual

On 28 November 2012 01:12, Ian Hickson <ian at hixie.ch> wrote:

>
> (If you're cc'ed, your opinion likely affects implementations of this and
> so your input is especially requested. See the question at the end. If you
> reply to this, please strip the cc list as the mailing list software will
> otherwise block your post for having too many cc's. Thanks.)
>
> There's a big section in the spec that tries to do three things:
>
>  * context menus
>  * toolbars
>  * menu buttons
>
> Right now it's not implemented by anyone, though Firefox has a variant.
>
>    http://whatwg.org/html/#the-menu-element
>
> This section has two big problems:
>
> 1. Styling of toolbars and menu buttons is just not defined.
>
> Toolbars could be a purely stylistic issue, to be solved either excluively
> by CSS, or CSS plus a component/widget binding model (whatever solution we
> end up with for that).
>
> Menu buttons are a real widget, though, so we can't just leave them to CSS
> styling of <div>s, there needs to be some real styling going on. Right
> now, because of the algorithm mentioned in #2 below, this is very
> complicated. I'll get back to this.
>
> (Styling for context menus is not a big deal, they just use native UI.)
>
>
> 2. Nobody is implementing it, in particular, the algorithm that converts
> HTML elements into a menu structure seems unpopular.
>
> Right now, the spec has this algorithm that defines how to map existing
> HTML semantics to a context menu or menu button (or toolbar, though the
> latter is less important if we move to a pure-CSS rendering model for
> toolbars, since we'd just drop the algorithm for them then).
>
> The idea here is that you don't have to use JavaScript to replicate the
> effects of existing semantics. For example, if you want a menu button
> which acts as a navigation mechanism, you just put <a> elements in your
> markup and they automatically get turned into menu items.
>
> There's also a generic <command> element for when you don't need an
> existing element to be used. Firefox essentially only implements this,
> though it's called <menuitem> in Firefox. <command> also supports an
> attribute that points at other elements to indirectly define features.
>
>
> To move forward on this, here are some proposals:
>
> #1: Drop <menu> and all related features. I don't think we should do this,
> but if we can't get agreement on what to implement, this is the only
> option left, so it's on the table.
>
>
> #2: A design that supports context menus and menu buttons using dedicated
> markup, with support for indirect defining of commands.
>
> First, we make <menu type=""> take three values: "toolbar", which just
> means to render the element using CSS (the default value for legacy pages,
> too), and "context" and "button", which define menus. "context" menus
> would be hidden by default, "button" menus would render as a button,
> which, when clicked, shows the menu. contextmenu="" can be used to point
> to a <menu type=contextmenu>.
>
> The <menu> element in "context" and "button" modes would only have three
> elements as descendants: <menuitem> elements, <menu> elements, and <hr>
> elements. (Or maybe no <hr>s, and we do separators by using groups of
> <menu> elements without labels.) Other children are ignored.
>
> <menuitem> elements would just have a label="" attribute and, optionally,
> a command="" attribute. The command="" attribute would work as it does in
> the spec now, deferring to some existing element. When the menu item is
> selected, it would fire click on the <menuitem>, and then as a default
> action do whatever the action of the command="" is, if specified. (We can
> talk about whether to bother supporting icons in the <menuitem>, and if so
> how, especially given high-res screens, but that's a minor detail.)
>
> With type=button, CSS would apply to the <menu> and <menuitem> elements,
> maybe with a limited set of properties applying. Long term, we look to XBL
> or Web components or whatever for styling.
>
> We drop <command> entirely.
>
>
> #2a: Same as #2, except we keep <command> as a way to introduce commands
> without using existing elements.
>
>
> #3: We forget the non-JS case; so, the same as #2, but <menuitem> doesn't
> get a command="" attribute. We add radio menu items, checkbox menu items,
> and the like, over time, as features on <menuitem>. (Defined much like
> <command> has some of them defined today.)
>
>
> #4: We do what the spec has now.
>
>
> #5: We do what the spec has now, except we change the type=toolbar to just
> be rendered in CSS (and remove type=list, making toolbar the default).
>
>
> #6: Your idea here.
>
>
> So, implementors: Which of these would you be willing to implement? Are
> there constraints I've not thought of? Are there features that we need to
> deal with that I haven't mentioned above? Are there use cases that we
> should just abandon that could simplify the solution drastically?
>
> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

From jackalmage at gmail.com  Wed Nov 28 14:31:43 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Wed, 28 Nov 2012 14:31:43 -0800
Subject: [whatwg] Menus and Toolbars
In-Reply-To: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDBvSML-uKht8Up5_FYKSze=C0DHpLkMqjx=tAd_Hpukmw@mail.gmail.com>

On Tue, Nov 27, 2012 at 4:12 PM, Ian Hickson <ian at hixie.ch> wrote:
> To move forward on this, here are some proposals:
>
> #1: Drop <menu> and all related features. I don't think we should do this,
> but if we can't get agreement on what to implement, this is the only
> option left, so it's on the table.

I'm gonna throw out this option.  Worst case, retaining <menu> solely
for its context-menu additions is necessary - this keeps being
requested over and over again by authors, both of small and large
apps.

> #2: A design that supports context menus and menu buttons using dedicated
> markup, with support for indirect defining of commands.
>
> First, we make <menu type=""> take three values: "toolbar", which just
> means to render the element using CSS (the default value for legacy pages,
> too), and "context" and "button", which define menus. "context" menus
> would be hidden by default, "button" menus would render as a button,
> which, when clicked, shows the menu. contextmenu="" can be used to point
> to a <menu type=contextmenu>.
>
> The <menu> element in "context" and "button" modes would only have three
> elements as descendants: <menuitem> elements, <menu> elements, and <hr>
> elements. (Or maybe no <hr>s, and we do separators by using groups of
> <menu> elements without labels.) Other children are ignored.
>
> <menuitem> elements would just have a label="" attribute and, optionally,
> a command="" attribute. The command="" attribute would work as it does in
> the spec now, deferring to some existing element. When the menu item is
> selected, it would fire click on the <menuitem>, and then as a default
> action do whatever the action of the command="" is, if specified. (We can
> talk about whether to bother supporting icons in the <menuitem>, and if so
> how, especially given high-res screens, but that's a minor detail.)
>
> With type=button, CSS would apply to the <menu> and <menuitem> elements,
> maybe with a limited set of properties applying. Long term, we look to XBL
> or Web components or whatever for styling.
>
> We drop <command> entirely.
>
>
> #2a: Same as #2, except we keep <command> as a way to introduce commands
> without using existing elements.

I assume that the "button" case is meant to still support toolbars,
except that each top-level entry in the toolbar is a separate <menu>
element?  (Thus delegating the actual "toolbar" styling fully to CSS.)

> #3: We forget the non-JS case; so, the same as #2, but <menuitem> doesn't
> get a command="" attribute. We add radio menu items, checkbox menu items,
> and the like, over time, as features on <menuitem>. (Defined much like
> <command> has some of them defined today.)
>
>
> #4: We do what the spec has now.
>
>
> #5: We do what the spec has now, except we change the type=toolbar to just
> be rendered in CSS (and remove type=list, making toolbar the default).
>
>
> #6: Your idea here.
>
>
> So, implementors: Which of these would you be willing to implement? Are
> there constraints I've not thought of? Are there features that we need to
> deal with that I haven't mentioned above? Are there use cases that we
> should just abandon that could simplify the solution drastically?

I'm down with keeping the current "do nothing" behavior, and the
"context menu" behavior.  I like the proposed "button with pop-up
menu" behavior, as a better version of the old toolbar initiative.  I
have no opinion on the rest of the details, as they seem roughly
equivalent.

~TJ

From ash at ashleysheridan.co.uk  Wed Nov 28 14:50:28 2012
From: ash at ashleysheridan.co.uk (Ashley Sheridan)
Date: Wed, 28 Nov 2012 22:50:28 +0000
Subject: [whatwg] Menus and Toolbars
In-Reply-To: <BLU002-W142BAA3F982A3381E7632EDAA5D0@phx.gbl>
References: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
	<BLU002-W142BAA3F982A3381E7632EDAA5D0@phx.gbl>
Message-ID: <9213ede6-ca30-4324-8486-0ee2bbf54e41@email.android.com>

There is a hack that allows css to handle clicks using hidden checkboxes and adjacent :checked siblings. Its not terribly suited for menu-type behavior though.

Fred Andrews <fredandw at live.com> wrote:

>Dear Ian,
>
>Thank you opening a discussion about these interactive elements.  It
>would be disappointing to see these abandoned, for those who would like
>to see more interactive non-javascript content.
>
>I would note that CSS alone is able to implement styled menus but only
>for 'hover to activate' and not for 'click to activate'.  Might there
>be an alternative approach using a 'click to toggle' property on
>elements that might allow CSS alone to implement click activated menus
>etc?
>
>cheers
>Fred
>
>> Date: Wed, 28 Nov 2012 00:12:08 +0000
>> From: ian at hixie.ch
>> To: whatwg at whatwg.org
>> CC: jackalmage at gmail.com; dglazkov at chromium.org; tkent at chromium.org;
>rniwa at webkit.org; eoconnor at apple.com; koivisto at iki.fi;
>jan.varga at gmail.com; adele at apple.com; jonlee at apple.com;
>simonp at opera.com; hsivonen at iki.fi; jgraham at opera.com;
>mounir at lamouri.fr; jonas at sicking.cc; ojan at chromium.org
>> Subject: [whatwg] Menus and Toolbars
>> 
>> 
>> (If you're cc'ed, your opinion likely affects implementations of this
>and 
>> so your input is especially requested. See the question at the end.
>If you 
>> reply to this, please strip the cc list as the mailing list software
>will 
>> otherwise block your post for having too many cc's. Thanks.)
>> 
>> There's a big section in the spec that tries to do three things:
>> 
>>  * context menus
>>  * toolbars
>>  * menu buttons
>> 
>> Right now it's not implemented by anyone, though Firefox has a
>variant.
>> 
>>    http://whatwg.org/html/#the-menu-element
>> 
>> This section has two big problems:
>> 
>> 1. Styling of toolbars and menu buttons is just not defined.
>> 
>> Toolbars could be a purely stylistic issue, to be solved either
>excluively 
>> by CSS, or CSS plus a component/widget binding model (whatever
>solution we 
>> end up with for that).
>> 
>> Menu buttons are a real widget, though, so we can't just leave them
>to CSS 
>> styling of <div>s, there needs to be some real styling going on.
>Right 
>> now, because of the algorithm mentioned in #2 below, this is very 
>> complicated. I'll get back to this.
>> 
>> (Styling for context menus is not a big deal, they just use native
>UI.)
>> 
>> 
>> 2. Nobody is implementing it, in particular, the algorithm that
>converts 
>> HTML elements into a menu structure seems unpopular.
>> 
>> Right now, the spec has this algorithm that defines how to map
>existing 
>> HTML semantics to a context menu or menu button (or toolbar, though
>the 
>> latter is less important if we move to a pure-CSS rendering model for
>
>> toolbars, since we'd just drop the algorithm for them then).
>> 
>> The idea here is that you don't have to use JavaScript to replicate
>the 
>> effects of existing semantics. For example, if you want a menu button
>
>> which acts as a navigation mechanism, you just put <a> elements in
>your 
>> markup and they automatically get turned into menu items.
>> 
>> There's also a generic <command> element for when you don't need an 
>> existing element to be used. Firefox essentially only implements
>this, 
>> though it's called <menuitem> in Firefox. <command> also supports an 
>> attribute that points at other elements to indirectly define
>features.
>> 
>> 
>> To move forward on this, here are some proposals:
>> 
>> #1: Drop <menu> and all related features. I don't think we should do
>this, 
>> but if we can't get agreement on what to implement, this is the only 
>> option left, so it's on the table.
>> 
>> 
>> #2: A design that supports context menus and menu buttons using
>dedicated 
>> markup, with support for indirect defining of commands.
>> 
>> First, we make <menu type=""> take three values: "toolbar", which
>just 
>> means to render the element using CSS (the default value for legacy
>pages, 
>> too), and "context" and "button", which define menus. "context" menus
>
>> would be hidden by default, "button" menus would render as a button, 
>> which, when clicked, shows the menu. contextmenu="" can be used to
>point 
>> to a <menu type=contextmenu>.
>> 
>> The <menu> element in "context" and "button" modes would only have
>three 
>> elements as descendants: <menuitem> elements, <menu> elements, and
><hr> 
>> elements. (Or maybe no <hr>s, and we do separators by using groups of
>
>> <menu> elements without labels.) Other children are ignored.
>> 
>> <menuitem> elements would just have a label="" attribute and,
>optionally, 
>> a command="" attribute. The command="" attribute would work as it
>does in 
>> the spec now, deferring to some existing element. When the menu item
>is 
>> selected, it would fire click on the <menuitem>, and then as a
>default 
>> action do whatever the action of the command="" is, if specified. (We
>can 
>> talk about whether to bother supporting icons in the <menuitem>, and
>if so 
>> how, especially given high-res screens, but that's a minor detail.)
>> 
>> With type=button, CSS would apply to the <menu> and <menuitem>
>elements, 
>> maybe with a limited set of properties applying. Long term, we look
>to XBL 
>> or Web components or whatever for styling.
>> 
>> We drop <command> entirely.
>> 
>> 
>> #2a: Same as #2, except we keep <command> as a way to introduce
>commands 
>> without using existing elements.
>> 
>> 
>> #3: We forget the non-JS case; so, the same as #2, but <menuitem>
>doesn't 
>> get a command="" attribute. We add radio menu items, checkbox menu
>items, 
>> and the like, over time, as features on <menuitem>. (Defined much
>like 
>> <command> has some of them defined today.)
>> 
>> 
>> #4: We do what the spec has now.
>> 
>> 
>> #5: We do what the spec has now, except we change the type=toolbar to
>just 
>> be rendered in CSS (and remove type=list, making toolbar the
>default).
>> 
>> 
>> #6: Your idea here.
>> 
>> 
>> So, implementors: Which of these would you be willing to implement?
>Are 
>> there constraints I've not thought of? Are there features that we
>need to 
>> deal with that I haven't mentioned above? Are there use cases that we
>
>> should just abandon that could simplify the solution drastically?
>> 
>> -- 
>> Ian Hickson               U+1047E                )\._.,--....,'``.   
>fL
>> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
>,.
>> Things that are impossible just take longer.  
>`._.-(,_..'--(,_..'`-.;.'
>

-- 
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

From ian at hixie.ch  Wed Nov 28 16:42:06 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 00:42:06 +0000 (UTC)
Subject: [whatwg] Adding crossorigin="" to more elements
In-Reply-To: <503D0918.1010203@mit.edu>
References: <503D0918.1010203@mit.edu>
Message-ID: <Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>

On Thu, 1 Mar 2012, Robert Kieffer wrote:
>
> For reasons documented in 
> https://bugzilla.mozilla.org/show_bug.cgi?id=696301, I?d like to propose 
> that support for the ?crossorigin? attribute be added to SCRIPT tags.
> 
> tl;dr - When applied to window.onerror information, the same-origin 
> policy makes it near-impossible to host script resources on a CDN, while 
> simultaneously using window.onerror to gather information about JS 
> errors.

Done.

On Tue, 28 Aug 2012, Boris Zbarsky wrote:
>
> I just added support for <link rel="stylesheet" crossorigin> in 
> Gecko.[1] Such links are subject to CORS checks if the load is 
> cross-site, and the sheet load will fail if the CORS check fails.  If 
> the CORS check succeeds, script in the page will be able to script the 
> cross-site stylesheet.
> 
> This allows stylesheets served from a CDN to be scripted by the page if 
> desired, so I would like to propose that we add this feature to the 
> spec.

Done, at least on the HTML side. For now it just makes .sheet return null 
for cross-origin resources. If that's not quite right, please update this 
bug with the details:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703

...and I'll try to fix it when I update that part of the spec (the 
CSSOM/HTML coordination).

> An open issue: what to do about @import?  I haven't done anything magic 
> here yet.  Inheriting the CORS mode from the importing sheet is a bit 
> weird, and I wasn't quite sure I wanted to make CSS syntax changes at 
> this time.

Inheriting the mode isn't so bad, all it really does is decide whether or 
not to send an Origin header.

On Tue, 28 Aug 2012, Boris Zbarsky wrote:
> 
> If the CORS mode is inherited from the importing sheet, then I think the 
> "origin" for the fetch should be the page, not the importing sheet, 
> since the page is what would get access to the stylesheet data.

Right, the origin of the importing sheet in this situation is the origin 
of the page that imported it, not the origin of its URL. That's what CORS 
does, it changes the effective origin of a resource from being the origin 
its URL would suggest it had, to being the origin of its caller.

> Maybe this is OK, but it's non-obvious; usually for security purposes 
> the importing sheet is what affects things like can-load checks, Referer 
> headers, etc.

Presumably a CORS-same-origin sheet would use the security characteristics 
of the page, since the page can make the style sheet dance as if it was 
its puppet.

Anyway, that part of it belongs in CSS/CSSOM.

From ian at hixie.ch  Wed Nov 28 16:50:20 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 00:50:20 +0000 (UTC)
Subject: [whatwg] Prerendering and APIs
In-Reply-To: <4F832C29.4090605@mit.edu>
References: <CAB2HWxj=v6pvRA4VPrN4gTrKNe69yvTraR3E3diPx7DBWEoQkg@mail.gmail.com>
	<CAB2HWxij6Km-5NeS-dgmnP=K13Y3yes9K2J6pfwQcV2m0FGeFQ@mail.gmail.com>
	<4F832C29.4090605@mit.edu>
Message-ID: <Pine.LNX.4.64.1211290045190.1991@ps20323.dreamhostps.com>

On Mon, 9 Apr 2012, Boris Zbarsky wrote:
> On 4/9/12 2:16 PM, Gavin Peters (?????) wrote:
> > However, this is strikingly similar to two other cases: when a<link
> > rel=stylesheet ...>  element is removed from the document, in WebKit, we
> > remove the stylesheet from the document, although this isn't explicitly
> > specified in 4.12.5.11,
> > http://www.whatwg.org/specs/web-apps/current-work/multipage/links.html#link-type-stylesheet.
> 
> In this situation, Gecko removes the stylesheet from the document, but 
> does not stop its load and keeps it in the per-document object cache. 
> Fwiw.

Spec somewhat updated (.sheet now changes to null if you take the <link> 
or <style> out of the document), though I'll revisit this as part of:

https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703

...to make it more precise.

From ian at hixie.ch  Wed Nov 28 17:09:36 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 01:09:36 +0000 (UTC)
Subject: [whatwg] <script> features
In-Reply-To: <CAKA+AxkLeq8_A_5dw8vf56BPc7iWoANCgoWjAR_NFfhM1a_t=Q@mail.gmail.com>
References: <mailman.5573.1282025627.18147.whatwg-whatwg.org@lists.whatwg.org>
	<4C6AFC58.6070503@johnjbarton.com>
	<AANLkTinbjJSvHZfAwsxxFC-bg-zBxjDbymuo3y8eUpCO@mail.gmail.com>
	<4C6B3401.5090202@johnjbarton.com>
	<AANLkTikfxnSu+vEJqYs9C-NCU-52n+HX4CvJoDjGDUTC@mail.gmail.com>
	<4C6B6566.8040407@johnjbarton.com>
	<AANLkTinH3dvwaD-5YNYK2N5rGSV+FJFYshazu7kDeN5p@mail.gmail.com>
	<4C6B7226.6070104@johnjbarton.com>
	<AANLkTikwWeOppMAYpMkFeWk2jmTj4WoZEDtnZfANAA8q@mail.gmail.com>
	<Pine.LNX.4.64.1202040423380.3868@ps20323.dreamhostps.com>
	<CA+c2ei86Kdj5H1x_L9vYhSFmOoDqCxsgVkEh2OmqvxnnraWnAg@mail.gmail.com>
	<Pine.LNX.4.64.1203240441070.22654@ps20323.dreamhostps.com>
	<CA+c2ei-ZUr8rd+BLD6ApmX=P33jZ9=qbAj3PsmDOfU5YhDCWLA@mail.gmail.com>
	<CAKA+AxkLeq8_A_5dw8vf56BPc7iWoANCgoWjAR_NFfhM1a_t=Q@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211290109050.1991@ps20323.dreamhostps.com>

On Sun, 25 Mar 2012, Jonas Sicking wrote:
> On Fri, Mar 23, 2012 at 9:41 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 23 Mar 2012, Jonas Sicking wrote:
> >>
> >> The whole point of this feature is to enable the js-code inside a 
> >> loaded script to use the .currentScript property in order to find the 
> >> <script> element in the DOM which loaded it.
> >
> > Ah, ok. What's the use case for that?
> 
> One use case is to be able to pass parameters to a script library by 
> sticking the information in the markup. data-* attributes would work 
> great for this. I seem to recall jQuery doing something like this, but 
> can't find information about that right now.
> 
> In the case of ReSpec it uses it to get its own url and then use that as 
> a base url to load dependent scripts as needed.

On Sun, 25 Mar 2012, Aryeh Gregor wrote:
> 
> testharness.js also does that, I think -- it loads a CSS file from the 
> same directory as itself.  IIRC, it does so by looking for the first 
> <script> whose src ends in "testharness.js".  It would be more reliable 
> if it could record the actual URL it's being loaded from.
> 
> (For this use-case it would be enough for the script to get its own URL.  
> In fact, this might be slightly more reliable, because there's nothing 
> to stop an earlier part of the script from inadvertently changing the 
> <script> element's src.  That wouldn't satisfy the first use-case Jonas 
> mentioned, though.)

Cool, thanks for the info.

I've added the feature to the spec.

From ian at hixie.ch  Wed Nov 28 19:35:21 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 03:35:21 +0000 (UTC)
Subject: [whatwg] Proposal: Add window.getLastError (or modify
 invocation arguments of window.onerror)
In-Reply-To: <CALrbKZhJB6bAfRd_tEwcx_YsNEP4jcNFw_fOQLxewCGHq1ntcA@mail.gmail.com>
References: <CALrbKZjyrULXrJQgY+KCf9wz33eOyjOSRyd90iXGNf7yvwPZrQ@mail.gmail.com>
	<CALrbKZh28iowH2BDBu8epxAz4O=Re9cPQv86hkb7D=xBSxNcZg@mail.gmail.com>
	<op.wd1ai0n4idj3kv@simons-macbook-pro.local>
	<CALrbKZhGTiMftzHeg0xBSkXj25VzEdja8ZuL58BQ5zz5njt37Q@mail.gmail.com>
	<op.wd4p5m03idj3kv@simons-macbook-pro.local>
	<CALrbKZgjFi8=VLHYU3jYRBbPWyAYzDrAjaLW84hRJbUvFRHMCQ@mail.gmail.com>
	<op.wd5mq7lyidj3kv@simons-macbook-pro.local>
	<CALrbKZhJB6bAfRd_tEwcx_YsNEP4jcNFw_fOQLxewCGHq1ntcA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211290117020.1991@ps20323.dreamhostps.com>

On Tue, 8 May 2012, James Greene wrote:
>
> The problem [with window.onerror is] that this mechanism does not allow 
> us to inspect the pertinent Error object at all: it only provides us 
> with three arguments at invocation time: message (string), fileName 
> (string), and lineNumber (number). These are rarely useful in practice.

Could you elaborate on what the exception object (Error or DOMException or 
whatever) provides that the onerror callback's arguments don't, that you 
would find useful for debugging? Is it just the stack trace?

On Wed, 9 May 2012, Simon Pieters wrote:
> >
> > ## My proposal(s) to fix it
> > As such, I propose the following two options as fixes:
> > 1. Add a function like `getLastError` to the global `window` object that
> > would fetch the actual `Error` object associated with the most recent
> > unhandled error.  I would foresee common usage looking something like the
> > following:
> > ```
> > var oldOnError = window.onerror;
> > window.onerror = function myErrorHandler(errorMsg, url, lineNumber) {
> >        if (oldOnError) {
> >            return oldOnError(errorMsg, url, lineNumber);
> >        }
> >       var e = window.getLastError();
> >        alert("Globally unhandled error! But we now can discover its origin.
> > Details: " + e);
> >        return false;
> > }
> > ```
> > 2. Alternatively (though less preferably), we could also update the
> > invocation arguments of `window.onerror` callbacks to include a new fourth
> > argument that would be the relevant `Error` object itself:
> >    ```
> >    var oldOnError = window.onerror;
> >    window.onerror = function myErrorHandler(errorMsg, url, lineNumber, e) {
> >        if (oldOnError) {
> >            return oldOnError(errorMsg, url, lineNumber, e);
> >        }
> >       alert("Globally unhandled error! But we now can discover its origin.
> > Details: " + e);
> >        return false;
> >    }
> >    ```
> >    While this essentially makes the first three arguments useless, I have
> > posed it this way for the sake of backward compatibility.
> 
> I'd prefer this second option (except making it the fifth argument), 
> because the exception object can become garbage earlier and because for 
> cross-origin script errors, the arguments to window.onerror are masked 
> for security reasons, and we would need to mask the exception object as 
> well, so it seems better to use the same mechanism for that.

I don't really understand the practical difference between these two 
options, assuming getLastError() only returns a value while the onerror 
handler is being invoked. (If it returns a value after it's invoked, you 
get the problem zcorpan describes above, of the value not being garbage 
collectable until much later.)

> Also for compile script errors, there is no exception object.

That's a good point also.

On Fri, 11 May 2012, James Greene wrote:
> 
> I personally am interested in adding the stack trace, yes, but ideally I 
> would just have access to the full "Error" object so I can always have 
> an up-to-date model if the "Error" object continues to change (as it 
> probably will).  For example, some devs may be interested in the "Error" 
> object's "name" property, which is already a part of the object today 
> but is not provided to "window.onerror" callbacks.  And again, if 
> additional properties are added in the future, it's just more and more 
> properties that may need to get incrementally added to the 
> "window.onerror" invocation arguments list.

Having the exception object, if any, in the onerror callback, seems 
reasonable, and would indeed limit how many more arguments we may have to 
add over the years. It seems that providing it as an argument would be 
better than as a global, though.

> For example, I proposed the addition of an "innerError" property (or 
> some would call it "cause") for chaining errors and masking internal 
> errors that consumers shouldn't see, instead providing a customer-facing 
> message.

I'm not familiar with that proposal.

On Fri, 11 May 2012, James Greene wrote:
>
> Alright... so what's next?  I'm assuming this needs further discussion 
> with other WHATWG members chiming in.  If I can help, please let me 
> know. I'd like to see this request through.

Discussion isn't really what's needed, so much as commitments (or at 
least, positive interest) from browser vendors. See this FAQ entry:

http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

In general, providing the exception object as a fifth argument to onerror 
seems reasonable to me. Any implementors interested in adding this?

From ian at hixie.ch  Wed Nov 28 20:01:59 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 04:01:59 +0000 (UTC)
Subject: [whatwg] Deferring javascript download and execution until
 after onload
In-Reply-To: <CABbusALOG54sOyBp-Y9e93E_w6ytxCgEp55+dJGcT6x211fsPA@mail.gmail.com>
References: <CABbusAKKvpmxhnt=HS73xQOBmiSzEo-3pwAzrZurhdUS3zDfZg@mail.gmail.com>
	<CA+c2ei8oFUmOtp08w5SXMMfzc79-pMdwgKwK9ZnmWpCOnKmgVQ@mail.gmail.com>
	<CABbusALOG54sOyBp-Y9e93E_w6ytxCgEp55+dJGcT6x211fsPA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211290342280.1991@ps20323.dreamhostps.com>

On Mon, 17 Sep 2012, Andy Davies wrote:
>
> The script defer attribute allows us to defer JS until after 
> DOMContentLoaded (?) but it will still execute before onLoad

Actually defer="" defers to just before DOMContentLoaded, but <script> 
elements with a src="" attribute that are inserted into the document 
dynamically will load between DOMContentLoaded and onload, so you can do 
all your important loading in the DOMContentLoaded handler.

You can use this pretty easily:

function loadScript(url) {
     var script = document.createElement('script');
     script.src = url;
     document.appendChild(script);
   }
   load('mylibrary.js');
   load('myotherlibrary.js');

This can be trivially extended to, e.g., add IDs and support the script 
being inserted by inline script in specific places:

function loadScript(url, id) {
     var script = document.createElement('script');
     script.src = url;
     script.id = id;
     var target = document.currentScript;
     target.parentNode.insertBefore(script, target.nextSibling);
   }

<script>
     loadScript('mylibrary.js', 'mylib');
   </script>

On Mon, 17 Sep 2012, Jonas Sicking wrote:
> 
> There has been discussions about implementing a "noexec" attribute on 
> <script> which would just load the script but instead of evaluating it 
> as soon as it's available, simply fire the "load" event. There would 
> also be an additional .execute() function on the script which would 
> permit executing the script after it has been loaded.
> 
> This has mostly been discussed in a performance context where people has 
> expressed interest in loading scripts, while only waiting to execute it 
> until needed in order to avoid the costs involved in parsing and 
> executing the script.

The cost of parsing the script can be done async, even off the main thread 
in theory, so it's a non-issue. The only cost there could be is the cost 
of executing the script, and it's already trivial to offload that: just 
put all the code in a function, then call the function when you're ready.

> So far Hixie hasn't been interested in putting this into the spec 
> though, due to, as I understand it, not being convinced that it's needed 
> from a performance point of view.

It's not that it's not needed, it's that it's already possible. As far as 
I can tell, it adds nothing for performance.

> I'd personally be interested to see it implemented since people clearly 
> do load scripts dynamically and it would seem common for such scripts to 
> have dependencies on each other, which means that you have to be able to 
> execute them in a certain order.

It's already possible now to design scripts such that they don't run until 
you call them, so you could already do this:

// library1.js
   // depends on library2!
   function loadLibrary1() {
     // do everything to load library1
   }

// library2.js
   function loadLibrary2() {
     // do everything to load library2
   }

<script src="library1.js"></script>
   <script src="library2.js"></script>
   <script>
     function loadLibraries() {
       loadLibrary2();
       loadLibrary1();
     }
   </script>
   <body onload="loadLibraries()">

With ES6 import statements, this presumably gets even easier.

From bzbarsky at MIT.EDU  Wed Nov 28 20:03:04 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 28 Nov 2012 23:03:04 -0500
Subject: [whatwg] Adding crossorigin="" to more elements
In-Reply-To: <Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>
References: <503D0918.1010203@mit.edu>
	<Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>
Message-ID: <50B6DE78.5040500@mit.edu>

On 11/28/12 7:42 PM, Ian Hickson wrote:
> Done, at least on the HTML side. For now it just makes .sheet return null
> for cross-origin resources.

Pretty sure that's not web-compatible...

> If that's not quite right, please update this
> bug with the details:
>
>     https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703

Done.

>> An open issue: what to do about @import?  I haven't done anything magic
>> here yet.  Inheriting the CORS mode from the importing sheet is a bit
>> weird, and I wasn't quite sure I wanted to make CSS syntax changes at
>> this time.
>
> Inheriting the mode isn't so bad, all it really does is decide whether or
> not to send an Origin header.

Not quite.  It also affects what happens when the server doesn't respond 
with an appropriate Allow-Origin.  A CORS-enabled load from a server 
that knows nothing about CORS will throw away the sheet, while a no-CORS 
load will happily apply the sheet to the page (but not give access to 
its data).  So inheriting the mode can cause drastic changes in behavior 
compared to not inheriting it...

>> If the CORS mode is inherited from the importing sheet, then I think the
>> "origin" for the fetch should be the page, not the importing sheet,
>> since the page is what would get access to the stylesheet data.
>
> Right, the origin of the importing sheet in this situation is the origin
> of the page that imported it, not the origin of its URL. That's what CORS
> does, it changes the effective origin of a resource from being the origin
> its URL would suggest it had, to being the origin of its caller.

That's not quite correct.  It changes the _object_ origin to that of the 
caller.  It doesn't change the _subject_ origin.  Otherwise loading 
something via CORS would allow it to act on behalf of the loading page, 
whereas usually pages assume that using CORS just gives them expanded 
access to something.

Or put another way, if I have a file:// page that loads a sheet from 
http:// with CORS, that shouldn't imply that the sheet can then link to 
file:// URIs the page can link to.

This is very important; oversimplifying the security model to the point 
where it becomes insecure is bad.  ;)

>> Maybe this is OK, but it's non-obvious; usually for security purposes
>> the importing sheet is what affects things like can-load checks, Referer
>> headers, etc.
>
> Presumably a CORS-same-origin sheet would use the security characteristics
> of the page, since the page can make the style sheet dance as if it was
> its puppet.

No, see above.  The page can make the sheet do whatever, agreed.  But 
this is about the _sheet_ taking on the permissions of the _page_ in 
some sense, which may not be desirable.

> Anyway, that part of it belongs in CSS/CSSOM.

That's fine by me.  Assuming we ever end up with a CSSOM spec.... not 
holding my breath.  ;)

-Boris

From bzbarsky at MIT.EDU  Wed Nov 28 20:08:29 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Wed, 28 Nov 2012 23:08:29 -0500
Subject: [whatwg] Adding crossorigin="" to more elements
In-Reply-To: <50B6DE78.5040500@mit.edu>
References: <503D0918.1010203@mit.edu>
	<Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>
	<50B6DE78.5040500@mit.edu>
Message-ID: <50B6DFBD.9070301@mit.edu>

On 11/28/12 11:03 PM, Boris Zbarsky wrote:
>> Inheriting the mode isn't so bad, all it really does is decide whether or
>> not to send an Origin header.
>
> Not quite.  It also affects what happens when the server doesn't respond
> with an appropriate Allow-Origin.

Oh, I see.  You've added this "taint" thing, which you're using for the 
CSS bit.

I don't believe Gecko has any such concept.  We simply fail the load if 
the CORS check fails.  Furthermore, Gecko's behavior is what the CORS 
spec requires: failure to respond properly to a cross-origin CORS 
request must be treated like a network error per CORS.

-Boris

From getify at gmail.com  Wed Nov 28 21:05:11 2012
From: getify at gmail.com (Kyle Simpson)
Date: Wed, 28 Nov 2012 23:05:11 -0600
Subject: [whatwg] Deferring javascript download and execution until
	after onload
In-Reply-To: <mailman.21341.1354162115.34820.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.21341.1354162115.34820.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <1A27332A-A307-4077-B381-C6309F179FA9@gmail.com>

Ian,

> The cost of parsing the script can be done async, even off the main thread 
> in theory, so it's a non-issue.

You have asserted many times that parsing is off the main thread, therefore it doesn't matter. That makes the giant (and I think faulty) assumption that the device in question has enough spare resources to give multiple threads, which not all do, and that all threads can run in parallel without hurting each other and/or the overall performance.

There have been a number of articles referencing issues where complex scripts do in fact take a non-trivial amount of parsing time on limited mobile devices. Even if such work wasn't strictly blocking the main UI thread, the fact that it may take a lot of processing (or memory) power from the device might very well mean that large parsing tasks could starve necessary resources, so even if it's on another thread, there's still very much not a "non-issue" to consider.

I tried quick google searching just now to dig some specific articles up and failed to find what I remembered reading, but perhaps others on the list know what I'm talking about. I recall someone showing that jquery.js took over 1+ second to parse on a mobile device, but I can't remember the exact numbers. I remember being shocked at how crazy long jquery.js took to parse.

Here's something though that seems it's related: https://github.com/tolmasky/language/issues/18

------------

Moreover, as has been mentioned many times in various threads (and you seem to gloss over repeatedly), the gmail mobile team passed down large amounts of javascript "hidden" in a javascript /* ? */ comment, so as to prevent that large amount of code from being parsed, until "later" when the hit was acceptable, because they felt that the parsing and/or execution was non-trivial enough to unacceptably slow down their app's startup time.

IIRC, this was their post: http://googlecode.blogspot.com/2009/09/gmail-for-mobile-html5-series-reducing.html

In any case, your assumption that parsing is a non-issue seems to fly in the face of not only some explicit evidence to the contrary, but there have also been some comments in various threads from browser vendor devs that lent credence to the fact that parsing could in fact be somewhat costly.

Do you have explicit evidence to the contrary that no such possible performance issues during parsing could possibly exist on any device or with any script in the wild? It would be nice if you could show such contrary evidence instead of dismissing or ignoring the arguments and evidence already out on the table.

The coming "module" feature (in ES6 or whatever) could make this worse, because AIUI, the parsing/compilation stage is where the browser will resolve static dependencies, so it's THAT stage which very well might be taking a lot longer while it fetches dependency resources.

--Kyle

From getify at gmail.com  Wed Nov 28 21:07:37 2012
From: getify at gmail.com (Kyle Simpson)
Date: Wed, 28 Nov 2012 23:07:37 -0600
Subject: [whatwg] Deferring javascript download and execution until
	after onload
In-Reply-To: <mailman.21341.1354162115.34820.whatwg-whatwg.org@lists.whatwg.org>
References: <mailman.21341.1354162115.34820.whatwg-whatwg.org@lists.whatwg.org>
Message-ID: <308A6EE0-B84B-4106-93D3-845E07D4AF52@gmail.com>

Ian,

> The only cost there could be is the cost 
> of executing the script, and it's already trivial to offload that: just 
> put all the code in a function, then call the function when you're ready.

> It's already possible now to design scripts such that they don't run until 
> you call them, so you could already do this:

You ask us not to make duplicate arguments because you say that it just clogs up this list and does nothing to change the outcome of your decision. I would like to ask that you not do the same. You have said this same thing no less than 10 times across various threads and communications. I really don't think anyone who's following this particular issue is unclear about your stance.

-------

What it boils down to is, you feel that the onus is on the developers of the scripts themselves to change so they are more "performance optimization friendly" for those who use the scripts.

There are a number of us who work in the performance optimization consulting arena, and when we consult with a site who's using a bunch of third party scripts, and most of those scripts are not written the way you think they should be, those clients aren't happy when we have to tell them "sorry, your only option to optimize the performance is to make your own modifications to those 3rd party scripts, and then self-host them, and then keep up with merging changes constantly, etc?" or some other such impractical nonsense.

Your approach is like tail-wagging-the-dog: let's make sure performance stays less than optimal, so that eventually the designers of these scripts have to wake up and fix it.

Perhaps you want to drag this issue out long enough (been under discussion for almost 2 years now) that all those poorly designed scripts across the web are just eventually made obsolete or finally "fixed" without the web platform needing to address it. The rest of us, I think, would like to actually make performance gains and optimizations now. It will be years and years before most of the popular scripts on the web may be rewritten in the way you suggest. It's just a shame that performance has to continue to suffer until then.

Giving us a mechanism by which we could load existing scripts written and maintained by others, which we don't control, in a way that is more performant than what we can currently do, regardless of how that script is designed to self-execute or not, would be a very useful tool to us, despite you insisting it's not useful.

Also, some scripts, by nature of what they do or how they do it, will ALWAYS have to auto-execute. Consider the feature-tests that jQuery or Modernizr do automatically during their initialization. I think it would hurt both jQuery and Modernizr and others like them if users all of a sudden had to start calling a $.init() or something like that before they could use the script. The untold tens of thousands of sites and books which explain how to use these scripts would all be rendered completely inaccurate if such a major paradigm shift were to happen.

--Kyle

From gphemsley at gmail.com  Wed Nov 28 22:30:38 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Thu, 29 Nov 2012 01:30:38 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as unknown
	for sniffing
Message-ID: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>

Based on my reading of the source code, it seems that Gecko treats a
resource served as 'application/octet-stream' as an unknown type which
is sniffed as if no Content-Type was specified.

Are there security implications with doing this? Or should I add
'application/octet-stream' to the list of unknown types that currently
includes 'unknown/unknown', 'application/unknown', and '*/*' (step 2
of the "media type sniffing algorithm")? Or, given that that step
calls the "rules for identifying an unknown media type" with the
sniff-scriptable flag set, should it get its own call, with the
sniff-scriptable flag unset? Are there other options here?

I haven't checked what UAs actually do in practice, but I don't
believe the spec currently allows anything but leaving resources
tagged as 'application/octet-stream' as they are.

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From lcamtuf at coredump.cx  Wed Nov 28 22:42:29 2012
From: lcamtuf at coredump.cx (Michal Zalewski)
Date: Wed, 28 Nov 2012 22:42:29 -0800
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
Message-ID: <CALx_OUDwMNkfZ4J03BVJ1ByJ2t1PKSs8wq4wCKPZNM+RbC3WAA@mail.gmail.com>

There are substantial negative security consequences to sniffing
content on MIME types that are commonly used as default fallback
values by web servers or web application developers. This includes
text/plain and application/octet-stream.

/mz

From bzbarsky at MIT.EDU  Wed Nov 28 22:48:46 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 29 Nov 2012 01:48:46 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
Message-ID: <50B7054E.10801@mit.edu>

On 11/29/12 1:30 AM, Gordon P. Hemsley wrote:
> Based on my reading of the source code, it seems that Gecko treats a
> resource served as 'application/octet-stream' as an unknown type which
> is sniffed as if no Content-Type was specified.

Only for media (<video> and <audio>) loads.  Note that the HTML spec 
requires this behavior for those.

> Are there security implications with doing this?

In general, yes.  Doing this for document loads would be a security 
nightmare, for example.

-Boris

From gphemsley at gmail.com  Wed Nov 28 23:07:29 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Thu, 29 Nov 2012 02:07:29 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
	unknown for sniffing
In-Reply-To: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
Message-ID: <CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>

On Thu, Nov 29, 2012 at 1:30 AM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> Based on my reading of the source code, it seems that Gecko treats a
> resource served as 'application/octet-stream' as an unknown type which
> is sniffed as if no Content-Type was specified.

Oh, wait, I forgot what I was reading?Gecko does this specifically in
the context of sniffing for an audio or video resource. So, if a
resource tagged as 'application/octet-stream' is included in <audio>
or <video>, for example, it will be treated as unknown for the
purposes of identifying its true nature. This never follows a path of
scriptable privilege escalation, AFAICT.

So perhaps a more useful question would be what to do in situations
like that?should mimesniff treat "application/octet-stream" as a type
"supported by the browser" for the purposes of sniffing images, audio
or video, fonts, or other media types?

I imagine this ties in, too, to the issues with sniffing CSS files
that has been raised elsewhere:

https://bugzilla.mozilla.org/show_bug.cgi?id=560388
https://bugzilla.mozilla.org/show_bug.cgi?id=562377
https://bugzilla.mozilla.org/show_bug.cgi?id=808593

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From bzbarsky at MIT.EDU  Wed Nov 28 23:32:56 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 29 Nov 2012 02:32:56 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
Message-ID: <50B70FA8.9040401@mit.edu>

On 11/29/12 2:07 AM, Gordon P. Hemsley wrote:
> So perhaps a more useful question would be what to do in situations
> like that?should mimesniff treat "application/octet-stream" as a type
> "supported by the browser" for the purposes of sniffing images, audio
> or video, fonts, or other media types?

The way it works right now is that 
http://www.whatwg.org/specs/web-apps/current-work/#mime-types says:

The MIME type "application/octet-stream" with no parameters is never
   a type that the user agent knows it cannot render. User agents must
   treat that type as equivalent to the lack of any explicit
   Content-Type metadata when it is used to label a potential media
   resource.

So for the purpose of sniffing media loads specifically, that type is 
treated just like no type at all.

But first you have to know it's a media load.

> I imagine this ties in, too, to the issues with sniffing CSS files
> that has been raised elsewhere:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=560388
> https://bugzilla.mozilla.org/show_bug.cgi?id=562377

Neither one of those has anything to do with application/octet-stream as 
far as I can tell.  Those cover cases in which data is sent with either 
no Content-Type header or with such a header which can't even be parsed 
as "major/minor".  Neither of which is true if the data says 
"appliction/octet-stream".

-Boris

From bzbarsky at MIT.EDU  Wed Nov 28 23:34:52 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 29 Nov 2012 02:34:52 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <50B70FA8.9040401@mit.edu>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
	<50B70FA8.9040401@mit.edu>
Message-ID: <50B7101C.7080601@mit.edu>

On 11/29/12 2:32 AM, Boris Zbarsky wrote:
> On 11/29/12 2:07 AM, Gordon P. Hemsley wrote:
>> I imagine this ties in, too, to the issues with sniffing CSS files
>> that has been raised elsewhere:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=560388
>> https://bugzilla.mozilla.org/show_bug.cgi?id=562377
>
> Neither one of those has anything to do with application/octet-stream as
> far as I can tell.  Those cover cases in which data is sent with either
> no Content-Type header or with such a header which can't even be parsed
> as "major/minor".  Neither of which is true if the data says
> "appliction/octet-stream".

Oh, and the other important bit is that there is no "sniffing" CSS 
involved.  If the load is for a <link rel="stylesheet"> and the server 
doesn't send a content type or sends one that can't be parsed, Gecko 
just treats the data as CSS.  That's not the same thing as sniffing the 
data.  ;)

-Boris

From gphemsley at gmail.com  Wed Nov 28 23:53:21 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Thu, 29 Nov 2012 02:53:21 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <50B70FA8.9040401@mit.edu>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
	<50B70FA8.9040401@mit.edu>
Message-ID: <CAH4e3M4NMQwUjJCpi5Se7bPEVibLnzu-7RafR4145smsd3dEDA@mail.gmail.com>

On Thu, Nov 29, 2012 at 2:32 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 11/29/12 2:07 AM, Gordon P. Hemsley wrote:
>>
>> So perhaps a more useful question would be what to do in situations
>> like that?should mimesniff treat "application/octet-stream" as a type
>> "supported by the browser" for the purposes of sniffing images, audio
>> or video, fonts, or other media types?
>
>
> The way it works right now is that
> http://www.whatwg.org/specs/web-apps/current-work/#mime-types says:
>
>   The MIME type "application/octet-stream" with no parameters is never
>   a type that the user agent knows it cannot render. User agents must
>   treat that type as equivalent to the lack of any explicit
>   Content-Type metadata when it is used to label a potential media
>   resource.
>
> So for the purpose of sniffing media loads specifically, that type is
> treated just like no type at all.
>
> But first you have to know it's a media load.

Oh, this is probably the location where the HTML spec doesn't
currently, but eventually should, reference the "rules for sniffing
audio and video specifically" in mimesniff. (Is this where Opera
implements such rules?)

Is it just me (and my late-night reading), or is that section
contradictory on how to treat "application/octet-stream"?

At one point it says, "The MIME type "application/octet-stream" with
no parameters is never a type that the user agent knows it cannot
render. User agents must treat that type as equivalent to the lack of
any explicit Content-Type metadata when it is used to label a
potential media resource."

But later it says, "The canPlayType(type) method must return the empty
string if type is a type that the user agent knows it cannot render or
is the type "application/octet-stream";"

This seems to me to be unclear as to when sniffing of the audio/video
resource occurs, and what it is used for.

>> I imagine this ties in, too, to the issues with sniffing CSS files
>> that has been raised elsewhere:
>>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=560388
>> https://bugzilla.mozilla.org/show_bug.cgi?id=562377
>
> Neither one of those has anything to do with application/octet-stream as far
> as I can tell.  Those cover cases in which data is sent with either no
> Content-Type header or with such a header which can't even be parsed as
> "major/minor".  Neither of which is true if the data says
> "appliction/octet-stream".

I was grouping them together because they both rely on context clues
for modifying the sniffing (fallback) behavior, but we can discuss
them separately if that's easier.

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From bzbarsky at MIT.EDU  Thu Nov 29 00:02:17 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 29 Nov 2012 03:02:17 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAH4e3M4NMQwUjJCpi5Se7bPEVibLnzu-7RafR4145smsd3dEDA@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
	<50B70FA8.9040401@mit.edu>
	<CAH4e3M4NMQwUjJCpi5Se7bPEVibLnzu-7RafR4145smsd3dEDA@mail.gmail.com>
Message-ID: <50B71689.7000200@mit.edu>

On 11/29/12 2:53 AM, Gordon P. Hemsley wrote:
> At one point it says, "The MIME type "application/octet-stream" with
> no parameters is never a type that the user agent knows it cannot
> render. User agents must treat that type as equivalent to the lack of
> any explicit Content-Type metadata when it is used to label a
> potential media resource."
>
> But later it says, "The canPlayType(type) method must return the empty
> string if type is a type that the user agent knows it cannot render or
> is the type "application/octet-stream";"

What's the contradiction?  We have set S = { types the user agent knows 
it cannot render }.  We have set T = S union { application/octet-stream }

What the above statements tell us so far is:

1)  T != S
2)  canPlayType(type) must return empty string for all types in T.

But later on in the resource selection algorithm there are certain 
actions taken for elements of S only.

> This seems to me to be unclear as to when sniffing of the audio/video
> resource occurs, and what it is used for.

It's used for actually showing the video even if it's sent as 
application/octet-stream.

> I was grouping them together because they both rely on context clues
> for modifying the sniffing (fallback) behavior

So first of all, "sniffing" and "default handling" are not the same 
thing at all.

But yes, context matters for determining default handling and also for 
determining sniffing.

-Boris

From simonp at opera.com  Thu Nov 29 01:07:42 2012
From: simonp at opera.com (Simon Pieters)
Date: Thu, 29 Nov 2012 10:07:42 +0100
Subject: [whatwg] Proposal: Add window.getLastError (or modify
 invocation arguments of window.onerror)
In-Reply-To: <Pine.LNX.4.64.1211290117020.1991@ps20323.dreamhostps.com>
References: <CALrbKZjyrULXrJQgY+KCf9wz33eOyjOSRyd90iXGNf7yvwPZrQ@mail.gmail.com>
	<CALrbKZh28iowH2BDBu8epxAz4O=Re9cPQv86hkb7D=xBSxNcZg@mail.gmail.com>
	<op.wd1ai0n4idj3kv@simons-macbook-pro.local>
	<CALrbKZhGTiMftzHeg0xBSkXj25VzEdja8ZuL58BQ5zz5njt37Q@mail.gmail.com>
	<op.wd4p5m03idj3kv@simons-macbook-pro.local>
	<CALrbKZgjFi8=VLHYU3jYRBbPWyAYzDrAjaLW84hRJbUvFRHMCQ@mail.gmail.com>
	<op.wd5mq7lyidj3kv@simons-macbook-pro.local>
	<CALrbKZhJB6bAfRd_tEwcx_YsNEP4jcNFw_fOQLxewCGHq1ntcA@mail.gmail.com>
	<Pine.LNX.4.64.1211290117020.1991@ps20323.dreamhostps.com>
Message-ID: <op.woi2a4w6idj3kv@simon-pieterss-macbook.local>

On Thu, 29 Nov 2012 04:35:21 +0100, Ian Hickson <ian at hixie.ch> wrote:

> Having the exception object, if any, in the onerror callback, seems
> reasonable, and would indeed limit how many more arguments we may have to
> add over the years. It seems that providing it as an argument would be
> better than as a global, though.

One question is what should happen with exceptions that propagate upwards  
in the case of dedicated workers. Should a new exception object be created  
for each worker up the chain, and finally for window? ErrorEvent would  
also need a new member for this.

-- 
Simon Pieters
Opera Software

From annevk at annevk.nl  Thu Nov 29 04:31:04 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 29 Nov 2012 13:31:04 +0100
Subject: [whatwg] proposal for a location.domain property
In-Reply-To: <ACB2DD95-08FF-41A5-AFD7-B5DA85F1C213@apple.com>
References: <op.wetj9zb0a3v5gv@hr-desk>
	<CAJE5ia9mko8jvFe3OynWnJ-L-k=RO0kN_5pZVu2iXZ2GHrEbhg@mail.gmail.com>
	<D65D5C11-CBCF-42E7-A17A-7871E841394D@apple.com>
	<op.weu3fcir2q99of@joaoe>
	<ACB2DD95-08FF-41A5-AFD7-B5DA85F1C213@apple.com>
Message-ID: <CADnb78hi=iHM-g4qszV_KwuUPt5dOzCff1O0zqPz9CfBkFizeA@mail.gmail.com>

On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them.
> For the URL "http://www.apple.com/", "apple.com" would be the domain, and "com" would be the TLD.

Yes, but for the URL "http://www.google.co.uk/" you would need to have
publicsuffix.org information in order to determine that the effective
domain is "google.co.uk" and not "co.uk".

I'm not going to add this because cookies and document.domain are not
good use cases for this. Cookies should eventually move to an
origin-based security model (probably via some kind of opt-in) and
document.domain should simply be avoided.

(Ian asked me to reply to this thread
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20011 as the URL
Standard now deals with these attributes.)

-- 
http://annevankesteren.nl/

From annevk at annevk.nl  Thu Nov 29 07:03:40 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Thu, 29 Nov 2012 16:03:40 +0100
Subject: [whatwg] Notifications API: minor change
Message-ID: <CADnb78hx6anX1SQdJb2dqycjt7eayP+qnVmU_6RJYR_cvhUfeQ@mail.gmail.com>

Hi,

Per http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0116.html
I removed the string coercion done in the Notifications API. It is now
up to the UI layer how to deal with lone surrogates, similar to how
that is handled elsewhere in the platform.

https://github.com/whatwg/notifications/commit/463112f1d38fed73eef9b8a0bd6f3fd68dc80c2d
http://notifications.spec.whatwg.org/

Kind regards,

-- 
http://annevankesteren.nl/

From gphemsley at gmail.com  Thu Nov 29 09:45:35 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Thu, 29 Nov 2012 12:45:35 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <50B71689.7000200@mit.edu>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
	<50B70FA8.9040401@mit.edu>
	<CAH4e3M4NMQwUjJCpi5Se7bPEVibLnzu-7RafR4145smsd3dEDA@mail.gmail.com>
	<50B71689.7000200@mit.edu>
Message-ID: <CAH4e3M6skbqWtmc0A3SW4bmDVzTKGN=stDSJU5hscWpXsupbng@mail.gmail.com>

On Thu, Nov 29, 2012 at 3:02 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 11/29/12 2:53 AM, Gordon P. Hemsley wrote:
>>
>> At one point it says, "The MIME type "application/octet-stream" with
>> no parameters is never a type that the user agent knows it cannot
>> render. User agents must treat that type as equivalent to the lack of
>> any explicit Content-Type metadata when it is used to label a
>> potential media resource."
>>
>> But later it says, "The canPlayType(type) method must return the empty
>> string if type is a type that the user agent knows it cannot render or
>> is the type "application/octet-stream";"
>
>
> What's the contradiction?  We have set S = { types the user agent knows it
> cannot render }.  We have set T = S union { application/octet-stream }
>
> What the above statements tell us so far is:
>
> 1)  T != S
> 2)  canPlayType(type) must return empty string for all types in T.
>
> But later on in the resource selection algorithm there are certain actions
> taken for elements of S only.
>
>
>> This seems to me to be unclear as to when sniffing of the audio/video
>> resource occurs, and what it is used for.
>
>
> It's used for actually showing the video even if it's sent as
> application/octet-stream.

The apparent contradiction occurs when, e.g., an Opus file is tagged
as "application/octet-stream".

If I understand correctly, a UA would return "" when canPlayType() is
called against such a file?but then the file would actually play
because it is later sniffed as "application/ogg".

Am I missing something?

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From bzbarsky at MIT.EDU  Thu Nov 29 09:57:43 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 29 Nov 2012 12:57:43 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAH4e3M6skbqWtmc0A3SW4bmDVzTKGN=stDSJU5hscWpXsupbng@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
	<50B70FA8.9040401@mit.edu>
	<CAH4e3M4NMQwUjJCpi5Se7bPEVibLnzu-7RafR4145smsd3dEDA@mail.gmail.com>
	<50B71689.7000200@mit.edu>
	<CAH4e3M6skbqWtmc0A3SW4bmDVzTKGN=stDSJU5hscWpXsupbng@mail.gmail.com>
Message-ID: <50B7A217.4080300@mit.edu>

On 11/29/12 12:45 PM, Gordon P. Hemsley wrote:
> The apparent contradiction occurs when, e.g., an Opus file is tagged
> as "application/octet-stream".
>
> If I understand correctly, a UA would return "" when canPlayType() is
> called against such a file

canPlayType is not called "against a file".  It's called with a single 
argument which is a string MIME type.  If you pass 
"application/octet-stream", it will return "".  Its behavior does not 
depend on any state of the element it's called on (like what it's 
actually pointing to, etc); only on the string passed in.

> but then the file would actually play
> because it is later sniffed as "application/ogg".
>
> Am I missing something?

I think you're misunderstanding what canPlayType does?

-Boris

From gphemsley at gmail.com  Thu Nov 29 10:11:03 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Thu, 29 Nov 2012 13:11:03 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <50B7A217.4080300@mit.edu>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
	<50B70FA8.9040401@mit.edu>
	<CAH4e3M4NMQwUjJCpi5Se7bPEVibLnzu-7RafR4145smsd3dEDA@mail.gmail.com>
	<50B71689.7000200@mit.edu>
	<CAH4e3M6skbqWtmc0A3SW4bmDVzTKGN=stDSJU5hscWpXsupbng@mail.gmail.com>
	<50B7A217.4080300@mit.edu>
Message-ID: <CAH4e3M41_VaoUDrZrD1RW4UMFiYnFDBLe8jyXukmmZVMKyB=mg@mail.gmail.com>

On Thu, Nov 29, 2012 at 12:57 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> canPlayType is not called "against a file".  It's called with a single
> argument which is a string MIME type.  If you pass
> "application/octet-stream", it will return "".  Its behavior does not depend
> on any state of the element it's called on (like what it's actually pointing
> to, etc); only on the string passed in.

Oh, I see. My mistake. (One should never attempt to understand
something after 2 AM.)

So... are there any additional places where "application/octet-stream"
should be treated as if the media type was undefined? Or is this
conversation moot now?

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From bzbarsky at MIT.EDU  Thu Nov 29 10:22:37 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 29 Nov 2012 13:22:37 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAH4e3M41_VaoUDrZrD1RW4UMFiYnFDBLe8jyXukmmZVMKyB=mg@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
	<50B70FA8.9040401@mit.edu>
	<CAH4e3M4NMQwUjJCpi5Se7bPEVibLnzu-7RafR4145smsd3dEDA@mail.gmail.com>
	<50B71689.7000200@mit.edu>
	<CAH4e3M6skbqWtmc0A3SW4bmDVzTKGN=stDSJU5hscWpXsupbng@mail.gmail.com>
	<50B7A217.4080300@mit.edu>
	<CAH4e3M41_VaoUDrZrD1RW4UMFiYnFDBLe8jyXukmmZVMKyB=mg@mail.gmail.com>
Message-ID: <50B7A7ED.6090708@mit.edu>

On 11/29/12 1:11 PM, Gordon P. Hemsley wrote:
> So... are there any additional places where "application/octet-stream"
> should be treated as if the media type was undefined? Or is this
> conversation moot now?

To my knowledge, the only places in the web platform that special-case 
application/octet-stream like this are media and <object>... And for 
<object> I believe it falls back to @type, not to data sniffing, but 
it's been a while.

-Boris

From ian at hixie.ch  Thu Nov 29 10:24:25 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 18:24:25 +0000 (UTC)
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAH4e3M6skbqWtmc0A3SW4bmDVzTKGN=stDSJU5hscWpXsupbng@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAH4e3M6RjZ0WCDT0VjfZj8p35of_m0B41=ekkD=4R5SnLkgpwA@mail.gmail.com>
	<50B70FA8.9040401@mit.edu>
	<CAH4e3M4NMQwUjJCpi5Se7bPEVibLnzu-7RafR4145smsd3dEDA@mail.gmail.com>
	<50B71689.7000200@mit.edu>
	<CAH4e3M6skbqWtmc0A3SW4bmDVzTKGN=stDSJU5hscWpXsupbng@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211291821030.12469@ps20323.dreamhostps.com>

On Thu, 29 Nov 2012, Gordon P. Hemsley wrote:
> 
> The apparent contradiction occurs when, e.g., an Opus file is tagged as 
> "application/octet-stream".
> 
> If I understand correctly, a UA would return "" when canPlayType() is 
> called against such a file?but then the file would actually play 
> because it is later sniffed as "application/ogg".

canPlayType() isn't called against files, it's called against MIME type 
strings.

The type "application/octet-stream" isn't a video or audio file type, so 
we know that the browsers can't play files actually of that type, any more 
than the browsers can't play videos of type text/css.

But when a file is labeled with that type, we know it's probably 
mislabeled, so we try to do something more useful.

On another note, the spec's current behavior with media elements and 
sniffing is actually very much up in the air, since the last time I worked 
on this I could not get browser vendors to agree on what to implement. 
Search for the note starting "This specification does not currently say 
whether or how to check the MIME types of the media resources".

From gphemsley at gmail.com  Thu Nov 29 10:42:23 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Thu, 29 Nov 2012 13:42:23 -0500
Subject: [whatwg] [mimesniff] Sniffing archives
In-Reply-To: <CAH4e3M7-K+5+gzd6mVHJVcx2TE7OWZCho16Z3=2d7WGZ9Ui+qQ@mail.gmail.com>
References: <CAH4e3M7-K+5+gzd6mVHJVcx2TE7OWZCho16Z3=2d7WGZ9Ui+qQ@mail.gmail.com>
Message-ID: <CAH4e3M6hBXz-6vp3HK6HpRb7pd+-q_yyTW5FOjFO3Czn6mTw4g@mail.gmail.com>

To be clear, I'm asking this because I would like to remove the
sniffing of archive types from the mimesniff spec if there aren't any
valid usecases.

On Wed, Nov 28, 2012 at 12:18 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> The mimesniff spec currently includes signatures for ZIP, gzip, and
> RAR archive formats. However, no major browser seems to support them
> natively (they all prompt for download), and it's not clear whether
> the type detection is a product of the browser code or the OS, or
> whether it is used beyond choosing an appropriate file extension for
> the download.
>
> Are there any valid usecases for explicitly sniffing archive formats
> instead of letting them default to application/octet-stream like other
> binary files would? Note that Henri Sivonen has previously raised the
> issue that ZIP-based formats (like office suite documents), for
> example, would be misleadingly sniffed as ZIP files, and there is no
> easy way around that.
>
> --
> Gordon P. Hemsley
> me at gphemsley.org
> http://gphemsley.org/ ? http://gphemsley.org/blog/

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From mjs at apple.com  Thu Nov 29 11:23:48 2012
From: mjs at apple.com (Maciej Stachowiak)
Date: Thu, 29 Nov 2012 11:23:48 -0800
Subject: [whatwg] proposal for a location.domain property
In-Reply-To: <CADnb78hi=iHM-g4qszV_KwuUPt5dOzCff1O0zqPz9CfBkFizeA@mail.gmail.com>
References: <op.wetj9zb0a3v5gv@hr-desk>
	<CAJE5ia9mko8jvFe3OynWnJ-L-k=RO0kN_5pZVu2iXZ2GHrEbhg@mail.gmail.com>
	<D65D5C11-CBCF-42E7-A17A-7871E841394D@apple.com>
	<op.weu3fcir2q99of@joaoe>
	<ACB2DD95-08FF-41A5-AFD7-B5DA85F1C213@apple.com>
	<CADnb78hi=iHM-g4qszV_KwuUPt5dOzCff1O0zqPz9CfBkFizeA@mail.gmail.com>
Message-ID: <B44639C3-3129-408A-BAA1-5C5178716829@apple.com>

On Nov 29, 2012, at 4:31 AM, Anne van Kesteren <annevk at annevk.nl> wrote:

> On Sat, May 26, 2012 at 3:58 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>> I don't think location.domain would be the same as location.tld, to the extent I understand the intent of them.
>> For the URL "http://www.apple.com/", "apple.com" would be the domain, and "com" would be the TLD.
> 
> Yes, but for the URL "http://www.google.co.uk/" you would need to have
> publicsuffix.org information in order to determine that the effective
> domain is "google.co.uk" and not "co.uk".
> 
> I'm not going to add this because cookies and document.domain are not
> good use cases for this. Cookies should eventually move to an
> origin-based security model (probably via some kind of opt-in) and
> document.domain should simply be avoided.
> 
> (Ian asked me to reply to this thread
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20011 as the URL
> Standard now deals with these attributes.)

To be clear, I don't support adding either location.domain or location.tld. It was messages earlier in the thread that asked for it. My remark above was just a pedantic correction.

- Maciej

From w3c at adambarth.com  Thu Nov 29 11:25:26 2012
From: w3c at adambarth.com (Adam Barth)
Date: Thu, 29 Nov 2012 11:25:26 -0800
Subject: [whatwg] [mimesniff] Sniffing archives
In-Reply-To: <CAH4e3M6hBXz-6vp3HK6HpRb7pd+-q_yyTW5FOjFO3Czn6mTw4g@mail.gmail.com>
References: <CAH4e3M7-K+5+gzd6mVHJVcx2TE7OWZCho16Z3=2d7WGZ9Ui+qQ@mail.gmail.com>
	<CAH4e3M6hBXz-6vp3HK6HpRb7pd+-q_yyTW5FOjFO3Czn6mTw4g@mail.gmail.com>
Message-ID: <CAJE5ia-JqSx2SiHZE_A8d-TAE2px3yr5rdtC2bC193jwcGLOOA@mail.gmail.com>

These are supported in Chrome.  That's what causes the download.  From
your comment, it's not clear to me if you are correctly reverse
engineering existing user agents.  The techniques we used to create
this list originally are quite sophisticated and involved a massive
amount of data [1].  It would be a shame if you destroyed that work
because you didn't understand it.

Adam

[1] http://www.adambarth.com/papers/2009/barth-caballero-song.pdf

On Thu, Nov 29, 2012 at 10:42 AM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> To be clear, I'm asking this because I would like to remove the
> sniffing of archive types from the mimesniff spec if there aren't any
> valid usecases.
>
> On Wed, Nov 28, 2012 at 12:18 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
>> The mimesniff spec currently includes signatures for ZIP, gzip, and
>> RAR archive formats. However, no major browser seems to support them
>> natively (they all prompt for download), and it's not clear whether
>> the type detection is a product of the browser code or the OS, or
>> whether it is used beyond choosing an appropriate file extension for
>> the download.
>>
>> Are there any valid usecases for explicitly sniffing archive formats
>> instead of letting them default to application/octet-stream like other
>> binary files would? Note that Henri Sivonen has previously raised the
>> issue that ZIP-based formats (like office suite documents), for
>> example, would be misleadingly sniffed as ZIP files, and there is no
>> easy way around that.
>>
>> --
>> Gordon P. Hemsley
>> me at gphemsley.org
>> http://gphemsley.org/ ? http://gphemsley.org/blog/
>
>
>
> --
> Gordon P. Hemsley
> me at gphemsley.org
> http://gphemsley.org/ ? http://gphemsley.org/blog/

From w3c at adambarth.com  Thu Nov 29 11:30:47 2012
From: w3c at adambarth.com (Adam Barth)
Date: Thu, 29 Nov 2012 11:30:47 -0800
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
Message-ID: <CAJE5ia8=gEboxDqTmY7n_7Ca+L8eFpjE3_48ZjjgypbroZTmBg@mail.gmail.com>

On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
> Based on my reading of the source code, it seems that Gecko treats a
> resource served as 'application/octet-stream' as an unknown type which
> is sniffed as if no Content-Type was specified.
>
> Are there security implications with doing this?

Yes, there are very large security consequences.  I'm sorry that I
don't have time to respond to all of these threads in detail, but I'm
worried that you don't understand the consequences of the changes
you're proposing to this specification.

I'm not sure how to help you succeed here, but tweaking things in the
spec without a compelling reason for doing so is not likely to lead to
a useful specification.  I spent a great deal of time and effort
studying the behaviors of many user agents and of a massive amount of
content on the web.  I'm certainly willing to believe that the spec
can be improved, but if you don't understand these sorts of basic
things about content sniffing, I worry that changes that you make to
the spec won't be improvements.

Adam

From dbk at google.com  Thu Nov 29 11:40:10 2012
From: dbk at google.com (David Barrett-Kahn)
Date: Thu, 29 Nov 2012 13:40:10 -0600
Subject: [whatwg] AppCache Error events
In-Reply-To: <CA+iXHYO4CrvH27cOX15g1_RFQCjqDVLnynbD34U3HRhVoZoDrQ@mail.gmail.com>
References: <CA+iXHYO4CrvH27cOX15g1_RFQCjqDVLnynbD34U3HRhVoZoDrQ@mail.gmail.com>
Message-ID: <CA+iXHYNk7NaWUFt2bX2_r7NK3eER6d_8uY=fpskyHPPx22xvdg@mail.gmail.com>

So are there no objections to this, should I draft a change to the spec?

-Dave

On Mon, Nov 26, 2012 at 12:00 PM, David Barrett-Kahn <dbk at google.com> wrote:

> Right now this event contains no structured information, just an error
> message.  It'd be helpful to us to know more about what failed, so we can
> know what to report to the server and take action on.  It's hard to
> distinguish cache update failures due to just being offline from those
> which are actually causing trouble.  In the second case it's also hard to
> work out which resource is proving unavailable and why.
>
> One way to do this would be to create an AppCacheError subclass, with an
> errorCode parameter, and also nullable url and httpResponseCode properties.
>  Potential error codes:
> * couldn't fetch manifest (includes url and httpResponseCode)
> * pre and post update manifest fetches mismatched (includes url)
> * fetching a resource failed (includes url and httpResponseCode)
>
> Related bug:
> https://code.google.com/p/chromium/issues/detail?id=161753
>
> Thoughts?
>
> -Dave
>
>

-- 
-Dave

From gphemsley at gmail.com  Thu Nov 29 11:40:01 2012
From: gphemsley at gmail.com (Gordon P. Hemsley)
Date: Thu, 29 Nov 2012 14:40:01 -0500
Subject: [whatwg] [mimesniff] Treating application/octet-stream as
 unknown for sniffing
In-Reply-To: <CAJE5ia8=gEboxDqTmY7n_7Ca+L8eFpjE3_48ZjjgypbroZTmBg@mail.gmail.com>
References: <CAH4e3M5h9=7+MzCUFMBw6Mh5FW6zBc2e+FkjkhAvoofzAnm0Hg@mail.gmail.com>
	<CAJE5ia8=gEboxDqTmY7n_7Ca+L8eFpjE3_48ZjjgypbroZTmBg@mail.gmail.com>
Message-ID: <CAH4e3M4c=G9LvFZYLONka_9MkH-JyvC4VaVpP9ijNhQJWvqTRw@mail.gmail.com>

On Thu, Nov 29, 2012 at 2:30 PM, Adam Barth <w3c at adambarth.com> wrote:
> On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley <gphemsley at gmail.com> wrote:
>> Based on my reading of the source code, it seems that Gecko treats a
>> resource served as 'application/octet-stream' as an unknown type which
>> is sniffed as if no Content-Type was specified.
>>
>> Are there security implications with doing this?
>
> Yes, there are very large security consequences.  I'm sorry that I
> don't have time to respond to all of these threads in detail, but I'm
> worried that you don't understand the consequences of the changes
> you're proposing to this specification.
>
> I'm not sure how to help you succeed here, but tweaking things in the
> spec without a compelling reason for doing so is not likely to lead to
> a useful specification.  I spent a great deal of time and effort
> studying the behaviors of many user agents and of a massive amount of
> content on the web.  I'm certainly willing to believe that the spec
> can be improved, but if you don't understand these sorts of basic
> things about content sniffing, I worry that changes that you make to
> the spec won't be improvements.
>
> Adam

I and others have already made clear that I was misreading the Mozilla
source code.

I'm aware of the security implications of interpreting a resource as
something other than what the Content-Type header says. The whole
reason I sent the original e-mail was because I thought Mozilla was
sniffing "application/octet-stream" in a way that it shouldn't, and I
wanted to clarify whether there was something I was missing.

I think you need to tone down your worry about my changes to the spec.
If I didn't have concern for the security implications for a change, I
wouldn't be sending an e-mail to the list about them, would I?

-- 
Gordon P. Hemsley
me at gphemsley.org
http://gphemsley.org/ ? http://gphemsley.org/blog/

From ian at hixie.ch  Thu Nov 29 12:50:57 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 20:50:57 +0000 (UTC)
Subject: [whatwg] AppCache Error events
In-Reply-To: <CA+iXHYNk7NaWUFt2bX2_r7NK3eER6d_8uY=fpskyHPPx22xvdg@mail.gmail.com>
References: <CA+iXHYO4CrvH27cOX15g1_RFQCjqDVLnynbD34U3HRhVoZoDrQ@mail.gmail.com>
	<CA+iXHYNk7NaWUFt2bX2_r7NK3eER6d_8uY=fpskyHPPx22xvdg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211292047220.12469@ps20323.dreamhostps.com>

On Thu, 29 Nov 2012, David Barrett-Kahn wrote:
>
> So are there no objections to this, should I draft a change to the spec?

The "process", insofar as we have one, is what is described here:

http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

At some point, I get around to examining all the e-mails on a topic, and 
I try to determine what level of interest there is from implementors, and 
then I respond. Right now my lag is about four months, though it tends to 
be longer for requests for new features and shorter for major bug fixes.

From michaeln at google.com  Thu Nov 29 13:36:30 2012
From: michaeln at google.com (Michael Nordman)
Date: Thu, 29 Nov 2012 13:36:30 -0800
Subject: [whatwg] AppCache Error events
In-Reply-To: <CA+iXHYNk7NaWUFt2bX2_r7NK3eER6d_8uY=fpskyHPPx22xvdg@mail.gmail.com>
References: <CA+iXHYO4CrvH27cOX15g1_RFQCjqDVLnynbD34U3HRhVoZoDrQ@mail.gmail.com>
	<CA+iXHYNk7NaWUFt2bX2_r7NK3eER6d_8uY=fpskyHPPx22xvdg@mail.gmail.com>
Message-ID: <CAHpoE=hD3ec4ADiEO8WKzK935ebrQWupPB=JhX10Aa5m46+CMw@mail.gmail.com>

Sounds reasonable to me. Webkit and chromium expose information like this
via the inspector console so users/developers at that can better diagnose
problems locally. Makes sense to also expose that info to app logic so
developers could diagnose from afar.

On Thu, Nov 29, 2012 at 11:40 AM, David Barrett-Kahn <dbk at google.com> wrote:

> So are there no objections to this, should I draft a change to the spec?
>
> -Dave
>
> On Mon, Nov 26, 2012 at 12:00 PM, David Barrett-Kahn <dbk at google.com>
> wrote:
>
> > Right now this event contains no structured information, just an error
> > message.  It'd be helpful to us to know more about what failed, so we can
> > know what to report to the server and take action on.  It's hard to
> > distinguish cache update failures due to just being offline from those
> > which are actually causing trouble.  In the second case it's also hard to
> > work out which resource is proving unavailable and why.
> >
> > One way to do this would be to create an AppCacheError subclass, with an
> > errorCode parameter, and also nullable url and httpResponseCode
> properties.
> >  Potential error codes:
> > * couldn't fetch manifest (includes url and httpResponseCode)
> > * pre and post update manifest fetches mismatched (includes url)
> > * fetching a resource failed (includes url and httpResponseCode)
> >
> > Related bug:
> > https://code.google.com/p/chromium/issues/detail?id=161753
> >
> > Thoughts?
> >
> > -Dave
> >
> >
>
>
> --
> -Dave
>

From ian at hixie.ch  Thu Nov 29 14:09:00 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 22:09:00 +0000 (UTC)
Subject: [whatwg] Adding crossorigin="" to more elements
In-Reply-To: <50B6DFBD.9070301@mit.edu>
References: <503D0918.1010203@mit.edu>
	<Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>
	<50B6DE78.5040500@mit.edu> <50B6DFBD.9070301@mit.edu>
Message-ID: <Pine.LNX.4.64.1211292159180.9975@ps20323.dreamhostps.com>

On Wed, 28 Nov 2012, Boris Zbarsky wrote:
> On 11/28/12 7:42 PM, Ian Hickson wrote:
> > Done, at least on the HTML side. For now it just makes .sheet return 
> > null for cross-origin resources.
> 
> Pretty sure that's not web-compatible...

Yeah, I don't expect it is. This stuff is going to change as part of the 
bug below though so I'm not too worried for now.

> > If that's not quite right, please update this bug with the details:
> > 
> >     https://www.w3.org/Bugs/Public/show_bug.cgi?id=14703
> 
> Done.

Thanks.

> > > An open issue: what to do about @import?  I haven't done anything 
> > > magic here yet.  Inheriting the CORS mode from the importing sheet 
> > > is a bit weird, and I wasn't quite sure I wanted to make CSS syntax 
> > > changes at this time.
> > 
> > Inheriting the mode isn't so bad, all it really does is decide whether 
> > or not to send an Origin header.
> 
> Not quite.  It also affects what happens when the server doesn't respond 
> with an appropriate Allow-Origin.  A CORS-enabled load from a server 
> that knows nothing about CORS will throw away the sheet, while a no-CORS 
> load will happily apply the sheet to the page (but not give access to 
> its data).  So inheriting the mode can cause drastic changes in behavior 
> compared to not inheriting it...

Well, yeah, but the sheet knows which mode it's in, so I don't think that 
part of it is a big deal.

> > > If the CORS mode is inherited from the importing sheet, then I think 
> > > the "origin" for the fetch should be the page, not the importing 
> > > sheet, since the page is what would get access to the stylesheet 
> > > data.
> > 
> > Right, the origin of the importing sheet in this situation is the 
> > origin of the page that imported it, not the origin of its URL. That's 
> > what CORS does, it changes the effective origin of a resource from 
> > being the origin its URL would suggest it had, to being the origin of 
> > its caller.
> 
> That's not quite correct.  It changes the _object_ origin to that of the 
> caller.  It doesn't change the _subject_ origin.

True (assuming we define those terms somewhere).

The real issue here is that CSS is different than other things we've 
applied CORS to before, in that it is, to some level, "alive". Before 
we've applied it to bitmaps (that can't do anything), scripts (that aren't 
in any way limited in the first place), and media (that can't do 
anything). This is the first time, I think, that we've used CORS with 
something that can do something with its privileges.

Anyway, this is somewhat moot to me because it'll all have to be defined 
by whatever spec it is that currently says that a CSS sheet on http: 
can't import an image on file:, etc.

On Wed, 28 Nov 2012, Boris Zbarsky wrote:
> 
> Oh, I see.  You've added this "taint" thing, which you're using for the 
> CSS bit.

That only applies when there's no crossorigin="" attribute, unless I made 
a mistake in the speccing.

> I don't believe Gecko has any such concept.

Well presumably you don't block all cross-origin loads of CSS when there's 
no crossorigin="" attribute. :-)

From ian at hixie.ch  Thu Nov 29 15:51:37 2012
From: ian at hixie.ch (Ian Hickson)
Date: Thu, 29 Nov 2012 23:51:37 +0000 (UTC)
Subject: [whatwg] Exposing framerate / statistics of <video> playback
 and related feedback
In-Reply-To: <4FA01EE7.6030407@jumis.com>
References: <AANLkTik6GpAcGVNDWxZpJ_Sjh3VYRFk+ePtbTm69PmuE@mail.gmail.com>
	<AANLkTi=yTeHcdmCEYT29+MsJr6__J+MhZEh8FZ1CY-28@mail.gmail.com>
	<Pine.LNX.4.64.1204302201340.1631@ps20323.dreamhostps.com>
	<CAEHyr+ZypQSRP_NMmLTnn=dM0-v+Mw6c47QDnL6VgPMZ0oPLuw@mail.gmail.com>
	<4FA01EE7.6030407@jumis.com>
Message-ID: <Pine.LNX.4.64.1211292350270.9975@ps20323.dreamhostps.com>

On Tue, 1 May 2012, Charles Pritchard wrote:
> 
> The list looked at having a (canvas) ctx.stream = mediaElement; option 
> to better copy frames from a media stream into Canvas. I don't think 
> that the assignment operator will work, but it does seem like we could 
> optimize our drawImage calls to only happen when needed. At present, we 
> simply would run requestAnimationFrame. But, if a video stream is 
> operating on a slower frame rate than rAF, then the drawImage + rAF 
> method will be wasteful.
> 
> I've suggested an onframeready event; it seems as though that event 
> could also carry the number of dropped frames.

I haven't added this, because copying a video one frame at a time doesn't 
seem like an efficient way to do anything. Some sort of mechanism like 
what I had proposed for WebRTC (not sure if it's still in there) seems 
like a more solid solution, letting the browser do all the heavy lifting 
(potentially off the main thread).

From ian at hixie.ch  Thu Nov 29 16:06:29 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 30 Nov 2012 00:06:29 +0000 (UTC)
Subject: [whatwg] A <link rel=stylesheet scoped> usecase
In-Reply-To: <4FD15902.5020400@csail.mit.edu>
References: <mailman.631.1330714712.31965.whatwg-whatwg.org@lists.whatwg.org>
	<20120303033321997228.57a8a5d2@xn--mlform-iua.no>
	<Pine.LNX.4.64.1206072313130.378@ps20323.dreamhostps.com>
	<4FD15902.5020400@csail.mit.edu>
Message-ID: <Pine.LNX.4.64.1211300001360.9975@ps20323.dreamhostps.com>

On Fri, 8 Jun 2012, Kang-Hao (Kenny) Lu wrote:
> (12/06/08 7:28), Ian Hickson wrote:
> > It still seems like a bit of an edge case, so I think it's ok for us 
> > to continue to rely on @import for this for now. But we should keep an 
> > eye out for how often people use this technique; if it is indeed 
> > something that comes up a lot, then introducing scoped="" on <link 
> > rel=stylesheet> would make sense.
> 
> (12/03/03 2:03), Kang-Hao (Kenny) Lu wrote:
> > A reader of html5doctor had the same problem too[1] and I can 
> > certainly image other people being confused by this.
> >
> > [1] http://html5doctor.com/the-scoped-attribute/#link
> 
> which I mentioned, Googling the string "html5 scoped @import" gives me 
> the following sites which mention this technique, even if there's only 
> one browser supporting the 'scoped' attribute at the moment: [2][3][4]
> 
> [2] http://www.codingforums.com/showthread.php?t=242411#postcount1154993
> [3] http://www.webdirections.org/blog/on-the-abominable-proposed-html5-scoped-attribute-for-style-elements/#comment-222761
> [4] http://www.peterrknight.com/loading-javascript-and-css-mid-page-html5-wordpress-passing-validation-part-1/

Yeah, that's fair enough.

Righ now I can't find any browsers that implement <style scoped>. Unless 
<link scoped> is preferred by vendors than <style scoped>, I'd rather get 
one implemented and proven to work before we add more, so I still haven't 
added <link scoped>. To make sure I don't forget about this, though, I've 
filed it as a bug and will mark it LATER.

https://www.w3.org/Bugs/Public/show_bug.cgi?id=20166

From bzbarsky at MIT.EDU  Thu Nov 29 18:13:39 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 29 Nov 2012 21:13:39 -0500
Subject: [whatwg] Adding crossorigin="" to more elements
In-Reply-To: <Pine.LNX.4.64.1211292159180.9975@ps20323.dreamhostps.com>
References: <503D0918.1010203@mit.edu>
	<Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>
	<50B6DE78.5040500@mit.edu> <50B6DFBD.9070301@mit.edu>
	<Pine.LNX.4.64.1211292159180.9975@ps20323.dreamhostps.com>
Message-ID: <50B81653.2000406@mit.edu>

On 11/29/12 5:09 PM, Ian Hickson wrote:
> Well, yeah, but the sheet knows which mode it's in, so I don't think that
> part of it is a big deal.

Maybe.  Problems can arise with a sheet that itself sends CORS headers 
but links to sheets that don't and that's tested in a UA that doesn't do 
<link crossorigin>.  But OK.  I'll see about inheriting the CORS mode.

> The real issue here is that CSS is different than other things we've
> applied CORS to before, in that it is, to some level, "alive".

Yep.  See https://bugzilla.mozilla.org/show_bug.cgi?id=732209#c1 for a 
(probably non-exhaustive) list of possible meanings for CORS here.  I 
implemented option 5 in Gecko.

> Anyway, this is somewhat moot to me because it'll all have to be defined
> by whatever spec it is that currently says that a CSS sheet on http:
> can't import an image on file:, etc.

Heh.  Does it affect things like CSP in any way?

> On Wed, 28 Nov 2012, Boris Zbarsky wrote:
>>
>> Oh, I see.  You've added this "taint" thing, which you're using for the
>> CSS bit.
>
> That only applies when there's no crossorigin="" attribute, unless I made
> a mistake in the speccing.

Oh, ok.  Sorry.  Reading diffs of HTML is a pain.  :(

> Well presumably you don't block all cross-origin loads of CSS when there's
> no crossorigin="" attribute. :-)

Sure.  We don't do any sort of "tainting" either, though; we simply 
remember the origin of the CSS (where it was actually loaded from, 
post-redirect, not the original URI) and do a same-origin check when you 
try to use the CSSOM on it.  Note that this check is done against the 
effective script origin of the script doing the CSSOM access, which may 
not actually match the origin of the page the CSS is loaded for, etc. 
Not sure whether the tainting setup you describe is equivalent to that, 
though I doubt it is.

-Boris

From ian at hixie.ch  Thu Nov 29 18:44:30 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 30 Nov 2012 02:44:30 +0000 (UTC)
Subject: [whatwg] Adding crossorigin="" to more elements
In-Reply-To: <50B81653.2000406@mit.edu>
References: <503D0918.1010203@mit.edu>
	<Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>
	<50B6DE78.5040500@mit.edu> <50B6DFBD.9070301@mit.edu>
	<Pine.LNX.4.64.1211292159180.9975@ps20323.dreamhostps.com>
	<50B81653.2000406@mit.edu>
Message-ID: <Pine.LNX.4.64.1211300233520.12469@ps20323.dreamhostps.com>

On Thu, 29 Nov 2012, Boris Zbarsky wrote:
> > 
> > Anyway, this is somewhat moot to me because it'll all have to be 
> > defined by whatever spec it is that currently says that a CSS sheet on 
> > http: can't import an image on file:, etc.
> 
> Heh.  Does it affect things like CSP in any way?

No idea. Adam?

> > That only applies when there's no crossorigin="" attribute, unless I 
> > made a mistake in the speccing.
> 
> Oh, ok.  Sorry.  Reading diffs of HTML is a pain.  :(

Yeah, couldn't agree more. If you have any idea how I can improve this, by 
the way, let me know. I tried running HTML diff tools for a while, but 
couldn't find one that actually could handle a 5MB file, and in any case 
they didn't really make things any more readable than plain text diffs in 
practice.

> Sure.  We don't do any sort of "tainting" either, though; we simply 
> remember the origin of the CSS (where it was actually loaded from, 
> post-redirect, not the original URI) and do a same-origin check when you 
> try to use the CSSOM on it.  Note that this check is done against the 
> effective script origin of the script doing the CSSOM access, which may 
> not actually match the origin of the page the CSS is loaded for, etc. 
> Not sure whether the tainting setup you describe is equivalent to that, 
> though I doubt it is.

The behaviour called "tainting" in this context in the spec just means 
"treat as a cross-origin resource" as opposed to "treat as a network 
failure". The term comes from the first time I introduced crossorigin="", 
which was for <img>, where the default behaviour of cross-origin images as 
opposed to same-origin images is that they taint the canvas.

From bzbarsky at MIT.EDU  Thu Nov 29 18:47:18 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Thu, 29 Nov 2012 21:47:18 -0500
Subject: [whatwg] Adding crossorigin="" to more elements
In-Reply-To: <Pine.LNX.4.64.1211300233520.12469@ps20323.dreamhostps.com>
References: <503D0918.1010203@mit.edu>
	<Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>
	<50B6DE78.5040500@mit.edu> <50B6DFBD.9070301@mit.edu>
	<Pine.LNX.4.64.1211292159180.9975@ps20323.dreamhostps.com>
	<50B81653.2000406@mit.edu>
	<Pine.LNX.4.64.1211300233520.12469@ps20323.dreamhostps.com>
Message-ID: <50B81E36.7040903@mit.edu>

On 11/29/12 9:44 PM, Ian Hickson wrote:
> The behaviour called "tainting" in this context in the spec just means
> "treat as a cross-origin resource"

Right.  My point was that "cross-origin" for the case of stylesheet at 
least in Gecko depends on the origin of the script that tries to modify 
them, not on the origin of the document that linked to them...

Wish I had any bright idea on HTML diffs.  :(

-Boris

From ian at hixie.ch  Thu Nov 29 21:14:25 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 30 Nov 2012 05:14:25 +0000 (UTC)
Subject: [whatwg] Load events fired during onload handlers
In-Reply-To: <CAJQvAucJ0T1oriUWQ5a=O=GNtMnnq1OuHXyx-ZKcW+P3zYs0NA@mail.gmail.com>
References: <5016A3FA.1030200@opera.com> <5016ABCE.10309@mit.edu>
	<5016B02C.6010502@opera.com> <50183786.3010106@mit.edu>
	<CAJQvAucJ0T1oriUWQ5a=O=GNtMnnq1OuHXyx-ZKcW+P3zYs0NA@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211300034070.9975@ps20323.dreamhostps.com>

On Mon, 30 Jul 2012, James Graham wrote:
>
> There seems to be general agreement (amongst browsers, not yet the spec) 
> that if a document does something that causes a new load event from 
> within an onload handler (document.open/document.close) the second load 
> event is not dispatched. This also applies to the load event on iframe 
> elements if an event handler in the iframe would synchronously cause a 
> second load event to fire.
> 
> There is not agreement about what happens where there are multiple 
> frames e.g. if a load event handler on iframe element A would cause a 
> load event in iframe B, should the handler on B fire. Gecko says yes, 
> WebKit no. There is a slightly rubbish demo at [1].
>
> [1] http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1686

On Tue, 31 Jul 2012, Boris Zbarsky wrote:
> 
> Gecko fires the load event on the <iframe> as part of the default action 
> of the load event on the window inside that iframe.  I think the spec 
> might actually call for it to fire async instead, though I haven't 
> tested what other UAs do there.

Per spec it's effectively async. More importantly, though, per spec the 
'load' event on the <iframe> is delayed by some stuff that the 'load' 
event _in_ the <iframe> isn't delayed by, e.g. readyState changes, 
pageshow is fired, and delayed printing steps are executed, between them.

> The code for firing the load event looks somewhat like this:
> 
>     if (!mEODForCurrentDocument) {
>         mIsExecutingOnLoadHandler = true;
>         // Fire onload here
>         mIsExecutingOnLoadHandler = false;
>         mEODForCurrentDocument = true;
>     }
> 
> and the handling for document.open() sets mEODForCurrentDocument to 
> false. Now what happens is we enter the above code for the normal load.  
> We fire the onload handler, which does the open()/write()/close() thing.  
> That tries to set mEODForCurrentDocument to false, but of course it's 
> already false.  When close() happens, onload does NOT fire sync from the 
> close() call, because there are still outstanding async tasks on the new 
> document that block onload. So we unwind the stack to the code above, 
> and set mEODForCurrentDocument to true, and block any further firing of 
> onload for this document until another open() call happens.
>
> Fundamentally, that looks like a bug in the handling of 
> mEODForCurrentDocument, really.
> 
> So if either that bug were fixed or item #1 above were changed, I think 
> you'd get two load events here in Gecko right now.

I haven't changed the spec to match Gecko here, since you seem open to 
changing Gecko. :-)

On Mon, 30 Jul 2012, James Graham wrote:
> On 07/30/2012 05:44 PM, Boris Zbarsky wrote:
> > On 7/30/12 11:10 AM, James Graham wrote:
> > > I don't think I have a strong opinion about what should happen here, 
> > > but the Gecko behaviour could be easier to implement, and the WebKit 
> > > behaviour slightly safer (presumably the point of this anomaly is to 
> > > prevent infinite loops in load event handers).
> > 
> > In Gecko's case, the only thing like that I know of is that onload 
> > fires synchronously in Gecko in some cases, I believe. So we had to 
> > put in some sort of recursion guard to prevent firing onload on a 
> > parent in the middle of a child firing onload or something like that.  
> > See <https://bugzilla.mozilla.org/show_bug.cgi?id=330089>.  Per spec, 
> > onload is always async, so this wouldn't be a concern.
> 
> Yeah, but as far as I can tell all browsers block (same document) load 
> events that happen from inside onload [1], so I *guess* at some point in 
> the past a site got into an infinite loop by trying to use document.open 
> from inside onload.
> [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17231

I wrote a similar test to the one you put in the bug:

http://damowmow.com/playground/demos/onload/001.html

It shows the onload handler actually getting called again in Gecko.

The interesting thing about the test in the bug is that it's actually the 
<iframe>'s onload that's not being called again, no page onload is being 
tested in that test. So for that test, the solution I suggested in comment 
10 in that bug is worthless.

Also interesting is that if you check what's actually going on, you'll 
find that in Opera and Gecko (and per spec) the iframe's onload is run 
asynchronously, whereas in WebKit it's synchronous.

That it's asynchronous means that what we need to do is:

* in the iframe code that fires 'load', annotate the iframe's document so 
   that it knows we're in a 'load' event handler,
 * in the document.open() code, set a flag to true if the aforementioned
   annotation is set, and false otherwise,
 * in the iframe code that fires 'load', don't fire 'load' if the
   aforementioned flag is set.

Sibling frames:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1937
   http://software.hixie.ch/utilities/js/live-dom-viewer/saved/1938

Gecko and Opera go on to infinity there; WebKit blocks, but being 
synchronous means that the algorithm above would block this case, so that 
makes sense.

I've put the above suggestion in the bug, if nobody objects to it then 
I'll spec that.

On Thu, 2 Aug 2012, Henri Sivonen wrote:
>
> For what it's worth, I think the weirdness described in this thread is a 
> good reason not to try to make DOMContentLoaded consistent with the load 
> event for the sake of consistency. For one thing, the code that manages 
> the weirdness of the load event lives in a different place compared to 
> the code that fires DOMContentLoaded.

Per spec they're about as consistent with each other as they can be, 
currently. (That's not to say that they're correctly specced; indeed 
there's an outstanding bug about making the "abort" steps work like the 
"the end" steps.)

From gman at google.com  Thu Nov 29 23:24:17 2012
From: gman at google.com (=?UTF-8?B?R3JlZ2cgVGF2YXJlcyAo56S+55SoKQ==?=)
Date: Fri, 30 Nov 2012 16:24:17 +0900
Subject: [whatwg] Canvas in Workers
In-Reply-To: <CAO9Q3iLfrHp8mS7Bg9aLzwT81f87NLad5Z=W5JE5FWs4cEbqjQ@mail.gmail.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
	<CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>
	<Pine.LNX.4.64.1211162147040.16964@ps20323.dreamhostps.com>
	<CAHfnhfq0cgZSVgc5e+DuU0QGQ2+HykTiNN0yiLgKfydjjuK-4A@mail.gmail.com>
	<CAKZ+BNoFMP8PqnfBnfK9PEPALip4mxc9GcRzcE_AO=Sd0z5cfw@mail.gmail.com>
	<CAO9Q3iLfrHp8mS7Bg9aLzwT81f87NLad5Z=W5JE5FWs4cEbqjQ@mail.gmail.com>
Message-ID: <CAKZ+BNrLpNEu=qWozcPhkh4GoYuxUHN_e74HGJJJKro3sydQfg@mail.gmail.com>

on ImageBitmap should zero size canvases just work (and create a 0 sized
ImageBitmap)?

My personal preference is for APIs that just work with zero sizes so I
don't have to write lots of special cases for handling zero.

For example [1,2,3].slice(0,0) returns []. It doesn't throw.
"abc".substring(0,0) returns "" it doesn't throw. fillRect(x, y, 0, 0)
doesn't throw. etc...

It just makes life a lot easier

On Tue, Nov 20, 2012 at 3:33 AM, Elliott Sprehn <esprehn at chromium.org>wrote:

>
> On Mon, Nov 19, 2012 at 12:26 AM, Gregg Tavares (??) <gman at google.com>wrote:
>
>> Sorry if this is clear in the specs but can you explain how sizing the
>> canvas works?
>>
>>
>>    // main.html
>>    <canvas></canvas>
>>    <script>
>>     var canvas = document.getElementsByTagName('canvas')[0];
>>     var worker = new Worker('clock.js');
>>     var proxy = canvas.transferControlToProxy());
>>     worker.postMessage(proxy, [proxy]);
>>
>>     setTimeout(function() {
>>         canvas.width = 200;   // does this work? What happens?
>>
>
> You resize the output surface that the image coming from the worker will
> be drawn into. This is different than changing the buffer used for drawing.
>
>     }, 4000);
>>    </script>
>>
>>    // clock.js worker
>>    onmessage = function (event) {
>>      var context = new CanvasRenderingContext2d();
>>      event.data.setContext(context);
>>      setInterval(function () {
>>        context.width = 400;  // Can I do this? What happens when I do?
>>
>
> You resize the buffer that's inside of the worker.
>
> - E
>

From jan.varga at gmail.com  Fri Nov 30 05:23:39 2012
From: jan.varga at gmail.com (Jan Varga)
Date: Fri, 30 Nov 2012 14:23:39 +0100
Subject: [whatwg] Menus and Toolbars
In-Reply-To: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
References: <Pine.LNX.4.64.1211272004390.1991@ps20323.dreamhostps.com>
Message-ID: <CAB1sDKwWAnJ55CfvNUFmXw1=gOxN2VgtC9xqN_AZ70V6WNeM5g@mail.gmail.com>

Hi,
I like the 2nd proposal, but #3 would be ok too in my opinion

Jan

On Wed, Nov 28, 2012 at 1:12 AM, Ian Hickson <ian at hixie.ch> wrote:

From annevk at annevk.nl  Fri Nov 30 09:17:55 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 30 Nov 2012 18:17:55 +0100
Subject: [whatwg] URL: URLQuery
In-Reply-To: <CAAWBYDDdGbSkG5cMRbroV0szydEKu6HeGijijU3MB4NgK3CXbw@mail.gmail.com>
References: <CADnb78gy8q0zT23zPwNkym1T9KS688y1AzzijKy=TJrUvtBNoQ@mail.gmail.com>
	<CAAWBYDDdGbSkG5cMRbroV0szydEKu6HeGijijU3MB4NgK3CXbw@mail.gmail.com>
Message-ID: <CADnb78ixOUa+F7wWKjkyCtpZ4-aA8RcaL2jKtiaA1xfULUTdKg@mail.gmail.com>

On Sat, Oct 13, 2012 at 12:24 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> If we do stick with the method-based map, I strongly feel we should
> match the JS Map API, and have a has() method as well.  *Ideally*,
> this would be a subclass of Map.

This is now done: http://url.spec.whatwg.org/#urlquery

Feedback welcome!

(Note that IDL bits for initializing with a dictionary and making it
based on Map underneath are still in progress.)

-- 
http://annevankesteren.nl/

From jackalmage at gmail.com  Fri Nov 30 09:42:54 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 30 Nov 2012 09:42:54 -0800
Subject: [whatwg] URL: URLQuery
In-Reply-To: <CADnb78ixOUa+F7wWKjkyCtpZ4-aA8RcaL2jKtiaA1xfULUTdKg@mail.gmail.com>
References: <CADnb78gy8q0zT23zPwNkym1T9KS688y1AzzijKy=TJrUvtBNoQ@mail.gmail.com>
	<CAAWBYDDdGbSkG5cMRbroV0szydEKu6HeGijijU3MB4NgK3CXbw@mail.gmail.com>
	<CADnb78ixOUa+F7wWKjkyCtpZ4-aA8RcaL2jKtiaA1xfULUTdKg@mail.gmail.com>
Message-ID: <CAAWBYDDwQ47tsZABaiOGEOt1rgXU3Px5WEZ8iFPGTGnuSA4kCA@mail.gmail.com>

On Fri, Nov 30, 2012 at 9:17 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Sat, Oct 13, 2012 at 12:24 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> If we do stick with the method-based map, I strongly feel we should
>> match the JS Map API, and have a has() method as well.  *Ideally*,
>> this would be a subclass of Map.
>
> This is now done: http://url.spec.whatwg.org/#urlquery
>
> Feedback welcome!

Only feedback left is the return types of set(), append(), and delete().

In Maps, set() returns the map, so you can chain more easily.  TC39
hasn't yet made delete() return the map, but they plan to (baby steps,
apparently, but us jumping on it will help).  Obviously, append()
should match set().

~TJ

From ian at hixie.ch  Fri Nov 30 09:44:59 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 30 Nov 2012 17:44:59 +0000 (UTC)
Subject: [whatwg] Canvas in Workers
In-Reply-To: <CAKZ+BNrLpNEu=qWozcPhkh4GoYuxUHN_e74HGJJJKro3sydQfg@mail.gmail.com>
References: <20120330143901.155050@gmx.com>
	<Pine.LNX.4.64.1211161915290.26354@ps20323.dreamhostps.com>
	<CAHfnhfrFJS1kK0poaJ7nF2s4YW=KZuXc85pjfRG=q9CvM7ke6Q@mail.gmail.com>
	<Pine.LNX.4.64.1211162110510.16964@ps20323.dreamhostps.com>
	<CAHfnhfr8Q3XW0ZOcHvegvGg0dJe0-9s-1JEPyOZPEmKHvm63QA@mail.gmail.com>
	<Pine.LNX.4.64.1211162147040.16964@ps20323.dreamhostps.com>
	<CAHfnhfq0cgZSVgc5e+DuU0QGQ2+HykTiNN0yiLgKfydjjuK-4A@mail.gmail.com>
	<CAKZ+BNoFMP8PqnfBnfK9PEPALip4mxc9GcRzcE_AO=Sd0z5cfw@mail.gmail.com>
	<CAO9Q3iLfrHp8mS7Bg9aLzwT81f87NLad5Z=W5JE5FWs4cEbqjQ@mail.gmail.com>
	<CAKZ+BNrLpNEu=qWozcPhkh4GoYuxUHN_e74HGJJJKro3sydQfg@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211301743080.12469@ps20323.dreamhostps.com>

On Fri, 30 Nov 2012, Gregg Tavares (????~T?) wrote:
>
> on ImageBitmap should zero size canvases just work (and create a 0 sized
> ImageBitmap)?
> 
> My personal preference is for APIs that just work with zero sizes so I
> don't have to write lots of special cases for handling zero.
> 
> For example [1,2,3].slice(0,0) returns []. It doesn't throw.
> "abc".substring(0,0) returns "" it doesn't throw. fillRect(x, y, 0, 0)
> doesn't throw. etc...
> 
> It just makes life a lot easier

The main reason 0-sized canvases have always thrown in drawImage() is that 
I couldn't work out what you would paint, nor why you'd have a zero-sized 
canvas, and throwing seemed like it'd be the best way to help the author 
figure out where the problem was, rather than just ignoring the call and 
having the author scratch their head about why nothing was happening.

If there's cases where you would legitimately end up with zero-sized 
canvases that you'd try to draw from, though, I'm happy to change it.

From annevk at annevk.nl  Fri Nov 30 09:47:42 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 30 Nov 2012 18:47:42 +0100
Subject: [whatwg] URL: URLQuery
In-Reply-To: <CAAWBYDDwQ47tsZABaiOGEOt1rgXU3Px5WEZ8iFPGTGnuSA4kCA@mail.gmail.com>
References: <CADnb78gy8q0zT23zPwNkym1T9KS688y1AzzijKy=TJrUvtBNoQ@mail.gmail.com>
	<CAAWBYDDdGbSkG5cMRbroV0szydEKu6HeGijijU3MB4NgK3CXbw@mail.gmail.com>
	<CADnb78ixOUa+F7wWKjkyCtpZ4-aA8RcaL2jKtiaA1xfULUTdKg@mail.gmail.com>
	<CAAWBYDDwQ47tsZABaiOGEOt1rgXU3Px5WEZ8iFPGTGnuSA4kCA@mail.gmail.com>
Message-ID: <CADnb78i7AQQ71RVtm8DRn7v4xACn1_VvYXvfVpC4Skrb=c6f4A@mail.gmail.com>

On Fri, Nov 30, 2012 at 6:42 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> Only feedback left is the return types of set(), append(), and delete().
>
> In Maps, set() returns the map, so you can chain more easily.  TC39
> hasn't yet made delete() return the map, but they plan to (baby steps,
> apparently, but us jumping on it will help).  Obviously, append()
> should match set().

Right, once I have a definitive answer to
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0164.html
I will update a bunch of APIs to use chaining (assuming the answer is
that yes, this is the plan). I'm not really a fan of the style myself
so I'm not sure I want to be the one to push TC39 :-)

-- 
http://annevankesteren.nl/

From Alexandre.Morgaut at 4d.com  Fri Nov 30 10:02:45 2012
From: Alexandre.Morgaut at 4d.com (Alexandre Morgaut)
Date: Fri, 30 Nov 2012 19:02:45 +0100
Subject: [whatwg] URL: URLQuery
In-Reply-To: <CAAWBYDDwQ47tsZABaiOGEOt1rgXU3Px5WEZ8iFPGTGnuSA4kCA@mail.gmail.com>
References: <CADnb78gy8q0zT23zPwNkym1T9KS688y1AzzijKy=TJrUvtBNoQ@mail.gmail.com>
	<CAAWBYDDdGbSkG5cMRbroV0szydEKu6HeGijijU3MB4NgK3CXbw@mail.gmail.com>
	<CADnb78ixOUa+F7wWKjkyCtpZ4-aA8RcaL2jKtiaA1xfULUTdKg@mail.gmail.com>
	<CAAWBYDDwQ47tsZABaiOGEOt1rgXU3Px5WEZ8iFPGTGnuSA4kCA@mail.gmail.com>
Message-ID: <0AEE8BD5-E2CC-43CE-B815-4A2407E5687C@4d.com>

>
> Only feedback left is the return types of set(), append(), and delete().
>

Maybe remove() would be better than delete() as delete is a reserved JS keyword ;-)

Alexandre Morgaut
Wakanda Community Manager

4D SAS
60, rue d'Alsace
92110 Clichy
France

Standard : +33 1 40 87 92 00
Email :    Alexandre.Morgaut at 4d.com
Web :      www.4D.com

From annevk at annevk.nl  Fri Nov 30 10:20:47 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 30 Nov 2012 19:20:47 +0100
Subject: [whatwg] URL: URLQuery
In-Reply-To: <0AEE8BD5-E2CC-43CE-B815-4A2407E5687C@4d.com>
References: <CADnb78gy8q0zT23zPwNkym1T9KS688y1AzzijKy=TJrUvtBNoQ@mail.gmail.com>
	<CAAWBYDDdGbSkG5cMRbroV0szydEKu6HeGijijU3MB4NgK3CXbw@mail.gmail.com>
	<CADnb78ixOUa+F7wWKjkyCtpZ4-aA8RcaL2jKtiaA1xfULUTdKg@mail.gmail.com>
	<CAAWBYDDwQ47tsZABaiOGEOt1rgXU3Px5WEZ8iFPGTGnuSA4kCA@mail.gmail.com>
	<0AEE8BD5-E2CC-43CE-B815-4A2407E5687C@4d.com>
Message-ID: <CADnb78jiDmtA1crkH1K2t7x8u=exfhNYvAaNA--CFwLpe+q9yQ@mail.gmail.com>

On Fri, Nov 30, 2012 at 7:02 PM, Alexandre Morgaut
<Alexandre.Morgaut at 4d.com> wrote:
> Maybe remove() would be better than delete() as delete is a reserved JS keyword ;-)

We use it because ES6's Map uses it. It should be no problem, except
with syntax highlighting, but that is already broken by Map's
existence as I understand it.

-- 
http://annevankesteren.nl/

From jackalmage at gmail.com  Fri Nov 30 10:28:46 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 30 Nov 2012 10:28:46 -0800
Subject: [whatwg] URL: URLQuery
In-Reply-To: <CADnb78i7AQQ71RVtm8DRn7v4xACn1_VvYXvfVpC4Skrb=c6f4A@mail.gmail.com>
References: <CADnb78gy8q0zT23zPwNkym1T9KS688y1AzzijKy=TJrUvtBNoQ@mail.gmail.com>
	<CAAWBYDDdGbSkG5cMRbroV0szydEKu6HeGijijU3MB4NgK3CXbw@mail.gmail.com>
	<CADnb78ixOUa+F7wWKjkyCtpZ4-aA8RcaL2jKtiaA1xfULUTdKg@mail.gmail.com>
	<CAAWBYDDwQ47tsZABaiOGEOt1rgXU3Px5WEZ8iFPGTGnuSA4kCA@mail.gmail.com>
	<CADnb78i7AQQ71RVtm8DRn7v4xACn1_VvYXvfVpC4Skrb=c6f4A@mail.gmail.com>
Message-ID: <CAAWBYDA=vExdzKtDmZ1q09eWS191WKcrEkVLZ9Vr4-YO1XdwWA@mail.gmail.com>

On Fri, Nov 30, 2012 at 9:47 AM, Anne van Kesteren <annevk at annevk.nl> wrote:
> On Fri, Nov 30, 2012 at 6:42 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>> Only feedback left is the return types of set(), append(), and delete().
>>
>> In Maps, set() returns the map, so you can chain more easily.  TC39
>> hasn't yet made delete() return the map, but they plan to (baby steps,
>> apparently, but us jumping on it will help).  Obviously, append()
>> should match set().
>
> Right, once I have a definitive answer to
> http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0164.html
> I will update a bunch of APIs to use chaining (assuming the answer is
> that yes, this is the plan). I'm not really a fan of the style myself
> so I'm not sure I want to be the one to push TC39 :-)

Map#set returning the map is already in the draft, and there are no
plans to change it.

~TJ

From jackalmage at gmail.com  Fri Nov 30 10:29:23 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 30 Nov 2012 10:29:23 -0800
Subject: [whatwg] URL: URLQuery
In-Reply-To: <0AEE8BD5-E2CC-43CE-B815-4A2407E5687C@4d.com>
References: <CADnb78gy8q0zT23zPwNkym1T9KS688y1AzzijKy=TJrUvtBNoQ@mail.gmail.com>
	<CAAWBYDDdGbSkG5cMRbroV0szydEKu6HeGijijU3MB4NgK3CXbw@mail.gmail.com>
	<CADnb78ixOUa+F7wWKjkyCtpZ4-aA8RcaL2jKtiaA1xfULUTdKg@mail.gmail.com>
	<CAAWBYDDwQ47tsZABaiOGEOt1rgXU3Px5WEZ8iFPGTGnuSA4kCA@mail.gmail.com>
	<0AEE8BD5-E2CC-43CE-B815-4A2407E5687C@4d.com>
Message-ID: <CAAWBYDC_kt_F48X5yfRTKK+_fsHmH7+S9ovdeX4RVHeMaOMcKg@mail.gmail.com>

On Fri, Nov 30, 2012 at 10:02 AM, Alexandre Morgaut
<Alexandre.Morgaut at 4d.com> wrote:
>> Only feedback left is the return types of set(), append(), and delete().
>
> Maybe remove() would be better than delete() as delete is a reserved JS keyword ;-)

Nope, it's contextually reserved.  You can use in places like a method
name without a problem.

~TJ

From jackalmage at gmail.com  Fri Nov 30 11:23:53 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 30 Nov 2012 11:23:53 -0800
Subject: [whatwg] Make DOMStringMap constructable, and el.dataset writeable?
Message-ID: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>

Currently, el.dataset is readonly.  A friend of mine passed along a
use-case for making it writeable.

She's making a game, where the game initialization script expects
certain types of elements, and for the initial state data of the
elements to be present in data attributes on them.  She'd like to be
able to pause the game, shifting all the state data into localStorage,
then later resume by pulling it back onto elements before starting the
game script.

Right now she has to do this with a for-in loop, like:

for(var i = 0; i < cards.length; i++) {
  for(var k in carddata[i]) {
    cards[i].dataset[k] = carddata[i][k];
  }
}

It would be somewhat cleaner if she could simply construct a
DOMStringMap and assign it, like so:

for(var i = 0; i < cards.length; i++) {
  cards[i].dataset = new DOMStringMap(carddata[i]);
}

Another potentially interesting use-case for this is making it
possible to "transfer" data-* attributes from one element to another
with a simple "el1.dataset = el2.dataset;" statement.

Thoughts?

~TJ

From annevk at annevk.nl  Fri Nov 30 11:31:24 2012
From: annevk at annevk.nl (Anne van Kesteren)
Date: Fri, 30 Nov 2012 20:31:24 +0100
Subject: [whatwg] Make DOMStringMap constructable,
	and el.dataset writeable?
In-Reply-To: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
References: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
Message-ID: <CADnb78g8pigkDy3trRmXzGXER7uDUJ5nRpboYyFQUcEFPnuuGQ@mail.gmail.com>

On Fri, Nov 30, 2012 at 8:23 PM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> Thoughts?

URLQuery uses this model. But I reckon that for DOMStringMap it is a
bit trickier since it is actually mostly about manipulating DOM
attributes through a simpler interface. It's not a map that is
serialized to attributes whenever you manipulate it and seeded from
attributes whenever those are manipulated.

-- 
http://annevankesteren.nl/

From w3c at adambarth.com  Fri Nov 30 11:42:57 2012
From: w3c at adambarth.com (Adam Barth)
Date: Fri, 30 Nov 2012 11:42:57 -0800
Subject: [whatwg] Adding crossorigin="" to more elements
In-Reply-To: <Pine.LNX.4.64.1211300233520.12469@ps20323.dreamhostps.com>
References: <503D0918.1010203@mit.edu>
	<Pine.LNX.4.64.1211282306550.1991@ps20323.dreamhostps.com>
	<50B6DE78.5040500@mit.edu> <50B6DFBD.9070301@mit.edu>
	<Pine.LNX.4.64.1211292159180.9975@ps20323.dreamhostps.com>
	<50B81653.2000406@mit.edu>
	<Pine.LNX.4.64.1211300233520.12469@ps20323.dreamhostps.com>
Message-ID: <CAJE5ia-juDBfNXnE5QA0g1bm43WyT1jvUwG9omanqoeh=sbMug@mail.gmail.com>

On Thu, Nov 29, 2012 at 6:44 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Thu, 29 Nov 2012, Boris Zbarsky wrote:
>> > Anyway, this is somewhat moot to me because it'll all have to be
>> > defined by whatever spec it is that currently says that a CSS sheet on
>> > http: can't import an image on file:, etc.
>>
>> Heh.  Does it affect things like CSP in any way?
>
> No idea. Adam?

I'm not sure I have all the context for this question, but generally
CORS and CSP don't really interact with each other.  If something is
blocked by CSP, the user agent never gets to the point where it
wonders about CORS.

Adam

From bzbarsky at MIT.EDU  Fri Nov 30 13:31:12 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 30 Nov 2012 16:31:12 -0500
Subject: [whatwg] Make DOMStringMap constructable,
	and el.dataset writeable?
In-Reply-To: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
References: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
Message-ID: <50B925A0.1020503@mit.edu>

On 11/30/12 2:23 PM, Tab Atkins Jr. wrote:
> It would be somewhat cleaner if she could simply construct a
> DOMStringMap and assign it, like so:
>
> for(var i = 0; i < cards.length; i++) {
>    cards[i].dataset = new DOMStringMap(carddata[i]);

So this would copy the DOMStringMap into the dataset, not actually 
change the value of cards[i].dataset, right?

Given that, would it make more sense to just have a setFrom method on 
dataset that takes a string?  I guess the problem with that is name 
collisions with data items...

Really, what we want to be able to do here is assign a string to 
.dataset and have it do the right thing...  WebIDL doesn't really 
support that very well; perhaps it should.

> Another potentially interesting use-case for this is making it
> possible to "transfer" data-* attributes from one element to another
> with a simple "el1.dataset = el2.dataset;" statement.

Again, this would copy, not share, yes?

-Boris

From ian at hixie.ch  Fri Nov 30 15:43:20 2012
From: ian at hixie.ch (Ian Hickson)
Date: Fri, 30 Nov 2012 23:43:20 +0000 (UTC)
Subject: [whatwg] Firing all the "the end" messages on abort
In-Reply-To: <503E9670.9090708@mit.edu>
References: <CAJQvAuchTA4pCDtQHTBv1Vua7iWY0DfXOc0UqVB3Dcyo=rHQHg@mail.gmail.com>
	<Pine.LNX.4.64.1207101850440.30734@ps20323.dreamhostps.com>
	<CAJQvAudTTZCx7zs8A8s4dTuNh+xq-W8Wnt8dK+s9QEFUHvWE-A@mail.gmail.com>
	<Pine.LNX.4.64.1208292212440.30734@ps20323.dreamhostps.com>
	<503E9670.9090708@mit.edu>
Message-ID: <Pine.LNX.4.64.1211302242220.9975@ps20323.dreamhostps.com>

On Wed, 29 Aug 2012, Boris Zbarsky wrote:
> On 8/29/12 6:11 PM, Ian Hickson wrote:
> > Documents that are aborted do not need to work, they were aborted 
> > precisely because they don't need to work and are no longer needed.
> 
> Or because once again some ad was taking forever to load and the web 
> page developer is doing all their stuff from onload, so the user just 
> hit stop to finally get the damn ui to show up.

On Thu, 30 Aug 2012, Simon Pieters wrote:
> 
> Indeed. It would be pretty bad user experience if we didn't fire load 
> when the user clicks "stop".

That's for the "stop" key, though, right? Not for aborts that occur e.g. 
due to navigation, document.open(), or window.stop().

The spec doesn't say what browser UI should do, so if this is just about 
the stop key, I don't think this needs a spec change. The browser can do 
whatever it wants when you hit the stop key, e.g. just closing all network 
sockets, or stopping JS, or stopping animations, or whatever.

As far as I can tell, firing 'load' events when a document gets aborted 
due to new navigation, or document.open(), or window.stop(), is not 
Web-compatible.

From ian at hixie.ch  Fri Nov 30 16:01:29 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 1 Dec 2012 00:01:29 +0000 (UTC)
Subject: [whatwg] Make DOMStringMap constructable,
	and el.dataset writeable?
In-Reply-To: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
References: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1211302359120.12469@ps20323.dreamhostps.com>

On Fri, 30 Nov 2012, Tab Atkins Jr. wrote:
>
> She's making a game, where the game initialization script expects 
> certain types of elements, and for the initial state data of the 
> elements to be present in data attributes on them.  She'd like to be 
> able to pause the game, shifting all the state data into localStorage, 
> then later resume by pulling it back onto elements before starting the 
> game script.

Presumably you wouldn't necessarily want to grab _all_ the data-* 
attributes, since some might be from other libraries, or temporary 
transitional values used for animations or tracking things like mouse 
position.

> It would be somewhat cleaner if she could simply construct a
> DOMStringMap and assign it

I don't really understand what you would do with the DOMStringMap and 
localStorage. Can you elaborate?

From jackalmage at gmail.com  Fri Nov 30 16:04:55 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 30 Nov 2012 16:04:55 -0800
Subject: [whatwg] Make DOMStringMap constructable,
	and el.dataset writeable?
In-Reply-To: <Pine.LNX.4.64.1211302359120.12469@ps20323.dreamhostps.com>
References: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
	<Pine.LNX.4.64.1211302359120.12469@ps20323.dreamhostps.com>
Message-ID: <CAAWBYDDmcJgpQ2TwHNg7KDZZdR53UXBRGybB3xzB3tcjBSRjQw@mail.gmail.com>

On Fri, Nov 30, 2012 at 4:01 PM, Ian Hickson <ian at hixie.ch> wrote:
> On Fri, 30 Nov 2012, Tab Atkins Jr. wrote:
>> She's making a game, where the game initialization script expects
>> certain types of elements, and for the initial state data of the
>> elements to be present in data attributes on them.  She'd like to be
>> able to pause the game, shifting all the state data into localStorage,
>> then later resume by pulling it back onto elements before starting the
>> game script.
>
> Presumably you wouldn't necessarily want to grab _all_ the data-*
> attributes, since some might be from other libraries, or temporary
> transitional values used for animations or tracking things like mouse
> position.

Nah, that's fine.  Might be non-optimal in some cases, but then you
can just pick them out individually.

>> It would be somewhat cleaner if she could simply construct a
>> DOMStringMap and assign it
>
> I don't really understand what you would do with the DOMStringMap and
> localStorage. Can you elaborate?

Sorry, when putting it in localStorage, you have to serialize it to
JSON.  Then you want to revive it as a DOMStringMap initialized by an
object.

~TJ

From jackalmage at gmail.com  Fri Nov 30 16:07:09 2012
From: jackalmage at gmail.com (Tab Atkins Jr.)
Date: Fri, 30 Nov 2012 16:07:09 -0800
Subject: [whatwg] Make DOMStringMap constructable,
	and el.dataset writeable?
In-Reply-To: <50B925A0.1020503@mit.edu>
References: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
	<50B925A0.1020503@mit.edu>
Message-ID: <CAAWBYDBoj+NDf6euBSjb+EJXoC8adjh50bJgWwZcahXvNp8UYg@mail.gmail.com>

On Fri, Nov 30, 2012 at 1:31 PM, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> On 11/30/12 2:23 PM, Tab Atkins Jr. wrote:
>> It would be somewhat cleaner if she could simply construct a
>> DOMStringMap and assign it, like so:
>>
>> for(var i = 0; i < cards.length; i++) {
>>    cards[i].dataset = new DOMStringMap(carddata[i]);
>
> So this would copy the DOMStringMap into the dataset, not actually change
> the value of cards[i].dataset, right?

Sure.  I presume you're afraid of multiple elements sharing the same object?

> Given that, would it make more sense to just have a setFrom method on
> dataset that takes a string?  I guess the problem with that is name
> collisions with data items...

Yes, collisions make this a no-go.

> Really, what we want to be able to do here is assign a string to .dataset
> and have it do the right thing...  WebIDL doesn't really support that very
> well; perhaps it should.

What would the string be?  String-serialized JSON object?

Isn't this what [PutForwards] is for?

>> Another potentially interesting use-case for this is making it
>> possible to "transfer" data-* attributes from one element to another
>> with a simple "el1.dataset = el2.dataset;" statement.
>
> Again, this would copy, not share, yes?

Yes.  I presume same fear?

~TJ

From bzbarsky at MIT.EDU  Fri Nov 30 17:49:47 2012
From: bzbarsky at MIT.EDU (Boris Zbarsky)
Date: Fri, 30 Nov 2012 20:49:47 -0500
Subject: [whatwg] Make DOMStringMap constructable,
	and el.dataset writeable?
In-Reply-To: <CAAWBYDBoj+NDf6euBSjb+EJXoC8adjh50bJgWwZcahXvNp8UYg@mail.gmail.com>
References: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
	<50B925A0.1020503@mit.edu>
	<CAAWBYDBoj+NDf6euBSjb+EJXoC8adjh50bJgWwZcahXvNp8UYg@mail.gmail.com>
Message-ID: <50B9623B.10307@mit.edu>

On 11/30/12 7:07 PM, Tab Atkins Jr. wrote:
> Sure.  I presume you're afraid of multiple elements sharing the same object?

We can call it "afraid" or we can call it "nonsensical" since the object 
is just syntactic sugar on top of the (not shared) attributes the 
objects have.... ;)

>> Really, what we want to be able to do here is assign a string to .dataset
>> and have it do the right thing...  WebIDL doesn't really support that very
>> well; perhaps it should.
>
> What would the string be?  String-serialized JSON object?

Whatever you're proposing be passed to the DOMStringMap constructor, no?

> Isn't this what [PutForwards] is for?

Unfortunately, no.  [PutForwards] will take the RHS and pass it to the 
setter of some attribute of the LHS.  But that requires there to be such 
an attribute, which is a no-go due to the name collision thing...

Basically what we want here is an IDL attribute for which the getter 
returns one type but the setter takes a different type.  Or something. 
We can do it the way you proposed, but it seems like a workaround for 
the lack of ability to declare such a thing in WebIDL.

> Yes.  I presume same fear?

Yes.

-Boris

From ian at hixie.ch  Fri Nov 30 18:55:08 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 1 Dec 2012 02:55:08 +0000 (UTC)
Subject: [whatwg] Make DOMStringMap constructable,
	and el.dataset writeable?
In-Reply-To: <CAAWBYDDmcJgpQ2TwHNg7KDZZdR53UXBRGybB3xzB3tcjBSRjQw@mail.gmail.com>
References: <CAAWBYDDVSJreETHcqSuyJ9CRwu8X7tmufCnws=0J2UUmX+NfqQ@mail.gmail.com>
	<Pine.LNX.4.64.1211302359120.12469@ps20323.dreamhostps.com>
	<CAAWBYDDmcJgpQ2TwHNg7KDZZdR53UXBRGybB3xzB3tcjBSRjQw@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1212010130480.12469@ps20323.dreamhostps.com>

On Fri, 30 Nov 2012, Tab Atkins Jr. wrote:
> On Fri, Nov 30, 2012 at 4:01 PM, Ian Hickson <ian at hixie.ch> wrote:
> > On Fri, 30 Nov 2012, Tab Atkins Jr. wrote:
> >> She's making a game, where the game initialization script expects
> >> certain types of elements, and for the initial state data of the
> >> elements to be present in data attributes on them.  She'd like to be
> >> able to pause the game, shifting all the state data into localStorage,
> >> then later resume by pulling it back onto elements before starting the
> >> game script.
> >
> > Presumably you wouldn't necessarily want to grab _all_ the data-*
> > attributes, since some might be from other libraries, or temporary
> > transitional values used for animations or tracking things like mouse
> > position.
> 
> Nah, that's fine.  Might be non-optimal in some cases, but then you
> can just pick them out individually.

Well that's kind of my point. You can pick them out individually... how 
common is it going to be that you want all of them?

> >> It would be somewhat cleaner if she could simply construct a
> >> DOMStringMap and assign it
> >
> > I don't really understand what you would do with the DOMStringMap and
> > localStorage. Can you elaborate?
> 
> Sorry, when putting it in localStorage, you have to serialize it to
> JSON.  Then you want to revive it as a DOMStringMap initialized by an
> object.

If you're going to do all that work, why not just do it with the element?

From ian at hixie.ch  Fri Nov 30 18:57:53 2012
From: ian at hixie.ch (Ian Hickson)
Date: Sat, 1 Dec 2012 02:57:53 +0000 (UTC)
Subject: [whatwg] Making cross-origin <iframe seamless=""> (partly) usable
In-Reply-To: <4FC21CB7.1040408@gmx.ch>
References: <CAJE5ia__1ecK3uDsz-JTKhGUEwKZGqs46d+x4vG8E-xb-fyuLA@mail.gmail.com>
	<4FC1FB34.4060008@gmx.ch>
	<CAJE5ia_qEstviP9NAkiBuY=GTr3waTWZB=C4QatW4Er7Shfcyw@mail.gmail.com>
	<4FC21CB7.1040408@gmx.ch>
Message-ID: <Pine.LNX.4.64.1211292235280.9975@ps20323.dreamhostps.com>

This thread discussed solutions for, amongst others, the following use 
cases, provided to me off-list by Steven Wittens:

> A first huge use case is Facebook Apps, which are inserted using
> iframes. They currently use ugly cross-frame communication methods
> to shrink-wrap and auto-size the iframe. As an ex-FB dev, this has
> always been a huge source of frustration and bugs. Facebook Apps
> don't want to inherit CSS from the parent site, it only means the
> layout will break whenever Facebook makes a stylistic change or
> reorganizes their CSS. Replace Facebook with any other service
> provider that allows some form of 3rd party development/integration
> through iframes.
>
> A second use case would be any sort of embeddable widget that comes
> with "pre-baked" styles (think Twitter sidebar widgets). Same
> problem, but in reverse. At my last job, we had a drop-in iframe
> product that provided an entire "contest in a box", with media
> submission, entry browsing/searching, modal dialogs, etc. Inheriting
> styles from the parent page would simply destroy the careful layout
> of what's inside. We shrink wrapped it by requiring people to embed
> a script tag rather than iframe tag, using cross frame communication
> to send a manual measurement from the frame to the parent. Ugly, and
> didn't work in older browsers, and we didn't have the resources to
> come up with an XD-proxy workaround like Facebook has.

Markus Ernst also discussed the use cases:

On Fri, 13 Apr 2012, Markus Ernst wrote:
> 
> I assume that one popular use case for seamlessly embedding cross-origin 
> frame content is: A service provider allows his/her customers to embed 
> the pages provided. In this case, the info needed is a list of domains 
> that are allowed to embed the content, rather than an allowseemless 
> yes/no flag.

On Sun, 27 May 2012, Markus Ernst wrote:
> 
> My use case is a content provider, who provides e.g. a Sudoku 
> application or a weather forecast for wind surfers. Paying customers are 
> allowed to embed the content seamlessly in their web sites. The content 
> can also be embedded for free, but not seamlessly.
> 
> The content provider includes some corporate info, such as his/her own 
> logo, and a "provided by XY" notice and link to his/her own page. The 
> paying customers then can apply their own styling, and set the corporate 
> info to "display:none" in the style sheet of the top document, via 
> seamless embedding.

...and Adam Barth posted some on the wiki:

> Dashboard: A dashboard web site wishes to display status indicators that 
> are hosted on a number of different domains. The size of these status 
> indicators varies depending on the status. For example, if a given 
> domain is having difficulty, the status indicator might list the 
> problems the domain is having.

> Expandable Advertisement: A publisher wishes to display an advertisement 
> that expands when the user interacts with the advertisement. Today, the 
> common practice is for the advertising network to run script in the 
> publisher's page that receives postMessage instructions to resize the 
> advertisement's iframe, but this requires that the publisher allow the 
> advertisement to run script in its page, potentially compromising the 
> publisher's security.

So basically, we're just looking for a way to let cross-origin content 
opt-in to being shrink-wrapped and/or styled on a per-origin basis.

On Thu, 12 Apr 2012, Adam Barth wrote:
> 
> [...] something like an attribute on the <html> element might be a 
> better mechanism [...]

That wouldn't work because you need to know before you start parsing, 
because at any time after you start parsing you might have to render, and 
you need to have decided whether to shrink-wrap or not by then. Also, it's 
probably best if we don't make this something you can dynamically change 
while the page is loaded, at least unless there's a compelling use case.

On Thu, 12 Apr 2012, Anne van Kesteren wrote:
> 
> [...] the enormous growing number of one-off flags developers can attach 
> to resources for various features is starting to get worrisome.

Yes, reusing something that exists already seems like a solid win. It's 
not clear anything suitable exists, though.

On Sat, 26 May 2012, Adam Barth wrote:
>
> [CSP]

CSP doesn't seem to include any features that would let you limit who is 
allowed to iframe you, so I don't think CSP as designed today provides a 
solution for the per-origin part. Could it be extended?

> [X-Frame-Options]

This doesn't let you chose on a per-origin basis whether you can be framed 
either (since you don't get an Origin header in the request, and the X-F-O 
header only gives a thumbs-up or thumbs-down in general).

I'm dubious about extending X-F-O since it lacks a spec and so how exactly 
to change it in a backwards-compatible way is unclear and getting it 
wrong would be very dodgy.

On Thu, 12 Apr 2012, Ojan Vafai wrote:
> 
> we could add a special http header and/or meta tag for this, like 
> x-frame-options, but for the child frame to define it's relationship to 
> the parent frame.

Yeah.

It seems to me like the best solution is to have a new HTTP header, with 
the four following values being allowed:

Seamless-Options: allow-shrink-wrap
   Seamless-Options: allow-styling
   Seamless-Options: allow-shrink-wrap allow-styling
   Seamless-Options: allow-styling allow-shrink-wrap

(Split on spaces, ignore unknown tokens.)

Then for the per-origin control, we would extend CSP to have a flag for 
limiting who is allowed to embed you (subsuming X-Frame-Options, essentially).

For the case of things that can be embedded by anyone but only seamlessly 
by paying clients, I would recommend putting the origin in the URL, and 
then limiting the embedding to that URL using CSP.

Is this a viable direction?

(There was also some discussion about how it should maybe be possible to 
do cross-origin DOM access, but that isn't really an option, as was 
discussed in the thread, so I haven't explored it further.)

From oyasumi at gmail.com  Thu Nov  1 03:17:05 2012
From: oyasumi at gmail.com (=?ISO-8859-1?Q?Johan_Sundstr=F6m?=)
Date: Thu, 1 Nov 2012 03:17:05 -0700
Subject: [whatwg] Proposal for window.DocumentType.prototype.toString
In-Reply-To: <Pine.LNX.4.64.1211010227140.5442@ps20323.dreamhostps.com>
References: <CAGFhi3_rQeLW9TDAZMndiXggpARQEtN7zQUqYySjZ6PbP1Fb_Q@mail.gmail.com>
	<gemini.mcpbdc009c2rk01s1.stewart.brodie@antplc.com>
	<CAGFhi3-PZC_=7Btw4qkLvo9v1s+3uEHsaoGrsWyqqxAtOwxKaw@mail.gmail.com>
	<Pine.LNX.4.64.1210312202460.5442@ps20323.dreamhostps.com>
	<5ADDD4F65DBE4310AE292FC787DAF33C@gmail.com>
	<Pine.LNX.4.64.1211010227140.5442@ps20323.dreamhostps.com>
Message-ID: <CAGFhi38iVqXQQFf9v7HaA52DuuTwKWrHjVyZ7Fi0Wcc0muP+Lw@mail.gmail.com>

On Wed, Oct 31, 2012 at 7:33 PM, Ian Hickson <ian at hixie.ch> wrote:

> On Wed, 31 Oct 2012, Johan Sundstr?m wrote:
> > On Wednesday, October 31, 2012 at 15:02 , Ian Hickson wrote:
> > > On Tue, 30 Oct 2012, Johan Sundstr?m wrote:
> > > > That said, I would still much enjoy a future where
> > > > javascript:alert(document.doctype) would tell you something rich
> about
> > > > the page that we today need deep knowledge of document.compatMode
> and/or
> > > > combinations of XMLSerializer and parsers, or deep study of
> DocumentType
> > > > refdocs to tease out.
> > >
> > > Can you elaborate on that?
> >
> > Sure ? rich as in not "[object DocumentType]", but
>
> Well the toString() isn't what matters, it's what you can get from the
> rest of the attributes on the object. Or are you just saying you wish
> .toString() would expose the concatenated string? That would just be a
> conveniece method. Is it worth the compat risk?
>

Yes, this is where our opinions differ. :-) To me, it is the (lack of)
language integration that is the heart of the matter and the source of my
itch ? not that what I attempted to do proved impossible to cobble together
with a (perfectly functional!) solution using other documented DOM APIs
scattered about in other disjunct parts of the browser object model, or
pasting together object properties and programmer provided constant strings
to almost reproduce the value sought. My own hack unintentionally got it
wrong in several ways, for example, and I deem that unnecessary brittleness.

>From my own experience, the only guaranteed safe, reliable and cross
browser method for figuring out an object's class name is
Object.prototype.toString.call(object_of_interest), so I would sacrifice
consistency with DocumentType.prototype.toString behaviours of the past in
an instance for a more useful and intuitive one. If a novice programmer's
expectations on what happens when she uses the object in a string context
is met, I'd call that improvement here.

> ?on apple.com: <!DOCTYPE html>
> >
> > ?on roxen.com: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01
> Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
>
> I don't understand how that is different than document.compatMode,
> really, other than the latter not exposing limited quirks mode. But in
> theory at least, this information is already exposed.
>

It tells me what the doctype is, instead of the name of a bucket the
browser sorts the doctype into for various semantic and standards
compliance (and/or political) reasons.

Both features are excellent, when they are the feature you seek, and they
already bear decent names helping with their findability and learnability.
I am essentially weary of the long knowledge gap and edit distance
between alert(document.doctype) and alert((new
XMLSerializer).serializeToString(document.doctype)) ? that we can straddle
both in this group we already proved; I aspire to help the other 99%.

> ?on the Firefox default homepage: <!DOCTYPE html [
> >   <!ENTITY % htmlDTD
> >     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
> > [...]
>
> This is for XML, right? In HTML the bit in the square brackets would just
> be dropped. It's not clear that it's worth exposing just for XML...
>
> Anyway, this is the DOM Core spec, so I'll let Anne, Aryeh, and Ms2ger
> give you a proper answer. :-)

It probably is, and it's also where the change would be useful; were SVG
and other DOMs exempt from returning a string serialization, it would be a
substantially less useful change.

-- 
 / Johan Sundstr?m, http://ecmanaut.blogspot.com/

From froidure_nicolas at yahoo.fr  Thu Nov  1 09:53:08 2012
From: froidure_nicolas at yahoo.fr (Nicolas Froidure)
Date: Thu, 01 Nov 2012 17:53:08 +0100
Subject: [whatwg] Meta "bugreport" proposal
In-Reply-To: <Pine.LNX.4.64.1210311914180.5442@ps20323.dreamhostps.com>
References: <5090EDA7.9040309@yahoo.fr>
	<5090F5A6.2080901@gmx.de>	<5090F81F.6010303@yahoo.fr>
	<Pine.LNX.4.64.1210311914180.5442@ps20323.dreamhostps.com>
Message-ID: <5092A8F4.6020400@yahoo.fr>

On 31/10/2012 20:33, Ian Hickson wrote:
> On Wed, 31 Oct 2012, Nicolas Froidure wrote:
>    
>> I think we need a specification to allow users to report websites bugs
>> from their browser. That's why i think it could be usefull to add a meta
>> markup like this :
>> <meta name="bugreport" content="(uri)" />
>>
>> The uri could be :
>> - mailto: to send a report by mail (ex: mailto:webmaster at example.org)
>> - http: to send the bug report a a simple HTTP POST request (ex:
>> http://example.org/bugreport).
>> - bug: something more customizable to allow webmasters to fit bug reports with
>> their systems (ex: bug:http?uri=/bug.dat&method=POST&captcha=/captcha.jpg )
>> - etc (ws:, irc: ...)
>>
>> In order to test this i just made a Chrome extension illustrating how browsers
>> could handle this meta markup :
>> https://chrome.google.com/webstore/detail/bugmeback/hgmagcomobmjhaomdoihiggpdekaehmg
>>
>> The code is there : https://github.com/nfroidure/BugMeBack
>>
>> Are you interested in that kind of approach for bug reporting ?
>>      
> This seems interesting. My recommendation would be to continue developing
> the extension, and to try to convince browser vendors and site owners that
> this is a good feature to expose. If there is momentum behind a feature
> such as this, it is much easier to push it into a spec.
>
> See also:
>
>     http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F
>    
I have made a Opera version of the extension today (it's on the repo for 
anyone who want to test). I've got a strong experience on Firefox 
add-ons so it wouldn't take a lot of time to do it for me. As some 
developper told me, it's on Internet Explorer that there's issues most 
of the time but no idea on how to do that for this browser, if anyone 
want to help, feel free.

In order to promote this feature, you have to know that the bug reports 
can be copy/paste into a mail when the <link> is not present. That's why 
i already use the extension to report bugs to webmasters. I suggest 
anyone who think the feature should become a spec to report bugs this way.

On my side, i'll get most feedback i can and then write uses cases. Feel 
free to give me yours.

>
> On Wed, 31 Oct 2012, Julian Reschke wrote:
>    
>> <link>, not<meta>.
>>      
> Indeed

From froidure_nicolas at yahoo.fr  Thu Nov  1 10:39:47 2012
From: froidure_nicolas at yahoo.fr (Nicolas Froidure)
Date: Thu, 01 Nov 2012 18:39:47 +0100
Subject: [whatwg] Meta "bugreport" proposal
In-Reply-To: <50921720.7090107@oupeng.com>
References: <5090EDA7.9040309@yahoo.fr> <50921720.7090107@oupeng.com>
Message-ID: <5092B3E3.5030800@yahoo.fr>

On 01/11/2012 07:30, Kang-Hao (Kenny) Lu wrote:
> I am not sure a new scheme is a good idea. For embedding data in a URL,
> you might consider something like
>
>    data:text/plain,http?uri=/bug.dat&method=POST&captcha=/captcha.jpg
>
> but I am not an expert on this to say whether this is a good idea.
>    
It seems better. I added this to issues on GitHub.
> I am not familiar Chrome extension API and what
> chrome.extension.sendRequest does, but if it does send an email when
> @href is a mailto: URL, you might want to either:
>
> 1. Discuss with whoever creates the entry for rel=webmaster in [1] to
> see if either rel=webmaster can be dropped or rel=bugreport can be
> merged into it.
> 2. Extract mailto: URL from rel=webmaster too and treat it as if it is
> rel=bugreport.
>    
Unfortunately, the mailto protocol doesn't accept more than 1048 
characters. It's not enought to cover console messages and the 
screenshot provided as a dataUri. It could be done by creating an 
internet resource and then providing a link via the mailto protocol, but 
i'm not able to host that content myself.

In the other hand it could be a good way for browser vendors to have 
tracability on bug reports done with their browser in order to know the 
main issues encountered by their users. I know opera currently have 
quality programs to retrieve bugs and contact webmasters manually.

From ojan at chromium.org  Thu Nov  1 10:45:07 2012
From: ojan at chromium.org (Ojan Vafai)
Date: Thu, 1 Nov 2012 10:45:07 -0700
Subject: [whatwg] Should scrollbars move focus?
In-Reply-To: <CAAHOzFCqo=JzH1imbnwP=wdkQz17n5ptOVpnoJ_QkC2SscXS9A@mail.gmail.com>
References: <CAPJYB1gkxsWuvMW0255WNa_0e+Zdpk-hSxAx2GQEYLVUxZz1Fw@mail.gmail.com>
	<Pine.LNX.4.64.1210192242460.2471@ps20323.dreamhostps.com>
	<CANMdWTv1ioRZerVK0zyot-Ge-26N+=L+x+9niXTCxmtzjdmoEw@mail.gmail.com>
	<CAPJYB1hcPjhDjax31aTx0EXR8E8ypLeaMcNf5wyF+7=PfV-7hQ@mail.gmail.com>
	<CANMdWTvuW8-AL5JkF71RH6DiDYhznASirGxZM-Hdsk4vrju8RQ@mail.gmail.com>
	<CAOp6jLZ+JOqMngNVcXTOJf0dZ_hmCU_2b2jQ_-wJ3+gWWT14Cg@mail.gmail.com>
	<CANMdWTuU7Fv0vpMUFHcZHhpY6=Ke2wnnFN7RzvSbbFYCjo7cfQ@mail.gmail.com>
	<CAAHOzFCqo=JzH1imbnwP=wdkQz17n5ptOVpnoJ_QkC2SscXS9A@mail.gmail.com>
Message-ID: <CANMdWTs0nC4mM7vCG0+tMEfYrCqJfsECmWaPJL=RjRVezJDx1g@mail.gmail.com>

On Wed, Oct 31, 2012 at 4:17 PM, Peter Kasting <pkasting at google.com> wrote:

> On Wed, Oct 31, 2012 at 4:08 PM, Ojan Vafai <ojan at chromium.org> wrote:
>
>> On Wed, Oct 31, 2012 at 3:46 PM, Robert O'Callahan <robert at ocallahan.org
>> >wrote:
>> > I think what's happening here in Gecko is that a click on a focusable
>> > element moves focus, and a click on an element's scrollbars counts as a
>> > click on the element. So clicking on the scrollbar of a <textarea> or
>> > contenteditable <div> (or even a <button> containing content with a
>> > scrollbar, if you're mad) moves focus to that element. I think this is
>> > quite reasonable actually.
>> >
>> > Example: http://people.mozilla.org/~roc/scrollbar-focus.html
>>
>> I see. Thanks for the clarification. I don't feel strongly about this.
>> Either direction seems fine. Although, it doesn't violate every native
>> platform's scrollbar convention.
>>
>
> The behavior Robert describes seems theoretically reasonable to me as well.
>