Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jul 29, 2013 at 9:21 PM, Dominic Mazzoni wrote:
> On Mon, Jul 29, 2013 at 7:51 PM, Rik Cabanier wrote:
>
>> Why not the style of the element? If the child element has a class of
>> 'button' and the CSS has
>>
>> button:focus {
>>
>> color:red;
>>
>> }
>>
>> Shouldn't the focus be in red?
>>
>
> While I also think there should probably be some way to override at least
> the color of the focus ring in order to match the rest of the UI, I also
> think that at this stage it might make more sense to just get this out in
> front of developers (behind a flag) and see what happens with some
> real-world apps.
>
That sounds like good plan. Keep us posted on your findings!
>
> I know at least 3 developers who are interested in trying it out with
> their apps.
>
> - Dominic
>
>
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jul 29, 2013 at 7:51 PM, Rik Cabanier wrote:
> Why not the style of the element? If the child element has a class of
> 'button' and the CSS has
>
> button:focus {
>
> color:red;
>
> }
>
> Shouldn't the focus be in red?
>
While I also think there should probably be some way to override at least
the color of the focus ring in order to match the rest of the UI, I also
think that at this stage it might make more sense to just get this out in
front of developers (behind a flag) and see what happens with some
real-world apps.
I know at least 3 developers who are interested in trying it out with their
apps.
- Dominic
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jul 29, 2013 at 5:26 PM, Ian Hickson wrote:
> On Mon, 29 Jul 2013, Rik Cabanier wrote:
> >
> > Does that mean it should be stroked along the path?
>
> That depends on the platform. Some platforms render the focus as a
> highlight, some as a dotted line around the exact path of the control,
> some as a box around the bounding box of the focused control, etc.
>
> The idea of this API is to let the user agent render the focus ring
> however it is appropriate for the platform.
>
I see. So the user agent can decided if it closes the path, use end caps,
round joins, etc.
Maybe the spec should be more specific and say that nothing in the graphics
state (except clipping) should affect the focus ring.
>
>
> > How is the focus ring usually calculated? Does the UA know about the
> > shape of the focused objects and then draws a box around it?
>
> It depends on the platform.
>
>
> > As for the color of the focus ring, shouldn't it come from the ':focus'
> > style of the element that is passed in?
>
> It should come from the platform.
Why not the style of the element? If the child element has a class of
'button' and the CSS has
button:focus {
color:red;
}
Shouldn't the focus be in red?
> See also this recent discussion:
>
>
> http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0345.html
Yes, we're still in that thread :-)
Re: [whatwg] Forms-related feedback
On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: > On Tue, Jul 30, 2013 at 10:43 AM, Ian Hickson wrote: > > On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: > >> > >> I actually think we need to distinguish between local and floating > >> time zones. > >> > >> When using datetime-local, I would actually expect that the browser > >> picks the local timezone as the default time zone, so doesn't expose > >> a timezone entry in the UI. The value that is returned by the form, > >> however, actually has a timezone. > > > > That's type=datetime (the time zone is always UTC). > > Hmm.. .what does a JS dev use, then, when they want to require a user to > have to pick a timezone other than UTC? There's no control in HTML today that exposes a time zone interface, whether it's UTC or anything else. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Tue, Jul 30, 2013 at 10:43 AM, Ian Hickson wrote: > On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: >> >> I actually think we need to distinguish between local and floating time >> zones. >> >> When using datetime-local, I would actually expect that the browser >> picks the local timezone as the default time zone, so doesn't expose a >> timezone entry in the UI. The value that is returned by the form, >> however, actually has a timezone. > > That's type=datetime (the time zone is always UTC). Hmm.. .what does a JS dev use, then, when they want to require a user to have to pick a timezone other than UTC? Silvia.
Re: [whatwg] Session history and discarding of Documents
On Mon, 29 Jul 2013, Andrew Oakley wrote: > > As far as I can tell when the user agent discards a Document in the > session history may change the contents of the history. This seems > wrong to me because it makes non-deterministic visible to scripting. > > The scenario that I'm thinking of is: > "index" has a frame that is navigated to: > "container" which has a frame that is navigated to: > "page1" (default using src=page1) > "page2" > > The "joint session history" now contains (elements in parenthesis are > removed because they are "current entries in their respective session > histories"): > (index) (container) page1 page2 > > If "container" is now navigated to "empty" we get this: > (index) container empty > > Now if we go back() and the Document for "container" has not been > discarded and therefore the nested browsing context exists we get page2 > visible in the frame and this joint session history: > (index) (container) page1 page2 empty > > If the Document for "container" had been discarded then the nested > browsing context and it's session history is discarded. This means that > page1 is visible in the frame and we get this joint session history: > (index) (container) page1 empty > > Apologies if the above description is confusing, it's rather difficult > to describe. > > I have not managed to find a way to get desktop browsers to actually > discard the Document for "container", I'm guessing there is some sort of > heuristic based on memory available. In a memory-constrained > environment a browser may wish to destroy the Document's fairly quickly > and I expect to see the second behaviour. > > Have I missed something or misunderstood the spec here? As far as I can > tell there is actually no requirement to maintain session history for > any nested browsing context that belongs to a document which is not > active but the major browser do. I believe your description is correct. There's not much we can do about it. We can't require that UAs remember everything, since on some devices (e.g. mobile phones) even the browser itself might get discarded if the user even so much as glances away. We can't require that the UAs forget everything as soon as possible, because remembering things is viewed as a massive performance benefit by some browser vendors, and they won't stop doing it, since they believe it brings them a competitive advantage. (I'm not making judgements on whether they're right or wrong; vendors disagree on this, which is why I'm couching my response in these terms.) Thus the current unfortunate situation. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Tue, 30 Jul 2013, Silvia Pfeiffer wrote: > > I actually think we need to distinguish between local and floating time > zones. > > When using datetime-local, I would actually expect that the browser > picks the local timezone as the default time zone, so doesn't expose a > timezone entry in the UI. The value that is returned by the form, > however, actually has a timezone. That's type=datetime (the time zone is always UTC). > In contrast, when the app doesn't want a timezone, the developer should > probably use something like datetime-floating. Then, it's clear that the > time zone is actually left off of the returned value, too. That's type=datetime-local. It's not only useful for floating times, as noted in the response on this bug, which is why it's not called something with "floating" in the name: https://www.w3.org/Bugs/Public/show_bug.cgi?id=17856 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Mon, 29 Jul 2013, Jonas Sicking wrote: > > Ian, has *any* implementer expressed a preference for implementing a > picker which allows selecting date+time+timezone? I.e. one that returns > UTC dates? Your "i.e." is a non-sequitur. A control that has date+time+timezone in the UI and a control that always returns UTC dates are orthogonal descriptions. type=datetime is not a control that allows selecting date+time+timezone. Regarding whether implementors have expressed interest in implementing specific controls: the controls currently in the spec were based on use cases, not on what specific implementors had indicated in terms of implementation interest. Once you can implement type=datetime-local, pretty much all the other date-related controls are trivial to implement usefully. > I have seen plenty of date and time pickers. But never one that also > allowed the user to set the timezone as part of the same widget. I have seen some, but that's academic, since none of the input controls in the HTML spec today are such a control. > I.e. claiming that there is *far* more widgets elsewhere which separates > picking date/times from ones that are picking date/time/timezones. Are > you really claiming that this is not the case? This seems like a claim > that needs to be backed up in some form. As noted in my previous e-mail, I'm not making any claims as to the relative proportions of the various controls. The design in the spec isn't about that, it's about reducing authoring mistakes by exposing authors to bugs quicker. > Additionally, if we were to build a date+time+timezone picker, the > current API to such a picker is insufficient since a date/time expressed > in UTC is insufficient to express a date+time+timezone. Agreed. I don't think anyone is suggesting building such a picker at this time. I could definitely see a need for it -- or more likely, for specifically a time-zone picker -- but it's a much harder problem than the existing controls, as noted in my previous e-mail on this thread. > If we want to return UTC dates, I instead propose that we make the > element take a timezone as an input (through an attribute or some such). > The picker would then select just date+time but return a result using > UTC timezone. I don't understand the use case for such a control. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Tue, Jul 30, 2013 at 9:59 AM, Tab Atkins Jr. wrote: > On Mon, Jul 29, 2013 at 4:50 PM, Jonas Sicking wrote: >> Ian, has *any* implementer expressed a preference for implementing a >> picker which allows selecting date+time+timezone? I.e. one that >> returns UTC dates? > > The Gmail time-picker (when you indicate that you want to set > timezones), gives you three things next to each other, for date, time, > and timezone. > > These are all right next to each other - whether they're separate or > combined widgets isn't observable unless you check out the code. The iCal one allows for selecting a specific time zone and a "floating" one (which is what is currently called "local"): http://www.macobserver.com/tmo/article/Understanding_iCal_Time_Zones I actually think we need to distinguish between local and floating time zones. When using datetime-local, I would actually expect that the browser picks the local timezone as the default time zone, so doesn't expose a timezone entry in the UI. The value that is returned by the form, however, actually has a timezone. In contrast, when the app doesn't want a timezone, the developer should probably use something like datetime-floating. Then, it's clear that the time zone is actually left off of the returned value, too. Silvia.
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 29 Jul 2013, Rik Cabanier wrote: > > Does that mean it should be stroked along the path? That depends on the platform. Some platforms render the focus as a highlight, some as a dotted line around the exact path of the control, some as a box around the bounding box of the focused control, etc. The idea of this API is to let the user agent render the focus ring however it is appropriate for the platform. > How is the focus ring usually calculated? Does the UA know about the > shape of the focused objects and then draws a box around it? It depends on the platform. > As for the color of the focus ring, shouldn't it come from the ':focus' > style of the element that is passed in? It should come from the platform. See also this recent discussion: http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Jul/0345.html -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Forms-related feedback
On Mon, Jul 29, 2013 at 4:50 PM, Jonas Sicking wrote: > Ian, has *any* implementer expressed a preference for implementing a > picker which allows selecting date+time+timezone? I.e. one that > returns UTC dates? The Gmail time-picker (when you indicate that you want to set timezones), gives you three things next to each other, for date, time, and timezone. These are all right next to each other - whether they're separate or combined widgets isn't observable unless you check out the code. ~TJ
Re: [whatwg] Forms-related feedback
Ian, has *any* implementer expressed a preference for implementing a
picker which allows selecting date+time+timezone? I.e. one that
returns UTC dates?
And can you point any other platforms that has such a UI widget.
I have seen plenty of date and time pickers. But never one that also
allowed the user to set the timezone as part of the same widget.
I.e. claiming that there is *far* more widgets elsewhere which
separates picking date/times from ones that are picking
date/time/timezones. Are you really claiming that this is not the
case? This seems like a claim that needs to be backed up in some form.
Additionally, if we were to build a date+time+timezone picker, the
current API to such a picker is insufficient since a date/time
expressed in UTC is insufficient to express a date+time+timezone.
If we want to return UTC dates, I instead propose that we make the
element take a timezone as an input (through an attribute or some
such). The picker would then select just date+time but return a result
using UTC timezone.
/ Jonas
On Mon, Jul 29, 2013 at 4:21 PM, Ian Hickson wrote:
> On Mon, 14 Jan 2013, Jonas Sicking wrote:
>> On Jan 8, 2013 1:47 AM, "Ian Hickson" wrote:
>> > On Tue, 27 Nov 2012, Mikko Rantalainen wrote:
>> > > 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).
>> >
>> > We could rename "datetime" to "datetime-absolute" and leave
>> > "datetime-local" as named, but I'm not really convinced that's much
>> > better than what we have now.
>>
>> I think it more common for people to interact mainly with people in
>> their own timezone. I.e. most time when talking about dates and times
>> people don't mention what timezone is involved and rely on context to
>> provide that information.
>
> I agree that that is accurate for when people talk. But that's somewhat
> misleading, I think, regarding what it implies about form controls.
>
> In Web apps, there's basically three cases:
>
> 1. Cases where you mean a specific global time (a time relative to UTC),
>for coordination amongst people from many locations.
>
> For example: the time that a broadcast begins
> e.g. a live Hangout on G+
> the time that a deliverable is due
> e.g. the due date for a poetry contest
> the time that a resource becomes available and the time
> it stops being available, if scheduled in advance
> e.g. the time that a meeting phone bridge code starts
> working and the time it ends working
>
> 2. Cases where you mean a specific global time (a time relative to UTC),
>but where the time is really only relevant for local purposes, and so
>when given is likely to be given relative to an implied time zone.
>
> For example: the time that a plane takes off or lands
> the time that a physical meeting (not one involving
> video conferencing across multiple sites) begins
> the time that someone wants to go home from work
>
> 3. Cases where you mean a floating time and no time zone actually applies.
>
> For example: a wake-up alarm on a phone ("wake me up at 8am on
> Monday", where the time zone isn't decided until
> Monday, by examining where the user is)
> the time for an event celebrated at different times in
> different time zones, e.g. New Year's.
>
> Now, when implementing these, there's often mistakes made. For example,
> authors will often confuse case 1 for case 2, and will often confuse case
> 2 for case 3. That is, they will often assume a time zone when one should
> not be assumed, and will often forget about time zones entirely when a
> time zone should be assumed.
>
> For example, they may ask for the time that a broadcast begins, and then
> just assume that the time zone is the time zone of the server. This would
> work fine in a single-time-zone-company where the server is colocated with
> the users. Similarly, they might ask for the time of a plane's departure,
> and then display it in the user's time zone, forgetting that there's an
> implied time zone given by the user's location.
>
> The opposite error is harder to make. It's harder to ignore the time zone
> when all times that the user enters get converted to UTC -- unless you're
> in the UK during the wint
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, Jul 29, 2013 at 2:48 PM, Ian Hickson wrote: > On Mon, 29 Jul 2013, Rik Cabanier wrote: > > > > > > The idea is it's supposed to be the system style (hence the name of > > > the method, draw _system_ focus ring), and that if the authors wants a > > > special style, they use drawCustomFocusRing() and if it returns true > > > they draw it themselves (using strokeStyle and stroke(), or whatever). > > > > > > There's an example in the spec -- search for "couple of checkboxes". > > > > That example doesn't show how the focus rings are supposed to render. > > The spec says: > > > > ... draws a focus ring *around *the current default path or the given > path > > ... > > Note that that text is non-normative. There's a big box to that effect > just above the text itself. > > > > and: > > > > ... draw a focus ring of the appropriate style along the intended path... > > That one is normative. > > > > Which way should it be drawn? > > The way the normative one says it is to be drawn. > Does that mean it should be stroked along the path? > > It seems that the focus ring should be around the path and drawn in > > accordance to the browser's algorithm of focus regions. > > Not really should what you're asking. Can you elaborate? > > How is the focus ring usually calculated? Does the UA know about the shape of the focused objects and then draws a box around it? As for the color of the focus ring, shouldn't it come from the ':focus' style of the element that is passed in?
Re: [whatwg] Forms-related feedback
On Mon, 14 Jan 2013, Jonas Sicking wrote:
> On Jan 8, 2013 1:47 AM, "Ian Hickson" wrote:
> > On Tue, 27 Nov 2012, Mikko Rantalainen wrote:
> > > 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).
> >
> > We could rename "datetime" to "datetime-absolute" and leave
> > "datetime-local" as named, but I'm not really convinced that's much
> > better than what we have now.
>
> I think it more common for people to interact mainly with people in
> their own timezone. I.e. most time when talking about dates and times
> people don't mention what timezone is involved and rely on context to
> provide that information.
I agree that that is accurate for when people talk. But that's somewhat
misleading, I think, regarding what it implies about form controls.
In Web apps, there's basically three cases:
1. Cases where you mean a specific global time (a time relative to UTC),
for coordination amongst people from many locations.
For example: the time that a broadcast begins
e.g. a live Hangout on G+
the time that a deliverable is due
e.g. the due date for a poetry contest
the time that a resource becomes available and the time
it stops being available, if scheduled in advance
e.g. the time that a meeting phone bridge code starts
working and the time it ends working
2. Cases where you mean a specific global time (a time relative to UTC),
but where the time is really only relevant for local purposes, and so
when given is likely to be given relative to an implied time zone.
For example: the time that a plane takes off or lands
the time that a physical meeting (not one involving
video conferencing across multiple sites) begins
the time that someone wants to go home from work
3. Cases where you mean a floating time and no time zone actually applies.
For example: a wake-up alarm on a phone ("wake me up at 8am on
Monday", where the time zone isn't decided until
Monday, by examining where the user is)
the time for an event celebrated at different times in
different time zones, e.g. New Year's.
Now, when implementing these, there's often mistakes made. For example,
authors will often confuse case 1 for case 2, and will often confuse case
2 for case 3. That is, they will often assume a time zone when one should
not be assumed, and will often forget about time zones entirely when a
time zone should be assumed.
For example, they may ask for the time that a broadcast begins, and then
just assume that the time zone is the time zone of the server. This would
work fine in a single-time-zone-company where the server is colocated with
the users. Similarly, they might ask for the time of a plane's departure,
and then display it in the user's time zone, forgetting that there's an
implied time zone given by the user's location.
The opposite error is harder to make. It's harder to ignore the time zone
when all times that the user enters get converted to UTC -- unless you're
in the UK during the winter, or one of a handful of other countries using
UTC, you're likely to notice right away (and even in those, in many cases
you'll likely notice within 6 months).
Because of this likelihood for mistakes, the controls are designed so that
forgetting a time zone requires more characters than giving one. Authors
are less likely to initially use datetime-local than datetime, so they're
more likely to be reminded to use time zones immediately, than they are to
forget to use time zones until too late.
> So in most contexts when people think about a point in time, they do so
> for a specific timezone.
I don't know how to evaluate if this is true.
> When that is not the case, this is something that people are aware of.
> When I interact with friends/family/coworkers where the timezone is not
> obvious this is quite clear. And in these cases I'm aware that I need to
> specify timezone.
I don't know that that's the case. I think it's more likely that authors
will incorrectly forget to use time zones when they should have, than it
is for them to use time zones when they should not. That, as described
above, is the principle on which the spec's design was
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Mon, 29 Jul 2013, Rik Cabanier wrote: > > > > The idea is it's supposed to be the system style (hence the name of > > the method, draw _system_ focus ring), and that if the authors wants a > > special style, they use drawCustomFocusRing() and if it returns true > > they draw it themselves (using strokeStyle and stroke(), or whatever). > > > > There's an example in the spec -- search for "couple of checkboxes". > > That example doesn't show how the focus rings are supposed to render. > The spec says: > > ... draws a focus ring *around *the current default path or the given path > ... Note that that text is non-normative. There's a big box to that effect just above the text itself. > and: > > ... draw a focus ring of the appropriate style along the intended path... That one is normative. > Which way should it be drawn? The way the normative one says it is to be drawn. > It seems that the focus ring should be around the path and drawn in > accordance to the browser's algorithm of focus regions. Not really should what you're asking. Can you elaborate? -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Outline style to use for drawSystemFocusRing
On Wed, Jul 24, 2013 at 4:14 PM, Ian Hickson wrote: > On Wed, 24 Jul 2013, Dominic Mazzoni wrote: > > > > I'm looking into implementing > > drawSystemFocusRing< > http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-drawsystemfocusring > >in > > Blink, but it's unclear what style to use when drawing the focus ring > > - > > i.e. the color, thickness, etc., assuming that the user hasn't overridden > > it for accessibility. Here are some possible interpretations: > > > > 1. Hard-code default values. I don't think this would be ideal, since it > > wouldn't necessarily match the focus color of other elements that get the > > focus color from the system. > > 2. Get them from the default style of a generic element (which may match > > the system focus style). This could work, but I think this is less > flexible > > for developers - if they picked a custom outline color for every other > > element in their site but would have no way to override it for canvas > > (other than using drawCustomFocusRing). > > 3. Get them from the outline style of the canvas element. This means > every > > focus ring within the canvas would be the same, but otherwise I have no > > objection. > > 4. Get them from the outline style ofelement passed to > drawSystemFocusRing. > > This is my preference. > > The idea is it's supposed to be the system style (hence the name of the > method, draw _system_ focus ring), and that if the authors wants a special > style, they use drawCustomFocusRing() and if it returns true they draw it > themselves (using strokeStyle and stroke(), or whatever). > > There's an example in the spec -- search for "couple of checkboxes". > That example doesn't show how the focus rings are supposed to render. The spec says: ... draws a focus ring *around *the current default path or the given path ... and: ... draw a focus ring of the appropriate style along the intended path... Which way should it be drawn? It seems that the focus ring should be around the path and drawn in accordance to the browser's algorithm of focus regions.
Re: [whatwg] Proposal:Improve internationalization in the autocomplete attribute
On Thu, 27 Jun 2013, Lara Rennie wrote: > > Re the CEDEX: it is a postal-code like thing, but it can't go in the > postal-code field, or formatting would be bizarre; as pointed out, it > should go after the locality field. However, if it was entered in the > locality field, certain systems may complain about validation, anyone > interested in aggregating data will start to get a lot of duplicate > localities etc. > > It's also not just France - many ex-French colonies use this too. > > The Google Address Widget does actually accept CEDEX as a separate > field; but you won't see this in most use-cases, because often the > widget is used to collect a physical address (and then they disallow > it), or it's used to give an address to a credit-card company (who are > US based, and don't understand it or want things they don't > understand...) > > Re the physical vs. mailing: This is not for postal addresses, but more > in the case of "I want to go somewhere in real life" -> in this case, we > don't want the military "states" to be allowed, or PO Box 123 addresses. > I would assume that the user, when setting up their addresses, would > indicate whether they do or do not represent a physical location > (assuming that a user can set up multiple addresses - it sounds like > they can, based on the shipping vs. billing things) Fundamentally, I think we're going to have trouble if we try to use different fields in different places, and in particular if we use fields for specific localities. (That is, after all, why the "given-name" and "family-name" fields are bad.) Since we're not going to convince people to offer fields that are useless in most cases, we can't really add a boolean field just for France and its old colonies. Hence the convention to append CEDEX to the locality field. I think this is detectable enough that anyone doing data aggregation is going to have far fewer problems just filtering out the word "CEDEX" than they are dealing with any of the other data integrity issues (like the way people often use real towns instead of post towns in the UK, even when giving postal addresses). On Tue, 2 Jul 2013, Albert Bodenhamer wrote: > > > > Re the physical vs. mailing: This is not for postal addresses, but > > more in the case of "I want to go somewhere in real life" -> in this > > case, we don't want the military "states" to be allowed, or PO Box 123 > > addresses. I would assume that the user, when setting up their > > addresses, would indicate whether they do or do not represent a > > physical location (assuming that a user can set up multiple addresses > > - it sounds like they can, based on the shipping vs. billing things) > > This sounds like something a browser could do if they wanted, but that > doesn't need to be part of the spec. Agreed. On Thu, 4 Jul 2013, Lara Rennie wrote: > > > > Thanks Lara. So if browsers ask for CEDEX as a separate optional > > field and then append it to "locality" when filling would that be > > acceptable? I think that's where the spec is right now. > > I don't know if the merchants would expect this? Especially if they did > want a separate field? What if they are using the (open-sourced) Google > Address Widget? If they want a separate field, they can trivially just extract out the CEDEX bit by looking for the word CEDEX in the locality, and stripping it out if it's present. I would expect most implementations not to bother (since there doesn't seem to be any reason to -- just pretend the locality has "CEDEX" in the name, and it all works, no?). > >> Re the physical vs. mailing: This is not for postal addresses, but > >> more in the case of "I want to go somewhere in real life" -> in this > >> case, we don't want the military "states" to be allowed, or PO Box > >> 123 addresses. I would assume that the user, when setting up their > >> addresses, would indicate whether they do or do not represent a > >> physical location (assuming that a user can set up multiple addresses > >> - it sounds like they can, based on the shipping vs. billing things) > > > > This sounds like something a browser could do if they wanted, but that > > doesn't need to be part of the spec. > > I guess I was just meaning; if a site can use the spec to say "please > autocomplete with a shipping address for this user" then they could also > use it to say "please autocomplete with a physical location for this > user". But just an idea. Just because you might have two localities: one > which is your post-town, and one which is your actual physical location. > But "shipping" might cover this sufficiently. What's the use case? Right now we have "shipping" and "billing" as possible grouping keywords; we can certainly add more if there are compelling use cases. I don't think I've ever seen a form that asks for a shipping address and a physical address, though. Or billing and physical that isn't shipping. On Mon, 8 Jul 2013, Albert B
[whatwg] Session history and discarding of Documents
As far as I can tell when the user agent discards a Document in the session history may change the contents of the history. This seems wrong to me because it makes non-deterministic visible to scripting. The scenario that I'm thinking of is: "index" has a frame that is navigated to: "container" which has a frame that is navigated to: "page1" (default using src=page1) "page2" The "joint session history" now contains (elements in parenthesis are removed because they are "current entries in their respective session histories"): (index) (container) page1 page2 If "container" is now navigated to "empty" we get this: (index) container empty Now if we go back() and the Document for "container" has not been discarded and therefore the nested browsing context exists we get page2 visible in the frame and this joint session history: (index) (container) page1 page2 empty If the Document for "container" had been discarded then the nested browsing context and it's session history is discarded. This means that page1 is visible in the frame and we get this joint session history: (index) (container) page1 empty Apologies if the above description is confusing, it's rather difficult to describe. I have not managed to find a way to get desktop browsers to actually discard the Document for "container", I'm guessing there is some sort of heuristic based on memory available. In a memory-constrained environment a browser may wish to destroy the Document's fairly quickly and I expect to see the second behaviour. Have I missed something or misunderstood the spec here? As far as I can tell there is actually no requirement to maintain session history for any nested browsing context that belongs to a document which is not active but the major browser do. Thanks -- Andrew Oakley -- Andrew Oakley
