Re: [whatwg] Iframe Sandbox Attribute - allow-plugins?
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] The blockquote element spec vs common quoting practices
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: blockquote cite=urn:isbn:978-2-07-07533-7 pSur un pétale de lotus, j'écrivis ces quelques vers :/p p«qMême si l'on vient me chercherbr/ Comment, abandonnant la roséebr/ De pareil lotus,br/ Retournerai-jebr/ Dans le monde changeant et frivole ?/q »/p pet j'envoyais ce pétale./p p class=source cite class=auteurShonagon, Sei/cite, cite class=titreNotes de chevet/cite, p.64, Unesco, NRF, 1966./p /blockquote 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 cite just like i (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 blockquote 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 details element if browsers implement it well. The cite attribute in blockquote 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 cite class=auteur lang=jp-LatnShōnagon, Sei/cite be better?) I don't think author names are allowed in cite 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] a rel=attachment
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
On 7/15/11, Jukka K. Korpela jkorp...@cs.tut.fi wrote: 14.07.2011 16:10, Bjartur Thorlacius wrote: I don't think author names are allowed in cite 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] The blockquote element spec vs common quoting practices
On 7/15/11, Jukka K. Korpela jkorp...@cs.tut.fi 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 cite just like i (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. Cite 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 details 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 details, 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 blockquote 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 cite was implemented as i, 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. Cite contains a human-readable name of a work. That'll rarely be machine-readable.
Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 9:08 AM, Alexey Proskuryakov a...@webkit.org 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 a href=blah.php?id=123 download=blah.pdf 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] PeerConnection, MediaStream, getUserMedia(), and other feedback
On Thu, 14 Jul 2011 18:53:00 +0530, timeless timel...@gmail.com 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 shweta...@opera.com wrote: On Thu, 14 Jul 2011 04:09:40 +0530, Ian Hickson i...@hixie.ch 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
2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com 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] Geolocation - Browser usability issues with regards to asking user permission
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
2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com: 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 a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf 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] a rel=attachment
On Fri, Jul 15, 2011 at 11:24 AM, Glenn Maynard gl...@zewt.org wrote: 2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com 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] Accept full CSS colors in the legacy color parsing algorithm
On Fri, 8 Apr 2011, Tab Atkins Jr. wrote: In the legacy color parsing algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value, 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, font color=rgba(255,0,0,.5)foo/font 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 font color values, http://philip.html5.org/data/bgcolors.txt for body 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] Accept full CSS colors in the legacy color parsing algorithm
On Fri, Jul 15, 2011 at 11:43 AM, Ian Hickson i...@hixie.ch wrote: On Fri, 8 Apr 2011, Tab Atkins Jr. wrote: In the legacy color parsing algorithm http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#rules-for-parsing-a-legacy-color-value, 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, font color=rgba(255,0,0,.5)foo/font 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 font color values, http://philip.html5.org/data/bgcolors.txt for body 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
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] a rel=attachment
2011/7/15 Jonas Sicking jo...@sicking.cc 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com: 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 a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf 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
On Fri, Jul 15, 2011 at 11:57 AM, L. David Baron dba...@dbaron.org 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 Ian Fette (イアンフェッティ) ife...@google.com: 2011/7/15 Jonas Sicking jo...@sicking.cc 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com: 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 a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf 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] a rel=attachment
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] Accept full CSS colors in the legacy color parsing algorithm
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] details, summary and styling
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] summary and details elements' specification
On Mon, 11 Apr 2011, Tomasz Jamroszczak wrote:
Instead of making summary inside details working as legend inside
fieldset, we can throw away the details tag and make summary work
like label 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 summary 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:
summary for=detailsIdThis is summary. Click to show/close
details./summary
div id=detailsId hidden.../div
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 summary tag.
Isn't it the same as on browsers that don't support details?
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 summary and details for summary, 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 label could have been defined to be paired with (by default)
its next sibling or, perhaps better, with the next input field,
summary could be defined to be paired with its next sibling or,
perhaps better, with the next details 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 details. This element is really
meant to be a control for rendering vs. not rendering the contents of
the details 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 details, so the name summary is
misleading. Perhaps control would be better, but as it's really a
special kind of control only, how about open?
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] Decimal comma in numeric input
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 input 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 input type=number 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 input type=number 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 input type=number 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 input type=text, 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 input 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 output in HTML. -- 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
On Fri, Jul 15, 2011 at 1:18 PM, Ian Hickson i...@hixie.ch 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] a rel=attachment
On Fri, Jul 15, 2011 at 1:15 PM, Julian Reschke julian.resc...@gmx.dewrote: 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] a rel=attachment
On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking jo...@sicking.cc wrote: 2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com: 2011/7/15 Jonas Sicking jo...@sicking.cc 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com: 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 a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf 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 This security concern is very
Re: [whatwg] a rel=attachment
2011/7/15 Darin Fisher da...@chromium.org: On Fri, Jul 15, 2011 at 1:09 PM, Jonas Sicking jo...@sicking.cc wrote: 2011/7/15 Ian Fette (イアンフェッティ) ife...@google.com: 2011/7/15 Jonas Sicking jo...@sicking.cc 2011/7/14 Ian Fette (イアンフェッティ) ife...@google.com: 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 a tag would be a straightforward, minimally invasive way to address this use case. a rel=attachment href=blah.pdf 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
Re: [whatwg] a rel=attachment
2011/7/15 Jonas Sicking jo...@sicking.cc 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 a href=ugly download filename=pretty also seems fairly clean, and avoids combining parameters that really are orthogonal to one another. -- Glenn Maynard
Re: [whatwg] a rel=attachment
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 gl...@zewt.org Sender: whatwg-boun...@lists.whatwg.org Date: Fri, 15 Jul 2011 19:43:45 To: Jonas Sickingjo...@sicking.cc Cc: whatwgwha...@whatwg.org; Darin Fisherda...@chromium.org; ife...@google.com Subject: Re: [whatwg] a rel=attachment 2011/7/15 Jonas Sicking jo...@sicking.cc 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 a href=ugly download filename=pretty also seems fairly clean, and avoids combining parameters that really are orthogonal to one another. -- Glenn Maynard
Re: [whatwg] a rel=attachment
On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote: * 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
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 pkast...@google.com Date: Fri, 15 Jul 2011 18:20:54 To: tan...@cs.stanford.edu Cc: Glenn Maynardgl...@zewt.org; whatwg-boun...@lists.whatwg.org; Jonas Sickingjo...@sicking.cc; whatwgwha...@whatwg.org; Darin Fisherda...@chromium.org; ife...@google.com Subject: Re: [whatwg] a rel=attachment On Fri, Jul 15, 2011 at 5:38 PM, Tantek Çelik tan...@cs.stanford.eduwrote: * 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
On Fri, Jul 15, 2011 at 6:25 PM, Tantek Çelik tan...@cs.stanford.eduwrote: ** 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
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 enclosure 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 pkast...@google.com wrote: On Fri, Jul 15, 2011 at 6:25 PM, Tantek Çelik tan...@cs.stanford.eduwrote: ** 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
On Fri, Jul 15, 2011 at 4:43 PM, Glenn Maynard gl...@zewt.org wrote: 2011/7/15 Jonas Sicking jo...@sicking.cc 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 a 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 a href=blah download=filename with the origin considerations mentioned in the previous email and move on. -- Glenn Maynard
Re: [whatwg] Decimal comma in numeric input
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 createdoutput 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 input type=number 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/
