Re: [whatwg] Allowing size and maxlength attributes for all new input types would provide better fallbacks

[Mounir Lamouri]

On 03/07/2011 04:29 PM, Jukka K. Korpela wrote:
> Current W3C Recommendations, as well ISO HTML, allow the maxlength and
> size attribute in an  element, irrespective of what the type
> attribute value is. I am not proposing a change to that. On the
> contrary, I am proposing that they be allowed, because disallowing them
> would partly break the fallback idea for no good reason.
> 
> And they need not be completely useless if the UA supports the given
> types. I don't see any reason why a UA could not implement, say,  type="time"> as a text box, provided of course that it checks the input
> value as required. I see no problem with the size attribute here. The
> maxlength attribute might seen as potentially problematic, as  type="time" maxlength="5"> could limit the input so that it only
> contains hours and minutes, not seconds. But I don't see that as a big
> problem.

I think you are mixing two issues here (or I am):
-  should be valid and might actually do
something when the UA supports type='time' ;
-  should be valid so it can be set for
legacy browsers.

I have no strong opinions against the former issue: I would agree that
an implementation might follow the specs without a date picker. Such
implementation could use the size attribute.

I'm commenting the later issue below.

>> However, I think the web page should set the attributes in a
>> compat check in javascript.
> 
> It sounds like an unnecessarily complicated and unreliable (Javascript
> might be off) way of doing something fairly simple that authors have
> done (almost) since the dawn of the Web. Old browsers will be happy to
> honor the attributes and new browsers may ignore them (or choose to
> honor them), so why should we need to take a long route?

My answer was actually assuming that you did want to pass
http://validator.nu/. And  isn't valid. In
that case, you can't simply write  in the
HTML code. My answer was also assuming that you were expecting  to show a date picker widget and you did want to provide
your own date picker widget when type='time' wasn't supported by the
browser. In that case, you need some javascript.
I don't think you can sanely expect to fully support legacy browsers if
you use HTML5 Forms without javascript. By "fully support" I mean giving
(more or less) the same level of functionality.

--
Mounir

Re: [whatwg] datalist @exclusive

[Diogo Resende]

On Wed, 9 Mar 2011 16:28:00 +0200, Jukka K. Korpela wrote:

Christoph Päper wrote:


Diogo Resende:


I was thinking.. what about allowing big time spans, like: from
April 1st to June 30th? Giving that the date has "-" as date 
element

separators we could not use 1-MM1-DD1-2-MM2-DD2.


ISO 8601 specifies how to code time intervals (and durations) in
several ways: start and end date/time, start date/time and duration,
duration and end date/time, or duration only – the separtor alwas is
a forward slash ‘/’, replacable by a double hyphen ‘--’ if 
necessary.


If HTML was to support this it should do so in compatibility with 
ISO

8601.


Setting a date range limitation is already possible according to the
current version of HTML5 drafts, just not as an ISO 8601 range
notation (which nobody uses outside laboratories and which requires
parsing the limits) but with min and max attributes, e.g.


Ref.:

http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state

This is supported both by Opera (in its calendar widget) and by
Chrome (in its somewhat odd widget that lets you scroll through 
dates,

one date at a time, but I think that's meant to be allowed as
conforming).


That is perfect for 1 date scope. What if I have a meeting to schedule 
in a month (eg. March) and (according to other meeting attendees) the 
meeting can only happen from 10-15, 19, 20-28 and 30. Do I have to make 
a data-list with every possible day? What if I would like to set a 
future event that cannot happen on weekends?

Re: [whatwg] Redirect handling for &

[Aaron Colwell]

Thanks for your response.. comments inline

On Fri, Mar 4, 2011 at 1:30 AM, Philip Jägenstedt  wrote:

> On Thu, 03 Mar 2011 22:15:58 +0100, Aaron Colwell 
> wrote:
>
>  Hi,
>>
>> I was looking at the resource fetch
>> algorithm<
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#concept-media-load-resource
>> >section
>> and fetching
>> resources <
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/urls.html#fetch
>> >
>> sections of the HTML5 spec to determine what the proper behavior is for
>> handling
>> redirects. Both YouTube and Vimeo do 302 redirects to different hostnames
>> from
>> the URLs specified in the src attribute. It looks like the spec says that
>> playback should fail in these cases because they are from different
>> origins (Section 2.7 Fetching resources bullet 7). This leads me to a few
>> questions.
>>
>> 1. Is my interpretation of the spec correct? Sample YouTube & Vimeo URLs
>> are
>>   shown below.
>>   YouTube : src  : http://v22.lscache6.c.youtube.com/videoplayback?
>> ...
>> redirect : http://tc.v22.cache6.c.youtube.com/videoplayback?
>> ...
>>
>>   Vimeo   : src  : http://player.vimeo.com/play_redirect? ...
>> redirect : http://av.vimeo.com/05 ...
>>
>
> Yes, from what I can tell you're correct, but I think it's not intentional.
> The behavior was changed by  in 2010-06-25, and
> this is the first time I've noticed it. Opera (and I assume most if not all
> other browsers) already supports HTTP redirects for  and I don't
> think it makes much sense to disallow it. For security purposes, the origin
> of the resource is considered to be the final destination, not any of the
> origins in the redirect chain.
>
>
> I agree that redirects should be allowed, but it seems like the force
same-origin flag was introduced to limit the types of redirects. The YouTube
& Vimeo cases mentioned above seem reasonable, but redirects from vimeo.comto
malicious-site.com might not be ok. It looks like the changes reference CORS
as a future solution. Do you have any CORS references that might be helpful?

You also mentioned that the final destination is what should be used for
security. It seems like this could cause problems for canvas.drawImage() (
http://www.whatwg.org/specs/web-apps/current-work/#security-with-canvas-elements)
when trying copy video data to the canvas. If I understand you correctly a
page on YouTube would have to come from the final destination origin to
allow canvas.drawImage() to work. Is that correct?


>  2. What about http: -> https: redirects? Some content is required to be
>> delivered
>>   only via https and this sort of redirect enforces that but isn't really
>> a
>> different origin.
>>
>
> Quoting <
> http://tools.ietf.org/html/draft-abarth-principles-of-origin-00#section-3
> >:
>
> "two URLs are part of the same origin (i.e., represent the same principal)
> if they have the same scheme, host, and port"
>
> Since both the scheme (http vs https) and port (80 vs 443) would be
> different, it's considered a different origin.


I think I made some poor word choices here. I agree that they are different
origins because the scheme and port are different. I was just trying to get
at the fact they still referred to the same content just over a secure
connection. It seems like there are use cases where a set of  tuples should be considered a single origin from a security point of
view. It just isn't clear to me how we are supposed to express that.


>
>  3. If my interpretation of the spec is correct, are there proposals to
>> change this
>>   or other specs that allow content providers to signal that these
>> different hostnames
>>   actually represent the same "origin".
>>
>
> I think the force same-origin flag introduced by 
> should be removed from the resource fetch algorithm, but the http vs https
> origin issue is not something that can really be changed.
>

So what is the process for proposing this type of change? Is this the right
forum?
Why is allowing redirects with the same scheme but different hosts ok, but
redirecting different schemes with the same host not ok? I'm new to this so
I'm just trying to understand.


Aaron

Re: [whatwg] datalist @exclusive

[Christoph Päper]

Jukka K. Korpela:
> Christoph Päper wrote:
>> Diogo Resende:
>>> 
>>> I was thinking.. what about allowing big time spans,
>> 
>> ISO 8601 specifies how to code time intervals (and durations) … – the 
>> separator always is
>> a forward slash ‘/’, replacable by a double hyphen ‘--’ if necessary.
>> 
>> If HTML was to support this it should do so in compatibility with ISO 8601.
> 
> Setting a date range limitation is already possible (…) with min and max 
> attributes

Sure. The slash notation should only be employed if one wanted to submit time 
interval data as a single entity to the server. HTML has no form widget, i.e. 
‘input’ type, supporting that (yet). Usually one or, more commonly, two 
entities / form elements out of “start”, “end” and “duration” are used instead.

Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]

[Markus Ernst]

Am 09.03.2011 12:19 schrieb Diogo Resende:

On Tue, 8 Mar 2011 16:51:25 -0800, Jonas Sicking wrote:

On Tue, Mar 8, 2011 at 10:46 AM, Markus Ernst  wrote:

Am 08.03.2011 19:02 schrieb Anne van Kesteren:


On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela
 wrote:


For example, consider a date picker. Quite often, whether trying to
make dates or selling flights, there is a known set of
(non-consecutive) days that are possible, so we would like to
write, say,









(...)

/ Jonas


I was thinking.. what about allowing big time spans, like: from April
1st to June 30th? Giving that the date has "-" as date element
separators we could not use 1-MM1-DD1-2-MM2-DD2. Couldn't this
be useful? Even more common might the usecase where a date must be from
some date onward (or until some date). How is this addressed?


I assume that this is only a problem if you need to allow/disallow 
several periods in the same date picker. For one single period, or 
allowing dates only from or up to some date, you can use "min" and "max" 
attributes in the input type=date element.

Re: [whatwg] datalist @exclusive

[Jukka K. Korpela]

Christoph Päper wrote:


Diogo Resende:


I was thinking.. what about allowing big time spans, like: from
April 1st to June 30th? Giving that the date has "-" as date element
separators we could not use 1-MM1-DD1-2-MM2-DD2.


ISO 8601 specifies how to code time intervals (and durations) in
several ways: start and end date/time, start date/time and duration,
duration and end date/time, or duration only – the separtor alwas is
a forward slash ‘/’, replacable by a double hyphen ‘--’ if necessary.

If HTML was to support this it should do so in compatibility with ISO
8601.


Setting a date range limitation is already possible according to the current 
version of HTML5 drafts, just not as an ISO 8601 range notation (which 
nobody uses outside laboratories and which requires parsing the limits) but 
with min and max attributes, e.g.



Ref.: 
http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#date-state


This is supported both by Opera (in its calendar widget) and by Chrome (in 
its somewhat odd widget that lets you scroll through dates, one date at a 
time, but I think that's meant to be allowed as conforming).


--
Yucca, http://www.cs.tut.fi/~jkorpela/ 

Re: [whatwg] datalist @exclusive

[Christoph Päper]

Diogo Resende:
> 
> I was thinking.. what about allowing big time spans, like: from April 1st to 
> June 30th? Giving that the date has "-" as date element separators we could 
> not use 1-MM1-DD1-2-MM2-DD2.

ISO 8601 specifies how to code time intervals (and durations) in several ways: 
start and end date/time, start date/time and duration, duration and end 
date/time, or duration only – the separtor alwas is a forward slash ‘/’, 
replacable by a double hyphen ‘--’ if necessary.

If HTML was to support this it should do so in compatibility with ISO 8601.

Re: [whatwg] Form input element for value-unit pairs

[Diogo Resende]

This is just a numeric input. It has a unit, just like a monetary 
value, but besides that it's just a number. Maybe a numeric input should 
have some type of formatting to proper show the unit (prefix/suffix, 
decimals places, decimal sep., ...).


On Sat, 5 Mar 2011 18:26:52 +0100, Christoph Päper wrote:

Imagine a richt text processor done in HTML5. If you want to select
the font size (of a template or class, of course) how would you do 
it?



Standalone word processors usually have a combo field that lets the
user enter a number

  [12]

possibly adding controls for increasng and decreasing

  [12]±[12]↕

or they may allow the user to select one of the predefined
recommended or frequent values.

  [12 ↓]

These are commonly using, without explicitly mentioning it, the magic
unit ‘point’, which users usually don’t know, especially if they’re
not from the US and are not trained typographers.

In other places, software interface designers honor the variety of
absolute and relative (length) units by introducing a widget that
bears the number and the unit symbol,

  [12 pt]±

which can both be changed, although not independently.

‘pt’→‘px’ ⇒ [12 px]  not  [16 px]

Some implementations are even broken in that they accept many unit
symbols, but always autoconvert (and round) to a preferred unit.

  [4 mm] → [11.34 pt]

Thus, would it make sense to add another new type for the ‘input’ 
element?

Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]

[Diogo Resende]

On Tue, 8 Mar 2011 16:51:25 -0800, Jonas Sicking wrote:
On Tue, Mar 8, 2011 at 10:46 AM, Markus Ernst  
wrote:

Am 08.03.2011 19:02 schrieb Anne van Kesteren:


On Tue, 08 Mar 2011 12:26:56 +0100, Jukka K. Korpela
 wrote:


For example, consider a date picker. Quite often, whether trying 
to

make dates or selling flights, there is a known set of
(non-consecutive) days that are possible, so we would like to 
write, say,










(...)

/ Jonas


I was thinking.. what about allowing big time spans, like: from April 
1st to June 30th? Giving that the date has "-" as date element 
separators we could not use 1-MM1-DD1-2-MM2-DD2. Couldn't this 
be useful? Even more common might the usecase where a date must be from 
some date onward (or until some date). How is this addressed?


-
Diogo

Re: [whatwg] Cross-domain databases; was: "File package protocol and manifest support?"

[Brett Zamir]

With IndexedDB apparently gaining traction, I'd like to reiterate my 
proposal for cross-domain shared databases. Though I'll admit I'm not 
sure I understand all of the concerns raised earlier, I do want to offer 
my own rebuttals to these counter-points as I understand them (and 
subsequently highlight some additional advantages):


*Compared to using cross-domain shared workers*

While cross-domain shared workers might be more ideal for sites which 
wanted more granular control of how their shared data was accessed, and 
no doubt a positive idea for sites wishing to go to the trouble to set 
it up, my strong feeling is that making one's data shared should also be 
possible in an easy a manner as setting up the database itself. 
Requiring the developer to create their own API for others to access 
their database would no doubt A) prevent some sites which might be open 
to sharing their data from doing so, and B) Add barriers for those 
wishing to mash-up different sites' data, as it would require study of 
not only the site's unique data store, but also its means of allowing 
access to it.


If not from the start, ideally the API could eventually offer more 
fine-grained access, such as to request read-only privileges or the like 
from the user, but these features would ideally work for any site 
offering a shared database, with no need to learn a site-specific API.


*Compared to being able to copy a remote database*

Besides avoiding wasted space in duplicating another database, the 
alternative of being allowed to make a simple copy of a remote database, 
is inferior in that one would not be able to operate off of the same 
data, especially if changes continue to be made by the user within the 
application and for which they do not wish independent copies of data. 
If one site offers a note-taking application, there are strong benefits 
for portability as well as concurrent use of different interfaces if the 
same data can be manipulated by multiple applications (as in different 
word processors being able to access the same file). Moreover, there is 
also the assurance for an application that it is allowing its users to 
work with the latest data from their targeted site if the targeted site 
has its own means of ensuring automatic updates.



*Transactional concerns*

I would think transactional concerns could be addressed by building in 
transactions and/or good judgment by the sharing party about whether to 
share a database in the first place (if a third-party application could 
cause corruption). Surely there are no inherently insurmountable 
barriers here.

*

Higher Privileges, Iterating Databases, and Search*

I would even hope, especially given the apparently similarly 
privilege-seeking FileSystem API,  for the ability to request permission 
from the user to access any local database, whether shared by the site 
author or not, if the idea is not shot down by those not willing to 
accept that good features may still come at the cost of security risk to 
some users who do not pay attention to dialogues (these users can also 
be duped to download unsafe executables, opt in for geolocation, etc., 
so I don't think the web should be stunted in its growth by 
over-coddling all of us just because some may abuse it). It would also 
be nice to be able to iterate through the available databases in order 
to allow generic database viewing programs to be built as web apps, as 
well as perhaps eventually see a Full Text Search API for searching 
through all of one's data (and files).


The WHATWG cannot anticipate and make its own API for every possible 
shared data use case (even if some general uses like calendar access 
indeed call for their own API) nor expect that everyone willing to share 
data will wish to go through numerous hoops to do so. I think the full 
power of Shared Data and Open Data remains to be seen if the user were 
able to download data once, while having the ability to query that data 
as they wish from any number of their own chosen applications, and if 
shared content providers could be free to lighten their server loads and 
alleviate security concerns for enabling unrestricted searches.


Thanks,
Brett

(The email below is repeated for convenience, but due to my loss of the 
original email, obtained from 
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-June/020299.html or 
as a better organized thread: 
http://www.mail-archive.com/whatwg@lists.whatwg.org/msg15393.html )

---
On Wed, 20 May 2009, Brett Zamir wrote:
>
> I would like to suggest an incremental though I believe significant
> enhancement to Offline applications/SQLite.
>
> That is, the ability to share a complete database among offline
> applications according to the URL from which it was made available.
> [...]

On Tue, 19 May 2009, Drew Wilson wrote:
>
> One alternate approach to providing this support would be via shared,
> cross-domain workers (yes, workers ar

Re: [whatwg] datalist @exclusive [was: Please reconsider: Set restricted palette for input type=color]

[Markus Ernst]

Am 09.03.2011 06:51 schrieb Jukka K. Korpela:

Jonas Sicking wrote:


I'm having a little bit hard of a time figuring out what a good UI
would look like in the general case. I.e. what should the UI look like
for









Do you allow flipping between only the months which have any available
dates in them using the next/previous month buttons in the date
picker?


That would be the idea, I guess, but there are two alternatives
regarding months that have no applicable days: either skip them or gray
them out. So in your example, when in April 2011, "Next month" button
could take you to June 2012, or it might take you to to May 2011 with
all days grayed out


It should definitely be the latter, as "Next month" taking you to 
somewhere else than the next month is confusing. IIRC I have seen JS 
date pickers behave like that, but I am sorry I don't remember where it was.


Even in a rare use case where several months are totally grayed out, the 
user needs the information that no dates are available there - else 
(s)he will assume a technical error or somewhat.

[whatwg] Improving the Application Cache

[Edward Gerhold]

Hi,

i have reviewed the "Programmable HTTP Caching and Serving" document. And
yes, it handles all i want.
Of course, the specification is a lot better than my suggestion and i find
the OfflineHandler and LocalServer
feature killer. The specification uses the speech of the other documents,
and seems to be ready for being
implemented. It wouldn´t be difficult for programmers to use these names and
programming rules, i think.
For the document i hold my thumbs up and i hope you advise the browser
vendors soon, to take care of.

The second i would like to mention again is "CACHE MANIFEST NOMASTER" for
the simple whitelisting of
the master file. I think you should remember it.

Using "Programmable HTTP Caching and Serving" would replace the rest of
my request and even extend it.
Thanks for reading my mails.

bye,
Edward