[whatwg] hit regions: event bubbling
Reading the hit region spec [1] on event handling, I was wondering how
event bubbling is supposed to be handled.
Let's say you have the following markup:
and the following code:
var ctx = document.getElementById("cnv").getContext("2d");
var a = document.getElementById("a");
a.addEventListener("click", function(){...});
var b = document.getElementById("b");
// draw region for a
ctx.addHitRegion({control: a, id: "a"});
// draw region for b
ctx.addHitRegion({control: b, parentID: "a"});
Now, if there's a mouse click for control b, should the event be handled by
the handler for control a?
Also, should event from the fallback content bubble out of the canvas
element or should it act as a barrier?
1:
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#hit-regions
Re: [whatwg] Supporting more address levels in autocomplete
On Fri, Feb 28, 2014 at 5:47 PM, Ian Hickson wrote: > On Mon, 24 Feb 2014, Jukka K. Korpela wrote: > > 2014-02-22 3:03, Ian Hickson wrote: > > > > > > (Note that a lot of people in the UK have no idea how to write their > > > address according to current standards. For example, people often > > > include the county, give the "real" town rather than the "post town", > > > put things out of order, indent each line of the address, etc.) > > > > The phenomenon is probably not limited to the UK. Few people even know > > the current standards (national and international). > > Well sure, but since we're writing a standard, if our assumption is that > people don't know standards, we're not going to reach a useful conclusion. > > > > Some fine-grained control for naming different components of an address > > are undoubtedly useful at times. It would be even more useful to have a > > common, "standard" name for just an address. That is, whatever someone > > wants the sender to put in an envelope. Its internal structure does not > > matter, as long as it works, and as usual, it is up to the recipient to > > specify the address in a manner that works. > > > > Forms that require the user to split his address to small pieces may > > have their reasons. But if you just want to have an address to send > > stuff to, then all you need is a working postal address. A textarea > > with, say, name="postal", if used on different pages, would then let the > > user enter his entire address very simply, after just once typing it. > > > > Probably "postal" should be specified so that it relates to a postal > > address that is complete for delivery except the recipient name. The > > reason is that the name is so often asked separately > > On Mon, 24 Feb 2014, Evan Stade wrote: > > > > I agree with this, and plan to propose it separately from the proposal > > currently under discussion. It might be hard to parse a working address > > out of a free-form input, but the other direction is doable enough: > > creating a block of text suitable to printing on an envelope given > > tokenized values. This tackles the problem of how to format an > > autocompleted address for a particular country and UI language (i.e. in > > the user agent has to know how to do it, but the website doesn't). > > We can definitely add something like this. We already have a simpler > version of this for street addresses. > > > On Mon, 24 Feb 2014, Charles McCathie Nevile wrote: > > > > That depends on whether you want to force your customers to think like > > the Post Office, or whether you prefer to be responsive to your > > customers. Speaking without data, I suspect that nervousness at not > > being able to put *what someone thinks* is their address translates > > fairly readily into a certain amount of failure to proceed with a > > transaction. > > I'd love to see real data on this. I can imagine scenarios that would lead > this to go both ways. > > > On Mon, 24 Feb 2014, Dan Brickley wrote: > >> > > Who is using the data? Just post offices? Or taxi drivers, pizza > > delivery bikers, pedestrians? > > The latter three are unlikely to really need much more depth at the > locality level. > > > On Mon, 24 Feb 2014, Evan Stade wrote: > > > > Regarding UK addresses, libaddressinput[1], which is used by Google for > > various products, currently accepts two levels of administrative region > > for GB: city and optional county. > > You need two levels, but those aren't it. :-) Counties haven't officially > been used in UK addresses since the mid 90s. > > > > > This would be the first open-ended field name. Do we really want to > > > make this open-ended? What happens if a form has n=1..3, and another > > > has n=2..4? What if one has n=1, n=2, and n=4, but not n=3? > > > > I don't know why a web author would do this > > Web authors do all kinds of crazy stuff. We have to be ready for it such > that we never end up forced to introduce weird heuristics. > > > > but n=m doesn't require n=m-1 or n=m+1 to be present. n=2..4 would just > > mean the site didn't get the n=1 value. > > My concern is that authors do something like this: > > > > > > ...and then the user enters their address: > >1600 Amphitheatre Parkway >Mountain View >CA > > ...and then the user goes to another site: > > > > > > > > ...and the browser autofills: > >1600 Amphitheatre Parkway >(empty) >Mountain View >Mountain View >CA > > ...or some such. > So the user is tricked into entering wrong data? (i.e. CA for address-level-3 instead of address-level-1) A web author could just as easily cause the user to enter wrong data to be stored by doing: > > > > > How does a site know how many levels to offer? > > > > It offers as many as it knows what to do with. It probably wouldn't know > > what to do with n=5, or n=100, and it's highly unlikely a user agent > > would return a value for those levels anyway, so practically speaking, > > n=1 to
Re: [whatwg] Supporting more address levels in autocomplete
On Mon, 24 Feb 2014, Jukka K. Korpela wrote: > 2014-02-22 3:03, Ian Hickson wrote: > > > > (Note that a lot of people in the UK have no idea how to write their > > address according to current standards. For example, people often > > include the county, give the "real" town rather than the "post town", > > put things out of order, indent each line of the address, etc.) > > The phenomenon is probably not limited to the UK. Few people even know > the current standards (national and international). Well sure, but since we're writing a standard, if our assumption is that people don't know standards, we're not going to reach a useful conclusion. > Some fine-grained control for naming different components of an address > are undoubtedly useful at times. It would be even more useful to have a > common, "standard" name for just an address. That is, whatever someone > wants the sender to put in an envelope. Its internal structure does not > matter, as long as it works, and as usual, it is up to the recipient to > specify the address in a manner that works. > > Forms that require the user to split his address to small pieces may > have their reasons. But if you just want to have an address to send > stuff to, then all you need is a working postal address. A textarea > with, say, name="postal", if used on different pages, would then let the > user enter his entire address very simply, after just once typing it. > > Probably "postal" should be specified so that it relates to a postal > address that is complete for delivery except the recipient name. The > reason is that the name is so often asked separately On Mon, 24 Feb 2014, Evan Stade wrote: > > I agree with this, and plan to propose it separately from the proposal > currently under discussion. It might be hard to parse a working address > out of a free-form input, but the other direction is doable enough: > creating a block of text suitable to printing on an envelope given > tokenized values. This tackles the problem of how to format an > autocompleted address for a particular country and UI language (i.e. in > the user agent has to know how to do it, but the website doesn't). We can definitely add something like this. We already have a simpler version of this for street addresses. On Mon, 24 Feb 2014, Charles McCathie Nevile wrote: > > That depends on whether you want to force your customers to think like > the Post Office, or whether you prefer to be responsive to your > customers. Speaking without data, I suspect that nervousness at not > being able to put *what someone thinks* is their address translates > fairly readily into a certain amount of failure to proceed with a > transaction. I'd love to see real data on this. I can imagine scenarios that would lead this to go both ways. On Mon, 24 Feb 2014, Dan Brickley wrote: >> > Who is using the data? Just post offices? Or taxi drivers, pizza > delivery bikers, pedestrians? The latter three are unlikely to really need much more depth at the locality level. On Mon, 24 Feb 2014, Evan Stade wrote: > > Regarding UK addresses, libaddressinput[1], which is used by Google for > various products, currently accepts two levels of administrative region > for GB: city and optional county. You need two levels, but those aren't it. :-) Counties haven't officially been used in UK addresses since the mid 90s. > > This would be the first open-ended field name. Do we really want to > > make this open-ended? What happens if a form has n=1..3, and another > > has n=2..4? What if one has n=1, n=2, and n=4, but not n=3? > > I don't know why a web author would do this Web authors do all kinds of crazy stuff. We have to be ready for it such that we never end up forced to introduce weird heuristics. > but n=m doesn't require n=m-1 or n=m+1 to be present. n=2..4 would just > mean the site didn't get the n=1 value. My concern is that authors do something like this: ...and then the user enters their address: 1600 Amphitheatre Parkway Mountain View CA ...and then the user goes to another site: ...and the browser autofills: 1600 Amphitheatre Parkway (empty) Mountain View Mountain View CA ...or some such. > > How does a site know how many levels to offer? > > It offers as many as it knows what to do with. It probably wouldn't know > what to do with n=5, or n=100, and it's highly unlikely a user agent > would return a value for those levels anyway, so practically speaking, > n=1 to n=3 should be sufficient for now (although n=4 seems possible in > the near future). But I don't see the purpose in setting a limit in the > spec. This makes me extremely uncomfortable. We're saying, "we don't know how to do this, I hope you do". Why would we be less able to answer this than Web authors? It's not like Web authors are experts in postal addresses. I think we should pick the number that is actually needed, and be
[whatwg] Size of non-rendered viewports
On Tue, 7 Jan 2014, Boris Zbarsky wrote:
> On 1/7/14 2:24 PM, Ian Hickson wrote:
> > It's probably just a matter of saying, in the rendering section, that
> > nested browsing contexts that aren't _being_rendered_ (or that are
> > s outside s) get a 0x0 viewport.
>
> That doesn't seem unreasonable.
Done.
> > (Viewports that are being rendered seem to have an unambiguous
> > dimension
>
> Actually, nothing defines this either. It should be the content box of
> the , assuming iframes can't get fragmented. If they can be
> fragmented, I have no idea.
Fixed (well, not the fragmented case).
http://html5.org/tools/web-apps-tracker?from=8517&to=8518
> How about this testcase:
>
>
>
> div { color: purple; }
>
>media="(min-width: 300px)">
>media="(max-width: 300px)">
>
>
>
> window.onload = function() {
> alert(getComputedStyle(document.getElementById("one"), "").color +
> " | " +
> getComputedStyle(document.getElementById("two"), "").color);
> }
>
>
> and variants on it. From my testing, in a display:none iframe:
>
> 1) Presto-based Opera treats the viewport width as 300px for purposes of the
> media queries and reports a document.body.offsetWidth of 0.
>
> 2) Blink and WebKit both seems to treat the viewport width as 0 when measured
> using either method.
>
> 3) Gecko doesn't allow creation of computed style objects in an iframe that's
> not being rendered and reports a document.body.offsetWidth of 0.
>
> 4) IE11 seems to do what Blink/WebKit do.
Making the viewport 0x0 makes Blink, WebKit, Gecko, and IE11 consistent
here, right? Whether or not computed style objects are created is
something I'll leave up to the CSSOM spec.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] iframe scrolling attribute
On Thu, 9 Jan 2014, Mats Palmgren wrote: > > The current spec[1] for the scrolling attribute of [i]frame elements > does not reflect what is implemented by a majority of UAs. We intend to > change Firefox to implement the behavior of IE/Chrome/Safari and would > like to see the spec changed to describe that behavior. > > There are two major problems with the current spec: > 1. mapping scrolling=yes (and synonyms) to overflow:scroll > 2. the mapped overflow value being a presentational hint > > Only Firefox implements 1 (we intend to change that[2]). None of the > four UAs mentioned implements 2. > > The spec should instead say that scrolling=no (and synonyms) suppress > scrollbars for the [i]frame viewport, and that any other value have no > effect. I think what the spec used to have makes a lot more sense, but if there's a compat need, fair enough. http://html5.org/r/8517 Note that Chrome/Safari don't seem to support "off" and "noscroll", only "no". I didn't test IE. The spec supports all three, still (as does FF). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
