Re: [whatwg] Decimal comma in numeric input

[Jukka K. Korpela]

16.07.2011 00:01, Ian Hickson wrote:


Much discussion on this topic happened when we started on this work in
2004 and 2005, I highly recommend perusing the archives around that time.


Authors and implementors will need to be able to understand the topic 
without checking discussions archives, so the specs should say at least 
a little about the issue that the rules for user’s input may be quite 
different from the rules for the as stored and forwared. And users will 
be confused anyway, when user interfaces work oddly.



On Thu, 14 Apr 2011, John Tamplin wrote:


The entire web application, which includes both client and server-side
code, must have the same idea about what locale the user is using.  If
the app provides a drop-down box or preference setting to choose a
different locale, as most localized apps do, the web browser has to be
using the same locale for any native locale processing it uses.
Otherwise, you run a serious risk of having incorrect data -- if a user
types "10,000" in a field when they think they are using a locale with a
comma as the decimal separator, does the app receive that as 1 or
10.000?  If the app is running in en-US because the user requested it or
their system locale isn't supported by the app, and the browser sends
"10.000" as the value because the system locale is "de", then that is a
problem.


Indeed. To solve this, we need help from CSS. That's one of the reasons we
created  in HTML.


This is about data representation and localization, not about optional 
stylistic suggestions, so CSS is a wrong way to deal with the issue. It 
will probably cause _further_ confusion.


I’m afraid the new input types for numeric data and for dates and times, 
even when implemented in browsers, will be of very limited usefulness 
and will cause more damage than good, unless the localization issues 
will be properly addressed.


It is part of the risk that they often _seemingly_ work. For example, an 
author would use  and test the software thoroughly by 
his own standards, but the standards don’t include testing with the 
system’s UI language being other than English. So things seem to work 
until someone tries to put a bid of 10,000 dollars but gets it turned to 
10 dollars and loses, or makes a date for 7/4/2012 and gets it 
interpreted as April 7 when he meant July 4, or vice versa.


I’m afraid many authors will start using the new types eagerly when 
browser support comes sufficiently widespread. It looks so much better, 
cooler, and easier than parsing data yourself or requiring the user to 
type data in specifically instructed format. But it’s a dangerous illusion.


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

Re: [whatwg] a rel=attachment

[イアンフェッティ]

On Fri, Jul 15, 2011 at 4:43 PM, Glenn Maynard  wrote:

> 2011/7/15 Jonas Sicking 
>
>> It definitely is an interesting usecase that Glenn brought up about
>> being able to specify a save-as name without otherwise modifying the
>> behavior of a reference. However that seems like a much more rare
>> usecase and so not the one we should optimize for.
>>
>
> Bear in mind that "optimize for" doesn't mean "support at all"; if
> download=filename is used, it seems unlikely that there will ever be *any*
> client-side way to supply the filename without implying attachment, which is
> a very different thing than "not optimizing for it".
>
> I don't feel strongly enough about this to press it further, but  href=ugly download filename=pretty> also seems fairly clean, and avoids
> combining parameters that really are orthogonal to one another.
>

I really don't see the importance of the "name the thing that isn't going to
be downloaded" usecase; there are countless edge cases that we could concern
ourselves with in HTML but that few users will ever hit, this is one. (I
also suspect a user sophisticated enough to actually save something, e.g.
right click save as, is sophisticated enough to be able to type their own
filename.)I think it's better overall to keep the semantics as clean and
simple as possible. I suggest we move forward with  with the origin considerations mentioned in the previous
email and move on.




>
> --
> Glenn Maynard
>
>

Re: [whatwg] a rel=attachment

[Kevin Marks]

Enclosure is precisely this use case.

You can go back and grep
http://www.imc.org/atom-syntax/entire-arch.txt for enclosure for the
discussion if you like. After much debate, rel="enclosure" was used to
replace RSS's  element, preserving the name.

This will lead you back via the RSS specs to this post by Dave Winer in 2001:

http://www.thetwowayweb.com/payloadsforrss

which makes the same analogy with email that you're using for "attachment"

The original example RSS file there:

http://static.userland.com/gems/backend/gratefulDead.xml

Is usefully rendered by Firefox and Safari, by translating the XML
file into an HTML representation that makes sense to users, and allows
subscription to it.

The same is true for any Atom or RSS feed containing podcasts.

Sadly, Chrome just shows a document dump of the XML tree, useless to anyone.

On Fri, Jul 15, 2011 at 6:30 PM, Peter Kasting  wrote:
> On Fri, Jul 15, 2011 at 6:25 PM, Tantek Çelik wrote:
>
>> ** Specs *and* publishers/consumers/implementations of rel-enclosure exist
>> (see aforementioned wiki page).
>
>
> The list on the wiki page, which I assume is non-exhaustive, is
> extraordinarily uncompelling.

Indeed, that could do with updating with newer examples and references
to oterh support.

>
>
>> And the name is based on re-using the existing term with the same semantic
>> from the Atom spec.
>>
>
> Don't care.  Atom feeds and HTML pages are very different things.  Basically
> I echo all of Tab's annoyances with this.
>

Atom/RSS Feeds are seen as useful HTML sources by many browser implementations.

Re: [whatwg] a rel=attachment

[Peter Kasting]

On Fri, Jul 15, 2011 at 6:25 PM, Tantek Çelik wrote:

> ** Specs *and* publishers/consumers/implementations of rel-enclosure exist
> (see aforementioned wiki page).


The list on the wiki page, which I assume is non-exhaustive, is
extraordinarily uncompelling.


> And the name is based on re-using the existing term with the same semantic
> from the Atom spec.
>

Don't care.  Atom feeds and HTML pages are very different things.  Basically
I echo all of Tab's annoyances with this.

PK

Re: [whatwg] a rel=attachment

[Tantek Çelik]

Specs *and* publishers/consumers/implementations of rel-enclosure exist (see 
aforementioned wiki page). And the name is based on re-using the existing term 
with the same semantic from the Atom spec.

Sorry but the paint on that bikeshed dried a long time ago in an IETF working 
group far away. ;)

Tantek

-Original Message-
From: Peter Kasting 
Date: Fri, 15 Jul 2011 18:20:54 
To: 
Cc: Glenn Maynard; ; Jonas 
Sicking; whatwg; Darin 
Fisher; 
Subject: Re: [whatwg] a rel=attachment

On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik wrote:

> * existing rel="enclosure" spec - download the link when clicked/activated.


I object to rel="enclosure" purely on naming grounds.  It is completely
unintuitive.  I don't find the fact that a spec exists for it a compelling
reason to use it.  (Specs exist for lots of things, many of them bad.)

PK

Re: [whatwg] a rel=attachment

[Peter Kasting]

On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik wrote:

> * existing rel="enclosure" spec - download the link when clicked/activated.


I object to rel="enclosure" purely on naming grounds.  It is completely
unintuitive.  I don't find the fact that a spec exists for it a compelling
reason to use it.  (Specs exist for lots of things, many of them bad.)

PK

Re: [whatwg] a rel=attachment

[Tantek Çelik]

Agreed with Glenn, narrowing the semantic solves this problem neatly:

* filename="" attribute - what to name the file if saved by the user (by 
whatever means)
* existing rel="enclosure" spec - download the link when clicked/activated.

So the author can choose to do one, or the other, or both. Clean, simple, 
orthogonal.

Tantek
-Original Message-
From: Glenn Maynard 
Sender: whatwg-boun...@lists.whatwg.org
Date: Fri, 15 Jul 2011 19:43:45 
To: Jonas Sicking
Cc: whatwg; Darin Fisher; 

Subject: Re: [whatwg] a rel=attachment

2011/7/15 Jonas Sicking 

> It definitely is an interesting usecase that Glenn brought up about
> being able to specify a save-as name without otherwise modifying the
> behavior of a reference. However that seems like a much more rare
> usecase and so not the one we should optimize for.
>

Bear in mind that "optimize for" doesn't mean "support at all"; if
download=filename is used, it seems unlikely that there will ever be *any*
client-side way to supply the filename without implying attachment, which is
a very different thing than "not optimizing for it".

I don't feel strongly enough about this to press it further, but  also seems fairly clean, and avoids
combining parameters that really are orthogonal to one another.

-- 
Glenn Maynard

Re: [whatwg] a rel=attachment

[Glenn Maynard]

2011/7/15 Jonas Sicking 

> It definitely is an interesting usecase that Glenn brought up about
> being able to specify a save-as name without otherwise modifying the
> behavior of a reference. However that seems like a much more rare
> usecase and so not the one we should optimize for.
>

Bear in mind that "optimize for" doesn't mean "support at all"; if
download=filename is used, it seems unlikely that there will ever be *any*
client-side way to supply the filename without implying attachment, which is
a very different thing than "not optimizing for it".

I don't feel strongly enough about this to press it further, but  also seems fairly clean, and avoids
combining parameters that really are orthogonal to one another.

-- 
Glenn Maynard

Re: [whatwg] a rel=attachment

[Jonas Sicking]

2011/7/15 Darin Fisher :
> On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking  wrote:
>>
>> 2011/7/15 Ian Fette (イアンフェッティ) :
>> > 2011/7/15 Jonas Sicking 
>> >
>> >> 2011/7/14 Ian Fette (イアンフェッティ) :
>> >> > Many websites wish to offer a file for download, even though it could
>> >> > potentially be viewed inline (take images, PDFs, or word documents as
>> >> > an
>> >> > example). Traditionally the only way to achieve this is to set a
>> >> > content-disposition header. *However, sometimes it is not possible
>> >> > for
>> >> the
>> >> > page author to have control over the response headers sent by the
>> >> > server.*(A related example is offline apps, which may wish to provide
>> >> > the user with
>> >> > a way to "download" a file stored locally using the filesystem API
>> >> > but
>> >> again
>> >> > can't set any headers.) It would be nice to provide the page author
>> >> > with
>> >> a
>> >> > client side mechanism to trigger a download.
>> >> >
>> >> > After mulling this over with some application developers who are
>> >> > trying
>> >> to
>> >> > use this functionality, it seems like adding a "rel" attribute to the
>> >> > 
>> >> > tag would be a straightforward, minimally invasive way to address
>> >> > this
>> >> use
>> >> > case.  would indicate that the
>> >> > browser
>> >> > should treat this link as if the response came with a
>> >> content-disposition:
>> >> > attachment header, and offer to download/save the file for the user.
>> >>
>> >> We've discussed a different solution to the same problem at mozilla.
>> >> The solution we discussed was allowing FileSaver to in addition to
>> >> taking a blob argument, allow it to take a url argument.
>> >>
>> >> One concern which was brought up was the ability to cause the user to
>> >> download a file from a third party site. I.e. this would allow
>> >> evil.com to trick the user into downloading an email from the users
>> >> webmail, or download a page from their bank which contains all their
>> >> banking information. It might be easier to then trick the user into
>> >> re-uploading the saved file to evil.com since from a user's
>> >> perspective, it looked like the file came from evil.com
>> >>
>> >> Another possible attack goes something like:
>> >> 1. evil.com tricks the user into downloading sensitive data from
>> >> bank.com
>> >> 2. evil.com then asks the user to download a html from evil.com and
>> >> open the newly downloaded file
>> >> 3. the html file contains script which reads the contents from the
>> >> file downloaded from bank.com and sends it back to evil.com
>> >>
>> >> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>> >> the browser. However it's well known that users very often hit
>> >> whichever button they suspect will make the dialog go away, rather
>> >> than actually read the contents of the dialog.
>> >> Step 3 again requires the user to answer "yes" to a dialog displayed
>> >> by the browser in at least some browsers. Same caveat applies though.
>> >>
>> >> One very simple remedy to this would be to require CORS opt-in for
>> >> cross-site downloads. For same-site downloads no special opt-in would
>> >> be required of course.
>> >>
>> >> It's also possible that it would be ok to do this without any opt-ins
>> >> since there are a good number of actions that the user has to take in
>> >> all these scenarios. Definitely something that I'd be ok with
>> >> discussing with our security team.
>> >>
>> >> Tentatively I would feel safer with the CORS option though. And again,
>> >> for same-site downloads this isn't a problem at all, but I suspect
>> >> that in many cases the file to be downloaded is hosted on a separate
>> >> server.
>> >>
>> >> Oh, and I don't have strong opinions at this time on if rel=attachment
>> >> or FileSaver or both should be the way to trigger this functionality.
>> >>
>> >> / Jonas
>> >>
>> >
>> > I agree FileSaver is useful and has its place, but I don't think it
>> > negates
>> > the need for something like rel=attachment or download=filename. For
>> > one,
>> > FileSaver currently operates on blobs and as you mention would have to
>> > be
>> > modified to handle URLs or streams more generally. Second, it would
>> > force
>> > developers to use javascript links and/or set up click listeners and so
>> > forth, which could be annoying for users (losing the ability to copy the
>> > URL
>> > etc).
>>
>> As stated, I don't have a strong preference here. I suspect ultimately
>> we'll end up wanting both a markup based and an API based solution
>> here.
>>
>> > I guess the interesting question is "If the response would not have
>> > otherwise triggered a download, and the request is cross-origin, should
>> > that
>> > require CORS" and personally I would say no, this is still a remote
>> > enough
>> > concern that I would not worry about it.
>>
>> Indeed, that is the interesting question.
>>
>> I know that I would personally feel a lot more comfortable if the site
>> opted in to allo

Re: [whatwg] a rel=attachment

[Darin Fisher]

On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking  wrote:

> 2011/7/15 Ian Fette (イアンフェッティ) :
> > 2011/7/15 Jonas Sicking 
> >
> >> 2011/7/14 Ian Fette (イアンフェッティ) :
> >> > Many websites wish to offer a file for download, even though it could
> >> > potentially be viewed inline (take images, PDFs, or word documents as
> an
> >> > example). Traditionally the only way to achieve this is to set a
> >> > content-disposition header. *However, sometimes it is not possible for
> >> the
> >> > page author to have control over the response headers sent by the
> >> > server.*(A related example is offline apps, which may wish to provide
> >> > the user with
> >> > a way to "download" a file stored locally using the filesystem API but
> >> again
> >> > can't set any headers.) It would be nice to provide the page author
> with
> >> a
> >> > client side mechanism to trigger a download.
> >> >
> >> > After mulling this over with some application developers who are
> trying
> >> to
> >> > use this functionality, it seems like adding a "rel" attribute to the
> 
> >> > tag would be a straightforward, minimally invasive way to address this
> >> use
> >> > case.  would indicate that the browser
> >> > should treat this link as if the response came with a
> >> content-disposition:
> >> > attachment header, and offer to download/save the file for the user.
> >>
> >> We've discussed a different solution to the same problem at mozilla.
> >> The solution we discussed was allowing FileSaver to in addition to
> >> taking a blob argument, allow it to take a url argument.
> >>
> >> One concern which was brought up was the ability to cause the user to
> >> download a file from a third party site. I.e. this would allow
> >> evil.com to trick the user into downloading an email from the users
> >> webmail, or download a page from their bank which contains all their
> >> banking information. It might be easier to then trick the user into
> >> re-uploading the saved file to evil.com since from a user's
> >> perspective, it looked like the file came from evil.com
> >>
> >> Another possible attack goes something like:
> >> 1. evil.com tricks the user into downloading sensitive data from
> bank.com
> >> 2. evil.com then asks the user to download a html from evil.com and
> >> open the newly downloaded file
> >> 3. the html file contains script which reads the contents from the
> >> file downloaded from bank.com and sends it back to evil.com
> >>
> >> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> >> the browser. However it's well known that users very often hit
> >> whichever button they suspect will make the dialog go away, rather
> >> than actually read the contents of the dialog.
> >> Step 3 again requires the user to answer "yes" to a dialog displayed
> >> by the browser in at least some browsers. Same caveat applies though.
> >>
> >> One very simple remedy to this would be to require CORS opt-in for
> >> cross-site downloads. For same-site downloads no special opt-in would
> >> be required of course.
> >>
> >> It's also possible that it would be ok to do this without any opt-ins
> >> since there are a good number of actions that the user has to take in
> >> all these scenarios. Definitely something that I'd be ok with
> >> discussing with our security team.
> >>
> >> Tentatively I would feel safer with the CORS option though. And again,
> >> for same-site downloads this isn't a problem at all, but I suspect
> >> that in many cases the file to be downloaded is hosted on a separate
> >> server.
> >>
> >> Oh, and I don't have strong opinions at this time on if rel=attachment
> >> or FileSaver or both should be the way to trigger this functionality.
> >>
> >> / Jonas
> >>
> >
> > I agree FileSaver is useful and has its place, but I don't think it
> negates
> > the need for something like rel=attachment or download=filename. For one,
> > FileSaver currently operates on blobs and as you mention would have to be
> > modified to handle URLs or streams more generally. Second, it would force
> > developers to use javascript links and/or set up click listeners and so
> > forth, which could be annoying for users (losing the ability to copy the
> URL
> > etc).
>
> As stated, I don't have a strong preference here. I suspect ultimately
> we'll end up wanting both a markup based and an API based solution
> here.
>
> > I guess the interesting question is "If the response would not have
> > otherwise triggered a download, and the request is cross-origin, should
> that
> > require CORS" and personally I would say no, this is still a remote
> enough
> > concern that I would not worry about it.
>
> Indeed, that is the interesting question.
>
> I know that I would personally feel a lot more comfortable if the site
> opted in to allowing downloads of the resource in question. But it's
> quite possible that I'm overly paranoid.
>
> Though one thing to keep in mind is sites that explicitly state that a
> resource should *not* reach the users 

Re: [whatwg] a rel=attachment

[イアンフェッティ]

On Fri, Jul 15, 2011 at 1:15 PM, Julian Reschke wrote:

> On 2011-07-15 19:05, Ian Fette (イアンフェッティ) wrote:
>
>> ..
>>
>>> It also doesn't naturally help understanding that it's just poor man's
>>> Content-Disposition:**attachment. From this point of view, I like Ian's
>>> original proposal (rel=attachment) more.
>>>
>>>
>> Yes and no - both are sort of a poor man's Content-Disposition :) The
>> question is whether we need to handle filename, and the proposal of
>> download=filename at least maps content-disposition fully and compactly.
>> ...
>>
>
> Well, one difference is that C-D is under the control of the owner of the
> resource being linked to (ideally), while attributes set somewhere else
> might not.
>
> So there is a security-related aspect to this.
>
> Best regards, Julian
>

So, in the interest of making progress, what if we tried...

download=filename

for same origin it's always downloaded (includes filesystem api from that
origin)
for cross-origin it's downloaded if we get a positive CORS response and/or
we get a content-disposition attachment
for cross-origin if we don't get positive CORS response OR
content-disposition:attachment we don't download

We can always start conservative and broaden out.

-Ian

Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm

[Tab Atkins Jr.]

On Fri, Jul 15, 2011 at 1:18 PM, Ian Hickson  wrote:
> On Fri, 15 Jul 2011, Tab Atkins Jr. wrote:
>> I'll note, though, that the spec algorithm seems to be Firefox's
>> behavior, which differs in a few significant points from IE's.  In
>> particular, IE doesn't strip whitespace from the color, doesn't have the
>> same "truncate at 128 bytes" behavior, and doesn't recognize a 3-digit
>> hex color as a CSS color (instead parsing it with legacy rules).
>>
>> I doubt it matters too much, but was there any particular reason you
>> went with Firefox over IE here?
>
> See:
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=9847
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=12372
>
> Basically, it looks like IE does strip whitespace in some cases, the main
> difference is that it doesn't handle #123 the same as #112233. Since that
> would introduce an incompatibility with CSS, and since there was no
> interop on that case, I figured (based on input from Aryeh and dbaron) we
> might as well go with the sane behaviour.
>
> Interop isn't perfect here so there's not really any winning whatever we do.

That's fine.  I was just curious.  Like I said, WebKit now matches the
spec, so whatever.

~TJ

Re: [whatwg] Decimal comma in numeric input

[Ian Hickson]

On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
>
> I was surprised at seeing that the Finnish-language version of Google 
> Chrome 11 beta accepts a number with a comma, such as "4,2", in  type="number">. It silently converts the comma to a full stop, "4.2".
> 
> This looked like a useful feature at first sight, as decimal comma is 
> standard in Finnish as in most human languages. But this seems to 
> violate the rules, since  is defined as allowing a 
> "valid floating point number" (the definition of which clearly allows 
> FULL STOP as the only decimal separator) only and, moreover, there is 
> prescribed error processing: an error shall be returned, and the value 
> sanitization algorithm shall set the value to the empty string; ref.: 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/number-state.html#number-state
>
> So the Google Chrome implementation is in error here, right?

No, it's exactly right. You are confusing the UI with the submitted value.


On Thu, 14 Apr 2011, Old�ich Vete�n�k wrote:
> 
> I am afraid that if the decimal separator (in rendering) doesn't behave 
> the way people expect it to, it will mean web developers will have to 
> deal with clients saying "We wan't to be able to enter a comma." The 
> "dealing" might mean not using  at all, which is 
> something we might not want...

That is a risk, it is true.


On Fri, 15 Apr 2011, Aryeh Gregor wrote:
> 
> I didn't read the whole thread, but: authors with specific needs will 
> always want to roll their own inputs for most of these things, and 
> that's fine.  If  satisfies 80% of the use-cases, 
> that's fine.  As more authors start using the new input types, we'll get 
> feedback about what the most-requested features are, and we can consider 
> adding them at that time.  Trying to add more features to the new form 
> stuff is premature when we only have one really good implementation 
> (IMO: Gecko's), and that implementation is partial. The time to talk 
> about new features is when we have some amount of stability and 
> interoperability in existing features.

Indeed.


On Mon, 18 Apr 2011, Jukka K. Korpela wrote:
> 
> My original observation was that Google Chrome accepts a number with 
> decimal comma. It does that quite independently of the language. As far 
> as specifications go, it could just as well _only_ accept decimal comma. 
> Would that be perfectly suitable?

Per spec, yes.

Of course, it would be a pretty poor user experience. But that's just a UI 
issue. What it _should_ do is magically guess what the user meant and just 
do the right thing. Failing that, an approximation based on the user's 
preferences and locale, and the page's locale and style sheets.



On Thu, 14 Apr 2011, Jukka K. Korpela wrote:
> 
> In general with the new input types, we have the problem that when they 
> are not supported but degrade to , the user would 
> need instructions on data format, e.g. saying that decimal point be used 
> or that a color be specified as #hh - and these would look stupid 
> when they are not needed. But this can probably be handled reasonably 
> using scripts that test for the support first. Or maybe it would be more 
> robust, transitionally, to include the instructions and  type="text"> in markup, with client-side scripting then trying to set 
> the state to, say, "number", and when successful, removing the 
> instructions (or replacing them with some different instructions).

Indeed.

Much discussion on this topic happened when we started on this work in 
2004 and 2005, I highly recommend perusing the archives around that time.


On Thu, 14 Apr 2011, John Tamplin wrote:
> 
> The entire web application, which includes both client and server-side 
> code, must have the same idea about what locale the user is using.  If 
> the app provides a drop-down box or preference setting to choose a 
> different locale, as most localized apps do, the web browser has to be 
> using the same locale for any native locale processing it uses.  
> Otherwise, you run a serious risk of having incorrect data -- if a user 
> types "10,000" in a field when they think they are using a locale with a 
> comma as the decimal separator, does the app receive that as 1 or 
> 10.000?  If the app is running in en-US because the user requested it or 
> their system locale isn't supported by the app, and the browser sends 
> "10.000" as the value because the system locale is "de", then that is a 
> problem.

Indeed. To solve this, we need help from CSS. That's one of the reasons we 
created  in HTML.

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

Re: [whatwg] and elements' specification

[Ian Hickson]

On Mon, 11 Apr 2011, Tomasz Jamroszczak wrote:
> 
> Instead of making  inside  working as  inside 
> , we can throw away the  tag and make  work 
> like  element with form element.  There's no need for "open" 
> attribute, instead already existing "hidden" attribute can be used on 
> any HTML element. Clicking on  adds or removes "hidden" 
> attribute from element with given id.
> 
>   Here's default UA style:
> 
> summary {
>  display: list-item;
>  list-style-type: -o-disclosure-closed;
> }
> [hidden] {
>  display: none;
> }
> 
>   Here's example HTML:
> 
> This is summary. Click to show/close
> details.
> ...

I don't think this really captures the way disclosure widgets work. On 
platforms that support them natively, the disclosure widget, the summary, 
and the details are all one unit.


> Pros:
> 1. Simple to understand by web page authors - its representation and semantics
> play well together.

It's not clear to me that it's any clearer -- in particular, for="" is 
especially bug prone.


> 2. No XBL involved.

We'd still have to have a binding for the animation effects.


> 3. Nicely rendered by browsers not supporting  tag.

Isn't it the same as on browsers that don't support ?


> 4. No quirky rendering.

Not sure what you mean here. Why would anything have quirky rendering?


> 5. Less keywords to memorize by web authors, reusing existing keywords 
> in semantically correct way.

It trades  and  for , for="", id="", and 
hidden="". I'm not sure that's much simpler.


> Cons:
> 6. Error-prone for web developers using copy-and-paste method.

That's a big con. :-)


On Tue, 12 Apr 2011, Jukka K. Korpela wrote:
> 
> Just as  could have been defined to be paired with (by default) 
> its next sibling or, perhaps better, with the next input field, 
>  could be defined to be paired with its next sibling or, 
> perhaps better, with the next  element, by default.

This kind of magic association is, IMHO, very confusing for authors and 
not at all good language design.


> The element name "summary" is somewhat odd, and would appear even more 
> odd if liberated from appearing inside . This element is really 
> meant to be a control for rendering vs. not rendering the contents of 
> the  element, and its contents is just a label for the control. 
> The example at 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/interactive-elements.html#the-details-element
>  
> is accompanied with the note "In these examples, the summary really just 
> summarises what the controls can change, and not the actual values, 
> which is less than ideal." In reality, the example seems to correspond 
> to _normal_ expected use of , so the name "summary" is 
> misleading. Perhaps  would be better, but as it's really a 
> special kind of control only, how about ?

The idea is to encourage people to give a summary.

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

Re: [whatwg] , and styling

[Ian Hickson]

On Mon, 11 Apr 2011, Jukka K. Korpela wrote:
> Wilhelm Joys Andersen wrote:
> > 
> >"If there is no child summary element [of the details element], the
> >user agent should provide its own legend (e.g. "Details")." [1]
> > 
> > How exactly should this legend be provided?
> 
> Since the situation raises implementation difficulties, it would be best 
> to make the summary element required in a details element, i.e. to force 
> authors to provide a summary.

It is required. That doesn't force authors to do anything, though.


> But it appears to be an undue burden to require browsers to provide a 
> default legend, which would need to be different for different 
> languages.

Making it required doesn't help user agents deal with pages where it is 
omitted.


> A key issue with the details element is that it does not degrade well. 
> It's difficult to say how much this could be improved. In any case, the 
> fact that the details themselves - the content of the details element 
> excluding the summary element - do not constitute an element makes 
> things rather difficult.

It's easy to wrap them in an element for fallback purposes.

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

Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm

[Ian Hickson]

On Fri, 15 Jul 2011, Tab Atkins Jr. wrote:
> 
> I'll note, though, that the spec algorithm seems to be Firefox's 
> behavior, which differs in a few significant points from IE's.  In 
> particular, IE doesn't strip whitespace from the color, doesn't have the 
> same "truncate at 128 bytes" behavior, and doesn't recognize a 3-digit 
> hex color as a CSS color (instead parsing it with legacy rules).
> 
> I doubt it matters too much, but was there any particular reason you 
> went with Firefox over IE here?

See:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=9847
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12372

Basically, it looks like IE does strip whitespace in some cases, the main 
difference is that it doesn't handle #123 the same as #112233. Since that 
would introduce an incompatibility with CSS, and since there was no 
interop on that case, I figured (based on input from Aryeh and dbaron) we 
might as well go with the sane behaviour.

Interop isn't perfect here so there's not really any winning whatever we do.

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

Re: [whatwg] a rel=attachment

[Julian Reschke]

On 2011-07-15 19:05, Ian Fette (イアンフェッティ) wrote:

..

It also doesn't naturally help understanding that it's just poor man's
Content-Disposition:attachment. From this point of view, I like Ian's
original proposal (rel=attachment) more.



Yes and no - both are sort of a poor man's Content-Disposition :) The
question is whether we need to handle filename, and the proposal of
download=filename at least maps content-disposition fully and compactly.
...


Well, one difference is that C-D is under the control of the owner of 
the resource being linked to (ideally), while attributes set somewhere 
else might not.


So there is a security-related aspect to this.

Best regards, Julian

Re: [whatwg] a rel=attachment

[Jonas Sicking]

2011/7/15 Ian Fette (イアンフェッティ) :
> 2011/7/15 Jonas Sicking 
>
>> 2011/7/14 Ian Fette (イアンフェッティ) :
>> > Many websites wish to offer a file for download, even though it could
>> > potentially be viewed inline (take images, PDFs, or word documents as an
>> > example). Traditionally the only way to achieve this is to set a
>> > content-disposition header. *However, sometimes it is not possible for
>> the
>> > page author to have control over the response headers sent by the
>> > server.*(A related example is offline apps, which may wish to provide
>> > the user with
>> > a way to "download" a file stored locally using the filesystem API but
>> again
>> > can't set any headers.) It would be nice to provide the page author with
>> a
>> > client side mechanism to trigger a download.
>> >
>> > After mulling this over with some application developers who are trying
>> to
>> > use this functionality, it seems like adding a "rel" attribute to the 
>> > tag would be a straightforward, minimally invasive way to address this
>> use
>> > case.  would indicate that the browser
>> > should treat this link as if the response came with a
>> content-disposition:
>> > attachment header, and offer to download/save the file for the user.
>>
>> We've discussed a different solution to the same problem at mozilla.
>> The solution we discussed was allowing FileSaver to in addition to
>> taking a blob argument, allow it to take a url argument.
>>
>> One concern which was brought up was the ability to cause the user to
>> download a file from a third party site. I.e. this would allow
>> evil.com to trick the user into downloading an email from the users
>> webmail, or download a page from their bank which contains all their
>> banking information. It might be easier to then trick the user into
>> re-uploading the saved file to evil.com since from a user's
>> perspective, it looked like the file came from evil.com
>>
>> Another possible attack goes something like:
>> 1. evil.com tricks the user into downloading sensitive data from bank.com
>> 2. evil.com then asks the user to download a html from evil.com and
>> open the newly downloaded file
>> 3. the html file contains script which reads the contents from the
>> file downloaded from bank.com and sends it back to evil.com
>>
>> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
>> the browser. However it's well known that users very often hit
>> whichever button they suspect will make the dialog go away, rather
>> than actually read the contents of the dialog.
>> Step 3 again requires the user to answer "yes" to a dialog displayed
>> by the browser in at least some browsers. Same caveat applies though.
>>
>> One very simple remedy to this would be to require CORS opt-in for
>> cross-site downloads. For same-site downloads no special opt-in would
>> be required of course.
>>
>> It's also possible that it would be ok to do this without any opt-ins
>> since there are a good number of actions that the user has to take in
>> all these scenarios. Definitely something that I'd be ok with
>> discussing with our security team.
>>
>> Tentatively I would feel safer with the CORS option though. And again,
>> for same-site downloads this isn't a problem at all, but I suspect
>> that in many cases the file to be downloaded is hosted on a separate
>> server.
>>
>> Oh, and I don't have strong opinions at this time on if rel=attachment
>> or FileSaver or both should be the way to trigger this functionality.
>>
>> / Jonas
>>
>
> I agree FileSaver is useful and has its place, but I don't think it negates
> the need for something like rel=attachment or download=filename. For one,
> FileSaver currently operates on blobs and as you mention would have to be
> modified to handle URLs or streams more generally. Second, it would force
> developers to use javascript links and/or set up click listeners and so
> forth, which could be annoying for users (losing the ability to copy the URL
> etc).

As stated, I don't have a strong preference here. I suspect ultimately
we'll end up wanting both a markup based and an API based solution
here.

> I guess the interesting question is "If the response would not have
> otherwise triggered a download, and the request is cross-origin, should that
> require CORS" and personally I would say no, this is still a remote enough
> concern that I would not worry about it.

Indeed, that is the interesting question.

I know that I would personally feel a lot more comfortable if the site
opted in to allowing downloads of the resource in question. But it's
quite possible that I'm overly paranoid.

Though one thing to keep in mind is sites that explicitly state that a
resource should *not* reach the users disk. This is today often done
using "Cache-Control: no-store". Seems scary to allow such content to
be saved based on a cross-site request.

/ Jonas

Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm

[Tab Atkins Jr.]

On Fri, Jul 15, 2011 at 11:57 AM, L. David Baron  wrote:
> On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote:
>> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we
>> just try to parse it as a CSS color.
>
> As I pointed out in
> http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html
> this isn't compatible with doing the following simultaneously:
>  * using the algorithm given, which converts the values to colors at
>   parse time
>  * correctly handling dynamic changes of system appearance for the
>   system color values
>
> Correctly handling dynamic changes of system appearance here would
> be a significant amount of work even if the algorithm here changed,
> and I'd really rather not add that support for a legacy feature, nor
> would I like to have an inconsistency between CSS and HTML as to
> whether system colors are dynamically updated.

WebKit now matches the spec (and Firefox) anyway, so the issue is moot.

~TJ

Re: [whatwg] a rel=attachment

[イアンフェッティ]

2011/7/15 Jonas Sicking 

> 2011/7/14 Ian Fette (イアンフェッティ) :
> > Many websites wish to offer a file for download, even though it could
> > potentially be viewed inline (take images, PDFs, or word documents as an
> > example). Traditionally the only way to achieve this is to set a
> > content-disposition header. *However, sometimes it is not possible for
> the
> > page author to have control over the response headers sent by the
> > server.*(A related example is offline apps, which may wish to provide
> > the user with
> > a way to "download" a file stored locally using the filesystem API but
> again
> > can't set any headers.) It would be nice to provide the page author with
> a
> > client side mechanism to trigger a download.
> >
> > After mulling this over with some application developers who are trying
> to
> > use this functionality, it seems like adding a "rel" attribute to the 
> > tag would be a straightforward, minimally invasive way to address this
> use
> > case.  would indicate that the browser
> > should treat this link as if the response came with a
> content-disposition:
> > attachment header, and offer to download/save the file for the user.
>
> We've discussed a different solution to the same problem at mozilla.
> The solution we discussed was allowing FileSaver to in addition to
> taking a blob argument, allow it to take a url argument.
>
> One concern which was brought up was the ability to cause the user to
> download a file from a third party site. I.e. this would allow
> evil.com to trick the user into downloading an email from the users
> webmail, or download a page from their bank which contains all their
> banking information. It might be easier to then trick the user into
> re-uploading the saved file to evil.com since from a user's
> perspective, it looked like the file came from evil.com
>
> Another possible attack goes something like:
> 1. evil.com tricks the user into downloading sensitive data from bank.com
> 2. evil.com then asks the user to download a html from evil.com and
> open the newly downloaded file
> 3. the html file contains script which reads the contents from the
> file downloaded from bank.com and sends it back to evil.com
>
> Step 1 and 2 require the user to answer "yes" to a dialog displayed by
> the browser. However it's well known that users very often hit
> whichever button they suspect will make the dialog go away, rather
> than actually read the contents of the dialog.
> Step 3 again requires the user to answer "yes" to a dialog displayed
> by the browser in at least some browsers. Same caveat applies though.
>
> One very simple remedy to this would be to require CORS opt-in for
> cross-site downloads. For same-site downloads no special opt-in would
> be required of course.
>
> It's also possible that it would be ok to do this without any opt-ins
> since there are a good number of actions that the user has to take in
> all these scenarios. Definitely something that I'd be ok with
> discussing with our security team.
>
> Tentatively I would feel safer with the CORS option though. And again,
> for same-site downloads this isn't a problem at all, but I suspect
> that in many cases the file to be downloaded is hosted on a separate
> server.
>
> Oh, and I don't have strong opinions at this time on if rel=attachment
> or FileSaver or both should be the way to trigger this functionality.
>
> / Jonas
>

I agree FileSaver is useful and has its place, but I don't think it negates
the need for something like rel=attachment or download=filename. For one,
FileSaver currently operates on blobs and as you mention would have to be
modified to handle URLs or streams more generally. Second, it would force
developers to use javascript links and/or set up click listeners and so
forth, which could be annoying for users (losing the ability to copy the URL
etc).

I don't understand why we would add CORS as a requirement for this. You can
already link to things from another origin, the fact that they may be
downloaded rather than displayed and then the user somehow tricked to upload
them seems like a rather remote concern...  if I now want to link to a
StarCraft 2 patch and give the browser a hint that it's a download (so that
maybe in the future the browser might be able to have more intelligent UI
when I hover over it, or at least not pop up a new window that just then
spawns a download) requiring CORS seems quite overkill, especially if the
response would have triggered a download anyways.

I guess the interesting question is "If the response would not have
otherwise triggered a download, and the request is cross-origin, should that
require CORS" and personally I would say no, this is still a remote enough
concern that I would not worry about it.

-Ian

Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm

[L. David Baron]

On Friday 2011-04-08 13:54 -0700, Tab Atkins Jr. wrote:
> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we
> just try to parse it as a CSS color.

As I pointed out in
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-May/026449.html
this isn't compatible with doing the following simultaneously:
 * using the algorithm given, which converts the values to colors at
   parse time
 * correctly handling dynamic changes of system appearance for the
   system color values

Correctly handling dynamic changes of system appearance here would
be a significant amount of work even if the algorithm here changed,
and I'd really rather not add that support for a legacy feature, nor
would I like to have an inconsistency between CSS and HTML as to
whether system colors are dynamically updated.

-David

-- 
𝄞   L. David Baron http://dbaron.org/   𝄂
𝄢   Mozilla Corporation   http://www.mozilla.com/   𝄂

Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm

[Tab Atkins Jr.]

On Fri, Jul 15, 2011 at 11:43 AM, Ian Hickson  wrote:
> On Fri, 8 Apr 2011, Tab Atkins Jr. wrote:
>> In the legacy color parsing algorithm
>> ,
>> steps 5 and 6 concern CSS color names - 'transparent' should raise an
>> error, and color names should be respected.  All other CSS color
>> syntaxes, though, such as the rgba() function, are just passed through
>> to the rest of the algorithm and appropriately mangled.
>>
>> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we just
>> try to parse it as a CSS color.  If we succeed, we use that color.
>> Otherwise, we chunk it into the legacy parsing algorithm and do what the
>> spec says.  So, for example, foo is
>> actually displayed as partially-transparent red instead of dark green
>> (following the algorithm mangles the string into #050).
>>
>> Could we change those two steps to just say "If keyword is a valid CSS
>> color value, then return the simple color corresponding to that value."?
>> (I guess, to fully match Webkit, you need to change the definition of
>> "simple color" to take alpha into account.)
>
> On Fri, 8 Apr 2011, Boris Zbarsky wrote:
>>
>> But it does match other UAs
>>
>> Do you have web compat data here?
>>
>> I would much rather stick with color parsing as defined in HTML4 modulo
>> the "not a color name, treat it as a hex color even if it doesn't start
>> with '#'" quirk than replace the "is it a color name?" test with a "does
>> it parse as a CSS color?" test.
>
> On Wed, 13 Apr 2011, Philip Taylor wrote:
>>
>> I don't know if this is relevant or useful but anyway:
>> http://philip.html5.org/data/font-colors.txt has some basic data for
>>  values, http://philip.html5.org/data/bgcolors.txt for > bgcolor>. (Each line is the number of URLs that value was found on (from
>> the set from http://philip.html5.org/data/dotbot-20090424.txt), followed
>> by the XML-encoded value.)
>
> Looks like there are values that would be affected by this change.
>
> I've left it as-is. I think compat here is vastly more important than
> adding new capabilities, since this is only used for legacy features.

I recently patched WebKit to match the spec anyway, so that's fine.  ^_^

I'll note, though, that the spec algorithm seems to be Firefox's
behavior, which differs in a few significant points from IE's.  In
particular, IE doesn't strip whitespace from the color, doesn't have
the same "truncate at 128 bytes" behavior, and doesn't recognize a
3-digit hex color as a CSS color (instead parsing it with legacy
rules).

I doubt it matters too much, but was there any particular reason you
went with Firefox over IE here?

~TJ

Re: [whatwg] Accept full CSS colors in the legacy color parsing algorithm

[Ian Hickson]

On Fri, 8 Apr 2011, Tab Atkins Jr. wrote:
>
> In the legacy color parsing algorithm 
> ,
>  
> steps 5 and 6 concern CSS color names - 'transparent' should raise an 
> error, and color names should be respected.  All other CSS color 
> syntaxes, though, such as the rgba() function, are just passed through 
> to the rest of the algorithm and appropriately mangled.
> 
> This doesn't match Webkit's behavior.  Instead of steps 5 and 6, we just 
> try to parse it as a CSS color.  If we succeed, we use that color.  
> Otherwise, we chunk it into the legacy parsing algorithm and do what the 
> spec says.  So, for example, foo is 
> actually displayed as partially-transparent red instead of dark green 
> (following the algorithm mangles the string into #050).
> 
> Could we change those two steps to just say "If keyword is a valid CSS 
> color value, then return the simple color corresponding to that value."?  
> (I guess, to fully match Webkit, you need to change the definition of 
> "simple color" to take alpha into account.)

On Fri, 8 Apr 2011, Boris Zbarsky wrote:
> 
> But it does match other UAs
> 
> Do you have web compat data here?
> 
> I would much rather stick with color parsing as defined in HTML4 modulo 
> the "not a color name, treat it as a hex color even if it doesn't start 
> with '#'" quirk than replace the "is it a color name?" test with a "does 
> it parse as a CSS color?" test.

On Wed, 13 Apr 2011, Philip Taylor wrote:
> 
> I don't know if this is relevant or useful but anyway: 
> http://philip.html5.org/data/font-colors.txt has some basic data for 
>  values, http://philip.html5.org/data/bgcolors.txt for  bgcolor>. (Each line is the number of URLs that value was found on (from 
> the set from http://philip.html5.org/data/dotbot-20090424.txt), followed 
> by the XML-encoded value.)

Looks like there are values that would be affected by this change.

I've left it as-is. I think compat here is vastly more important than 
adding new capabilities, since this is only used for legacy features.

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

Re: [whatwg] a rel=attachment

[イアンフェッティ]

On Fri, Jul 15, 2011 at 11:24 AM, Glenn Maynard  wrote:

> 2011/7/15 Ian Fette (イアンフェッティ) 
>
> Yes and no - both are sort of a poor man's Content-Disposition :) The
>> question is whether we need to handle filename, and the proposal of
>> download=filename at least maps content-disposition fully and compactly.
>>
>
> Not fully; it lacks an equivalent for "Content-Disposition: inline;
> filename=file".
>
>
Ok, not fully, but at least covering what I would view to be the important
use cases that are actually used in practice.


> --
> Glenn Maynard
>
>

Re: [whatwg] a rel=attachment

[Jonas Sicking]

2011/7/14 Ian Fette (イアンフェッティ) :
> Many websites wish to offer a file for download, even though it could
> potentially be viewed inline (take images, PDFs, or word documents as an
> example). Traditionally the only way to achieve this is to set a
> content-disposition header. *However, sometimes it is not possible for the
> page author to have control over the response headers sent by the
> server.*(A related example is offline apps, which may wish to provide
> the user with
> a way to "download" a file stored locally using the filesystem API but again
> can't set any headers.) It would be nice to provide the page author with a
> client side mechanism to trigger a download.
>
> After mulling this over with some application developers who are trying to
> use this functionality, it seems like adding a "rel" attribute to the 
> tag would be a straightforward, minimally invasive way to address this use
> case.  would indicate that the browser
> should treat this link as if the response came with a content-disposition:
> attachment header, and offer to download/save the file for the user.

We've discussed a different solution to the same problem at mozilla.
The solution we discussed was allowing FileSaver to in addition to
taking a blob argument, allow it to take a url argument.

One concern which was brought up was the ability to cause the user to
download a file from a third party site. I.e. this would allow
evil.com to trick the user into downloading an email from the users
webmail, or download a page from their bank which contains all their
banking information. It might be easier to then trick the user into
re-uploading the saved file to evil.com since from a user's
perspective, it looked like the file came from evil.com

Another possible attack goes something like:
1. evil.com tricks the user into downloading sensitive data from bank.com
2. evil.com then asks the user to download a html from evil.com and
open the newly downloaded file
3. the html file contains script which reads the contents from the
file downloaded from bank.com and sends it back to evil.com

Step 1 and 2 require the user to answer "yes" to a dialog displayed by
the browser. However it's well known that users very often hit
whichever button they suspect will make the dialog go away, rather
than actually read the contents of the dialog.
Step 3 again requires the user to answer "yes" to a dialog displayed
by the browser in at least some browsers. Same caveat applies though.

One very simple remedy to this would be to require CORS opt-in for
cross-site downloads. For same-site downloads no special opt-in would
be required of course.

It's also possible that it would be ok to do this without any opt-ins
since there are a good number of actions that the user has to take in
all these scenarios. Definitely something that I'd be ok with
discussing with our security team.

Tentatively I would feel safer with the CORS option though. And again,
for same-site downloads this isn't a problem at all, but I suspect
that in many cases the file to be downloaded is hosted on a separate
server.

Oh, and I don't have strong opinions at this time on if rel=attachment
or FileSaver or both should be the way to trigger this functionality.

/ Jonas

Re: [whatwg] Geolocation - Browser usability issues with regards to asking user permission

[Ian Hickson]

On Wed, 6 Apr 2011, Andrew de Andrade wrote:
>
> Depending on the browser and device, permission will be asked either in 
> a bar across the top of the browser (Firefox and Chrome on the desktop) 
> or with a modal dialog (Safari on the desktop and on the iPhone). [...]
> 
> As the creator of a site that uses geolocation, these two different 
> implementations of the permissions dialog concerns me. In my tests with 
> users, I've noticed that with Firefox and Chrome, many users don't 
> notice the bar across the top and thus features of the web application 
> end up crippled because the app doesn't have access to the user's 
> location and this degrades the user experience.

As with all user interface choices browser vendors have to make, some work 
better than others. Different goals can result in different choices, too; 
for example, it might be the goal of one user agent to make it clear to 
the user that they should share their location, while another user agent 
might decide that it's better to the user have to explicitly look for a 
way to share their location, since then they won't do it by mistake.


> [Proposal:]
> 2) The HTML5 specification defines how browsers should implement this 
> consistently --> either a bar across the top OR modal dialog box, but 
> not both.

It's user interface: we're not going to specify it. This is the kind of 
thing browsers can compete on.

In any case, it's impractical: If we said it should be a non-modal 
graphical bar, how would a browser that doesn't have a screen but instead 
reads everything out using speech synthesis do it? If we said it had to be 
a red icon, what about browsers targeting cultures where the colour "red" 
is considered offensive? If we said that the user agent should offer the 
option to give the user's location or no location, what about users that 
want to lie about their location? There are just too many possible 
variables here to define the UI, even if we wanted to.


> 3) Each browser chooses their default interface approach (bar or modal 
> dialog), but the Geolocation API specification allows for the webapp 
> developer to override this default.

This doesn't work because those options might not be available in the 
first place. What if the operating system the browser is running on 
doesn't have the concept of a modal dialog? What if it's a line-driven 
text browser, with no concept of a non-modal alert?


> Those apps for which location is essencial for the user experience can 
> choose to always display a modal dialog box before the user proceeds to 
> use the webapp.

What if the user never wants a dialog?


On Wed, 6 Apr 2011, Peter Kasting wrote:
> 
> If users don't notice or understand the geolocation prompts in a 
> particular browser, I think the appropriate response is to provide 
> feedback to the browser vendor that users are not successfully 
> navigating their UI.

Indeed.


On Fri, 8 Apr 2011, Rich Tibbett wrote:
> Biju wrote:
> > What I want from browser vendors is make 
> > navigator.geolocation.getCurrentPosition and 
> > navigator.geolocation.watchPosition ONLY callable from a CLICK event. 
> > I thought we all learned lesson from window.open popups
> 
> window.open is still entirely underspecified in standards when it comes 
> to its behavior in trusted vs. non-trusted click event invocation. The 
> first thing somebody would need to is document how window.open works 
> according to different modes of invocation. Then at least we would have 
> a model to be able to discuss for other similar scenarios.

The HTML spec defines this, but in a somewhat wishy-washy way intended to 
allow UAs to experiment with different constraints. Is this something that 
needs defining more precisely?

In general I haven't specified this in detail because the model of 
trusting user clicks doesn't work (due to clickjacking attacks).

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

Re: [whatwg] a rel=attachment

[Glenn Maynard]

2011/7/15 Ian Fette (イアンフェッティ) 

> Yes and no - both are sort of a poor man's Content-Disposition :) The
> question is whether we need to handle filename, and the proposal of
> download=filename at least maps content-disposition fully and compactly.
>

Not fully; it lacks an equivalent for "Content-Disposition: inline;
filename=file".

-- 
Glenn Maynard

Re: [whatwg] PeerConnection, MediaStream, getUserMedia(), and other feedback

[Shwetank Dixit]

On Thu, 14 Jul 2011 18:53:00 +0530, timeless  wrote:


I'd expect a web app to have no idea about device camera
specifications and thus to not be able to properly specify a flash
duration. I don't see how such a thing is valuable.

If a user is in a movie theater, or a museum, it's quite likely they
won't notice a web app is forcing a flash. Let the user control flash
through a useragent only or host application only mode. I believe the
hazards of exposing flash duration outweigh any benefits. The only
application class I know of built using control of camera flash is
"flash-light", and that's both a hack and not guaranteed to be
workable for all possible flash technologies.


Just like, just allowing the web app to use the camera as it is will not  
make sense, and presumably, user agents will implement a authorization by  
the user before the app gains access to the camera (something like 'This  
application requests access to the camera. Allow for now/Always  
Allow/Never Allow/Close' just like you do in geolocation right now) ...  
just like that, you could do it for flash, where the app only gains access  
to it if the user allows it. If that is the implementation, i do not think  
there would be much hazards in allowing flash access.


Apart from helping capture images/video in low light conditions, there are  
a few other use cases for flash such as the flash light thing you  
mentioned, as well as a possible S.O.S type app.


I'm fine if the consensus is that the device/user agent will handle the  
issue of flash by showing some sort of control where the user can click  
between 'flash on/off/auto'. That will cover *most* of the use cases,  
which is recording images/video in low light conditions. If so, then it  
might be good to specify that somewhere in the spec just to make things a  
bit clearer?




On 7/14/11, Shwetank Dixit  wrote:

On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson  wrote:




Another question is flash. As far as I have seen, there seems to be no
option to specify whether the camera needs to use flash or not. Is  
this

decision left up to the device? (If someone is making an app which is
just clicking a picture of the person, then it would be nice to have  
the

camera use flash in low light conditions).

getUserMedia() returns a video stream, so it wouldn't use a flash.


Wouldn't it make sense to have a provision for flash separately then? I
think a lot of apps would like just a picture instead of video, and in
those cases, flash would be required. Maybe a seperate provision in the
spec which defines whether to use flash, and if so, for how many
miliseconds. Is that doable?
--
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Core Engineering Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary email client: http://www.opera.com/mail/






--
Shwetank Dixit
Web Evangelist,
Site Compatibility / Developer Relations / Core Engineering Group
Member - W3C Mobile Web for Social Development (MW4D) Group
Member - Web Standards Project (WaSP) - International Liaison Group
Opera Software - www.opera.com

Using Opera's revolutionary email client: http://www.opera.com/mail/

Re: [whatwg] a rel=attachment

[イアンフェッティ]

On Fri, Jul 15, 2011 at 9:08 AM, Alexey Proskuryakov  wrote:

>
> 14.07.2011, в 13:59, Tab Atkins Jr. написал(а):
>
> >> re-using the "enclosure" term from the Atom format (thus minimal
> bikeshedding)
> >
> > "enclosure" is a completely opaque name.  I have no idea how it is
> > meant to refer to "download the linked resource instead of navigating
> > to it".  If I think about it in terms of Atom I can *kinda* imagine
> > it, but it feels like a bad term there, and it would be an even worse
> > term in HTML.
> >
> > A boolean @download attribute is much clearer and more direct.  If
> > you're using @download to name the file as well, then adding a @rel
> > value is unneeded.
>
>
> What meaning will this attribute have on a platform that simply doesn't
> expose the notion of a file?
>

I would assume the platform would treat  the same way as if it had followed a link to blah.php
and received a Content-Disposition: attachment; filename=blah.pdf header.
It's not introducing any new problems, and I would expect the behaviour to
be consistent.


>
> I think that this attribute could be quite confusing, and it will likely
> become more confusing with time, as more platforms arise that have creative
> ways of presenting data to users.
>
>
I agree we don't want to prevent creative UI in the future / platforms that
don't necessarily deal with files in the traditional way. However I don't
think this actually introduces any new problems, it just allows something
that can already be specified in server-side code to be specified in
client-side code.


> It also doesn't naturally help understanding that it's just poor man's
> Content-Disposition:attachment. From this point of view, I like Ian's
> original proposal (rel=attachment) more.
>

Yes and no - both are sort of a poor man's Content-Disposition :) The
question is whether we need to handle filename, and the proposal of
download=filename at least maps content-disposition fully and compactly.


>
> - WBR, Alexey Proskuryakov
>
>

Re: [whatwg] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

On 7/15/11, Jukka K. Korpela  wrote:
> Should it? Even when the book has no URL? If you expect urn:isbn:… to
> work anytime soon in any significant browser, you’re very optimistic.
>
Wikipedia and Amazon (among others) have all the mechanisms already.
Such ISBN handlers could even be registered by JavaScripts.

> Browsers currently treat  just like  (except that it has a
> different name). There is no sign of advance functionality emerging. It
> does not matter how usable something is when it does not exist at all.
>
 is not nearly as useful as @cite.

> I forgot to mention that the ISBN number should be included visibly in
> the credits, especially because it is usually the simplest and sometimes
> the only reasonable way to identify a book unambiguously (and can be
> copied and pasted into a suitable bibliographic search form). It’s
So you're saying that users should rather search for the term ISBN,
select the following number, copy it, remove/add hyphens as necessary
and then paste it to a suitable bibliographic search form? Instead of
registering a suitable bibliographic search form once, and having the
user agent do the hard work in a click or two?

> metadata, but metadata that need not and should not be hidden but
> presented in textual content. At most it might be included into elements
> that are not initially displayed but become available when the user so
> requests—possibly some day via the  element if browsers
> implement it well.
>
But browsers need to be told that that number close to the quotation
is an ISBN. And if you always hide it in , user agents may be
compelled to expand it by default, making it unusable for e.g. hiding
answers to a quiz.

> The cite attribute in  should really be moved to the
> non-recommended part of HTML. It hardly ever serves a useful purpose,
> and it tends to mislead authors into including important information
> _only_ in the attribute, which has no browser support worth mentioning
> (despite having been in HTML for over 13 years).
>
Before you said  was implemented as , and your point is that
the cite attribute is useless? They're barely related, @cite contains
an URI, that an user agent might be able to use in an automated
fashion.  contains a human-readable name of a work. That'll
rarely be machine-readable.

Re: [whatwg] The blockquote element spec vs common quoting practices

[Bjartur Thorlacius]

On 7/15/11, Jukka K. Korpela  wrote:
> 14.07.2011 16:10, Bjartur Thorlacius wrote:
>> I don't think author names are allowed in  in HTML 5.
>
> They aren’t, but HTML5 linters (“validators”) won’t report the issue, as
> they don’t understand the meanings of words.
That doesn't make it any more valid.

Re: [whatwg] a rel=attachment

[Alexey Proskuryakov]

14.07.2011, в 13:59, Tab Atkins Jr. написал(а):

>> re-using the "enclosure" term from the Atom format (thus minimal 
>> bikeshedding)
> 
> "enclosure" is a completely opaque name.  I have no idea how it is
> meant to refer to "download the linked resource instead of navigating
> to it".  If I think about it in terms of Atom I can *kinda* imagine
> it, but it feels like a bad term there, and it would be an even worse
> term in HTML.
> 
> A boolean @download attribute is much clearer and more direct.  If
> you're using @download to name the file as well, then adding a @rel
> value is unneeded.


What meaning will this attribute have on a platform that simply doesn't expose 
the notion of a file?

I think that this attribute could be quite confusing, and it will likely become 
more confusing with time, as more platforms arise that have creative ways of 
presenting data to users. 

It also doesn't naturally help understanding that it's just poor man's 
Content-Disposition:attachment. From this point of view, I like Ian's original 
proposal (rel=attachment) more.

- WBR, Alexey Proskuryakov

Re: [whatwg] The blockquote element spec vs common quoting practices

[Jukka K. Korpela]

14.07.2011 16:10, Bjartur Thorlacius wrote:


Þann fim 14.júl 2011 11:09, skrifaði Jukka K. Korpela:

14.07.2011 13:49, Karl Dubost wrote:


Sur un pétale de lotus, j'écrivis ces quelques vers :
«Même si l'on vient me chercher
Comment, abandonnant la rosée
De pareil lotus,
Retournerai-je
Dans le monde changeant et frivole ? »
et j'envoyais ce pétale.

Shonagon, Sei,
Notes de chevet, p.64, Unesco, NRF, 1966.


Yes, but for usability reasons the cite[@class=titre] should represent a
hyperlink to the cited book.


Should it? Even when the book has no URL? If you expect urn:isbn:… to 
work anytime soon in any significant browser, you’re very optimistic.


Browsers currently treat  just like  (except that it has a 
different name). There is no sign of advance functionality emerging. It 
does not matter how usable something is when it does not exist at all.



Is an user agent to find a cite descendant
of  and make it represent a hyperlink to the cited resource
(identified by the URI in the cite attribute of blockquote)?


That would be rather pointless.

If there is an online resource to link to, you can simply make the title 
a link to it, explicitly. Then you can also style the link to desired, 
and it will stand out as a link (unless the author styles it badly).


I forgot to mention that the ISBN number should be included visibly in 
the credits, especially because it is usually the simplest and sometimes 
the only reasonable way to identify a book unambiguously (and can be 
copied and pasted into a suitable bibliographic search form). It’s 
metadata, but metadata that need not and should not be hidden but 
presented in textual content. At most it might be included into elements 
that are not initially displayed but become available when the user so 
requests—possibly some day via the  element if browsers 
implement it well.


The cite attribute in  should really be moved to the 
non-recommended part of HTML. It hardly ever serves a useful purpose, 
and it tends to mislead authors into including important information 
_only_ in the attribute, which has no browser support worth mentioning 
(despite having been in HTML for over 13 years).



(I don't like to nitpick on the author identification, but wouldn’t
Shōnagon, Sei be better?)

I don't think author names are allowed in  in HTML 5.


They aren’t, but HTML5 linters (“validators”) won’t report the issue, as 
they don’t understand the meanings of words.


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

Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?

[Julian Reschke]

On 2011-07-14 17:01, Jonas Sicking wrote:

...
True. I would be fine with removing the plugin requirement. Or
changing it such that it states that plugins can only be loaded if
it's done in a manner that ensures that all other requirements are
still fulfilled. Or just dealing with this once there actually are
plugins and plugin APIs which could be loaded while still fulfilling
the other requirements.
...


Well, the spec is in W3C LC. So if we think this requirement needs to be 
rephrased then it should be brought up as a problem.


Best regards, Julian

Re: [whatwg] proposal: extend to markup durations

[Bruce Lawson]

On Fri, 15 Jul 2011 03:17:07 +0100, Tantek Çelik   
wrote:


On Thu, Jul 14, 2011 at 14:51, Tab Atkins Jr.   
wrote:

On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson  wrote:




I haven't studied the above yet, but I just wanted to bring up a trial
balloon for a possible alternative solution: drop  and replace it
with a generic solution.

There are several use cases for :

A. Easier styling of dates and times from CSS.

B. A way to mark up the publication date/time for an article (e.g. for
conversion to Atom).

C. A way to mark up machine-readable times and dates for use in
Microformats or microdata.

Use cases A and B do not seem to have much traction.


I think it's too early to tell whether there is "traction". I wonder  
whether any of the new semantics (article, nav, section, header etc) have  
much traction yet, simply because they don't yet have many obvious  
"consumers" - eg, browsers, crawlers, search engines [as far as we know]  
aren't making use of them yet. Also, developers are still understandably  
getting used to the more whizzbang aspects of HTML like canvas, video etc.





Proposal: we dump use cases A and B, and pivot  on use case C,
changing it to  and making it like the  for  
machine-readable

data, primarily for use by Microformats and HTML's microdata feature.


I disagree.

Opera has just begun to support  in Opera 11.50 (demo  
http://people.opera.com/miket/2011/5/time.html) [Disclosure: Opera is my  
employer but I'm speaking for myself here, not representing them].


We're seeing  used "In the wild", for example on recipes  
http://www.jennybristow.com/category/recipes/, reddit  
http://www.reddit.com/ ("submitted 5 hours ago"), http://smashsummit.com/,  
the default 2011 WordPress theme  
http://theme.wordpress.com/themes/twentyeleven/ and consequently many  
WordPress blogs


We also see schema.org encouraging the use of   
http://schema.org/docs/gs.html#advanced_dates and given the importance of  
Bing, Yahoo and Google it;s fair to assume that web developers will adopt  
these patterns.


In my opinion, rather than dump , we should consider changing the  
spec so the schema.org use-cases such as time periods


1 1/2 hrs

and "fuzzy" dates like 2011-11 for November 2011 are acceptable: there  
have been previous mails to the WG from wikipedia authors, genealogists  
and those working on museum websites stating that the utility of the  
current  element is diminished because of the requirement for  
precise dates which isn't always possible for historians.



--
Hang loose and stay groovy,

Bruce Lawson
www.brucelawson.co.uk (personal)
www.twitter.com/brucel