Re: [whatwg] Web Sockets

[Ian Hickson]

On Mon, 14 Jul 2008, Honza Bambas wrote:
>
> I am just concern about the way the protocol is specified. When I read 
> the notes it is obvious the communication is actually an HTTP 
> communication. Let's say I am a browser developer. Let's say I have to 
> enhance my already fully armed browser with all the support for HTTP 
> protocol and proxy/HTTP authentication, cookies, fixed many security 
> issues etc. It would be reasonable to use my HTTP implementation and 
> build ws/wss client protocol on top of it. Problem is that spec counts 
> with exact byte compare but my implementation might possibly change 
> headers order or HTTP version (to higher one). This would violate the 
> WHATWG spec but the request according to HTTP protocol would still be 
> correct.

On the browser side I don't think there is any reason to reuse the HTTP 
implementation. This isn't HTTP, and isn't intended, on the client-side, 
to be even like HTTP. It's similarity to HTTP is only intended to allow 
servers to Upgrade to WSP so that one IP/port combination can be shared 
between HTTP and WSP.


> This might make the implementation (and therefor also adoption) of this 
> technology more complicated for browser developers.

Given how easy the handshake is to implement on the client, I don't think 
that's a concern at all.


> Why exactly is in the spec intention to do exact byte-to-byte match? To 
> allow very easy implementation using scripts?

Making writing servers easy and having a handshake that other protocols 
can't be tricked into resembling are the two primary driving forces behind 
the current design.

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

Re: [whatwg] Should enter be mapped to click?

[Ian Hickson]

On Mon, 14 Jul 2008, Aaron Leventhal wrote:
>
> Now that tabindex can be used on any element to make it focusable, it 
> makes sense that it should be possible to trigger a click on those 
> elements with the keyboard.
> 
> Opera maps Enter to click. As far as I know, other browsers only do that 
> for a few elements like.
> 
> What do people think? Should it be spec'd?

3.4.1.7. Interactive content, paragraph 3:

| When activation is performed via some method other than clicking the 
| pointing device, the default action of the event that triggers the 
| activation must, instead of being activating the element directly, be to 
| fire a click event on the same element.

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

Re: [whatwg] element

[Ian Hickson]

On Mon, 14 Jul 2008, Lars wrote:
> 
> I have written a little text now which have some documentation and info 
> about this attribute.

Woah, that's the most useful information I've ever seen on , 
thanks!


> Where should I send this, and to whom?

Sending it to this list was the right place.

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

Re: [whatwg] Should enter be mapped to click?

[Aaron Leventhal]

3.4.1.7. Interactive content, paragraph 3:
   

Thanks! Small typo:
instead of being activating the element directly,
Extra word "being"

- Aaron

Re: [whatwg] Should enter be mapped to click?

[Anne van Kesteren]

On Tue, 15 Jul 2008 09:50:25 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:

On Mon, 14 Jul 2008, Aaron Leventhal wrote:


Now that tabindex can be used on any element to make it focusable, it
makes sense that it should be possible to trigger a click on those
elements with the keyboard.

Opera maps Enter to click. As far as I know, other browsers only do that
for a few elements like.

What do people think? Should it be spec'd?


3.4.1.7. Interactive content, paragraph 3:

| When activation is performed via some method other than clicking the
| pointing device, the default action of the event that triggers the
| activation must, instead of being activating the element directly, be  
to

| fire a click event on the same element.


Last I checked that doesn't say each focusable element actually gets  
activation behavior as well. Here's an example:


  TEST

The specification states that only certain elements are "interactive  
content", not everything that's focusable.




--
Anne van Kesteren

[whatwg] Select element suggestion

[Csaba Gabor]

I know it is rather late in the game, but there is an attribute that would be 
immensely useful for SELECT elements.  It is motivated by a desire to make web 
page interaction more efficient.

It is frequently the case that SELECT elements of size 1 (drop downs) are quite 
long, requiring scrolling to reach most of the options.  For example:
Year a person was born in
States of the US
Countries of the world
Height (in inches or cm)

This necessitates a minimum of 4 actions for most of the options (click to pull 
down the select, click on scroll bar, drag scroll bar, click desired option) 
vs. 2 actions (the first and last) for those options near the top.  Clearly the 
time difference is significant, especially when the same select element must be 
selected on repeated visits.  Furthermore, the overwhelming liklihood is that 
only a few of the many options will ever be of interest to any individual.

Therefore, it makes sense to float those values to the top of the select 
element in a reasonable way.  What's reasonable?  I would like to suggest:
frequencyLimit=percent



Alabama
Alaska
Arizona
Arkansas
...
Wyoming


This would say that if any element is selected 16% or more of the time, it 
floats to the top part of the select element.  It would apply to any select 
element of the same name and frequencyLimit at [for efficiency reasons] the 
current page's directory level or lower.

Specifically, a reasonable UA implementation would be:
For each select element of a minimum size (say 9 elements) with frequencyLimit 
set, compute a checksum of the select element (e.g. md5) and if that matches 
the previous value, then frequency analysis should be done (otherwise, start 
with a fresh slate).  The initial position (for reinsertion purposes) of each 
option and frequency count of each option is stored.

If the frequency of an option being selected reaches the threshhold, it is 
moved to the top portion of the select element.  If the frequency drops below 
this threshhold, it is moved back to its original position.

This is clean, backwards compatible, and offers a clear advantage in usability, 
especially for impaired users.  It is something that could be implemented by 
javascript on individual web pages, but it makes more sense to have a uniform 
approach.

A few comments/pitfalls:
1.  If frequencyLimit=p, this does not float the Math.floor(100/p) most 
frequently selected options to the top.  At most that many will get floated to 
the top.  For example, with frequencyLimit=33, if Oregon and New York are both 
selected 40% of the time, while ILlinois and California are selected 10% of the 
time, only Oregon and New York will float to the top since only they exceed 33%.

To consider a second example in this light, frequencyLimit=5 might seeem to 
mean that one can expect 20 elements to float to the top, but it is extremely 
unlikely that there would be such uniform distribution of selections.  It's far 
more likely that fewer than 10 elements float to the top.

One could put lomething like frequencyLimit='.2', effectively floating 
anything that is selected to the top.  However, this would create two separate 
lists within the select, likely leading to confusion.  If M is the maximum 
number of options that can be seen at any one time, probably the frequencyLimit 
should ensure that no more than M options get floated to the top.

2.  Of course this proposal represents a demand on the UA to cache the 
information across sessions as with cookies, so it makes sense for the UA to 
limit the number of such cached select elements under any particular 
domain/directory.  In addition, there is some exposure of privacy, so these 
saved values should perhaps live and die with corresponding cookie information.

3.  As outlined above, the scheme does not work for dynamically populated 
select elements.  However, in those situations, frequencyLimit should not be 
set a priori (in the HTML); rather, it should be set after the select element 
is populated.  At this point, the UA would then compare the select element 
against any cached image (ie. checksum).  This also provides a mechanism for 
the server to clear out cached information, by setting frequencyLimit on an 
empty select element.

4.  Everything can apply just as well to multiselect elements and to elements 
of size greater than 1.

5.  One could envision only using the last n selections (where n is say 100) 
for analysis, but this puts an additional implementation burden on the UA.


Csaba Gabor from Vienna



  

Re: [whatwg] Select element suggestion

[ddailey]

This does not really address what you're asking for, but rather what you're 
asking for reminds me of something else:


several years ago I used to ask my students to program, as exercises, 
various useful widgets in HTML/JavaScript (color pickers, alarm clocks, 
zoomers and panners and sliders and so forth) -- the sorts of things that 
were not really standardized yet but which might be useful in applications 
of all sorts running in some WWW-like network. Fortunately I now hold 
patents on all of these (just kidding! but I pleased that my prior art 
invalidates new patent claims that might arise).


One of the exercises was to develop a slider in which an ordinal discret 
entry k < n could be chosen as quickly as possible for large integer n. The 
familiar examples I gave were the digital timer on a stove (if you keep your 
finger down long enough it accelerates from 1 min/sec of change to 10 
min/sec of change. Can we make some sort of slider in which the movement of 
the mouse allows the construction of the numbers 162537, 2, or 791 quicker 
than it would take to type that number (or at least most) by hand. The 
detection of both duration of the mousedown event as well as subtle changes 
in its positioning, I argued, could be used to do just that. None of the 
students (all undergrads) ever accomplished quite what I had in mind, so 
I've de-elevated (or elevated) the thing to extra credit status. The problem 
is sort of similar, how best to enable a user to select from a large number 
of possibilities. In the case of certain objects, like magnitudes and 
numbers, there is a natural and intuitive ordering of options, such that 
some loglinear interface to an accelerometer allows (in theory) linear-time 
access to 2^n options. Likewise in the case of alphabetization of 
western-language style strings: relying on the mapping that people 
presumably internalize between the alphabet and the line, a slider (like a 
selection list) maps n options onto points on a line. The irregularities 
along that line posed by discontinuity of actual words, is arguably 
negligible. When it comes to semantically discrete categories, the prospect 
of speeding users' ability to choose from among N options, depends on either 
a) the division of those N options into logN intuitive categories (such was 
the goal of Dewey and L of Congress classifications) -- think of cascading 
submenus in which logN branches in a tree ultimately accesses any of the N 
leaves, or in the ability to somehow map those N options onto a linear (or 
multidimensional) manifold that intuitively maps the space. The problem in 
either case is in customizing our interface to people's intuition about the 
Semantic proximity (in the original sense of the term semantic in 
linguistics as differentiated from the newfangled spec-speak usage of the 
term) of the various options presented.


You've suggested an approach which could involve server side intervention: 
as options are more frequently chosen (across multiple users), those options 
eventually float closer to the top, and the spec, if responsive to your 
suggestion, would presumably allow the author to choreograph this 
client-server interaction. Assuming that frequency of choices tends to obey 
some sort of Zipf's law, then the top 4/n items would account for 
k(1/2+1/4+1/8+1/16) of the options chosen for some k, hence simplifying life 
for lots of people. I'm not sure Zipf's law though would actually apply to 
most things though. Population across geopolitical districts (states and 
countries) is probably distributed more like a Bell curve than like word 
frequencies ("the" "of" "a"), so the advantage may not be so pronounced as 
we might hope.


But as long as we're open to the kind of approach, that allows the author to 
choose some soft of server-optimized ordering then it seems like broader 
possibilities arise. Telling the server to perform a principle components 
analysis based on some lexico-semantic criterion and then to map the options 
in a 2D plot, or to find the most intuitive taxonomy (based on method A B or 
C) for our options would also become possible. Even in the simplest case: 
maximize users' selection speed for a large set of contiguous integers, the 
situation becomes rather fun. So fun, in fact, that it would be worth 
playing with.


Again, much of this is rather tangential to your idea, but the idea is just 
intriguing enough to provoke thought.


cheers,
David Dailey

- Original Message - 
From: "Csaba Gabor" <[EMAIL PROTECTED]>

To: <[EMAIL PROTECTED]>
Sent: Tuesday, July 15, 2008 8:14 AM
Subject: [whatwg] Select element suggestion


I know it is rather late in the game, but there is an attribute that would 
be immensely useful for SELECT elements.  It is motivated by a desire to 
make web page interaction more efficient.


It is frequently the case that SELECT elements of size 1 (drop downs) are 
quite long, requiring scrolling to reach most of the options.  For 
exa

Re: [whatwg] Select element suggestion

[Gervase Markham]

Csaba Gabor wrote:

Therefore, it makes sense to float those values to the top of the
select element in a reasonable way.  What's reasonable?  I would like
to suggest: frequencyLimit=percent


I assume you would want this to work across different sites? If so, you 
have a privacy problem. I can tell with fairly good certainty what state 
you are from without you telling me; I just set up a hidden one of these 
and query the DOM. I can also find out the expiry month and year of your 
main credit card.


Gerv

Re: [whatwg] Select element suggestion

[Tab Atkins Jr.]

On Tue, Jul 15, 2008 at 1:30 PM, Gervase Markham <[EMAIL PROTECTED]> wrote:

> Csaba Gabor wrote:
>
>> Therefore, it makes sense to float those values to the top of the
>> select element in a reasonable way.  What's reasonable?  I would like
>> to suggest: frequencyLimit=percent
>>
>
> I assume you would want this to work across different sites? If so, you
> have a privacy problem. I can tell with fairly good certainty what state you
> are from without you telling me; I just set up a hidden one of these and
> query the DOM. I can also find out the expiry month and year of your main
> credit card.
>
> Gerv
>

Good catch.  The proposed implementation appears to intended to be
cross-site, as it would key the frequency data off of the checksum computed
from the select (that is, purely from the chunk of code that the select
comprises).  It would not be difficult for evil sites to simply copy the
exact structure of s on major sites and do as you suggest.

Perhaps checksumming off of a combination of the select text and the URI of
the document?  This reduces the ability to have, say, Texas always float to
the top of select elements, but that's already out of the question.  At
least it would allow a single often-visited site to compile your usage
statistics.

A thought:  the intended use of the suggestion (allowing s across
the internet to auto-recognize you) isn't likely to work in any case, simply
because it's unlikely that many sites will write their code exactly the
same.  Nearly all sites would have to recognize your preferences
individually and associate them with a personal checksum.  The only sites
that are likely to benefit from your expressed preferences are the
individual sites you select on, and evil sites doing as Gervase suggests.

As well, though an intelligent implementation of this *would* be somewhat
convenient in reducing keystrokes, it produces a potential decrease in
usability when different sites place your preferred selection in vastly
different places.  Existing practices produce nearly identical selects in
the cases that this proposal is intended for (common dropdowns, like state
and such), merely because there is already a defined ordering and most
places just copy their code from someone else because it's easier than
typing out all of the options.  I know that I get *very* confused when
United States isn't in its expected place (at the top of the list, of
course, since I'm such a country chauvinist), and would have a similar
problem if my state were moved around - I've internalized about how far down
I need to scroll to see my state on a dropdown.

~TJ

Re: [whatwg] re-thinking "cue ranges"

[Silvia Pfeiffer]

Hi Philip, Dave, all,

I agree with Philip and Dave that we need a simple way to include the
cue ranges concept into video for video authors.

As one of the authors of Annodex, I have been meaning to look over the
HTML5 video element for a while and examine how it's details works -
sorry for my late contribution.

In Annodex we created a simple XML markup language called CMML (for
Continuous Media Markup Language) that would turn time-continuous data
such as audio and video into Web-style documents with the ability to
define temporal segments (or events or cues or clips - call them
whatever you prefer), attach a description and meta data to it, attach
an outgoing hyperlink to it, and address these segments directly
through URLs. If this feels almost like a web page, then that's
exactly what we intended to achieve.

In addition to this author-controlled creation of cue ranges, we also
allowed for the creation of temporal hyperlinks, which would point
directly to a time-defined (dynamic) segment inside a video. This is
now being examined more closely in the new W3C Media Fragments Working
Group http://www.w3.org/2008/01/media-fragments-wg.html .

But I digress...

Taking the definition of cue ranges out of html and including it into
the media content itself, but providing a similarly simple markup
language to create the segmentation makes a lot of sense. Above
everything else, it reduces the complexity of the HTML specification
and puts the definition of the segmentation into the hands of the
person that would create it: the video content author.

But you want to stay flexible with the segmentation since it may be
needed in multiple representations:

* you may want to have it "burnt" into the video such that every copy
of the video continues retaining the segmentation created by the
author - for this case we created a representation of CMML that is a
binary interleave of the original video file and the CMML temporally
multiplexed into it such that the right right cues are aligned with
the video data they refer to. The multiplexing is done to allow for
live streaming of such cues with the video within one network
connection. This is what we called an Annodex stream (annotated and
indexed video).

* you may want to keep your cues and associated data in a database and
only create the CMML and/or the Annodex stream upon a user request.
This is similar to the dynamic creation of a Web page from a database.

* or you may indeed want to continue keeping one or more cue range
segmentations in separate CMML files aside the original video file to
make the cues and annotations for a video available in separation of
the video (e.g. for use by a search engine crawler). Imagine Google
could index deeply inside a video because the cues and annotations of
the video are made available in a standard crawlable format.

In such a scenario, all you need to do in the video element is the
creation of a set of javascript API calls that can directly make use
of the information defined in the CMML file, like is demonstrated in
this video: http://au.youtube.com/watch?v=LbWb1dkvm0s
The code for this demo is available here:
http://svn.annodex.net/browser_plugin/trunk/test/test.html .

Notice how the problem of addressing cues has been taken totally out
of the javascript API - all we do in javascript is address time
offsets. The semantics of the time offsets is stored in the
annotations, which can be retrieved using their own javascript API
call.

Cheers,
Silvia.


On Sat, Jul 12, 2008 at 4:00 PM, Philip Jägenstedt <[EMAIL PROTECTED]> wrote:
> Just to add some of my thought on cue ranges.
>
> Like Dave, I am not terribly enthusiastic about the current cue ranges
> spec, which strikes me adding a fair amount of complexity and yet
> doesn't solve the basic use case in straightforward manner.
>
> If I were a content author and looked at the available options to
> display subtitles, I would probably simply add a timeupdate event
> listener and use e.target.currentTime to decide on an action to take.
> While lexical closures are fun and useful, depending on them isn't
> terribly nice to those who don't have experience with functional
> programming (you can use ECMAScript without realizing that it's a
> function language, so it doesn't count).
>
> I agree that proper events make a lot of sense here instead of
> callbacks. We could use some new event -- CueEvent maybe -- which would
> actually include the start and stop times and a reference to the target
> HTMLMediaElement. I might suggest a modified addCueRange which takes a
> data argument which is also passed along in the event object.
>
> If we support external annotations we need some open format for this
> which all browsers can support. I'm not very familiar with SMIL, but it
> looks like a Swiss army knife. Perhaps http://www.annodex.net/ is also
> worth a closer look: "CMML is a HTML-like markup language for
> time-continuous data such as audio/video." Then there's the new
> http://w