Re: [whatwg] Should generate click events?

[Rick Waldron]

On Wednesday, August 21, 2013, Tab Atkins Jr. wrote:

> On Wed, Aug 21, 2013 at 7:43 AM, Rick Waldron 
> wrote:
> > Ideally the event.target is defined more specifically, eg. if event
> objects
> > from clicks (and others) on controls had an event.target that was the
> > actual controls element.
>
> What "actual controls element"?  There is no such thing.


I guess I incorrectly assumed that the video element controls in the shadow
subtree could stand in here—sorry for creating confusion and thanks for
setting it straight.

Rick


>
> Again, events based on the actual actions are the way to go.  If
> you're trying to track user's behavior in some way, what happens if
> you're listening for clicks on the controls but they instead do a
> right-click on the video and select "pause" from there?  The scenario
> you're trying to defend is broken from the start. :/
>
> ~TJ
>

Re: [whatwg] Should generate click events?

[Elliott Sprehn]

On Thu, Aug 22, 2013 at 10:03 AM, Elliott Sprehn wrote:

>
> On Tue, Aug 6, 2013 at 2:30 PM, Ian Hickson  wrote:
>
>> On Thu, 27 Jun 2013, Philip Jägenstedt wrote:
>> >
>> > In a discussion about a "click to play/pause" feature for Opera on
>> > Android, the issue of click event handlers came up.[1] The problem is
>> > that pages can do things like this:
>> >
>> > ...
>>
>> I've made the spec say this is a valid (and recommended) implemenation
>> strategy.
>>
>
> This means that if I have  on the page and then I click
> something that shows a non-modal dialog that should dismiss on clicking
> elsewhere in the page, and then click the video the page popup doesn't
> disappear.
>
> Should authors be listening for mouseup instead to take actions when users
> click inside ?
>
>
I see now that even this isn't possible:

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-video-element.html#attr-media-controls

"""
If the user agent exposes a user interface to the user by displaying
controls over the media element, then the user agent should suppress any
user interaction events while the user agent is interacting with this
interface. (For example, if the user clicks on a video's playback control,
mousedown events and so forth would not simultaneously be fired at elements
on the page.)
"""

This is wrong, it means I have no way to tell if you click inside the
 to dismiss popups or notifications. I don't think we should be
making  a blackhole to events, it breaks lots of use cases.

Instead we should expose the controls as a pseudo element on the event,
just like TransitionEvent has a String pseudoElement so you can tell if the
thing transitioning is the "::before" or the "::after", we should add
::controls and inside the click handler you can take no action if the
target is the controls. If we assume the new Shadow DOM spec, we could just
use the "part" feature which was designed specifically for this kind of
thing and should be exposed on all events.

(User agents don't need to actually allow styling using the ::controls
pseudo element)

I already raised a bug about adding this to all MouseEvents specifically to
handle cases like this:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=22569

- E

Re: [whatwg] Should generate click events?

[Elliott Sprehn]

On Tue, Aug 6, 2013 at 2:30 PM, Ian Hickson  wrote:

> On Thu, 27 Jun 2013, Philip Jägenstedt wrote:
> >
> > In a discussion about a "click to play/pause" feature for Opera on
> > Android, the issue of click event handlers came up.[1] The problem is
> > that pages can do things like this:
> >
> > ...
>
> I've made the spec say this is a valid (and recommended) implemenation
> strategy.
>

This means that if I have  on the page and then I click
something that shows a non-modal dialog that should dismiss on clicking
elsewhere in the page, and then click the video the page popup doesn't
disappear.

Should authors be listening for mouseup instead to take actions when users
click inside ?

- E

Re: [whatwg] Can the maximum allowed value length be changed to restrict the number of characters?

[Boris Zbarsky]

On 8/22/13 9:01 AM, Charles McCathie Nevile wrote:

The basic question is whether a validator should flag  as a conformance error or not.  It seems to
me like it should.


Why? It seems that it generally works in browsers, and has for a long time.


Sort of.  It gets you in a state where the user can erase the "c" but 
not retype it (though the erasing edit can be undone via the editor's 
"undo" functionality, apparently)


-Boris

Re: [whatwg] Can the maximum allowed value length be changed to restrict the number of characters?

[Charles McCathie Nevile]

On Tue, 20 Aug 2013 19:33:12 +0500, Boris Zbarsky  wrote:


On 8/19/13 7:40 PM, Ryosuke Niwa wrote:
Also,  
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#the-maxlength-attribute  
says "if the input element has a maximum allowed value length, then the  
code-unit length of the value of the element's value attribute must be  
equal to or less than the element's maximum allowed value length."


This doesn't seem to match the behaviors of existing Web browsers


The spec bit you quote above is an _authoring_ conformance requirement.  
  That is  is not valid HTML and a  
validator would flag it as invalid.  What UAs do with this markup, on  
the other hand, is defined by the UA conformance requirements, and what  
they do is allow a value longer than maxlength if it's specified.


or  
http://www.whatwg.org/specs/web-apps/current-work/multipage/association-of-controls-and-forms.html#maximum-allowed-value-length


These are the UA conformance requirements in question.

The paragraph should be revised to mention and only mention that the  
maxlength attribute affects the validation and the user agents may  
prevent the user from typing more characters than the specified value.


The basic question is whether a validator should flag maxlength="2" value="abc"> as a conformance error or not.  It seems to  
me like it should.


Why? It seems that it generally works in browsers, and has for a long time.

On the other hand the use cases I can think of have mostly been taken over  
by placeholder, and pattern with good labelling, and so on.


cheers

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: [whatwg] Navigation and history traversal issues

[Andrew Oakley]

On 19/09/12 01:18, Ian Hickson wrote:
> I've changed the spec so that traversing the history by a delta
> always cancels any pending navigations unless you're in the middle of
> an unload, in which case it just aborts the algorithm entirely.
> 
> I've also made back()/forward()/go() not work during the document's
> unload handler, since that could be used for griefing. I'm tempted to
> disable it entirely for all docs a la alert(), but I've no idea if
> that's Web- compatible and I suspect not.

I assume this is where steps 3 and 4 of the "traverse the history by a
delta" algorithm came from.

It's not clear from the spec which browsing context and document these
steps refer to.  Is it the "specified browsing context" and the active
document of that context (I think that makes most sense)?

Additionally it isn't clear which event loop the task should be
associated with.

> Aah, ok. The spec already says that's not allowed. You can't get to
> the History object of a cross-origin Window:
> 
> http://www.whatwg.org/specs/web-apps/current-work/#security-window
> 
> (I forget what the story is if you get a History object from a
> same-origin Window, then have the browsing context navigated, then
> use the History object you kept around... I expect it is supposed to
> work much as if you were to call it on the new, cross-origin, History
> object, though.)

The implication here as that you should never be able to do a history
traversal of a browsing context that is not same origin (and so there is
only one event loop to choose from).  The "story" about keeping history
objects around seems does not seem to be specified anywhere (so the
assumption was that it should work as normal).

It looks like some browsers don't let you use history objects you kept
around (they should probably throw an InvalidStateError), others let you
use them if the current document of the relevant browsing context is
same-origin (and should probably throw a SecurityError).

It's rather awkward to test this, but can we have something in the spec
to prevent cross-origin history traversal?  If this is not in the same
section as the "traverse the history by a delta" algorithm can we have a
note to say that this can never happen cross-origin?

Thanks

-- 
Andrew Oakley

Re: [whatwg] Can the maximum allowed value length be changed to restrict the number of characters?

[Anne van Kesteren]

On Wed, Aug 21, 2013 at 8:19 PM, Alexey Proskuryakov  wrote:
> FWIW, this is tracked for WebKit as 
> .

I think Darin's comment about the server component makes sense. My
remark was mostly as to what is exposed to JavaScript. I don't think
we expose an API to measure the number of grapheme clusters in a given
string at the moment and writing such a function might be rather hard.
(Although if maxlength was redefined to work this way...)

Considering end users makes sense too, but we should also consider
what applications people want to write. From limited testing I believe
Twitter currently counts Unicode scalar values. This is somewhat
better than code units, but e.g. U+0041 U+030A still subtracts two
from your 140 limit. (This also means the example in the specification
that makes a jab at Twitter is technically incorrect.) (Not that
Twitter's current control could be implemented with a plain  or
.)

All choices seem to have drawbacks of sorts. I wonder if Norbert or
Richard have an informed opinion. Rest of the thread is archived here:
http://lists.w3.org/Archives/Public/public-whatwg-archive/2013Aug/thread.html#msg184


-- 
http://annevankesteren.nl/