Re: [whatwg] HTML extension for system idle detection.
On Aug 29, 2009, at 00:47, David Bennett wrote: There currently is no way to detect the system idle state in the browser. Henri Sivonen wrote: How could such a notification be abused? The first abuse use case I can think of is throttling Web Workers-based botnet computation to be less detectable by the user (i.e. taking over the user's compute resources while the user isn't experiencing the slowdown). True, but this could probably be implemented to a largely equivalent degree using the techniques currently employed by sites in lieu of a dedicated API to know when the user is idle. I agree that an event model would be a good idea. Having a straightforward way to disable wasteful bandwidth usage when the user becomes idle is a good thing. Still, being able to check the idle state without events could be useful for some code, say a periodical executer that checks the idle state prior to doing it's work. If events are the only interface a developer would have to implement their own state keeping. One issue: Is the user idle when the tab is in the background, when the browser is in the background, or when the user is away from the machine? These are all distinct cases of different levels of idleness, and it's largely depended on the use case which kind of idleness makes sense for a particular application. .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Text areas with pattern attributes?
Smylers wrote: The point is to have cases specifically _for_ it -- not adding everything for which there isn't a reason against. If textarea pattern=... wouldn't in practice be used by authors then there's no point in adding it. If it would be used then it should be trivial to show some places where it would be used. I think it's important not to forget that a great deal of web applications are internal applications not exposed to the Internet. In an environment like that performance issues with evaluating regexps against a large body of text are less of an issue, since the workstations used are under the control of the organization the application is internal to. Personally I just feel that a unified interface is more valuable than holding author's hands and preventing them from making unwise design choices. If an input field used with the pattern attribute for inputting a single value needs to be changed to a multi-line textarea with the same pattern repeated not having pattern for textareas would mean a great deal of extra work for authors. Granted, my judgement is clouded... I've always felt that the separation of input type=text and textarea seemed unnatural. I guess I'm just personally against widening the gap when the difference from a user's perspective is that one is single-line and the other multi-line. :) .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Adding alpha channel to input type=color
Victor Vasiliev wrote: I suggest to add a boolean attribute alpha to input type=color (disabled by default). If this attribute is present, the color well allows to set opacity value, and instead of sRGB, sends RGBA. Another question is which format should be used to submit RGBA color. We have rgba(number, number, number, float) used in canvas, but I feel like it's not the best format to be used in submited data. Maybe #rrggbbaa or #aarrggbb? input type=color is specified to define a simple color: http://dev.w3.org/html5/spec/Overview.html#simple-color While alpha information is useful, it's not really a color attribute is it? Using type=color paired with type=range for alpha would serve fairly well in most cases, I believe. How do the people more into design feel about this? I'm mainly a coder myself. .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Text areas with pattern attributes?
Mike Shaver wrote: It's also pretty common to enter multiple email addresses or tracking numbers or URLs one-per-line for batch operations on sites, and they would benefit from having client-side validation of such patterns. I also believe that it would be beneficial to have an option to regex-validate a text area in cases like this. One might argue that a case like this is served by having an AJAX interface with multiple inputs, but in my experience a lot of real world office work involves the worlds most used database, the spreadsheet. It's not far fetched to imagine copy-pasting a bunch of data from a spreadsheet column into a textarea, in which case it would make sense to be able to have client side validation for a given pattern repeated n times with newlines in between. I really don't see a case for not allowing pattern for a textarea. The implementation side should not be that different from the same attribute on a text input? Except for the client side overhead of parsing a large amount of data against a regex, what would be the drawbacks on having pattern on textareas? .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] A tag for measurements / quantity?
Aryeh Gregor wrote: It's not very hard to auto-convert units without semantic markup. I'd think it would be pretty easy to write a browser extension that read through a site's HTML and converted the units without author support. This would have the major advantage of not relying on authors knowing how to mark up their document correctly, so it would work in all cases instead of in probably a small minority. Has anyone written such an extension? There is an extension: http://converter.mozdev.org/ Judging from the documentation it seems to work rather well with trivial cases. But there are a number of situations where semantic information could aid conversion. For example Finnish has a rather complex morphology which makes automatic conversion tricky. The units will not be parseable from the text without parsing the language grammar. An example: Lisää 1 teelusikallinen sokeria 2 desilitraan vettä. Add 1 teaspoon of sugar to 2 deciliters of water. The roots of the words are 'teelusikka' and 'desilitra'. But it's still quite possible authors would not use semantic markup even if it was available. Additionally there are localization issues, things like decimal separators and such. It might well be such a tag would end up being used so little that automatic conversion would be the only viable option anyway. Regards, Max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Remove addCueRange/removeCueRanges
Silvia Pfeiffer wrote: Precision is influenced more strongly by the temporal resolution of the decoding pipeline rather than the polling resolution for currentTime. I doubt the previous implementations of start and end gave you a 3 sample accurate resolution even for wav files. I'll chime in here, having done extensive work with audio and video codecs. With current codec implementations getting sample- or frame-accurate resolution is largely a pipe dream. (Outside of the realm of platforms dedicated to content production and playback.) Especially for video there can be several seconds between keyframes, frame-accurate jumps requiring complex buffering tricks. A reasonable forward-compatible solution would be to allow (by whichever method settled upon) millisecond-resolution to be specified for setting/resetting from where/to play the clip. User agents could implement a best-effort, not needing to guarantee any specific resolution at this point. Regards, Max Romantschuk -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] A tag for measurements / quantity?
Ian Hickson wrote: I don't really understand the use case here. What problem would this be solving? What do we have to demonstrate that this problem matters? It might well be that there is no problem. From a practical perspective it would be nice to have an ambiguous way to mark up numerical constants in a document and thus allow a straightforward way of doing conversions. Personally, the obvious use case for me is recipes. Even a relatively simple one requires a lot of manual calculation to convert cups, pounds and ounces into deciliters and grams. While some sites supply conversion tools for this providing the semantic information straight in the markup would allow conversions for any document. With the large majority of humanity doing cooking one could argue that this would be genuinely useful. Then again, it's quite possible no one would ever use this, and it would just end up cluttering the spec. Regards, Max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] A tag for measurements / quantity?
Max Romantschuk wrote: it would be nice to have an ambiguous way to mark up numerical constants Make that an unambiguous way... I seem to have lost my negations today. -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
Re: [whatwg] Remove addCueRange/removeCueRanges
Dr. Markus Walther wrote: The much weaker goal I would propose is to support at least one simple lossless audio format in this regard (I am not qualified to comment on the video case). Simple means 'simple to generate, simple to decode', and PCM WAVE meets these requirements, so would be an obvious candidate. For that candidate at least I think one could give sample-accurate implementations of subinterval selection - tons of audio applications demonstrate this is possible. That is a good point, and having done sample editing it's true that for applications like speech sub-millisecond resolution makes sense. The problem becomes what makes sense as the chosen unit. Time is the intuitive option, but with samples we have aliasing issues when trying to match a particle time offset to a sample offset. Allowing microseconds would be a possible solution, but I doubt any authors would like to think in the terms of microseconds. But on the other hand if samples are the unit of choice that instantly ties the interval scale to the file. If an author wants to halve his bandwidth usage by halving the sample rate for PCM or FLAC (comparable to increasing the compression for a lossy format) all the interval information has to be redone. (The offsets will point to the wrong parts of the file at a different sample rate.) Time based intervals would not have this issue. The problem becomes even more convoluted when taking video into account. Then there are multiple permutations of sample rates and frame rates to take into account. It would of course be an option to have a sample-accurate option for audio only, but would this really be implemented in user agents? Authors will likely not adopt any solution poorly supported in user agents and stick to existing plugin solutions like Flash. Regards, Max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
[whatwg] A tag for measurements / quantity?
Hi Everyone, I've been off the list for quite some time, so bear with me if I missed something searching the archives. I've been looking at the meter element, which specifically states that There is no explicit way to specify units in the meter element, but the units may be specified in the title attribute in free-form text. Having used the web for the past 15 years I've always felt that it's a shame when you run into a page with a set of measurements and those can't be interpreted automatically in a sensible fashion. Especially with the fact that there are both imperial and metric units still around in this day and age. An backwards compatible inline element to specify a quantity would be rather trivial: quantity unit=cm12 cm/quantity quantity unit=kg2 kg/quantity With this implementation a number inside the quantity element would be interpreted as the numerical value of the unit. Other characters would be ignored. That way old browsers would simply ignore the unknown tag, whereas a browser aware of this tag could provide DOM hooks for things like implementing a browser extension to convert between metric and imperial units. Food for thought. Opinions, anyone? .max -- Max Romantschuk m...@romantschuk.fi http://max.romantschuk.fi/
