Re: [whatwg] for year input
On 20/02/2014 01:34, TAMURA, Kent wrote: Hi, The current WebKit/Blink behavior is: - Accept both of the ASCII digits and localized digits - Accept both of the standard decimal point '.' and a localized decimal point That sounds similar to what I've implemented, but users can't mix digits, decimal or grouping separators from different locales. The entire input must be consistent. Specifically, input typed in by the user is first processed using the locale of the element (as defined by the 'lang'/'xml:lang' attributes, if any). If that fails we retry with the locale of the document (Content-Language header). If that fails we retry with the locale of the browser. If that fails then we pass the string off to HTMLInputElement's internals to be set as its value without "de-localizing" it, where it will be parsed using the HTML 5 rules for "valid floating-point number" (essentially allowing ASCII digits and decimal point as the final fallback). (We start with the element and work out looking for locale information in order to give priority to the locale of the context in which the input exists.) For what it's worth I just tried the following in Chrome, and if I type in "12,34" then increment using the spinner it resets to zero, seeming to indicate that the "," was rejected. Is that expected? data:text/html, - Not accept grouping separators and don't show grouping separators > We showed grouping separators in the past. But we stopped it because grouping separators disturb some use cases. So I've discovered. ;) We accepted entering grouping separators in the past. But we stopped it because users had to know their locale correctly. e.g. "1,234" has different meaning in French locale and English locale if we support grouping separators. So essentially you assume any separator that is a decimal separator in any locale is a decimal separator all cases? Even that approach would seem to have the potential for unexpected results for users; for example, a user types in "1,234" meaning 1234 but the input takes the value 1.234. Or maybe I misunderstand? Jonathan
Re: [whatwg] for year input
On 19/02/2014 01:24, Karl Dubost wrote: I wonder if it would not be more flexible to have a `format` attribute. (or any other formatting syntax) I'm not sure a formatting attribute is desirable, at least not if it leads to content authors making decisions that are inappropriate for a given locale. A boolean attribute to say that the grouping separator is not appropriate might be useful though, given the other comments on this thread regarding other number types where such separators would be undesirable, and may not be so subject to misuse. It's not clear that in all these cases (or even in the case of years) that the grouping separator is undesirable for all locales though.
Re: [whatwg] for year input
On 18/02/2014 23:17, Ian Hickson wrote: On Tue, 18 Feb 2014, Jonathan Watt wrote: When implementing for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as "1,234". This is causing a problem for at least media wiki, because they use for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIX&action=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. My recommendation would be to just use comma separation It would be the appropriate separator(s) for the locale in use, not necessarily the comma, but I'm guessing that's what you meant. for numbers greater than . It doesn't help that much for four-digit numbers, and years beyond four digits often _do_ have commas, e.g.: http://en.wikipedia.org/wiki/Year_10,000_problem I agree that it's a bit weird (though not particularly wrong) for four-digit years to have commas. Personally I think it's a bit more than a bit weird to have "Year: 2,014". It seems pretty ugly to me, and four digit years are going to be the common case. type=number does seem appropriate for years, though. I wonder if it would be that bad to have a 'year' type to compliment the 'month' and 'day' types...
Re: [whatwg] for year input
On 18/02/2014 23:09, Jonathan Watt wrote: When implementing for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as "1,234". This is causing a problem for at least media wiki, because they use for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIX&action=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators. I should also have noted that I did get some early feedback that failing to include grouping separators in the general case would be bad/suboptimal for certain locales, but I can't remember which locales those were at this point. If anyone knows of such locales I'd be interested to hear which.
[whatwg] for year input
When implementing for Mozilla I decided to display the value to the user using the grouping separator (generally the thousands separator) of the users locale. So, for example, if the input's value is 1234 and the user's locale is English, it is displayed to the user as "1,234". This is causing a problem for at least media wiki, because they use type=number> for year input. For example: https://en.wikipedia.org/w/index.php?title=IRIX&action=history https://en.wikipedia.org/wiki/Special:Contributions/newbies The question is, should I change Mozilla's implementation to stop displaying the internal value using grouping separators, or is it wrong to use type=number> for year input. I'm erring on the former, but I'd like to solicit others' thoughts on this matter. I should also note that I can still allow the implementation to accept input from the user that contains grouping separators, even if when the internal value is set/changed the visual result will be updated to a string that does not contain grouping separators.
Re: [whatwg] Forms: and directory tree picking
On 05/08/2013 00:54, Glenn Maynard wrote: On Sun, Aug 4, 2013 at 2:47 AM, Jonas Sicking wrote: We can't do what you are suggesting for a plain since there's already a defined API for that, and that API only exposes a .files property in the DOM. Sure we can; we can always add to that API, such as adding a getFileSystem() method. A different @type may be better anyway, though. Currently my own view is that exposing a filesystem type API must be opt-in (as in new code has to be written to use it; old code isn't going to "just work"). As such a new attribute [value] such as multiple=fs could be required to make use of it, and could change the behavior of the input so that it doesn't build up a FileList, but instead sets .files to an object representing the picked directory if a directory is picked. -Jonathan But we could certainly add some way to enable creating an which exposes files and directories in the DOM, rather than just files. Doing that will depend on coming up with a filesystem proposal which all parties actually agree on implementing, so far we don't have such a proposal. Unless we think it won't ever happen, it'd be better to keep working towards that than to rush things and implement greedy recursion. It also requires an actual proposal for what such an would look like. I.e. would it be an ? Or with some sort of API call saying that flattening directories into files aren't needed? Or ? It's probably not worth worrying about this part too much until we have a filesystem API for it to enable. Any of these seem fine (though I'd lean away from an API call), or maybe , which would cause it to fall back on the current (files only, non-recursive FileList) behavior on browsers that don't support it. (I don't think "flattening directories into files" is something that should ever happen in the first place, but if it does we'd definitely need to make sure it doesn't happen in this mode.)
Re: [whatwg] Forms: and directory tree picking
On 02/08/2013 23:39, Glenn Maynard wrote: On Fri, Aug 2, 2013 at 11:15 AM, Jonathan Watt wrote: In my prototype implementation it took around 30 seconds to build the FileList for a directory of 200,000 files with a top end SSD; so depending on what the page is doing, directory picking could take some time. A static list isn't appropriate for recursively exposing a large directory. I hope that won't be implemented, since that's the sort of halfway-feature--"not quite good enough, but it sort of works"--that can delay a good API indefinitely. An interface to allow scripts to navigate the tree like a filesystem should be used, to avoid having to do a full recursion. I see this more as a means of getting directory picking working in the existing content out there that's using file pickers without requiring that content to be updated (which is not going to happen in the vast majority of cases). I would hope that it would not _prevent_ a filesystem-like API from being implemented, although I agree it would inevitably reduce the pressure for such an API. That said, such an API that everyone agrees on doesn't seem to be materializing any time soon. For example, a photo browser probably only wants to read data on demand, as the user navigates. Also, doing it synchronously means that if the user adds another photo, he'd have to reopen the directory (and wait for the long recursion) all over again for it to be seen by the app. A previous discussion (on drag and drop, but the issues are the same) is here: http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2011-November/033814.html Thanks for the link. I've read through that thread. -Jonathan That centered around FS-API, which is probably not the direction things are going, but whichever API things land on for filesystem access should probably be used for this--or vice-versa, if this comes first. I suspect they're actually the same thing, since a file picker (along with drag and drop) is the likely way to expose a filesystem-of-real-files API.
[whatwg] Forms: and directory tree picking
I'm working on Mozilla's implementation of to allow the user to pick a directory. The idea would be that the files in that directory and its subdirectories would be added to the HTMLInputElement.files FileList. A brief summary of the behavior I'm currently working towards is described below. For now we just plan on requiring the 'multiple' attribute to allow directory picking, and do _not_ plan to add a 'directory' attribute. Instead we want to see whether we can get away with allowing the user (not the content author) to decide whether they want to pick a directory or to pick individual files from a directory (perhaps by having two buttons in the UI, "Choose file(s)" and "Choose directory", since platforms generally have different pickers for the two tasks). The advantage of avoiding the need for the 'directory' attribute would be that directory picking would work for existing content with multiple> without needing to be changed. One disadvantage would be that existing content may depend on the file names in the FileList being unique. If that turns out to be a significant problem in practice, we may have to implement the 'directory' attribute. We would change the File interface to add a 'path' property, which would be the path (without the file name) of the file relative to the directory that was picked. Currently authors can use HTMLInputElement.click() to open a system file picker. To give content the ability to open a system directory picker we'd add a corresponding .openDirectoryPicker() function. In my prototype implementation it took around 30 seconds to build the FileList for a directory of 200,000 files with a top end SSD; so depending on what the page is doing, directory picking could take some time. To allow content authors with styled to provide feedback to users during scans of large directory trees we plan to have openDirectoryPicker return a ProgressPromise: https://github.com/slightlyoff/Promises/blob/master/ProgressFuture.idl We'd then fire progress events at the promise specifying how many files had been processed so far. Thoughts? Questions?
Re: [whatwg] Allowing authors to obtain a vertical
On 26/03/2013 14:55, Simon Pieters wrote: On Tue, 26 Mar 2013 15:07:55 +0100, Jonathan Watt wrote: The result of the discussion here: http://www.w3.org/mid/514a17d4.3070...@jwatt.org is that I've changed Firefox Nightly's handling of to allow it to render as a vertical slider if it has an orient="vertical" attribute on it. There was only one reply to my email to www-style, but the author suggested using an attribute which I'd also concluded was the best thing to do. I'd like to propose that this attribute be added to the HTML5 specification. I don't have strong opinions on this topic, however, if we are going to add an attribute, it would be less verbose to use a boolean attribute: My original approach for supporting vertical range was to have Mozilla's -moz-orient CSS property apply to , but the initial value of this property was 'horizontal'. That prevented the auto-orientation hinted at in the HTML5 spec (and implemented by Opera) where the orientation of the range is based on the width-to-height ratio of the input, unless explicitly specified by the author. To fix that I added an 'auto' value for -moz-orient and made that the initial value. Then I realized that authors will want to style the component parts of a range differently based on whether it is vertical or horizontal, which is incompatible with using a CSS property to specify the orientation. That's how I arrived at using an attribute, and it's to leave open the future possibility of auto-orientation that I made a direct conversion to an 'orient' attribute rather than a 'vertical' attribute. Jonathan
[whatwg] Allowing authors to obtain a vertical
The result of the discussion here: http://www.w3.org/mid/514a17d4.3070...@jwatt.org is that I've changed Firefox Nightly's handling of to allow it to render as a vertical slider if it has an orient="vertical" attribute on it. There was only one reply to my email to www-style, but the author suggested using an attribute which I'd also concluded was the best thing to do. I'd like to propose that this attribute be added to the HTML5 specification. My original email to www-style is reproduced below in case anyone wants to reply here, directly quoting parts of my original description of the problem. -Jonathan I'm working on support in Mozilla, and one of the questions that has come up is how best to allow content authors to change the orientation of to be vertical (so the slider runs up/down instead of left/right). There is some vague text in the HTML5 spec describing an example that hints that a UA might change a range's orientation based on the ratio of its width to height[1], which says: Note how the UA determined the orientation of the control from the ratio of the style-sheet-specified height and width properties. As far as I can tell that's all that any relevant specifications say on the matter though. This issue becomes tricky when user agents provide pseudo-elements to allow content authors to style the component parts of a range. Typically there are two main component parts: the thumb (the bit that can be dragged left/right or up/down) and the track (a visual "gutter" or "line" that the thumb is fixed to move along). It seems like, A), it would be desirable to be able to apply different styles to the thumb and track depending on whether the range is horizontal or vertical. For example, content authors might want to give the thumb a background image that would make it appear like one of the following two diagrams depending on its orientation: | | | | __ | | / \_|_|_ --| | | \ --| | |_/ |__| | | | | | | | | It also seems like, B), it would be desirable to be able to use CSS to specify the orientation of the range, since, to a certain extent, whether the range is vertical or not is a matter or presentation. Unfortunately, B (specifying the orientation using a new CSS property called 'orient', say) seem to conflict with A. Content author's don't have a way to select on the computed value of one property to specify the values of other properties, so they can't select on the computed value of an 'orient' property to specify different styling for horizontal/vertical range. One way to solve the issue would be to reject B and have an 'orient' _attribute_ instead, since it _is_ possible to select on attributes. It may seem tempting to say that if content authors are specifying different styles for vertical and horizontal range, then they can specify those styles in the same rules that specify the 'orient' property. It doesn't seem like that is going to provide for authors' needs in some circumstances though. For example, if a JavaScript library provides API to insert a "vertical range", and it specifies style="orient:vertical" on the range that it inserts. Does anyone have any thoughts on the mechanism that should be provided to content authors to specify that an should be vertical, given the above? Jonathan 1. http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29
Re: [whatwg] Implementation issue: step mismatch handling for
On 17/01/2013 20:13, Ian Hickson wrote: Fixed, by adding "if there is a number that matches these constraints", which means that the value now ends up at 0 and remains suffering from a step mismatch. Regarding this change: http://html5.org/tools/web-apps-tracker?from=7640&to=7641 For what it's worth the comment was wrong since it contains "value=-1 max=2 step=3>" whereas my example was "step=3>". It's only in the latter case (lower max value) that there will be a step mismatch. Also, would it be possible in future to have content and formatting changes made in different commits? Several people I've discussed this change with off list have complained that having both types of change in this one commit made it difficult to see what changed, and this is quite a small change (really they should mention that here themselves). Thanks, Jonathan
[whatwg] value sanitization algorithm
In addition to the value sanitization algorithm, some input types specify actions that the user agent must take when the element's value is suffering from underflow/overflow or a step mismatch. To make it clearer that these actions will also be run when the value sanitization algorithm is run, could the text be changed to include each type's underflow/overflow and step mismatch actions under the the respective type's value sanitization algorithm? (Otherwise it's unclear to me why some of the steps that are applied when converting the value content attribute to the input element's value have this special "value sanitization algorithm" label attached to them, while others do not.) Jonathan
[whatwg] Confusing text relating to
The text on at: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29 says: The step scale factor is 1. The default step is 1 (allowing only integers, unless the min attribute has a non-integer value). I found the words "allowing only integers" to be confusing. I initially read it to mean that "step" is only allowed integer values unless the "min" attribute is a number with a fractional part. Talking it over with dbaron we believe it is probably just a parenthetical observation that if the "min" attribute's value is an integer and the default value of 1 for "step" is being used, then the input's value can only have integer values. (This is unclear because the input's value isn't otherwise mentioned in the sentence.) Jonathan
Re: [whatwg] Implementation issue: step mismatch handling for
On 17/01/2013 19:29, Jonathan Watt wrote: I'm working on implementing for Gecko and have encountered what I believe to be an issue in the spec. Step 1 of the algorithm to find the "step base": http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#concept-input-min-zero says "If the element has a min content attribute...to the value of the min content attribute...". Should this not talk about "minimum" rather than "min content attribute"? It would otherwise seem to give bad results in the case of , which has a default minimum of zero (a default minimum makes sense in the case of type=range, since an unbounded slider would be impossible for a user to interact with). Consider for example: As it stands, the current spec text says that the "step base" is -1 (from the 'value' content attribute), the 'minimum' is zero (from the default minimum), the 'maximum' is 1, and the step is 3. As a result, an implementation would seem to be directed to enter an infinite loop An alternative reading of the paragraph beginning "When the element is suffering from a step mismatch" would be that there is no value that can satisfy the constraints of being both greater than or equal to the minimum, less than or equal to the maximum, and not suffer from a step mismatch. In which case the spec doesn't seem to define the behavior. Changing the step base text to refer to "minimum" instead of "'min' content attribute" would also fix things from that perspective. Jonathan applying the paragraphs beginning with "When the element is suffering from an underflow..." and "When the element is suffering from a step mismatch..." in: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29 If the step base considered the 'minimum' instead of the 'min' content attribute, then the step base would be zero, and thus the value would settle at zero. Jonathan
[whatwg] Implementation issue: step mismatch handling for
I'm working on implementing for Gecko and have encountered what I believe to be an issue in the spec. Step 1 of the algorithm to find the "step base": http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#concept-input-min-zero says "If the element has a min content attribute...to the value of the min content attribute...". Should this not talk about "minimum" rather than "min content attribute"? It would otherwise seem to give bad results in the case of , which has a default minimum of zero (a default minimum makes sense in the case of type=range, since an unbounded slider would be impossible for a user to interact with). Consider for example: As it stands, the current spec text says that the "step base" is -1 (from the 'value' content attribute), the 'minimum' is zero (from the default minimum), the 'maximum' is 1, and the step is 3. As a result, an implementation would seem to be directed to enter an infinite loop applying the paragraphs beginning with "When the element is suffering from an underflow..." and "When the element is suffering from a step mismatch..." in: http://www.whatwg.org/specs/web-apps/current-work/multipage/states-of-the-type-attribute.html#range-state-%28type=range%29 If the step base considered the 'minimum' instead of the 'min' content attribute, then the step base would be zero, and thus the value would settle at zero. Jonathan
Re: [whatwg] Separating intrinsic sizing out from the iframe seamless attribute
On 18/07/2012 13:31, Ojan Vafai wrote: I made a proposal for this at the end of http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2012-July/036584.html. Great! The best way to get this specced is to provide additional use-cases (for having intrinsic sizing without inheriting style) in addition to use case #3 in my email. The use cases are simple. I want to be able to embed SVG as-a-document (not as-an-image) and have it size to its intrinsic size, without messing up the style of the SVG.
[whatwg] Separating intrinsic sizing out from the iframe seamless attribute
It seems like there should be a way to get iframe to size to the intrinsic size of the embedded content without having style from the embedding document inherit into the embedded document. Could we have a way to do just the intrinsic sizing please?
[whatwg] Addition of a setExtend(in DOMString extend) method to the CanvasGradient interface
The extend mode of canvas gradients isn't under user control as it is in SVG. I'd like to propose adding a setExtend(in DOMString extend) method to the CanvasGradient interface[1], where the method would accept the arguments "none", "repeat", "reflect" and "pad". These would be defined similarly to the values that the 'spreadMethod' attribute on SVG gradients accepts[2]. Jonathan [1] http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#canvasgradient [2] http://www.w3.org/TR/SVG11/pservers.html#LinearGradientElementSpreadMethodAttribute
